131–140 of 295 posts
Earlier quoted context omitted.
I did not use the wrong units, I converted them. The speeds available in my area currently max out at 1.2Gbps which is 150MBps.
When talking about network bandwidth, it is custom to measure in bit-per-second therefore the "bps" notation. If you convert to bytes, it is highly recommended to use "b/s" notation instead, i.e 150MB/s, to avoid confusion.
We need reliable, real-world ~20mbit/s for our warehouse scanners, not 382722 theoretical Gbit/s 5cm from the access point. And roaming that works instead of stupid clients clinging to somewhere or being thrown into a reconnect loop when the AP tries to get them to roam. I know this is theoretically possible today. But in the real world, I have inherited the setup, so AP locations are fixed for now, clients are some…
LoRa is quite nice for this in the lower frequency bands, and the bandwidth should suffice for this sorta thing. And the tech is super cheap to build and maintain, both hardware and software is open source.
Oh no. I haven't even upgraded to WiFi 7 yet!
You are not missing too much. One of the core features (MLO) is currently mostly scam. APs/Clients negotiate the protocol (and it shows up in the status) but doesn't it to either increase robustness or bandwidth (by combining/switching between two frequency bands). Also the driver quality is a huge mess. (We tested it using the latest generation Cisco Enterprise gear but also with Prosumer stuff like Ubiquiti or TP-L…
Earlier quoted context omitted.
I've had similar issues with clients (Blink camera sync modules) connecting to far-away APs instead of the much closer router. I could not force them to connect directly to the router no matter what. Turns out the 2.4 GHz radio of my router had died (Fritzbox 7590, apparently a common issue), thus forcing 2.4 GHz-only clients to use those other APs.
In ubiquity gear you can “lock” devices to a specific endpoint. I suspect ultimately you would prefer to have failover available but at least for troubleshooting you can see how it connects to that specific AP. Similarly you could see the amount of clients connected to an AP on every frequency and WiFi version.
It will still try to roam, it will still cause issues.
A lot of the roaming logic is in the clients. Newer android and iOS versions have gotten better but there are tons of old and new devices with poor roaming logic and capabilities.
Earlier quoted context omitted.
Dead outside the US unfortunately, worse range than regular wifi due to being strangled by lower channel width and ridicolously low power limits. The two bulky HaLowLink routers are the only off the shelf thing with support for it, it's nonexistent as a wifi standard. I was so excited when I discovered it a few months back after struggling for years to set up reliable wifi for outdoor robotics, only to realize we can…
LoRa is not fast enough?
Earlier quoted context omitted.
How often do you see your router's UI to justify any change?
I had a TP-Link deco, which while great as mesh, you couldn't limit the speed of certain devices. Which was again fine, except when the PlayStation 5 in a room could literally saturate the whole 250mbs bandwidth of my internet and when it would do an update would make our whole houses internet unusable. It's seriously impressive how it wasnt possible to set per device speed limits or even QoS which has been a thing s…
We need reliable, real-world ~20mbit/s for our warehouse scanners, not 382722 theoretical Gbit/s 5cm from the access point. And roaming that works instead of stupid clients clinging to somewhere or being thrown into a reconnect loop when the AP tries to get them to roam. I know this is theoretically possible today. But in the real world, I have inherited the setup, so AP locations are fixed for now, clients are some…
> or being thrown into a reconnect loop when the AP tries to get them to roam The AP does not have visibility into what the client actually sees, and no, a coordinator that has knowledge what the APs see isn't that much better. Imagine a situation with two APs and a client being in the middle of the two in a RF-impeded situation (i.e. your typical office building). AP1 may "hear" the client better (i.e. it gets a hig…
Sometimes we forget that for the communication to be reliable, signal must flow both ways. Clients will happily connect to far away APs, but won't be reliably heard back.
Solution is to use more APs and lower their radio tx power. A lot of customers push back on the approach because they have only one gaming router monstrosity in their country home and it works perfectly, not understanding that their downtown office with 150 devices have nothing in common.
We need reliable, real-world ~20mbit/s for our warehouse scanners, not 382722 theoretical Gbit/s 5cm from the access point. And roaming that works instead of stupid clients clinging to somewhere or being thrown into a reconnect loop when the AP tries to get them to roam. I know this is theoretically possible today. But in the real world, I have inherited the setup, so AP locations are fixed for now, clients are some…
I hadn’t realised that DECT is still in use. It was pretty good in its heyday so glad it’s survived.
Earlier quoted context omitted.
In ubiquity gear you can “lock” devices to a specific endpoint. I suspect ultimately you would prefer to have failover available but at least for troubleshooting you can see how it connects to that specific AP. Similarly you could see the amount of clients connected to an AP on every frequency and WiFi version.
You can ban devices from all access points except one. That is not "locking" it to one, it's just preventing it from successfully connecting. It will still try to roam, it will still cause issues. A lot of the roaming logic is in the clients. Newer android and iOS versions have gotten better but there are tons of old and new devices with poor roaming logic and capabilities.