Add some debugging to hunt down the infamous E.86

[steve8x8]

@ondrej1024 seems to have found, a couple of weeks ago, that (sometimes) there's an extra message from the CNL2.4 while a query is in flight - and apparently this one (which hasn't been decoded yet) makes the whole retrieval process get out of sync.
IMHO there's a chance that this extra message can be interpreted or ignored in ContourNextLinkMessage.java, and the code could continue receiving the actual answer for the current query.
The report is somewhat hidden here: #261 (comment) .
Adding some debugging code to the Python incarnation would certainly be easier, but any approach to get hold of what's being sent by the stick (not matching the expectations) might get us half a step further.
I'm convinced that the CNL stick has some tolerance built-in to handle timing issues, and that error 86 should not show up as often as I've seen it with a 1-GHz Android 4.4.4 tablet - the device has been around for long enough to "play" nicely with older Android devices.

[Pogman]

These are issues in the Python driver. It does not handle CNL comms precisely the same as the Android uploader.

[ondrej1024]

I'm in the process of documenting the CNL python driver to better understand how it's working. From what I've understood so far, I think it's important to add at least the clearMessage function from the Android code to the python driver in order to make it work more reliable and deal with unexpected messages from the CNL stick. I've made some progress but lack of time is my main problem.

[steve8x8]

Thanks @ondrej1024 for chiming in - my main problem is the same as yours, plus lack of CNL... I hope there's something to be learned from that code change, about which messages the CNL sends in which rare cases.