I changed the transmit frequency to be in the 70cm amateur band, increased the output gain and replaced the three blocks I had been using for symbol coding (uchar to float -> multiply const -> add const) with a single "chunks to symbols" block.
I also made a second version of the transmitter that works well on USB 2.0. It reduces the output sample rate down to 2/3 times the symbol rate so that less USB bandwidth is required.
I've been using the combo of the BladeRF and this script to do ATSC testing on our Roku TVs now for several months. I had one question -- if I use this script with a transport stream that was originally captured as a low-bitrate subchannel, it looks like there's no padding inserted, so our TV plays the video at a high speed. Does anyone know of a good way to insert padding into the TS so it wll play at the proper speed? Doing it automatically as part of this script would be excellent.
A quick followup -- after some research, I finally found a tool that would pad the TS with null packets, TStoATSC from http://www-personal.umich.edu/~balazer/tstoatsc/. It only had a Windows executable, but it didn't take too much effort to port the command-line tool to unix, but it's still awkward to use. I think a better tool would be to update the GNU Radio ATSC module to include a "padWithNull" block that could be used on the TS input before going into the pad() block, and I might work on that in the near future.
TCP/IP encapsulation, what would it take to wrap internet traffic so it could be send along with a digital video transmission? perhaps as one of the sub channels along with actual video.
drmpeg, I see in your first post a listing for QAM modulations. has a transmitter been established for such modulations? I'm curious if they could be used for digital amateur radio television.
The amateur radio digital television community is pretty fragmented right now with folks using DVB-S, DVB-S2, DVB-T, 64-QAM and ATSC. For bladeRF (also Ettus B2X0 and hackRF) we've tried to cover all the formats with at least a transmitter. DVB-T and ATSC also have GnuRadio receiver implementations, but the ATSC receiver requires a high-end CPU to achieve real-time decoding.
For those wishing to use the ATSC transmitter with gnuradio-companion, there's a set of block definitions available. Just copy the files to your GnuRadio blocks directory. On my system:
I've created a custom GnuRadio block for the new ATSC FPGA. It maps the 3-bit ATSC symbols to a floating point (gr_complex) stream that can be sent to the standard osmocom sink block.
How do I create a ATSC receiver in gnu radio companion ? I haven't been able to find it on the internet. Clayton's tutorial was for transmission only, and I would love to learn how the receiver is made. But like all receivers, it is very complex to create. Could you help me out ?
On the off chance that you expel the RRC channel (I know you're not transmitting over the air, so the test ought to be alright) how much lower does the CPU load get?
Is most by far of CPU time spent doing the RRC sifting?
With a 100 tap channel, symmetric, and 4 timekeepers for every image should transform into something like 26 multipliers to do the entire separating in the FPGA - presumably less since a portion of those taps are most likely going to be exceptionally little, or less difficult moves and includes.
I'd be interested the amount CPU it takes to do the interleaving, and RS encoding, versus simply the image forming a channel.