Jump to content

All Activity

This stream auto-updates     

  1. Last week
  2. Earlier
  3. Causing interference and failing to provide station identification on amateur radio frequencies. All that for the low price of $18,000. https://www.fcc.gov/document/eb-imposes-18000-fine-against-amateur-radio-licensee
  4. Yes, be careful with the hot air. The nearby components may reflow; Then they can move off their pads while you wrestle with the SAW chip. That's exactly what happened to one guy that messed up his SAW chip upgrade.
  5. Good advice!! I got some chip quick which i can use with hot air station.Not sure if hot air can damage the adjacent components?
  6. Low risk for heat damage. The SAW construction is similar to a crystal oscillator and can take normal rework / soldering temperatures. Besides the three pin legs, the bottom side of the filter is also soldered to the PCB. It takes a lot of heat to reflow this hidden region. After fully desoldering the three legs with your Hakko vacuum tool, you can move on to the hard part. I suggest using two soldering irons, one on top of the SAW's metal case and another on the bottom of the PCB (on the copper area that is under the component's center area). Apply extra flux and when the PCB is hot enough to reflow the hidden solder the SAW will come right out with a gentle pull. Don't force it, you don't want any PCB damage.
  7. Thanks Thomas. I will first try flying long range and compare it with my existing RMRC comtech with saw filter already modified with D480A.If the difference is not much then i will leave it alone. Regarding PCB rework,i am not that expert but i think i can handle this.I got Hakko desoldering vacuum gun which should help in case i need to replace.So far i have replaced main MCU on my frsky QX7 transmitter after i nuked it when accidentally i supplied trainer port with 5v and also some RAM chips on my VW diagnostics tool. Are these SAW filters temperature sensitive?
  8. If it has a 27MHz SAW filter then replacing it with the ECS-D480A filter will add a couple dB of gain. But be aware that removing the old filter is difficult. Some people that tried it caused some damage that reduced RF performance (or killed it). So don't attempt it unless you have strong PCB reword skills.
  9. Hi Thomas, I just got hold of 2 used range video receivers.I tested these receivers by placing clode to my dragonlink antenna(at full power settings) but no interference at 1280 MHz. So i thought they must have been modded by D480 saw filter.But when i opened it,i found NM F480-2 and it looks like 21 or 27 MHz filter. So wondering is it worth to swap the saw filter on these receivers?Please suggest.Thanks.
  10. It seems unlikely that resetting cleanflight would prevent binding the radio (transmitter) to the receiver. Do you mean you can't arm the drone? If that's the problem, then I suspect you need to correctly set up the channels in cleanflight. Some suggestions are discussed here: https://blog.dronetrest.com/quadcopter-not-arming-how-to-solve-in-betaflight/
  11. ive reset the walkera rodio 150 by mistake through cleanflight and now i cant get the remote to bind with the drone any suggestions please
  12. You are welcome. Thanks for letting me know you got it working.
  13. That might be the reason. The R/C servo signal must be present when RCFS boots up. If the servo signal is delayed when the receiver is turned on then RCFS will ignore programming mode. Try the test again. But disconnect RCFS from the receiver before starting the test. After the receiver is powered up and confirmed working, plug in RCFS while holding the programming button. Confirm the flashing LED while the button is held/pressed. Then proceed to step 2 in my previous post to see if the problem is resolved. BTW, what brand/model receiver are you using? It should be an old analog design with simple shift register decoding (no microcontrollers) that uses 50Hz framerates. That's what was commonly available in 2005 when this project was created. AKA, the good old days. Also, if you have an oScope then please post a screenshot of the servo pulse waveform.
  14. All good up to step #3. The LED never gets to rapid flash. I don't think it ever enters program mode. At any time after power up, I can hold the button and the LED will slow blink, just as it does when holding the button and then powering up.
  15. All your observations seem reasonable. As a test, follow the steps below and provide feedback. The RCFS will be set to Hold mode with Impulse Filter data averaging. 1. Turn on R/C transmitter. Remove power from receiver & servos. Press and HOLD the button on RCFS. Apply receiver power. The LED should flash. It should continue to flash until the button is released, then turn off. Is this what you see? 2. Next, press the button TWO times to enable the hold mode. This must be done within five seconds of entering programming mode. Did you see the LED blink after each press? 3. After the second press wait five seconds. At the end of the five second wait the LED should change to a continuous rapid flash. Do you see this? 4. As soon as you see the flashing LED, press the button once. This enables the filter mode. The LED will acknowledge by a single LED blink and programming mode is exited. 5. R/C system operation should be normal at this point. Confirm the servo operates correctly when the radio's stick is moved. 6. Press RCFS button once. It will blink a pattern that reports its configuration. What do you see? During normal operation (Tx on), pressing the PB Switch will blink out the active Failsafe mode. 1-Blink = Idle mode (servo signal turns off) 2-Blink = Hold mode 3-Blink = Fixed Position mode. After a short delay (about two seconds), the LED will blink one more time if the Impulse Filter (averaging) is turned on.
  16. Yep, system is on, servo operates correctly thru the Fail Safe via the TX. When the TX is switched off, LED flashes rapidly and lights steady, immediately goes out when TX is switched on. I have bypassed the low voltage detection with a jumper from pin3 to GND, no change.
  17. Some thoughts: 1. Is the R/C system turned on? RCFS programming mode will abort if a valid servo pulse is not being received from the R/C receiver. BTW, servo pulse frame-rate must be traditional 50Hz (38 to 62 Hz is allowed). If you have a o-scope then confirm your R/C signal satisfies this requirement. 2. Low voltage detection problem? While debugging I suggest you disable the low voltage circuitry.
  18. Just built two of these with low voltage detection and I am unable to program any of the 3 modes. LED flashes on power up when holding the button and goes out when released but then it won't accept any of the 3 modes. Pressing the button lights the LED but that's it. Any idea what the problem is?
  19. Thank you Mr. RC-Cam, I will try this and post the results
  20. You might achieve satisfactory results by altering cap C1's value. Currently it is 0.1uF, but try 0.22uF. I suggest using an o-scope (or servo pulse tester) to confirm the pulse width values. If necessary, vary C1 and/or R2 until you achieve the desired pulse width range.
  21. Is there a way to make the servo tester work with 1.9k pots instead of the 5k pots? I am wanting to use the tester with a FrSky replacement gimbal PR10. 1.9k is what I measured , but the box states resistance range is 2.4k ohm. Sorry, I wanted to put this under Rc-Cam Projects
  22. Umm, decoding demodulated NTSC even in an FPGA may be a bit more of a hassle than I expected. One challenge is going to be all the DSP filtering that needs to be done to separate the luma signal from the chroma subcarrier and modulation. Decoding color information will require implementing a phase locked loop within the FPGA to lock on to the colorburst, and require analog means to decode it. GNU radio and the SDR community might give me some insight this all works. My first prototype will probably be black and white, and may even have the dot crawl all over everything lol! It looks like an uncompressed digital stream of from something like HD-SDI might actually be easier and "better" as the signal encoding is more "naive" and easy to decode, although finding cheap hackable security cameras that use digital signals over coax is proving to be more challenging than expected. Then again, with uncompressed 720p30 you effectively need more than double the bandwidth, it's just how it goes. Intra-frame compression will help some. I've considered ATSC, too. ATSC occupies the same bandwidth as NTSC, and even uses the same AM modulation! This means you should be able to continue using current 5.8GHz transmitters, a huge plus! But ATSC does rely on video compression algorithms, which makes it a stateful system and bit errors take some time to resolve. (like if you lose too much data within a frame to fully reconstruct, that bad data must be used to calculate future frames and adjacent pixels, leading to the classic digital corruption look with several blocks of bad pixels being shifted around until a full I-frame is sent to fix accumulated errors) So it stands to be scene how flyable a system like this would be when the whole image gets corrupted for up to a couple seconds. I suspect the best approach is to use ODFM modulation as it was engineered specifically to be resilient against multipathing and doppler shift, combined with a video compression algorithm that relies mostly on intraframe compression (to prevent 1 corrupt frame from screwing up the rest) and can tolerate errors elegantly (such that the result is simply increased noise, or reduced resolution rather than missing blocks). ODFM is outside my scope of knowledge, it would require a PhD in RF electronics to do it right! Unless there is an IC that allows ODFM communication over 5.8GHz band. If anyone knows of a digital video transmission that meets these requirements, can be transmitted over a single channel, and occupies the same bandwidth of NTSC, I'm all ears! So far the only thing that comes to mind is ATSC and EX-SDI.
  23. OK, I'm joining in on this adventure! I posted on reddit asking about AHD video systems wondering the feasibility of them. Looks like it isn't a totally far-fetched idea! My thoughts on the AHD system: Mr.RC-Cam, I commend your progress , I saw the DVR video of the FPV using AHD system, this would be a promising avenue for higher quality on small builds. There is still some work to be done as you pointed out, we need improve error handling a LOT, and allow the signal to degrade gracefully. It looks like it is FM moduated, which has the characteristic of digital where it either works or it doesn't (compare the footage at 53:00 vs the rest of the video). Frequency Modulation also wastes bandwidth which isn't desirable, but it does help with the noise immunity... I'm wondering if the AHD standard can be modified even more to allow 720i60, I think 60i would be better than 30p as it would have 720p resolution with still image and about half that when moving but with much smoother motion. Deinterlacing filters have gotten pretty good! You can actually extend this concept of analog video compression to Multiple sub-Nyquist sampling encoding or MUSE, which was a failed quasi analog/digital standard that pushes a 1080i videostream down an 8 MHz channel, this should be easy to do with the current analog systems on the market, as you mentioned with the 960H systems! There are quite a few standards out there: TVI, CVI, AHD, MUSE, then of course the ones that require multiple channels; S-video, component, VGA, etc. The biggest limitation of analog systems is the difficulty in compressing the datastream meaningfully. That is; removing redundancy. You can look into digtial compression schemes to see how it's achieved, but it adds latency by design, AND by reducing redundancy small errors result in much more severe consequences and frame drops! It's a 2-edged sword! Digital FPV: Of course nowadays we can't ignore the presence of the DJI digital FPV system. But I think there are still some advantages to analog as Joshua Bardwell pointed out in his review of them. I for one take some dislike to it for being proprietary, although it is understandable given how much R&D had to go into developing them. Digital systems like this are going to be inherently complex state-full systems. Just look at VP.9 encoding if you want a taste of just how complicated digital compression is! Complicating things further, it seems the DJI system has variable bit-rate, which requires RSSI calculation and a bi-directional link to allow the goggles to report to the transmitter how much power to push! (or maybe not; maybe DJI has ways of recovering partial data better!) The other outstanding issue with digital FPV is not so much that it's digital, it's that it after compression, it's a lot less tolerant to data loss. And compression by design requires having a number of buffered frames as decoding any frame requires the previous frames (they are effectively deltas) and future frames. Like in the case of MPEG, if you lose a frame it corrupts every frame to follow because they build on that corrupt data. RF output / transmission: This is a very hard topic. There are chips out there that effectively abstract this so it isn't too much of a concern unless you wanted something better, but worth noting a high level overview of different technologies: AM (or more accurately, DSB-SC) is what I believe is used for NTSC. DSB-AM is quite wasteful, literally HALF the transmitted power is just transmitting a DC bias, which is mixed up to a the RF center frequency. This was well known even in the very early days of radio, it was used anyway cause it's darn easy to demodulate, literally a single diode (envelope detector) is all that's needed! The fact that it's Double Sideband means that if your signal has 5MHz of bandwidth, it takes 10MHz bandwidth once modulated. FM is even worse! Look at Carson's rule to understand the workings of FM. It is more immune to noise. Again, a trade-off between bandwidth, noise immunity, and quality! It's like there's some theoretical limit haha. Then you have the more advanced methods, like QAM. QAM is still pure analog means of data transmission, it allows you to transmit/receive 2 channels concurrently! an 'I' component and a 'Q' component, which are 90 degrees out of phase with each other which means that changes to one component do not affect the other, they are 100% independent (in theory at least). This allows you to fully utilize the band, so 5MHz baseband takes up 5MHz when mixed up to RF. But now you lack the elegant redundancy of DSB-SC and have more noise susceptibility... You can take all theses methods, and simply feed them with digital data to turn them into their equivalent digital modulation counterparts. AM becomes OOK or ASK, FM becomes FSK (or variants like GSK MSK, etc.) and QAM is still called QAM but with a number at the end telling you how many symbols are in the constellation diagram. More symbols means more digital data within the same bandwidth, but means also higher noise susceptibility and the need for a cleaner channel. Hence QAM tends to be used mostly for high bandwidth low-loss coaxial data links, like cable internet. If you want to get REALLY complicated, just look at the voodoo that mobile phone carriers are doing with 3G, 4G, and 5G. One of the hallmark technologies is the use of ultra wide-band communication with time and frequency division multiplexing and orthogonal frequency-division multiplexing (OFDM) which massively improves on problems like multipathing, which is important for cellular service. I suspect 5G with the touted low latency, may enable FPV over 5G and IP! The latest development here are large antanna arrays where you control the phase of the signal to each one to "beam" a signal in a particular direction. You can constuct a number of virtual signals in an FPGA or ASIC unique for each device on the network and optimize how much of a signal goes to each antenna to "beam" the signal in a particular direction! And each user has their specific traffic beamed towards them by putting carefully broadcasting those RF components on each antenna at just the right amplitude and phase to allow maximum reception. It's over my head for sure! Solving the issue's at hand with AHD: I recently bought a Xylinx Arty Z7 FPGA/SoC with HDMI outputs, and I used a similar dev board back in my university days. I might attempt to build a decoder for these signals and see. Low latency will hopefully be easy to achieve, just make the VGA output each line of data synchronous to the data from the AHD signal. Hopefully I can get a software/HDL ibrary that also allows compression and writing to a file to the SD card slot. Another far-fetched goal of mine is to integrate the recording camera and the FPV camera. Having 2 separate cameras just seems redundant. Why not have a camera that outputs a videostream that can be used as your FPV? Many camcorders offer composite or even microHDMI outputs although these are useless for FPV as they are provided only for purposes of focus, framing/composition, and replaying video on the big-screen, all cases where latency is of little concern. Hopefully I can reverse-engineer one of those little MIPI/CSI camera sensors and use my FPGA to record 4K video from them and also because it's an FPGA, I can whip up some HDL that implements a AHD video output! Things that will take time for me to figure out is how video compression works, reverse-engineering a camera sensor, and learning more about RF stuff.
  24. I know this is a very old post but thought I'd ask about it as I am beginning my build of the Apollo-era Saturn V launch vehicle as well as the MLP and LUT.
  25. Hey, I am just reading in as i am researching some of the same challenges. Quite happy to see that you are still on the project after such a long time. One of my main goals was to be able to get CVBS on my Blackmagic Video Assist (field monitor with integrated ProRes (Broadcast Quality) Recorder, and I happen to have found a converter that might be low signal friendly: https://www.aliexpress.com/item/32897673378.html?spm=a2g0s.9042311.0.0.27424c4dYjTfU1 First test were quite good, as it seems to have some sort of signal sync generator, but I have yet to test this recorder in the field. Just so that you know, this is what a recording on ProRes looks like with CVBS footage: https://youtu.be/ID-fd5XVzuA It just so happend that this converter can also see AHD, so I purchased a bunch of AHD camera's, that got sidelined to another project and are currently installed in a birds nest, but I'll get some more and share on the researching part.
  1. Load more activity
×
×
  • Create New...