Find a new OSD solution

[skaman82]

The MAX Chip seems not right for the job because it needs a perfect video to display the OSD.
Researching the LM1881 OSD circuits currently…

https://youtu.be/zhLGqg2VBxQ

See: https://github.com/skaman82/Pocket-Groundstation/blob/master/updates.md

[sheaivey]

Getting solid OSD on transmitted video feed is very difficult. LM1881 has the same issues in that regard as the MAX chips. We use the EL1883 which is a 3v i/o variant of the LM1881 in the La Forge FPV v4 module. But it also has the same issues with poor video sync pulses.
The only way around the sync issues would be to lock onto the sync pulses (PAL/NTSC) and asume the timing never changes and bang out the OSD out via an internal clock. Not an easy task to accomplish.

Aside from the sync issues the max chip offers a lot of features to offload the video generation from the main microcontroller. The LM1881 would require you to generate the video signal from a microcontroller usually done by bitbanging or using the SPI buffer.

Hopefully this helps in in some way with picking a OSD direction by explaining some of the tradeoffs.

[skaman82]

@sheaivey yes thanks - I've looked into the LM1881 solution and tried some different approaches - it's would be flyable because the "blue screen" is not there anymore compared to the MAX chip. But I decided to drop the OSD feature because of poor sync performance.

[sheaivey]

If the overlay OSD is an issue there is another option you could go with which is mirroring the OLED on a B&W video (not an overlay but generating your own video). This is really easy to accomplish and only requires 2 resistors and a transistor to switch the video source. You could have it switch over to the B&W in the goggles when the user presses a button and return to the video feed after no interaction has happened for 5 seconds. Just throwing ideas out there to consider.

[skaman82]

Thanks, I thought of that. But I think in my case the most valuable information is the battery voltage, dvr status and (if I solve this) the RSSI information and both values should be always visible on screen as an overlay. Displaying the OLED info would work only when you are not flying and you have to get to the buttons on the ground-station first.

[wx4cb]

Why not just have a locally generated sync pulse and just switch to it when needed. The problem with the dockking for me is that there are some elements u cant remove so they get in the way of the osd i have on the aircraft

[skaman82]

@wx4cb I have actually have no clue how to get this done :D This is what the max chip does when the video rssi gets a bit low (sync loss/flicker + grey background) https://youtu.be/zhLGqg2VBxQ - the LM1881 behaves basically the same (sync loss/flicker but without the grey background). If someone has the skill to solve this, please join the project!

[JyeSmith]

@skaman82 while the rest of the community is developing an OSD, I am not convinced it is a useful feature. Displaying VTx RSSI isnt really useful, unlike radio link RSSI. Regardless of the VTx RSSI value we will still fly if the image is acceptable.

It may also become a redundant feature since most new VRx modules being released will have an OSD.

But if you are going to continue with an OSD you might like to checkout the work over at WPro58 if you haven't.

https://github.com/piodabro/WPro58

[skaman82]

@JyeSmith yes, its not like it is a "killer feature" and I abandoned this feature for now but having some data displayed still seems useful to me. Like: seeing if the DVR is running and the battery status of the groundstation - RSSI is just a bonus, it can be used for readjusting the antenna mid flight. If you are 10km out its nice to have the battery info. But again, you can just adjust the voltage alarm to go off a bit earlier...

B.T.W. - I tried the new True-D 2.4GHz module with its integrated OSD - it has the same sync issues I had encountered on my LM1881 test setups (OSD is flickering and then completely disappearing at about 50% video RSSI). The DockKing has the same problem.

[StoneColdCrazy]

I found is talk about the rest here....
i say it in the other "issue" .... the sync problems maybe solved with rapidfire, because rapidfire also needs an clean sync to work. So my idea was, to check this. The only other way is to resync all the frames. But here is the next problem, you lose time. (with an extra dsp)

[skaman82]

I am currently looking into a way to still use the MAX based OSD, but switch to direct RX feed on sync loss - not a 100% solution, but usable if it works

[skaman82]

Ok, this looks promising: https://youtu.be/Wh2_j9sja44

Wired the LOS pin from the MAX chip to the VBAT1 pin on the minimosd micro to detect sync loss and controlling two LEDs with the CURR and RSSI pads. I think that we could switch to a direct videofeed from the RX during sync loss to prevent the grey screen blocking the image. Ordered some CD4066B switches to test. Thanks to @fedorcomander for this idea!

[fedorcomander]

You are most welcome ;)

[skaman82]

some progress on OSD fallback in case of sync loss: https://www.youtube.com/watch?v=TMlkBO-3MI4&feature=youtu.be. Using 4066 for switching.

[realhuno]

Hi, any news? I looking for something like this to make my capture the flag game for racing quads.
i need an osd and a groundstation to push in the team-points. red and blue team. The Flag State (R =red and B=blue)

my first idea was to use an minosd like here in your projekt...
https://www.youtube.com/watch?v=jcf5mTSx9RA

my second try with the internal OSD from the quad. This solution only works on betaflight and frsky telemetry. (i use the telemetry to change the pilot name for my points)
i only can use ppm values and they flickering ;-(

[skaman82]

@realhuno I sadly cold't find a good solution for this (just a workaround) so I've abandoned this topic until somebody has a better idea. I guess it requires video sync generation by the MCU and I just don't know how to do that neither in hardware or in code. I am also guessing an ATmega382 is too slow for this job.