Potential DATV settop box project (aka the Ryde project)

Discussions about the Ryde "Set-top Box" Style Digital ATV Receiver. See https://wiki.batc.org.uk/Ryde_Receiver
G4EWJ
Posts: 1359
Joined: Wed Feb 17, 2010 10:11 am

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

Post by G4EWJ » Thu May 21, 2020 12:32 pm

A while back, I made some notes on the waveforms from the NIM. I think the clock frequency changed with the symbol rate, but I don't think it was proportional. I'll check that again.

Brian
.
FTS4334LV-waveforms1.jpg
FTS4334LV-waveforms1.jpg (83.72 KiB) Viewed 4419 times

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

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

Post by YL3AKC » Thu May 21, 2020 12:48 pm

G4EWJ wrote:
Thu May 21, 2020 12:18 pm
MW0RUD: The 74HCT40105 would extend the latency limit to 16us, so could work. I'll try to set up the kernel module latency test on a running Portsdown.

G8GTZ: Definitely use both channels on the NIM. I'm sure Heather can advise. The second NIM is for 2 more channels.

G0MJW: I've had a look at the MCP23S17. I haven't figured out yet if it has buffering. The NIM is effectively a master device, so you have to be ready to accept what it gives.

YL2AKC: I got the chips confused there somehow. Can you tell which pins on the RPi are being used to interface to the TV Hat?

I think we should investigate NIM serial mode. If that works, then there's no need for any interface hardware. SPI slave mode on the RPi should be fine.

Brian
MCP23S17 not buffering, it is a way to convert parallel 8 bit to SPI. MCP is SPI slave, so no problems with RPi SPI programming. I don't thing that FIFO is necessary for this setup. DMA+SPI hardware will handle data rates. As alternative is 74HC597, but with higer speed.

Regarding FIFO, why not to use something like this: CY7C130-55PC or This FIFO
More practical is to solder FPGA/CPLD and don't mess with FIFO memory.

RPi TV HAT is using SPI inteface to RPi with max SPI frequency 55 MHz (~ 55 MBit/sec transport stream+control).
https://www.raspberrypi.org/products/ra ... pi-tv-hat/ I found additional information by looking on CXD2880 TV tuner driver in kernel source code.

Janis, YL3AKC
Last edited by YL3AKC on Thu May 21, 2020 12:54 pm, edited 1 time in total.

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

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

Post by YL3AKC » Thu May 21, 2020 12:52 pm

g0mjw wrote:
Thu May 21, 2020 12:20 pm
I already have a Kicad PCB design so getting the NIM in the right place is not difficult. It more depends on what other components are needed and how it connects to the PI. It would make sense for the board to power the PI perhaps but I am not sure it would work as a hat as the PI needs active cooling and a board sitting on top would interfere with that. Perhaps a side by side approach and connection cable might be better. It would also minimise the height with the vertical NIM.

It would be good it someone could test the serial mode first. If it's possible it greatly simplifies the hardware.

Mike
Thank you, This is great news.

I attached some ideas regarding NIM placement. Sorry I don't have any drawing experience. Take these drawing with some grain of salt.
rpi_nim-hat_mechanical.svg.7z
(245.59 KiB) Downloaded 285 times
Janis, YL3AKC

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

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

Post by YL3AKC » Thu May 21, 2020 12:59 pm

G4EWJ wrote:
Thu May 21, 2020 12:32 pm
A while back, I made some notes on the waveforms from the NIM. I think the clock frequency changed with the symbol rate, but I don't think it was proportional. I'll check that again.

Brian
.
FTS4334LV-waveforms1.jpg
NIM TS serial out have two modes:
1) Constant CLK and Valid pin tells to use or ignone current clk pulse.
2) Variable CLK and Valid pin do the same. CLK is comparable with TS bit rate, but sometimes can be slower to resynchronise with STV910 internal FIFO.

Janis, YL3AKC

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

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

Post by G4EWJ » Thu May 21, 2020 3:15 pm

Thanks Janis.

Brian

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

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

Post by G4EWJ » Thu May 21, 2020 4:15 pm

I seem to have the missed the rather awkward point that RPi SPI ports do not operate in slave mode. Unless the NIM can be persuaded to operate as an SPI slave, directly connecting the NIM to the RPi SPI ports is not going to work. It may be possible to use the RPi PCM input to accept the NIM SPI output.

In the meantime, it looks like you can make the NIM operate as an SPI master by changing 2 configuration registers.

cd /home/pi/longmynd

nano stv0910_regs_init.h

On line 38, change 0x00 to 0x40

{ RSTV0910_OUTCFG2, 0x40 }, /* OUTCFG2 all Transport stream signals not inverted */

This inverts the VALID signal to active low, which is the norm for an SPI SS/CE enable input.

On line 402, change 0x80 to 0xc0

{ RSTV0910_P2_TSCFGH, 0xc0 }, /* P2_TSCFGH */

This selects serial data output.

There is also an RSTV0910_P1_TSCFGH register, so make sure you get the correct one.

CTRL-X and Y to save and exit

Rebuild Longmynd and reboot

rm *.o

make (there will be a few warnings from the compiler)

sudo reboot

The serial data comes out of both D0 and D7 on the NIM. I haven't connected it to anything yet, but I can see the 0x47 packet start byte on the scope.

The clock still runs continuously, but I don't think that will be a problem for an SPI port.

Longmynd won't display video anymore of course, but you should get the text info box, although sometimes it says Found Headers, but doesn't display the info.

Brian

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

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

Post by G4EWJ » Thu May 21, 2020 6:01 pm

I repeated the kernel module latency test on a Portsdown displaying an SR1000 transmission on the small screen and it varied from 2 to 12us, so I think that an interrupt based solution would still be risky.

Brian

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

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

Post by YL3AKC » Fri May 22, 2020 3:55 am

G4EWJ wrote:
Thu May 21, 2020 6:01 pm
I repeated the kernel module latency test on a Portsdown displaying an SR1000 transmission on the small screen and it varied from 2 to 12us, so I think that an interrupt based solution would still be risky.

Brian
So you thing interrupt+GPIO is dead end? 2 uS latency mean 500 kBytes/s. That is 4 MBit/s for TS. Beacon transport stream rate is ~2.4 MBit/s. Should work for version 0.1 (alpha). On future I am planning to use DMA+parallel GPIO. This must boost data rates to electrical GPIO limits.

Can you share latency test code?

PS: didn't make anything for project on Thursday. Tody I'll try to work on kernel module.

Janis, YL3AKC.

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

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

Post by MW0RUD » Fri May 22, 2020 1:27 pm

Hi Brian,
Those measurements are useful, it might just work but ideally we would need a bigger buffer. You can chain those I mentioned but once you start having 4 of them on a board other devices and methods start to look more appealing.

Looking at the SPI on the Pi it looks like it need 32bit words for DMA use and it has a fairly limited set of bitrates so we are unlikely to be able to match the in and out bitrates of the NIM and the Pi closely for lots of symbol rates. Whatever the intermediate device is it is going to need a reasonably sized buffer and a way to gate the Pi to read from it by whichever method so that the Pi never drains the buffer and never lets it fill completely.

I was thinking for example if we sued using DMA SPI read on the Pi we need to set a page size(SPIDLEN) sufficiently large that we have time to service the SPIDone interrupt before before the external buffer has received a page at the max symbol rate we are supporting. The SPIDone interrupt service will need check if there is more than a page in the external buffer and re-trigger the transfer immediately or set an interrupt to trigger once the external buffer fills sufficiently. This would then mean we need slightly more than 2 pages of external buffer which can then be filled by any convenient mechanism from the NIM. Thoughts?

As mainly a software person my knowledge of what devices out out there is rather poor, but I did think that programming devices does add an extra level of homebrew complexity which might be nice to avoid if possible.

Tim

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

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

Post by G4EWJ » Fri May 22, 2020 3:40 pm

>>So you thing interrupt+GPIO is dead end?

I think it's an unknown situation. Based on that last test, you would have to assume 12us and then allow more time to actually input and process the data. If you allow 16us, then you're down to about 60k bytes/s, 480k bits/s, which is barely enough for SR250, for single byte input.

With the 74HCT40105 16 element fifo, that would allow SR4000, but you never know if circumstances will occur which delay the interrupt past 12us and how often that may happen.

Here's the kernel module. It's basically the example from the web site I mentioned above. Latency is best when the cpu is running at maximum speed. I just have a program that loops forever to engage maximum speed.
.
hello5.zip
(3.22 KiB) Downloaded 286 times
.
There are instructions in the C file. I have a program to generate a square wave on GPIO4, if you need that.

Brian

Post Reply

Return to “The Ryde Digital ATV Receiver”