UINT32 parameters lose precision when written

[tenchirocom]

Issue details

MP->component transmisssion of uint32 parameters lose precision during paramet set. It seems it's actually getting converted to a floating point number somewhere along the way. For example:

60180513 gets to the component as 60180512.

Similar such experiments seem to alter the 8th digit. No problems with 7digit numbers, which would be expected behaviour with at float conversion problem.

Interesting that component->MP sees to work fine. That path seems okay. The initial read of 60180513 will display properly in the parameters list. But writing it back will corrupt it.

The mavlink interface in the component is just memcpy the message, no byte swapping is being used on component side.

The paramtype is correctly set as 5 in the parameter set message.

Thank you.

Version

1.3.77, build 1.3.8110.38294

Platform

[ ] All
[ ] AntennaTracker
[X] Copter
[ ] Plane
[ ] Rover
[ ] Sub

Airframe type

n/a this is a peripheral component

Hardware type

Custom ESP32 based 191 onboard computer attached to Holybro PX4 fmuv7

Logs

Please provide a link to any relevant logs that show the issue

[tenchirocom]

One more thing, MP doesnt seem to catch the mistake. The parameter display will continue to show the incorrect number, even though the corrupted number is emitted back. It seems the internally stored number that checks for changes has already been corrupted even though the UI still shows the intended value.

[meee1]

do you have a tlog of the communications?

[tenchirocom]

These are the ones from today. Thanks.

[meee1]

thats just the images, need the tlogs as well

[tenchirocom]

I get the message "We don't support that file type."

[tenchirocom]

2022-06-15 tlog 1.zip

[tenchirocom]

2022-06-15 tlog 3.zip

[tenchirocom]

There was another today, but it's too big. 36mb. Github won't let me upload it.

[tenchirocom]

tlog 1 is a quickie I just did with a param write to the component. Hopefully that has what you need. I think tlog 2 is my morning tests. Thank you for taking a look.

[tenchirocom]

These last two in the zip I just made with the full round trip. I had to reset the component back to default to get the component->mp success scenario, since I cannot set the parameter correctly afterwards. That's the first log. Then the second we see correct value from comp->mp and corrupted value from mp->comp. Look at parameter CH_16SRSS_FCODE. The default is 60180503. It comes across the wire comp->mp, and is displayed correctly in MP. Then I just write it back (after selecting the parameter so it gets flagged for write, and press write). It arrives at the component as 60180504, not 60180503 like it should be.

I did some testing this afternoon with different 8th digits. It always gets changed to either 0,4, or 8 for values 0-9.

Again, thank you. Nice program.
tlog mp-comp-mp rt.zip

[magicrub]

@tenchirocom Most mavlink params are transmitted as 232 floats, which gives 24bit integer precision. Which param are you having a problem with?

[tenchirocom]

Good morning. The parameter in the log is CH_16SRSS_FCODE. This is an on-board computer code, not an autopilot parameter. So it wouldn't likely be familiar. Is it being passed as or just packed as float? If the latter, then all should still be okay when unpacked. If the former, then MAV_VAR_UINT32 would be an inaccurate specifier.