Clear memory support in the GUI does not work for GT-100 on Mac OS X

[B4tm4n]

I'm trying to use the OS X dmg version. The gui starts up and then it seems to hang untill I unplug the GT-100.
I read the thread about 10.5.6 and nothing in that tread helped.
The blue light is flashing when I start the app and then goes out.

I've attached the terminal output.

If you need any more info let me know.

Thanks.

[B4tm4n (sp1derm4n)]

forgot to add after the Gt-100 is unplugged, heres the error message in terminal

USB error: libusb/darwin.c usb_bulk_transfer: device not responding
USB error: usb_bulk_read: An error occured during read (see messages above)
libusb/darwin.c usb_control_msg (device: 002-0df7-0900-00-00): 33 9 512 0 0x510a00 8 1000
USB error: libusb/darwin.c usb_control_msg(DeviceRequestTO): device not responding
Command: 930507100004030000000000000000
Failed: Unable to send data to the device: Input/output error
USB error: usb_release_interface(USBInterfaceClose): no connection to an IOService
usb_os_close: 0df7:0900
USB error: usb_os_close(USBDeviceClose): no connection to an IOService
Unable to connect to gps tracker: Unable to send data to the device: Input/output error

[Michael Hofmann (mh21)]

There is a workaround for a firmware bug in the GT-120 series, that
might affect devices without the bug (at least the position where it
hangs looks like it). Sadly there is no workaround.

I will be out of town for a week, I will post a fix after I come back.

If you want to try it yourself, go to src/igotu/commands.cpp:120 and
comment out
  connection()->send(QByteArray(), true);

[B4tm4n (sp1derm4n)]

Cheers.

I did the edit and compiled and that did the trick, now to play around with it :)
I've been waiting for nearly a year for a for something like this, now I don't
have to boot into windows anymore, Thank god (and you).

Thanks again.

[bbdam (fabiefred)]

High,
i've have the same problem than B4tm4n.
I tried his compiled application but it doesn't work.
I don't understand how to use see errors in the terminal and I don't know how to do what Michael Hofmann tells about this problem.
Indeed I use the application in the dmg file : so ther's nothing in libraries and/or in src files. Is it normal ? Did I forgot anything ?
Thanks for your help.
Thanks to Michael to have made this software.

[B4tm4n (sp1derm4n)]

Sorry my compiled version doesn't work on your system, thats probably because its dynamically linked to libraries on my Mac and I don't know how to compile a static linked version.
But I'm sure soon as Michael gets back he'll sort you out a working version.

[Michael Hofmann (mh21)]

bbdam, could you try the patched version at http://mh21.de/temp/igotu2gpx.dmg?

[bbdam (fabiefred)]

Excellent.
It works very well.
Thank you for everything. If I can help, tell me.
bbdam

[bbdam (fabiefred)]

Version 2.2.3 doesn't work : I have the retrieve info pannel for a long time but nothing happen. The gps receiver is connected because when I disconnect it I have an error message, but there's no data transfer.
Thanks for your job

[Philip Bragg (phil-mossyvale)]

I hope this information is useful:

I have two i-gotU GT-100 trackers, one is old and one is quite new. The old one will only work with the patched version from Michael Hofmann in reply #8 and the new one only works with the 0.2.3 release and does not work with the patched version.

The S/N of the old model is 10310 and it shows up as "Uknown Model" with firmware version 1.39.
The new S/N is 223341 and firmware 2.24, model GT-100/GT-200.

When I use the Windows software in vmware I've noticed that the velocity sensitive tracking option is not available on the older unit which has me wondering if it's possible to update its firmware.

[Philip Bragg (phil-mossyvale)]

I should add that the older GT-100 shows up as "Unknown model" and not what I typed above.

[Michael Hofmann (mh21)]

Thanks Philip, that's really interesting. As far as I know you can't update the firmware (there is a question on the mobilaction forums http://www.a-trip.com/forum/ somewhere), but it seems as if they use the same firmware for all of their devices. Which means that the workaround that is used for the newer models should be specific to a certain firmware version, not model number. I will try to come up with a version that makes it possible to enable the workaround directly, do you use Mac OS X or Linux?

[Philip Bragg (phil-mossyvale)]

Thanks for the reply, interesting about the common firmware. I use Mac OS X but I have some Ubuntu and FreeBSD servers around, too.

[Michael Hofmann (mh21)]

Would it be possible for you to test the release candidate of the new version (with purge support, localization, map view) at https://launchpad.net/igotu2gpx/0.3/0.2.91 to see whether identification/transfer/purge work?

[Philip Bragg (phil-mossyvale)]

Testing 0.2.91

The old 1.39 firmware model was not identified, though the correct firmware version and serial number was displayed. The "file a bug" message was displayed.
Downloading a track worked and that track showed up correctly on the map. Nice work. The purge function did not work, a message in the status area indicated that it wasn't available for this firmware version.

The newer 2.24 firmware model was not identified either, again the "file a bug" message was displayed. The initial configuration-getting process seemed to cause the unit to stop responding and igotu2gpx did not indicate that the transfer of configuration had completed. I'm going to fully charge it and try again in case there was a problem with low battery voltage. I'll give it another try later. Also, the @trip PC software on my Windows VM is updating itself with another 82M download (again!). I'm going to verify correct operation of both units with the new Windows software before I continue the tests.

[Philip Bragg (phil-mossyvale)]

I've just charged and intialised the 2.24 firmware model from Windows as the state it gets left in by Igotu2gpx 0.2.91 is such that it doesn't seem to be able to power on normally. I configured from Windows to record a track of points at 10 sec intervals with the dynamic mode set to switch to 1 sec intervals if I exceeded 10km/h then I left the GT-100 by the window for a while and then connected to my computer.

The configuration is obtained, including the number of points but the track does not download, returning error: -1.

After this has happened the GT-100 becomes mixed up and Igotu2gpx is unable to connect to it.

I repeated this with the 1.39 model and this downloaded the track correctly again. When I tried to clear its memory I received the status message: Invalid response packet: 1919ff

[Michael Hofmann (mh21)]

Ok, lets first sort out the identification issue. Can you post the numbers that are shown together with the file-a-bug messages?

Because I have no GT-100, I don't know how to implement purge on the trackers :-(. If you have time and want to help, please follow the steps at https://answers.launchpad.net/igotu2gpx/+faq/480 for both trackers. The instructions are a bit long, but they ensure that the logs contain information on how to purge devices with 0, 1, or more blocks filled with trackpoints.

For the connection problems, it is more or less the same as for bug 394302. Until I (or somebody else :-) gets around to finish the libusb 1.0 implementation, I have no idea how to fix this.

[Philip Bragg (phil-mossyvale)]

Sorry, I should have posted the whole lot, here goes:

Serial number: 10310
Firmware version: 1.39
Model: Unknown (c22013), please file a bug at http://bugs.launchpad.net/igotu2gpx/+filebug
Number of points: 25
Schedule date: 27 July 2009
Schedule date offset: 0 day(s)
Schedule table: disabled
Log interval: 15 s
Interval change: disabled
LEDs: enabled
Button: enabled
Security version: 0
Password: disabled, []

Serial number: 223341
Firmware version: 2.24
Model: Unknown (c22013), please file a bug at http://bugs.launchpad.net/igotu2gpx/+filebug
Number of points: 47
Schedule date: 7 September 2009
Schedule date offset: 0 day(s)
Schedule table: disabled
Log interval: 10 s
Interval change: above 10 km/h, use 1 s
LEDs: enabled
Button: enabled
Security version: 0
Password: disabled, []

I'll give your instructions a try later on, if I can!

[Philip Bragg (phil-mossyvale)]

I've tried to do the test perfectly but it looks like I might have created too much data on the newer logger, presumably by accidentally starting the logging. Hope it's usable. It was a real pain to capture the data because the com: port was a moving target and USB reconnections are really slow, possibly because of vmware fusion.

[bbdam (fabiefred)]

Everything works perfectly (even the data erasing).

Serial number: 13872
Firmware version: 1.39
Model: Unknown (c22013), please file a bug at http://bugs.launchpad.net/igotu2gpx/+filebug
Number of points: 0
Schedule date: 7 septembre 2009
Schedule date offset: 0 day(s)
Schedule table: disabled
Log interval: 7 s
Interval change: disabled
LEDs: enabled
Button: enabled
Security version: 0
Password: disabled, []

[bbdam (fabiefred)]

I've forgotten to say thoses results are with MAC OS 10.5.8 and igotu2gpx 0.2.91.

[Philip Bragg (phil-mossyvale)]

I have the same version of firmware with a slightly older serial number but when I click on the memory clear icon I receive a status message saying "Unable to clear memory of GPS tracker: Unknown (c22013): Unable to clear memory of this GPS tracker model. etc.
I find that when I have tried "clear memory" the tracker behaves oddly, for instance the log interval seems to switch to something like 15 seconds even though the configuration shows 1 s. It also doesn't seem to record points properly until it has been reset by the Windows software.

bbdam, your Model identification isn't working, incidentally.

[Michael Hofmann (mh21)]

Philip, thank you very much! I will take a look at it as fast as possible.

[Michael Hofmann (mh21)]

The dumps are really interesting, looks like it is the firmware version and not the model that determines the commands used for purging...

[bbdam (fabiefred)]

At first time with the default SN it didn't worked but after changing the SN in the config panel it works. I'll try it again to be sure and tell you.

[bbdam (fabiefred)]

Well. I've mistaken myself : no the data erasing doesn't work anymore. So It worked once and that's all. So I think this is normal for this version of GT-100.
(MAC OS 10.5.8 and igotu2gpx 0.2.91)

[Michael Hofmann (mh21)]

Philip,

can you tell me the version number of @trip PC you are using?

[Philip Bragg (phil-mossyvale)]

File Version on GPSPlatformExe is 2.0.908.446

[Philip Bragg (phil-mossyvale)]

I've just found the proper About box, it's Version 2.0 Build 908.446 (Aug 4 2009)

[bbdam (fabiefred)]

I use this version : 2.0 Build 908.446 (Aug 4 2009)

[Michael Hofmann (mh21)]

Philip, how is the current RC working for you? It should actually be able to purge both the old and the new GT100.

That the tracker behaves oddly after you tried to clear memory is weird, as nothing is written to the tracker in this case (it is only asked for model, serial number and firmware version), so I don't really have an explanation for that.

[Philip Bragg (phil-mossyvale)]

By coincidence I've just come back from a walk where I'd taken the V1.39 GT-100 tracker and recorded about 12k points at 1 second intervals. The second (0.2.92) RC showed the correct model, downloaded and displayed the track faultlessly and also cleared memory perfectly - I confirmed this by getting the configuration again after the purge and it showed 0 points. I'll give the V2.24 GT-100 a test in the next few days. Thanks! Incidentally, a friend is now using your software to download tracks from a GT-120 that he takes flying with him, he reports that it works well.

[Philip Bragg (phil-mossyvale)]

Unfortunately my v2.24 GT-100 does not work with 0.2.92, I get a correct model displayed but attempting to transfer the track data results in "returned error: -1" . I transferred the track using igotu2gpx 0.2.3 instead, which worked fine so I quit that and tried to clear the tracker's memory using 0.2.92. The result of clearing memory was igotu2gpx hanging with the Clearing memory... message in the status bar area, I've attached output from "sample", though I'm not sure how much help it will be.

[Michael Hofmann (mh21)]

Could you also attach the output of /Applications/igotu2gpx.app/Contents/MacOS/igotugui -v, ..../igotu2gpx -v dump or ..../igotu2gpx -v clear? I'm still puzzled that 0.2.3 works, as nothing really changed...

[Philip Bragg (phil-mossyvale)]

I have 3 versions installed. The current 0.2.92 and 0.2.3 with and without the patch. The original unpatched 0.2.3 is named igotu2gpx-new.app and the RC 0.2.92 is igotu2gpx.app. The patched 0.2.3 which I have installed as igotu2gpx-old works only with the older 1.39 firmware and I've not attached anything relating to that here.

Attached is a tarball of igotugui -v and igotu2gpx -v dump output from 0.2.3 and 0.2.92, apologies for the mac junk in there too!

[Michael Hofmann (mh21)]

Ok, I think I found at least the dump bug for the newer GT100. Could you try 0.2.94?

[Philip Bragg (phil-mossyvale)]

Great!

Downloading tracks is now working on both the 1.39.and 2.24 firmware. Purging is working on 1.39 from the GUI.

On 2.24 purge does not work from the GUI. It is returning different invalid response packet error numbers between runs. See below for my investigation into what is triggering this.

Purging works perfectly on both firmware versions from the command line using igotu2gpx -v clear assuming a cleanly connected tracker that no previous commands have run on. With 2.24 running other commands first, as the GUI does, causes problems.

If I run igotu2gpx -v info, igotu2gpx -v dump, igotu2gpx -v clear with the 2.24 I get the same behaviour as the GUI, the output ends with protocol violated (ignored): Invalid response packet:

Command: 930c001f0000000000000000000000
Result:
...snip...
Command: 930101000000000000000000000000
Protocol violated (ignored): Invalid response packet: 2c0000

Or another run ended

Command: 930101000000000000000000000000
Protocol violated (ignored): Invalid response packet: 330000

Interestingly I can run -v info and -v clear sequentially or -v dump and -v clear sequentially and clear will function correctly, it's only when I run all three in an info, dump, clear sequence that the protocol violation/invalid response packet happens. The 1.39 firmware is not affected by this and works properly with any combination of those commands.

[Michael Hofmann (mh21)]

Hmm, the Protocol violated (ignored) messages come from the switch to NMEA mode (which starts to send messages immediately), so this is kind of expected, and igotu2gpx should not fail because of them. Is there anything printed afterwards? If not, could you attach a debugger with "gdb -p <pid>", pause it with Ctrl-C and get a backtrace with "bt"?

[Philip Bragg (phil-mossyvale)]

I tried last night with the command line tools and it worked fine on the 2.24 but I found that I couldn't start the tracker recording again, so I couldn't fully reproduce the tests so I reconfigured it in Windows, recorded a new track and now it seems to work fine with 0.2.94, including purge.
I've been unable to reproduce the problem in comment #38 but I'm 100% sure I wasn't imagining it. It must be a situation where the device gets into a certain state and so far I've only seen the 2.24 unit get into that state and I don't know how it got there, possibly a result of using one of the older releases?

In other words, until I can reproduce the problem again I believe that I can say that both GT-100 firmware versions 1.39 and 2.24 work properly with 0.2.94 on Mac OS X.

[Michael Hofmann (mh21)]

I know that there are still some weird errors that occur occasionally, but let's just close this bug and open a new one if that happens.