Readout freezes randomly (how to debug?)

[steve8x8]

I own a next-one meter, and have modified contour.h to use its id (7800).

The readout stops at random places, and if I ^C the process and restart it, the reading resumes - leaving a gap of a single record. This may happen multiple times until the capacity of 800 records is reached, and again, after the L|1||N record, the program doesn't finish.

I've checked the forks, and @cabreu's seems to incorporate all known models, but
otherwise didn't mae any changes to the parser.

I presume that some sync bit gets lost at a random frequency, and resyncing isn't possible (yet). That the code continues at the point where it stopped is giving me hope that this could be fixed rather easily - although there seems to be no way to get debugging information from the program now.

Any suggestions?

[der-b]

The last time i looked in the code is a long time ago. Therefore i have no idea what the problem could be.

You should start with enabling debug information while compiling with something like this:

./configure CFLAGS="-g -O0"
make

Afterwards try to find out, where the program hangs. Use GDB for it:

gdb ./src/contour-next-usb/contour_next

And than type "run". If the program hangs, hit [crtl]+C and type "bt" for backtrace. This should tell you, where the program hangs.

My personal guess would be, that it hangs here: https://github.com/der-b/contour-next/blob/master/src/contour-next-usb/contour.c#L235

Maybe the error happens due to the incomplete implementation of ASTM 1394-91. If i'm right, it would be nice, if you could inspect the usb packages. You can use WireShark for it. You need to load the kernal module "usbmon" to be able to sniff usb packages.

Kind regards.

[steve8x8]

The problem happens in absolutely random places and is hard to reproduce. If transmission stops, one ^C's the running process and just restarts it, exactly one record is lost (i.e., it's already been sent by the meter but didn't arrive in proper fashion). Of course this may happen several times...
Yesterday, I performed three runs, and had a complete set of records (800 glucose readings) in the third one; merging the first two produced the same result (with the exception of the header line which contains a timestamp and therefore must be different).
This doesn't smell of an incomplete implementation but rather of transmission errors or desynchronisation or something interfering (although there's nothing else on the USB bus).
I'd like to track this down (possibly using a completely different hardware - and perhaps software - platform), but it's low priority now.