-
Notifications
You must be signed in to change notification settings - Fork 35
mwp multi procotol
Unmaintained Article Please check the manual for more up-to-date information.
mwp supports a number of different data transports for "serial" protocols:
- Real serial devices (USB TTL (VCP) etc.)
- Bluetooth
- IP (UDP and TCP)
- "Special" (e.g. BulletGCSS via the MQTT protocol).
Each of these requires a specific device name and may require a protocol selection.
Serial devices are defined by the operating system device node name and optionally include an embedded baud rate, for example:
# Linux, USB seral
/dev/ttyACM0
# Linux, USB serial with baud rate
/dev/ttyUSB0@57600
# Linux, RFCOM Bluetooth
/dev/rfcomm1
# FreeBSD
/dev/cuaU0
Bluetooth may be specified by either an rfcomm
device node (/dev/rfcommX
) or by the device address (Linux only):
# BT RFCOMM device node
/dev/rfcomm1
/dev/rfcomm1@57600
# BT device address (note here baud rate is immaterial)
35:53:17:04:07:27
mwp uses a pseudo-URL format for TCP and UDP connections udp://host:port
and tcp://host:port
(where host
is either a hostname or an IP address as required).
Typically on one side of the connection you'll provide a hostname /IP and on the other you won't (as it can get the peer address from the first data packet).
Assuming the required UDP port is 43210
if mwp is the "listener" (doesn't need, a priori, to know the address of peer), set the "Device" to:
udp://:43210
i.e. the host part is empty.
If the remote device / application is the listener, and we know its IP address; in the following example "192.168.42.17", set the "Device" to:
udp://192.168.42.17:43210
Note that for TCP, mwp only supports the latter form (it expects to be the TCP client).
See the mwp's MQTT support article for a detalied desription of the URI format:
mqtt://[user[:pass]@]broker[:port]/topic[?cafile=file]
As WSL does not suport serial connections, mwp provides a bespoke serial / UDP bridge using the pseudo-device name udp://__MWP_SERIAL_HOST:17071
. See the WSL article for more detail.
From 4.317.587 (2021-11-21), mwp does away with some of the weirdness around serial protocols (e.g. having to separately specify --smartport
in order to use S-Port telemetry).
Instead, there is now a protocol drop-down that allows the user to select the in-use serial protocol.
Offering:
Item | Usage |
---|---|
Auto | Auto-detects the protocol from the serial data stream. Note that MPM cannot (yet) be auto-detected reliably, and must be explicitly selected). |
INAV | INAV protocols, MSP, LTM and MAVLink. Legacy behaviours |
S-Port | Smartport telemetry, previously required --smartport options. Expects a non-inverted stream |
CRSF | Crossfire Telemetry. |
MPM | Multi-Protocol-Module telemetry. The output from an EdgeTX / OpenTX radio with a multi-protocol module, FrSky Smartport or Flysky 'AA' via the EdgeTX / OpenTX "Telem Mirror" function. Is not auto-detected, must be explicitly selected. |
- For radar functions (inav-radar, ADSB), it is necessary to set the
--radar-device=
. Leave the protocol selector at 'Auto'. - For telemetry forwarding, it is necessary to set the
--forward-to=
. Leave the protocol selector at 'Auto'. - For FlySky MPM telemetry, the inav CLI setting
set ibus_telemetry_type = 0
is required; any otheribus_telemetry_type
value will not work.
- INAV (MSP, LTM, MAVLink) auto-detection should be reliable (legacy function).
- S-Port and CRSF may be less reliably detected.
- MPM is not auto-detected. This may change if EdgeTX merges an extant PR
- It is recommended that for S-Port, CRSF and MPM, the desired protocol is set explicitly (not left at "Auto").