Closed stronnag closed 2 years ago
+1 Maybe it would also be possible, to use the USB-Serial port as the connection to the PC/GCS ?
Looks good to me ! Current code should comply with that, with the limitation that MSP_NAME is truncated to 6 chars, because OLED. MSP_STATUS and _BOXIDS are not used, and I added a check to not MSP_RAW_GPS a GCS.
About the serial over the USB port, it's on the to-do list. It was in there at some point, a long time ago, aswell bluetooth, but I removed it all because that's what I do, remove things :)
Olivier, sure that MSP_STATUS is not used for GCS? In 2.0, the check is still curr.host != HOST_NONE
rather than curr.host == HOST_INAV
(src/main.cpp#940), unless I'm not seeing some prior if(){}
.
So it's still asking for ANALOG and STATUS, neither of which are relevant to a GCS.
Olivier, sure that MSP_STATUS is not used for GCS? In 2.0, the check is still
curr.host != HOST_NONE
rather thancurr.host == HOST_INAV
(src/main.cpp#940), unless I'm not seeing some priorif(){}
.So it's still asking for ANALOG and STATUS, neither of which are relevant to a GCS.
you're 100% right, forgot this one, I force-pushed the fix, the check is done at 944, in the next IF
This RFC summaries chat discussion on the above.
Some users may wish to connect a GCS (Ground Control Station) to an inav-radar node in order to view cooperating aircraft. Currently this is somewhat possible (e.g. https://github.com/stronnag/mwptools/issues/90) but is sub-optimal from both sides:
This proposal seeks to address these issues whilst maintaining a degree of integrity to the connection.
direction
flags are concerned.MSP_FC_VARIANT
with the "GCS" (e.g. 0x47, 0x43, 0x53, 0x0)MSP_NAME
: The GCS should provide an identifying name within MSP limits (16 octets).MSP_FC_VERSION
: The GCS should provide an identifying version (3 octets, e.g. 0x06, 0x06, 0x06).MSP_STATUS
MSP_BOXIDS
MSP_RAW_GPS
MSP2_COMMON_SET_RADAR_POS
messages.