ArduPilot / ArduPilot/ardupilot

MAVFTP very slow over Ethernet when using CubeOrange with PPP and CubeNodeETH

Open
#29,673 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
15.9k
Forks
21.4k
Avg merge
3d 17h
Merged PRs (30d)
119

Description

When both NET_P1_TYPE and NET_P2_TYPE are set, parameter downloads are very slow. If NET_P1_TYPE is set to zero, parameter downloads are extremely fast.

I'm not yet sure of which component is wrong but I have this setup:

- CubeOrange with PPP enabled connected to a [CubePilot CubeNodeETH](https://ardupilot.org/copter/docs/common-cubepilot-cubenodeeth.html#common-cubepilot-cubenodeeth) and then connected to a [BotBlox switch box](https://botblox.io/switchblox-for-ardupilot/).
- CubeNoteETH is using IP 192.168.144.14
- CubeOrange is using IP 192.168.144.15
- NET_ENABLE = 1
- NET_OPTIONS = 1 (EnablePPP Ethernet gateway)
- NET_P1_TYPE = 1 (UDP Client)
- NET_P1_IP01,2,3 = 192.168.144.25 (for siyi)
- NET_P1_PORT = 37260 (for siyi)
- NET_P1_PROTOCOL = 8 (gimbal)
- **NET_P2_TYPE = 2 (UDP Server)**
- **NET_P2_IP0,1,2,3 = 0.0.0.0**
- **NET_P2_PORT = 14560**
- **NET_P2_PROTOCOL = 2 (MAVLink2)**
- PC also connected to the BotBlox switch box with IP address set manually to 192.168.144.99

With both Mission Planner and MAVProxy parameter downloads are very slow.

When testing with MAVProxy:

- added link, with Connection Type = "udpout", IP:Port = "192.168.144.15:14560"
- "param fetch" took 22 seconds between, "Requested parameter list" and "Received 1183 parameters"

For comparison the same parameter download over a USB cable took less than 2 seconds.

CubeOrange is running a recent version of 4.7.0-dev, "ArduCopter V4.7.0-dev (e2fc648c)"

Contributor guide

Open the contributing guide

Research direction

First reproduce the slowdown with NET_P1_TYPE and NET_P2_TYPE enabled, using MAVProxy's "param fetch" over 192.168.144.15:14560, then compare it with NET_P1_TYPE set to zero and the USB result. Trace the MAVFTP/MAVLink path involved in the PPP Ethernet gateway and determine which component causes the delay; done means parameter downloads are fast with both network settings enabled.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
embedded-iot, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.