Its a 4-sensor parking assist device, I would like to hack the sensor data from the module. It is a central module, 4 sensors and an LED display. 4 sensors with two wires is somehow processed to a "data" wire that connects to a LED display to the module. I have researched the project so far by finding 2 other blog's on the internet for the same setup, however - the DATA waveform on THEIR modules output 24 data bits, and appear to follow a standard generic binary decoding method.
(I've attached a scope capture from the data wire).
The two large pulses in the begin of the transmission appear to be constant, however the 21 pulses of data that follow appear to change when a sensor is moved. Does anyone have experience decrypting this information and can give some advice ?
The two large pulses are the sync/start pulses. The rest almost certainly encode a binary string of 1s or 0s depending on the pulse spacing.
To decode this you need to make a table of the pulse pattern observed with the scope, as a function of the distance of the sensors to a wall. If you do this for a number of known distances, it should be relatively easy to figure out how the pulse train encodes the distance. It is possible that the bits will be sent in the reverse order (low order bits first) so a binary number may appear backwards.
Google "decode remote weather sensors" or the like, to see how this has been done for other types of sensors.
Yes I took your advice and made a program to log the data from the pulse pattern to the serial port. Unfortunately it appears to output only ONE number for all four sensors, whichever ONE sensor is closer. Oh well, that's what I get when I cheap-out and buy the least most expensive sensor that looks just like the one in the blog.
I would - so where do you think I should do that where people could actually see it, and it wouldn't take me 4+ hour distraction learning how to create a blog project and read 18 page "read this before submitting a blog" ? I've got alot of notes down and got the project up to almost complete.
I got examples from some other forum posting code without those code-break quotations, and it wound up changing the code - and costed me like 2 days of trying to figure out what was going on, since the html replacement for their codes somehow WORKED without causing a compiler error.
Anyway...
This project has consumed WAY TOO MUCH of my time trying to learn how to decrypt the signal. And my research this far - is that the sensor module I purchased, somehow mergers the signals of two sensors into one side - and I was unable to figure out how to get a steady reading from just one sensor in the module. I am unable to track down the specific make/model of the car park sensors in the example b-logs I went to because the ebay items all appear to have the same box artwork, same exterior plastic shell, and do not list exact make/model build date code.
I put this on hold, probably just going to install the sensors, remove the dumb beeper and use the crappy read-out it comes with, since the $15 I paid for it didnt really break my bank.
