Question: Client count for USB WiFi chipsets in AP mode #296
Comments
|
I remember a message here last year from a guy that had run into the 32 client limit on the adapter he was using. He had around 50 IoT devices if I recall correctly. He only needed 2.4 GHz support. What band (s) do you want to support? |
|
Thanks for your comment. I think we are band agnostic. I list some factors below but none are as definitive as the number of clients. Range/coverage is important. We keep getting asked about that. So we have looked for devices that sport an SMA connector, allowing us to put a strong antenna in a good location. Dual antenna might help. Because of the desire for range, the modest data rate requirements and the expectation that this will be used outside of congested WiFi environments, one could tilt toward 2.4 Ghz. |
|
I found a little time to add some more info.
You might want to take a look at replacing Ubuntu with OpenWRT given what it appears that you are doing. OpenWRT is designed to do what you are doing. That is its job. The cost is the same as Ubuntu. If you need help, there are some OpenWRT users here. I use OpenWRT. I also use Ubuntu.
Let me suggest a better place to shop: FYI: The Main Menu for this site is: https://github.com/morrownr/USB-WiFi The adapter that I mentioned the guy used for his 50+ client IoT setup is the Panda PAU08. It has good signal strength but it is highly unlikely the pipe is big enough for your project. We really need more details: What size and shape should the adapter be? The more details you can provide, the better we can do. |
Okay. Just what I was looking for. You narrowed the contenders down greatly. In the Main Menu item called The Plug and Play List, you will find information about one adapter that appears to meet all of your criteria. Here is a direct link to a seller: Recommend you read the review in the Plug and Play list. It has a standard removable antenna, it is USB2 (AC600), OpenWRT has a driver for it and it comes with an extension cable. It will be Plug and Play on the desktop Ubuntu (not sure if Ubuntu server ships with in-kernel drivers but I'm sure they can be added), This adapter has the longest range of any usb wifi adapter that I have tested. The following link needs updated but it hits on what you are looking for: https://github.com/morrownr/USB-WiFi/blob/main/home/Performance_Comparison.md The link to the product is at a dealer called Rokland. They do Linux so calling them up and talking to them about your project might help. They also sell higher gain antennas and directional antennas in case you need something like that to help. The one thing I do not know is how many clients the driver supports. I can round up about 12-14 clients here to test but that is about it. You likely are just going to have to order one and test. |
I am NO expert but I am am not worried about how many clients the driver supports. (Maybe I should be.) Fresh background: I am here because the integral WiFi chipset for the Pi4 peaks out at about 19 clients. It used to stall at about 6 clients before a scholar named Phil Elwell wrote a more efficient firmware patch. It had nothing to do with system resources I could touch. Phil testified that on-chip memory was getting constrained. The more features they added to the firmware, the fewer connections it could support. He ripped out some features and, voilá, more connections. The integral WiFi chip cannot be stretched any further, so I am looking a pluggable options. Still, I would like to see how they fare on the same issue that just bit me. |
|
In answer to your other question. Here is the packaging as currently envisioned. The antenna you see links to the integral WiFi radio. So that no longer cuts it. Still, it has the server and a 12-hour battery pack in a canvas case that can be carried or hung somewhere handy. We can ask for some design changes so the case will have a pocket in a strategic spot for the USB-Wifi device. Very likely the antenna will be "sewn" into the bag and not directly connected to the device, using a cable instead. We need to assume that anything long will be subject to torque during normal usage. Durability of the final system is enormously important.
The ALFA AWUS036ACHM looks a bit large . . . but if it has good range and the chip can support 50 connections, we will just make a bigger pocket. |
|
This looks like a challenge.
I say clients and you say connections but we are talking about the same thing.
The integral chip is bad. There are 3 reasons: Broadcom, Broadcom and Broadcom. The Pi foundation did a terrible job picking hardware and still are. They picked Linux to be the os and then Broadcom to supply most hardware. Bad idea.
The picture of the bag helps. It still is not clear to me what those connections are getting from the AP. Internet access? The ACHM is not as big as it may look but you would have to be the judge of that. It does have the best range. Another adapter that could work is: https://www.amazon.com/dp/B08NPX2X4Z/?tag=pandaw-20#customerReviews I don't have this adapter so I am not a judge of its range. It does get good reviews. The one thing I know is this is going to take some trial and error to see what works. |
|
Sadly the Mediatek drivers are not using |
|
Thank you for your comments, valuable prizes below
That sounds like me. I will say clients, although looking at @dubhater comment, drivers sometimes call them associated stations. It also sounds like there is sometimes a theoretical max value we can look at. I will figure out how to test a lot of connections on some of these. It sounds like there is no other choice. It isn't a number that gets published. What do they get from the AP? This is the interesting part. In addition to being an AP, it is a full web server and a router. The router is there for the times when it is connected upstream, but forget that for a moment. It provides local services to anything with a browser. Sharing photos, videos -- reliving the day. The tour director can also sponsor content: maps, restaurant guides, educational stuff, fun stuff. On a long rides, tourists can play multiplayer games: Yahtzee, Backgammon, etc. Each one holds its own cached copy of Wikipedia, a popular feature. Or real-time audio - follow the tour guide around while listening on your phone while she is speaking into hers. Anytime there is a group of people in bad coverage with shared interest, this architecture might have a play. Think remote medical clinic or refugee school. We picked tourism. This is based on the belief that good internet services are mainly provided in densely populated areas for sound economic reasons. It turns out that, geographically speaking, 98% of the globe does not have good internet service, not being densely populated. |
We will get one to test. I like their focus on range. I am also a fan of antenna diversity for consistent coverage and will probably get one or two of the other Alpha adapters which have multiple antennae. Being larger is inconvenient but not terrible. Not supporting enough clients is terrible. |
|
I'm pretty sure the theoretical maximum is in there, it's just not as easy to find as looking up that name I mentioned. Most likely it's in their sta_add functions. They should be keeping track of the number of connected clients and returning an error if the maximum is reached. |
This may not be the case generally speaking. If it was a situation where there was an exact formula for calculating the max, sure, lets use it. But lets think about this for a moment. We may have clients/connections that need very little bandwidth such as most IoT connections or we may connections that need a lot of bandwidth or a mix. I just did a little grepping around and there are some drivers that make use of max_ap_assoc_sta but most do not. I think it was a Realtek out-of-kernel driver that seemed to have a hard limit of 32 in the story I told earlier this thread. When the guy tried the Panda PAU08 that uses the rt3070 chipset, there was no limit and things worked. If there was ever a situation where testing to see what works is in order, this is it. I had given the guy a list of 3 adapters that I thought might work and the Panda was at this top and it worked, That was a combination of luck and knowledge about many chipsets, drivers and adapters but I could not guarantee it would work. All I could promise was to give his money back if it did not work,,, well, given that I do not charge, that is a joke. |
Alfa has a long history of focusing on range... and quality. I'm familiar with their line of adapters. I have several. Let me offer this: You make a list of the ones you think may be worth testing, let me see the list and I'll give you my opinion. Not all of Alfa's adapters are optimal for Linux and I might be able to point those out to you if they end up on your list. |
|
That is a fine offer! Thank you. I will take you up on it. I guess that once I set up a test, I will run all available adapters through it. |
|
I have several adapters on hand. Here is what my shopping list looks like: On the AWUS036AC: Last century (literally), I worked for a wireless company. The RF architect was all about antenna diversity. Given that one scenario is that this is worn on the person of someone who is at continuously changing angles and distances relative to the client, it struck me as sensible. I may give him a call . . . |
|
I would recommend that you bump the Alfa AWUS036AC because it uses the rtl8812au chipset. Good chipset but only an aging out-of-kernel driver. If that size of adapter will work, add the Alfa ACM. It does make a good AP. I use mine on my RasPi AP. Here are some more for you to consider:
Adapter 1 is based on the rtl8811cu chipset. As of kernel 6.3, it has an in-kernel driver but you probably won't be to that kernel for some time but there is a very good out-of-kernel driver that we maintain here. Adapter 2 uses the mt7910u in-kernel driver. Both of these adapters are nano size or close to it. The reason I am throwing these out is that I have both and, for their size, they have decent range and I am having a hard time rectifying how to get good range and make a mobile setup that won't be broken at the connection between the usb port and the adapter. I'm also leaving out some of the more modern adapters simply because you do not need them. Besides that, usb2 is more dependable and has the bandwidth you need if I am understanding things correctly. All of the new recommendations are in The Plug and Play List which will have more info with the adapter link. I'm going to pop some popcorn. This is going to be good. |
|
Brian, Here is another one that might work for your project. It is also in The Plug and Play List. It uses the rtl8812bu chipset. We have a good out-of-kernel driver here at this site and it is plug and play with an in-kernel driver on kernel 6.3 and later. This football style adapter is small, cute, has removable antennas and good thermal characteristics. It is ranked one level below the ACM on Alfa's range ranking scale so the ACM may be preferred but it is cute. I have not given them a head to head range test but can if you want. Don't even think about asking me how many adapters I have. It looks like the Alfa ACM and ACU are the only 2 on the list with dual removal antennas. |
|
Great stuff! Thanks. I will add a couple of those. I am so very glad we connected up.
I had a solid couple days of funk when I realized I might have to use a pluggable device as a mission-critical component in a portable setup. I am thinking now that, we sell a hat as part of the kit. Run a USB cable up to the hat, which has some jazzy antennae. Quite likely, we will include an LED lamp, for night tours. ;-) In seriousness, there is a challenge to put the antennae and device in decent spots and protect the cord from being accidentally yanked. It puts more pressure on satchel design. If you still have popcorn, here are some other complications it causes. There was to be one pluggable USB-Wifi only - for connecting to the cloud upstream. There was even a pocket for it, for storage while you are on the move. NOW we may have two, the "upstream dongle" and the "downstream dongle" which hosts a Wifi network (with 50 connections). The human factors are significant. We want to make them intrinsically unmistakeable. A technologist might suggest that we use the same device for both upstream and downstream. Just ask our tour guide to hop on a config screen and change modes whenever they want to switch from one to the other as their needs change. I consider that idea to be product suicide. If there is no overlap between the chipsets used for the upstream dongles and downstream dongles, then the system can do the right thing when a dongle is plugged in. How to make them unmistakeable? Well the upstream dongle might be compact and the downstream one might be tethered and sewn into the satchel. |
|
Hello everyone! As I was getting organized the following occurred to me. Any given chipset is likely to support the same number of clients (associated stations) in AP mode, no matter what label is on the adapter. There may be other differences — RF performance, antenna count, durability — but the make/model will not affect max clients behavior. This belief simplifies testing. If I am wrong, please correct me. |
While I do not have the number of clients/connections to be able to test this, I am under the impression that it is not the hardware that may limit the number of clients, but rather the driver. It might be time to research the issue. The Truth is likely Out There. I had to steal that one from X-Files. |
It would be wonderful if some underlying causes could be sussed out. At least in one case, the Pi integral chip, the hardware is the bottleneck, according to Scholar Elwell. According to him, each client requires the chip to reserve some on-board memory for state management and cryption. He also derided the chip, so it may be a unique situation. All of the units pictured here are being driven by one of the fine drivers on this site. RealTek is very dominant. The Pi has plenty o' memory. We cannot test 50 clients under our own power, so I think we will look for a local testing center. We are in Silicon Valley, so there should be something. We can practice testing with 20 units. |
|
Not that you need more options but here is something to add to the mix: https://www.raspberrypi.com/products/compute-module-4/?variant=raspberry-pi-cm4001000 The Compute Module 4 comes in 32 variants. You can totally leave out the onboard wifi so it is not even there to deal with. It would require an I/O board but there are numerous available that provide a lot of options. You can even find I/O boards that support things like M.2 wifi cards. This may provide a lot of options and reduce the amount of limitations for your project. I've been reading your posts and am well aware that your project has some challenges.
Allow me to correct you. Several of the pictured wifi adapters do not use drivers from this site. They use drivers from the following site: https://github.com/torvalds/linux Linus says hi. Linus' site has the drivers you want to use as they meet Linux Wireless Standards. The drivers here at this site are the Realtek out-of-kernel drivers. I maintain them and do my best to make them reliable and easy to install but I do not recommend users buy Realtek wifi adapters that use out-of-kernel drivers because these type of drivers are not dependable in the longer term. All of the adapters I have been suggesting use in-kernel drivers. There is currently one situation where you may need to use out-of-kernel drivers until such time as the new in-kernel drivers are matured and in the kernel that you are able to use for this project. Those chipsets are the rtl8812bu and rtl8811cu. The in-kernel drivers for both of those chipsets are new as of kernel 6.2 but I recommend kernel 6.3 or later. FYI: I do consulting at times. Generally when I am contacted. someone or some company is working on a project for commercialization. They make a plan and often they buy products to start building without fully understanding and testing. I have lost track of the number of times I have tried to help when large quantity of parts such as boards and wifi adapters have already been purchased and the person is trying to make what they have work. What I usually want to say is that if might have worked out better if you had talked to me before you bought the parts because you have parts that are going to make your project a challenge. Very often Realtek USB WiFi adapters are included and are at the center of what will make the project a challenge. You appear to be doing this right. The long pole in the tent is generally the wifi. You are researching the hell out of what will meet your needs. That needs to be done first and then the distro needs to be determined and the cpu hardware along with power. Figuring out what works and is going to be dependable needs to happen before committing to any large purchases. Your project is complicated by the need for the end product to be able to hold up in a mobile environment where users may not take care of the product. Most of the projects I help with are robotic type situations where the board, power supply and wifi are not exposed to physical abuse. Yes, the supply of popcorn should hold out for some time. |
|
Well, this is fun!
We might have a bit more history than you expect. This started as a PC-based system, it moved to the Pi during Covid. (tourism + covid == nothing) Useful entertainment and, retrospectively brilliant. The integral WiFi is the absolute anchor of the system. It is the "admin" port. Just your smartphone and the info on the product label. It's web driven so any device can do it. Being integral makes it more reliable. Vital for a product that will fly to all places in the earth.
Our software is built with scripts and then reproduced through a straight load of a disk image. We try to pick a tolerably recent version of umpteen packages and then not change them . . . for years. Drivers will be part of that, once we pick the supported adapters. I believe the package in our vault includes Ubuntu 22.04.1.
Thank you kindly. :-) (Some of this is driven by old scar tissue. I am more keenly aware of the downsides of an unsupportable product that a newcomer.) Just a few months ago we learned that we had under-estimated the number of people our customers would attach to this. Shortly thereafter, we learned that the integral (admin) radio would not carry the load. Only after we get that sorted, can we move onto the core issue of app load on the Pi4 with a lot of demand.
This is very good to know. |
|
Update on the project. We are doing qualitative testing, not comparing range, throughput or connection counts, although we are getting close. One interesting challenge for us is that when a client (phone) goes out of range, it switches to LTE for internet traffic. Reasonably satisfied, it is rather unhurried about reconnecting to WiFi when the user comes back into range. I see why it works that way but it is not what we want.
I admit the AWUS036AC was surprisingly big. We will order the ACM. |
I wish there was a nice easy solution to this and there may be but I unaware of it. Users turning their data is the only solution I can think of. Keep the updates coming. |
|
Here is an update; it won't center particularly on drivers for USB WiFi but may be of interest to some folks. Smart Phones: Present doggone huge challenges. For example, the selection of audio codecs in mobile Safari and Chrome have shifted rapidly and do not necessarily present an internally compatible set (lookin' at you Cupertino). Also, Safari has only started supporting a streaming media source very recently. w3c/media-source#320 Mechanical Design: These USB WiFi dongles present serious disconnect opportunities. Our market morphed to the plan that users may carry this with them. USB in general is not that secure but some of the dongles have a design such that it seems they barely slide in halfway. Immediate vulnerability when things are flexing. If the dongle comes out, all the stations all disconnect and you are royally Effed for five minutes. So, maybe some of these drivers have stability problems but we haven't even noticed yet . . . RF range (line of sight) with some of them is very good. Easily twice what we need. Still some issues with antenna placement. We arrived here looking for something that can carry 50 stations in AP mode. Stress testing that from a practical point of view is a wee challenge. We are tapping local high school kids. If you stand back, we have solved many problems by throwing hardware at them. Smart phone compatibility is tenuous, so we are throwing an Android phone in the package. Maybe later, guides can use their own phones. The integral WiFi cannot support the application, so we are adding a WiFi USB adapter. USB WiFi adapters tend to fall out, so we are gonna incorporate an extension cable that can be more secure. Oy! |
If you could design and adapter, what would it look like? |
|
Thank you for the question. I can offer some provisional conversation-starters. Let's say the mission is: USB Connector: The first thing is that the USB-A connector is not my favorite pick. USB-C takes less room, especially if you consider the body of the connecting cable. Right angle USB-C cables are easy to find - I use that to power the Pi. So are cables with thumbscrews. https://www.amazon.com/StarTech-com-Screw-Locking-Cable-10Gbps/dp/B09J99WGSF/ref=sr_1_3 Supporting thumb screw sockets would be a valuable product differentiation. Antenna: Standard dipole antenna might not be right for every application. Google Naturally, we won't be using the dipoles we get in every package, a terrific waste. It might be good to have an option of no antennae with the device but an extended list of reference antennae that can be used. Spectra: Standard consumer WiFi adapters perform some sorts of frequency selection based on factors that are opaque to me. Some levers to control that might be called for. In an integrated device, the designer is likely to know whether they most need optimal range, optimal throughput, maximum station count, etc. Go back to the antenna, which are sometimes optimized for a particular frequency (https://www.data-alliance.net/antenna-2-4ghz-2dbi-directional-patch-adhesive-mount-w-rp-sma/). You would want the adapter to sing in chorus. |
|
I hope that was helpful. I will append a couple of comments. My section above on Spectra might be moot. I think we know how to get the desired channels. This model looks interesting because it has four RP-SMA ports. https://www.alfa.com.tw/products/awus1900?variant=36473966231624 We can combine it with four high-gain patch antennae and probably get good coverage in all directions. (Patch antennae are easier to mount/affix/embed in some designs.) So the dipole antenna are probably superfluous, along with the cable, CD, mounting fixtures, etc. It's bigger, but I think that is OK. Size goes behind: I am sure they selected that USB port for an excellent reason but it is the only one we have no hardware for. We are fat with USB cables of all kinds, except for the one on the AWUS1900. |
|
Brian, I need to attempt to wave you off from the AWUS1900. Realtek ceased work on the out-of-kernel driver for the rtl8814au chipset in 2019. It was a bad driver then and is not getting better. There is no in-kernel driver. The only known out-of-kernel driver for the rtl8814au that is being maintained is the one I have up here (as far as I can tell). Also, this chipset can consume up to 900 mA of power and the thermal characteristics are really bad. Did I mention you should run, not walk, away from this or any other adapter with a rtp8814au chipset?
Yes. I am trying to put together a couple of proposals for adapters. I think the usb wifi makers are missing the mark in at least a couple of areas where I think the market is there. Nick |
Consider me waved off. Thank you for saving me a bunch of time. Both the USB connector selection and the ventilation suggested a lot of power consumption. The Alpha AWUS036AC has performed well. We are going to be demoing with it.
My only vantage is a system integrator. It seems that manufacturers optimize things for consumers that are not right for OEM. This may not be the same as your angle. Still, I will mention: In consumer-targeted adverts, the emphasis is relentlessly on some theoretical top speed. (Given that such speed are many times higher than normal consumer internet, it has been a bit of a head scratcher.) We care more about other issues. One can look at LTE-M and NB-IOT to see that some market segments strongly prefer max range and low power. I don't understand why there is so much activity around wearable antennae and Body Area Networks but it seems relevant. My wife and I just spent fifteen minutes considering ways to integrate antennae so they would be "acceptable" to male and female guides. It is at least two different designs. I have already given comments on USB connectors and adapters without antennae in the box. This GitHub repo provides fantastic guidance for people who need to make adapter choices. I think there is a need for analogous documentation on antennae. This antenna works hilariously well with the Alpha AWUS036AC. https://www.data-alliance.net/antenna-2-4ghz-2dbi-directional-patch-adhesive-mount-w-rp-sma/ They cost less than $3, and they come with 5 feet of coax. Plug right into the adapter and work instantly. |
Remind me of the chipset that this adapter uses. What driver are you using? |
|
Nick, the Alpha AWUS036AC uses rtl8812au. I am using the driver on this repo. We picked it because it had good range line-of-sight with the stock antennae. The Alpha AWUS036ACU uses rtl88x2bu. It seems like a contender when we have time to compare. Having four, not two RP-SMA connectors would be a whopping advantage. This led us to eye the AWUS1900 before you waved me off. This may be tied to our own peculiar application — wanting good coverage off a mobile human. The human body is full of water and has a roundish cross-section. Unfortunately, the only four-antenna adapters I found use the rtl8814au. |
|
Brian, Various comments in the hope that it might help:
The rtl8812au is a good old chipset that is owned by many Linux users, including me. It was a generation 1 AC1200 chipset. The out-of-kernel driver I have up here is good. If fact, I would go so far as to the say that this driver is the best out-of-kernel driver that Realtek has ever released. Also, I have the source to a slightly newer version of the source that I would like to get up as I have time. I could give that project a priority bump if it would benefit you. It would take at least 2 months. Realtek's last and final release was in 2021. No more Realtek support. I have an Alfa ACH that also uses the rtl8812au chipset. The big difference between the two is that the ACH is what Alfa calls "high power" whereas the AC is "standard power. The ACH has astounding range but is more expensive. On the downside, the rtl8812au will likely never have an in-kernel driver. There used to be others that supported recent released of this driver but not so much anymore so if something happens to this site, your options could be limited.
I have an Alfa ACU. It is a cute little adapter. I have a review in the Plug and Play list. Yes, it uses the rtl8812bu chipset and is in the Plug and Play list because it does have an in-kernel driver with kernels 6.2 and later. It has good range and good thermal characteristics. If your testing shows that both adapters meet your needs, I would go with the ACU as you have options for which driver to use and the cost of the ACU is half of what the AC is.
Humans are problematic. Put that wearable antenna in a hat. He he. I am not an EE but I think that the 4 antennas on the 1900 are used like this: 3 for 5 Ghz band and 1 for the 2.4 Ghz band. That allows for optimizing for a specific band. Having 4 antennas may or may not help. The adventure continues... Nick |
If I had the hardware, I might add support to rtw88. How hard can it be? 😎 Unfortunately this and the RTL8814AU are a bit more expensive than the 1-7 USD devices I have bought before. |
I needed a good laugh. For those watching from the stands: The 1st gen Realtek AC class chipsets are not supported in rtw88. It is highly unlikely the rtl8812au, rtl8814u or rtl8821/11au chipsets will ever see in-kernel support. Realtek has terminated work on the out-of-kernel drivers. I see those chips as dead-end. |
For those chipsets or for anything going forward? |
It was a joke, but also not. „How hard can it be?” has produced results for me in the past. I started with close to zero knowledge of wifi and drivers, e.g. I was asking questions like „Do beacons come from the AP or the client?” Still, I managed to add support for RTL8188FU, RTL8188GU, RTL8192FU to the rtl8xxxu driver, so how hard can it really be? :) |
|
It is surprising that the most interesting adapters out there are based on old chipsets and drivers (by technology standards). I am not intentionally shopping for antiques. While a driver being in-kernel is an enormous factor for a hobbyist or consumer, it is not for us. All of our systems are created from a Linux build image that we make with the necessary goodies, and is frozen. In fact, we turn off the capability to upgrade it. The current image has not changed for 9 months. Putting a USB WiFi driver into the image is a small one-time effort in the scheme of things. Your drivers were particularly smooth to install.
I had had similar thoughts. The only way to find out is to get one and see. /sigh/ |
It should be a concern. |
I'm all for you giving it a try. There are a lot of Linux users out with rtl8812au based adapters. I'll even help test. Now let me tell you why it would be a challenge. The rtl8812bu chipset has an in-kernel driver primarily because Realtek provided and maintains the core part of the rtl8812b driver (in rtw88) and the firmware and all that had to be done was provide the usb support and yet that took over a year if memory serves me correctly. To support the rtl8812au chipset, you have no firmware, no core driver and no usb support. |
I understand. Basically you are building an embedded product that is fixed. However I see validity in what @bjlockie is saying. This site gets about 20k hits per week but that is only part of the fun. I get direct messages from companies asking me to help. It often goes something like this: We had a plan and then when we sent engineering samples out to customers, the customers came back with... we need it to do this or that and we can't get the driver to do that. Can you fix it? Sometimes I can fix it and sometimes I can find a way around the problem if I can get info to analyze. Often, and especially with drivers that Realtek no longer maintains, it is just a bridge too far situation as we don't have and can't get reasonable documentation or help from Realtek. With a still maintained Realtek driver, I have a contact or 2 that might be able to get Realtek to work the problem. There is a massive difference in support between Realtek and Mediatek. Example: A guy reported a problem today. It is with AP mode in the mt7921u driver. Two others had reported what is probably the same issue over the last few months so I said there is something to this even though I could not duplicate it so what did I do? My reply added one of the Mediatek kernel devs on the message. I explained and asked if he wanted me to take this is linux-wireless. He replied a few hours later thanking me for the report. He said let's work it here as this gives us more flexibilty while we are trying to discover what could be causing the problem. He also addressed 2 other Mediatek kernel devs to ask if they had ideas. Mediatek kernel devs do stop by this site. Brian, if I were in charge of a product that used wifi, I would be doing what you are doing... research the hell out of it before spending any real money. Now, to the bottom line. Given everything I know, the only Realtek chipset I would consider is the rtl8812bu but would give priority to adapters that meet the need and are based on Mediatek chips because support is far better and the drivers are Linux Wireless Standards compliant (don't under estimate what this means.) Working on Realtek drivers is an adventure as their out-of-kernel drivers are a mix of the depreciated WEXT and some things that they pulled out of their asses as far as I can tell. |
|
Nick, beautifully said. Thank you. I appreciate the advice.
I didn't set out to make our needs complicated, that's just kinda emerging on its own. The need for a person-held device (a human borne AP) emerged because we are replacing analog walkie talkies. This led to fixation on RF coverage. Sadly, I cannot put antennae up from each shoulder or in a special hat. We can have a special utility belt with has embedded antennae. With only two antennae, RSSI is changeable when the human AP turns in a circle — we get disconnects. I believe that all four-antenna USB/WiFi adapters use the dreaded rtl8814au. Its power consumption alone makes it completely unusable. So, what does that leave in terms of desperate fallbacks?
|
Do you know anyone who would like to donate one of these devices? |
Is this referring to the RTL8814AU? If so, I have one. I could ship it before Thanksgiving. |
Me. I have an extra adapter based on the rtl8814au chipset. Whadda ya think? I actually only have one adapter with the rtl8812au and rtl8811au chipsets but can probably round something up for you. It is not like we don't know people around here that have adapters. If you want to give it a try, I'll try to support you. FYI: These out-of-kernel drivers have firmware inside. I don't know if you will need to extract those excrypted files or what but gotta have the firmware files. |
|
I don't have a preference. I meant the RTL8812AU, but I won't say no to the 11AU or 14AU either. The more the merrier:
The firmware was the easiest part. To extract it you just need a text editor and |
|
By the way, Brian, did you see the Banana PI BPI-R3? I don't know if it's otherwise suitable for you, but it has 8 antenna connectors. |
|
I can also contribute a Alfa AWUS036AC, with the rtl8812au, to the cause. Should there be a cause . . . Same timeline — a couple weeks out. Starting a trip tomorrow.
Thank you for that. Never heard of it previously. Wow. As you can imagine, I have constraints on power, weight and bulk. In weight and bulk, people tell me I am at the hairy edge of a generally acceptable product. Most tour guides are women and all of them have other stuff to carry. Given that all these problems get sooooo much easier with better placement of antennae, I am starting to think about pushing back there. We might need to launch with a product that is not unobtrusive — antennae up high and visible. This will presumably reduce the market size but we will be reaching early adopters anyway. There is still friction in other areas. iPhones, for example need to have a Feature Flag set to listen to streaming audio using our technology. I believe that will eventually go away. So, we can sand away at these friction points gradually. Saves me from an excessively steep production ramp anyway . . . |
|
For those interested, I have gotten out of the previous rathole. Basically the antenna must be up high — above the shoulder. This voids my previous approach of putting a load of antennae in all directions around a belt. Concern over multipath might still cause me to go with two antennae. But there is a new factor: a cloverleaf antenna. (https://www.ebay.com/itm/252206816062) Never heard of it before. I fell into a part of the internet populated with drone hobbyists; they are a little antenna wonky. For example, they recommend using a three-leaf clover to transmit and a four-leaf clover to receive. I bet you didn't see that coming! In theory, cloverleaf antennae have intrinsic multipath resistance. This might (possibly) obviate the need for two antennae. The visual appearance is different — instead of having two dipole sticking up in the air, it will look like there are mushrooms growing out of the guide's shoulders. (https://www.ebay.com/itm/266333867452) Possibly this will be better. |
|
Brian, This keeps getting better. Did not see that coming but I can see the drone folks pushing development. Nick |
We are trying to serve a busload of tourists with an onboard server using Ubuntu on a Raspberry Pi 4. We have plenty of storage, processing power and bandwidth to serve 50 folks at "normal" usage levels.
The connection-count limit caught me unawares, though. Oops!
The approach is to use a USB/Wifi device based on one of the chipsets in this table, in AP mode. (https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Chipsets.md) It works in concept but I can find no documentation, official or otherwise to suggest how many connections the system might support. Can anyone point me in the right direction?
At some point we can organize some scale testing to verify any claim but, as you can imagine, that is arduous. It would be good to know what claims there are, if any.
The text was updated successfully, but these errors were encountered: