topic Re: TPMS bit timing in Sensors

TPMS bit timing

kumaichi — Tue, 03 Feb 2026 23:39:17 GMT

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.

Re: TPMS bit timing

TomasVaverka — Thu, 27 Nov 2025 07:16:02 GMT

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

Re: TPMS bit timing

kumaichi — Fri, 28 Nov 2025 04:50:20 GMT

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

Re: TPMS bit timing

kumaichi — Sun, 30 Nov 2025 00:52:40 GMT

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