ATSC Transmitter

[argilo]

I've also eliminated two more unnecessary blocks, by having the "Chunks to Symbols" block output complex numbers:

https://github.com/argilo/sdr-examples/ ... f10f5c17ba

[unwiredben]

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.

[unwiredben]

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.

[N2TOH]

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.

[N2TOH]

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.

[drmpeg]

The thread for QAM modulation is here:

http://nuand.com/forums/viewtopic.php?f=8&t=3551

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.

Here's the list of repositories:

https://github.com/BogdanDIA/gr-dvbt

https://github.com/argilo/gr-qam

https://github.com/drmpeg/gr-dvbs

https://github.com/drmpeg/gr-dvbs2

And a couple of utility repos:

https://github.com/argilo/sdr-examples

https://github.com/drmpeg/dtv-utils

ATSC is built in to GnuRadio. The updated ATSC receiver was released with GnuRadio 3.7.4, and resides in a new directory called gr-dtv.

There's a DATV (Digital Amateur Television) Yahoo group.

https://groups.yahoo.com/neo/groups/DigitalATV/info

Clayton (argilo) VE3IRR has a nice blog entry about his DVB-T experiments.

http://www.irrational.net/2014/03/02/digital-atv/

Ron W6RZ

[drmpeg]

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:

/opt/gnuradio-3.7.5git/share/gnuradio/grc/blocks

Adjust accordingly for your installation.

https://github.com/hpux735/grc_blocks

And a flow graph here.

https://github.com/hpux735/sdr-examples ... -blade.grc



Ron

[drmpeg]

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.

https://github.com/drmpeg/gr-atscmap

The stand alone Python script is here:

https://github.com/drmpeg/gr-atscmap/bl ... de-fpga.py

ATSC FPGA images are here:

http://hoopycat.com/bladerf_builds/35e5 ... txx115.rbf

http://hoopycat.com/bladerf_builds/35e5 ... _txx40.rbf

A gnuradio-companion flowgraph is also available.

https://github.com/drmpeg/gr-atscmap/bl ... e-fpga.grc



Ron

[hackair]

Hi drmpeg !

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 ?

- Sam

[tara]

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.