RF video connection to HDTV (ATSC)
SaucySoliton
Posts: 568
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.
The coloring here is a test of changing only the U,V components of the video. The Y component is unmodified like it must be we were going to concatenate pre-encoded bitstreams.
1920x1080 would give a 120x33 text mode. I don't see much of a point to pursuing a restricted text mode output. I would rather design for graphics. That way we could use any size text. Responsiveness would be fine if we only draw a few lines of text at a time. The concatenating text mode would not be able to update the full display every frame either. It would be restricted by the 19mbps ATSC channel.
What I'm not really happy about is this encoder can only output 12 fps at 320x240 even though the discrete cosine transform and quantization is not part of that time. Those steps are done once as the image is generated before it's stored in the PSRAM.
I've turned off the serial video output to test the time but that only gives a minor improvement. My JPEG encoder runs 32 fps and that includes the discrete cosine transform. I guess I would have to write a whole bunch of functions in PASM2 to match the performance.
Also due to an improved FFT, realtime DVB-T might be possible if one could dedicate 4 cogs for IFFTs.
@SaucySoliton this is neat stuff…. What if only wanted to display semi- static images. Guess the bitstream could be generated on PC and stored in PSRAM in advance…
What kind of resolution could you get doing it that way?
Maybe it’s the same as shown above but have no idea…
Just read 1080i above. How hard would that be?
MPEG is pretty hard >.>
If you have trouble encoding dynamic graphics even at 320x240, I think the pendulum of practicality swings back towards just doing HDMI instead and getting 640x480 60 FPS to the TV for free-ish.
Not to discourage you from trying a crazy idea though!
In related reverse ideology: Having P2 MPEG(2?) decoder would be kinda neat. I did some work with the old cinepak codec some years back, but that wasn't very good quality and turned into a sidequest of trying to write a better cinepak encoder for PC. (at which I partially succeeded, but the whole program never really worked that well. The main area to get improvements from is luminance-correcting RGB->YUV conversion and seeding the VQ with sensible initial values before refining into a local optimum with LBG. The former is theoretically relevant to any chroma subsampling codec. I have a comparsion in the relevant thread). Though I do recall getting that to decode at 1024x768 in 16bpp once but without associated audio track.
Big issue with any video stuff on P2 is having to make the whole algorithm run with partial image buffers, because full ones (even in 12bpp 4:2:0 format that isn't directly useful) don't fit well in hub RAM. I forgot how big the motion vector range is for MPEG2...