ArduPilot / ArduPilot/MAVProxy

mavproxy 'no link'

Open
#25 5 comments 2 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
595
Forks
773
Avg merge
2d 6h
Merged PRs (30d)
18

Description

Is this likely to be a bug in mavproxy or its host or AP?

Im bringing up a new port of AP to flymaple. AP is latest git version. mavproxy talks happily to the new port but at apparently random times loses the link:

RTL> no link
link 1 down
no link
.... repeated forever.....

and prints no more data from the AP, although I can stlll get a prompt from mavproxy.

In that state:

I can see serial data on the serial line still coming from AP to the host (FTDI USB-serial). The mavlink host (OpenSuSE 12.3) reports no errors with the USB port, but at the time the link is lost the mavproxy log file mav.tlog.raw stops being appended.

I can see on the serial line heartbeats still being transmitted by mavproxy.

Killing and restarting mavproxy (without doing anything to the AP) brings the link back to life. It might run OK for up to 10 mins again before losing the link again.

I know its possible there is something wrong with my flymaple port, though
interestingly, when connected to MissionPlanner 1.2.79 on a PC, connected with the same FTDI cable, the mavlink connection will stay up forever. And the fact that the flymaple is still producing a stream of serial data after mavproxy thinks it sees no more data is compelling, as is the fact that stopping and restarting mavproxy also fixes it.

Could of course be an OpenSuSE USB-serial driver problem, though I have not seen similar problems with serial-USB FTDI dongles before.

This seems like mavproxy is not receiving any more chars from the USB-serial port. Ring a bell with anyone?
Anyone else running it OK on OpenSuSE 12.3?
I cant see any debug options in mavproxy to help diagnose this.
Suggestions?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the intermittent link loss with MAVProxy on OpenSuSE 12.3, using the FTDI USB-serial setup and observing mav.tlog.raw. Compare the failing MAVProxy session with the stable MissionPlanner connection and the serial data and heartbeats described in the report. Done means isolating whether the failure is in MAVProxy or the host/USB-serial path and recording enough diagnostic evidence to act on it.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.