Sparkfun support will be closed from 3:00PM to 4:15PM on April 27th for a company-wide townhall meeting. We will resume regular hours on the 28th.


Member Since: December 29, 2008

Country: United States

  • possibly a useless comment since this is going into the discontinued list, but don’t forget that pins 15 and 16 on the lcd control the backlight. they aren’t attached, but two of the L-header pins make it easy to attach to one of the ‘spare’ header pins.

  • 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

  • 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 <O(V.)…wq ….
    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.

  • 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;

  • 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

No public wish lists :(