About a year or so ago I bought a Sabre Lite board from Element14.
I am glad to report that after the success with the PI I have now
managed to run DATV-Express on the Sabre Lite too.
I am using the 12.04 distribution from Linaro for the i.MX6.
I had to re-compile the Kernel to get compatible driver modules.
While rebuilding the system I added PVR USB2 support and support
for various satellite receiver dongles. So it should be possible to use it
for receive as well as transmit.
I am able to transmit a solid 4 Msymbols/sec FEC=7/8 DVB-S signal.
With DVB-S2 I can transmit 1 MSymbol/sec FEC= 9/10 APSK16, S2
requires more processing. The source code is the same as the Intel
version, I expect it can be optimised.
With no fans and no noise and a power consumption of < 10 watts
I am even doing my bit to save the planet from global warming.
Keep up the good work Charles I admire all the good work for the radio fraternity around the world.
ReplyDeleteKeith G0KTD
Great work.
ReplyDeleteWhat is the latency of your codebase? Lets assume hardware encoding mpeg4 camera or even file input - what is the delay between video frame hitting dvbqt and I/Q flying out of USB?
The delay is around 1.8 secs, if I make it any less than that I get buffering issues.
ReplyDeleteSounds great compared to 10 seconds someone was getting in Gnuradio, but still slow :(
DeleteWhat is taking up most of the time? mpeg-ts encapsulation/interleave/csa/fec
is it the same in s/s2 and t?
As I understand currently you fill the buffer, process the whole thing, and start work on the next one while the current one is send out to the usb.
Basically could this be eventually made real time (1-2 frames delay) using data pipelining on something like 4 core ARM board? Make every core do only one task and work on very small chunks
Buffering, the mpeg encoder, even in CBR mode, has some variation in its frame size. To cope with this I have had to add a buffer to smooth out the variation and this has added extra delay. S2 is even worse because of its large block size 64K. T is similar to S. I can't really answer the last part of your question as the Freescale chip has a GPU but I am not sure what will be able to be done with it as it is not fully supported yet in Linux.
ReplyDeleteNext generation of ARMs will have compute/renderscript support (example Mali t604). i.MX6 has Vivante chip that has some preliminary opencl 1.1 ep drivers that seem to work (0.6gflop = slower than one A9 arm core) . But that wasnt my question.
DeleteI meant full CPU implementation on 4 core ARM system with pipelined data. Every core computing just a small block and passing it to the next one.
http://en.wikipedia.org/wiki/Pipeline_(computing)
This way latency and buffer size is kept at a minimum.
Could you just pad transport stream (adaptation field padding) instead of over buffering? Afaik this is how TV stations do it, they send VBR mpeg streams and pad the whole mux.
I found your github, but its empty :(. Did you publish your code anywhere? Is there anything you need help with? I do c/.net/java/python.
I imagine I could setup gnuradio in a loopback to validate code changes so I wouldnt need any hardware.
btw here is an interesting paper:
http://etd.adm.unipi.it/t/etd-04232013-094907/
that advocates using lookup tables to lower computational needs for the heaviest parts of the encode/decode process (afaik FEC)
I tried a version of the Freescale graphics accelerated libraries from boundary devices, it just was not stable enough to use. The Raspi had an mpeg4 video hw encoder in it (no audio) which I have used and it has prospects if we can ever get Amateurs to drop mpeg2.
ReplyDeleteI think what you are referring to is an ARM targeted version and it certainly would be nice to do but it is not in the schedule for the Jan launch of the hardware.
I do pad the transport stream with NULL packets and add all the SI packets required to make it a valid DVB stream. However unless I add some buffering I can't drive libusb in a way that does not cause dropouts. With libusb I have had to use async mode as with sync mode the turn around time does not seem fast enough except on my quad core PC.
I do use lookup tables for parts of the FEC but my code is written in C so it is portable. Brian G4EWJ has written some ARM assembly code which is 2-3 times faster than my C code but that is for the ARM only.
Ah Github, I only set that account up because someone asked me to collaborate with them on a different project. Sadly I have not had time to help them. I plan to release the code about the time the hardware is available, at the moment it is quite messy and I want to add more comments and make it more readable.
Currently I am battling with PCR timestamps. I bought a used Tandberg TT1200 professional receiver and while it can decode the Video and Audio it is reporting massive PCR jitter which I am trying to correct. I am also having some issues with PAL/NTSC to do with picture size and frame rates. My system defaults to PAL but I then override some of the settings which seem to upset NTSC systems. Live and learn!
I was thinking about small ARM devices, but pipelining is universal and would benefit all multi core architectures.
ReplyDeleteI would ignore PCR - it is only important in real time implementations. Do you timestamp with current clock as soon as data blocks are processed instead of keeping local timer? Nah, its probably something more complicated than that :)
OK, Ill wait for the full release, but if you need any help, even with menial tasks, Im happy to help.
Some raw I/Q data dumps to play with in the mean time in gnuradio would be nice too :)
I use the program SCR to create the PCR. A number of STBs seem to need a PCR before they will decode correctly. There will be plenty of opportunity to help when we have hardware available in quantity. There is lots of DVB/TV software available for Linux and it would be nice to leverage some of that. Also it would be nice to do a GNU-Radio object for the board. I am also thinking about a DATV specific receiving program for Linux. Using something that is aimed at commercial satellite reception is really clunky for Amateur TV.
ReplyDelete