TPMS bit timing

[kumaichi]

Hello All,

I'm trying to match an OEM TPMS sensors bit timing using a FXTH87E sensor.  I modified the getting started project, FXTH87_E_FW_Periodic_RF_Tx.

The issue I'm seeing, I'm trying to achieve ~25us bit timing for the data being sent but I have bits that are ~50us and others that are ~25us.  I have tried doubling the Data Rate via RFCR0 to ~40 kbits which fixed the preamble but then I end up with bits that are ~13us.  I'm using Manchester encoding as well.

I can't seem to figure out the correct settings to have the bits all at the same data rate.  I have attached my main.c as well as two logic analyzer captures, one of the OEM TPMS sensor and mine.  I'm trying to duplicate a packet length of ~5ms and bit timing of ~25us.  I'm currently getting a packet length of ~7ms and a variable bit timing of ~50us and ~25us.

Any suggestions would be greatly appreciated.

Kindest regards.

[TomasVaverka]

Hello Craig,

From the code in the main, 136 bits are transmitted at a data rate of 19200 bps (RFCR0 configuration). This makes a transmission time of 136/19200 = 7 ms. So from the code, it is completely expected to have a frame lasting 7 ms and not 5 ms.

With a data rate of 19200 bps, one bit lasts ~50 us. From the RF configuration, Manchester encoding is selected at 434 MHz. And in Manchester, there is a high-to-low or low-to-high transition at the middle of the bit (so after ~25 us). It means that a low or high state can last either 25 us or 50 us.

I copied below the extract from the manual (UM11227) showing Manchester encoding.

So the waveform captured matches the configuration done in the main.c, there is nothing unusual.

BRs, Tomas

[kumaichi]

Hello Tomas,

Thank you for your detailed response.  The OEM sensor, that is also using an FXTH87E, must not be using a standard way of sending the data?  The logic analyzer capture below doesn't have transitions like what is displayed in UM11227.  As far as I can tell, consecutive 0's and 1's aren't creating a transition, it just holds the same value for two cycles i.e. ~50us.  The decoded capture is:

010101010101010101010010110010101010101

Is it possible they are somehow modifying the data being sent to create the above data with consecutive bits doubling the bit timing without a transition?  I have tried using the different CODE[1:0] settings and I've also increased the bit timing to 40 kbit to get the ~25us bit timing but it did not remove the transitions.  I apologize for the simple questions; this is my first attempt at trying to duplicate a packet of data.  Any further guidance would be greatly appreciated.

Kindest regards,

Craig

[kumaichi · Accepted solution]

I believe I've made progress after many hours of experimentation.  I know that the data is Manchester encoded.  Knowing this, I used NRZ so that I could achieve the consistent bit timing of 25us for a single bit and 50us for two consecutive bits.  I then proceeded to encode the data bytes using Manchester encoding.  After a lot of trial and error I was able to duplicate the OEM data packet and could decode it successfully via my receiver.  Thank you for your guidance while I struggled to get this working.

Please consider this issue resolved.

Kindest regards,

Craig