MSP DisplayPort

Thanks for the logical suggestion but it still does not work.
I flashed INAV onto the quad, to check the hardware, and that worked OK, (OSD and stick menu) selection, so it’s looking as if the hardware is all good.
I’m flashing back to Arducopter as this is my preference.

I’d be grateful for any solutions please.
Woud also like to know if anybody who has the OSD working also can use stick commands

Thank in advance
Steve

Hi, I do, and I can get into the VTX menu by inverting pitch, my radio is in mode 2 so I invert the right stick.

Hmm. back to the bench for me then :smile:
I’m changing the TX to the Race V2 and will try it again with Arducopter.
Will post the outcome :crossed_fingers: :crossed_fingers:

1 Like

@yaapu

I’ve changed the HDZERO VTX, Race V2 behaves exactly as the TX5M.1
i.e OSD: Yes, VTX menu access: No :frowning_face:

I’m running ‘latest’ Arducopter Beta version 4.2 RC1 but just noticed that RC2 has appeared today. However looking at the revision notes there is no mention of my problem.

My FC is Matek 405-STD
I have the following attached to the ports:
SERIAL1 RX3/TX3 Mavlink telemetry back to GCS via Crossfire
SERIAL2 RX4/TX4 GPS, Ublox, BN220
SERIAL3 RX1/TX1 RC control, Crossfire
SERIAL4 RX5/TX5 HDZERO VTX
SERIAL5 RX2/TX2 not used

The SharkByte receiver menu, in the ‘about’ tab, says communication error, suggests check RX/TX swapped etc. and this system does not support Soft-Serial.
My connections are good (independantly checked) and I’m not using Soft-Serial.

I may have mentioned previously I temporarily moved the VTX to SERIAL1 but no difference.

I’m at my max skill level now on this. :grinning:
Hope somebody can solve this please

Thank you Steve

Other thing I meant to mention…
Without ‘seeing’ the FC it doesn’t know when it’s ‘armed’ so it stays in LP mode :frowning_face:
Will have to turn LP mode off and watch the heat before flying

1 Like

Hi guys, just a quick question. When gathering info for my upcoming first DJI HD Ardu-build, I came across this sentence:

  • OSD_TYPE = 3 (only required to obtain statistics information panels). Can be set to 1 if autopilot has integrated analog OSD to use that feature in addition to the MSP OSD feature for DJI goggles.

Is it really somehow possible to use analog OSD (from the chip on FC) and MSP OSD (DJI HD) at the same time, and if yes, how exactly does this work?

I’ve trying out a BNF BF copter so far with DJI Goggles, just to test the whole thing. The limited OSD (few items, no font options) on BF really is one of the only things I don’t like about digital FPV.

Hi, analog + DJI is supported, @hwurzburg flies an analog + DJI OSD setup so we better ask him for insight!
I did submit a pull request to add “explicit” support for dual OSD like DJI + MSP but it’s not merged (nor planned) yet

Yes, you can have both at the same time…set internal osd like normal and a serial port for protocol 33 for the goggles…however,you will need to use different screens for each since the layout will probably need to be different unless very simple since dji goggle location are not same as normal analog display…ie. you will probably need to change screens when looking at one or the other

Thanks a lot! Still curious how this works… I always thought the analog cam signal goes into the FC, on which the OSD chip adds the analog OSD, and then the result goes out to the VTX. In this case, is the “output” from the OSD chip somehow routed to the serial port the digital cam/air unit is connected to and “imprinted” onto the video signal, in addition to the DJI OSD? And if that’s indeed possible, why don’t they do it on Betaflight as well?

Two separate systems…DJI goggle"custom osd" is takes serial data messages and creates the display overlay in the goggles

Ah now I’m beginning to understand, so the DJI “custom OSD” is essentially generated on the ground from telemetry that is passed along with the digital video signal, correct? So the font size/type could only be changed in the goggles, provided DJI made it possible.

But how can the analog OSD chip be used on the digital video? Excuse my persistence, but I’d really like to understand how this works (in layman’s terms).

The analog OSD chip only produces analog video overlays which are fed to the analog video transmitter

I see, so you’re actually using an analog VTX along with the digital VTX, and the wiki entry simply refers to both being editable at the same time?

So far I was assuming DJI HD wipes out all competition on the 5.8Ghz band, no matter what channel it is set to, and especially in HQ mode. But I’m really still a beginner at digital FPV.

In any case, analog people I used to fly with now refuse to take off as long as I have the digital VTX on. :wink: There’s always some interference it seems.

I have exactly the same problem as StevieGeek above…
OSD works, stick menu does not. and YES I have tried the pitch stick inverted.
(I actually tried all 16 combinations of AETR inverted/normal.)
Also with the 1W HDZERO Vts my rang is not good so I suspect its staying in low power mode.

This is MatekH743 wing and HDZERO.

I’ve set:
MSP_OPTIONS,5
OSD_TYPE,5 --Above in this thread says 5, docs say 3 for MSP, but with 3 OSD does not work.
OSD_OPTIONS,1
SERIAL4_BAUD,115
SERIAL4_PROTOCOL,42
SERIAL4_OPTIONS,0

1 Like

General comment this topic is not supposed to be for debgging…
Alas when I search for debugging info on this problem it takes me to this thread…
I can move it to arduplane 4.2 if requested, alas I think the issue effects all variants.

I have a bunch more info …
I hooked up a serial monitor to the RX and TX to/from the VTX.
I wrote some code to do a crude decode of the MSP going back and forth…
The FC only sends : MSP_DISPLAYPORT and MSP_FC_VERSION messages.

The VTX sends a bunch of
MSP_FC_VARIANT
MSP_STATUS
MSP_RC
MSP_VTX_CONFIG
MSP_FC_VARIANT
Requests. None of which are EVER answered by the flight controller.

I verified by oscilloscope probing the actual pin on the FC board.
that the VTX serial tX signal is getting to the FC pcb RX pin.

Its almost like the recieve process for MSP is not running or otherwise misconfigured?

Checksums all computed correctly and the FC and VTX messages had opposite <>.

I can build ardupilot locally, but have not yet tried to install a locally built image on the board. Still using the officially released one. Can share configs or any other info.

I guess next step is to modify the build to spitout logs or messages on correct MSP receive. Any other ideas?

@pbreed @Steviegeek can you post the exact VTX/VRX firmware and board version you’re using?
All I have is a TX5M.1 which is the board I did all the dev/testing with, I can try to replicate you’re setup with the same firmware with my HW but that’s about all I can do

Hi Alex,

My testing was on a HDZERO Freestyle VTX, (the metal cased 1W unit)
It was ‘unlocked’ for maximum power
If you wish I can send you one.

Firmware was rev. 22032022

Freestyle VTX - HDZERO_TX.bin (56.8 KB)

Receiver was also rev. 22032022

VRX unit has PCB revision REV2R2
VTX has no revision markings, unless the Model number HDZ3130 signifies something.

Thank you for your interest in solving this, it is much appreciated
Steve

Yesterday i was given beta firmware version 01062022
I will try this today/tomorrow and advise if any change to this issue, maybe the reference to smart audio will have an impact (point3 below) ??

image

Also the 1W VTX with the latest public firmware. REV2203022
I’m using a matek F743 V3 wing. MatekH743_4_2

The VTX is sending properly formatted requests the FC is ignoring them.
Using TX3, RX3 which according to the matek document is Serial4.
Tried setting RXpull down and Rxpull up (not at the same time ) in serial options.
No change the FC is still not responding to the VTX query.

So I suspect this is a serial receive issue.

I can send you the log of data sent by the VTX and you could try injecting into a serial port and seeing if the FC responds?

I’m thinking I’d add counters in msp.cpp to count chars processed in :
bool MSP::msp_parse_received_data(msp_port_t *msp, uint8_t c)
and
Full packets processed in the process command stuff…

What is the best way to put this info in the Log?
Or to send it out serial console of some sort?
IE how does hal->console get setup and assigned to a specific port?

Steviegeek… the smartaudio for Ardupilot has compiled in VTX table that is not compatible with HDZERO.
So do not use or enable smartaudio…your frequency will be off…