BATC Forum

Hello Dave!

I really want to achieve 270 MBit/sec (34 MByte/sec) transport stream speed, so I can use it for commercial DVB-S/S2 receiving. So, things will happen really quickly. That is reason for DMA and because memory must be reallocated for DMA really quickly it must happen in kernel mode. Why driver? Because it is working in kernel mode and cam make really simple access to user. User simply open character device and read byte by byte transport stream. Then user can feet transport stream to SoC MPEG decoder or stream over ethernet/wifi...

I have nanopi neo2 and read H5 datasheet. It already have dedicated hardware to read parallel TS from Serit tuner. Also it have MPEG2/MPEG4/H.265 decoder on board. HDMI, composite, analog and digital audio output etc. Seems that H5 was made so universal and flexible that Chinese already building consumer set top boxes with this kind of SoCs.

So it depents... Allwinner SoC board (friendryarm or whatever) because cheap and all MPEGs + dedicated hardware, but almost no documentation.
RPi available, but some difficulties with GPIO and DMA input (not much info on internet).

BTW I already using STmicroelectronics LNBH25 polarisation voltage controller and want to see LNBH26 controller in this project.

BTW I already purchased two SERIT tuners with horizontal mounting, but they cost me 55 EUR each (incl shipment and local import taxes). In theory I can start design PCB in eagle.

Anyway lot or work to do. I need to start learning more about kernel driver designing and dive into RPi DMA magic. Lot of ideas and not enough time.

PS: Axis-NT PolishAmp also waiting when I will finish coding.

Janis, YL3AKC

OK!
Let's start with simple things:
1) I need to make setup and test my pluto as dvb-s transmitter.
2) need to test already made I2C modifications and make shure that receiver is working.
3) Cleanup I2C code and push to main longmynd repository. As result (I hope) there will be some additional rpi/ftdi switching module in main branch. This is useful because Phil is making lot of good additions to main longmynd repository.
4) Try to make simple kernel driver from existing examples with gpio and interrupts with the hope that gpio+irq on rpi will work fine on low TS data rates.
5) Solder data pins from ftdi and connect them to RPi. So I can read either from rpi gpio or from ftdi(usb) for tests.

I am just beginner C programmer and my code usually isn't clean. I hope that some BATC pro can make it cleaner.
Going to read kernel module development examples and theory.

PS: did you guys checked TSduck (https://tsduck.io/) transport stream manipulation tool? Could be useful for datv transmitting in future.

Janis, YL3AKC

Hi Janis

Sounds good. The one thing that I would ask you to remember is that we are aiming at producing a reliable set top box receiver. So something that needs minimal user intervention and recoves itself from errors.

Moving away from USB to GPIO is likely to help a lot, but the code must be reliable so that we can control it with just an infra-red remmote control eventually.

I've looked at TSDuck in the past, but not found a need to use it yet.

73

Dave, G8GKQ

For IR control, somebody need to play with LiRC. What remote control is planned to use? Most popular el-cheapo like in arduino kits?

Janis, YL3AKC

I have been doing some research and the "hard bits" have mostly already been done we just need some glue and user interface code to make a viable proof of concept.

Once I finish building my MiniTiouner hopefully this week I should be able to throw together some quick (probably) python code to interface between longmynd, VLC and LiRC.

I have an old RPi and an IR receiver in a box somewhere that hopefully will be up to working as at least a proof of concept before I shell out for a RPi4

It makes sense to attack this from both directions meeting in the middle with longmynd as the interface. Janis seems to have had roughly the same thoughts as I have regarding interfacing directly with the RPi, although as nice as being able to receive broadcast would be a custom kernel module does sound like a bit of an integration and maintenance nightmare.

Tim, MW0RUD

Hello!
I forked longmynd from myorangedragon.
My fork include RPi direct i2c control.
To activate it you must cut 2 trces on PCB to isolate FTDI chip i2c lines and manualy wire i2c lines from RPi to minitiouner board. They are located blow R4 and R5. Sorry, I don't have time to test it now. LNB voltage control and NIM reset not implemented yet. They must work via USB for now. To activate RPi i2c bus use -r switch in command line. Good luck with testing.



Best regard,
Janis, YL3AKC

Hello Tim!

Reason for kernel driver is because you need really quiclky read data. With conventional (userland) GPIO this could be problematic because of speed.

I have following vision: Kernel driver have interrupt handler, who triggers when certain GPIO pin change state (transport stream clock).
Inteerup handler routine read 8 GPIOs and put them into simple fifo buffer. This should be really quick and (I hope) will work on multiprocessor system with like 1 000 000 times per second, what is acceptable for transport stream. I need to test this. From user point of view you only need to open special file like /dev/minitiouner and read it. This can be done via longmynd software or with other programs like netcat or VLC. In future I will try to make DMA version.

I am inspiring from following information:
http://morethanuser.blogspot.com/2013/0 ... ernel.html
https://www.apriorit.com/dev-blog/195-s ... r-linux-os
http://freesoftwaremagazine.com/articles/drivers_linux/
https://lwn.net/Kernel/LDD3/
https://github.com/hzeller/rpi-gpio-dma-demo
https://github.com/Wallacoloo/Raspberry ... dma-gpio.c
https://stackoverflow.com/questions/504 ... a-dma-work

Best regards,
Janis, YL3AKC

Given it needs a PCB wouldn't it be better to add some helper hardware to do this?

I was thinking of an intermediate PCB which hosts the IR receiver, plugs in place of the FTDI and connects to the header on the Pi once we work out what the correct pin map is on the Pi.

We have to be slightly careful to make sure all the TS pins are mapped in the right order to the same bank on the Pi to minimise bit twiddling in the performance critical bit of the software later.

I was thinking of memory the TS could be clocked into and then read out by the PI, fifo buffer.