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.


Trusted Member
  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

1,550 profile views

pseddon's Achievements


RC-Cam'er (2/4)



  1. Very interesting - thanks for publishing it. Peter
  2. I personally use a slightly different technique so here are the main differences: 1. I cut the legs off the dead chip right next to the chip body using fine wire cutters and then carefully remove each leg from the pcb using the iron. 2. Clean up the pads. 3. Align the new chip and solder one of the corner legs and check that all the pads are aligned. 4. Solder all the other legs without bothering about solder bridges. 5. Using desolder braid apply to each set of chip legs and run a hot soldering iron the length of the braid to remove excess solder. I also use a jeweler's loupe to inspect each leg before applying power. It's very satisfying when it works isn't it? Peter
  3. This may help from the OfCom website in the UK OfW311 Radio Contolled models: IR 2030 (available here) sets out the criteria that must be met by certain short range devices, in order to qualify for exemption from the need for a licence. It provides for devices that operate on 5.8 GHz (IR2030/1/23 on page 21) and permits airborne use though radiated power must not exceed 25 mW EIRP. We believe that this could cover video cameras. and this for the 2.4Ghz band Additionally, the Wideband Data Transmission Applications (WBDTS) at 2.4 GHz may also be used for model control. Apparatus is allowed to operate at higher powers than the General Non-Specific Short Range Devices. Peter I have a vague recollection that power on 2.4G is 100mW EIRP
  4. Good news!!! Looks like changing the start bit pulse width to 2mS has fixed my problem as the 9x now talks to me. I should point out I am using a gruvin board so it is a somewhat unusual setup.
  5. Thomas, Ok I think I have found the problem - it's not the datasetup time but the start pulse width. A review of the SOMO-14D data sheet (rev 5) showed the following: Start bit pulse width 2mS min (tstart) Write Datasetup 1uS min (this seems to be at odds with your figure of 125uS) (tds) Clock High/low width 100uS min (tch/tcl) The Open9x firmware for the Gruvin board has a very low datasetup period of 250nS - on my test rig I couldn't get the voice board to fail however low I went (probably 125nS min). The start bit measured on my Gruvin board is 1.5mS but in my tests the voice module fails at 1.6mS min. As the somo14d.cpp comments that it is set for start and stop times of 2mS I'm not sure what is going on here. My knowledge of C firmware is very rudimentary so I can't verify the comment. I also found that the Clock pulse width needs to be a minimum of 175uS (total clock period of 350uS) otherwise it would consistently miss one file in a sequence of voicing 256 files. It fails totally at less than 20uS - I haven't tried replacing that one file it fails upon so the 175us may not be quite correct. I did not measure the clock pulse on the gruvin board but I suspect it is much longer so I don't think that is an issue. I hope someone will be able to check their gruvin board and the somo14d.cpp file and do me a recompiled version - I have posted in the 9x forum. I'll keep you posted, regards Peter
  6. Thomas, I think you are probably right about the data setup time. The gruvin9x board voice software was written by Cam (th9xer) who compiled me a special version (http://9xforums.com/forum/viewtopic.php?f=45&t=1947) to increase the setup time from 250nS to 1uS which is what I am using at this moment. As the delay is inside the interrupt routine he felt it could not be increased much further and as his SOMO board worked with no delay he hoped 1uS would work for me. In my test system I am using about 3uS which works so I may be able to get away with much smaller than the datasheet (not good practice!). I will measure the minimum delay I can use of my test system and then talk to Cam. Peter
  7. Hello again - an update on my sound module problem. I set my micro test rig up using the timing from the SOMO data sheet (I am relying on the on-board reset) but interfacing with series 330R resistors rather than resistive dividers. Great it counts correctly from 1 to 100 so it looks like the module works correctly in serial mode. I haven't tried it with sounds above 100 so that will need to be checked. I quickly put it back on the transmitter and all was silence. As the transmitter uses quite different timings I will simulate them to eliminate timing issues. Peter Peter
  8. Thomas, Thank you for such a very detailed response. You have given me a great deal of food for thought which will make me relook at everything. Whilst I did have it partially working when connected to the transmitter, it was random which made me think there was a timing issue. I became concerned about the data setup time and decided to put the voice module on to a test rig so I could play around more easily. I'll keep you posted. Peter
  9. Thomas, Thank you for the offer of help. This is the thread that I have been seeking help from:http://9xforums.com/forum/viewtopic.php?f=45&t=1916 and http://9xforums.com/forum/viewtopic.php?f=45&t=1947 The Gruvin9x board brings out the PortH of the 2560 to spare pads and the firmware uses that. I had to deduce the connections by looking at the firmware listings. I could not find a fully detailed mod and confirmed the final details from the photos that are posted in the above thread. I used 1.8k/3.3k for the dropper resistors in the Data/Clock lines and directly connected the Busy line back to the Gruvin9x board. So it uses a +5v supply from the Gruvin9x board and the three connections for data/clock/busy and then the speaker is directly connected to the MP3 board https://www.sparkfun.com/products/11125. There are no other connections. It seems most use the Emartee board. I have ordered two of the microSD versions. I have tried 1GB, 125MB and 2GB microSD cards and have more on the way - 1GB are rare so I think it will only be 2GB types. Yes I have been using .ad4 sound files. With all my problems I am now trying to get things working outside the 9x on a test system but so far no joy - but the voice card still works with key inputs so I don't think I have killed it yet! I was hoping it was the very short data setup time that was causing problems and have used 50uS but all I get is silence! Peter
  10. I wanted to use this thread as I am trying to get it to work in a 9x transmitter fitted with a gruvin pcb (ATMega2560) so thought justified! I cannot get the voice board to work on the transmitter - I have included resistive dividers on data and clock - and have now taken it off the TX to try it on a test ATMega system but can't get it to work on that either - the clock and data look good and very occasionally it does output the correct message. I must check the actual signals at the chip clock and data pins to see if there is anything worng there. Otherwise I am confused! Peter
  11. Sorry this is OT but it is a related question. I have a Sparkfun WTV020 module with the microSD card and cannot get it to understand the Serial port. It works in the Key mode without problem. I read that the chip has a number of different modes that are set by the manufacturer. Is that correct? Could I therefore have a module which does not work in Serial Mode and was programmed for key mode only ? Peter
  12. This may help http://www.riccibitti.com/witnesscam/entry/witnesscam.htm Peter
  13. Paul B Mather (Happykillmore) wrote an easy to use GPS emulator as part of his GCS for the Ardupilot series of products. Try DIYDrones.com. Peter
  14. Have a look at this http://code.google.com/p/arducopter/wiki/AC2_Sonar I and many others are using sonar on the Arducopter and it works very well over short distances. If you fly a copter up steps then it keeps a constant height from the steps. The AC has a Planner that allows waypoints to be flown and other actions can be programmed as well. It also has an immediate mode so that the flight plan can be varied as you fly and all open source. Auto lift of, return to home, auto land are all available and the software base is good for conventional helis, 'copters and fixed wing which are catered for by variants of the software. Peter
  15. I fed a Futaba training port from an external joystick (with a processor of course!) and it worked a treat although I did find that if the pulse widths of the external channels were out of spec (I think less than 1.1mS and more than 1.9mS) the transmitter ignored the external signals and switched off trainer mode. Peter
  • Create New...