Any plan for supporting DJI Goggles 2 canvas mode?

[donne1226]

I wanna switching from v1 to Goggles 2

[FlyChenPiPi]

The canvas mode of INAV6.0 does not work properly when using DJI Goggles V2 with O3 air unit

[b14ckyy]

its not canvas mode. It is MSP-Displayport. DJI names it wrong there causing lots of confusion. What did you set up in ports? If it works as expected then you should only enable MSP-Displayport in the Peripherals column on the UART. Do not enable MSP on the left column.

[OlivierC-FR]

its not canvas mode. It is MSP-Displayport. DJI names it wrong there causing lots of confusion. What did you set up in ports? If it works as expected then you should only enable MSP-Displayport in the Peripherals column on the UART. Do not enable MSP on the left column.

I tried that 5 mins ago, does not work, there's no OSD in my Goggle V2.
The O3 only display on OSD the few datas for the video link (bandwidth, LQ), and the battery voltage it's connected to.

For clarification, here talking about brand new V2 goggles (not G2), no rooted, flashed with newest (official) firwmare so they can connect to the O3 air unit also with newest firmware.

[FlyChenPiPi]

its not canvas mode. It is MSP-Displayport. DJI names it wrong there causing lots of confusion. What did you set up in ports? If it works as expected then you should only enable MSP-Displayport in the Peripherals column on the UART. Do not enable MSP on the left column.

I tried that 5 mins ago, does not work, there's no OSD in my Goggle V2. The O3 only display on OSD the few datas for the video link (bandwidth, LQ), and the battery voltage it's connected to.

For clarification, here talking about brand new V2 goggles (not G2), no rooted, flashed with newest (official) firwmare so they can connect to the O3 air unit also with newest firmware.

Yes, I tried 5.1 and 6.0 but could not display OSD information normally. The OSD working mode of O3 seems to be only compatible with Betaflighe4.3, which caused a lot of trouble for my remote FPV UAV.

[donne1226]

its not canvas mode. It is MSP-Displayport. DJI names it wrong there causing lots of confusion. What did you set up in ports? If it works as expected then you should only enable MSP-Displayport in the Peripherals column on the UART. Do not enable MSP on the left column.

I just ordered it today, and I will try it out when I got it.

[OlivierC-FR]

Obviously the topic is rather wide, and not limited to the initial title, there's many different kind of goggles (V1, V2, G2, rooted and WTFOS, not rooted, etc), there's the new O3 air units, the old AU/Vistas etc, maybe we should make a whole new topic for clarification. Also, in some cases/combos the solution is only in DJI hands, not INAV side.

[brousselle]

I also followed the exact same way and tests as @OlivierC-FR but with the new Googles 2.
And i confirm there is no OSD.

[b14ckyy]

Then I have no idea. This O3 stuff and Goggles 2 is brand new stuff. DJI didn't gave a sh** in the past about INAV. I wouldn't be surprised if it is the same here.
although MSP-DP is standardized for the 3 existing systems, maybe they messed up the implementation for O3, who knows.

[MrD-RC]

It's likely DJI need to implement the font. But I'd have thought you'd at least get weirdness in the goggles. Either way. I feel at this stage it's something that people should be complaining to DJI about. We know MSP DisplayPort is working. Even with an old firmware on Avatar, I got glitching OSD characters.

[OlivierC-FR]

At least the MSP for arm is going through, the O3 detects the arming and react accordingly by starting and stopping the onboard recording, but the MSPs about the OSD are not ok obviously

[b14ckyy]

At least the MSP for arm is going through, the O3 detects the arming and react accordingly by starting and stopping the onboard recording, but the MSPs about the OSD are not ok obviously

When people talking about MSP its always confusing. You are NOT supposed to use MSP if they use the same OSD type as wtf.OS, Walksnail and HDZero.
send a screenshot of your ports tab please.

[claudiozavagno]

I can confirm that the dji O3 unit gets the arm input, starting the recording, if i set the peripheral as dji fpv vtx but also if i set the peripheral as HDzero VTX. Enclosing the port screen. No OSD on either, though. I am not using the DJI unit for rc control, only for video link. Goggles 2.

[OlivierC-FR]

At least the MSP for arm is going through, the O3 detects the arming and react accordingly by starting and stopping the onboard recording, but the MSPs about the OSD are not ok obviously

When people talking about MSP its always confusing. You are NOT supposed to use MSP if they use the same OSD type as wtf.OS, Walksnail and HDZero. send a screenshot of your ports tab please.

Can't SS right now, MSP is not enabled on the left-most column, here talking about the column Peripheral set to MSP displayport.
As Claudio said above, setting to DJI FPV or HDzero also trigger a response of the O3 to arming-disarming actions.

See the SS in this parallel topic I made, with Betaflight 4.3.2, only checking the MSP column is enough to get the OSD :
#8596

[b14ckyy]

@OlivierC-FR if for betaflight enabling MSP is enough, then they do NOT use MSP Display Port.
It looks to me like they use the MSP Canvas that was already used in the old DJI system.

In this case Preipherals have to be set to DJI and not to MSP-Displayport/HDZero VTX and the old DJI hack has to be used.

[OlivierC-FR]

@OlivierC-FR if for betaflight enabling MSP is enough, then they do NOT use MSP Display Port. It looks to me like they use the MSP Canvas that was already used in the old DJI system.

In this case Preipherals have to be set to DJI and not to MSP-Displayport/HDZero VTX and the old DJI hack has to be used.

Ok I'm digging this way now, I see BF has bumped their API minor to 45 instead of 42, maybe that's only that, and/or the FC identifier, will make a build later today

[claudiozavagno]

Don't know if it can be of any use but setting msp on data column gets the arm reaction from the O3, exactly as setting hdzero or dji fpv on the peripherals column. Still no osd though.

[MrD-RC]

That will be an MSP connection, not a DisplayPort connection. DJI has never been set up like that on INAV. For the DJI port, MSP in the column should be off. Then in the last, peripherals, column. Either HDZero (5.1 and earlier) or MSP DisplayPort (6.0 onwards) for MSP DisplayPort; or DJI OSD for basically what they did last time.

[OlivierC-FR]

Ok this is what I tried, with a custom build (6.0FP) with MSP API minor version set to 45 same as BF 4.3.2, instead of 42

MSP on, periph = None, speed 115200, response to arm = YES, OSD = no
MSP on, periph = None, speed 232400, response to arm = YES, OSD = no
MSP on, periph = None, speed 250000, response to arm = YES, OSD = no

MSP off, periph = DJI FPV VTX, speed 115200, response to arm = YES, OSD = no
MSP off, periph = DJI FPV VTX, speed 232400, response to arm = YES, OSD = no
MSP off, periph = DJI FPV VTX, speed 250000, response to arm = YES, OSD = no

MSP off, periph = MSP displayport, speed 115200, response to arm = no, OSD = no
MSP off, periph = MSP displayport, speed 232400, response to arm = no, OSD = no
MSP off, periph = MSP displayport, speed 250000, response to arm = no, OSD = no

MSP off, periph = Frsky OSD, speed 115200, response to arm = no, OSD = no

Next I'll try to also change the FC identifier

[a1axx]

Hey, won't the character set have to match bf 4.3?

Here is what DJI's 'canvas' (MSP-DP) can display:

[b14ckyy]

@a1axx ok this must be a joke by DJI.... xD
This is the default char set for INAV 6.0 FP1.

if that is really their full char set they offer, it is again completely useless for INAV

[a1axx]

@a1axx ok this must be a joke by DJI.... xD This is the default char set for INAV 6.0 FP1.

if that is really their full char set they offer, it is again completely useless for INAV

There must be a way to choose available items from a BF compatibility point of view.

[b14ckyy]

@a1axx that was already done with the old system. THere is a DJI Compatible switch in the OSD setup.
But that's the problem. The available items are still not adequate for INAV especially for fixed wing pilots. And if it is different now from the old system it means a shitload of extra work for INAV devs and again needs hacks applied in INAV to make DJI accept the OSD data. this is utter BS imho. Just shows again how little DJI cares about us.

[OlivierC-FR]

I might be wrong but I don't thing it has anything to do with the charsets, with BF 4.3 it's obviously the same old "DJI FPV" kind of communication, MSP based, not displayport, same as the old MWOSD as sample, over the UART goes the low level MSP queries and requests, I don't see why the fonts should be involved, no ?
As sample the O3 request LAT GPS, BF replies "45.12345", the O3 displays it with whatever font it want, and that's all.
It's not BF sending strings involving fonts.

Again, for the OSD to work with BF 4.3.2 it only requires the MSP column checked, nothing else.
Not displayport. Just some old MSP API versioned 1.45
Unless I misunderstood something.

[b14ckyy]

@OlivierC-FR

As sample the O3 request LAT GPS, BF replies "45.12345", the O3 displays it with whatever font it want, and that's all.
It's not BF sending strings involving fonts.

this iis true for the "classic" DJI OSD. maybe they still use parts of that. But they also advertise full "Canvas Mode" that would actually need that char set and would work similar to MSP Display Port.

And something MUST have changed in the DJI system. even if it still works with betaflight now. INAV got the DJI OSD hack implemented that actually fakes BF 4.2 MSP for the air unit. As you proved, this does not work anymore so they must have changed something in the firmware to prevent INAV applying this hack in the MSP side instead of actively supporting INAV.

This char set that @a1axx posted above is not even the full betaflight OSD Char set so even there it is limited. This is just laughable.

That means again the INAV devs have to spend many hours in adapting to this. possibly changing the OSD setup page again to make different options for the old and new DJI osd set etc....

[b14ckyy]

Did you test the FC identifier change already?

[a1axx]

@b14ckyy

To be fair it's not that bad. Users should be able to end up with an AHI & access to the stick menu. The crazy thing is, no matter how measly you think it is, I am sure a fair portion of inav users will still want to use it.

[b14ckyy]

Especially that's why I don't get why DJI acts like this....
So many users they left behind. Especially on fixed wings this O3 air unit might be of use. Right now no one with INAV can really use it at all. That's just stupid especially now that they have serious competition with Walksnail. The O3 is just a niche product in the first place as it is just overkill in price to put on any craft. It is only suitable for very specific crafts in the first place or if the user has just too much money to throw away.

[OlivierC-FR]

Especially that's why I don't get why DJI acts like this.... So many users they left behind. Especially on fixed wings this O3 air unit might be of use. Right now no one with INAV can really use it at all. That's just stupid especially now that they have serious competition with Walksnail. The O3 is just a niche product in the first place as it is just overkill in price to put on any craft. It is only suitable for very specific crafts in the first place or if the user has just too much money to throw away.

The very root of the issue is that they always send the first batch of gear to the same dozen of influencers, half of them make a video for the $ then put it on a shelf and never use it again, the other half fit on a BF quad and do like 3 flights "wooaaaaa product is awesome !!!" and that's the end of it. They get near zero valuable feedback from these people (excepted few I can count on a single hand) If only they would send one or two samples to INAV and arduplane users or devs, even the worse moron would think to send them an email like "eh what about adding support for everything else than a BF quad"... same sad old story, again. Sorry for the rant, they never learn.

Now on a more positive note, looks like they are at work with new firmware so we can hope I guess

[b14ckyy]

They have not made the old DJI systems INAV and Ardu compatible even after 3 years. Do you seriously think that this will change after they now seem to actively block INAV?
I mean. Nothing changed in BF. It works with BF 4.2 and later. INAV has the DJI OSD hack implemented that fakes a BF 4.2 FC. but now it does not work anymore so there must be an active block in place.

[a1axx]

@b14ckyy it still won’t stop us from buying it though as it works pretty well.

[JoeSa3rd]

Thanks for the addition info.

[JoeSa3rd]

Thanks @JoeSa3rd @OlivierC-FR for looking at this! Basic compatibility with the bf4.3 limited osd will be super :)!

I was the one that posted the part about the heartbeat.

this 0 identifier was sniffed out by someone trying to get it to work with Kiss. I can’t remember, but I think there was something needed for ardu as well. It should be documented if you search o3 osd on ardupilot website.

excellent effort for trying so far 👍👍👍

@a1axx Thanks for the additional info.

As stated in a prior post, it's interesting that if you disable all forms of MPS on the UART connected the 03 AU, the DJI auto bitrate increase and auto video record feature does not work. Which tells me part of the MSP implementation is working just not the needed coms for OSD. I need to figure out what Kiss and Ardu have done to solve for this and we will be one step closer to a workaround.

[a1axx]

Thanks @JoeSa3rd @OlivierC-FR for looking at this! Basic compatibility with the bf4.3 limited osd will be super :)!
I was the one that posted the part about the heartbeat.
this 0 identifier was sniffed out by someone trying to get it to work with Kiss. I can’t remember, but I think there was something needed for ardu as well. It should be documented if you search o3 osd on ardupilot website.
excellent effort for trying so far 👍👍👍

@a1axx Thanks for the additional info.

As stated in a prior post, it's interesting that if you disable all forms of MPS on the UART connected the 03 AU, the DJI auto bitrate increase and auto video record feature does not work. Which tells me part of the MSP implementation is working just not the needed coms for OSD. I need to figure out what Kiss and Ardu have done to solve for this and we will be one step closer to a workaround.

Apparently this was the key:

[JoeSa3rd]

I couldn’t find any info on the Kiss code updates that were used to fix MSP with the 03 AU. It looks like AdruPilot has likely been working from back in Sept when yaapu fixed Arm/Disarm issue in the MPS for legacy DJI MSP logic. I spent a good part of my day looking into this and trying various option but nothing was successful. It does not look like DJI is blocking anything by FC IDENTIFIER, API_VERSION or FC_VERSION. It seems more like a coms issue in the basic MSP (not DisplayPort) implementation. Unfortunately, I don't have the tools to trace the traffic between Betaflight<->03 AU and or INAV<->03 AU to find any notable differences. I can say there are a good number of differences in the Betaflight vs. INAV MSP implementation. Some might be the fix but not sure where to start. No offence to the hardworking coders of this project but the code is lacking useful comments, which makes this even more challenging as I've not worked with this code in the past. Reverse engineering code due to lack of useful comments all while trying to find an issue blindly is not a very efficient way to get to root cause. Someone who has worked their way around this MSP code would be able to find root cause more quickly than I can.

[krousenick]

@JoeSa3rd

Can you share the make command with options you used to build? I was looking to test this weekend as well. Thanks!

[erstec]

I couldn’t find any info on the Kiss code updates that were used to fix MSP with the 03 AU. It looks like AdruPilot has likely been working from back in Sept when yaapu fixed Arm/Disarm issue in the MPS for legacy DJI MSP logic. I spent a good part of my day looking into this and trying various option but nothing was successful. It does not look like DJI is blocking anything by FC IDENTIFIER, API_VERSION or FC_VERSION. It seems more like a coms issue in the basic MSP (not DisplayPort) implementation. Unfortunately, I don't have the tools to trace the traffic between Betaflight<->03 AU and or INAV<->03 AU to find any notable differences. I can say there are a good number of differences in the Betaflight vs. INAV MSP implementation. Some might be the fix but not sure where to start. No offence to the hardworking coders of this project but the code is lacking useful comments, which makes this even more challenging as I've not worked with this code in the past. Reverse engineering code due to lack of useful comments all while trying to find an issue blindly is not a very efficient way to get to root cause. Someone who has worked their way around this MSP code would be able to find root cause more quickly than I can.

With all respect to you and your comment:
"Reverse enginering" is not related to what you speaking about. It is exactly what you proposed to do - sniffing communications between BF and O3 and INAV and O3.
Code reading is not reverse engineering. It is just part of development.
I wasn't hear such "complains" from peoples contributed to this project a lot. At all.

Asking for comments in code in open source project is just wasting of time, as all contributors are doing it as decide and propose pull requests as is and if we start to ask to comment code before merge - project just die tomorrow.

INAV (and BF too) are written in pretty simple manner (C language), it is not Git or Linux kernel sources ;) There was no any problems to "understand it all" without any comments, it just need some time. Reading "comments" is not panacea, as eventually you will fing to go through code anyway to understand what and how works.

Regarding all this situation: Pawel stated officially and very clearly that we don't know what was changed by DJI, we don't have any documentation or comments from DJI, as long as we don't even have hardware to implement/test O3. Togetether with statement: we don't do any workaround again. At all.
If someone will provide working code, it, MAYBE, be merged, but as someome stated before, it will be first candidate to remove when we will need space for functionalities in F722 anf F411 MCU's.

If DJI "have no plans" (according answer to @b14ckyy why we should? Because we much smaller than DJI and non-commercial?

I ordered O3 set before all this discussion started, but still not received it, and, maybe, if will have time and mood will do exactly reverse enginering, maybe. As there is much higher priority things in life. At least I will have ability to do that.

And just my opinion: OSD should be OSD, not a "part of OSD". And if 1% of INAV users use 3 of 50 OSD elements and are happy with it, rest 95% want to have all they need on screen, without compromises, but this is impossible without having things I wrote before.

[a1axx]

@erstec i get that it’s annoying that DJI won’t actively release any information or continually work with the ‘community’. The facts are that they haven’t before, even their KOLs barely have any influence. They just do things how they want.

Once they finish a project, there is not going to be long term on going patches and feature up dates, it’s on to the next project or milestone for developers.

What they have is a limited betaflight 4.3 osd, not 3 out of 50 elements, but more like 50% of what available might be fairer to say.

Rather than us taking the attitude of ‘they wont work with us, so why should we do anything’, we can try something to get Bf 4.3 osd compatibility as DJI intended, because that’s probably it, it’s just unlikely they will work directly with Inav.

Putting the OSD compatibility aside, it’s the best HD system available to us today, so a lot of people in the community want to use it and will not boycott it if DJI won’t work with Inav..

[a1axx]

Best of luck again @JoeSa3rd, I have asked ‘Fedor’ to add comments as he was the chap who got it working on kiss ultra.

he may be able to shed some light on it aside from the statement I posted in her yesterday about the 0 ‘sub command / heartbeat’ he mentioned. This was found when sniffing out BF->o3 MSP

[KissUltra]

Basically, only thing u have to change is to send heartbeat subcommand like every second and add new xlat table on ultra to map to DJI charset as i do for ALL hd systems. And obviously squeeze osd to smaller screen. Yes, i logic analyzed the traffic between BF and AU because i am not allowed to see/use the code (Ultra is closed source). Ah, screenshot with fonts above its from my osd ;) When dji sees heartbeats it will go to display port or whatever you boys call it. after that i use SAME code as any other hd systems i support (WS, WTF, HD0).

If you guys interested - here is dump from ultra that works.

https://drive.google.com/file/d/1b32JheoxzGTymRMMNCSed71zufs1qEfu/view?usp=sharing

Enjoy.

[a1axx]

Hey, won't the character set have to match bf 4.3?

Here is what DJI's 'canvas' (MSP-DP) can display:

@erstec this is the limited character set ^ it’s not all bad

[KissUltra]

Funny to see screenshots from ultra hahaha ;)

[erstec]

@erstec i get that it’s annoying that DJI won’t actively release any information or continually work with the ‘community’. The facts are that they haven’t before, even their KOLs barely have any influence. They just do things how they want.

Once they finish a project, there is not going to be long term on going patches and feature up dates, it’s on to the next project or milestone for developers.

What they have is a limited betaflight 4.3 osd, not 3 out of 50 elements, but more like 50% of what available might be fairer to say.

Rather than us taking the attitude of ‘they wont work with us, so why should we do anything’, we can try something to get Bf 4.3 osd compatibility as DJI intended, because that’s probably it, it’s just unlikely they will work directly with Inav.

Putting the OSD compatibility aside, it’s the best HD system available to us today, so a lot of people in the community want to use it and will not boycott it if DJI won’t work with Inav..

I don't have intension to start discussion about 3 of 50 or 25 of 50. Compatibility is when it is 50 of 50. It is my opinion, as I stated before.

Last comment about "what dji 'canvas' mode can display" don't have artificial horizon, vari, and a lot of things needed to fly planes and wings. How I can fly wing if I don't know is it accending/decensing, am I upsidedown, maybe? Whatever... All that was already talked before.

Main point is we do not develop without having hardware on a bench. At least noone from us have it atm. If you have it - let's do this. If "a lot people in community want it" there is nothing wrong for those peoples to make it working by themselves and make great contribution to project, instead of complaining about how hard to read C code :) sorry but it is at least very strange to have such approach like "I can't do that but I know that this is very simple". "Effrective managment" will not have place in INAV project.

Just imagine, how much time it will took for ex. to me to develop changes just from "unclear directions", build fw and give it to you for test, then, because we have different timezones, somehow adjust time to have results, then repeat this 20 times at least and eventually propose PR? How much? Week? Two? Who will cover all expenses? Nobody. In other hand having it on a bench will let me do thi myself, completely, wherever and whenever I decide and want! And YES it is my wants and wishes, absolutely, as I am not hired by anyone (as other developers too) to be obligate to adjust my PERSONAL time to anyone else. Again, main reason is bolded before.

IMHO: Best HD system available for us today is not O3, but previous one with wtf-osd. It work perfect and have great range. I bought O3 just because I can affored it and it is hype, as I 100% enjoying "older" one. At least "older V2" googles fit my face without removing galsses :D

I will not comment further, just to prevent possible flame. Only constructive suggestion will be answered, but not management.

[KissUltra]

Hardware helps A LOT. You guys have patreon, why not to spend (invest) 250 euro to get O3 AU for sake of users? It works with V2 googles just fine.

[erstec]

Hardware helps A LOT. You guys have patreon, why not to spend (invest) 250 euro to get O3 AU for sake of users? It works with V2 googles just fine.

INAV have Patreon, are you sure? :) Even if it is and I just don't see it, having one O3 is not right way, as "old" V2 googles can't work with both systems. According to yesterday MadsTech video googles should be upgraded/downgraded everytime you want to use them with "old" system and vice-versa, or I'm wrong? Note: Personally I don't plan to update FW's on all my planes and quads (Vistas and AirUnits) to O3, they work excellent right now, no need to put O3 to them. Moreover "new" AirUnit O3 FW don't have SD card recording support, so no compromises again, after >2years waiting of "when old DJI system will became perfect". I want to enjoy flying as every other pilot. Not just developing :D

As I told before, I ordered set of new googles and O3 unit already, more than 2 weeks ago, but... it is still in transit and I have no idea when it will arrive.

[KissUltra]

Afair, Pawel got patreon. Well. I am using V2 googles with O3 unit. Because it was only way to get it for development. Anyhow. I will let you be. You have plenty of info now to get it done i guess.

[erstec]

Afair, Pawel got patreon. Well. I am using V2 googles with O3 unit. Because it was only way to get it for development. Anyhow. I will let you be. You have plenty of info now to get it done i guess.

Pawel's Patreon is Pawel's Patreon. Most probably it is a good idea to have opencollective or service like that for INAV project. Idk.

Information you provided is highly valuable, thank you!

Personally for me, it is not necessary to have O3 support right now at all. I prefer to wait for my set and then will try to do something (if noone will do this before, ofc.)

[a1axx]

@erstec

[a1axx]

Basically, only thing u have to change is to send heartbeat subcommand like every second and add new xlat table on ultra to map to DJI charset as i do for ALL hd systems. And obviously squeeze osd to smaller screen. Yes, i logic analyzed the traffic between BF and AU because i am not allowed to see/use the code (Ultra is closed source). Ah, screenshot with fonts above its from my osd ;) When dji sees heartbeats it will go to display port or whatever you boys call it. after that i use SAME code as any other hd systems i support (WS, WTF, HD0).

If you guys interested - here is dump from ultra that works.

https://drive.google.com/file/d/1b32JheoxzGTymRMMNCSed71zufs1qEfu/view?usp=sharing

Enjoy.

Thank you very much for commenting.

@JoeSa3rd @OlivierC-FR ^^

[erstec]

@a1axx
I don't understand what I should do with picture you provided, if you posted it as "evidence" - it is not. It still lost things.
Ok, maybe you don't read about my position in previous messages, but mainlyit is same as Pawel's, with one difference, MAYBE, I will try to do something AFTER I will receive O3 set. I don't need motivation, I have it, but I don't want waste my time. There is no such 'evidences' will change my position, as I think my approach is more that friendly (just tools needed).

[b14ckyy]

I don't like to make this unhelpful discussion continue but I have to set a few things straight. For ardu there are absolute basic items missing and some items just reused because there is no equivalent (the arrows). All in red circles has missing something or wrong symbol alltogether.

Snipes OSD is even just a very simple setup and still has things messed up.

And please don't tell me "you get used to it" because that's not the point. Then we need no OSD elements at all and just need to put plain numbers and letters there. We will remember what is what then after a while. That's no argument.

Now imagine an INAV developer or someone like me testing INAV stuff, needing much more data. try to find out what value is what on my OSD, that I need for testing and then imagine someone like Pawel, who is nearly exclusively on DJI would have to deal with that. These are all items I have used over the last weeks for development testing. Now imagine I would not have all the red marked symbols at all so I don't know what the number actually is.

[a1axx]

@b14ckyy since it is highly unlikely that DJI will work with any firmware devs, bf, kiss, ardu, inav etc, there is no use in getting hung up on getting every element that you want to see in inav from a dev or test point of view.

The original question is there any plan for inav supporting ‘goggle 2 canvas mode’. That is simply going to be the reduced character set that DJI have put on the G2 and for the o3 / v1 system. The GV2 are no longer compatible with the DIY system once updated to be compatible with the G2.

Pawel is using the root hacked wtfos, which continues to work fine.

What we are looking at is the implementation of a reduced character set to have compatibility with what DJI have provided. That’s it, nothing more, nothing less.

I think thats the clarity needed on this topic. If you want full inav OSD compatibility, this system will most likely never deliver.

More over, if they do work with any devs, or any particular FW, it will be BF. Where it is possible they may implement their 512 char set, again, compatibility would be needed. I don’t see it happening as they have not even implemented the full BF set for 4.3.

[b14ckyy]

@a1axx Well then, I think there is no need to further defend or justify DJIs actions in any way.

The main topic of this thread was answered:

• No there will NOT be official "support" by INAV for O3 OSD as INAV cannot support it, only vice versa.
• If a developer is willing and capable to implement a reduced workaround OSD, then it might happen
• if this happens, be aware that this will have a very low priority and be removed if it causes any conflicts with other OSD systems or other features or if the flash storage is needed for other INAV development on F722 and F411.

There is always the option for any developer to Fork INAV and make a custom version of it with all the releases but then this developer is in charge of maintaining it.

So at this point I guess this thread can be closed as answered.

[a1axx]

@a1axx Well then, I think there is no need to further defend or justify DJIs actions in any way.

The main topic of this thread was answered:

• No there will NOT be official "support" by INAV for O3 OSD as INAV cannot support it, only vice versa.
• If a developer is willing and capable to implement a reduced workaround OSD, then it might happen
• if this happens, be aware that this will have a very low priority and be removed if it causes any conflicts with other OSD systems or other features or if the flash storage is needed for other INAV development on F722 and F411.

There is always the option for any developer to Fork INAV and make a custom version of it with all the releases but then this developer is in charge of maintaining it.

So at this point I guess this thread can be closed as answered.

On a positive note, it’s being worked on and I will be trying a 411 wte next week.

I think it can stay open for further discussion between contributors trying to get this to work as it affects them.

[a1axx]

They usually close when there is some code to cross ref too when something has be ‘done’ right?

[erstec]

@a1axx after so "long" discussion this thread is not Issue. All answers provided and if someone provide PR - it will can be started again. This one can be moved to Discussion, I think.
@b14ckyy @MrD-RC do you agree?

[b14ckyy]

ok for me.

[MrD-RC]

I think moving to a discussion is fair.