Doodle Labs mini-OEM Helix Mesh Rider Radio M1-M6 Hex Band not configuring

shawn_ricardo

Hello,

My platform is the Starling 2 and I am attempting to integrate the Doodle Labs mini-OEM 2023 Update.

I am supplying 5V at 3.1A via the 6 PIN JST GH connector and have a JSG GH to USB Type A cable, following this pinout

The setup works on a windows laptop:

miniOEM JST Port 1 connected via USB Type A to a windows laptop
configuration of windows laptop via doodle instructions
able to ping the miniOEM and a wearable Mesh Rider Radio ( the wearable is another separate physical device on the wireless network)

When I connect the same USB Type A port to the starlings usb port via the wifi adapter card (not the usb c port; where the Alfa network adapter is), a few things occur:

the device is not seen under lsusb
if the device is seen, voxl-configure-modem steps do not produce a valid eth0 port
if the eth0 port is created, the default ip address of 10.233.0.100 is not active

I'm unable to find support for this model of doodle labs radio. I believe the driver is included in the kernel (the doodle shows up as a LAN9500A USB 2.0 to Ethernet 10/100 Adapter), but I'm not certain.

Hoping a dev could point me in the right troubleshooting direction, thanks!

shawn_ricardo

Hello,

There was a brief moment today when the device was working. Steps were...

Connect doodle labs radio to Starling USB port (the adapter)
Connect Starling to PC via USB-C
Power the doodle labs radio
Power the Starling 2

Upon entering shell, was able to see the default doodle labs ip address 10.223.0.100 on bash printout and was able to ping the doodle labs miniOEM radio and the wearable mesh rider radio

I configured QGC to point to the updated IP address and then started voxl-px4-hitl.

At this point, I realized QGC did not connect and upon further investigation found that the device was no longer seen via lsusb.

Is there any idea why the device would no longer be seen randomly or how I could troubleshoot this step?

shawn_ricardo

Per this post, I've tried the M0151 on another VOXL2 board w/ the USB to JST-GH cable. The doodle radio was still not showing up under lsusb

@Moderator , do you have any additional insight into what may be occurring here?

shawn_ricardo

Hi @Eric-Katzfey , would you happen provide further assistance on this issue?

My setup in summary:

120VAC to 5VDC 3.1A Type A Female adapter --> Type A male cable to 6 pin JST GH where 3 wires are spliced from the hot wire into pins 1/2/3 on port 4 and 3 wires are spliced from the ground into pins 4/5/6
For connection to VOXL2, I have a JST GH 4 pin where pin1 is disconnected, pin 2 = D-, pin3 = D+, and pin4 = gnd. These connect to the corresponding wires for a USB 2.0 Type A Male to pigtails
The USB Type A Male from (2) is plugged into the Starling 2 USB port (where the ALFA adapter usually is) and dmesg -w continues to show error -71
The USB Type A Male from (2) is plugged into the USB adapter that comes with VOXL 2 USB3.0 / UART Expansion Adapter and dmesg -w continues to show -71
- Not shown in the image (I have another separate VOXL2 board)

Here is an image of the setup:

This setup works repeatedly on Windows 11 PC. That is, the PC can ping the miniOEM doodle radio as well as a Wearable radio located several meters away.

Any next steps would be great, thanks!

Vinny

Hi @shawn_ricardo
You are lucky that works on a windows PC. The USB cabling is in need of improving to work reliably. Please shorten the USB data lines, and ideally keep them twisted pair.
Our system does not buffer our USB lines on a Starling but I bet many full sized PC's do.
Also, we do not know the GND connections on doodle for power vs USB, but I bet we have a ground loop here.
The power supply for the drone and radio need to have the same ground at some point, and I cannot tell if that is done here.
Third, there is no way to confirm if the wall adapter is indeed providing 5V @ 3A since there is no USB bus to negotiate that current. Without any negotiation of a USB Host/Charger and a peripheral, you are most likely only getting 500mA.
The better test is to use a power module, like our V3 https://www.modalai.com/collections/cables-1/products/mdk-m0041-1?variant=46923853955376, and use that to create the 5V for Doodle using the same source that is powering your Starling. You'll eventually be trying to fly this right? Unplug from the wall adapter and try it the way you intend and I have a feeling things will be better.

Vinny

Hi @shawn_ricardo
I was thinking a bit more about this and I'm even more confident it's most likely a ground loop issue. When you use a PC, it is plugged into the same wall-ground connection as the 5V power supply, so there is no ground loop between the PC and the Doodle (they share the same common ground from your house/lab/office). However, with our drones, that GND connection is isolated due to the battery. If you are using a bench power supply instead of a battery, then the ground has a (typically) isolated path to push through since most benchtop supplies are isolated from wall power to the load output for replacing batteries (i.e.: you need to NOT have the negative terminal shorted to Earth GND for battery powered electronics replacement supplies).
So, I'm even more confident you should try a power module fed by whatever supply is powering your Starling.
The other smaller thing I thought of could be related is turn-on timing. Some devices, Boson in particular (though I have not heard this with Doodle) are very picky with power up timing and will not enumerate if VBUS is too fast to rise, or if some devices turn on before their host. I'm curious if the turn on timing between the Doodle and the PC is less of a concern (likely the USB port is going into a hub internal to your PC), whereas with us on a Starling, it's direct to the Snapdragon (no Hub) and the timing of it may be more sensitive. The way to check for this is to experiment with turning on the doodle power at various stages (before Starling, after Starling, after Starling for a long wait, and even "with" Starling) and see if that makes a difference. If that changes things, then we have a timing issue that may be addressed by a SW enabled power supply based on when the enumeration is successful....
But, I'd still go with the power module as a priority, since that is what is needed anyway for flight. Might as well test as you will fly.
Keep us posted.
Thanks!

Vinny

@shawn_ricardo And one more point I wanted to make about the cable...
this is our solution which we know works well:
https://docs.modalai.com/cable-datasheets/#mcbl-00085
However, our only design that can power a doodle at full specs is M0130: https://www.modalai.com/collections/expansion-board/products/m0130-3?variant=48186331693360
and under that combination of HW and cable, we see no issues, so I'm not inclined to think there are any SW issues going on here.

shawn_ricardo

@Vinny

Really appreciate the in-depth response and thoughtfulness, your intuition was correct

I tried to reproduce the setup from the windows PC

Wall power supply to Starling 2
(Same mains outlet) 12VAC to 5VDC to doodle labs radio
Twisted D-/+ cables

Upon USB connection, I'm able to see the following on dmesg -w:

[ 1156.696173] usb 1-1: new high-speed USB device number 6 using xhci-hcd
[ 1156.832876] usb 1-1: New USB device found, idVendor=0424, idProduct=9e00, bcdDevice= 3.00
[ 1156.832886] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1156.848011] smsc95xx v1.0.6
[ 1156.912009] smsc95xx 1-1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.0.auto-1, smsc95xx USB 2.0 Ethernet, 00:30:1a:3a:eb:c8
[ 1156.981572] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1156.989474] QTI:Netlink Query to Kernel Success
[ 1158.456775] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1158.464411] QTI:LINK_UP message posted
[ 1158.465167] QTI:Processing LINK_UP
[ 1158.465606] smsc95xx 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1
[ 1158.472660] QTI:Enable mobileap
[ 1158.479629] QCMAP:Enable mobileap
[ 1158.598399] QCMAP:Enable mobileap done
[ 1158.602320] QTI:Setup TETHERED link
[ 1158.676632] QTI:LINK_UP Processed

and am able to stream data via voxl portal for a few seconds. Afterwards, the USB connection goes into a repeated disconnect/reconnect cycle.

Moving forward for next testing (and obviously final configuration), I'll power both from the same source (w/ a BEC), shorten the cables, and be sure to twist the data lines (similar to mcbl-0085)