Jump to content

Attention: RC-CAM.com will be closing down August 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 is being announced now (March 2021) so that everyone has 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.



DaveThomasPilot

Trusted Member
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DaveThomasPilot

  • Rank
    RC-Cam'er
  • Birthday 12/14/1954

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Location
    Raleigh, NC
  • Interests
    RC helicopters with video downlink and gadgets, instr rated private pilot
  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 sto
  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
  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 i
  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 trigge
  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
  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 indicato
  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
  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 hou
  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--t
×
×
  • Create New...