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…
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.
Sounds like a great idea to make the network card selectable. Not sure why Onefinity is so against making WiFi working on their machine, but glad we have a working solution now!
I just went through this thread again, and the bottom line is that the onboard wifi is useless, most people prefer a wired solution, but some of us want a wireless option with a reliable dongle. I’ve been running wifi on several pieces of equipment in my shop while lathes, table saws, vacuums and drill presses are operating with no issue. You just have to realize that the network connection is not for real time control, but data transfer and perhaps job monitoring. In literally years of doing this with 3D printers and laser cutters on wifi in this fashion I’ve had no problem.
Others may have different experiences, but the best solution is the one that provides reliable operation for as many use cases as possible.
I know this is an old thread, but my buddy just bought the BuildBotics controller and they recommended one of the USB WIFI adapters above. There interface has a check box on the network tab to disable the internal WIFI. 
i’m intrigued by the raspberry pi usb wifi adapter as well.
in my garage, i get great wifi signal on my phone & even on my pc out there, but the onefinity hasn’t been able to find my network ap that’s only about 25ft away.
on my garage pc, i used a usb extension cable & mounted a cheapie usb wifi adapter/antenna to the top of my monitor… it’s farther away from my network ap than the onefinity but it’s working great.
wondering if there’s a raspberry pi usb adapter that has a larger antenna or if using a usb extension cable to raise the wifi adapter away from the controller would finally let the OF find some wifi signal.