We have purchased ~10 mangoh reds for building IoT devices, and have been trying to enable a wifi access point. We tried to use the out of the box wifi, but it seems like development is not yet complete on those drivers: MangOH Red , wifi client start failed and the executable fails:
To work around this, we purchased some 300M Wireless USB adapters, but whenever we run lsusb, we get an error. We have tried lsub with at least 10 types of USBs, ranging from smart card readers to storage, all receive this error:
root@swi-mdm9x15:~# lsusb
unable to initialize libusb: -99
Those USBs with LEDs that light up when plugged into a traditional computer do not light up when connected to the mangoh. We checked the USB pins and they are receiving power. It seems as if the USB driver is not working.
Thank you for that suggestion. We have ordered that, but we still would like to use our USB slot for other purposes. Is the lsusb issue a known issue or is there a solution you have come across?
I went with your suggestion and purchased the IoT WiFi Card. Unfortunately, the board is failing to start and the LED is not powering on:
The issue is that the wifi board is simply not being found/powered. This is happening on all of our Reds. It DOES work on the Green. But it is very important that it works on the red. What could be the issue?
According the wifi driver tutorial here: http://mangoh.io/wifi-expansion-card states âThe Wi-Fi LED on the Wi-Fi expansion card turns ONâ - This is not the case. There is no indication that the command worked, as the app is off and the light is not on.
Passing this, I perform the next step âwifi client scanâ and get the following result:
Hey Rauger1, is there any play on the IOT board in the amphenol connector? We had some IoT boards made and we found we werenât getting a very good connection inside of the amphenol connector. As a result I had to add nylon washers under the board to prop the IOT board up slightly when itâs screwed on⌠This would force some contact.
Iâm assuming this is likely not your problem, but it may be worth a quick test to check.
We took your suggestion and set the board to the left and right of the amphenol connector to no luck. Then we tried with a small piece of rubber underneath the board like your nylon washers and that did not help. We have a board that plugs into the amphenol which contains LEDs and small speakers that we can power from the board that does work, so the amphenol connector is not the issue.
lsusb does not work, and we donât have any way of interfacing with the USBs. The USBs we have with LEDs that light up when plugged into a traditional computer do not light up when connected to the mangoh. We checked the USB pins and they are receiving power. It seems as if the USB driver is not working.
As for the mirage board, I posted the error above. I am not quite sure what to make of it.
Here is apossible fix that was suggested to us by @davidc
"we need to add the following line to the end of the existing /etc/mdev.conf file
$DEVNAME=bus/usb/([0-9]+)/(0-9]+) 0:0 0666 =bus/usb/%1/%2
This will create the appropriate device nodes for USB devices (assuming that the device hasnât matched a previous rule) as they are plugged into the WP into /dev/bus/usb, and remove them if the device is removed.
i tried adding this rule to mdev.conf and i still get lsusb
root@swi-mdm9x15:~# lsusb
unable to initialize libusb: -99
so i pulled the usb device, and plugged it back in⌠now libusb works our code loaded⌠however we have a dilemma
the usb device is actually an iot card, this would mean having to pull / push the iot device every time⌠and its not feasible in the business model of deployed systems⌠ideas ??
Here is a bit more detail on this, again from @davidc ,
"The second problem
The above was working for devices that were âhotpluggedâ (i.e. plugged into the USB host port on the mangOH after it had booted). I still wasnât seeing the onboard devices appear in the /dev/bus/usb directory. Interestingly, once one device had appeared in the directory, lsusb was happy and could see the rest of the onboard devices. Why? No idea.
Not having device nodes for devices that appear early in the boot sequence is a known problem - itâs called âcoldpluggingâ - and essentially it means that the kernel has recognised the device/loaded module etc before the hotplug manager is alive. So to get around this, mdev has an option â-sâ (scan) that forces a manual rescan of /sys/class and re-evaluates all devices found there according to the rules in /etc/mdev.conf. It is intended that âmdev -sâ is called during the startup sequence to enumerate any devices that the kernel knowns about, but havenât been configured yet.
But I found that âmdev -sâ was NOT enumerating the USB devices - even after adding the correct rule to mdev.conf. After a lot of head scratching, debugging and looking through the mdev source code, I found that mdev was only scanning /sys/class for device families - and somewhere between kernel 3.6 and 3.18, the kernel was no longer putting usb device descriptors into /sys/class/usb - but only into /sys/bus/usb - so mdev -s could not see the âcoldpluggedâ USB devices.
I found a hint on a forum that you could âforceâ a hotplug event by echoing data to a file in /sys/bus/usb/devices/xxx/uevent, so Iâve hacked up a script that forces a âhotplugâ add event to all devices in /sys/bus/usb/devices - which then trips mdev and evaluates the correct mdev rule - which puts the correct device nodes /dev/bus/usb/
Iâm not sure just where to put the re-scan script yet - probably edit the init script that calls mdev -s
"
In the short term , see if the following script helps:
so⌠just to update everyone on this subject⌠after adding the magic udev rule to our build it seems that running i2cgpioctl enter â100â load setup defaults, enter â0â to exit does bring up the usb iot cards without having to reslot them, then simply running the pasted enableIoT2.sh
which is specific to IOT2 with notes on the others slots, might just get you there
cat enableIoT2.sh
#!/bin/sh
I2C bus switch on address 0x71
0xFC - expander #3, this has the IoT card reset lines
Expander #3 address 0x70 (after selecting expander 3 bus above)
Port A Pin I/O 2 = IoT port 2 Reset (low = reset, high = run)
Port A Pin I/O 3 = IoT port 1 Reset (low = reset, high = run)
Port A Pin I/O 4 = IoT port 0 Reset (low = reset, high = run)
NOTE:
The default programming loaded by the OS to this expander sees
port âaâ, which contains these reset lines (which are âactive lowâ)
configured in âinverted polarityâ. (Reg 0x0d = 0xFF).
This means that to remove reset, we need to write a 0 to the appropriate