SparkFun will be closing early at 3:30 Friday 5/27 and remain closed Monday for Memorial Day (5/30). Orders placed after 2pm MT on Friday (5/27) will process and ship out on Tuesday (5/31).
Track My Order
Frequently Asked Questions
International Shipping Info
Mon-Fri, 9am to 12pm and
1pm to 5pm U.S. Mountain Time:
Chat With Us
December 29, 2008
about 6 years ago
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.
about 7 years ago
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, sum = 0xff; i <= n; i++)
sum += bs[2 + i];
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 :(
Forgot your password?
No account? Register one!