Doofer

Trusted Member
  • Content count

    284
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Doofer

  • Rank
    RC-Cam Mentor
  • Birthday 12/16/1963

Contact Methods

  • Website URL
    http://myweb.tiscali.co.uk/splat
  • ICQ
    0

Profile Information

  • Location
    Nottingham, UK
  • Interests
    Gliders (especially slope), electric, heli, submarine, rockets, quadrocopters
  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!)