Andrew: Flow control right now is slower than plain log download. But with flow control it can be faster. Peter: But that means that there’s no standard path for log download. A: Yes, we’ll need to wrap around it.
Some optimizations can make the parameter download 650kB/s, log download 400kB/s, in CubeOrange in MAVProxy and Linux.
In Windows USB packet loss causes a lot less throughput. Probably due to the USB driver in Windows.
People welcome to test it and report back. If you get a message mentioning retries, then there’s packet loss.
MAVProxy is slightly faster than Mission Planner.
It’s very hard in Windows to test non-signed drivers. Sid: PPP is a good workaround, probably getting ~900kB/s.
Another bottleneck may be the SD card read.
P: Are there downsides to increasing the transfer size? A: Haven’t tested it thoroughly. Perhaps in non-flow controlled connections you might write more before you realize you lost data.
UTC0725
S: When you have more than 4 compasses then weird things can start to happen. Upon reboot, a configured compass might go missing.
When using DronCAN and a mag that is out of the priority list goes into the list, then the autopilot gets confused.
Tested with 5 DroneCAN mags and the 1 internal.
A: Why do we need to have DroneCAN as a special case in allocation still? S: DroneCAN is special because it can do allocation during runtime, not just during startup. P: By the way, we have run out of bus types. A: If we are flying and then discover a new mag, will the order change? S: No, because you will stop registering new devices once you find all your tracked compasses. And you can’t arm before you find all your configured compasses. A: But people force-arm all the time. S: Yes, in this case there might be suprizes. A: Ah, we’re not doing compass detection once we’re armed, that’s good to see.
This PR is quite complex. I agree with its need, but I can’t follow it now. We can discuss another time.
UTC0759
Approved and merged!
UTC0801
Approved!
UTC0804
A: Do both DCM algorithms produce TAS?
Yes, they both do.
Approved!
UTC0814
P: We’ll need Randy to approve of it.
It refactors and pushes a lot of gimbal functionality to the respective backend, as there was a lot of code duplication in the individual drivers.
A: LGTM. P: The issue is that we’re delaying David Sastre’s PR with all these preliminary PRs. A: We can try to fast-track it by puttin his gimbal PR on top of this one.
UTC0820
A: I’m fine with these changes.
UTC0832
P: If we add the new define in a different place, then you don’t need to go out of order in the disovery.
And it will prevent screwing up your board with making the internals appearing before the externals.
Andy: Okay, I’ll give it a shot.
UTC0841
Approved and merged!
UTC0843
Approved!
UTC0844
A: Is it possible to have the hwdef.py change separate so that we can check for no code-change? P: I tried to, but it was very hard and complicated, it wasn’t worth it. A: You could change master hwdef processor to not process any baro lines. Then make your new hwdef not parse any baro lines. Then we can compare the output binaries, to ensure that only baro generation is affected by this PR.
UTC0858
P: This PR allows custom messages to be forwarded through the autopilot. A: Does this mean that someone can use this to circumvent signing, especially for MAVLink peripherals? P: Agreed, let’s not ignore BAD_SIGNATURE.