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 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.



Doofer

Trusted Member
  • Posts

    284
  • Joined

  • Last visited

Everything posted by Doofer

  1. Feeling a bit paranoid, but has anyone else noticed that duck tape (usually grey, sometimes white, black, other colours) has changed in the last 18 months? Whether it was brand-name 'Duck Tape' or numerous lookalikes, it used to: 1. have clear fibre strengthening 2. would only occasionally 'lift' after putting in place 3. if you let the sticky side touch itself before placement, you had to throw it away, as the adhesion strength was almost as strong as the tape itself. All that has now changed. I have bought several different varieties over recent months, 'Duck Tape' and grey brands, and it now seems to: 1. have lost much of its fibre strengthening, acquiring tiny perforations across its width to assist tearing 2. invariably lifts off the surfaces on which it was placed if left for a few hours 3. if you let the sticky sides touch, it is now very possible to pull the sticky bits apart. I'm not that bothered about 1., but duck tape used to hold the world together, because it used to stick, as my brother would say, "like sh*t to a blanket". Now, thanks to behaviour 2., it is suddenly almost useless, unless one can repeatedly check and re-apply it. (As I mention above, point 3. seems to me the best objective test for 'old vs. new') I may just be unlucky with my local supplies. It might be global warming, although I used to know the difference between summer and winter use especially with regard to 2., and I am now sure it's changed. Fashioning a tinfoil hat as I type....
  2. I can always use my Oracle and a couple of Airwave RX's... Did you ever make a smaller version? Even stripped down to the board + servo sockets for connections, it's a fair footprint...
  3. Rats - thought I'd nailed it. With the FT951 (same manufacturer) Channel B has the hairy sync pulse, Channel A is clean - faulty Rx syndrome. But then back to Airwave transmitter, and both Channels have the noise on the picture, I'll probably see if a local supplier will let me have one on 'success or return'...
  4. I guess I was hoping that if it was a known problem, someone would suggest some component in these things that could be altered... Mind you, looking in detail at single shots on the scope, the sync pulse outputted from my FR632 contains bursts of something at a much higher frequency, totally absent with other receivers. I am wondering if it's just a faulty one; I get this even with a FT951 transmitter, which is from the same manufacturers as the FR632! Also, given that no-one else is moaning about this receiver, I'm inclined to think it may just be a faulty one.
  5. Trying a 10mW FPV Hobby Tx, the picture looks alright, although the sync pulse still looks a bit odd
  6. 5.8GHz seems to 'need' diversity less than 2.4GHz in terms of dropouts, but even so I thought I'd try the new FR632 diversity receiver for a local plus high gain arrangement. Bench tests seemed okay, but on fitting it into a real system I found picture roll on some screens, intermittant 'interference' across the middle of the screen on others. Swapping the part out for an Airwave module or a 5.8GHz single-input 'scanning' receiver gave a perfect picture, so I suspected a sync problem in the FR632. On the 'scope' the outputs are different (see attached) - FR632 - Airwave - Scanner. Everything else was the same - okay, there was a OSD message flashing on and off in all three cases, which probably explains the slight extra 'detail' in the video trace for the Scanner. The Airwave and Scanner outputs, although at different references to earth, look fine, with a clear sync pulse at the beginning. In practice these receivers perform well. The FR632 looks odd, and is awful. Any suggestions how I might fix this? Online reviews of the FR632 are full of praise, so presumably it's just this one...
  7. Thanks, yes, firmware 1.18 recommended by Rngevideo for PAL 'All problems sorted out now'etc. So I have to assume, with 1.18 now installed, this is as good as it gets...
  8. Okay, so not a subject folks can add to there. Mind you, now I'm using my Headplay goggles for FPV, I'm wondering if my eyes need upgrading Headplay 'should' be better than my (now getting quite old!) GCD 640x480 goggles: 1. Higher resolution (800x600) 2. Adjustable parameters (sharpness, saturation etc.) In practice so far, I'm not finding this to be the case. 3. The HeadPlay has a narrower 'window' for optimum eye position - move the unit just a little on your head and the image does out of focus, especially at the edges. Probably something about the depth of field. Not fun trying to adjust this finely once something is in the air. 4. I'd swear there is a latency issue. Movement of the whole image generates little strips of image at the edges. I don't get this at all with the older goggles, which just present movement smoothly, whether it is just a little or a lot of the image moving. I'd read about 3, but 4 surprises me. It could be some processing overhead which slows down the framerate on moving the whole picture. Or, perhaps the edges of the image are sharper in the HeadPlay, whereas in the old GCD goggles the image isn't so crisp, so these movement artefacts are just more obvious. Either way, in practice, I find the HeadPlay really quite distracting due to this effect. Perhaps I should try flying on a cap-mounted screen - MR RC-Cam, did you get anywhere with your baseball-cap screen?
  9. Hi there. Does anyone know how the Headplay goggles connect to the base box (aka 'Liberator'.... "Long live Blake!", in case there are any 1970's UK Sci-Fi fans out there)? I made life MUCH easier for myself by replacing my RVision control box and two short-ish cables - always in the way, connectors pulling out etc. - with 4m of stereo cable (+v, gnd & composite video), soldered at the goggle end. It seems the Headplay goggles might be more sophisticated than the composite IN displays of the Rvision. But 'The Liberator' is very big, and the cable pretty short. I asked Headplay, who replied: "If I remember correctly, the cable length is restricted to that length for technical reasons. I don't recall the details but some combination of signal strength and emissions determined the allowable length of cable. I don't have access to the technical specifications you are requesting." I then asked if they could ask their manufacturer for some info on the interface, or a contact - name, even - of the manufacturer, but have had no reply. I guess at least I now know it is 'for technical reasons'. Rather than issues of fashion or creed, presumably. So, anyone out there know anything about this? Even if it's LVDS or somesuch, a small inline buffer is going to be less likely to cause trouble than mounting that big box somewhere close. In the field, 4m of cable from goggles to base station is very nice!
  10. Helix1, considering many online forums, this is a refreshingly practical one for people who make real things and try them out. Your big brother/best mate/esteemed colleague/whoever may well be bigger/brighter/right more often than Old Man Mike's, but - a word to the wise - a line about something you've built and tried out in the field is invariably of much more interest to this forum than multi-page lecture notes. And please note that no-one is the least bit interested in how credible you, or Old Man Mike, or anyone else is. We just want to know what you're up to and what does and doesn't work, so we don't have to waste our time repeating experiments done elsewhere. Register as a member, crack on and build this doohickey, and let us know how you get on - we're all very interested in that!
  11. You didn't say what sort of helmet you're using. It seems the most 'suspicious' feature you report is the lack of audio signal in normal use - suggests to me that it's not working as intended. 'Ear bone' mics fit tightly in the ear and pick up from the skull, 'jaw bone' mics pic up from close contact with the jaw... but a 'top of head' bone (skull) mic is only going to work well if you're bald, or you move your hair out of the way of the transducer. Just sitting on top of your hair, getting good enough contact to get bone vibrations might be a big problem. Looking at that device, and the services they provide for (emergency services) I suspect those are all fairly enclosed-design helmets. I wonder whether it is more an air acoustic device working within the confines of an enclosed space (the helmet), rather than bone contact. I would contact Savox and ask if there are any special requirements about the helmet type, and perhaps in the meantime try some other helmet types...
  12. Interesting - a reply from Xaircraft. They've clearly stepped-up customer services! "Stuart, XAircraft X500D adopted PPM asynchronous input. After installing receiver on X500D,connect to PC and poke the joystick.It can be checked out by seeing signal mast graph on PC software if signal lost in about 0.5 second.In that case, framerate can be tested whether it's lost. As for the slide on the flight, it may be caused by ESC or motor malfunction. It's advised to hold X500D onto the ground, throttle up what you need in the fly, after a while check out the four motors' temperature whether is the same as well as the output power.What's more, throttle signal is transmitted after attitudes calculated by flight control algorithm to ESC rather than straightly to. Asynchronous phenomena on your X500D will be probably caused by ESC or motor failure." I think they are saying the X500D can accept asynchronous inputs. The PC software they refer to is clearly something different from that supplied to me. As for the slide comment, I think they are confusing with sudden slides at low altitude (ESC overheating) with slow, un-recoverable slides at altitude. It's the latter I seek a solution to; I guess GPS position lock would have the same effect as the (reputedly highly-sensitive) FY20A linear accelerometers. However, they're talking! I will ask for the PC software they're talking about, and if there have been firmware updates.
  13. Status is that I can either have the 'comb' cut out my throttle every 3secs for long enough to make it fall about 20ft each time, or I can adjust the sequence of channels to get brief cuts in throttle a couple of times a second. Either way, not really enough consistency to judge whether the FY20A is doing anything... unless I conclude it's deliberately doing all this, in which case I'm far better off without it! I'm awaiting a response to an inquiry about asynchronous firmware from Xaircraft (who made the X500D), and a similar query on the discussion board at RC Groups that Adrian at Fyetech suggested I should direct queries to - a Mexican stand-off, as Fyetech can blame Xaircraft for not coping with asynchronous inputs, and Xaircraft can blame Fyetech for not providing synchronous outputs. So, realistically, I could wait for Terry to implement his 'easy' synchroniser PIC... or even have a go myself, although I've avoided them so far. I'm not even certain the FY20A is the solution to my challenge, which is to get sufficient stability in X & Y at height to prevent uncontrollable slides. From what I can see on the web, I should just try a more sophisticated quad board with position lock or somesuch. But I hate to put hardware in the bin unless I have to. (I'm also building a tricopter, along the DIY 'one heli heading-lock gyro per arm' model. Assuming it flies, I will be able to fit the FY20A to it via a CCPM mixer such as the ACE TG6100M. Okay, in a way I'm getting away from other people's bespoke firmware by such an approach, in another way I'm not. With heading lock gyros $10 a pop on eBay, a cheap approach, tho'....)
  14. It's easy to imagine a situation in which, given different damping time-constants, the FY20A and the Gaui board constantly fight each other. Without access to these parameters, might seem hopeless until you remember the parameters are trying to model the real physical world (masses oscillating around notional CofGs), so perhaps experimenting with a few weights on the arms, to alter these, might have an effect? (SO frustrating to not be able to take part in these experiments!)
  15. Perhaps the gain/wobble needs sorting at the Gaui end - adjusting the PIDs if you have access to them. Easy reference (in mangled engineering english) at the end of this manual for the X600D (the next generation after my quad, which has no such adjustments alas).
  16. Yup, it's a slightly different frame length, so straight-through channels slowly slide over all the channels output by the FY20A. I tried capturing the screen output, but that didn't work, so I went looking for a camcorder then got distracted, made some tea etc. Just imagine two combs slowly moving past each other, and that's what it looks like. I've never had a reply from the chaps who make the X500-D (over their overheating ESCs), so I don't have much hope that they'll update the firmware...
  17. Perhaps this is the time I finally use a PIC solution - anyone know of widget that takes 4 PPM inputs and synchs them to a single frame rate? Such a pain - manufacturers really should mention it somewhere if their inline device doesn't preserve sync...
  18. Okay, no, re-setting doesn't help. Looking at the outputs on a 'scope, Rx outputs vs. FY90A outputs are two combs slowly going past each other i.e. the FY90A is clearly imposing it's own frame rate on the control outputs, and isn't synching to the Rx inputs. So if the X500D is expecting inputs in order, yes, the throttle will seem to keep going out of sync. Hmmm... the question is, whose problem is this? At least the FY20A folk reply to emails, I'll see what they say - Why are they selling something you put in some signal paths & not others that doesn't sync to the original input frame? Seems a simple question, should have a simple solution, if only the FY20A were flashable....
  19. Close!... but no cigar. I've found that using a different Tx (MPX Cockpit) I get a different effect - the power still pulses down, but the pulses are much briefer, and more random, occuring every ~0.5-0.75 seconds or so apart. And still no discernable difference between different control settings. Interestingly, your suggestion - I've mapped the throttle to Channel 9 - changes the Royal Evo 9 performance to be pretty much exactly the same as this. So yes, something about frame length, frame desynchrony, something like that. Irritating. I'll dig out an old jap 5Ch Tx, and see what that does. Must get it on the bench and look at the FY20A outputs vs Throttle output on my o'scope...
  20. (Well, consistent - no-one else using FY20As with the Gaui board are reporting problems!)
  21. Yes, confidence is an issue with quads, as unless all the active stuff is working fine, they fall out of the sky. I've had a fall from about 100ft - presumed Rx glitch. I've had the "sliding uncontrollably at height" problem, which isn't completely consistent. I've had a 'partial loss of power on one ESC through overheating' problem, although after much soak testing I think I've solved this (fit little IC-type heatsinks on the ESC chips). Thankfully the X500D board does have a 'universal' LBV alarm, although it cuts in a bit late, as if to explain why the quad is sagging out of the sky i.e. it's set a bit low. But at least it sounds before the ESC LVC's kick in! Further FY20A tests. I've tried the reset procedure - no difference. I've also tried pinging it up to about 30 ft, so when the power pulses off it doesn't hit the ground before it comes back on again; amusing to watch, and strongly suggesting that apart from the power glitches it is working! But not a sensible way to fly a quad (boing boing boing....). I can't think of an attitude control input combination that would cut all 4 motors, so I'm wondering if it is something to do with the 3 attitude controls having slightly different timing relative to the throttle control input - since the throttle bypasses FY20A. But if this were a problem, I wouldn't be alone, and these days if I google a bit and no-one else is having the problem, it's invariably not the problem I think it is! Having said that, the X500D isn't that common...
  22. Good idea. I've been using a Multiplex Synth IPD 7Ch, the same receiver type I used in the 'plane. Still, it could be that receiver. So I just tried: - another Multiplex IPD 7Ch - same effect. - Multiplex DS IPD 9 Ch Rx - same effect. - Corona RP8D1 - same effect. So it's probably not the receiver, but worth a try!
  23. Pity - I've fitted my FY20A to my X500D, and have hit an interesting problem - the power pulses (briefly) OFF to all 4 motors every 3 seconds or so, regardless of the throttle setting! Now, the throttle channel doesn't go through the FY20A, but the X500D's onboard IMU/CPU varies power to all four motors continuously to keep level... BUT what exactly is the FY20 doing to the ail/ele/rudd inputs that is persuading the X500D's brain to cut power to all 4 motors every 3 seconds?! I've tried hooking it up in a conventional ail/ele/rud 'plane, just to check, and it seems to do what you'd expect. Red & blue LED's don't suggest there is a problem. Flies fine without the FY20A. So, some sort of strange interaction between the FY20A and the onboard IMU/CPU? I would be interested in your experience with it on the GAUI - different IMU/CPU/firmware, of course...
  24. Lot's of interesting information here: http://www.rcgroups....ght=fy+20a+330x
×
×
  • Create New...