Jump to content
FredericG

Oracle Diversity Receiver and STV5730A based OSD

Recommended Posts

I am experimenting with my new Oracle Diversity Receiver and it is obvious that there is also a problem with my STV5730A based OSD :( I do not know how the Oracle should behave, in general I have the impression there is a lot of switching back and forth but when I enable the OSD, the Oracle switches much more often or sometimes goes mad. I could use a little help.

I attach a few pictures of the video signal when the camera is looking at a gray surface and there is some OSD content on the screen. Does this look OK? The timebase is 2 and 1us/dev.

I also checked the Vpp when shining with a bright light in the camera and that is around 900 mV for both receivers.

I know there have been issues with the IF OSD. Do we know exactly what is confusing the LM1881?

Thanks,

Frederic

post-2786-1207931403_thumb.jpg

post-2786-1207931423_thumb.jpg

Edited by FredericG

Share this post


Link to post
Share on other sites

Your waveforms show huge spikes on the tail end of the whites. These spikes are traversing below the black level and getting into the sync's area. This is not typical of a STV5730 IC and I have never seen one do that before. Can you post a schematic of how you implemented the IC?

In regards to excessive switching with the OSD removed, and you are sure it isn't caused by multipathing around the workbench's area, the first thing I would suspect is improper video levels. You should ensure you have standard 1Vpkpk composite with full whites; start with the input to the Tx and verify 1V. Then go to the output of both Rx's and verify 1V there too.

Edit: I'm assuming the waveforms are directly from the output of the OSD. However, if they are from the output of the Rx, then the odd spikes could be caused by the A/V Tx or the Rx's. So, check each stage to see where they come from.

Edited by Mr.RC-Cam
Spikes from OSD or Wireless A/V?

Share this post


Link to post
Share on other sites

Thank you for your help.

The waveforms I posted are measured at the RX side. Both receivers generate the same signals and have 900mV p-p. As you suggest, I will also look at the signals on the TX side.

This is a standard BlackBoxCamera board, I do not have any schematics. May I assume there are no errors there? It is however my own software, the way I configured the OSD-chip might be different from other applications.

My comments on the switching come from in-flight observations. I assume that the system is working properly with OSD disabled.

I will investigate further.

Thanks,

Frederic

Share this post


Link to post
Share on other sites

Although anything is possible, I can't imagine how the issue could be caused by your custom software. I'd have to say that you should take a peek at the video output of the OSD. I have a feeling it will look fine there; It would more likely be caused by a problem in the Tx or the two Rx's. But, for now it is a mystery.

Share this post


Link to post
Share on other sites

I did some more measurements.

The levels on the TX side are too high: 1.5V. 0n the RX side around 1V. Is this 1.5V dramatic? Could this be the impedance problem with the new lawmate transmitters?

I attachment a picture of the RX side (above) and the TX side when I shine into the camera with a light. 0.5V/div

post-2786-1207988771_thumb.jpg

Then I did some tests with the camera looking at a gray surface. The 2nd picture shows how it looks when OSD is not active, 0.2V/div 5us/div, TX side

post-2786-1207988782_thumb.jpg

Share this post


Link to post
Share on other sites

Now, the same line (I think/hope) at the RX side:

post-2786-1207989229_thumb.jpg

It is the first time that I look at video-signals. A difference I see is that at the RX side, the levels go well below black while it is less the case at the TX side.

I suppose I could also measure at the sync-pulses on the PIC and show them together with the video signal to see when sync-chip miss-triggers.

Thanks,

Frederic

Share this post


Link to post
Share on other sites

By the time the video is presented on the Rx's output, the OSD pixel levels are incorrect. The OSD's pixels have entered into the sync area. There is a bit of this on the Tx side too, but the most significant seems to be at the Rx's side. It is very strange indeed.

Below is a waveform from Inspire's STV5730A OSD, with a full screen of data, while overlaid on color bars. This is directly out of the OSD into a 75 ohm load. Notice how the video levels do not traverse below the black level.

The levels on the TX side are too high: 1.5V. 0n the RX side around 1V. Is this 1.5V dramatic? Could this be the impedance problem with the new lawmate transmitters?

I'd have to say its due to their Tx's poorly chosen input impedance (a result of their recent design change). Sometimes I wonder if Lawmate knows about the video standard that the rest of the world uses. Does your OSD's signal levels look correct when simply terminated with a standard 75 ohm load?

.

post-2-1207992179_thumb.jpg

Share this post


Link to post
Share on other sites

Here's another example for reference. This time there is no camera (STV5730A internal sync mode). Again, the OSD pixels remain within the active video area and do not enter the sync.

Also, notice how much "cleaner" the pixel waveform is? The waveform from your OSD has sort of a ragged look to it. Maybe this is caused by the Tx's odd input impedance. So as mentioned, try a 75 ohm load instead and see if things look nicer.

By the way, I didn't see a color burst in your video signal. Your camera is B/W?

.

post-2-1207993131_thumb.jpg

Share this post


Link to post
Share on other sites

I think we are getting close (but I am not sure this is good news :-) )

I took a picture of a white surface so that my photo camera could generate a perfect PAL image and used that as input for the OSD. Than I modified the OSD code to display only "IIII".

First I used my PC capture box to terminate the signal, it looks good. Level is almost 1V and black (the borders of the "I"'s) is at black level.

.2V/div:

post-2786-1207993701_thumb.jpg

So, when I let the TX terminate, the signal is much bigger, but still looks good:

.5V/div

post-2786-1207993753_thumb.jpg

Share this post


Link to post
Share on other sites

Now, when I look at the signal at the RX side, there is over and undershoot.

0.2V/div:

post-2786-1207993975_thumb.jpg

The problem is that I do not know how I could solve this. I thought that I could influence the "color" of the borders, but I did not succeed yet, I think this only works in "full mode"

Could I filter the video signal before it is fed to the LM1881?

Thanks,

Frederic

Edited by FredericG

Share this post


Link to post
Share on other sites

Regarding the color-burst. I have also seen this, sometimes it is visible, sometimes it is not. I think this is because the scope is in digital mode and does not take enough samples. Is this reasonable? I think this is also the source of the "ragged" aspect of some of the signals that are taken at higher timebases, you do not see the real peaks.

Another remark is that the last 3 images are taken with another spare board. It looks to me that this board puts black exactly at the black level while the board installed in my plane puts black slightly below the black level. In both cases, at the RX side there is over- and undershoot.

Frederic

Share this post


Link to post
Share on other sites

For sure, there is an issue with the A/V system and what it does to the high frequency aspects of the video signal. For example, if you look at the edges of the syncs, they too are exaggerated at the Rx. It sort of reminds me of a bad de-emphasis filter or the usual 4Mhz filtering is missing.

Could I filter the video signal before it is fed to the LM1881?

You could try filtering the composite video going into the sync detectors. The only issue is that filtering is going to affect the horz syncs. But in case you go this route, there are two LM1881's in the Oracle. Take a look at their Vert (pin 3) and Horz (pin 1) outputs with the OSD turned on and off. The filtering should ensure these signals are properly cared for.

It might be of value to determine if this is a Video Tx problem or caused by the Rx's. Too bad you don't have a buddy with a similar Lawmate system to see if the issue is the same for him.

By the way, does Oracle work with the OSD if you reduce its sensitivity to 1?

Another remark is that the last 3 images are taken with another spare board. It looks to me that this board puts black exactly at the black level while the board installed in my plane puts black slightly below the black level.

Until you get this sorted out, I would recommend you debug using the spare OSD board since it does not seem to have a black level issue. Once you find a cure with that OSD, you will be better suited to test the other board.

I think this is also the source of the "ragged" aspect of some of the signals that are taken at higher timebases, you do not see the real peaks.

Digital scopes do indeed cause a lot of headache in some situations. But in this case I think the ragged edges are due to the A/V system's frequency response issue. From what I see in your photos, ALL the "sharp" edges are affected at the Rx's output.

Share this post


Link to post
Share on other sites

I still have another TX, exactly the same lawmate .5W. For reason it has become VERY sensible to vibrations, but OK for this test.

I tested with both transmitters and both receivers. Unfortunately the signal at the RX looks the same. :angry2: I include a more detailed picture. The bottom black line is the level of the sync tip, the dashed line should be around 100mv. In the datasheet of the LM1881 I have read that the threshold for the sync pulses is a fixed (typical) 70 mV. Some spikes must reach this value. I think this "better" OSD will also cause trouble and it would be a lot of work to swap the boards as I has lots of connections soldered to the board.

post-2786-1208071768_thumb.jpg

I experimented with different OSD settings (output level, reintroduce sync, colors), but no improvement.

As I use a TX/RX bought a year ago and one that was bought a month ago, I think we must conclude this is the way lawmate devices function, no? I suppose no camera will generate steep edges as the OSD chip does. I might soon switch to an OSD based on this new MAXIM OSD chip, but will things be dramatically different?

I was hoping I would be able to suppress the overshoots with a simple RC-filter, while the sync-pulses still come trough. Do you think this might work?

I did not try lowering sensitivity yet. Problem is, the weather turned bad again in Belgium :-(

Thanks,

Frederic

Edited by FredericG

Share this post


Link to post
Share on other sites
I think we must conclude this is the way lawmate devices function, no?

It sounds like the 500mW system has something evil about it. I suspect this problem may have come about the same time they made the changes to the Tx's video input impedance (another issue that they have yet to do anything about). Too bad we can't identify the exact cause of your issue; Tx or Rx?

I was hoping I would be able to suppress the overshoots with a simple RC-filter, while the sync-pulses still come trough.

Fortunately, the inputs to the sync strippers already have a low pass filter. So, most of the work is already done for you. :) In their current form the cutoff freq is about 1Mhz.

Each RC Filter is 620 ohms/470pf. U3's filter is comprised of C19 and R9. U5's filter is C24 and R15. I suggest that the resistors remain the same. Just increase the cap values instead. Perhaps try 1000pF.

Keep in mind that if the filter becomes too aggressive then the Oracle will not work correctly or will be dumbed down and less effective. The best thing to do is to scope out the LM1881 sync outputs and ensure they have valid pulses. If the filter fixes it, then also verify that reduced video levels work well too (reduce the Rx's video levels to .8Vpkpk) and test for proper operation. If that all works, then the solution is robust.

If you were USA based I would just invite you to send your stuff to me so that I can design the fix. But since you are overseas, it is best that we do this by "remote control." :)

Share this post


Link to post
Share on other sites
Fortunately, the inputs to the sync strippers already have a low pass filter. So, most of the work is already done for you. :) In their current form the cutoff freq is about 1Mhz.

Each RC Filter is 620 ohms/470pf. U3's filter is comprised of C19 and R9. U5's filter is C24 and R15. I suggest that the resistors remain the same. Just increase the cap values instead. Perhaps try 1000pF.

Keep in mind that if the filter becomes too aggressive then the Oracle will not work correctly or will be dumbed down and less effective. The best thing to do is to scope out the LM1881 sync outputs and ensure they have valid pulses. If the filter fixes it, then also verify that reduced video levels work well too (reduce the Rx's video levels to .8Vpkpk) and test for proper operation. If that all works, then the solution is robust.

This is interesting.

I started measuring inside the Oracle. I looked at the video-signal after the filter and the sync pulses from the LM1881 (pin 1). The filter is doing a good job filtering the overshoots generated by the A/V system. As far as I an see (I should have a better scope) I cannot detect false sync pulses. This is with the "better" osd board printing much more "I" characters than before.

post-2786-1208367788_thumb.jpg

post-2786-1208367799_thumb.jpg

What is very confusing is that the signal looks good to me, but when I enable both receivers, Oracle starts switching rapidly. This is indoors, I know, but the pulses look good to me... Very confusing.

If you were USA based I would just invite you to send your stuff to me so that I can design the fix. But since you are overseas, it is best that we do this by "remote control." :)

I do appreciate your help :->

Share this post


Link to post
Share on other sites

Afterwards I did the same test with the system installed in my plane. Here the plane is outside and I am inside. This is with the OSD that generates some "blacker than black"

post-2786-1208367968_thumb.jpg

The overshoots are gone but the black is a bit below black. I can however not see false sync-pulses. To be honest, I start wondering if this is really our problem. However, what else could it be? AFAIK, the sync pulses is the only thing the device uses as input.

When I now enable both receivers, there is some switching, but not a lot. :huh:

The sync pulses are hardly affected by the filter, so I suppose I can increase the cap safely. I might filter away the "blacker than black", but again, I wonder if this realy my problem.

Thanks,

Frederic

Edited by FredericG

Share this post


Link to post
Share on other sites

Very interesting indeed. Just to establish a reference: The problem appears when the OSD is used. Without the OSD, Oracle works correctly. Is that correct?

If so, then the next step would be to monitor the LM1881's two outputs and find a detected Vert or Horz sync that is not aligned to a valid video sync position. I know that is like finding a needle in a hay stack, but somewhere in there is an evil thing looking to be discovered.

Also check to see if the OSD alters the sync pulse widths or their general timing. Oracle is looking for industry standard timing, but it does include realistic padding for slight variations.

Is there a chance that Oracle's NTSC/PAL video mode is set to the wrong selection? Sorry, but I had to ask. :) BTW, does the rapid switching with the OSD stop if you set Oracle to the lowest sensitivity (1)?

Lastly, do you have a 1x2 video buffer? If you do, then try this test. Install the OSD into the input of the buffer. Connect the buffer's two outputs directly to Oracle's Video Inputs. This eliminates the RF link. Now does Oracle work correctly? If the problem is still there, then that would be very convenient: your spare OSD board could be sent to me for testing in my lab.

Edit:

When I now enable both receivers, there is some switching, but not a lot.

That is one thing that is not clear to me; Is your situation normal? Switching will occur if the active video source has "errors" in it. Errors are caused by lost RF signals, multipathing interference, and all other nasty things that corrupt the video. That is the basis behind Oracle's technology.

The question is if your errors are valid interference or something in Oracle's processing that needs to be fixed. Generally speaking, if the OSD is turned on and it causes Oracle's operation to change, then that suggests something is introduced into the composite video that is causing it to work outside the standard NTSC/PAL video standard. All of Oracle decisions are based on the sync timing, so abnormal operation would involve only the sync's that are detected by the two LM1881 IC's.

Once we ID the culprit we can fix it. So, all that is needed is a smoking gun.

Edited by Mr.RC-Cam

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×