Using Arducopter 4.1.0-dev. The Link Stats in MP shows the following:
Is this normal, especially since the connection is over USB? Shouldn’t the quality be 100%?
Setup:
Thanks!
Which serial port? Is it serial 0 ?
Thanks for the report. Could you clarify where you’re seeing this? I’m afraid that I don’t look much at the telemetry quality. Is it this number displayed at the top right of the HUD? Seems like you have more information than just this simple number…
Ah, after a chat with @meee1 I’ve found what you’re looking at. there is a little “Stats…” label near the connect button. My stats look better when using a CubeOrange connected through a USB cable.
I guess we now need to try and narrow down where the difference is coming from. If you pull up the MAVLink Inspector from Setup>> Advanced screen do you see just two components or perhaps more?
Yes, it is Serial0 (USB)
There is also a discrepancy between the number shown in the HUD and the “quality number” shown in the Stats window. Not sure how they are related.
According to @meee1 the difference is that the percentage shown on the HUD is, “just the item you’re connected to” while the “Stats…” percentage is “all on the link”.
I would have guessed that you’ve only got on thing on the link so I can’t explain why they are different.
I can imagine two possible things:
I wonder if you could try reverting to 4.0.7 to see if the issue is new to 4.1 or an existing issue? Beyond this I suspect I need to ask @peterbarker and @meee1 to run point on this issue.
I’ll add it to our 4.1 issues list so it’s not forgotten.
Wow, this is a very active forum (sorry, an arducopter newbie here). Thanks for all the prompt replies and willingness to help!
I actually started with the “stable” version of the firmware for H743 (firmware version 4.0.7-FIRMWARE_VERSION_TYPE_OFFICIAL), and it had the same behavior – everything seemed really sluggish over USB and the “quality” percentage was below 50%; which I found interesting, hence my attempt to switch to a newer firmware hoping to take advantage of any recent optimizations ;).
Is there any logging that I may be able to look at to see if this is indeed a serial buffer issue?
Any chance you could provide a short-ish tlog? To keep it short I would shutdown MP and then start it up again and connect to the autopilot. open the link status window to confirm you see then problem, then shut down MP and get the latest tlog out of the mission planner’s log directory (for me this is C:\Users<username>\Documents\Mission Planner\logs) and post it here. If you’re uncomfortable providing it on the forums then you could PM it to me and/or @meee1.
P.S. there isn’t really anything very secret in the log beyond where the vehicle was tested.
Did a bit more digging and wired up the PDB, ESCs, and telemetry radio. Interestingly, when I now connect to the UAV remotely via the SiK radio, the quality stays at 100%. So the SiK connection seems to be more reliable than the USB connection! Super odd, but alright…
OK, I guess that’s good news. If you see it again and can produce a tlog then we can investigate further. txs for testing out 4.1!
@rmackay9 Thanks, I have PM’ed you a tlog for this issue. It only occurs when connecting to the UAV through its USB-C connection. For now I will stick with connecting via the radio.
@meee1 had a look at the log and it does seem like messages are being lost. He thinks that this means it is not an MP issue but rather an AP flight code issue. He also found that there were a lot of these pre-arm errors indicating IMU resets were happening.
INFO MissionPlanner.CurrentState - messageHigh PreArm: Internal errors 0x1000000 l:168 imu_reset
There are other reports of this imu reset happening with Matek boards so this may be the underlying issue.
We can actually see the message peeking out from behind the “Link Stats” image you’ve posted above… so I think on the AP side we should try and get to the bottom of these Mateksys board IMU resets and then ask you to re-test with a USB connection. I guess on your side if these imu resets don’t always happen you may be able to confirm that the two issues always come together.
Txs for the log and report!
@rmackay9 You are welcome, and don’t hesitate to reach out if I can further test any proposed fixes for this.
BTW, as far as I can see, the imu_reset “internal errors” occur every 20-30 seconds irrespective of whether I connect through USB or radio. (sorry about the cross-thread reference, I already have an active thread on imu_reset).
Thanks again!!
starting to work with mavlink i had some problems getting things working. turned out that (part of) the problem was caused by transmission errors.
at the end i wrote the image transmission tool (i wanted to write) in a way that it can also write packet logs that allow me to analyse transmission errors. analysis is done in a jupyter notebook.
you can have a look at it at https://gitlab.com/rm/mavmit .
it’s far from ready and perfect but maybe can help find some problems.
