log tyre pressure/temp in Racechrono ?

2»

Comments

  • @aol

    Just a quick update from my last post there. I've been thinking more about my answer to #1 and really I guess it comes down to.

    Are there any other devices that use iBeacon sort of communication that would warrant adding some sort of option directly in the app for monitoring and receiving iBeacon Data and then processing it.

    If not, then I imagine the option then becomes using the "RaceChrono DIY" --> "Bluetooth LE" and make a board that would require coding to read the values which then transmit to Racechrono. Are any of the ones on the forum capable to your knowledge of taking the place of the OBDlink MX? I use the custom pid feature there. But if I had to go this route, then I may as well replace my OBDLink MX at the same time if I can make an all in one solution which then passes the results to Racechrono.
  • edited December 2021
    Hi Michael86,

    I been trying to digest this, and it seems that using "DIY" protocols for a commercial product is probably not the right way to proceed with this. First of all, most BLE devices require a lot more code than just decoding a byte array into channels. Second, the feature would probably not have that many users as writing the equations is not exactly easy.

    I think the way it should be is that there would be a native support in RaceChrono, similarly to other commercial devices. Also I rather not reverse engineer the support, but would get the documentation from the manufacturer... Sometimes it's really simple to reverse engineer it, but in this case it seems not to be? Or maybe my BLE knowledge is not enough to immediately see whats happening with the broadcasts.

    Certainly you could build a "centralised" sensor hub, using the CAN-Bus DIY API. It can be used to input other data too.
  • Hey @aol,

    Warning...long post.

    Note: Please forgive my suggestions below in terms of workload on your part. I don’t have the knowledge of the backend so don’t actually know what kind of effort is required on your end to do additions to the app. Just putting some thoughts out there for you to do with as you wish. This has been fun for me to learn as I enjoy this stuff. (Though I wish I was faster at it!)

    I see what you’re saying. Having MFR support would be much better but I doubt they would help. With that in mind though, I’ve done some more digging though and will list some more here.

    First – on the discussion on DIY - keeping in mind that you said you’d rather not use “DIY” protocols for a commercial product. My question is this – would having a “Custom iBeacon” parameter be useful to anyone else who wants to send custom values to overlay into their video? I know that you’ve opened up some other options in there with Racechrono DIY but I don’t see anything with regards to iBeacons.

    If it is, then I would see it work like this:

    Step 1: Assuming that the best spot to have this would be under “settings” -> “Other Devices” -> “Add Other device” -> “Custom iBeacon”

    Then I would anticipate the following steps would be the options:

    1) Select unique device identifier (Options: MAC Address, UUID, Major, or Minor)

    Note: From my research on iBeacon’s they sometimes use the same MAC address but lots of them rotate and use UUID/Major/Minor in order to id / transmit data like my device.

    2) Enter unique identifier (Depending on what was selected, for Major or minor it could include option to be in decimal or Hex.

    3) Enter value to be monitored (leave options for either Major or Minor / both)

    4) Enter equation 1, 2, 3 to x (using the formula’s already available in Racechrono)


    Second – Doing native support in RaceChrono without MFR. (Yay the freedom!)

    In terms of the reverse engineering the device. You said, “sometimes it’s really simple to reverse engineer it, but in this case it seems not to be?”. Well I’ve done more work and you can grab some information from the back of the TPMS sensor so anyone else getting it would be able to grab their “Major id” from the back (though in HEX) which is the unique identifier for this one. I’ve included some more information below as well as some of the other UUID’s that are possible with the different formulas that they would use. So really, you could add native support for this device without the MFR’s involvement with just having the digits that I’m about to explain on the back.

    That’s possible because the ID on the back is HEX and when converted to Decimal it is the Major ID of the device. So using these sensors it can easily be added to a monitoring app just by knowing the HEX ID on the back of the device.

    Ex: On my tested device the ID is:
    07466 (HEX) which converts to:
    29798 (Decimal) (The Major ID that is broadcasted).

    So in order to add this as a native support without the MFR you could do it like this:

    User Steps:
    Step 1: “settings” -> “Other Devices” (or a new “TPMS Devices” section)-> “BLU TPMS”

    Step 2: Here there would be options. But the user needs to be able to add location of the TPMS and provide the “ID” from the back of the sensor (which is in HEX). I would also suggest leaving a spot for a custom name so that individual sensors can be easily swapped when the user swaps out the front tire etc.

    EX:
    Name: Front Rain (custom field for user to toggle on or off depending on rims on vehicle)
    ID: 0x07466
    Location: Front (Motorcycle) (or, Front Left, Rear Left etc for a car)



    Backend Racechrono setup:

    After that. The rest can be in the backend without any user involvement thereby making it extremely simple as a plug and play addition to Racechrono which makes it easier for the majority of the users. Here is what is needed for Temperature and then for Pressure.


    Step 1: Convert HEX ID into Decimal
    EX: 0x07466 = 29798 (decimal)


    Step 2: Receive incoming iBeacon and scan / match the MAJOR id (decimal) to the value converted in step 1. Ie: if 29798 = 29798 then analyze further and store data into a table (or whatever you do on the back end!)


    Step 3: Log Minor ID (decimal) and convert to HEX (also log the UUID that is broadcast as you will need it)
    Ex: 23401 decimal = 0x5B69


    Step 4: Calculate Temperature
    Analyze byte 1 (0x5B)

    Note 1: You’re best suited to know how you would do this. But I imagine you would store the Minor data into a table and use your existing equations like bytestoUint to get the next value.

    Convert byte to Uint16 – little endian BA
    Ex: 0x5B = 91

    Apply formula based on which temperature unit the user selected in the global settings.

    Note 2: There are 3 different formulas for Temperature based on UUID. I grabbed them from the app code and listed the three options below. The UUID is broadcasted each time along with the Major / Minor so you can use that to know which one to use:

    Note 3: The UUID’s are all the same other than the final digit. So really, you could just log the final digit for knowing which set of formulas to use.

    Case 1: UUID = b54adc00-67f9-11d9-9669-0800200c9a66

    Formula degC = value – 40 (value in this case is 91 as shown above). Therefore output would be 51 deg C.

    Formula degF = (value-40) * 9 / 5 ) + 32 (Note: standard equation for this but I confirmed in the app coding that they calculate in Celsius and convert to F if the user requests F)

    Case 2: UUID = b54adc00-67f9-11d9-9669-0800200c9a67
    Formula degC = (value*2 – 40)
    Formula degF = (value*2 - 40) * 9 / 5 ) + 32

    Case 3: UUID = b54adc00-67f9-11d9-9669-0800200c9a6a
    Formula degC = (value*3 – 40)
    Formula degF = (value*3 - 40) * 9 / 5 ) + 32


    Step 5: Calculate Pressure (This formula is revised after looking into the app coding)

    Analyze byte 2 (0x69)
    Convert byte to Uint16 – little endian BA
    Ex: 0x91 = 105

    Pressure (kPa) = value * 2.5 (This is the unit that the sensors use as a base)

    Note: The following 3 are the exact conversions that the app uses from the code.

    Pressure (Bar) = (value * 2.5) * 0.01
    Pressure (psi) = (value * 2.5) * 0.145038
    Pressure (km/cm2) = (value * 2.5) * 0.0102

    Note: the UUID plays no role in the pressure calculation. Same for all sensors.

    So basically, I think I’ve discovered all the necessary items / formulas through my test combined with my work going through the app coding and I believe that now you would have enough data to do a native addition for BLU TPMS sensors. All up to you of course! It’s just different than normal since all of your custom devices require the device to be “active” to add it whereas in this case it wouldn’t be. Racechrono would just ask for the hex ID and then listen for the broadcasts when the vehicle is in motion.

    Let me know if you have any questions!


    Some other random info I found out while looking at it:

    The Serial Number on the back starts and ends with the MAC address that is transmitted with each intermittent beacon packet. Ie: my SN for my device was 98588A0A7466 and all the iBeacon broadcasts were from MAC Addresses with 98:xx:xx:0A:74:66 and the value increments linearly as it broadcasts. Ie:
    98:84:B8:0A:74:66 was followed by
    98:84:B9:0A:74:66
    Just including it as extra info. Not needed.
  • Hey @aol just wondering if this is something that you might implement into the app or not. If yes I'll keep the sensors handy, if not I'll use them for something else.

    Thanks!
  • @Michael86 Well it's not a priority right now, unfortunately, as implementing them seems to be a bit complicated; at least there's still some stuff to figure out with the broadcasts.
  • @aol no worries at all.

    Just curious though, do you mean figuring out broadcasts on your Racechrono development side for receiving that sort of broadcast or is it something that needs more research on my side that I can work on and get you some info on? I also have way too much on the go but next Fall / Winter I might have time to do some more digging into it if it's something I can do.
Sign In or Register to comment.