Support for USB network adaptors (Feature Unavailable)

There is no need for that, I think that there are plenty of other/better options that don’t require me to flash my SD card.

Mesh networks are cheap and benefit the entire household!

-Alex

1 Like

My understanding is the Buildbotics OS is based on Raspbian. This web page lists a ton of wifi adapters that are supported (to varying degrees) by Raspbian and should not require changes at a “deep kernel level.” RPi USB Wi-Fi Adapters - eLinux.org
You can basically just add a pull-down menu that lists any wifi adapters that are detected by the OS at boot time, including the internal one plus any other one that someone tries to use. If the OS detects it, great, we can use it. People can share their experiences with different adapters and you will quickly end up with a short list of adapters you can recommend to customers.

1 Like

Unfortunately, Buildbotics uses a edited version Raspbian with a bunch of other things on top of other things on top of other things. It’s a very custom mesh of code.

I agree with Alex. I use a TP-Link Deco M5 Wireless Mesh System (3 bundle set on Amazon for $150) into the OF about 75’ away from the Main Mesh Unit that is wired to my Verizon Router, Mesh System wi-fi through 2 walls to a shed next to my driveway. Each unit has two Ethernet ports you just treat as wired Ethernet connections to anything, like the OF Controller. Assign a fixed IP Address to the OF in the Mesh Network set-up or you will go crazy trying to use the OF remote over your network through a browser. Otherwise, no problem.

2 Likes

Unfortunately that is the best solution so far, treat the controller like it has Ethernet only, and don’t even try the WiFi. Hopefully Onefinity will support a USB adaptor soon.

Update: External wifi is working!

Shout out to Drew Fisher on Facebook for finding that this external usb wifi dongle is supported, without any intervention from Onefinity or Buildbotics required!

I put one on mine and it worked immediately, and now I get a wifi signal without needing a repeater six inches from the controller.

14 Likes

My wifi connection was working but the signal was very weak so I thought I’d give this one a try. When you say “it worked immediately” are you saying you didn’t have to change anything on the 1F controller to disable the internal wifi? I plugged the CanaKit adapter in and booted the controller and while it recognizes the new adapter (wlan1) it is still using the internal wifi (wlan0):

pi@onefinity:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:3d:9c:7b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 27614 bytes 480006259 (457.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 27614 bytes 480006259 (457.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.22 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::250b:849f:bec0:2848 prefixlen 64 scopeid 0x20
ether b8:27:eb:68:c9:2e txqueuelen 1000 (Ethernet)
RX packets 1942 bytes 546801 (533.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 555 bytes 89403 (87.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 1c:bf:ce:59:f0:ae txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Well, I guess I don’t know for sure that it is using the USB WiFi, but the internal WiFi would not pick up my regular WiFi network, which I am now connected to, and it wouldn’t even pick up my WiFi repeated until it was within a foot of the controller, so I think there is no way it could be using the internal WiFi.

It actually did not work immediately (or at least I did not try). I did reboot the controller.

what is interesting is I literally just plugged mine in and I believe it is using it. I agree that it shows everything on the wlan0 link however my output shows a mac address difference that would indicate maybe mine is working differently than yours. If you look up the mac ranges for RPI (Raspberry Pi Foundation <- MAC vendors list :: udger.com) you can see that the 1c prefixed that I show is not theirs.

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.144 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::c160:9e12:e4d4:c951 prefixlen 64 scopeid 0x20
ether 1c:bf:ce:55:c5:e0 txqueuelen 1000 (Ethernet)
RX packets 742941 bytes 86413180 (82.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 546780 bytes 128398863 (122.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:59:23:f2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Definitely weird. Mine seems to be picking up the internal one (MAC b8) first and then the external one (MAC 1c) while yours is the opposite. I was able to hack it and make it work but have been trying to avoid messing with the default config too much so I will see if I can find a cleaner solution.

OK I found a solution I like. It still involves modifying the 1F software but at least is not a total hack. I will provide this solution in case others run into the issue where the external adapter is not taking precedence over the internal wifi.

The solution is to entirely disable the internal wifi which is done by editing the file /boot/config.txt. However, the /boot file system is mounted read-only by default so first you have to remount it read-write:
sudo mount -o remount,rw /boot

Now you can edit /boot/config.txt with your favorite editor and add the following:
dtoverlay=pi3-disable-wifi

Now reboot and only the external wifi adapter will be recognized by the OS.

2 Likes

Excellent work here! I got to the point of figuring out that I needed to change the config.txt file (after looking at all the DHCP-related alternatives), but could not figure out how to make /boot writeable. Glad you posted this. Even enabling unique names for all devices did not help in finding the solution to the randomly assigned wlan0 and wlan1 problem.

The Edimax adapters work very well with the RPI also. I’m running the 7811.

Glad I was able to provide the little piece of info that you needed! Also good to hear that the Edimax adapter works. Honestly, I do not understand why @OnefinityCNC insists it would be so difficult to support external WLAN adapters. It is not a matter of having to support a bunch of different drivers as they are claiming. There are clearly multiple adapters that work out of the box with the built-in drivers. The solution is quite simple, IMO. In the Network configuration screen, they could have a pull-down list of all the network interfaces that are recognized by the OS e.g. wlan0, wlan1, eth0. Pick the one you want out of the list and that is the one it will use. If you try to use an adapter that doesn’t work with the stock Raspian drivers, it just won’t show up in the list. The community can identify which adapters work as we are doing here.

3 Likes

We’re thinking alike here Robin - I just added a new feature request to simply disable wlan0.

2 Likes

Agreed. The issue seems to be that Onefinity is a hardware company and Buildbotics sold them on the idea of their controller but does not have the resources to make it fully custom. The Onefinity decision to put the controller in a faraday cage did not help.

However, since we now have access to the system through SSH and keyboard, I’ve made several changes, among them publishing a samba share to directly download. Interestingly the software does not pick changes in the directory up until rebooted, but it’s still useful.

I might have preferred a different controller: There are several others that could run on the RPI, but the driver interface is the issue and we don’t seem to have much information about it.

Overall I really like the hardware and perhaps we can help them do better on the controller/electronics.

BTW, the RPI switching wlan issue is pretty common with lots of bad solutions. It’s an artifact of a Linux change from a few years ago and binding of hardware to software devices Looks like we were on the same path and I had not yet found the mount incantation. Thanks for doing that; much more stable now. I did just mill out an aluminum blank to make my own touchpad since The official one is so expensive.

Hillsboro, OR

1 Like

Disabling on the on board wifi device would then require an external wifi connection or a wired connection. But, since we’re dealing with a radio in a faraday cage anyway, perhaps that is the better solution even though it adds cost.

1 Like

Right, I was thinking this would just be an option for people who are wishing to add an external Wi-Fi, like the Cana Kit adapter that some people are having success with!

Upon further reflection, I think you’re right. The wifi in the controller box is unreliable and not really useful. The exceptional case is when the router is about 5 feet away. The only wifi option ought to be an external device. I’ve found the Edimax dongles to be bulletproof on 3 other designs (sprinklers, MQTT server, etc.). There are many USB dongles that use the same chipsets and they are not expensive. Of course, a plastic lid on the controller box would probably fix the problem entirely also…:slight_smile:

If wifi is important to you, why don’t you try using a wifi extender that has an ethernet port and connect your Onefinity to the extender using an ethernet cable. Something like this:

I haven’t tried it as I have cabled ethernet everywhere but it should work.

Martin

That’s what I was doing, but this solution is far better.