Thanks Stro, I like the way you think; the differentiation is handled in software though. Since I decided to not implement LF communication modules to keep things simple, the receiver won't know if temp\pressure data is from the front or rear. So... to get around this I added a tire location byte to the data packet sent by the transmitters.Originally Posted by stroguy
The sensors transmit using essentially the same technique as FM radio, using an additional encoding scheme called FSK (frequency shift keying). In FSK, a base frequency is chosen and an excursion above or below base are recognized as zero or one. For example, my base frequency is 325 Mhz and my excursion is 38 kHz. Signals received at a frequency of 325 MHz - 38 kHz is decoded as zero and signals received at a frequency of 325 MHz + 38 kHz is a one.
If the videos above were zoomed in you'd see this... the pulses on the left are below baseband (zero's) and the pulses on the right are above baseband (one's).
These pulses are picked up at the receiver and decoded into a binary stream of one's and zero's which then makes it possible to process the information with digital circuitry. I've gone through a few iterations of exactly what information needs to be transmitted and I think I've firmed up on the below. The less information to be transmitted, the better, because it takes valuable battery power to send every one and zero. Data transmission is by far the largest power draw used by TPMS sensors.
The first 3 data bytes are a preamble; when the receiver detects a preamble being sent, it initializes its' receive circuitry for possible reception of data. The next 3 bytes are sync words which act like an encryption key; if this sequence matches the same sequence programmed in memory, it accepts the remaining bytes of the data packet... otherwise the packet is discarded as invalid. This is what will keep the TPMS system from picking up pressure data from the car in the next lane over.
The length byte tells the receiver how many more data bytes to accept.
And, finally, we get to the tire location byte. This is a unique sequence used to inform the receiver of where the data is coming from, front or rear. If front tire data is detected, for example, it will display that data on the top line of the LCD. If rear tire data is detected, it'll display that data on the bottom line of the LCD. The system is currently setup with just one alert LED, and an alert status sent from either tire will light it up. However, this doesn't tell the rider which tire is having problems. So... I wrote some code to inform the rider on the LCD. After seeing the alert LED and pulling over, the rider will see a message on the LCD telling which tire is the problem.
I'm thinking the alarm buzzer should work the same way; either tire can set it off and then the LCD will tell you which one is the problem.
Reply With Quote
