Ardupilot: Telemetery radio loses link

[rscarawa]

Issue details

Telemetry radio stops communicating. It is inconstant when it happens. Many times the link breaks when I push the safety button to arm the plane. I would say it breaks the link about 50% of the time when I arm it. When the link breaks, I can see that either the heart beat remains or reestablishes. When the link breaks, the FC still seems to function.

I did a test this afternoon trying to pin point which hardware has the problem. After starting the board up and getting a link, I pulled power from the radio, leaving the FC powered up and functional. After MP indicated the link breakage, I powered the plane's telemetry back up and MP then re-established the comm link. I ran the same test again with the same results. As luck would have it, the link broke about 30 seconds later. At that time, the heartbeat was still active. I pulled power from the telemetry radio. After 10 seconds plugged it back in. Heartbeat established but no communication. That leads me to believe that there is a problem on the FC board with communication. Any idea why this would be? Is there a communication buffer that manages data flow to the various UART devices? Is it possible that a buffer was either corrupted or over flowed? This is extremely annoying as it requires me to power down the FC in order to get the telemetry working again.

Version

3.5.3 SIK 1.9

Platform

[ ] All
[ ] AntennaTracker
[ ] Copter
[ x ] Plane
[ ] Rover

Airframe type

Flying wing

Hardware type

Airbot Px4 Mini AIO

Logs

let me know where to get the logs, if any should exist.

[magicrub]

check dropped packets count & rate in MP. Try reducing StreamRate to send less data. Try the latest release v3.6.0

[rscarawa]

Since I am using a PX4 Mini AIO board, I need to use a customized software due to it having no internal compasses. There is a configurability in the custom code that allows all compasses to be external. Does 3.6 have this feature rolled into it? What is the attribute name I need to track in MP?

I would hate to reduce stream rate considering how slow the data rate is now. it takes about a minute for the board to do its initial config load when connecting to MP via radio link. Is there something that leads you to believe that the problem is with the communication between the two devices? If the link is going to drop, it typically happens when pushing the safety button to arm the board. No motor or servos running at that time. I have seen it fail more than three times in a row right when pushing that button.

[magicrub]

customized software, surely the manufacturer supports their own product. Try checking with them.

[rscarawa]

well, they are limited in their expertise. I do not think it is from the manufacture either. I think it is someone who just has an interest in making it work.

Is there a buffer that manages communication with the telemetry radio?

[rscarawa]

The person who hacked the code to allow for the all external compasses says he will do the same for the arduplane 3.6 code. Will see eventually if this fixes the communication issue.

[magicrub]

have that person contact us about submitting a pull-request.

Try reducing StreamRate to send less data.
What are your stream rates now? 1 minute connection time means you've got something wrong.

check dropped packets count & rate in MP.
What are these numbers?

surely the manufacturer supports their own product.
have you contacted the manufacturer? We don't like supporting other people's hardware who don't contribute to the project in any way. If they don't want to help you then you need to remember that next time you're shopping for hardware.

[lvale]

@magicrub I believe that fix has already been merged. This is a support case that has already generated some conversations at RCG.

[rscarawa]

I did comment on RCG but not sure it has been fixed. The person who had the code hack released a 3.6 version but it seems to still have the problem. I noticed that the initial variable load on connection is faster but I had the whole system lock up when I touched the elevator while MP was receiving its load from the FC via telemetry radio. It was so bad that I had to reload the firmware. When it locked up, it would not complete a boot cycle. How can that happen?

[magicrub]

Summary:
-someone made a pixhawk clone
-someone made proprietary changes to the open-source codebase to get that clone to work but we don't know what the changes are and there has been no attempt to add those changes back to the codebase.
-have problems with the clone with the custom firmware and you come to the open-source developers who don't know anything about this custom firmware instead of the guy who broke it.

My summary: please see your manufacturer for support. Have a nice day.