Jump to content

Attention: RC-CAM.com will permanently shut down on August-08-2021.

The RC-Cam.com forum was the very first online community dedicated to the advancement of wireless video cameras on radio controlled (R/C) models. This is now called "FPV" (First Person View). We are proud of the contributions that our members have made to the FPV hobby.

We've seen significant changes over the last twenty years. Initially there were a lot of eager R/C hobbyist that built their own video systems. Allowing these creative individuals to share their work was the purpose of this site. Now the FPV market is flooded with low cost systems; Sadly DiY FPV video projects are now rarely discussed.

RC-CAM.com (main site and forum) will be closing down August 2021. This was announced several months ago (March 2021) to allow our members ample time to download any information that is important to them. After the site is shutdown the information will no longer be available here.

We appreciate every member's involvement with advancing the FPV hobby. It is indeed sad to say goodbye to all our online friends. Be safe and stay healthy.


Trusted Member
  • Posts

  • Joined

  • Last visited

About DaveThomasPilot

  • Birthday 12/14/1954

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Location
    Raleigh, NC
  • Interests
    RC helicopters with video downlink and gadgets, instr rated private pilot

DaveThomasPilot's Achievements


RC-Cam'er (2/4)



  1. If I get a packet gets through, everything for the next 3.5 seconds is ignored. So, rather than bother with the extra bits required for the packets that support auto-ack, I just resend the packet several times, until it's too late to matter anyway. The receiver throws away all packets it receives for 3.5 seconds after it receives the first one. So, having the receiver send an ack packet and the transmitter conditionally resending based on whether the receiver got the packet just adds more latency. Didn't want to cloud the issue with this detail, but "now you know the rest of the story". Thanks, Dave
  2. It shows the passes. An important part of flyball is to time release of your dog so that he doesn't cross the start line before the previous dog has crossed it on his way back. The release is 40 or 50' away from the start line so your dog gets to full speed before he gets to the start line. You waste precious time if you release 100 msec too early, and get a big penalty (you have to rerun your dog) if you pass too soon. A fast dog will take less than 4 seconds to go from the start line 55' over four jumps, grab his ball, and return those 55' in less than 4 seconds. Frequently, a team wins or looses based on how well the handler's pass. Typically a team member will be dedicated to "calling passes". He watches for when the returning dog breaks the start line plane and notes how many feet away from the start line the outgoing dog is at that instant of time. A good pass is 1 or 2 feet. That corresponds to about 50 msec per foot. I have lots of video showing humans can't really do this. And most people don't believe how bad they are, like calling the pass 1 or 2 feet when it's really 6 or 7 feet. But, without good feedback from the pass caller, the team can't be truly competitve. So I got a system working that takes a snap shot and a few additional frames for slow motion replay starting at the instant the returning dog breaks the start line plane. This is displayed on monitors competitors and spectators can view. Everything is saved on a pc so people can later proudly point to their great pass. Anyway, this has been up and working for a little less than a year. But, I've had some intermittent missed triggers at some events that might be due to WiFi interference. Hence, the diversity receiver, hard wire option, and firmware to identify good/bad channels and missed packets. And the question whether a directional antenna is likely to help too. It's all just a hobby for me--I'm paid nothing. But it's a really fun project and it is really appreciated by the competitors. Thanks, Dave Thomas
  3. Mr RCCAM, I haven't really tried reducing transmit power. I recall the same thing when I was trying to eliminate video drop-outs due to multi-path. I guess I thought since my baseband was digital instead of analog, things might be different. But, I can dynamically change the transmit power and see if that helps. Thing is, this type of characterization is only valid at the real venue. Maybe I should add a command that counts missing packets on a given RF channel at various power levels. Shouldn't be that hard to do. Thanks, Dave Thomas
  4. I can't really do much at the transmit end. That's pretty space constrained. The transmitter along with my custom pcb has to fit in a 2" pvc cap. This sits on top a 3' piece of PVC which is full of stuff I can't mess with. My pcb senses a led turning from red (light curtanin interrupted) to green and transmits a trigger for a "photo finish" sort of thing (I'd have to talk about flyball here to better explain). I've used both an antenna on the pcb layout as well as a "rubber ducky" antenna that extrudes from the top of the pvc cap. I haven't noticed a difference in how they work with interference, but I'm only now adding firmware that will count missing packets. The receiver end is not so space constrained. That is typically mounted on the ceiling and cosmetics don't really matter like they do on the transmit end. So, I was thinking a Yagi at the receive end my help. Don't know much about circular polarization pros/cons, but I'm guessing it wouldn't make sense to use a CP receive antenna if the transmit isn't only CP? I also have a LVDS transmiter and receiver on the custom transmit/receive pcbs to use when hard wiring is an option or the interference problem really can't be solved. But it's not very practical to hard wire from the transmitter to the receiver in many venues. Thanks! Dave Thomas
  5. Changing to a different frequency band really isn't an option at this point. And the interference is not THAT much of an issue. Missing an occassional trigger isn't a killer (say, one out of a thousand). I'm just trying to make it as robust as practical given my constraints. I've added a second "diversity" receiver so the trigger can be sent (nearly) simultaneously and receiverd on two separate 2.4X frequencies. So this should decrease the missed triggers dramatically (haven't tested this yet). Also, eerything is now "frequency agile" -- the frequencies (2.4x Ghz) used for triggers can be changed on the fly based on congestion metrics or packet loss statistics. Haven't tested this in the "real world, demanding environment yet either". Won't happen until a big event late January. And, my application is not nearly so demanding as wireless video from a flying model. In my case, the transmitter and receiver are in fixed positions, and only 20 or 30 feet apart. The signal from my transmitter can always be much stronger than any noise source. I might be able to improve the S/N by simply using a "bad" antenna. Bascially, anttenuate both signal+nosie, then crank up the transmit power to achieve higher S/N. Without some attenuation at the receiver, I worry that excessive transmit power might saturate its front-end. So, that brought me to a consider a directional antenna. I really don't care how much "gain" it has--lossy may even be good. I just need something highly directional. Thanks for the reply! Dave Thomas
  6. I used to actively monitor this forum. I learned a LOT from Mr. RCCAM! I'm now working on a project that has wireless "triggers" on a 1 Mhz channel between 2.4 and 2.525 Ghz, using Nordic NRF24L01 chips. Everthing works well, except occaisonal interference from Wifi (I think). I'm doing lots of stuff to minimize the interference, like scanning the channels for RSSI, sending a bunch of packets on each channel to find the ones with minimal packet loss, etc. Another option I've thought about (and remembered this Forum) was use of a "high gain" antenna. In this context, I don't need higher receive signal strength, but rather just a narrow beam width. What do you think? If I use something with a narrow beam width and aim the receive antenna at the omni transmitter, am I likely to reduce problems from interference? The application is indoors (lots of multi-path) with potentially hundreds of Wi-Fi users. I was thinking something like a pringle can might be work. The receiver is always "aimed" at the transmitter anyway, since it's a camera that is taking a picture of the area around the trigger. (using auto-ack, retransmit, etc doesn't help, since the trigger needs to sub 1 msec latency--resending the trigger later doesn't help). Thanks, Dave Thomas
  7. Bummer, I snoozed and loozed. Wanted one bad. Anybody who wants to sell, let me know. Dave Thomas
  8. Hey, you're talking about me! I've been playing with video overlay using a Cypress PSOC instead of a MicroChip PIC. I'm really just getting started. I've got the syncgen stuff working (the equivalent of the LM1881) and have been talking with Mr. RC-CAM off-forum about how I want to proceed. Basically, what you are asking for is on screen display of a servo pulse width. 1.5 msec pulse (neutral) would result in centered glyphs. Deviations from the nominal servo pulse width cause glyph displacements similar to how the AI indicates pitch and roll attitudes. The flyer uses the indicator to get the heli pointed at the camera subject. Have I got it right? The PSOC has quite of bit of hardware resource available. An extra timer block time multiplexed between the two servo channels would be required. The nice thing about the PSOC is that not only does it have an abundance of configurable hardware resources, these resources can be dynamically reconfigured under software control. So its possible the chip could be programmed with a jumper to be either an character OSD or the servo pulse width indicator. The digital blocks for the the UART function could be used for the servo pulse width timer function, if digital block resource becomes critical--but so far I'm not hardware resource limited. Mr. RC-CAM, do both the camera man and the flyer see the same display? If so, your idea (I think) of the camera man moving a cursor to a screen position that indicates the object of interest would make sense. But I thought the problem to be solved was that the camera man sees the object through one camera while the flyer is using a different camera. Hence, the difficulty in the camera man communicated the desired attitude change to the pilot. Dave Thomas
  9. Hey, it looks like it's working! Did everybody catch the readout of the battery voltage that occured periodically? Neat! Good job! I agree the gain looks a little too high. Also, I'd expect the relationship between sensor voltage and attitude to be non-linear. Does a voltage delta correspond to a constant displacement of the glyph, or do you use a look up table of some sort to try to "linearize" the sensor output? Something like an "expo" setting. Again, good job! Dave Thomas
  10. Thanks, Mike. I really need to know the codes for the functions on the Sony camcorder. If these happen to be for the Sony Handycam, that would be great. But if I implement the code (on a PSOC) and (when) things don't work, it would be difficlut if not impossible to know whether the problem was in the implementation of the LANC or simply because the wrong codes were used. (And the LANC implementation won't be useful without the right codes). Maybe they are the same as the IR codes? Does anyone know if this is true? Or, I can always just interface through the IR detecter via an IR emitter... Thanks, Dave Thomas
  11. This may have been covered before in this forum, but does anyone have a pointer to the LANC protocol used by Sony Video cameras (like the HandCams or the newer, MicroMV cameras?) Thanks, Dave Thomas
  12. Thanks, Mr. RC-Cam. This probe is a "Probe Master" PM4901. It's labelled as a 150 Mhz probe. Got it with the scope at a Hamfest. A buddy also says it should be trivial to fix, so maybe I'll get around to buggin it. Pretty simple, though as I'm looking at it now. It looks like the base only has a resistor pot and a capacitive trimmer. Only the resistor pot is accessable when the housing is on the base. Can't see much a the tip, other than the center wire solder connection (looks good). There is a three position switch (10X, gnd, 1X), but I can't figure out how to remove its housing (in the probe tip) or if it's even possible. Anyway, the probe works fine as long as you don't want to watch something with a slew rate greater than a couple of volts per microsecond. I've used it a lot on audio frequency work with no problems. Doesn't hack it for video, at least not for trying to observe the 4 usec H-sync pulses. Dave Thomas
  13. Bad scope probe. Borrowed scope probe from work, now all looks good on my scope. Funny, don't see how a probe could fail this way--amplitude is correct in both 1X and 10X modes but it is very slow or capacitively loads the video input. Dave Thomas
  14. Val, I've never had much luck in using the CoPilot at our flying field. Our field is next to a large lake, so I thought maybe that's why the co-pilot didn't work well for me. It would correct attitude to near level, but I could never trim it or adjust the mounting of the sensor so that it wasn't "fighting me" for maintaining a perfectly level attitude. Do have similar problems using your CoPilot for stabilization at your flying field (at the same altitudes as your AI test video?) Dave Thomas
  15. Turns out there must be something wrong with my scope. I used the scope at work, and everything looks good--I'm getting a valid composite sync signal that incudes the horizontal sync pulses. The H-sync pulses are about 4 usec wide, so my 60 Mhz scope SHOULD easily have sufficient slew rate to see the pulses. I tried both oscope vertical input channels and each appear to be slew rate limited. I wouldn't expect much common circuitry between the vertical amps, so maybe I have a bad probe (I only had one available). Anyway, I now have to figure out why my o-scope seems to be such a dog--the LM1881 and PSOC work fine for extracting sync. Dave
  • Create New...