Unrecorded points = crash

[haama]

I've got a Highgear XT7 watch that works just fine with this software. However, on one of my trips it missed a few points in the middle, so the "fetching" number of points was higher than the actual number of points. Changing the loop test around 175 in download.py fixed this.

I still have the points file if you'd like to see it. I might still have the debug file? (Not entirely sure where it outputs to.) The actual crash error was something like "Non-BCD argument C in AC", unpackBCD called from pack_coord called from lat = pack_coord(b"\x00" + lat0, b'S'). Also, using Windows 2000 and cxfreeze as per the instructions.

[mlt]

I've got a Highgear XT7 watch that works just fine with this software

Thanks for the feedback! I'll update compatible hardware list once it works flawlessly.

Not entirely sure where it outputs to

It saves a debug file named schwinn810.bin into your TEMP, which is likely C:\Documents and Settings\user\Local Settings\Temp\ or alike on Windows.

on one of my trips it missed a few points in the middle

Is it reproducible or is it just one single track that causes troubles? It would be nice if you could create a small file with just a few points that has an issue. Otherwise, your existing schwinn810.bin should be fine if it is still there:-) Remember to use --debug when calling download.py to produce that.

Also, using Windows 2000 and cxfreeze as per the instructions

It is hard to call those instructions just a general guidance :-) I'd recommend to use the code from git as is without compiling it into EXE. From what I understand you've already set all the things up, so it should be one step less for you to do.

I did not reflect that in main REAME, that it should work with Python 2.7 (preferred because various uploaders are planned and there is no OAUTH for python 3.x :( ) as well as with 3.2 .

The actual crash error was something like "Non-BCD argument C in AC"

I had something similar when I used udev triggered download on GNU/Linux. I thought it was caused by an attempt to extract data too fast before watch switches into charging mode etc. Some delay looks like helps a bit. Also I never got similar error when I tried to download in a regular way same tracks that used to fail when download was triggered by udev.

Changing the loop test around 175 in download.py

I'm not sure what you are referring to as it points to a dump. Perhaps you've meant line 171. An alternative would be to do something similar as with waypoints (as of now which is not quite right especially since I know where # of waypoints is reported). Each track point must have 0xFA as the last byte as described in data format wiki. However I really don't want to do that because it looks like it might break things in the future for Mio Quest pretty badly. From some preliminary data when I was playing with Mio software on Windows, it reads smaller chunks and may have no trailing bytes with point # and signature (0xFA).

missed a few points in the middle

This is really awkward. As you might seen in the code there is only one sequence that makes watch to dump all its data at once. I wonder how something can be missing in the middle. How did you determine that it was from the middle? Time stamps? Is it possible that there was no GPS reception? I still don't know what happens in this case... I guess it just does not record point, but the count should be correct.

Also would you mind telling me what your watch reports according to SET->PROD.ID ? I would like to be able to distinguish brands/models/firmware versions from that.

[mlt]

Did you solve your problem? Or did you quit? I'm closing it. Reopen if needed.