For those that program on embedded hardware like Esp32. If you send a html header for “Content-Encoding” with a value of “gzip”  first then you can send compressed data rather than html plain text. Ive just got a small script that read the .html files in the project folder and saves a copy with .gz or .txt containing a c byte array which can be copy pasted into the c source. This is obvious if you know anything about the internet, but I just hadn’t looked at it since I was still trying to get things working. Even for my small pages this on the browser side reduces 8k to 1.2k. While this isn’t really large amount of data by modern standards, it is noticeable on the user side in browser having the page appear quicker. Since even the 10 year old android I’m, testing on has 4x 1.5ghz and 4x 2ghz cores, compared to the esp32 with 1 or maybe 2 cores at 240mhz. The decompression is faster on the phone cores than the delayed in sending more data by the slower esp32.

Bluetooth Low Energy 5.0 aka BLE 5 sensors finally arrived after getting lost at the airport for 3 weeks.   Tested them and for the record are the same as the most common sensors (#2 in previous post) for data and how they work. Physically externally they look very similar too.  The only difference in the specs is the power use is around 30-40% less. This is likely correct as the power is mostly in the Bluetooth transmission and ble5 is lower wattage than ble4. The manual is also just a copy with a few spec and details changed. Though the did miss changing a few ble4 references.   Good news for me and anyone else using those sensors if the receiver is ble5 there’s now need to change anything and they just work. This may also apply to OEM devices as ble4 hardware is old and may have already been substituted to ble5 during later production as it is backwards compatible. 

While not total disasters, they are still a little risky. This one even has the wrong components fitted. I’d stick to brand name or at a minimum a little more expensive devices.   The op-amp chip in this one is the same physical package as common canbus transeivers. Just in a transceiver there is a lot more protection and isolation to protect the canbus and device from each other. Thought the cost is at least 50x higher, possibly 2-500x higher.    

So far they seem to have exclusive access to Subaru, Suzuki etc diagnostic tools and Subaru support (eg unlock codes).   Almost every garage I called gets parts from them in the region so they set prices.   Not all parts are actually genuine! They get cheaper parts and don’t tell you, which I found out today from their parts department. But those cheaper parts arent sold much cheaper. Not to mention the $250-375 scanning fee for diagnostic if they don’t know what the fault is already. Though services include a scan for cheaper.   Combined with nearly $250 an hour labour rate seems like they are really milking it.

Well turns out JavaScript is more hassle than c. Finally after a couple of days the TPMS scanner now sends a nice webpage with a sorted list of discovered sensors. So all you need to do is select which one and which number you want it save it as.   The current arbitrary limit is 16 sensors that it will learn. The c code is a single line #define sensor-count 16 to change but the JS isn’t linked so has to be manually updated at the same time. The last piece is how sensor data is sent over canbus. The plan is to send the sensor number and mac address the first time it is seen. Then just sensor number and pressure every time the sensor broadcasts data. Sensors only send data on average every 10 minutes or so. Unless they detect a leak over time or a rapid change. Once they stop they send a idle message and go to sleep about 15 minutes later.