vivadatv.org

Using Raspberry PI to feed a DATV modulator – no PC required –
3/17/2014
Introduction

Raspberry Pi is a little module running an ARM processor. CPU power computation is not very huge (like on a phone), but the hardware offers (among other) :
- 2 USB
- 1 HDMI or Composite output display
- 1 100 MBit/S Ethernet connexion
- 1 SD card where there is a Linux image on it
- On optional HD Cam could be added to acquire video

It seem that hardware required to feed a DATV modulator is in this system and thus could replace a PC and the video acquisition system.

The most suprising and powerfull feature is the hardware encoder/decoder. It allow to encode in REALTIME a very good quality video in H264. Most of the encoding done by the OM’s nowadays is the MPEG-2 format. H264 is more efficient and allows to have a better quality for the same bitrate. On a normal PC, if you want to encode in H264 HD in software, it requires a very powerful CPU.

Workflow

I acquire the video from the Raspberry cam. This video is encoded in H264 Elementary stream which is then processed to make a constant bitrate transport stream. This transport stream finaly feed a modulator.
All these processes are done on the raspberry and it is then completely stand-alone.

Experiments with several modulators

DVB-T
First I use the Hides UTC100D USB dongle which is a DVB-T modulator. Thanks to its API I could easily send the transport stream. No other process is needed.

Digilite
Thanks to information from Brian G4EWJ and his great tool dvbs2enco, I could successfully send to digilite. Dvs2enco do the process of transport stream 188 to Reed Salomon which is waited by the digilite. Thanks also to Rob M0DTS for his tips learnt by his MK808 experience.

Price of the solution
Raspberry : 40 Euros
Raspberry CAM : 25 euros
SD CARD : around 15 euros

Testing on your own
All the linux system that I have set up is on a SD card. I can easily copy it as an image which could be download by who wants to test it : no linux neither programming skill is required in a first time (only when if you want to look deeper on it). I hope that in such way, even no PC skill OM”s could test the system !
Future improvements
- Developp a web interface to set parameters (which could be access by any device which have a internet browser : PC, Smartphone, Tablet)
- Add a receiver electronic part (DVB-S or DVB-T demodulator) in order to display directly to a screen
- Make multi-encoder through Ethernet to allow multiple program streams
- Add the module from G8GKQ to pilot the Ultram VCO

And of course a lot of other thinks

Evariste F5OEO
evaristec@gmail.com

Many thanks for the SD image
I have had it working tonight, very well done Evariste.

Received on my comag SL100HD RX

Same again,
The delay was a bit long, but a fantastic start, thanks for sharing with us.

I have been doing a lot of testing and it is working well.

Sometimes the program exits back to the command prompt after a few seconds. It does this a few times and then it is OK.

I am not familiar with ffmpeg, so I am guessing a bit, but I increased the data rate from 1843000 to 1843137, but it still exits sometimes.

I have changed the settings to 1920 x 1080, SR4000, FEC 3/4 and the quality is excellent. I have set the overclocking on the RPi to 950MHz to do this. CPU% is about 70%. I am running SSH and HTOP, so it may not need to be overclocked so high without them.

I am experimenting with sending the TS by WiFi to DigiLite UDP on another PC, so that I can use the RPi as an 'outside broadcast camera' and have the main transmitter on a mast.

It would be good to keep sending the A:SRF command every second, so that if the DigiLite loses power, it will be put back to the correct settings. It does not matter for A:SRF2000,1 because those are the DigiLite power up settings.

Ca marche bien. C'est bon!

Brian

Hi Brian,

Good to hear it works well now ! About the "sometimes" process stopped, I change the ffmpeg command in order to have less latency and also dvbsenco8 which stopped if there is no data input and then it seems OK. I have still about 5 to 6 seconds of latency but I didn't inspect deeper if it could be the digilite itself which could insert such a delay.
At 720*576 the CPU is about 4% for encoding, I am surprised that HD encoding takes such a CPU. Have you run a "top" to see which process cause this consumption ?
By the way...I have to flash the digilite, as I have an old version which does not accept low bitrate...

73's Evariste F5OEO

The DigiLite pcb has only a 13.5kB FIFO (in the dsPIC), so it cannot add a lot of a delay.

At SR2000, FEC 1/2, DVBSENCO uses 4% cpu. At SR4000, FEC 3/4, DVBSENCO uses 24% cpu. There should only be 3 times as much data, but it is taking 6 times as long. Maybe with higher data rates, DVBSENCO does not run in the cache as much. I will do more tests.

Brian

I am using a Hides stick with the Raspberry Pi feeding the 'Darko Amp' 4 Watt output.
How can i change the settings? Default Freq is 560 Mhz. Want to change it to 436Mhz.
Config file on de image? Can't find it.

BTW ... i am a Linux nono.. so

Hi,

For Hides parameters , you could edit the script : encodehides.sh located in the /DATVRelease/Hides/ folder.
For this use :
nano encodehides.sh

You see at the end : tsrfsend 0 530000 2000 4 ....

530000 is the frequency in Khz. you can modify it to suit your needs.

Do a CTLR o for saving the files.

You can launch encodehides.sh and it should modulate on the frequency you set

73's Evariste F5OEO

Hi Evariste,

Many tnx for your clear explanation. It works!

73 Rene