by

|   September 18, 2008 at 10:44 AM

I just got mine and tried it out with the sample software and it works as advertised!

Now I want to try my own applications, what are the serial commands I need to send to the receiver to put it in listen mode?

by

|   December  1, 2008 at 9:29 PM

Take a look at the Example VB files. You won't need VB Studio installed, a text editor will suffice. We send a couple serial HEX commands to the pod that cause it to then go into 'listening' mode. And then we parse the response for what we believe is the unique ID of each footpod. Be sure to checkout the tutorial for more details.

by

|   January  2, 2009 at 3:10 PM

just an fyi for the next experimentor.

i wrote up some c code since i dont have vb, but my transmitter thingee (ma365ll/c) seems to have a slightly different protocol which seems to work.

i send the commands as in the original vb but the responses are slightly different

79: read(8) : 8
ff 55 04 09 00 00 07 ec
91: read(8) : 8
ff 55 04 09 06 00 25 c8

the original said that the commands 1 and 2 should have the same response string (0xFF, 0x55, 0x04, 0x09, 0x00, 0x00, 0x07, 0xec).

anyway, after this i do get 34 byte strings but i think that these have 'timestamps' or something because they appear to vary each time i hit the 'button' on the sensor.

99: read(34) : 34
ff 55 1e 09 0d 0d 01 a8 69 29 30 a9 ef dc 70 fe 0d d9 0d 3d 5a 8e ff 62 b6 a4 87 3f f4 b6 8a 7d 7e aa
99: read(34) : 34
ff 55 1e 09 0d 0d 01 a8 69 29 30 aa fd 7a af 2a 94 5e d0 cc be 23 3b 18 1e 70 6c a6 61 5f 10 5f 35 94

by

|   January  2, 2009 at 3:49 PM

i forgot to add that the original vb has a comment

The last byte is a addition CRC - always 0x54 remainder?

i'm not quite hw person enough but this generates the proper checks against the messages i've seen thus far. (skipping the leading 0xff/0x55)

for(i = 0, n = bs[2], sum = 0xff; i <= n; i++)
sum += bs[2 + i];
return ~sum;

by

|   January  4, 2009 at 8:11 PM

i had some time so i soldered some leads to the 2402 on the sensor unit (back to work tomorrow :-) and hooked it up to the analyzer.

on the receiver i see

ff 55 1e 09 0d 0d 01 a8 69 29 30 af b3 c5 16 c3 .U......i)0.....
3c 4f 28 56 1c 29 0b 8f fd 77 71 20 aa 1b a0 e2 ec 34 .4

this gets sent in groups of 9/11/10 octets as

c2 bd 0d 01 a8 69 29 30 af
b3 c5 16 c3 3c 4f 28 56 1c 29 0b
8f fd 77 71 20 aa 1b a0 e2 ec

the first three nibbles are different so i've been thinking this was used to 'encode' something since the remaining #s dont seem to be monotonic up/down like a timer would be.

the last byte in the first group appears to be a sequence #. the first nibble comes as 0 when the sensor hasn't triggered in a while (and as 'a' otherwise). the last nibble is a sequence 0-f.

i guess i'll have to attach to the pic to see what the timers are doing to actually reverse something.

by

|   May 20, 2009 at 10:18 PM

neutered:
this gets sent in groups of 9/11/10 octets as

c2 bd 0d 01 a8 69 29 30 af
b3 c5 16 c3 3c 4f 28 56 1c 29 0b
8f fd 77 71 20 aa 1b a0 e2 ec

the first three nibbles are different so i've been thinking this was used to 'encode' something since the remaining #s dont seem to be monotonic up/down like a timer would be.



When I looked into this a while back, I was under the assumption that 'c2 bd' was actually the address field value in order for the nRF2401A to send the receiver. If you look at the spec sheet, the address field is automatically removed when the device is in ShockBurst mode (which I also found out to be the case). This would explain why it doesn't appear on the receiver side.

by

|   January 10, 2009 at 8:41 AM

i should have mentioned this before, but my sensor has the xmit side of the pcb covered in plastic goo. this wa a pain in the ass since i was trying to see what got transmit (to do differential against what the ipod serial side saw).

anyway, the pic side doesn't seem to have any goo (or as much) so here are teh pin connections from pic to xmit.

4 - clk
5 - cs
6 - pwr_up
7 - ce
12 - din

by

|   April 20, 2009 at 2:19 PM

Do you plan on offering a serial only version without the USB?

by

|   June  2, 2009 at 9:42 AM

I created a Perl script that reads from this adapter and I've got it working on Windows and Linux, and it shouldn't be long before it's working on the Mac if anyone is interested:

http://rtadlock.blogspot.com/2009/06/some-perl-code-for-nikeipod-serial.html

by

|   June 25, 2009 at 2:47 PM

Hopefully someone knows the answer to this.

My current project is building a carpc, I've got it all together and have a aftermarket stereo installed (DEH-P4000UB), which has a usb port w/ ipod support.

Now what I wanted to do, is use something like this to interface the carpc with the stereo, allowing the stereo to control the pc & display music information on the stereo display. I've already gotten the p-bus pinout(used by car stereo), so connecting the audio to the stereo isn't a problem. And since this device based on sending and receiving signals, I'd imaging it could be used for this as well. And advice?

Here is the P-Bus pinout, just in case...
http://stereophonik.com/gutterslide/IP-BUS_Hack/

by

|   January 12, 2010 at 8:43 AM

I am having a hard time getting anything other than the VB code to communicate with the device. I have tried the perl code from the rtadlock.blogspot.com post both on my Mac and on redhat linux but no luck yet. I ultimately would like to get this to work on my Mac but anything on Linux would work too (perl, C, python) Pretty much anything script based, but I refuse to use VB :). Nothing I send seems to get the thing in listen mode and I have to be doing something simple wrong since it works with the VB code (on Fusion on my Mac even). Any sample code would be appreciated.

Thanks in advance.

-Bill

by

|   January 29, 2010 at 1:44 PM

Can someone tell me if the footpod transmits on a fixed schedule (ie. every 10 seconds), or per step.

I'm trying to figure out why my Nike+ running data only shows pace readings at a 10-sec resolution, and whether it's the footpod, the receiver, or Nike+ website that's smoothing over the second-to-second data.

And once that's figured out, how we can hack the device to increase the frequency for the readings.