- Software
- IQANdesign
-
Questions
Packing huge (uint32) numbers into J1939 CAN
One of our IQANs is doing math with GPS coordinates, and broadcasts the resulting latitude/longitude over J939-CAN. However, we can't pack it properly. Most likely due overflowing a Float or Signed Int32 value.
According to the J1939 guidelines (, Longitude/Latitude are ought to have a scale of 0,000 000 1 (thus 7 decimals), and an offset of 210. This results in huge numbers. They fit in a UINT32 type, but I suspect IQAN juggling them between either float or signed ints, losing a few bits. Smaller inout numbers like 5,1234567 would work, but higher numbers get trashed.
We could reduce the scale to 6 decimals, but in our case we need the very last centimeters for a precission system, so that's not really an option. Plus we'd like to stay close to the J1939 standard. Other suggestions?
Customer support service by UserEcho
I can't find a previous post I was going to reference. I had to use a GPIN(type INT) instead of a JPIN(Type Float) when reading a large number off the CAN.
Thanks for your help
Tried it, but ran into another problem. Since GPOUT (sending in this case) do not have an offset/scale, I still need to use a (int)Math block first to pack the value. The math block screws up the value as well, probably again because its not a UINT32.
Can't test it with a real IQAN now, but maybe the GPOUT "fixes" this anyway when set to unsigned. But in the simulator, the GPOUT still gets a negative value strange enough.
The channels in can IQANdesign only have the value types 32-bit real and 32 bit singed integer.
Even when you set a GPOUT type to unsigned integer, the channel value in IQANdesign will still be a 32-bit signed.
If you have the GPOUT set to e.g. 2-bytes unsigned and feed it a negative number, the check for calculation overflow will detect it, give an error status on the channel and set it to zero.
But when the output length is also 4 bytes value, the GPOUT check for calculation overflow won't catch this, so the value will be sent out without change.
Which means the modules listening on the bus can read the 32-bit value and interpret it as intended.
(on a GPIN, you'll get a project check warning if you try to set unsigned 32-bit)
Also see feature request:
https://forum.iqan.se/communities/1/topics/387-handling-huge-unsigned-int32-numbers