Yes, I was planning to do that too if nothing else helps. Maybe it’s working for everybody else because I’m the only one who upgraded from last weekend’s ‘test’ version to the release version, while everybody else started with that version from scratch.
The fonts that are part of the wtfos repo are all blocky/pixelated and look like they’re all made for SD resolution
The color HD fonts in the ardupilot repo are much, much better, but have issues.
Issues/questions:
-
There is for some reason a tiny 3.1 that is used as a placeholder for spaces or something
-
Why doesn’t power in Watts work anymore? (Nothing appears in the spot where it is supposed to be)
-
Why doesn’t cell voltage work anymore? (Nothing appears)
-
What is the point of effective milliamp hours? I’m trying to find an efficiency metric like watts per kilometer. Does something useful, like watts per kilometer exist?
-
The message field is stuck displaying “Sending unknown message (5”
-
Nothing appears for “sidebars”.
-
Is there also another color HD font that is a good alternative to the color HD font in the ardupilot repo?
There’s an issue with the font aknowledged by the author, he’s updating them, you can find them here
David did you read the wiki about the different types of MSP OSDs?
The DJI FPV Goggles support 2 kinds of MSP OSD, the “standard” one which renders on screen using an internal engine, so it reads raw telemetry data and draws using DJI widgets/panels, so for instance watts are not a raw telemetry data, the goggles multiply instant current*instant voltage.
The other type is the hacked one, the goggles do not read telemetry data but work as a big text framebuffer, ArduPilot draws on screen via MSP, OSD panels are the same as analog built-in ones, so whatever you can get from your matek765 analog OSD you can get on the DJI goggles via MSP DIsplayPort.
Questions about individual OSD panels is a bit OT here, perhaps you can raise an issue on the discord osd channel or better on github if you suspect a bug.
In the meantime I updated, reinstalled WTFOS, anything I could think of - still stuck with one refresh per 1-2 mins and missing items. I went on their Discord and one of the guys said something about messages with bad checksum potentially being dropped, leading to slow refresh.
Apparently at the moment there is no log of those on the goggles that could be checked - which might change, as recording the data on the goggles in order to later ‘burn it’ into the video is on their to-do-list.
The guy mentioned bad serial wiring as a potential cause for bad checksums, but I never had a problem with the standard OSD. Will check the wiring, but I’m 99.8% sure it’s ok.
ouch… debug will be hard
so whatever you can get from your matek765 analog OSD you can get on the DJI goggles via MSP DIsplayPort.
Why are the metrics I mentioned in the previous post dependent on the flight controller model? For example, cell voltage can easily be obtained by dividing the pack voltage by the number of cells that ardupilot is already aware of. That should work, right?
The same logic goes for the other metrics I mentioned. Ardupilot can calculate them on the flight controller and send them, using serial 5 my case, to the fpv air unit, which then sends that data the goggles. The goggles then take that data, use the font supplied, and render the canvas. Why does that have anything to do with with what my particular flight controller model’s analog OSD may or may not support? Seems irrelevant.
Seems aggressive, right? Did you notice that in most of your posts you sound like a disgruntled customer who didn’t get what he paid for? Only you didn’t pay anything. People are providing all of this for free, so in my opinion that tone is not appropriate.
Anyway, of course there are differences between the values different FCs can provide to any type of OSD, as there are differences between the values it can detect. Some boards have no current sensor, no baro etc.
1 Like
yes UnknownPilot,some people expect every thing done for them and then criticise,I am am grateful to people that help me and have so much respect for the developers,they keep this old man well amused tinkering with Ardupilot,long live the developers and those that help on here
2 Likes
This isn’t the case for the questions in my earlier post. MSP protocol support - #794 by David82
I feel like I put a lot of effort into explaining detailed issues that can be improved upon, (or corrected on my side, if there is an issue,) but the questions were just briefly skimmed over, or not read fully, and a generic answer was given that doesn’t speak to the level of detail I originally provided, or misunderstands the questions entirely.
I’m making no assumptions as to why these metrics seem broken, but the proposal that all or most of the missing metrics are the fault of the FC doesn’t hold up to any scrutiny.
Cell voltage, for example, is just a division of the pack voltage by the number of cells. That is one of the metrics that stopped being displayed. Same idea for the other missing/broken metrics. Watts for example is based on the already known amps, and the already known pack voltage. There is no missing data stopping watts/power from being displayed.
Hi David,
I guess I didn’t do a great job at explaining the way MSP DisplayPort works 
ArduPilot, just like INAV, Betaflight and many others as a matter of fact do, has a native driver for the onboard analog OSD chip that many FC have, the difference between the onboard OSD and for instance the DJI FPV one is that OSD data is drawn straight on screen (actually it’s an overlay) without the need to setup a serial port for the telemetry stream, it’s all built in.
When you activate MSP DisplayPort ArduPilot will use the very same code to draw on your DisplayPort OSD so whatever you can get with the onboard OSD you can get it with MSP DisplayPort, this is the point I wanted to make in my previous answer.
All this is explained in the official documentation here and that’s why I asked if you did read it.
So back to your questions:
2. watts are not supported by onboard OSD (unsupported by DisplayPort as well)
3. cell voltage is not supported by regular OSD (unsupported by DisplayPort as well)
4. this is what the onboard OSD provides (mirrored by DisplayPort) if you have a feature request for the onboard OSD please raise it on github (DisplayPort will inherit the new feature)
5. no clues, this sound like an issue on your side
6. they should be there, I do not use them and they might require a build time option
7. the best font IMO is the one we included in the docs we pointed you at
3 Likes
Thanks for replying and going into detail.
There’s one concept I don’t get, or is missing, after reading the docs. Can’t the goggles, in MSP displayport mode, display whatever text is sent to it? ← If that is true, can’t ardupilot extract data from whatever sources it needs to, before sending that data to the air unit, which relays that same info to the goggles? Why do we care about the FC’s onboard OSD? Aren’t we sending text to a text buffer, which has nothing to do with the FC’s onboard OSD? If so, we can get data from whatever sources we want, and additionally make any custom data (like watts per km), and send that to the goggles. If not, specifically, technically, why not?
you’re welcome.
Yes, but to minimize code duplication (or maximize code reuse) the functions used to draw on the DisplayPort OSD are the same used by the analog OSD except that the screen is remote rather than local. So technically possible but not a good solution on a resource constrained device such as a FC.
To add new panels to the ArduPilot OSD (whatever gets added to onboard OSD will be added to DisplayPort as well) you should open a new feature request on our github to trigger discussion with the devs and the community whether the new panel is usefull/needed. The rationale for adding new code varies but a new panel also requires new parameters which in turn require more flash space which as already pointed out is “at a premium”
I think that now the picture should be quite clear!
Thanks for confirming my suspicions that the missing OSD elements are merely the result of an artificial/invented limitation.
There is already an efficiency metric.
Displays flight efficiency (mAh/km or /mi)
I was using this, but wasn’t sure what it was really measuring until I found the documentation on it. Of course watts/km is much smarter than mAh/km.
There are hints of the existence a wh/km metric here in ArduConfigurator/messages.json Does a wh/km OSD element actually exist?! If so, how do I enable/use it?
1 Like
No. Smarter would be only Wh/km, because only that is comparable with different batteries (3S, 4S, etc.).
Yea, that’s what I said. 
Been tracking this for a while now and got it working with ease. Awesome work and finally! Is there a way to adjust the OSD screen in MP so that the elements are somewhat where they should be on the DJI goggles? Right now if I want an element in the center of my goggles, I have to drag it almost off the right side screen. Same goes for top/bottom. Thanks!
You can use the X/Y fields to push them to any point, even outside the range of screen, or just wait for MP to be updated to reflect the larger grid (check for beta updates).
You can push through MP by overlapping them. Drag and overlap.
Thanks. I just tested it and that font is better.
The “Sending Unknown Message (5” issue is still there, and it is not just me. You can see the same issue in @macfly1202 's screenshots as well.
“Senidng unknown message” it’s unrelated to MSP DisplayPort, you get the very same message in mission planner and onboard OSD, I don’t know when you would get it, need somebody to jump in and clarify. It’s not an “issue” is probably a misconfiguration or a message during autopilot initialization, but only wild guesses on my side. Open a dedicated topic and ask what’s the meaning of that message and when is does occur