PGSPW1 issues

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Connect PGSPW1 with it's cable.
2. plug into my USB port.
3. run ./kalenji_reader
4. LIBUSB_ERROR_TIMEOUT.

What is the expected output? What do you see instead?
make gpx data for endomondo.

What version of the product are you using? On what operating system?
I've tried in ArchLinux(VMware in OSX), OSX(10.9.1). but, both case show same 
message. 

Please provide any additional information below.

Original issue reported on code.google.com by bongd...@gmail.com on 27 Dec 2013 at 6:35

[GoogleCodeExporter]

Hello,

I'm not sure if VMware fully supports emulation of USB support. If you do lsusb 
or lsusb -v in ArchLinux, do you see your device (should have ID 10c4:ea61) ?
Was a logs directory created in your output directory (/tmp/kalenji_import if 
you didn't configure anything). Is there a file in it ?

If lsusb shows your device, one thing you can try is the following:
make clean
make debug

Then try again. You should have a verbose output that you can attach to this 
issue.

Regards,
Colin

Original comment by colin.pi...@gmail.com on 27 Dec 2013 at 7:54

[GoogleCodeExporter]

Hi, Colin.

I have already tried lsusb, debug mode. More than that, I checked the PSGPW1 
routine is called with adding some debug string.
The vervose output and the source said the last line of PGSPW1 init member 
function calling readmessage with timeout error. But, with Windows XP in VMware 
and Sportstrack that PYLE recommanded for reading data from PGSPW1 do good read.

I wonder how you reveal the command to control PSGPW1.I could not find any data 
with googling. and, I'm planning to gather log with VMware's USB logging 
function in this weekend. If it failed, disassemble the sportstrack add-in will 
be next approach. I'll be very happy if you let me know easier method.

Thanks.
Kim

Original comment by bongd...@gmail.com on 28 Dec 2013 at 12:46

[GoogleCodeExporter]

Hello,

The method I use to reverse-engineer the protocol of a watch is to produce dump 
when using the regular software on Windows with this procedure: 
https://code.google.com/p/kalenji-gps-watch-reader/wiki/ProduceDumps

I didn't produce the dumps myself for the PSGPW1, I used one sent by someone 
that had this watch. Once I finished the dev, he tested it and it worked for 
him.

So I see two main potential reasons for the failure:
 - your model may not be exactly the same as his (for example different firmware release)
 - I changed something in the code since that broke it !

You can find the hexdump of the exchange with the watch I used for the reverse 
engineering in test/case3/kalenji_reader_20130930_133720.log
However, it doesn't contain the control transfers.

One thing to check if you produce a dump using Sportstrack is whether the first 
data transfer done is sending "54 5A 01 01 00 00 FF FF" to the watch as this is 
what the write_data does.

Another thing to check is the USB endpoint, to ensure it is 0x01. You can see 
it in lsusb -v in bEndPointAddress. I do not retrieve it manually, this may be 
the problem.

Regards,
Colin

Original comment by colin.pi...@gmail.com on 28 Dec 2013 at 8:58

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

First of all, this processing is very interesting to me. I WAS a software 
engineer, BUT not now. so, This kind of approach is fun for me. And, your help 
is very useful to me. Thanks.

and,
I've tried with VMWare Log functions and duct coding. Shortly, first data is 
"56 5A 01 01 00 00 FF FF". but, that was not only the reason of malfunctioning. 
I think reverse engineering is need for this case. but, It'll be cost much of 
time.

I've attached some log and modified source for test. mypgspw1.log is generate 
by VMWare and greped for USBIO. my device id is "dev=4 'usb:3'" in this log. 
other 2 file is .cc and you made. In this environment, the app run without 
error and show no result. It is question for me that size WORD is 12, 13th in 
your code. but they show 0. That's why I'm planning to disassemble the 
sportstrack's add-on binary.

I think you will be wonder why the command and returned data is different. That 
makes me wonder too. I always happy with your comments.

Happy Holidays!
Kim.

Original comment by bongd...@gmail.com on 29 Dec 2013 at 12:22

Attachments:

• my_logs.zip

[GoogleCodeExporter]

Hello,

I'm not sure of the content of mypgspw1.log. Is it a capture of Sportstrack or 
of your modified version of kalenji_reader ? I suspect it is the first one ...

It looks very different from the dump I had to do the reverse engineering. I 
added the dumps I had in svn, they are in protocol/PylePGSPW1. The txt files 
are the dumps.

In your logs, the control transfer, that occurs before the data transfer 
(including the "56 5A 01 01 00 00 FF FF" sequence) is very different too. In 
particular, we can see in one of them the string "GPS Navigator".

Maybe the data returned in the control transfer allow to determine that the 
protocol for your device is different than the one I implemented.

Did your device contain a track at the moment of the upload ?

Regards,
Colin

Original comment by colin.pi...@gmail.com on 29 Dec 2013 at 6:56

[GoogleCodeExporter]

Hello,

Right, the log is capture of Sportstrack 3.1 with PGSPW1 add-on. and, there is 
just one track for upload.

I'm going to test multi-track data today. See you later.

Regard,
Kim 

Original comment by bongd...@gmail.com on 30 Dec 2013 at 12:07

[GoogleCodeExporter]

Oops. I missed mentioning, "GPS Navigator"  is Windows's driver which PGSPW1 
provide.

Original comment by bongd...@gmail.com on 30 Dec 2013 at 12:38

[GoogleCodeExporter]

Sorry again. "GPS Navigator" is device name of my PGSPW1 watch. It show same 
name in OSX.

Original comment by bongd...@gmail.com on 30 Dec 2013 at 11:52

[GoogleCodeExporter]

Hello Colin.

I've fixed communication problem. The data from watch was not match original 
source. so, I tried case by case and made some fix. Modified source is attached.
The size filed position is moved. and, the data chunk is 4096 bytes plus 8 
bytes. Even more, Reading next chunk needs additional read command sending to 
device.
(I've tested with python using pyusb. after that modified PylePGSPW1.cc)

But, After examine the generated gpx file, I noticed that the alititude value 
looks not valid. Could you help me understand the method of PGSPW1's 8 bytes 
GPS data?

Regard,
Kim

Original comment by bongd...@gmail.com on 1 Jan 2014 at 1:01

Attachments:

• PylePGSPW1.cc

[GoogleCodeExporter]

Modified source was missed. Loading again.

Original comment by bongd...@gmail.com on 1 Jan 2014 at 11:53

Attachments:

• PylePGSPW1.cc

[GoogleCodeExporter]

Hello Colin.

I'm sorry, I've been busy with own job.
Today, I've check the PGSPW1's Sportstrack3 addon dll file. And, fixed 
something. Checking negative degree , Considering timezone, etc.

I'm going to check multiple session handling.

Thanks.
Kim 

Original comment by bongd...@gmail.com on 16 Jan 2014 at 9:09

Attachments:

• PylePGSPW1.cc

[GoogleCodeExporter]

Hello,

sorry for not answering for quite some time, I've been quite busy these times 
...

Your work is very interesting and I'd like to integrate it but it conflicts 
with the existing support of Pyle PGSPW1. It may be different versions of the 
firmware, or newer/older version of the watch. 

The productId / vendorId are obviously the same as you didn't have to change 
it, but there may be a difference in the answer of the watch to the init 
sequence. There is the same kind of thing for the OnMove / Keymaze 700 Trail. 
You can see how I defined a variable named "type" that I set depending on the 
first exchanges outcome.

The USB communication used for the previous implementation is available in SVN 
in protocol/PylePGSPW1/*.txt. You can see that the answer to the control 
transfer are always buffers full of 0. If this is not the case for your watch, 
then you can use it as a way to determine which protocol to use.

Are there still parts of the protocol you don't get (e.g: elevation) ? If yes, 
can you attach an example of a GPX imported with Sportstrack and the 
corresponding USB capture so that I can have a look ?

Regards,
Colin

Original comment by colin.pi...@gmail.com on 23 Jan 2014 at 7:14

[GoogleCodeExporter]

Hi, 

Glad to see you again. :)

After looking the log you left in protocol/PylePGSPW1, I found there are some 
different data. But, I can't assume which is meaning firmware version. I've 
attached SportsTrack's log captured in VMWare. It shows only initialization 
part, but there is no missing line between top and bottom. I hope you can find 
any clue.

Thanks,
Kim

Original comment by bongd...@gmail.com on 24 Jan 2014 at 8:20

Attachments:

• usb_log_part.txt