Repository navigation
Add MSP2_COMMON_SERIAL_INJECT to feed raw bytes into a serial port over MSP - #12141
Draft
MartinovEm wants to merge 1 commit into
Draft
MartinovEm wants to merge 1 commit into
MartinovEm wants to merge 1 commit into
Conversation
New MSP message 0x1010. It takes a serial port identifier and up to 191 bytes, and puts the bytes into that port's receive buffer as if they came in over the wire. All or nothing. It refuses closed ports, the USB VCP and ports read through an RX callback like serial RC receivers. With no data it only checks if the port can take bytes. The X-Plane HITL plugin uses it to send ADS-B traffic to a MAVLink port over USB. Unit test, msp_messages.json 2.1.3 and the regenerated MSP README included.
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #12141 251 targets built. Find your board's
|
Contributor
|
tested over hitl, works nicelly, just aircraft type is not sent in ADSB message, but it's up to x11 HITL plugin. MSP2_COMMON_SERIAL_INJECT works 
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds one new MSP message, MSP2_COMMON_SERIAL_INJECT (0x1010). You give it a serial port and some bytes, and INAV puts the bytes into that port's receive buffer as if they came in over the wire, so whatever reads that port sees them as usual. The main use is testing ADS-B in HITL. INAV takes traffic only as MAVLink ADSB_VEHICLE on a serial port, but the X-Plane HITL plugin talks to the FC over USB, so today a second cable and a USB to UART adapter are needed to get any traffic in. With this message the plugin sends the traffic over the USB link it already has. The plugin side is RomanLut/INAV-X-Plane-HITL#38.
How it works
The payload is the port identifier as one byte, the same identifier MSP2_COMMON_SERIAL_CONFIG reports, followed by the raw bytes. MSP's input buffer is 192 bytes, so that leaves up to 191 bytes of data per message. It only goes one way, the reply is an ack or an error and nothing else.
It's all or nothing. If the port isn't open, doesn't receive, or its receive buffer can't take the whole block, nothing is written and the FC answers with an error. The USB VCP is refused because it has no software receive buffer, and so are ports read through an RX callback, which means serial RC receivers, the CRSF sensor port and the head tracker, since those parse in interrupt context. The one exception is a receiver set to MAVLink. INAV takes RC_CHANNELS_OVERRIDE from any MAVLink port, so with that setup injected bytes could carry RC, just like any other MAVLink sender on that port.
Sending only the identifier with no data is a probe. It checks that the port can be fed, and an INAV without the message answers it with an error, which is how the plugin detects support.
There's no new state, buffer or setting. The bytes go into the same ring buffer the RX interrupt fills, so it's meant for a port with nothing else connected, otherwise the injected bytes would get mixed with the real ones. Everything after the identifier is payload, so the message can't get new fields at the end later, a future variant would need a new ID. 0x1010 is the next free ID after MSP2_COMMON_GET_RADAR_GPS on maintenance-10.x, maintenance-11.x and master.
RAM and flash
Measured against maintenance-10.x (3f9fde4) with the same toolchain. RAM doesn't change on any of the three targets. Flash goes up 176 bytes on MATEKF405 and 80 bytes on MATEKF722. On IFLIGHT_BLITZ_H7_WING the image came out 240 bytes smaller, which is just LTO laying things out differently, the new code itself is about 90 to 180 bytes. The size report the bot posted below compares against an older commit (e87050f, six commits back), so its numbers come out a little different.
Testing
There's a new unit test for it covering the fill, the wrap around, all or nothing, the refusals and the probe, and the whole suite passes, 627 of 627. The three targets and SITL build with warnings as errors, msp_messages.json is bumped to 2.1.3, the MSP README is regenerated and check_msp passes.
On SITL it was also driven by a small MSP script. The probe gets an ack, blocks of 156 and 185 bytes (the sizes the plugin sends) are accepted, INAV counts 7 ADSB_VEHICLE and 1 HEARTBEAT and lists the aircraft, a closed port gets an error, and a 193 byte frame is dropped without a reply while the link keeps working.
With X-Plane 11, LiveTraffic and the plugin PR on SITL, the real aircraft show up on the Configurator GPS tab and match a live tracking site, and INAV's ADS-B warning works too. So far it has only been tested on SITL. HITL on an H743 wing comes in the next few days, and this draft will be marked ready for review after that.
To test it, flash the test firmware with Full Chip Erase, set a free UART to MAVLink telemetry on the Ports tab (nothing connected to it, not shared with MSP or a receiver), turn on the Telemetry feature and save. Then put the Windows plugin from the test build for RomanLut/INAV-X-Plane-HITL#38 in the plugin's 64 folder, connect as usual and pick Send X-Plane traffic as ADS-B in the Traffic menu. With the ADS-B warning and ADS-B info elements switched on in the OSD tab, the traffic shows up in the OSD the plugin draws in X-Plane, and in SITL also on the Configurator GPS tab.
The real aircraft in the screenshots come from LiveTraffic with the Bluebell CSL models, see its installation guide and the Bluebell step by step. LiveTraffic puts them into X-Plane's TCAS list and the plugin passes them on like any other traffic, while X-Plane's own AI traffic works without anything extra.