Hey guys, is there a way to read in single-precision float values from a CANbus message? I have no issues reading unsigned and signed integers but can’t figure out how to read float values.
Obviously DBC files don’t natively support floats but Holley ECU’s use floats exclusively so being able to read those float values would be great. Apologies if I missed something in the software for this
Hi,
in the dbc file u usually set a factor for a signal. E.g. factor 0,1 then means the raw hex number needs to be multiplied with 0,1 that u get the physical value. With this u sent float values with any precision on CAN.
Hi,
There is a CANX file for Holley that you can import into the project tree.
Holley is not using single-precision floating point numbers.
They use fixed-point numbers, where 24 bits are for the integer, and 8 bits are for the fraction.
In most cases, we can ignore the fraction part, which means the first byte is not used. Now, we have 3 bytes as an integer, but since most values will fit in 2 bytes, we can ignore the last byte. That’s how we created the CANX file to read Holley CAN.
Holley’s “Holley Standard” aka HEFI (not Racepak) uses big-endian 32bit values that are encoded single-precision floats; I would know as I reverse engineered their device firmwares and prompted Holley to publicly release a DBC (and a matching tech document that confirms their message format uses floats)
I see the ‘number’ and ‘function’ sections of the PMU software but can’t figure out if there is a way to do bitwise math - is that available in the PMU-16?
Ok, I see.
So, we have the CANX file for the Racepak, not the standard Holley.
PMU doesn’t have support for 32-bit numbers, and there are no bitwise operations.
Why do you want to use the standard format and not the Racepak?
The full “standard” format has about 500 signals (on the Dominator ECU), including dozens of ECU-controlled input and output channels, whereas the Racepak format only has about ~20 of the most common sensor values. With the “standard” format it would be possible to have the Holley ECU and the PMU work a lot more closely together than with Racepak.
The recently-released Holley DBC’s are here: https://documents.holley.com/techlibrary_holley_efi_can_information___dbcs.zip
but they have some minor inaccuracies (I’m working with Holley to get them to fix those) but should be a good start.
I would suspect that with Holley’s release of this info that Holley+ECUMaster PMU will be a more common combination soon, perhaps you guys can look into adding support for floats, I’d be happy to beta test
We have a CAN system that can receive float numbers in EMU PRO.
We plan to move that system from PRO to PMU, but it’s a big task and not a high priority, so there is no timeline.
Another thing is that there is basically no demand regarding Holley.
People are moving away from Holley because of the company politics.
And most people who use it are not really interested in PDMs or custom CAN buses.
We are not interested in changing development priorities to accommodate Holley devices that intentionally make CAN communication difficult. The same goes for FuelTech.
Thanks for the message; it sounds like Holley has a new head of their EFI products division who is an active race driver himself and he seems like he wants to shed their old reputation. Releasing the DBC files and full details of their protocol was a first step to that end, I would say.
I’d love to be on the list to beta test the eventual software release because for now the PMU-16 I bought last week isn’t much use to me without the ability to read float values. If there was an option to do bitwise math it would at least allow us to calculate the values ourselves; for now I think I will see if I can build an approximation table to calculate the exponent and mantissa using the arithmetic functions that the software currently has.
Is there any documentation on the file format ECUmaster uses for the PMU or similar so that I can attempt to auto generate all of the value fields/tables instead of adding them by hand in the software?
We talked about it, and we can pretty easily add float decoding, but the final number will be clamped to 16-bit in some way. We don’t have support for 32-bit numbers, which is the most significant change we would have to make to get full support.
We added that to the list, but there is no timeline yet for the new PMU version.
We make posts here for every official and beta release.
All the newest beta versions can be downloaded from here:
https://www.ecumaster.com/testVersions.html
Project files are zip-compressed XML files.
We don’t have documentation we can give you.
Since you know your stuff about computing, I think you can understand it by playing around.
You can unpack the project file, make changes, and open it directly in the software. You don’t have to compress it again.
Remember that you are doing it at your own risk, and we can’t provide support for a custom approach like that.
Excellent! Perhaps you could use a float16 (half precision float)? That would require just extracting the sign, exponent, and mantissa bits from the 32bit float value, subtract 115 from the exponent, and truncate the mantissa into 10 bits and then you can calculate the a float16 value without having to do any 32bit math.
I’ll keep an eye on the beta releases 
thanks so much!
Every CANbus Input is represented in the PMU and ADU as a Singed 16-bit integer with 0, 1, 2, or 3 decimal places.
We will add the decoder for float32 that will set 1000 if you receive the 1.0 value (for decimalPlaces=3). It will be relatively easy, as we have IEEE-754 float32 support in our CPU. So we don’t need to work on the bits.