Potential DATV settop box project (aka the Ryde project)
Re: Potential DATV settop box project (aka the Ryde project)
Tim,
Are you looking at the BCM2835 peripherals document? The errata document suggests that the SPI clock divisor is a multiple of 2 rather than a power. The BCM2711 peripherals document for the RPi4 has it as a multiple of 2.
I don't think it would be possible for a direct connect SPI solution, convenient though that would be. The PIC is the middle idea would work with the PIC as an SPI slave. It signals to the RPi when data is available and the RPi reads it until there's no more data available. The dsPIC I'm using has 14k bytes available for buffering.
There's probably no need to delimit the data sent to the RPi from the buffer on a packet boundary, but if it did, the buffer could return a packet of zeros if there isn't any data available. The RPi can be chaining a ring of several 188 byte DMA buffers until it noticed that the data available signal from the buffer had gone. It wouldn't matter if it received a few zero packets. If we're looking at 8M bits/s as a target to allow SR4000, that would be a light load for the RPi.
Brian
Are you looking at the BCM2835 peripherals document? The errata document suggests that the SPI clock divisor is a multiple of 2 rather than a power. The BCM2711 peripherals document for the RPi4 has it as a multiple of 2.
I don't think it would be possible for a direct connect SPI solution, convenient though that would be. The PIC is the middle idea would work with the PIC as an SPI slave. It signals to the RPi when data is available and the RPi reads it until there's no more data available. The dsPIC I'm using has 14k bytes available for buffering.
There's probably no need to delimit the data sent to the RPi from the buffer on a packet boundary, but if it did, the buffer could return a packet of zeros if there isn't any data available. The RPi can be chaining a ring of several 188 byte DMA buffers until it noticed that the data available signal from the buffer had gone. It wouldn't matter if it received a few zero packets. If we're looking at 8M bits/s as a target to allow SR4000, that would be a light load for the RPi.
Brian
Re: Potential DATV settop box project (aka the Ryde project)
Ah I was, and the RPi spi docs seem to be out of date and make a similar mistake.
I was just having a quick look on Farnell at dsPIC devices and came to a similar conclusion, several with multiple 15Mbps SPI peripherals and comparatively loads of RAM.G4EWJ wrote: ↑Fri May 22, 2020 5:26 pmI don't think it would be possible for a direct connect SPI solution, convenient though that would be. The PIC is the middle idea would work with the PIC as an SPI slave. It signals to the RPi when data is available and the RPi reads it until there's no more data available. The dsPIC I'm using has 14k bytes available for buffering.
Out of curiosity how easy are they to program? Could we use the GPIO on the Pi to do it so we can push firmware updates easily?
I hadn't thought of delimiting on packet boundaries, I was just thinking of it as a generic bitstream which would be more problematic to stuff a load of 0s in to randomly.G4EWJ wrote: ↑Fri May 22, 2020 5:26 pmThere's probably no need to delimit the data sent to the RPi from the buffer on a packet boundary, but if it did, the buffer could return a packet of zeros if there isn't any data available. The RPi can be chaining a ring of several 188 byte DMA buffers until it noticed that the data available signal from the buffer had gone. It wouldn't matter if it received a few zero packets. If we're looking at 8M bits/s as a target to allow SR4000, that would be a light load for the RPi.
Tim
Re: Potential DATV settop box project (aka the Ryde project)
There's plenty of free development stuff for PICs. I use the PICkit3 USB programmer. I mostly work with the dsPIC33FJ128GP802 which I used in DigiLite and DigiThin, but there may be slightly cheaper variations of the chip that would do the job. I've pushed both SPI ports simultaneously up to 22MHz and it looks OK.
They have flash memory, so the chip could have a resident monitor program and accept updates via the serial port. This could also be the command path for intelligent packet filtering.
Brian
They have flash memory, so the chip could have a resident monitor program and accept updates via the serial port. This could also be the command path for intelligent packet filtering.
Brian
Re: Potential DATV settop box project (aka the Ryde project)
Looks like pickle can probably program them directly from the GPIO so we could build that functionality into a board to save homebrewers having to do the initial programming or putting pre programmed chips in the shop like the FTDI
Tim
Tim
Re: Potential DATV settop box project (aka the Ryde project)
Its amazing what you can do with junk box parts, with a Raspberry Pi B rev2 and a NEC remote that I think came with a RTL dongle I have been writing some UI code.
https://youtu.be/-twkJDGAyi0
Currently its just a UI and video player, LongMynd integration is the next task once I finish getting my MiniTiouner working (regulator mounting hardware finally arrived this morning), hopefully I will have a demo with an actual signal in the not too distant future.
What Works:
Tim
I made a quick video demo of what is working so far:https://youtu.be/-twkJDGAyi0
Currently its just a UI and video player, LongMynd integration is the next task once I finish getting my MiniTiouner working (regulator mounting hardware finally arrived this morning), hopefully I will have a demo with an actual signal in the not too distant future.
What Works:
- Integrated VLC video player
- Drawing menu over the screen including VLC (https://youtu.be/0IzH5drBGiI)
- Menu navigation with IR remote
- Ability to enter Frequency, Symbol Rate, LNB Voltage and to select which NIM input to use
- Write code to start and restart LongMynd based on current setting
- Connect LongMynd TS output to internal VLC player
- Read LongMynd status FIFO to get lock state
- Add a lot of code comments
- Add sensible defaults
- Config files for persistent settings
- Tidy up and release pyDispmanx Raspberry Pi GPU module
- Possible test on a Raspberry Pi 4
- Auto start on boot script
- Install and update scripts
- SD card image
- LNB IF Config
- On screen display of signal parameters
- Presets
- Raspberry Pi GPIO status flags
- Tool for setting up IR remote
- Things I haven't thought of
Tim
Re: Potential DATV settop box project (aka the Ryde project)
>>Looks like pickle can probably program them directly from the GPIO
Nice spellchecker.
That would be useful to avoid pre-programming the PICs.
http://picpgm.picprojects.net/install_raspberry_pi.html
Brian
Nice spellchecker.
That would be useful to avoid pre-programming the PICs.
http://picpgm.picprojects.net/install_raspberry_pi.html
Brian
Re: Potential DATV settop box project (aka the Ryde project)
OK! GPIO+IRQ is too slow according to Brian. There are many more solutions for this:
1) Parallel GPIO + DMA, but I have no idea how to work with DMA. This could achieve high speeds.
2) FIFO IC => parallel-to-SPI IC => SPI+DMA (already in stock kernel). I recommend to use little more exotic IC SN74ALVC7813 because it have 8 bits already (actually 18 bit wide), and more important: it have much better access times and not so expensive. Then it goes to parallel in - serial out shift register 74LV165A and then to SPI bus. Good news is that SPI driver already have DMA support and you can access it simply by reading /dev/spidev0.0 file. With these component it is possible to achieve TS speed with many tenths of MBit/sec which is also usable for experiments with commercial transponders.
3) dsPIC solution, but I don't like that there is IC, who need to be programmed before can be used. additional work for enduser if he/she assemble themself or additional programming before selling in BATC shop.
4) FPGA most elegant, but most complex for designing. I have only little experience with FPGAs and don't have any dev board, so can't help much. Programming problems are the same as for dsPIC solution.
I have to order some components from farnell/digikey anyway, so I can add these chips for experiments.
Janis, YL3AKC
1) Parallel GPIO + DMA, but I have no idea how to work with DMA. This could achieve high speeds.
2) FIFO IC => parallel-to-SPI IC => SPI+DMA (already in stock kernel). I recommend to use little more exotic IC SN74ALVC7813 because it have 8 bits already (actually 18 bit wide), and more important: it have much better access times and not so expensive. Then it goes to parallel in - serial out shift register 74LV165A and then to SPI bus. Good news is that SPI driver already have DMA support and you can access it simply by reading /dev/spidev0.0 file. With these component it is possible to achieve TS speed with many tenths of MBit/sec which is also usable for experiments with commercial transponders.
3) dsPIC solution, but I don't like that there is IC, who need to be programmed before can be used. additional work for enduser if he/she assemble themself or additional programming before selling in BATC shop.
4) FPGA most elegant, but most complex for designing. I have only little experience with FPGAs and don't have any dev board, so can't help much. Programming problems are the same as for dsPIC solution.
I have to order some components from farnell/digikey anyway, so I can add these chips for experiments.
Janis, YL3AKC
Re: Potential DATV settop box project (aka the Ryde project)
1) is the optimum solution if it can be done (didn't Evariste play about with ARM DMA).
2) Looks like a conventional Minitiouner interface
3) Why add another processor
4) This is a trivial job for an FPGA but adds extra cost (using a CPLD might be a better option)
I suppose it might be possible to use the CSI lanes on a PI to receive the transport stream.
Are we talking about a set top box or a Pi hat now?
- Charles
2) Looks like a conventional Minitiouner interface
3) Why add another processor
4) This is a trivial job for an FPGA but adds extra cost (using a CPLD might be a better option)
I suppose it might be possible to use the CSI lanes on a PI to receive the transport stream.
Are we talking about a set top box or a Pi hat now?
- Charles
Re: Potential DATV settop box project (aka the Ryde project)
Thanks Janis,
Thanks to everyone for all the ideas and work going in to this project.
Noel
I would agree, as the one who has now programmed over 1,000 FTDI modules, it would be good to avoid parts needing programing before being sold in the shop!3) dsPIC solution, but I don't like that there is IC, who need to be programmed before can be used. additional work for enduser if he/she assemble themself or additional programming before selling in BATC shop.
Thanks to everyone for all the ideas and work going in to this project.
Noel
Re: Potential DATV settop box project (aka the Ryde project)
I know that I'm a little way out of the normal loop however if this project could be capable of decoding DVB-T / T2, even as a side thought, it may increase the audience for this project in the US (where thete is an inexplicable resistance into DVB-S) and may attract more to the BATC & Portsdown etc.
Andy, KA5BBC/MM0BQV