MSP DisplayPort

Here is a link to the captured data from the VTX to the FC.
https://drive.google.com/file/d/1evsZUcbmtCOM8UjPP1muLUm6EyidVCz_/view?usp=sharing

not sure when I’ll have time to check this, but my first attempt would be to write a full debug version, a very verbose one for incoming and outgoing MSP traffic, which I actually did and should be somewhere deep i my github repos :slight_smile:

I will attempt this myself… I’m new to this code set and I have a simple question:
What is the best way to get debug data out ?

It looks like there is a hal->console
This is used by DEV_PRINTF macro…
docs say this goes to USB… yet I thought USB Was doing
MAVLINK <-> missionplanner

I’m confused…
How do I turn hal->console on and what is it connected to?

Or I could add logger->Write_MessageF and log data that way,
how do I get a pointer/handle to the logger from within the AP_MSP stuff?
(Is logger a global)
Are these functions thread/task safe?
Still digging in this code…

use hal->console, you see this type of messages using mavproxy printed on the main screen

So I’ve got diagnostic info coming out looks like its receiving Waaaay too many RX chars and
no complete packets… so will work on it some more this evening.

Is there a command line tool that will load code on the board?

Right now I’m launching mission planner and using the firmware settings update for every code change.

Thank you for that👍
I was not planning on using SA, just thinking that changes in that area of coding might have thrown some things up :crossed_fingers:

:grinning:

Yet more data…
The ftp get @SYS/Uarts.txt has a field that is supposed to be total number of chars recieved. On my platform this always reports 0.

So I fixed it and verified that it works.
I reported this as bug #20951 I described in that bug report exactly how to fix the issue. I earlier asked how to report bugs and someone was nice enough to post how to contribute… alas my experience with github is minimal and I have zero clue how to do several of the github operations in the directions… (See the discussion at the end)

Given that the instrumentation I put in and described in the previous post looks to be processing almost exactly twice the number of characters both transmitted and received per the uart.txt report. It continues to increment the chars processed count even though the rx count in uarts.txt goes to zero when disconnecting the VTX.

Discussion on contributing…
If someone wants to walk me through the process like I’m a 5yr old I’ll try to submit fixes instead of bug reports. The specific issues I don’t understand:

  • Commits should be in a new branch of your fork/clone (i.e. not “master”).
    Is this a branch on my local machine? (That I know how to do) or is this a branch that belongs to me but up on github if this is the case I have not idea how to do that.

  • The new branch should be up-to-date with [ArduPilot/master]
    rebase??? No clue exactly what rebase is /does???

Solved *

So I basically blew off work and chased this for 2 days.

From UartDriver.h
int16_t read() override;

In the
AP_MSP_Telmetry_Backend.cpp
const uint8_t c = _msp_port.uart->read();
So if you look at the core read code, there are a lot of cases where it returns -1
This misses it entirely…
And this is the core problem that confused me.

When it returns a -1 it does not actually read any chars from the rx buffer… so
the buffer fills up and it reads the max of 1023 chars EVERY time through the loop, only its not actually reading any of it, its processing -1’s.

In the int16_t UARTDriver::read()
It is failing the test:
( _uart_owner_thd != chThdGetSelfX())

So it thinks a different thread owns the uart.

Once that was resolved, there was also a change to msp.cpp
Inside
bool MSP::msp_parse_received_data(msp_port_t *msp, uint8_t c)
The spec says that the third char can be <,> or !
You only look for < the VTX (is correctly by spec) sending a >

case MSP_HEADER_M:      // Waiting for '<'
    if (c == '<') {

So if I change this to:
if((c == ‘<’)||(c==’>’))
VTX stick menu now works.
now one of my fixes was improper…
I just killed the thread check in the uart read…
This should probably be a differnt solution, but I don’t exactly understand the thread start up/system that yaapu/alex set up for the this code.

Hi, finally had some time to play with this.

I upgraded my TX5.1 kit to latest hdzero firmware Rev 11062022

I also created an MSP debug branch to dump the MSP traffic, it’s here GitHub - yaapu/ardupilot at pr/msp_debug

What I see (as expected) is incoming/outgoing traffic, I enabled all OSD panels so traffic is quite high, an example produced by this branch follows

MSP: recv hdr: '$' 'M' '<' 02 data:
MSP: send hdr: '$' 'M' '>' 0x04 0x02 data: 0x41 'A' 0x52 'R' 0x44 'D' 0x55 'U' crc: 0x04
MSP: recv hdr: '$' 'M' '<' 65 data:
MSP: send hdr: '$' 'M' '>' 0x16 0x65 data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 crc: 0x73
MSP: recv hdr: '$' 'M' '<' 69 data:
MSP: send hdr: '$' 'M' '>' 0x08 0x69 data: 0xDC 0x05 0xDC 0x05 0xDC 0x05 0xE8 0x03 crc: 0x53
MSP: recv hdr: '$' 'M' '<' 58 data:
MSP: send hdr: '$' 'M' '>' 0x00 0x58 data: crc: 0x58
MSP: send hdr: '$' 'M' '>' 0x01 0xB6 data: 0x02 crc: 0xB5
MSP: send hdr: '$' 'M' '>' 0x19 0xB6 data: 0x03 0x06 0x02 0x00 0x43 'C' 0x41 'A' 0x4C 'L' 0x49 'I' 0x42 'B' 0x52 'R' 0x41 'A' 0x54 'T' 0x49 'I' 0x4E 'N' 0x47 'G' 0x20 ' ' 0x42 'B' 0x41 'A' 0x52 'R' 0x4F 'O' 0x4D 'M' 0x45 'E' 0x54 'T' 0x45 'E' 0x52 'R' crc: 0x9F
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0A 0x00 0x84 crc: 0x36
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0B 0x00 0x84 crc: 0x37
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0C 0x00 0x84 crc: 0x30
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0D 0x00 0x84 crc: 0x31
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0E 0x00 0x84 crc: 0x32
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0F 0x00 0x84 crc: 0x33
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x10 0x00 0x84 crc: 0x2C
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x11 0x00 0x84 crc: 0x2D
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x12 0x00 0x84 crc: 0x2E
MSP: send hdr: '$' 'M' '>' 0x07 0xB6 data: 0x03 0x08 0x0D 0x00 0x26 '&' 0x7E '~' 0x27 ''' crc: 0xC8
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0B 0x00 0x1B crc: 0xA3
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0C 0x00 0x1D crc: 0xA2
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0D 0x00 0x1C crc: 0xA2
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0E 0x00 0x1D crc: 0xA0
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0F 0x00 0x18 crc: 0xA4
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x10 0x00 0x1D crc: 0xBE
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x11 0x00 0x1C crc: 0xBE
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x12 0x00 0x1D crc: 0xBC
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x13 0x00 0x1A crc: 0xBA
MSP: send hdr: '$' 'M' '>' 0x09 0xB6 data: 0x03 0x08 0x17 0x00 0x20 ' ' 0x20 ' ' 0x20 ' ' 0x30 '0' 0xB1 crc: 0x02
MSP: send hdr: '$' 'M' '>' 0x08 0xB6 data: 0x03 0x02 0x19 0x00 0xC0 0xD0 0x30 '0' 0x9A crc: 0x1C
MSP: send hdr: '$' 'M' '>' 0x09 0xB6 data: 0x03 0x03 0x17 0x00 0x20 ' ' 0x20 ' ' 0x20 ' ' 0x30 '0' 0x07 crc: 0xBF
MSP: send hdr: '$' 'M' '>' 0x09 0xB6 data: 0x03 0x08 0x02 0x00 0x49 'I' 0x4E 'N' 0x49 'I' 0x54 'T' 0xE9 crc: 0x45
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x11 0x02 0x00 0xE2 crc: 0x41
MSP: send hdr: '$' 'M' '>' 0x09 0xB6 data: 0x03 0x11 0x03 0x00 0x60 '`' 0x20 ' ' 0xC0 0xD0 0xA1 crc: 0x5F
MSP: send hdr: '$' 'M' '>' 0x08 0xB6 data: 0x03 0x09 0x18 0x00 0xA4 0xC0 0xD1 0x9F crc: 0x86
MSP: send hdr: '$' 'M' '>' 0x08 0xB6 data: 0x03 0x0B 0x18 0x00 0x20 ' ' 0x20 ' ' 0x30 '0' 0x25 '%' crc: 0xBB
MSP: send hdr: '$' 'M' '>' 0x08 0xB6 data: 0x03 0x02 0x0D 0x00 0x20 ' ' 0x20 ' ' 0x30 '0' 0xA8 crc: 0x2A
MSP: send hdr: '$' 'M' '>' 0x09 0xB6 data: 0x03 0x00 0x00 0x00 0xBD 0xBE 0xC0 0xD0 0x30 '0' crc: 0x9F
MSP: send hdr: '$' 'M' '>' 0x10 0xB6 data: 0x03 0x0D 0x09 0x00 0xA6 0x20 ' ' 0x20 ' ' 0x20 ' ' 0xC0 0xD0 0x30 '0' 0x30 '0' 0x30 '0' 0x30 '0' 0x30 '0' 0x30 '0' crc: 0x37
MSP: send hdr: '$' 'M' '>' 0x10 0xB6 data: 0x03 0x0E 0x09 0x00 0xA7 0x20 ' ' 0x20 ' ' 0x20 ' ' 0xC0 0xD0 0x30 '0' 0x30 '0' 0x30 '0' 0x30 '0' 0x30 '0' 0x30 '0' crc: 0x35
MSP: send hdr: '$' 'M' '>' 0x01 0xB6 data: 0x00 crc: 0xB7
MSP: send hdr: '$' 'M' '>' 0x01 0xB6 data: 0x04 crc: 0xB3
MSP: send hdr: '$' 'M' '>' 0x01 0xB6 data: 0x02 crc: 0xB5
MSP: send hdr: '$' 'M' '>' 0x19 0xB6 data: 0x03 0x06 0x02 0x00 0x43 'C' 0x41 'A' 0x4C 'L' 0x49 'I' 0x42 'B' 0x52 'R' 0x41 'A' 0x54 'T' 0x49 'I' 0x4E 'N' 0x47 'G' 0x20 ' ' 0x42 'B' 0x41 'A' 0x52 'R' 0x4F 'O' 0x4D 'M' 0x45 'E' 0x54 'T' 0x45 'E' 0x52 'R' crc: 0x9F
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0A 0x00 0x84 crc: 0x36
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0B 0x00 0x84 crc: 0x37
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0C 0x00 0x84 crc: 0x30
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0D 0x00 0x84 crc: 0x31
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0E 0x00 0x84 crc: 0x32
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x0F 0x00 0x84 crc: 0x33
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x10 0x00 0x84 crc: 0x2C
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x11 0x00 0x84 crc: 0x2D
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x08 0x12 0x00 0x84 crc: 0x2E
MSP: send hdr: '$' 'M' '>' 0x07 0xB6 data: 0x03 0x08 0x0D 0x00 0x26 '&' 0x7E '~' 0x27 ''' crc: 0xC8
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0B 0x00 0x1B crc: 0xA3
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0C 0x00 0x1D crc: 0xA2
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0D 0x00 0x1C crc: 0xA2
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0E 0x00 0x1D crc: 0xA0
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x0F 0x00 0x18 crc: 0xA4
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x10 0x00 0x1D crc: 0xBE
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x11 0x00 0x1C crc: 0xBE
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x12 0x00 0x1D crc: 0xBC
MSP: send hdr: '$' 'M' '>' 0x05 0xB6 data: 0x03 0x03 0x13 0x00 0x1A crc: 0xBA
MSP: send hdr: '$' 'M' '>' 0x09 0xB6 data: 0x03 0x08 0x17 0x00 0x20 ' ' 0x20 ' ' 0x20 ' ' 0x30 '0' 0xB1 crc: 0x02
MSP: send hdr: '$' 'M' '>' 0x08 0xB6 data: 0x03 0x02 0x19 0x00 0xC0 0xD0 0x30 '0' 0x9A crc: 0x1C

so to recap I do not see anything unexpected,

regards,

Alex

The problem on my setup was two fold…
The chibios uart driver requires the uart be opened or initialized in the same thread as it’s read. It was not. Also as your debug shows the vtx sends < and the msp parser expected a > both fixes described above. In your setup are the received packets parsed (not just displayed?). Either your on a different code base or I suspect they are not… Made a pull request with the fixes as pbreed you can find changes details there…

Note osd worked, but fc was never seeing/responding to vtx requests so vtx stick menu did not work. With my fixes it does.

Hi Paul,
my dump shows a system with full working OSD so packets are shown and parsed.
You see both MSP commands and MSP displayport packets, the former are a request + response, the latter are packets sent without being asked by the VTX.
I’d like to reproduce your issue which currently I cannot.
Could you run my debug branch against your HW setup and post you msp traffic?
In my testing I don’t see reversed direction headers, VTX sends ‘<’ which is expoected by the ArduPilot parser and FC sends ‘>’ on response.

Alex

I’m away from my ability to test things this week. Won’t be back till mid next week. Are you doing this on chibios platform?

On matek h743 zero chars we’re ever rxed as read was failing with -1 due to owner thread not matching current read thread.

Once I fixed that it rejected packets from vtx until I added ‘>’ to line 180 of msp cpp

I was using freestyle 1w vtx and I’m 100% positive it was failing the parse. Your rx shows < which would have worked…I was seeing > so maybe that is a vtx code error…

In any case it was 100% working now with those two fixes…

Paul you are right, thread ownership was wrong, thanks for catching this!
I’ll make a PR and reference the issue you opened!

But you really must have a VTX that outputs reversed direction headers :frowning:

BTW: the fix unlocks high definition fonts I made for ArduPilot that are now part of stable hdzero firmware, so double thanks :slight_smile:

this is the proposed fix

I see you were using an older firmware rev 2203022 vs 11062022, before reaching hdzero for a solution could you flash your VTX with the newer version? Reversed MSP header really lloks like a firmware bug

Yes I started this before 6/11 so was using the latest version, will try the next version late next week…

@yaapu Sorry for late replay, email notification ended up in Spam. I linked to the code for the official sources of the names for MSP DisplayPort and Canvas APIs in my original post.

Some history:

MSP comes from MultiWii, later used by Cleanflight and Betaflight and I was involved with the development team when the MSP DisplayPort mode was added, by @jflyper if memory serves correctly.

Canvas API is a much more recent development. Original implementation was by @fiam for iNAV and BetaFlight. I was working with @fiam after I noticed the OpenSource iNAV-OSD project, but he was offered a job to work for FrSky. We both developed PixelOSD hardware systems at the same time. I had working prototypes of the SP Racing PixelOSD about 2 weeks after he started work on the FrSky PixelOSD system and then later ported my solution into the H7 boards. I waited for his Canvas API support to be published and then wrote the support for the SPRacing PixelOSD system for Betaflight. Around the same time the SP Racing PixelOSD system was also used by FlightOne in the H7Lightning flight controller that I designed for them, but that does not support any Canvas API modes.

ok?

Thanks Domicic, now it’s clear :slight_smile:

Arduplane Stable 4.22 with this settings:

OSD_TYPE = 5
SERIAL5_PROTOCOL = 42
MSP_OPTION = 5

OSD works. But no stick commands. Mode 2 is set on the transmitter with inverted pitch.

Who has working stick commands?

Hi Reinhard,
yes, that’s a known bug and… my fault :frowning:
There’s a pull request to fix stick commands, i’ts here you will need to build it though.

Alex

You make so many beautiful things, a few bugs are forgiven … :wink:

Is this in the master for 4.3? Or can I get a firmware for F765-wing based on 4.2.2 stable?