Hypertech (or similar) Speed Calibrator Operation

In the process of suspension/37s and now looking into calibrators. Hypertech has a piggyback unit which goes directly into the cluster. Looking at the wiring schematic it seems that the cluster's speedo/tach operates from CAN communicated OBD-II PIDs. There's lot of talk of 'reprogramming' but can anyone verify the operation of these devices? Has anyone opened the black box and checked the ICs? Based on pics in this thread: https://www.tundras.com/threads/hypertech-speedometer-calibrator.21747/, my guess is that the Hypertech unit has an MCU receiving power, ignition, and CAN. Then, based on the tire size and diff gear ratio you input, the calibrator just rewrites PIDs 12 and 13 in real time. It seems like an intercepting device and not an actual programmer. This is all speculation - someone educate me.

 

Sounds like over-analyzing to me. Just install it, put in your tire size, and be done with it.

 

Guessing he's wanting to integrate the functionality into his Carputer project: https://www.tundras.com/threads/raspberry-pi-open-auto-pro-carputer-build.102721/

As for the OP question, I've got this installed and am under the same impression that the box is translating the speeds, not reprogramming anything. I'd venture to guess that if I removed the box from behind my dash, it would go back to stock ratios and speed readings.

 

Ahhhh now I see. An electronic guru building things to make the rest of our brains hurt lol.

 

Bingo. And thanks for the feedback.

Need to decide if I want to just buy the Hypertech, build a standalone unit similar to Hypertech such that it operates independently of the RPi (I don't turn it on for short, in-town drives), or make the RPi handle the calibration alongside everything else.

 

I'll be following your progress on this. Seems like a very cool project. I love to tinker and hack, but this is way over my head lol.

 

I'm pretty dumb when it comes to electronics. Now that everything is transitioning to smart and IIoT, my career has been forced to pick these skillsets up. The truck is just a fun platform for experimentation with the added benefit of increased functionality/UX.

 

So I have that Hypertech unit installed and it works great. But when I tuned my truck with HP Tuners the speed correction was lost. HP Tuners flashes the computer with a base profile plus the mods you want to tweak. I then redid the Hypertech and got the calibration back but I lost the tune I did with HP Tuner. I redid the HP Tuners and use GPS to know how fast I’m going.

 

I had read a bunch of mixed opinions on Hypertech and that's another reason I'm considering a DIY solution. What you're describing implies real time rewriting isn't how the calibrator works but may be a solution that'd get around your issue. If diff ratio and tire SLR are EEPROM variables, then it seems strange that a tuner flash would be overwriting those registers. But I have no idea if a chip rewrite takes all values back to stock other than what was being issued. If that was case, it makes sense that each time you flashed from either Hypertech or HP Tuners that those variables were lost.

Is there anyone on this forum that has mapped CAN PGNs or knows what the ECM/BCM/ABS registers are?

 

I ran down the highway and calibrated with GPS speedometer on my phone. The "just put in your tire size" method will get you close, but you'll probably still be off 2-3 MPG.

More importantly, consider going with 5.29 gears with 37s if you want to keep decent drivability. No the gears will not fix your speedo.

 

The HyperTech and Rough County "Inline" Calibrators read the incorrect CAN bus signal for speed, does a conversion factor (based on your inputted new tire size ect), and then sends the newly corrected speed CAN signal to the Instrument cluster. It is a signal interceptor/converter. The rest of the CAN network is still seeing the old incorrect signal. MY question is if it is also correcting the Distance signal that increments the Trip and Odometer. I would assume so.

The Speed signal and Trip/Odometer signal are both broadcast by the Stability Control/ABS ECU. It reads the pulses from the wheel speed sensors, determines the Speed and Distance using math and sends these signals along the CAN Bus. The Cluster reads in the CAN signal, translates it and moves the Speedometer needle accordingly.

I am in the middle of a several month long project building a digital dash display that runs off the CAN Bus signals. I have been reading the CAN Speed signal and using it to run a digital speedometer for months with no problems. It runs very fast (about 33 updates per second) and very accurate.






For reference the instrument cluster, Speed, Tach, Coolant Temp, Trans Temp as well as almost all warnings, lights, ect are run on the CAN Bus.


"PIDs 12 and 13 in real time." Be careful here. Big difference between OBD2 protocol PIDs for diagnostic monitoring and actual addresses and locations of data on the CAN Bus.

(On-board diagnostics Parameter IDs) or PIDs are literally universal commands to send into the OBD2 port asking for a value (ex. Speed). The OBD2 sends a signal asking for the Speed and then has to wait for the ECU to read its request and reply with the value. Pretty slow process compared to internal CAN between the ECUs

 

Sent you a PM. Thanks for the input. Will go along with the original idea of an interceptor.

 

Got the interceptor working with the onboard RPi 4b and a dual channel CAN card. Cut into the bus at the cluster and sent that to the first channel. The premise is that the CPU filters all messages looking for the speed arbitration ID of 0x00B4. If found, the correction is applied, the message reconfigured, and then sent onto the second channel. If not, the message is passed unaffected onto the second channel. The code is not optimal as filtering is done within the software but I can tweak that as I learn the python-can library some more.

To trial I setup a second RPi 4b to listen to the second channel. The laptop shows a before and after with the above filter in place.

Going from OEM tires to 37" Ridge Grapplers, without a change in diff gearing requires a 12% bump. Checked this against phone GPS and a radar speed sign in my neighborhood.

Now for the bad news: permanent DTC of U0155 - lost comm with the instrument panel. I think this is happening since the RPi has a ~25sec boot. Time will tell if it resets itself. If not, anyone have any ideas? Only thing coming to mind would be a GPIO-driven SSR config which would be setup in a normally closed mode.

 

Nice work!

Just to clarify you are reading all CAN data in on channel 1 and passing it out to the cluster on channel 2. Between 1 and 2 the speed signal is corrected and sent out on 2 to the cluster.

The DTC is coming from the engine ECU because it can no longer sees the cluster. Remember the Cluster is considered an ECU also, not only does it receive signals but it also sends them out. Flip your converter so anything it reads coming into channel 2 (from the cluster) is sent out down channel 1 (to the rest of the truck). The cluster sends out 8-10 CAN addresses and none of them are making it to the network I would bet, so the the Engine ECU doesn’t “see” the cluster and creates the code. This data includes a low resolution speed signal, fuel tank level, and odometer. The cluster sends all of these to the main body and engine ecu as well as other data. This should fix the DTC issue.

As far as other warnings on the cluster during the 25 sec boot time, I would think you get some warning lights ect while waiting for the messages to start coming in on channel 2. In my experience if you go more than 2-3 seconds without an updated signal warning lights will come one. Even faster for ABS, VSC warnings from the skid control ecu.

However once your converter is fully booted and running it should turn all these off when signals start coming through after 25 seconds.

I had always thought to use an Arduino to do this since it has no boot time really. As soon as the key comes on data would be flowing down channel 2 into the cluster. Then you could just use the Pi to read the corrected data when it finally boots. Just a thought.

I am about to start building a CAN translator to run the 2018 cluster. I am thinking an Arduino to do the conversion with a CAN transceiver bringing data in and a second sending data out to the cluster only.

 

Some more thoughts on this.

Over the last few weeks I have decided that most likely a value programmed into the Skid control ecu determines the amount of wheel speed pulses per mile driven. Considering the tire total tire diameter of all factory 18,20 inch wheels is similar I think Toyota is using the same value for all trucks.

The Skid control ECU is what is generating the Speed, Trip/Odo CAN signals from the wheel speed pulses. The signals you are intercepting and correcting.

I need to go to my local salvage yard and buy and extra Skid control ecu. I have been reading up on ECU programming, security keys ect. If I can get into the flash memory, locate and change the value corresponding to number of pulses per mile, that will make the Skid Control ECU generate correct signals with no need for correcting down the line before the cluster.

Depending on tire size just flash in a new value for wheel pulses per mile and it’s fixed the “correct” way.

This is on my list of projects but I am not near knowledgeable enough yet to “crack” the ecu and read the programming file inside of it. Still would like to get one to start playing with.

 

This is correct. Looking at the pic, the truck side sends all bus data to channel 1 and the cluster side receives channel 2. The dash lights unfortunately do not turn off after boot. Reversing the order would still impose the same problem - missing node. But good tip on the cluster needing to communicate back to the bus. Will have to write in a filter allowing channel 2 to pipe to channel 1.

Agreed, this is a better job for a purpose built MCU but I don't believe there are any dual channel expansion boards. You could use two MCUs and link them through SPI/UART/I2C, but I'm still interested in having a CAN interface for other projects. An HVAC replacement with portrait screen would be baller.

Definitely pursue this because reflashing the register which holds tone ring pulse count for tire SLR to distance is exactly what's needed. My master locksmith buddy told me that TechStream does not have this as a parameter which is accessible. Apparently Toyota is the oddball in that category.

 

For this to work you have to have 2 way communication. You have to pass data across forward as well as backwards.

All data coming from the truck on channel 1 has to be passed to channel 2 into the cluster. Once the cluster sees the correct data from channel 1, coming in on channel 2, all the warning lights should go off. Make sure you are not loosing frames when moving from channel 1 to channel 2. You could also boot the PI first then turn the key on for testing purposes. Remove the delay time.

Also all data coming out from the cluster on Channel 2 has to be passed into channel 1 to the network of the truck. This will fix the DTC issue.

Obviously you will do the correction to the B4 address when going from channel 1 to channel 2 to the cluster.

If you get continuous flow of data forward and backward between channel 1 and 2 you should have no errors or warnings.

Also you could turn the key on, fully boot the Pi then plug the cluster into the factory harness. This would be a quick way to delay powering up the cluster until the PI is fully operational. For testing ect.

 

Jeff, thanks for the help. I setup two pipes, each on their own thread, cleared the codes, and everything seems to be ok. The catch is that the RPi has to be fully booted. If not, the codes show back up.

 

Kinda odd but keep playing with it. I know of my benchtop cluster when I power it on with no CAN signals being sent all the warnings light come on. As soon as I start sending correct signals they all go off.

I would think waiting for your PI to boot would be the same situation. As soon as it starts sending the correct data the warnings should go away.

For curiosity sake which warning lights come on and won’t go off?

 

Trac off and check engine stay lit. 4LO flashes.

I'll report back as I learn more.

 

Trac Off is CAN signal from Skid Control ECU, trying pushing the button on the dash to turn it on and off.

4Lo is CAN signal from 4WD Ecu.

Check engine light is a direct line from Engine ECU. It is not CAN driven. Once a code is thrown you have to reset it.

 

Built another board which is based around an IC with four SPDT relays. If the RPi hasn't booted yet, bus flow isn't intercepted. Upon boot, the dual channel CAN card is implemented as described above. No lights or DTCs with this setup.

Interestingly, I can turn the RPi off while the truck is running and the gauges will drop for a fraction of a second and cluster lights turn on, but then the ECUs realize they didn't drop a node, turn off the lights, and the needles bounce back as messages flow again. That behavior matches Jeff's description. There must be a missing node timeout implemented on the bus.

 

I’m not sure if it’s a missing node timeout as the cluster is collecting data from several nodes to run everything. For example the Skid control ecu node is speed, trip, abs warning lights ect. but RPM, Coolant Temp ect come from the Engine ECU node, while data from the body control node runs headlight, fog light indicators ect. These are just a few of the values the cluster is reading in.

I would describe it as the cluster “holds” data for a second or two for each gauge, if it doesn’t see an updated data packet it drops to 0 and assumes loss of communication.

I can send a speed signal to my 2014 cluster and the needle will hold that value for a second or two. If I do it on my 2018+ cluster it will hold it for 3-4 seconds, much longer. I assume Toyota adjusted the timeouts on the newer trucks as all data on them is run through a gateway and the Toyota Safety Sense ECUs greatly expanded the bus network. Significantly, like 2x, more data on the newer networks.

I think my 07 has 70 ish unique addresses on the CAN bus while I have seen 2018 Toyota logs with 150+ unique addresses

 

Did you go down the road of asking Hypertech why this is the case? Ever get any kind of answer? The Hypertech just reads in and modifies the Speed signal, I dont understand why people keep posting that it quit working when the truck was tuned.

When it quit, did it just pass the factory signal on to the speedometer?

 

No, never bothered contacting Hypertech.
Did it pass the factory signal? I would assume so (no way to confirm) because the speedo was way off (indicating the Hypertech was no longer applying the configuration I saved) and the HP Tuner doesn't have the capability to adjust speed.

But I did it a bunch of times thinking I missed a step (configured Hypertech, test drove to validate the speedometer, applied my HP tune, test drove again) and ended up with the same result. Since having the correct gear ratio, applied by the HP Tuner, was more important than correct speed I just left the Hypertech alone - it's still physically installed.

 

Yea if your speedo is still working it is still passing along the factory unmodified signal. What kind of crap code did hypertech write into these things. I am running into a similar situation where we made one very small change and the whole unit has now shut down and quit working.

I called their customer support and that was a huge waste of time... The concept here is simple, their execution of it not so much. Its becoming more obvious they have some kind of a check program to make sure the truck is "factory" or the calibrator will not work.

 

Interesting Jeff, any idea what kind of check for "out of factory" it would look for? Obviously that is a Hypertech question (I got the same response from them when I attempted to talk to them) but it could provide some clues as what I could be looking for.

Good read