RF video connection to HDTV (ATSC)
SaucySoliton
Posts: 550
So the P2 can emit an ATSC HDTV signal.* https://hackaday.io/project/194559-atsc-transmitter-from-parallax-p2-microcontroller Is this something people would be interested in?
The good:
Transmit a solid 19.3 mbps over a coaxial cable and receive it with a standard HDTV tuner stick.
Display up to 1080i resolution. Maybe newer TVs would even accept 4k.
The P2 Edge with 32MB ram can play a 6 second video loop. That could be lengthened by doing more of the signal processing on the P2. The ATSC standard is not very computationally intensive to transmit.
The bad:
The P2 doesn't read the 19.3 mpbs from SD card needed for a proper video player. But how useful would a video player be?
I think it would be possible to make a heavily modified MPEG encoder that uses text as an input instead of video frames. What is the obvious way to do this? Look up a bitmapped font for the character. Then assemble an image of the text. Feed that to an MPEG encoder. The encoder will do a discrete cosine transform, quantization, and Huffman coding. Now if we put some restrictions on the size of the font we could speed up the process a lot. Suppose we used the character and looked up a pre-computed image block. Hopefully at the Huffman encoding stage. So maybe we could build a 1080i MPEG stream of text by simply concatenating data from a table. That sounds like a lot of work to me.
There might be too much lag from the TV's MPEG decoder for a fun computing experience. It will be hard to know without testing.
On most TVs it seems necessary to rescan for channels when switching from the P2 to broadcast TV and vice versa. This could be remedied with a diplexer. Most HDTV signals are UHF. The P2 is best suited for VHF low signals. The diplexer would allow both the P2 signal and local TV stations to be available to the TV at the same time.
The P2 probably can't do OFDM based signals like DVB-T. That requires less than 280uS for a 2048 IFFT or 1120uS for a 8192 IFFT. P2 needs 1185uS for 2048 FFT and 5674uS for a 8192 FFT at 320MHz. So maybe DVB-T would be doable if we had 5 or 6 cogs just for the IFFTs.
. * Of horrifying spectral purity. Although the Raspberry Pi FM transmitter used to be worse. 
Comments
Is that a reason to get a full SD 4-bit mode working? It won't be able to use the built-in 1-bit SD slot on existing boards.
Yeah, that would be cool!!!
Did they actually produce an image on a HDTV over coax cable this way?
Can't really tell from that website...
Text mode might be interesting. My understanding is that mpeg divides the screen into 16x16 pixel areas for coding/decoding. If you had a 16x16 pixel based font, maybe that could be pre-encoded and sent easily?
Why can't the P2 read 2MB/s from SD? I would think it can, but have never tested it.
Also, this is a very cool idea! That's a "one wire" video solution, LOL.
It can, at least using Flexprop's drivers. The available speed is over 3 MB/s
Improved to fit a 12 second video in PSRAM. Video of it in action here:
https://hackaday.io/project/194559-digital-tv-signal-from-parallax-p2-microcontroller#menu-details
That's really cool Saucy. The 4 bit SD mode @evanh has implemented is now certainly enough to read higher speeds - you'd need a board for it though.
Now we just need a DVB-t version for us mortals Down Under and in the EU although the top post mentions this would likely not be doable on the P2 - any more things you've learned with this whole experience since then that would change the opinion on achieving OFDM etc?
Yes, 4-bit sd driver for flexprop is fast enough. Would be neat to play 1080i video with 1 pin…
Maybe this could also be good for a nearly static display…. How long would it take a cog to turn bitmap in psram to output frame in psram?
Also, can small parts of the image be updated? Or have to do whole frame?
I've got a dvb-s version going too. Neat part about that is because the symbol rate is configurable we can reduce the symbol rate to the point that everything fits in one cog.
It's possible to send dvb-t with a pre-generated loop of samples. See https://bellard.org/dvbt/ . The special modeline for the dac mode has a frame rate of 15.915 Hz. With the transmission specs that is 272 OFDM symbols. (4 frames or 1 superframe.) I think the P2 can easily add the cyclic prefix in real time. So we need to store 272*2048 = 557056 pre-generated samples, requiring 1114112 bytes. We will need to read 18.3MB/sec from PSRAM. It will take 322mS just for the IFFTs for that data. So maybe we are looking at 2 frames per second. Maybe we could send a data frame after it's done and then switch to an idle frame while waiting on the next one.
The whole deal with MPEG is only updating the parts of the image that need to be updated.
My PASM JPEG encoder does about 320x240x30 which is 2.30 million pixels per second. 1920x1080 is 2.07 million pixels. So 1 cog, 1 fps. It can be 30 fps if you only change 1/30 of the frame. I think it will work fine for a text editor or HMI because not much will change each frame. Having a mouse pointer is not a big deal because that just needs a few block updated each frame.
This is very interesting. Could be good for slideshow. Maybe stored on usd as a jpeg means you could use directly?
Or, needs some special file format for that?
Any chance of adding sound?
4k would be something. If that works would have to try it.
Is the video transmitted as progressive and shown interlaced?
Or, transmitted interlaced?
Guess 16x32 font work.
Can this work wireless?
As far as I understand MPEG video is progressive unless the encoder determines that it's more efficient to use the interlaced transform. I think the decision is made on a macroblock level.
Sound?
ATSC/DVB-S: Encoding MP2 or a52 sound would take about 1 cog of cpu time. It might be possible to make a stripped down encoder that only generates beeps. Or have pre-encoded silence and sound files. They might have timestamps that need to match the video.
DVB-T: Since real-time transmission is not possible each pre-encoded frame could have silence or a sound.
Wireless?
Will need some good bandpass filters and amplifiers. Also likely illegal unless operating on amateur radio frequencies. Also broadcasting your computer display unencrypted is a security risk.
ATSC: I think a certain amount of filtering is possible with an additional cog just for filtering. I've implemented a beta version of this for dvb-s. Maybe with double side band output, maybe proper vestigial side band. Since the chroma modulator does not do any kind of interpolation of the samples there will still be some spurious emissions from that. With an L-C bandpass filter we might have a clean enough signal on the VHF-low band.
DVB-S: At lower symbol rates it should be possible to generate a signal as clean as the 8 bit DAC allows. Also lower symbol rates will allow the entire modulator to operate in 1 cog. Will still need a bandpass filter because the tuning range of off the shelf dvb-s hardware is 950-2150 MHz. About 27-1700MHz for rtl-sdr and leandvb. Oddly enough there are COTS SAW filters for the 23cm ham band.
DVB-T: Can be as clean as the DAC allows because of offline signal generation.