These are chat archives for dronekit/dronekit-android

29th
Feb 2016
WickedShell
@WickedShell
Feb 29 2016 07:22
@ne0fhyk I've run into a problem which seems to be related to mavlink/mavlink@88c648e where the upper nibble of uint32's are parsed incorrectly (ie onboard_control_sensors_health in sys_status). Before the parsing code changed to this version it worked but after the change it stopped interpreting the upper nibble correctly. Do you have any idea why these changes could have broken it/why were they needed?
Fredia Huya-Kouadio
@ne0fhyk
Feb 29 2016 07:31
@WickedShell not sure why the changes would have broken the parsing. Along these changes we also added codes to auto-generate unit tests to validate the parsing.
@WickedShell the test should attempt to validate the parsing.. could you take a look and see which part it's missing. We can use that to isolate which part of the parsing code is not working as expected.
WickedShell
@WickedShell
Feb 29 2016 07:43
@ne0fhyk Yeah I'm doing a quick bisection to verify that is the exact commit thats causing me problems, (it is the major commit between the dates I updated my jars) but I do need to show exactly which it is
WickedShell
@WickedShell
Feb 29 2016 08:59
@ne0fhyk It's fine until that commit (I did have to add the same fixes from mavlink/mavlink@4412c47 but I just wrote them in without pulling the commit)
I haven't cloned dronekit android as I'm using the java stuff elsewhere, but if the test is passing then I think it might be a case of bad data in bad data out.
With the commit I can't get the upper nibble correct on the uint32's
IE connect to a plane and print the onboard_control_sensors_health in sys_status on the as parsed as well as from something like mavproxy you will see an error
WickedShell
@WickedShell
Feb 29 2016 09:05
What should be a value of 3275823 is parsed as 16776239 (this is by using the same tlog)
Which leaves me worried about all the other uint32's we parse...