USB OTG and Dexcom G4 Receivers

[jaylagorio]

I've been using this board off and on for a month or so and have previously been able to communicate with the G4 receiver over USB using a USB OTG cable and external USB power source. Today I have been unable to communicate with the device. My quick test involves running openaps use cgm iter_glucose 1

The G4 receiver shows that it's plugged in with the icon in the corner and the USB OTG cable is connected to the OTG port on the Explorer board. lsusb returns error -99 and /dev/ttyACM0 doesn't show up on the Edison like it does on a Pi 2.

@scottleibrand Mentioned a hardware issue being looked into - unless there is something else I can check to see why the receiver isn't being recognized?

[mogar]

@jaylagorio We have identified a bug in the current hardware version that can make USB OTG function sporadically. My only suggestion for you now is to try unplugging your USB OTG device, rebooting, and then plugging back in. That may fix it. We're working on a better fix for this.

If you'd like, there's a quick hardware modification that should make this more stable. It requires cutting a single trace. Contact us by email if you want help with that.

[ghost]

I would like info on cutting the trace.

Glen Robinson (@glenrob1940)

On 1/23/17 8:37 PM, Morgan Redfield wrote:

@jaylagorio https://github.com/jaylagorio We have identified a bug in the current hardware version that can make USB OTG function sporadically. My only suggestion for you now is to try unplugging your USB OTG device, rebooting, and then plugging back in. That may fix it. We're working on a better fix for this.

If you'd like, there's a quick hardware modification that should make this more stable. It requires cutting a single trace. Contact us by email if you want help with that.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/issues/14#issuecomment-274692701, or mute the thread https://github.com/notifications/unsubscribe-auth/AWpWcdQp3KqlXWxyMACxIqzHaS5dke_4ks5rVXHygaJpZM4LqNMk.

[Kdisimone]

Yes please +1

[PieterGit]

Please give me more information on the suggested hardware fix @pietergit

[scottleibrand]

@mogar's comment above asked you to email him, so you might want to do that...

[jaylagorio]

Yeah, I emailed sales@enhancedradio.com

[mogar]

Here are the instructions for the trace-cut: https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/wiki#usb-otg-flakiness

This could be a difficult cut to make if you don't have a microscope and experience with PCBs. Anyone who would like to ship their board back to us for us to do it is welcome to. Just email us beforehand at sales@enhancedradio.com

[scottleibrand]

@mogar just confirmed that this is indeed a hardware issue. (Specifically, U8 needs to be a MIC2039A instead of a MIC2039B.) Future Explorer boards will be produced using that part, and should be much more reliable for OTG use. The trace-cut described above should work well for any existing boards. The only side effect of that cut would be that, because it bridges the 5V power between the two microUSB ports, plugging two different power supplies into the same Edison at the same time should be avoided if possible. If it does occur, one of the devices (particularly if it's a computer) may disable its USB port temporarily due to the unexpected voltage. It shouldn't damage anything, though, and plugging both microUSB ports into the same device (i.e. for flashing) should work fine.

I have been testing a board with the trace-cut, and have had much more reliable OTG than on other boards. I have not noticed any issues when plugging in wall power to one microUSB port and a USB battery to the other (briefly, while swapping power sources). I have not plugged into my computer's USB port while powering the other microUSB port, and do not intend to do so.

[scottleibrand]

For those of you who've done the trace cut for USB OTG reliability: have any of you tried re-flashing the Edison since doing so? I'm not able to see the Edison over the trace-cut Explorer board's OTG port, and therefore can't get it to re-flash. Wondering if that's an inevitable side-effect of the trace cut, or something specific to my setup. If you'd like to test without re-flashing, you can plug the board in to your Mac using the OTG port, and then reboot or unplug it, and you should get the Disk Not Ejected Properly warning if OTG is working. If you've done the trace cut, can you give that a try?

[jaylagorio]

I've done the trace cut and now have a successful loop! However, Morgan explained the following about how/why this works: "The wrong part was used for the OTG power switch, so when you plug in OTG it turns power off and not on. Straightforward to fix, but a bit tough to implement a fix for everyone's current board. You could either replace the part or do the trace cut, and either would work."

This leads me to believe that we've irreversibly made it so you can't flash it since we've reversed the way the power works by cutting the trace. At @scottleibrand's suggestion I did this:

1. Edison/Explorer with Lipo already powered on and logged into SSH, connecting OTG port to PC USB
2. shutdown -r now over SSH
3. Absolutely no movement of any kind in Device Management, not even a quick change

So unless you have a second board you can use to flash the Edison you might not want to do this in case you have to reflash.

[mogar]

Thanks for the thorough reports, @jaylagorio and @scottleibrand. You are both correct that the trace cut causes the Edison to always be in OTG mode, and never be in peripheral mode. That means that the Explorer can't be used to flash the Edison after the trace cut is made.

One further note is that there's also a design flaw on the PCB for these boards. Just replacing the incorrect part won't fix everything. Right now it's a choice between OTG always, or flakey behavior where it only sometimes works with OTG.

I have a new set of boards on order that will have this problem fixed. Those should come in by the end of February.

[jaylagorio]

I think we've thoroughly documented the issue, the workaround (trace cut), the workaround side effects, the solution (design fix), and the expected time to market for the solution. If everyone else is happy I can close this. Anyone agree?

[Kdisimone]

agree