Potential DATV settop box project (aka the Ryde project)

Discussions about the new Ryde "Set-top Box" Style Digital ATV Receiver
YL3AKC
Posts: 41
Joined: Wed Aug 08, 2018 8:42 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by YL3AKC » Wed May 13, 2020 2:51 am

g0mjw wrote:
Tue May 12, 2020 5:33 pm
I was thinking of memory the TS could be clocked into and then read out by the PI, fifo buffer.
Yes it should work like this, but more interesting question is how exacelty TS will be clocked into RPi? Will there be enough CPU resources to clock in? Remeber that it is no arduino, it is multiprcessor system under linkux control. Realtime stuff is interesting.

YL3AKC
Posts: 41
Joined: Wed Aug 08, 2018 8:42 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by YL3AKC » Wed May 13, 2020 3:44 am

I assume that you really want to get TS from both receivers.
I started to look on GPIO details for RPi and planning GPIO mapping and start GPIO driver compiling/make experiments.

For live chat I made telegram chat channel. Everybody are welcome and can join: https://t.me/Ham_DVBS_IRD

G8GKQ
Site Admin
Posts: 1682
Joined: Sun Mar 22, 2009 1:21 pm

Re: Potential DATV settop box project (aka the Ryde project)

Post by G8GKQ » Tue May 19, 2020 10:02 pm

Hi Janis

Sorry, I should have answered your question - I do not think that TS from both tuners is a key requirement. Remember that the ultimate goal is a simple set-top box feeding one display.

However, it would be great if we can allow for future expansion to read both TS streams.

I know that you are focused on getting 27.5 MS signals clocked into the RPi (so almost 4M bytes/s), but for amateur use if we can get something that works up to 4MS (less that 500KB/s) it would be adequate.

Is there anything that we can do to help?

Dave, G8GKQ

G4EWJ
Posts: 748
Joined: Wed Feb 17, 2010 10:11 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by G4EWJ » Wed May 20, 2020 3:18 pm

That NanoPi NEO2 has a lot of nice features for interfacing with a Serit NIM, but the RPi has more facilities.

Janis, do you have a link to that Serit RPi hat please. I wonder if they use the secondary 4 bit SD card bus to talk to it? Does the Serit NIM have a 4 bit mode?

I've never looked at Linux loadable kernel modules before, so I adapted the ones here to see what the interrupt latency is like.

http://derekmolloy.ie/writing-a-linux-k ... troduction

On the RPi4, the latency is 2.0us in the photo, but sometimes it settles on 1.2 or 1.6us. You can see it dancing around a bit on the top right pulse. Maybe there are other ways to do it to make it faster.

The lower trace is the GPIO pin generating an interrupt on the rising edge. The upper trace is the kernel module interrupt handler turning a GPIO pin high then low.
.
RPi4-kernel-module-interrupt-latency1.jpg
RPi4-kernel-module-interrupt-latency1.jpg (104.09 KiB) Viewed 481 times
.
4MS QPSK FEC 9/10 would generate 4 x 2 x 9/10 = 7.2M bits/s = 0.9M bytes/s = 1 byte every 1.1 us, so it wouldn't be fast enough to read the 8 bit port on the NIM with a 2us interrupt latency.

This test was with the cpu speed at 1.5GHz and no other user processes running. I doubt if an interrupt driven system would be reliable, as you never know when the system needs to disable all interrupts, or throttle back the cpu speed because it's too hot.

I think that a more reliable and extensible approach would be to have something in between the NIM and the RPi, as suggested. The interface can accept the 8 bit output from the NIM and send it to the RPi on an SPI port. The RPi4 has 5 SPI ports available on the connector and they appear to have DMA capability. You can have several chained DMA buffers on the RPi to avoid any problems with system latency.

I've done something similar with a dsPIC when I was looking at 'Fast Audio'. The dsPIC was sitting on the bus between the NIM and the FT2232H, extracting Fast Audio packets. I'm currently experimenting with an RPi3 sending 2 x 20M bits/s SPI streams into the dsPIC on a DigiThin and it seems stable.

If you want to use the second output on the NIM, you just drop in another interface module and connect it to an SPI port on the RPi. Subject to resources on the RPi, you may be able to have a second NIM with 2 more interface modules - for the person who doesn't want to miss anything on QO-100.

I think that with the 2 HDMI ports on the RPi4, 2 receive channels would be desirable, so that you can follow a QSO on QO-100. The pcb could have room for 2 NIMs and 4 interface modules and be populated as required.

For broadcast, the data rate could be 62M bits/s for the BBC English transponder on 12073H 8PSK FEC 3/4. This would be a bit much for the dsPIC33FJ. There are faster PICs, but they tend to be homebrew unfriendly. Is this going to be for home construction, or a manufactured item?

For broadcast, the interface dsPIC could do some intelligent packet filtering, under command from the RPi. First it could let through all the control PIDs below 32, then the PMT PIDs, which would tell you which video and audio PIDs to let through for a particular programme. There are 9 programmes on that transponder, so the data rate for any one is likely to be about 7M bits/s.

Brian

MW0RUD
Posts: 16
Joined: Fri Apr 24, 2020 3:09 pm

Re: Potential DATV settop box project (aka the Ryde project)

Post by MW0RUD » Wed May 20, 2020 5:11 pm

At those sorts of speeds it defiantly sounds like we need some kind of hardware buffer for any of the higher symbol rates. I was thinking something like a 74HCT40105 and setting an interrupt on DOR to read it might give us the headroom we need for higher symbol rates (although broadcast is probably pushing it).

Multiple displays is an interesting idea, does the Pi4 have the multiple video decoders needed to decode different things for each display?

P.S. a UI proof of concept is post coming in the next few days once I have a bit more of the state machine finished

g8gtz
Posts: 1276
Joined: Wed Apr 07, 2010 6:26 pm

Re: Potential DATV settop box project (aka the Ryde project)

Post by g8gtz » Wed May 20, 2020 5:20 pm

Hi Brian,

Thanks for the comments.

Ideally the project will be for home construction. BATC doesn't really want to get in to getting PCBs made up etc - we did do it for Portsdown but hope it's not necessary for the Ryde project. Whilst being able to receive a broadcast mux would be nice, it's not part of the spec and it would be a shame to over complicate the design to enable it to happen.

And yes, a Rpi Hat is the ideal and I'm sure Mike is keen to do a new PCB but I think most people would be happy with a USB connected MiniTiouner as phase 1 and the Pi hat as phase 2.

Do you need 2 NIMs, doesn't it make more sense to enable the 2nd channel in a single NIM - or maybe that's not practical?

73

Noel

g0mjw
Posts: 1172
Joined: Sat Sep 20, 2014 9:15 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by g0mjw » Wed May 20, 2020 7:30 pm

Hi Brian,

I was wondering if a microcontoller could provide the link between the NIM and the PI. That or an FPGA. What about the MCP23S17 ? Costs about £1 and allegedly runs 10 Mb/s. Useless for high symbol rates but should be fine for RB-DATV.

Mike

YL3AKC
Posts: 41
Joined: Wed Aug 08, 2018 8:42 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by YL3AKC » Wed May 20, 2020 8:00 pm

Hello Dave!
G8GKQ wrote: Sorry, I should have answered your question - I do not think that TS from both tuners is a key requirement. Remember that the ultimate goal is a simple set-top box feeding one display.

However, it would be great if we can allow for future expansion to read both TS streams.
Dual receiver would be great, but I am not shure about GPIO speeds on RPi.
I thing that it is Ok to connect both TS outpurs to GPIO on PCB is good, even is it will not be used at the beginning. Lees PCB revisions - less problems.
G8GKQ wrote: I know that you are focused on getting 27.5 MS signals clocked into the RPi (so almost 4M bytes/s), but for amateur use if we can get something that works up to 4MS (less that 500KB/s) it would be adequate.
I really want to get 7.2 MS from DSNG feeds. Standard HD TS bitrate is near 16 MBit/sec. IF this work, much slower DATV will work witout any problems. So far this is my goal. With 1 receiver (1 TS feed).
G8GKQ wrote: Is there anything that we can do to help?
Definetly yes!
1) Any ideas how PCB should look like? Does anbody dan make quick 3D mechanical desing for PCB with 3D NIM and RPi. This is nacessary to understan where F-connecers should go out of box. How it will fit with USB/Ethernet, HDMI, RPi PSU pin etc. I only want that result (HAT+RPi) can fit into low profile (1U rack unit) height and easy to use connectors. So far best idea is to locate NIM F-connectors on the same side whre USB/ethernet are located but need to make some measurements to make shure everything fits nicely.

2) Brainstorming ideas and best practices with RPi programming, hardware connections, mechanical/case ideas etc.

3) Let's ssume tall RPi GPIOs are busy for both TS outputs. We still need some additional GPIO for LNB control, LEDs, displays, buttons etc. What about to use I2C expanders like MCP23017 for these slow peripherals?

Janis, YL3AKC
Last edited by YL3AKC on Wed May 20, 2020 8:23 pm, edited 1 time in total.

g0mjw
Posts: 1172
Joined: Sat Sep 20, 2014 9:15 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by g0mjw » Wed May 20, 2020 8:09 pm

If height is an issue the flat nim version might be the best. There is an accurate mechanical drawing in the data sheet.

YL3AKC
Posts: 41
Joined: Wed Aug 08, 2018 8:42 am

Re: Potential DATV settop box project (aka the Ryde project)

Post by YL3AKC » Wed May 20, 2020 8:22 pm

G4EWJ wrote: That NanoPi NEO2 has a lot of nice features for interfacing with a Serit NIM, but the RPi has more facilities.
Actually NanoPi NEO2 don't have pinout for most interesting peripheral: TS input. To get TS input we need look on other Allwinnner H5 embedded computers. Also Beaglebone Black is promising because it have two MCU peripherals who can work with up to 200 MBit/sec data rates.
G4EWJ wrote: Janis, do you have a link to that Serit RPi hat please. I wonder if they use the secondary 4 bit SD card bus to talk to it? Does the Serit NIM have a 4 bit mode?
No, Serit NIM HAT is only an idea. Not real hardware. This is only product name. How else can call DATV receiver board who fit on RPi? :-)
STV910 have two output options: 8 bit parllel or 1 bit serial, but on Serit NIM is available on parallel output. I don't have schematic for Serit NIM and didn't study exact STV910 for serial output capabilities. There is still small chance to get 1 bit serial TS output fro Serit NIM.
G4EWJ wrote: I've never looked at Linux loadable kernel modules before, so I adapted the ones here to see what the interrupt latency is like.

http://derekmolloy.ie/writing-a-linux-k ... troduction

On the RPi4, the latency is 2.0us in the photo, but sometimes it settles on 1.2 or 1.6us. You can see it dancing around a bit on the top right pulse. Maybe there are other ways to do it to make it faster.

The lower trace is the GPIO pin generating an interrupt on the rising edge. The upper trace is the kernel module interrupt handler turning a GPIO pin high then low.
.
RPi4-kernel-module-interrupt-latency1.jpg
.
4MS QPSK FEC 9/10 would generate 4 x 2 x 9/10 = 7.2M bits/s = 0.9M bytes/s = 1 byte every 1.1 us, so it wouldn't be fast enough to read the 8 bit port on the NIM with a 2us interrupt latency.

This test was with the cpu speed at 1.5GHz and no other user processes running. I doubt if an interrupt driven system would be reliable, as you never know when the system needs to disable all interrupts, or throttle back the cpu speed because it's too hot.
Thanks this is interesting measurement. Right now I am writing kernel module. It compiles witout errors but need to glue all parts together.
It have following parts:
1) initialisation/deinitialisation including peripheral base config from command line
2) Really short interrupt routine and push to FIFO buffer.
3) character device interface nd FIFO reader.

I am worrying about race conditions, semaphores add mutex stuff.
G4EWJ wrote: I think that a more reliable and extensible approach would be to have something in between the NIM and the RPi, as suggested. The interface can accept the 8 bit output from the NIM and send it to the RPi on an SPI port. The RPi4 has 5 SPI ports available on the connector and they appear to have DMA capability. You can have several chained DMA buffers on the RPi to avoid any problems with system latency.

I've done something similar with a dsPIC when I was looking at 'Fast Audio'. The dsPIC was sitting on the bus between the NIM and the FT2232H, extracting Fast Audio packets. I'm currently experimenting with an RPi3 sending 2 x 20M bits/s SPI streams into the dsPIC on a DigiThin and it seems stable.

If you want to use the second output on the NIM, you just drop in another interface module and connect it to an SPI port on the RPi. Subject to resources on the RPi, you may be able to have a second NIM with 2 more interface modules - for the person who doesn't want to miss anything on QO-100.

I think that with the 2 HDMI ports on the RPi4, 2 receive channels would be desirable, so that you can follow a QSO on QO-100. The pcb could have room for 2 NIMs and 4 interface modules and be populated as required.

For broadcast, the data rate could be 62M bits/s for the BBC English transponder on 12073H 8PSK FEC 3/4. This would be a bit much for the dsPIC33FJ. There are faster PICs, but they tend to be homebrew unfriendly. Is this going to be for home construction, or a manufactured item?

For broadcast, the interface dsPIC could do some intelligent packet filtering, under command from the RPi. First it could let through all the control PIDs below 32, then the PMT PIDs, which would tell you which video and audio PIDs to let through for a particular programme. There are 9 programmes on that transponder, so the data rate for any one is likely to be about 7M bits/s.
It is ok to use any additional hardware like dsPIC, STM32, FPGA or whatever if it works.

Some time ago I had more crazy ideas:
1) Use 74HC597 (or similar) register to convert 8 bit parallel TS stream into SPI. Inspired for official RPi DVB-T HAT with Sony reciver chip. This works with SPI and maximum dt rate near 55 MBit/sec. This could work but need to test.

2) Build only FPGA + 1GBit/sec ehternet (and ASI BNC TS output) to stream TS over UDP, no RPI involved for receiving. RPi only receive UDP TS and decode picture+sound.

Janis, YL3AKC

Post Reply

Return to “The Ryde Digital ATV Receiver”