All Activity
This stream auto-updates
- Yesterday
-
walter joined the community
- Last week
-
Not very different to my early attempts! -
ripon219@gmail.com joined the community
-
BurnBrothaMario joined the community
-
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.
- Earlier
-
PowerMax joined the community
-
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.
-
DOm007 joined the community
-
StanJ joined the community
-
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.
-
truckmen joined the community
-
Herre Vermeer joined the community
-
Analog HD FPV Video. Why Not?
Herre Vermeer replied to Mr.RC-Cam's topic in Video Piloting (FPV/RPV)
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. -
Vanja joined the community
-
Larry was a 1980's rock musician with a passion for R/C model airplanes. Last month (Feb 13 2020) he posted a YouTube video that shows his FPV activity that started in 1986. It's a fascinating documentary. Another recent FPV history video was posted by YouTuber CurryKitten. This video was produced after Larry posted his documentary, so it also mentions his FPV flights. -
Chris82 joined the community
-
Great write up, I had an idea when I was at the local electronics store (Jaycar). I’ve installed/ wired two cr2032 battery holders into the tx so I can keep it powered up and replace batteries before they fail and not lose the memory. Wish I’d thought of it last time the battery failed..
-
The Comtech BSS-479 is no longer made and has sold out. RMRC was also selling them, so maybe they can help?
-
I haven't done anything yet with the chinese no name Rx as i wanted to have comtech tuner.I was thinking that its just a saw filter that i need to replace but when i opened it,,F 480-1 was already there. Maybe just comptech module with good saw filter can solve the problem. Do you have any comptech module that i can buy.Then i will modd it with your proper saw filter and can tst it it interferes with UHF. -
Sorry, but those wonderful vRx's are no longer available. It was a sad day when Racewood closed their factory. That's an option. But you mentioned that you have a Chinese vRx that has bad UHF interference. Maybe there is a solution? What have you done so far to solve it? Thanks for your kind words. I appreciate the feedback.
-
Thanks Thomas for the detailed explanation.I wish you have any 1280 Mhz Rx in stock. I am tempted to try out your 900mhz Rx and will try to replace the saw filter on it. I really appreciate your honesty in providing proper details and not trying to just sell your product.Also i have couple of your products working flawlessly from the years!!
-
The BSS-479 Comtech tuner module is a better design than the lower cost Chinese made "clone" tuner modules. Plus the overall design of the FPV receiver is important too. The upgraded SAW filter's effectiveness depends on many circumstances. I normally recommend the SAW filter upgrade as a way to increase vRx sensitivity rather than promote it as cure for bad UHF noise. But if the original SAW filter is a poorly manufactured component then replacing it could help out a lot. If you are having success with the RMRC vRx then I highly recommend you choose another one if you are expanding your ground station. A bird in the hand is worth two in the bush. EMI/RFI noise is cruel. Sometimes the cure is as simple as rerouting a cable or moving the offending RF source further away. Or maybe adding a capacitor at some strategic place on the circuit board will help. Or improving the RF grounding on the metal case. Or adding EMI/RFI filtering to all the external A/V signal & Power entries. The list goes on. And sometimes a practical cure is impossible, other than replacing the inadequately designed RF device. I'm not a RMRC receiver user, so I have no idea what they may have done to improve the receiver's resistance to UHF interference. But if it has a Comtech tuner in it then that is certainly a big advantage.
-
I don't know what they mean by "hardened"
-
This is the info from RMRC website:
-
Thanks Thomas for looking. I can control the frequency with pitlab controller then. So now I want to try one Rx first from you and will mod it with your saw filter. But one thing is confusing for me is that i have a no name 1.3ghz chinese rX which doesn't have comtech tuner and i get terrible interference from 433mhz dragonlink.But i opened the tuner cover,its fitted with F480-1. So looks like its fitted with proper saw filter and i am still getting lots of interference where as my RMRC 1.3 Rx doesn't show any interference.Does that mean there are other components involved to get rid of 433mhz interference?Please suggest.Thanks.
-
I looked inside my old Racewood "900MHz A/V Receiver, Deluxe Model with Comtech Tuner" and it uses a Microchip Technology PIC16C55A microcontroller. The chip is a 28 Pin DIP package. I also looked inside my Racewood "Standard Receiver" (small tan colored metal box model). It has a SOIC-18 SMD packaged PIC16C54C microcontroller. But I also recall they used a Chinese clone of that part in some production lots (it was a direct replacement IC). These microcontrollers were programmed with Racewood's firmware, which is proprietary. So I don't have the source code.
-
Oh okay. Sent you a PM.Please check.Thanks.
-
It has the stock 27MHz SAW filter. You could de-solder it and replace with a ECS-D480A (17MHz SAW). The microcontroller is OTP (one time programmable). It's a Chinese clone of an old Microchip Technology part. I don't recall the part number.
-
Thanks for your reply. Actually pitlab diversity controller can send i2c signals to change the frequency on the tuner.May be i should buy and try:) One more thing,has the tuner been modified with saw filter to use it with dragonlink 433mhz? If the microcontroller is somehow re-programmable,then i can try to desolder it. I am looking for a quality video product like you sell on DPCAV and that's why i don't mind trying to mod only it if its possible.
-
Possible? Yes. Practical? Not really. The Racewood 900MHz and 1280MH VRx have the same hardware. The Comtech tuner's operating frequency is handled by a microcontroller on the baseband PCB. So the firmware is different. Unfortunately the microcontroller is soldered in place and is not re-programmable. It's possible to disconnect the two wire I2C bus from the Comtech tuner and use an Arduino microcontroller (and your custom software) to control the frequency. I don't have any project links on doing this, but maybe Google will help you find some useful information.
-
Hi Thomas, Wondering if its possible to convert the "900MHz A/V Receiver, Deluxe Model with Comtech Tuner" thats available on your website?I want to buy 1280 video Rx but they are not available.Please suggest.Thanks.
-
I found an interesting article that describes microscopic hair growth (tin whisker) failures in old germanium transistors. http://www.vintage-radio.com/repair-restore-information/transistor_transistor-faults.html Maybe the transistor problems in my Sampey receiver were affected by this phenomenon.
-
Sparky: A Little Stick Welder with Big Features
Mr.RC-Cam replied to Mr.RC-Cam's topic in Floobydust
Those are on the future feature wish list. Not sure when I'll have the free time to add them. However, any developer is welcome to roll up their sleeves and tackle it. This is an open source project so contributions are welcome. Some special Arc control actions (scratch-start, lift-start) are being added in hogthrob's TIG software. His code might be useful for adding the new stick functions too. https://github.com/thomastech/Sparky/pull/6 - Thomas -
Great project! I like it! I was planing on doing something similar for same welder. Is it possible to implement hot start function and anti-stick? It would make this welder even more useful! Many strong welds! :)
-
Sparky: A Little Stick Welder with Big Features
Mr.RC-Cam replied to Mr.RC-Cam's topic in Floobydust
Weld Current Calibration Notes: The PWM controller board has a multi-turn trim Pot that affects the Welding Current. See photo: But before any attempts to change the trim Pot's factory setting it is important to understand how it interacts with the front panel's Current Adjustment. The front panel current setting changes the gain of the PWM based inverter. This is the user's control for adjusting the weld current. It has a end-to-end range of about 60 Amps. The internal trim Pot is used to apply a constant offset to the Weld Current. It can "move" the weld current up or down about 60 Amps. It's a "factory" calibration adjustment for setting the minimum weld current. And since it is an offset, that means it also affects the absolute maximum current. Although far short of the advertised 200A specification, it's possible for Sparky to achieve 125A (short current). When the trim Pot is calibrated to allow 125A maximum current the minimum current will be about 65A. If a lower minimum current is needed then the maximum current will be reduced by the same amount. Adjusting the trim Pot means that the machine's top cover must be removed. This exposes dangerously high voltages to the world. The unprotected circuitry can harm (or kill) you! Do NOT proceed with adjusting the trim Pot until you have had proper training with working on high voltage equipment. Proceed at your own risk.
