Capturing PAL video with an SDR, and a few dead ends | Hacker News Reader

Capturing PAL video with an SDR, and a few dead ends

windytan.com

113 points1987021322 comments

This is the same person that was listening to a clip from a news helicopter on YouTube and heard some "weird interference" in the audio. She went on from there to do some audio processing and eventually realized it was the chopper transmitting some information. That information was its Latitude & Longitude, after which she plotted its flight path on a map.

http://www.windytan.com/2014/02/mystery-signal-from-helicopt...

Windytan has hearing that puts a bat's to shame.

Anecdotally, there are people that can pick up RTTY by ear.

Oona is great, and her blog is the perfect example why I fid RSS readers indispensable: she posts four or fives times per year at random intervals, yet each post is worth dozens of average articles. The "firehose of information" model is simply not adequate for these cases.

I remember when I was a young student I lived next to a park, and I could hear bats! No longer the case, and not for a long time.

I've loved this blog though, since coming across it somewhat randomly - looking into decoding the radio-broadcasts that update the Helsinki tram-displays. I never got it to work, despite a few attempts, but it is still something I'd like to come back to.

I did get sucked into the world of decoding random 433Mhz transmissions, and doing protocol analysis with ESP8266 devices though. So that if the company sauna gets turned on I can now post to slack..

Even crazier, she just used Perl and SoX to extract the data. It's MacGyver-like stuff. Amazing.

In reading this I'm reminded of some efforts to produce a software decoder for Laserdiscs by using a ADC sample the exact data on the disk [1]

1: https://www.domesday86.com/?page_id=978

I wonder if there's some way to tweak the now seemingly common SDR adapters to provide a plain ADC (ie: without demodulation). When folks are capturing old consoles, generally the RF output is avoided because of the extra noise injected. It would be ideal to work directly with the composite video.

Working with the composite video also would have implications for archiving VHS and other tape-based analog footage: right now, folks tend to use hardware devices called TBCs (time base correctors) to correct issues in the video signal from a VHS player. These are all obsolete at this point and growing increasingly expensive, so it would be nice to replace this hardware with software.

I'm not sure this is terribly practical for console capture unless you're a signal processing hacker who really doesn't want to go out and buy a capture device - decent consumer-level capture devices use some really fancy, carefully-optimized filtering to produce high quality pictures with minimal artifacting, and it'd probably take quite a bit of development and CPU time just to match the off the shelf stuff.

A reasonably priced and good quality bodge is described in "The Best Easy Way to Capture Analog Video (it's a little weird)" https://www.youtube.com/watch?v=ZC5Zr3NC2PY

So he has a $25 RCA-to-HDMI and a $70 HDMI capture card for around $100. A fully assembled Domesday board is also somewhere $100 according to https://forum.lddb.com/viewtopic.php?p=100903&sid=a582ac9ebc..., although I guess it could be higher without a good PCB supplier. The article's Airspy R2 SDR is $169.

There's a PAL decoder in https://github.com/happycube/ld-decode/blob/3d5cdeddbaf4515b..., I'm guessing it could be adapted to the article's purposes with some work. https://twitter.com/windyoona/status/1163043586314821635 says she was looking at it.

Despite my love for his channel, content, and personality, I think he was hugely in the wrong here. His example setup provided no better quality than my experience with a cheap analog capture device from ebay[0], though his is more pliable for other devices.

[0]: https://www.ebay.com/itm/USB-Video-Capture-Converter-Analog-...

The domesday project is much more important IMHO for VHS and Beta captures, than for console captures. Consoles tend to have a stable timebase.

Tapes tend to, especially if copies were made tape-to-tape, be very jittery. These could be almost flawlessly fixed in the domesday software, much better than any TBC.

Since the capture is at the "almost RF" stage early in the tape player, the overall quality is very good too. There is the potential to view VHS in better quality than anyone has ever seen it, even back in the day.

Is there anyone using this hardware for VHS or Beta captures? Seems the original project itself is very targeted, and I'm having difficulty searching up different uses of the project. I'd considering purchasing one to do high quality VHS transfer, but I'd want a community I could turn to with problems.

One of the committers have submitted VHS patches, so there is a community of one so far. :-)

Currently it can decode to black and white I think.

I am very interested also. I bought a high end consumer JVC deck unopened in box, just for this purpose in the future. But the thing is, only the mechanical transfer needs to be good, and the heads OK, the rest of the machine need not be high end at all. It really has the potential to get better VHS rips than any pro lab today in existence can achieve.

I think you may be misunderstanding what I'm referring to as "RF" in my comment. In the specific case of old consoles (and VCRs and other equiptment, though this isn't really relevant), there is a built-in or external "RF modulator" which takes the video (composite in this case) & audio signals and modulates them such that they appear as a TV station on channel 3/4 (typically). This is an additional signal conversion from the unmixed and not-modulated-with-a-carrier-frequency signal that is composite + audio, and tends to have additional losses when restoring it to the RGB/YCbCr signal that we actually care about vs going from plain composite to that representation.

The "almost RF" you're referring to here is a different end of things, the end dealt with by domesday, etc, which is the analog signal stored to the medium in question (whether tape, laserdisc, or something else). Using that signal is, as I think we agree, a very reasonable choice for constructing reasonable archival copies.

> [PAL colour] was designed in the 1960s to be backwards compatible with black-and-white TV receivers.

Fun fact: unlike for NTSC, this technically isn't true, because there is not a preceding black-and-white format that PAL was compatible with. Rather, PAL's black-and-white format (the line count and refresh rate) was defined at the same time as the colour standard. They chose their number of lines (625) to avoid having to do NTSC's 29.97fps thing.

Or so I think I have heard. Please correct me if I am wrong.

It's complicated and I don't know the full history, but the reason it's 625 lines is so that the horizontal refresh rate is approximately the same as for NTSC, allowing monochrome sets to be relatively easily converted. Also, 625-line television was developed at roughly the same time as early colour but I'm not sure they necessarily arrived at the same time depending on the country.

Standupmaths has a good video on this: https://www.youtube.com/watch?v=3GJUM6pCpew

That might explain why 60Hz PAL modes (on games consoles etc) work so well.

Ah, memories! I was a teenager in Denmark in the seventies. We easily picked up TV from both of the two Germanies. The channels from the west were sleek and modern in full color, while those from the DDR were in lifesapping greyscale ("black and white", as some like to call it). I knew this was an artifact from the SECAM -> PAL conversion, but it still managed perfectly well to reinforce our hazy notions about the Eastern Bloc as a strange, grainy, not-quite-real kind of place - a slightly subconscious impression many of my age will no doubt recognize. And then there were the occasional American clips on the evening news, and sometimes even whole shows that noone had bothered to give a quality conversion: Poor resolution and loud, garish, oversaturated colors. This I also knew to be a conversion artifact, but just like the eastern greyscale, it tended to reinforce certain preconceived notions. Perception is an interesting thing to hack.

Really cool experiment. I'd love to see how much the performance could be improved by offloading a bunch of the filtering to the GPU, though I suspect that might be a bit tricky due to driver constraints (and in particular how bad OS X drivers can be). Typically pixel shaders are quite capable of doing filtering and convolution even if you aren't ready for compute shaders - a mid tier GPU can handle doing filters with 29 taps or more per pixel pretty easily at 60hz.

Ideally that'd get the CPU and power usage way down, freeing up CPU for things like streaming.

This is interesting as it highlights how easily we lose arts. You could tune PAL video on cheap Brooktree ASICs 25 years ago, and code for decoding PAL video on the USRP has been available forever.

Brooktree was effectively spun off as Conexant, who made direct successors to many of those ASICs for quite a while including updated single-chip USB and PCIe versions. I don't think they're still around now that analog broadcast is dead though.

Reply on news.ycombinator.com