CUAV V6X board support

[davids5]

Continuing #19750 here.

Rebased on current master.

[bmeagher]

@davids5 I believe your proposed change for the RM3100 self test bug does not address the fundamental problem with the current self test implementation. The software timeout needs to be greater than what is programmed into the RM3100 BIST register (0x33). The current implementation sets the BW and BP bits to all 1's (the maximum value). This equates to a timeout value of 480us (4 sleep oscillation cycles per LR timeout period and 4 LR periods for BIST) according to the latest published datasheet. Currently, the driver is waiting 26ms (2*RM3100_INTERVAL) which is significantly longer than required. See pull request #19583 for a proposed fix to address the RM3100 self test failures. I’d be interested to know if my proposed changes address the RM3100 self test failures you are experiencing on your flight controller.

[davids5]

@davids5 I believe your proposed change for the RM3100 self test bug does not address the fundamental problem with the current self test implementation. The software timeout needs to be greater than what is programmed into the RM3100 BIST register (0x33). The current implementation sets the BW and BP bits to all 1's (the maximum value). This equates to a timeout value of 480us (4 sleep oscillation cycles per LR timeout period and 4 LR periods for BIST) according to the latest published datasheet. Currently, the driver is waiting 26ms (2*RM3100_INTERVAL) which is significantly longer than required. See pull request #19583 for a proposed fix to address the RM3100 self test failures. I’d be interested to know if my proposed changes address the RM3100 self test failures you are experiencing on your flight controller.

@bmeagher - Thank you! This was not my work, just a continuation of a PR I could not write to.

@mxiaogit Let's drop 8ea548d and when #19583 comes it will be fixed

[mxiaogit]

@davids5 I believe your proposed change for the RM3100 self test bug does not address the fundamental problem with the current self test implementation. The software timeout needs to be greater than what is programmed into the RM3100 BIST register (0x33). The current implementation sets the BW and BP bits to all 1's (the maximum value). This equates to a timeout value of 480us (4 sleep oscillation cycles per LR timeout period and 4 LR periods for BIST) according to the latest published datasheet. Currently, the driver is waiting 26ms (2*RM3100_INTERVAL) which is significantly longer than required. See pull request #19583 for a proposed fix to address the RM3100 self test failures. I’d be interested to know if my proposed changes address the RM3100 self test failures you are experiencing on your flight controller.

@bmeagher - Thank you! This was not my work, just a continuation of a PR I could not write to.

@mxiaogit Let's drop 8ea548d and when #19583 comes it will be fixed

@davids5 Yes, we can delete it.

[davids5]

@mxiaogit - I have dropped that commit and rebased on current master.

[cuhome]

@davids5 Pixhawk V6X kit will include CAN PMU Lite, can you enable Dronecan battery monitor by default?

[davids5]

@davids5 Pixhawk V6X kit will include CAN PMU Lite, can you enable Dronecan battery monitor by default?

@cuhome Please do a PR against this PR and test it.

[dagar]

You want to backport this for v1.13.1?

[davids5]

@dagar - was in the middle of testing and had 2 meetings. I Give me a bit....

[davids5]

Well good news it works

[davids5]

@dagar I do not have time to do the back port do you?

[cuhome]

@dagar @davids5 This pr was not merged into the newly released 1.13.1stable, but was merged in 1.13.0master, can you please help me?

[mrpollo]

@dagar @julianoes can you help me get this PR into 1.13 please?

[julianoes]

The v1.13.2 has been released but I have no objections to a v1.13.3 once more backports like this one are in.

[mrpollo]

@julianoes we need to make sure things like this don't slip from releases, there doesn't seem to be any process for that currently

[julianoes]

I don't have the overview of all these things and what needs to be backported, sorry.

[cuhome]

@davids5 @dagar How should we deal with it?

[mrpollo]

@cuhome we are working on a point release for your hardware

[dagar]

I'm verifying things here.

[cuhome]

@dagar Thanks, when there is no gps positioning, the wrong altitude (>1000) (local_position_ned) appears.

[cuhome]

[mrpollo]

@cuhome there's a PR for this #21765