Open akumpu opened 4 years ago
Thanks. Hopefully this is of use to some with this issue.
I had a look at the changes for possible inclusion but due to potential issues with security and variability across android versions and even products from the same manufacture and no real way to do broad tests, I think it will be up to the user to apply and build this patch for their device.
This doesn't explain why the same issue can be seen on a 7-year old tablet, running Android 4.4.4, constantly connected to wall power (it's got a separate charger socket - which was the main reason it's got a new job despite its age) and in devel settings there's "screen always on when on power". E86, nevertheless. Some random message sent by the CNL seems to get in the way of normal query-read handshakes, and I suspect that ignoring that message (that doesn't start with the expected byte) and reading again might also address the issue. There's python code that shows the same behaviour, and perhaps could more easily be tweaked to present the extra data - and get an idea of how to handle or ignore them. @ondrej1024 got closer to it - I'm out right now because I don't have access to the whole setup (which was given to a friend).
@steve8x8 fyi the patch here addresses a particular device brand and their android customizations with manifest permissions.
Android 4.4.4 is really old and has it's own set of issues. While it's supported I would recommend using android versions from 6 on for solid reliability. Android OS will regularly kill apps and restart them without notification and when this happens while a CNL read is in progress it will E86. The android uploader has mitigations for this but with the older os it is much less reliable.
I was happy too early. Next issue occured: 12-11 21:23:07.871 949 1181 I UsbAlsaManager: USB Audio Device Removed: null 12-11 21:23:07.878 949 1036 I UsbDeviceManager: HOST_STATE connected:false 12-11 21:23:07.880 1523 1761 I ash : android send broadcast:android.hardware.usb.action.USB_DEVICE_DETACHED notify package: info.nightscout.android, pid: 2983 12-11 21:23:07.880 1523 1761 I ash : info.nightscout.android { hibernation duration=204713 UptimeDuration=204714 } transition to: doze reason:bc_notify_android.hardware.usb.action.USB_DEVICE_DETACHED 12-11 21:23:07.932 2983 2983 D MasterService: receiver: android.hardware.usb.action.USB_DEVICE_DETACHED 12-11 21:23:07.944 1523 1761 I ash : android send broadcast:android.hardware.usb.action.USB_DEVICE_DETACHED notify package: com.android.gallery3d, pid: 5206 12-11 21:23:07.945 1523 1761 I ash : com.android.gallery3d { hibernation duration=730855 UptimeDuration=730856 } transition to: doze reason:bc_notify_android.hardware.usb.action.USB_DEVICE_DETACHED 12-11 21:23:07.989 12838 13637 E MedtronicCnlService: java.io.IOException: Error writing to usb endpoint 12-11 21:23:07.989 12838 13637 E MedtronicCnlService: at info.nightscout.android.USB.UsbHidDriver.write(UsbHidDriver.java:90) 12-11 21:23:08.011 1193 1193 D StatusBar: onNotificationPosted: StatusBarNotification(pkg=info.nightscout.android user=UserHandle{0} id=1 tag=null key=0|info.nightscout.android|1|null|10107: Notification(channel=error pri=2 contentView=null vibrate=null sound=null tick defaults=0x0 flags=0x0 color=0x00000000 vis=PRIVATE)) 12-11 21:23:08.011 1193 1193 D StatusBar: addNotification key=0|info.nightscout.android|1|null|10107 12-11 21:23:08.038 1193 1193 D StatusBar: No peeking: not in use: 0|info.nightscout.android|1|null|10107 12-11 21:23:08.052 12838 13637 D UsbHidDriver: Releasing HID interface. 12-11 21:23:08.053 12838 13637 W UsbHidDriver: releaseInterface returned false 12-11 21:23:08.053 12838 13637 D UsbDeviceConnectionJNI: close Any hints available to share :)
it seems that USB connection fails randomly, now-and-then. But it still works at next poll. So you can forget the previous message. Normal behaviour, perhaps?
The usb device should never be issuing a detached broadcast unless it has actually become detached or the CNL self cuts the usb due to a E86 / E81 error (at around 10 mins after). Errors while in MedtronicCnlService would indicate this has happened during a poll. Are you absolutely sure the wired connection is solid?
It should be solid. CNL was "stationary" all the time on the table, and no one touched it. And USB connectors are tight ones.. Maybe I should try an another OTG cable?
Sounds like it should be good if it's just sitting there. Keep tracking the logs for a while and maybe there is some underlying trend that will give a clue.
My daughter's CNL is several years old, so I don't know what kind of hits it got in those years :) So it may CNL issue as well, bad connector or even connector is in loose from PCB side. I'm planning to buy an another CNL for nightscout usage only. I'll keep tracking it from the logs.. And I'll use IPA to clean-up the connectors etc..
Looks nice now. after using IPA the connection is much more stable now. But I'll follow it.
Just a thought... maybe get a phone that is known to work well for this and be done with it. I've been running for nearly 4 years with Sony Xperia Z3 Compact going 24/7 and it has a separate charge connector to the usb. Also use a stripped down CNL taped to back of phone and with this low profile it runs very solid for months on end.
Nice idea to strip it down. Thanks for the tip. Sony sounds quite reliable HW, perhaps I bomb my Huawei and switch to Sony. It would be nice, if we could collect a list from working HW + SW envs with Medtronic.
This seem to be Huawei specific issue. I set display to sleep after 30min of inactivity. And it started to work smoothly without any E86 or USB disconnection. Next I changed display to sleep after 30s of inactivity. And then I got a bunch of errors E86 + USB errors. So lessons learned: Never buy anything from Huawei :( Perhaps it is time to switch Huawei to Galaxy J5. But first I have to fix its broken display to able to try it. Similar kind of fights is ongoing in here: https://github.com/AltBeacon/android-beacon-library/issues/778
Yesterday I got a new display to J5, and the uploader was on overnight without any issues. So my problem is now solved. Perhaps you should mentioned somewhere: "Not recommended for use with vanilla Huawei devices, because of aggressive battery strategy" or similar..
@akumpu first I was wondering why you'd want to soak the stick in India Pale Ale - then became aware of yet another (also alcoholic!) meaning of that "IPA" abbreviation ;) Will try thoroughly cleaning the connector, although after so many reconnects, it should be shiny as hell...
Also I'll check whether I can find any images of the CNL inside (FCC site?) - and possibly how to reversibly disassemble it. The image by @Pogman doesn't show anything connected to the internal antenna socket, does it?
@steve8x8 to open the cnl use a thin edged tool to work the shell open starting at the usb end.
Hello,
Device: Huawei Mate 20 lite Android: 8.1
from my experience in the last 3 days:
After three days of usage i had no "E86"- Error.
HI Akumpu & aendes, Am facing the same CNL E86 errors on a Huawei 20 lite. Newbie question, how do I go about applying said patch to the Uploader? Thanks all for your great work!
@aendes: About your comment:"set "screen/Display off" to highest value which is not "never" (15 Minutes)" Does it leave screen on "forever".. Then this is no option for me, because then I'll lose mobility. I.e the battery will drain quite fast
@blad974 : You need to install Android Studio, and download the source, change the file and compile the app. After that you can sideload the app.
@pazaan: Maybe you could release a version with these power settings?
@akumpu: I did not set it to never, my settings now are down to 5 Minutes and i have no issues over days.
With these settings i had no E86- Error since days
Thanks ever so much. Shall do and test. Cheers.
FYI. setting doesnt work with Honor7s.
@pazaan: Maybe you could release a version with these power settings?
@aendes - see https://github.com/pazaan/600SeriesAndroidUploader/issues/262#issuecomment-564552417. We're very unlikely to make bespoke builds for vendor customisations to Android.
Your Environment
Brief Explanation of Issue
Huawei's ash process hibernates uploader, i.e. its ignores acquired wakelocks
Uploader Error Code
CNL gives E86 and then USB connection is lost
Steps to Reproduce (for bugs)
The issue is permanent, and is visible after 5-10 mins from the start when CNL is connected to USB bus
The attached patch to AndroidManifest.xml seems to fix the issue huawei.patch.gz
Don't know if it is a valid workaround/fix
Severity Score
5