My wife drives a Toyota Auris Hybrid and sometime ago (winter I think) the TPMS (Tyre Pressure Monitoring System) dashboard warning light came on. Unfortunately that is all the information the car gives - no indication of which tyre is the problem or why. Checking the tyres and resetting the TPMS made it go away for a while before the problem quickly returned. At the next car service, it was mentioned to them and whatever they did, it seemed to go away. They stated that one of the tyres was slightly low on pressure which I disputed because I had checked them on several occasions. Anyway the problem seemed to be 'solved' but the frustration of not knowing why remained.
How It Came About (Part 2)I was recently using an RTL2832U dongle, SDR (Software Defined Radio) and the excellent RTL_433 software to sniff some 433MHz signals when, to my surprise, up popped some messages about Toyota Tyre pressures. I realised these were coming from my wife's car outside on the driveway. Given the history (see Part 1!), I thought I should be able to come up with a way to display these tyre pressures in the car using a standalone Arduino and without having to resort to the car's ODB2 interface and CAN message decoding.
About TPMSThere are various methods which car manufacturers use for TPMS and I would point out that this solution is targeted specifically at a Toyota Auris Hybrid. It may work on other Toyota hybrids/car types but I can't say for sure. Should you decide to do a similar project, you should ensure you know what type of monitoring system and sensor is used on your car before starting otherwise you will be disappointed.
The TPMS sensors on the Auris Hybrid tyres transmit at 433MHz approximately every 90 seconds although this varies (presumably to avoid repeated collisions). The data transmitted consists primarily of a sensor ID, the tyre pressure, the tyre temperature and a checksum (other status bits are also transmitted).
There is no indication of which sensor ID maps to which wheel so this is trial and error. I have worked out which is which for our car and encoded this in the software to ensure the information is displayed consistently.
The sensor signals do not appear to be very strong so I found I needed to be within 2-3 meters to get a reliable signal.
Note: Some TPMS sensors do not transmit when the vehicle is stationary - only when the vehicle is in motion or there is a sudden change in pressure. Please remember this if trying on different car/sensor types!
AcknowledgementsI'd like to acknowledge the work done by the RTL_433 team (in particular Christian W. Zuckschwerdt) and by 'shcm' on the RAV4 Drivers Club website. Both of these were very helpful to me in understanding the 433MHz transmission protocol from the tyres and therefore speeding up the development.
Very many thanks too to Steven Andrews for his most generous support and help on this project. He has been especially helpful in helping to progress the adding of sensors for other TPMS sensors.
Two libraries were included for the I2C display:
AdaFruit_GFX/Adafruit_SSD1306 (not used in the end due to memory limitations) SSD1306Ascii/SSD1306AsciiWire (Text only library) - thanks to Bill Greiman for this.
Library for the ST7735 TFT 128 x 160 display:
Adafruit_ST7735
Adafruit_GFX.h
Adafruit_ST7735.h
Library for the ST7735 TFT 240 x 240 (round) display:
Adafruit_GFX.h
Adafruit_GC9A01A.h
EasyEDA used for schematic capture
Technical DetailsUsing the GNU SDR software I was able to work out that the tyres transmit using FSK (Frequency Shift Keying). The centre frequency is about 433.88 MHz with a deviation of around +/- 24-30kHz. The data is Biphase Mark Coded and is 72 bits in length. The data rate is 10kHz and the total message length is about 8ms.
To receive the signal I chose a CC1101 module. This module is based around the CC1101 IC from Texas Instruments and has an SPI interface along with a couple of pins which can be configured in the device to output various signals. I configured it to output the raw receive signal and the carrier sense (CS) signal. The CS hardware signal was not used in the final solution as the same signal is available by polling a register over the SPI however the hardware signal was useful when hooking up the logic analyser to 'frame' the raw receive signal and aid debugging.
Configuration of the CC1101 registers can be a little daunting but there is a software package from TI called SMART RF Studio which can help with this. The CC1101 can be used with the internal FIFO etc. to capture the data bytes directly and read them over the SPI but I could see no way to configure it for the data I was expecting so this project uses it as a basic RF receiver with the RX data being output onto one of the configurable pins and the Arduino then tries to make sense of the data stream.
The CC1101 runs off 3.3volts. Most of the Arduino boards are 5v which means a level translator is required for the interface signals. I did in fact do this with a Mega initially but I wanted the final solution to be as compact as possible so I chose the Arduino Pro Micro 3v3 (note: there is also a 5v version of this so be careful which one is ordered!). This 3v3 board only runs at 8MHz and has limited RAM but I decided I could probably get away with this.
The display used was a 0.96" 128 x 96 yellow and blue I2C module based on the SSD1306 which can be found from various suppliers. My choice of Arduino came back to bite me a bit here as the normal library for these displays uses a 1k buffer to hold a mirror of the display data. This exceeded the RAM limit and meant I had to switch to a text only, low RAM library but it seemed to work well.
Once the basic register settings for the CC1101 were established, a logic analyser assisted in showing that the CC1101 was receiving a reliable signal and was used to decode the biphase mark coding to show the individual bytes (see image below). The logic analyser was triggered from the CS signal when the pulse width was around 8ms. This generally filtered out the analyser being triggered by other unwanted RF signals.
The picture below shows an example of the logic analyser capture from one of the tyres.
The shorter pulses are around 50us and the longer pulses around 100us. Data is transmitted MS bit first. There should be a sync pattern prior to the valid data but I didn't find this a very reliable method for detecting the start of the message (possibly due to my amateurish configuration of the CC1101 AGC etc.?)
Although the data rate is 10kHz, the bi-phase encoding meant the CC1101 needed to be configured at twice this data rate (20kHz) to ensure capturing of all the transitions
As reported in the RTL_433 code, the message structure is 1st 4 bytes = sensor ID, 1 bit status, 8 bits for the pressure (P), 8 bits for the temperature (T), 7 bit status, 8 bit pressure repeated (but inverted) and an 8 bit CRC (0x07 truncated polynomial with 0x80 initial value).
The actual temperature = (T - 40) degrees C
The actual pressure = ((P/4) - 7) PSI
So I could see the message on the analyser, all I had to do now was to implement a method of decoding this using the Arduino.
I tried a few methods but the one which proved the most efficient and reliable was:
- Wait for CS to go high (by reading the CC1101 status) and mark the start time
- Use the Arduino pin interrupt to detect and store the time between edges Timings less than 12us were classified as 'glitches' and ignored. If more than 255 transitions were seen, the interrupt routine stops storing the times (buffer full).
- When the CS goes low again, calculate the width of the CS being high. If it was high for the expected ~8ms, process the timing buffer and look for a valid message. If not ~8ms or no valid message detected, wait for the next CS high again.
- The validation routine checks the timings and converts them to 0s and 1s and stores these in a 'bit buffer'. The number of bits found is returned.
- If the number of bits is the expected 72, the bit buffer is decoded into bytes
- The byte buffer is checked for a valid TPMS message - 9 bytes in all anda includes a checksum check.
- The TPMS data is displayed on the I2C display module (screen position is TPMS sensor ID specific).
The 3 components (Arduino, CC1101, OLED display) were built into a 3D printed case. The design was created using Fusion 360. It isn't the best (although OK for a first prototype) and could do with refining in the following areas:
- A little bigger to allow more room for the cabling (currently a bit tight)
- Close down the USB cable entry aperture slightly
- Close down the OLED display area (an area at the bottom of the display does not form part of the display and could be hidden
Power is supplied through the 5v USB input and can be sourced from the USB socket in the car.
How to Build OneThe design and wiring is very simple (see schematic). Make sure the OLED is wired from the correct side to avoid wires getting in the way of any enclosure which might be used.
If you haven't used this particular Arduno board before, you may need to configure the Arduino IDE for the Pro Micro board.
An excellent guide for this can be found on the Sparkfun website here.
Make sure "Sparkfun Pro Micro" is selected from the Tools-> Board list menu.
Also ensure "ATmega32U4 (3.3V 8MHz)" is then selected from the Tools-> Processor menu.
Plug in the Arduino to the computer USB port and select the allocated port from the Tools-> Port menu option.
Load the code (consisting of 5 files) into the IDE and compile and upload it to the Arduino.
To see the decoded information on the Serial port, you should uncomment the SHOWDEGUGINFO line at the top of the globals.h
Line 64/65 in the globals.h file has 4 IDs listed. These are specific to our own car and are in the order of Front Left, Front Right, Rear Left, Rear Right. This ensures that no matter what order the IDS are received in they will always appear in the correct location on the display.
Once you know the IDs for your car (shown on the Serial port with debug enabled. - note: the IDs are not shown on the OLED display) and which wheel they relate to, possibly by altering the tyre pressures one at a time, you can update the code with your IDs. This ensures they are always shown in the correct order on the display.
If the codes received don't match with lines 64/65, the 1st 4 tyre pressures received will still be displayed but the order will be based on 1st come 1st served basis and therefore there will be no relationship with the physical tyre.
The Seeeduino Xiao can be used in place of the Pro Micro. This is a faster device with more memory and is smaller in size.
Also, if using the Seeeduino Xiao, a bigger display can be used - a 1.8" ST7735. This provides space for more information such as the ID and provides a colour display.
Note: Given the larger graphics libraries, this display is unlikely to work with the limited memory on the Pro Micro.
A suitable 3D printed case for the Seeeduino Xiao and the ST7735 display will hopefully follow when all the new code additions have been completed.
V8.0 adds an optional audible alarm using a 3v3 buzzer. The flashing code is also improved and requires the installation of the ticker.h library.
How to UsePlug into a 5v USB supply.
If functioning, the title (in yellow) should be displayed on the top two lines.
If within range of any Toyota TPMS tyres, the display should show each one in turn. The larger digits show the tyre pressures, the line under the pressure shows that tyre's temperature and a digit from 1-5 giving a rough indication of how long since the last transmission. 5 = very recent, 1 = least recent. If a transmission is not received within 30 minutes, any previous data for that tyre will be erased from the display.
The tyres only transmit every ~90 seconds, so be patient when waiting for the unit to receive and update the information on the display. The closer to the tyres, the better the reception should be but it should also be possible to gather some information from nearby (e.g. in the house) if the car is sufficiently close.
This unit does not remove the need to check tyre pressures regularly with the correct equipment. It is intended only to provide some insight as to why a TPMS alarm might have been raised by the vehicle.
Versions and ConfigurationVersions:
V1.0 Originally published version using asynchronous data output from CC1101
V2.0 Updated to allow support for spare tyre reporting (although not displayed on LCD display)
V3.0 Added #define in globals.h to switch between BAR and PSI
V4.0 Significant changes to use synchronous data output from CC1101. Allows option of getting the CD signal state either via SPI or by monitoring hardware pin.
V5.0 Bug fix - improvements to better detect start of valid data. Should improve hit rate on valid TPMS detection.
V5.1 - Added freq offset updates (SWRA159) - removed again(makes it worse!)
V5.1.1 - Added functions for extracting RSSI as dbm
V6.0 - Added code for options for US (315MHz) or UK (433MHz), also for different sensor types (PMV-C210, PMV-107J)
V6.1 - Added support for Seeeduino Xiao processor
V6.2 - Included support for Renault (Renault Clio, Renault Captur and maybe Dacia Sandero?) as an option (to be verified)
V6.3 - Included support for Citroen (possibly also includes Peugeot and likely Fiat, Mitsubishi, VDO-types) as an option (to be verified)
V6.4 - Some code rationalisation, all sensor timings now in Configs.h
V6.5 - Tried to improve PMV-107J decode by starting at the end of the buffer and working forwards
V6.6 - Added other car types (under development), changed PMV-107J frequency deviation, added #define as option to only detect specified IDs, stripped leading 4 bits from ID (as per 'Glopes' comment) for Toyota, moved some globals settings to Config.h, changed AGC settings
V6.7 - Adjusted PMV_C210 presure calculation to lower PSI by 0.3 (as suggested by Steven Andrews by comparing with Autel programmer).
- Added option for displaying Fahrenheit (#ifdef DISPLAY_TEMP_AS_FAHRENHEIT in configs.h) rather than centigrade.
- Re-introduced flashing display if pressures outside of pre-set limits (enabled by #define ENABLE_PRESSURE_ALARMS in configs.h. PressureLowLimits and PressureHighLimits in config.h should be set as required)
V7.0 - Included option for 1.8" TFT display (requires use of the Seeeduino Xiao for extra memory - Nano may work but not tested!), The previous 0.96" display is still supported in this version! Tested OK on Nissan Leaf (2016).
V8.0 - Added (optional) audible alarm for pressure alarms (see schematics). Improved display flashing. Tested with Toyota Auris (2016) and Nissan Leaf (2016) 433MHz OK
V9.0 - Added Pontiac (US) decoder option, moved all CC1101 configs to sensor-specific include files, improved timer handling. Added temperature compensation for pressure limits (set pressure limits reference temperature in configs.h). Added kPA pressure display option. Pressures always stored locally as psi and temperatures as deg C - including limits (converted if required for the display). Tyre pressure and temperature limits are assumed to be in the required units e.g. bar, kpa, psi, degC, degF depending on config choice.
Added support for 240x240 round display (Steven Andrews' display code - thank you!)
V9.1 - Added provisional support for Arduino Nano 33 IOT board
V9.2 - Fixed bugs in audible alarm for temperatures. Fixed missing degrees F/C for round display.
V9.3 - Corrected some title positioning for display.h, Added support for Renault Zoe (pre 07/2019 sensors). Zoe sensors on or after 07/2019 should work as standard but comment out 'Zoe' in configs.h for these.
V9.4 - Corrected compile error when not using a display - thanks Zaran on Hackster.io!
V9.5 - Changes to cope with multiple tyre sets (Summer/Winter). Corrected bug in ID matching (IDs were allocated to PROGMEM but referenced as SRAM for lookups), this meant tyre position was not being reported correctly. Moved Ref[3] to globals.
V9.6 - Fixed bug where lcd display was partially obliterated if TYRECOUNT > 4 (the default is now 5)
V9.7 - Fixed bug in Ford.h which caused out of range temperture values to be displayed on screen when temperture below 0C. Changes to support new larger screen type (supplied by Steven Andrews' - thank you!). 2.4inch LCD Display Module 65K RGB Colors, ILI9341 2.4" TFT 240×320. Requires Adafruit ILI9341 library.
V9.8 - Added support for Truck Solar TPMS and Mega256 builds
V9.9 - Added variation for Ford for different temperature structure (trial only) to support Ford E-Series (Schrader 29020 - Tom Logan)
V10.0 - Improved Ford incoming message handling
V10.1 - Changed Ford pressure decode in line with actual E-series Schrader sensor feedback. This sensor also seems to delay sending temperatures after sleeping and sends a counter instead.
V10.2 - Missing conditional for 2.4" screen in setup in .ino file (line 350) preventing initialisation of display (USE_24_INCH_ILI9341_DISPLAY). Causes screen to continually display white (thanks to TomasoNL for his help on this one).
V10.3 - Changed PMV-107J & PMV-C210 to try to improve detections. Code now walks through the received bit stream until a valid checksum match is found (or runs out of data). This avoids the need to look for sync bits which may not be reliable at the start of the bit stream (includes change to common.h)
V10.4 - Added TRW-C070 (Toyota Sienna) support. Requires real-world validation.
V10.5 - Improvements to Toyota Sienna TRW C070 detection/validation. Added Hyundai I35 as option for this same sensor. Fixed temperature display bug (thanks Larry on Hackster for pointing this out.) - it would overflow/underflow with certain readings. Feedback from Alistair Clark on Hackster indicates that the C210 decode also works for Toyota Corolla (2019-22 PMV-C215 sensor).
V10.6 - Corrected slight bug in display.h for Hyundai (should have been newline print)/ Thanks to grigata on Hackster for pointing this out. Reported by gamer765 that PMV-107J also works for PMV-C11A sensors.Added support for Hyundai Tucson TL/TLE (2015) using Schrader C1100/C8000 sensor. Many thanks to RM for helping on this one. Late change in CC1101.h to correct bug where FIFORead function did not have a correct return statement (not apparent when compiling for Xiao processor!)
V10.7 - Correct bug in CC1101.h in ReadFIFO function - it was missing the return statement (but worked for Xiao without it???)! Thanks to Nomake Wan for helping out on this one. Added possible support for Xiao RP2040 (TBC). Added support for Schrader A0009054100 sensor used on Smart Fortwo 01/2007-02/2014 (433MHz) - OOK
V10.8 - Changes to get code working for Xiao RP2040 (same schematic as existing Xiao)
V11.0 - Added Winter tyre pressure limits (optionally). These could be easily be missed and cause an indexing outside of the array if INCLUDE_WINTER_SET enabled. Added suport for Summer/Winter tyres on the displays (previously only available on serial output). Basically, if so configured, the Summer and Winter tyre IDs will be recognised and displayed in their position on the display - user should make sure the other tyre set is out of range!
V11.1 - Abandonded (not published)
V11.2 - Changed handling of CD in main routine. Need to configure a valid ENDTIMING_MAX for each sensor type. This is used to exit the CD loop early if a reasonable number of bits have been received and it's been > ENDTIMING_MAX since the last edge (i.e. an ivalid bit timing - probably only valid for Manchester coded data)
V11.3 - Added processor option for Adafruit 3v itsybitsy (although not recommended due to memory size). Put in conditionals for the TFT display include files to handle different GPIO formats (e.g. D1 vs just 1) depending on processor selected (fix for SPI displays not working with RP2040 Xiao)
V11.4 - Changes from 10.8 affected CDWidth timings causing some sensors not to be detected. Fixed. Added software version to serial print out at startup.
V11.5 - Added LCD type to serial print out at startup. Debugged Jansite Solar code. Corrected bug in CRC routines. Changed all general declarations to width-specific types e.g. int to int16_t
V11.6 - Trial of Subaru Impreza sensors code, both 433MHz and 315MHz (the two frequencies have different protocols)
V11.7 - Tidied sloppy coding as much as possible in order to remove compiler warnings
V11.8 - Corrected bug in Manchester decoding under cetain circumstances when the number of leading 'short' timings before a 'long' timing is an odd number.My thanks to Andrey Oleynik for pointing this out. Affected Toyota PMV_C210 and PMV107J. Fixed bug in Toyota_PMV_C210 around line 426,, DecodeBitArray call was missing a parameter and therefore calling the wrong instance. This caused the search for possible alternative valid checksum somewhere in the sequence to have always failed. Adjusted Deviation, data rate, AGC settings for PMV107J (US - 315MHz) as recommended by Andrey Oleynik to improve reception
V12.X - Trial version only. Written for ESP32 (also tested with Seeeduino Xiao). Only tested with Toyota PMV_C210. Eliminates use of CD signal from CC1101 by continuously monitoring RX pin. Seems to improve detection rate. Tested with Wifi and MQTT. Packaged as zip file only.
Configurations:
The software specifically supports the following processors:
ProMicro (3.3v)
Arduino Nano - no longer recommended due to insufficient RAM (only 2k). (Try switching to Seeeduino Xiao (or possibly Arduino Nano 33 IOT - not yet verified but it won't require level shifters as it's 3v3!)
Seeeduino Xiao
Seeeduino RP2040 Xiao
The code automatically detects the processor type from the IDE setting (other processors are likely to work e.g. Mega but will require minor code changes and testing)
The appropriate wiring must be used for the processor being used (including level shifters for 5v processors where applicable e.g. Arduino Nano).
See pin configurations in globals.h and the schematics section for more details.
Possible combinations and status:
Sensor Type 433MHz 315MHz Comment
Toyota PMV-C210 OK N/A Working in UK
Toyota PMV-107J N/A OK Range can be an issue
Toyota TRW-C070 OK TBC Used on Toyota Sienna
Nissan Leaf (2016) OK ? Working in UK
Renault TBC ? Not confirmed
Citroen TBC ? Not confirmed
Ford TBC ? Not confirmed, different types
Jansite ? ? Not confirmed
JansiteSolar ? ? Not confirmed
Pontiac G800 N/A OK Believed working in US
Truck Solar OK N/A Awaiting confirmation
Schrader C1100 TBC ? Used on Hyundai Tuscon
Schr(A0009054100) OK N/A Used on Smart Fortwo
? = code may require changes to support these if they exist with these frequencies
TBC = code should work but needs to be confirmed with real sensors (code based on previous individual releases)
Display settings:
Please be aware there are typos in the code for the display settings - defines shown as 'ST7753' but should really be 'ST7735'. It works OK as is but may be confusing! Will try to correct on later version.
For no display at all (i.e. relies on the data put out on the usb serial port), comment out all display options:
//#define USE_1_INCH_YB_I2C_DISPLAY 1
//#define USE_2_INCH_ST7753_DISPLAY 1
//#define USE_2_INCH_ST7789_DISPLAY 1
//#define USE_24_INCH_ILI9341_DISPLAY 1
For the 0.96" OLED I2C 128x64 display uncomment the USE_1_INCH_YB_I2C_DISPLAY only
#define USE_1_INCH_YB_I2C_DISPLAY 1
//#define USE_2_INCH_ST7753_DISPLAY 1
//#define USE_2_INCH_ST7789_DISPLAY 1
//#define USE_24_INCH_ILI9341_DISPLAY 1
For the 1.8" TFT 128x160 SPI display, uncomment the USE_2_INCH_ST7753_DISPLAY only:
//#define USE_1_INCH_YB_I2C_DISPLAY 1
#define USE_2_INCH_ST7753_DISPLAY 1
//#define USE_2_INCH_ST7789_DISPLAY 1
//#define USE_24_INCH_ILI9341_DISPLAY 1
For the TFT 240x240 SPI round display, uncomment the USE_2_INCH_ST7789_DISPLAY only:
//#define USE_1_INCH_YB_I2C_DISPLAY 1
//#define USE_2_INCH_ST7753_DISPLAY 1
#define USE_2_INCH_ST7789_DISPLAY 1
//#define USE_24_INCH_ILI9341_DISPLAY 1
For the TFT 240x320 2.4" display, uncomment the USE_24_INCH_ILI9341_DISPLAY only:
//#define USE_1_INCH_YB_I2C_DISPLAY 1
//#define USE_2_INCH_ST7753_DISPLAY 1
//#define USE_2_INCH_ST7789_DISPLAY 1
#define USE_24_INCH_ILI9341_DISPLAY 1
Readout options:
To display the tyre pressures in BAR rather than PSI on the LCD display, uncomment the #define DISPLAY_PRESSURE_AS_BAR 1 in configs.h. Similarly, to display in kPA, uncomment the #define DISPLAY_PRESSURE_AS_KPA 1 line in configs.h. WIth both options commented out, the default will be PSI.
To display tyre temperatures in Fahrenheit, uncomment #define DISPLAY_TEMP_AS_FAHRENHEIT 1 in configs.h - with this line commented out, the default will be degrees C.
Alarm options:
To enable warnings of low/high tyre pressures visually on the display by flashing the value, uncomment the line:
#define ENABLE_PRESSURE_ALARMS
in configs.h and set the high/low pressures for each tyre in these arrays:
const float PressureLowLimits[]
const float PressureHighLimits[]
These values should be the same units as selected in the readout options above for the pressures (PSI, kPA or Bar).
The flash rate can be altered by changing the DISPLAYREFRESHTIMING value in globals.h (this is in milliseconds and defaults to once per second).
To enable audible alarms as well (requires buzzer connected to the appropriate Arduino pin), uncomment the line:
#define ENABLE_AUDIBLE_ALARM in config.h
Similar alarm settings can be set for temperature warnings if required:
#define ENABLE_TEMPERATURE_ALARMS 1
Buzzer settings can be altered if required in globals.h. By default, the buzzer will give 5 bleeps if an incoming tyre pressure is outside the set limits. If the alarm has already been triggered once by a particular tyre, the alarm will not sound again for repeated out-of-spec transmissions for that tyre, however a 'reminder' buzzer will go off after every 30 minutes (alterable in globals.h). Setting the reminder value in globals.h to 0 will disable this option.
Note: the alarm will give 2 short beeps on start up to indicate the buzzer is working OK.
Vehicle/Sensor settings (config.h):
- Uncomment the required frequency (433MHz or 315MHz). The other frequency option should remain commented out
- Uncomment the vehicle manufacturer/car+sensor type (only one should be selected)
- If necessary set any optional settings for that vehicle manufacturer (e.g. Ford)
Examples:
For UK frequencies (433MHz) and (Toyota) PMV-C210 TPMS sensors:
#define UK_433MHz 1
//#define US_315MHz 1
#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
//#define Toyota_TRW_C070 1
//#define Renault 1
//#define NissanLeaf 1
//#define Citroen 1
//#define PontiacG82009 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For UK frequencies (433MHz) and Renault TPMS sensors:
#define UK_433MHz 1
//#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
//#define Toyota_TRW_C070 1
#define Renault 1
//#define NissanLeaf 1
//#define Citroen 1
//#define PontiacG82009 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For UK frequencies (433MHz) and Nissan Leaf Sensors:
#define UK_433MHz 1
//#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
//#define Toyota_TRW_C070 1
//#define Renault 1
#define NissanLeaf 1
//#define Citroen 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For UK frequencies (433MHz) and Citroen TPMS sensors:
#define UK_433MHz 1
//#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
//#define Toyota_TRW_C070 1
//#define Renault 1
//#define NissanLeaf 1
#define Citroen 1
//#define PontiacG82009 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For UK frequencies (433MHz) and Truck Solar TPMS sensors:
#define UK_433MHz 1
//#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
//#define Renault 1
//#define NissanLeaf 1
//#define Citroen 1
//#define PontiacG82009 1
#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For US frequencies (315MHz) and (Toyota) PMV-107J TPMS sensors:
//#define UK_433MHz 1
#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
#define Toyota_PMV_107J 1
//#define Toyota_TRW_C070 1
//#define Renault 1
//#define NissanLeaf 1
//#define Citroen 1
//#define PontiacG82009 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For US frequencies (315MHz) and Pontiac G800 TPMS sensors:
//#define UK_433MHz 1
#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
//#define Toyota_TRW_C070 1
//#define Renault 1
//#define Dacia 1
//#define NissanLeaf 1
//#define Citroen 1
#define PontiacG82009 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For US frequencies (315MHz) and Toyota Sienna TRW-C070 TPMS sensors:
//#define UK_433MHz 1
#define US_315MHz 1
//#define Toyota_PMV_C210 1 //should also work for PMV-C010??
//#define Toyota_PMV_107J 1
#define Toyota_TRW_C070 1
//#define Renault 1
//#define Dacia 1
//#define NissanLeaf 1
//#define Citroen 1
//#define PontiacG82009 1
//#define TruckSolar 1
//#define JansiteSolar 1
//#define Subaru 1
For hardware monitoring of the CD signal (recommended), uncomment USE_HW_CD in globals.h, To obtain the CD state over the SPI bus from the CC1101, comment out USE_HW_CD (use this method if GO0 is not hardwired to an Arduino pin)
To display valid TPMS readings in the serial monitor, uncomment the #define SHOWVALIDTPMS in globals.h
To display more detailed timings etc. uncomment the #define SHOWDEBUGINFO in globals.h
Note: displaying information on the serial monitor should only be done for debug purposes as the TPMS timing is critical and readings may be missed if excessive serial port activity is employed.
Additional Information