How does the uploader recover a blocked CNL USB stick

[ondrej1024]

This is not a bug report but rather a question.

When experimenting with the CNL Python driver, I sometimes end up with the CNL USB stick completely hanging which means it is not not responding anymore to any request.

How do you deal with this situation in the Android uploader? Is there a way to automatically recover without unplugging the stick?

Thanks, Ondrej

[Pogman]

Oh boy... you don't want to know how long I've spend diagnosing and dealing with this particular issue. It got a tad obsessive... the CNL is temperamental and any hiccup will cause a E86 error that can only be reset by pulling power on the usb bus. This can't be done on Android or at least not for vanilla un-rooted devices and it requires a user to unplug / plug the CNL to get going again.

You may have option with rPi devices to shut power to the usb to reset. If you can't do that have a look at this code as it handles most of the important issues that catch and reduce the potential for glitches that can error the CNL. This is extensively stress tested and can run continuously, most CNL errors are now a result of a poor wobbly usb connection.

https://github.com/pazaan/600SeriesAndroidUploader/blob/master/app/src/main/java/info/nightscout/android/medtronic/message/ContourNextLinkMessage.java

[ondrej1024]

Thanks for the pointer.

On the RPi3 I act on the USB event when the CNL is removed (which occurs when the stick locks up) and run this script to power down and up the USB port.

Unfortunately this cannot be done on the RPiZero which has the 5V hard wired to the USB port. So I am facing the same problem as on a smart phone. I might need to port your enhancements of the protocol handler to the Python driver to make this more reliable on the RPiZero 😟

[ondrej1024]

I just tried the CNL Python driver on the RPi-Zero. While the driver is running quite reliably on an RPi3 (no hangups for a day or so) on the RPi-Zero I get only 1 good reading from the CNL. At the second attempt I get this error:

2019-11-23 19:20:52,206 WARNING [read_minimed_next24] Timeout waiting for message
2019-11-23 19:20:52,253 ERROR [read_minimed_next24]  ### checkControlMessage: Expected to get an 0x5 control character, got message with length 293 and control char 0x125

At the next reading I get:

2019-11-23 19:20:57,306 ERROR [read_minimed_next24] readDeviceInfo: Expected to get an ASTM message, but got 05 instead

and the CNL hangs up compeltely, which means it even disappears from the USB bus.

Any idea why the same driver would perform so much worse on the RPi-Zero?

[Pogman]

There may be an issue with the first read that looked successful. It's vital that the CNL be opened and closed in a controlled way or the next read can error. Check timing too, the CNL can send responses if things take too long and these need to be cleared from the input stream before any request sent.

[steve8x8]

Someone might invent a USB-controlled USB switch... (think smart socket, but for USB).
I'm sure there are many other applications for this - and actually it might yet exist somewhere?

[steve8x8]

Indeed there's such a device: https://www.yepkit.com/product/300115/YKUSHXS ...

[ondrej1024]

Well, let's hope we can fix this in the CNL driver software so there is no need for additional HW.

[steve8x8]

@ondrej1024, re your report from Nov 24: apparently the next read attempt returns the 0x5 value the previous one was waiting for - would it help to see what's in the "extra data" that were provided before (the one with length 293)?

[ondrej1024]

Yes, you are right. I didn't notice that. I need to debug this some more.

Apparently the current Python driver does not have all the optimizations that went into the Android version which was developed later. So I need some time to do the backport. But first I want to get the Nightscout upload support out.

[steve8x8]

Perhaps, in checkControlMessage(), if the control character doesn't match

• dump the whole record (may give a clue what's going on)
• instead of raising an error early, try to read yet another record (with a timeout exception handler in place)

Possibly it's the second sendMessage() that confuses the stick - if it still has some data ready from the previous one?

[ondrej1024]

@steve8x8 : I think it would be perfect if you could do a bit of debugging regarding this issue. I am really tied up at the moment and don't have time to dedicate to this. Get yourself a RPi-Zero-W, it's just 10€ 😎

[steve8x8]

RPi0: I got two of them - but am lacking a CNL :'( that's why I'm limited to guesses

[akumpu]

Hi and FYI
I have already discussed about this one with steve8x8 in gitter.
This issue is permanent in my(actually my daughter's) setup.
I'll get E86 within ten or fifteen minutes from start, i.e. from the point when I have plugged CNL to android.
I tried to reproduce it with python driver, with Linux laptop.
But unfortunately the issue is not easy to reproduce with it. I have run several hundred read rounds without problems.

[steve8x8]

@akumpu and others: can you provide a logcat of the android device when e86 has happened? I'm afraid though this wouldn't help much - as long as we don't know what the contents of the unexpected response from the CNL are. Back to printf debugging?

[akumpu]

@steve8x8 : I have used CNL + uploader several months now without any issues (with my Galaxy J5).
But I'll follow it and I'll take the logs if possible

[ondrej1024]

This issue is solved. After modifying the Python code I have it running on a battery powered RPi-Zero and downloading the pumps status information successfully for 24h without getting stuck.

Here is the modified Python CNL2.4 driver lib:
https://github.com/ondrej1024/ddguard/blob/comms_robustness_backport/cnl24driverlib.py