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.
Potential DATV settop box project (aka the Ryde project)
Re: Potential DATV settop box project (aka the Ryde project)
Re: Potential DATV settop box project (aka the Ryde project)
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
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
Re: Potential DATV settop box project (aka the Ryde project)
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
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
Re: Potential DATV settop box project (aka the Ryde project)
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.
. .
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
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.
. .
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
Re: Potential DATV settop box project (aka the Ryde project)
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
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
Re: Potential DATV settop box project (aka the Ryde project)
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
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
Re: Potential DATV settop box project (aka the Ryde project)
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
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
Re: Potential DATV settop box project (aka the Ryde project)
Hello Dave!
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.
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
Dual receiver would be great, but I am not shure about GPIO speeds on RPi.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.
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.
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: 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.
Definetly yes!G8GKQ wrote: Is there anything that we can do to help?
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.
Re: Potential DATV settop box project (aka the Ryde project)
If height is an issue the flat nim version might be the best. There is an accurate mechanical drawing in the data sheet.
Re: Potential DATV settop box project (aka the Ryde project)
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: That NanoPi NEO2 has a lot of nice features for interfacing with a Serit NIM, but the RPi has more facilities.
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?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?
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.
Thanks this is interesting measurement. Right now I am writing kernel module. It compiles witout errors but need to glue all parts together.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.
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.
It is ok to use any additional hardware like dsPIC, STM32, FPGA or whatever if it works.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.
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