21 replies to this topic

[twinturbostang]

Hey guys. Been a LONG time since I posted here. I was out of FPV for a couple of years but have recently taken it back up. Since then I've been flying for a few months. Just recently got the dpcav 900MHz video system and it works great. But... today I had a bit of a problem. While I was flying, the video image started "rolling" in my goggles. Not exactly sure how to explain it. The video image started scrolling upward with a horizontal black bar and the remaining part of the image appearing on the bottom of the screen. It continues to roll upward and would repeat the cycle every 1-2 seconds I'm guessing. Is that a video sync issue or something? I recorded the flight, but what's weird is the recording never shows this. There is some noise every once and a while. Plus I also have some sort of video banding issue (maybe from a switch regulator). I'm wondering if this is maybe causing my goggles to freak out. I'm using an OLD OLD pair of I-Glasses. I've seen this behavior before, but just very quickly (not continuous). It was so bad today that I almost had to hand the Tx to my spotter.

Anyway, here's the recording of the flight: Password is: CASA

For most of the first half of the video, I was experiencing this rolling image. I found if I stay really close in, and low, that it would go away or was at least good enough to fly. But again, the recorded image does not show this. Have my glasses had it???

Also, attached are pics of my video pod and a screen capture of the banding (visible in the sky). In the video pod pic are the camera (KX131), dpcav microphone, 5V regulator for the KX131 (stock reg. that came with it, removed from its plastic case), 900MHz Tx, and 3S 730 mAh battery that powers the video gear. I thought that the stock KX131 regulator was pretty good, but I'm starting to suspect it is the source of the video banding.

Thanks for the help!
Brian

Attached Thumbnails

• 
• 

Edited by twinturbostang, 13 November 2010 - 09:36 PM.

[Terry]

Thats scarey it only seems like yesterday you were here, time sure dose fly !

I think you are well on the way to sorting this yourself, can you use some different glasses to test


Terry

[Mr.RC-Cam]

The fine lines in the video are typically DC-DC switching noise. But sometimes the same thing can occur with loud audio sounds near the mic.

[Kilrah]

How are you splitting the video signal for simultaneous viewing and recording? Do you have an active buffer?

[twinturbostang]

Terry: "yesterday" was like 2 1/2 years ago! lol

I actually have a set of goggles on the way to me. Couldn't pass up the Headplay $100 deal from Dell. Hopefully that will resolve the issue. The glasses I'm using are the very old original I-Glasses. They have (at most) 320 x 200 resolution. So I'm really looking forward to better quality images. It's tough to see small objects on the ground with them. I think they were built back in the late 90's, so they are old and have no way of updating the firmware.

The video lines have been there before I installed the microphone, so it shouldn't have anything to do with that. I'm guessing it's due to the stock KX131 regulator, but I'll do some testing using a regular 4 cell nicad to make sure.

I'm also using the Oracle diversity which has two buffered video outputs. So there shouldn't be anything funny going on there.

Brian

Edited by twinturbostang, 14 November 2010 - 11:24 AM.

[Mr.RC-Cam]

Couldn't pass up the Headplay $100 deal from Dell.

The last thing I needed was another set of goggles. But I too sprang for the $100 Headplay deal. It will be interesting to compare them to my custom Trimersions.

Regarding the KX131 Vreg, try adding 200uH - 500uH chokes (rated at 200mA or higher) on the input and output power leads.

[twinturbostang]

Can you get those from the local RatShack? And do they go across the + and - leads? If I can improve the regulator, that would be great. It's a nice and compact design and doesn't weigh much.

Edited by twinturbostang, 14 November 2010 - 02:06 PM.

[Mr.RC-Cam]

Hard to say if Radio Shack can help, but you can easily check their catalog offerings online. The choke goes in series with the power lead.

[twinturbostang]

I'll check and see if they have anything.

Meanwhile, I did a little bit of testing today on the video banding issue, and I'm confused (more than usual). It appeared that I was getting the banding when powered from the switch regulator.. but only when it was transmitting the video signal via the 900MHz Tx/Rx. If I bypassed the video Tx and plugged the camera output directly into my goggles, I didn't see any banding. That was odd, as I did not expect it to be better. If the switching regulator is causing ripple on the power line, could that be affecting the video Tx?? That's the only thing I can think of. Microphone was disconnected. I also disconnected the Oracle and ran directly from one Rx just to eliminate that as a possibility. Same result.

I need to do some more testing to verify this. I also want to run 5V power to the camera from a 4 cell pack (so no regulator), and then feed the video signal to the Tx. That requires modifying my camera harness though as I need to remove the V+ pass through of the 900Pro and instead splice in an external 5V source. I may or may not have time to do that in the next couple of days.

BTW, I've had this banding issue since before I started using the 900Pro. It was there with my Range Video 900 Tx also. So I don't believe it's anything specific to the 900Pro Tx.

Edited by twinturbostang, 14 November 2010 - 08:23 PM.

[Mr.RC-Cam]

When you say "banding" do you mean the faint hard-to-see horizontal lines that appear throughout the background, as shown in the video example you posted? If that is it, and you have removed the mic, then it is most likely unwanted power supply noise from the camera's switching Vreg. But it could be caused by another source; Just continue with the troubleshooting until you solve it.

[twinturbostang]

Yes, that's what I was referring to.

I did get a chance to do some quick testing this morning, and I think it is in fact due to the regulator. I powered everything up as usual, and the banding was there. Then I removed the power lead from the video connector on the 900 Pro, so that I could power the camera via a 4 cell nicad pack. Video Tx powered by a 3S lipo, and camera via 4 cell nicad. No external regulators. And no banding was visible at all then. So it looks like I need to try the added filters you suggested, try a different regulator, or go with a 12V camera. Which as it so happens, I have. I've got a KX171 from Intelligent Flight (back when they were still in business). It's a 12V camera, and has higher resolution than the KX131. It doesn't have as good color saturation though. But at least I've got a couple of options of things to try.

BTW, in the flight recording, if you turn the volume way up (before the motors are turned on), you can hear a high pitched whine. Could that be the electrical noise from the regulator getting into the microphone? ESC noise? Or is that normal?

[Mr.RC-Cam]

if you turn the volume way up (before the motors are turned on), you can hear a high pitched whine. Could that be the electrical noise from the regulator getting into the microphone? ESC noise? Or is that normal?

It is possible to hear audio whine if you crank up the volume. Just keep the volume settings at a normal level and ignore any background noises.

[twinturbostang]

Ok, I didn't know if that was normal. Or maybe an indication of the electrical noise that's going on.

[twinturbostang]

I FINALLY determined the source of my video rolling issue. Weather has been bad lately and I haven't had much free time. But, this morning I finally got to fly and yep, my video glasses were the source. I flew with my new Headplay glasses today and they were great! No video rolling at all. Nice crisp image. I've also switched back to a linear regulator for powering the KX131 camera and there's no video banding either.

However, I have another issue now. Well, it's not new, I just haven't addressed it yet. It seems whenever I have my OSD hooked up, the Oracle diversity goes nuts. It constantly switches between inputs so fast, it sounds like it's sending Morse code! lol Any idea why it might be doing this? I have the DragonOSD+ v2. Even when the plane is on the ground just 10 feet away from the Oracle, with perfect video image (at least to my eyes) it still does this. And when in the air, it doesn't matter if it's close range or out far. Still does it. But when I bypass the OSD and just run the video image straight from the camera to the video Tx (DPCAV 900 Pro), it seems fine. Only occasional blips from the Oracle, which is normal.

Any help would be appreciated. I need to do some diagnostics and testing on this but I don't know where to start.

Thanks,
Brian

[Mr.RC-Cam]

If Oracle goes nuts when the OSD is used then it means that something unexpected has happened to the video signal. Here are the first two things to consider as possible causes.
1. Overall video level too low (or too high) due to the OSD's video interface circuitry.
2. OSD's pixel white level amplitudes too high (which causes severe video sag in some wireless A/V systems).

An o-scope is the best thing to use to see what is going on. But if you don't have one then it may be possible to learn a bit more about the problem using some simple stick poking techniques.

For example, find an old video monitor (at least 10 years old) with a 15" or larger screen that has brightness and contrast adjustment knobs. Begin by using the monitor to observe the video image from the video Rx when the OSD is not installed. Adjust the monitor's brightness/contrast controls to obtain the best image. Make a lot of mental notes about the quality of the image. Then quickly install the OSD and carefully observe the video image again, but DO NOT change the brightness/contrast control settings. Switch back and forth a few times (OSD installed, OSD removed) to train your eyes on the two image views. The Rx's image quality should remain the same in the two comparisons. Carefully look for differences in clarity (resolution) and brightness/contrast. Any differences that you see may help pinpoint the problem, so feel free to describe what you find.

The reason for using an old monitor is because nearly all modern models have aggressive AGC and other processing trickery, which will mask most of the problems from goofy video and interfere with the troubleshooting. But those features were not readily available a few years ago and that is why you will find things like brightness/contrast knobs on the old stuff.

Another thing to try is to install the Oracle and confirm the wild video switching when the OSD is used. The remotely turn off the OSD overlay using its remote on/off feature. If the Oracle works correctly with the OSD remotely disabled then perhaps that would imply that the OSD's white levels are much too high. If the OSD has a menu setting for brightness then use it to reduce the intensity of the OSD's text/graphics.

[twinturbostang]

Thanks for the info. I have an o-scope at work that I might be able to use. However, before I drag my airplane into work (lol) I'll try to do the other suggestions first. Not sure if you meant an old TV or a computer monitor, but I have a very old 19" TV that might work. Although it's so old that I'm not sure if it even has RCA inputs. It might just be a co-ax connection.

As for the second set of tests, I may not be able to do those yet. The DragonOSD+ v2 uses a PPM stream input to control the system and output to the control surfaces. However, I don't currently have a Rx that has PPM stream output. So I don't have a way of disabling the overlay features. At least not yet. I have a DragonLink on order (which has PPM out) and hopefully that will arrive soon.

[twinturbostang]

No update on my Morse code Oracle. But I did fly today from a new location, and believe I have external video interference. What does this look like to you guys? I haven't seen this before on my plane. I removed the switching regulator for a linear one to power my camera. And that was several flight ago. So I don't think it's any kind of onboard interference. Although, who knows. I've got to try and fly from my usual location with the plane in the exact same configuration to be sure.

Anyway, the flight today was over a man-made lake. And I think there was a large antenna over near the dam, which was approx. 1/2 mile from launch point. At 300' out (sometimes less than that) I could see strong interference, and it got progressively worse from there. Farthest out I got was only 1/4 mile. I've been out 1.4 miles with my 900MHz gear and great video quality, so I suspect it's external interference, but can't be sure yet.

Any ideas?

Attached Thumbnails

• 

Edited by twinturbostang, 11 February 2011 - 07:30 PM.

[twinturbostang]

Update: I flew this morning from my usual field. Video interference was completely gone. So the last flight definitely had some sort of external interference present. Bummer. I was really looking forward to flying to a few locations at that spot. I may have to look into running video on a different frequency band. I have some 2.4GHz gear. But I'm currently using the Futaba FASST RC control system (which operates on 2.4GHz), so that's a no go. At least until my DragonLink UHF system arrives.

Also, I have found the source of the problem with my "Morse Code" Oracle. There is an option in DragonOSD to turn off "text borders". With text borders ON, it puts a black border around the text. Makes it a bit easier to read in bright conditions. But with it turned OFF (which is how I had it set for today's flight), Oracle was whisper quiet except for the occasional Rx switch.

So, now that I have found the source of the problem, what to do about it? I would still like to have the ability to turn the text borders on in case it makes it easier to view the text. When the sky is overcast (read: all white), I think it's going to be harder to read the text at the top of the screen. Anyway, do you think it's a problem with the OSD output when this feature is enabled? Or is it a problem with the Oracle seeing such a drastic change in the white level so quickly?

[Mr.RC-Cam]

Anyway, do you think it's a problem with the OSD output when this feature is enabled? Or is it a problem with the Oracle seeing such a drastic change in the white level so quickly?

That is a common symptom of Video Sag and it involves the wireless video Tx or Rx (usually both). Fast rise time / over-driven white levels, especially when adjacent to black levels, is one of the things that invites the problem. The fix usually involves reducing the OSD's white pixel levels (without reducing the sync levels). Some OSD designs have a software feature for controlling their pixel brightness. Whites should never exceed the 1Vpp NTSC/PAL standards, but unfortunately I have seen a variety of OSD designs that do that.

Wireless video Tx's and Rx's that do not have calibrated video levels will add to the problem too. But I think you are using a dpcav.com 900MHz system, which is properly calibrated for each customer. You will probably need to perform the video level calibration yourself if you made the purchase elsewhere.

Edit: A possible temporary band-aide is to dumb-down the Oracle by reducing its sensitivity to the lowest setting. If the video sag is not too severe then this may mask it.

[twinturbostang]

Yes, I'm running your 900 Pro Tx and matching Rx, along with a second Rx purchased from Range Video a couple of years ago.

I have already reduced the sensitivity of Oracle to "Low" (if I remember correctly). However, I prefer to have the switching sensitivity set higher so that it switches receivers quicker when encountering normal noise or multipathing.

I don't believe DragonOSD has a pixel brightness setting. I've heard Daniel Wee (designer of DragonOSD) talk about adding a resistor across the camera leads or in series with it. And I think it's to help with what you say... to bring the voltage levels down. I could try that and see if it helps. Any thoughts on that?