Hobbyist Open Source Satellite Receiver - Raspberry Pi 2???
- Thread starter Titanium
- Start date
- Latest activity Latest activity:
- Replies 390
- Views 71K
- Status
I recommend the hauppauge 950q. There are cheaper ones out there that work, but not as stable or fast as the 950q
UDL
Thanks! I was racking my brain on which one to get. Was looking at Hauppauge and Kworld. But with Kworld you don't know if you will get V1 V2 or V3.
I finally found some time yesterday afternoon to get my hands dirty with the PI2. To any Linux beginners out there find a project and get to know your hardware and find out any idiosyncrasies now. Example: The Edimax 802.11n adapter will cut out continuously unless you turn off power management of it.
My sub-project is a Openelec/Kodi/TVHeadend box. It was interesting to see the interface, the organization of media types,and all the different plugins available.
I also looked at where you could subdivide processing power into different Pi units. One interesting feature I noticed was how you could separate out file serving.
You could have separate PIs with disk space for Movies, Pictures, TV shows and Music if you wanted to go that far. Lots of options of where to store media and separate stores for each media type is possible. Having media on a central file server also allows access to it from any tv in the house. It was also a good time to organize all my media on my file server too.
The next point of interest is remote control. Kodi offers web page I ran on a tablet that has a remote controller. Sorta cool.
I also have a small Logitech wireless keyboard with built in touchpad. I ended up using both as one did things better the the other. If I had to pick one it would probably be the mini keyboard w/ touchpad.
One more thing I realized is I want a box that does satellite and OTA. Right now I need pile of remotes to switch from watching satellite and antenna.
It would be nice to have a channel list containing both, seamlessly surfing between satellite and OTA.
Now if you have both tuners on one box, DVR functionality is merged. All my FTA receivers have DVR functionality but with OTA I have none. Also as mentioned earlier something recorded on one TV is watchable from anywhere using a central media server.
All in all the PI2 has functioned pretty well. I could play music and picture media in a slide show at the same time with no problems. Recorded video seemed to play OK too.
So far I have only worked with media on a CIFS share and currently have no tuners. The main point of the exercise is to see whats out there and how other products work and get ideas, and mainly get the PI2 up and running and see how well it worked.
Last edited:
I should add that I haven't tested any tuners on the RPI but I do use them extensively in Linux on a PC. It's on my to do list to try them in the RPI and confirm it has the USB bandwidth nessisary
UDL
UDL
Next on my list is to bring a pi2 into the lab and do a proper benchmarking of the wired Ethernet. Hopefully next week I will post true max up and down figures with pretty graphs.
I am curious of the true bandwidth of the USB also. So theoreticaly usb 2.0 is 60 MegaBytes per second which translates into 480 Megabits per second. Seems like that would be enough if the pi yields close to theoretical values.
I've been told it's not even close to theoretical. I'm hoping the rpi2 is better. So I'm very curious of the results you find. Using dd on a USB hard drive on a PC then on the rpi2 should give you a good idea.
UDL
Let me lay out my methodology for testing wired Ethernet speed, and other concerns, mainly unforeseen bottlenecks. Then I will propose scenarios for benchmarking USB speeds on the PI2.
Let me know if there are any issues.
First: Benchmarking wired Ethernet of the PI2
I will build a Raspian (Debian Wheezy, current version) image and shut down all unnecessary processes. It will be headless and Samba Server installed. No interaction with the PI will be needed other than accessing the share externally.
It will be connected to a port on a Cisco switch hard coded to speed 100, duplex full. The switch will have SNMP turned on and a polling workstation will poll the PI2's switch port for throughput measurements at one second intervals. Polling of the switch port data will not effect the PI as you are really polling the switch's CPU. SNMP polling of a Cisco switch has a negligible effect.
A reference file will be selected of 500MB to 1GB in size. It all depends, I don't want the transfer to end too quickly. Multiple copies of this file will be placed on the PI's CIFS share named File1, File2, File3, File4 etc.... CIFS overhead is not a factor as any overhead will be part of the measurements. CIFS overhead would be a factor in any type of timed transfer scenario. One client workstation will pull File1 from the share, a second client workstation will pull File2 and so on. Maximum outbound throughput will be considered reached when an additional client workstation pull does not increase observed bandwidth utilization.
A similar test will be performed by the client workstations pushing the file to the share.
The true upload and download speeds of the wired Ethernet will then be observed on the graphs produced by the polling software.
One concern I thought of with this scenario is the performance of the microSD card.
I will be using this one:
it is the SanDisk SDSDQUAN-016G-G4A. Here is a note from their website:
"Up to 48MB/s read speed; write speed lower. Based on internal testing; performance may be lower depending on host device, interface, usage conditions and other factors. 1MB=1,000,000 bytes."
That works out to 384 Megabits per second read speed under ideal conditions, but no posted write speeds.
If the bandwidth for file push is way lower than file pull microSD write speed may be at fault.
Let me know if there is a better card out there please.
Second: Benchmarking of True USB Bus speed.
My first thought was to use the same methodology as above using this:
It is a Gigabit Ethernet USB 2.0 adapter with Linux support. But then I thought about the theoretical maximum speed of the microSD as published is 384Mbps whereas theoretical USB max is 480Mbps.
In this case the microSD would be a theoretical bottleneck. Then updatelee mentioned dd to an external drive which would remove any microSD bottlenecks from the equation, especially when there are no published write speeds.
Taking UDL's advice I found this article:
http://www.binarytides.com/linux-test-drive-speed/
"USB 2.0 has a theoretical maximum signaling rate of 480 Mbits/s or 60 Mbytes/s. However due to various constraints the maximum throughput is restricted to around 280 Mbit/s or 35 Mbytes/s. Beyond this the actual speed achieved depends on the quality of the pen drives and other factors too."
Here's another:
http://raspberrypi.stackexchange.com/questions/4268/benchmark-usb-hdd
My only issue is what device to use as the test subject? I don't have anything on hand good enough.
You really want to test a device where the bottle neck is usb bus speed and not read/write times of the media itself.
Is there someone else that can run the USB test using dd?
If not I can try the Gig Ethernet adapter.
So the equation (Measured USB Max Speed) - (Measured Ethernet Max Speed) should give us the remaining throughput left over on the USB bus for a tuner.
Let me know if there are any issues.
First: Benchmarking wired Ethernet of the PI2
I will build a Raspian (Debian Wheezy, current version) image and shut down all unnecessary processes. It will be headless and Samba Server installed. No interaction with the PI will be needed other than accessing the share externally.
It will be connected to a port on a Cisco switch hard coded to speed 100, duplex full. The switch will have SNMP turned on and a polling workstation will poll the PI2's switch port for throughput measurements at one second intervals. Polling of the switch port data will not effect the PI as you are really polling the switch's CPU. SNMP polling of a Cisco switch has a negligible effect.
A reference file will be selected of 500MB to 1GB in size. It all depends, I don't want the transfer to end too quickly. Multiple copies of this file will be placed on the PI's CIFS share named File1, File2, File3, File4 etc.... CIFS overhead is not a factor as any overhead will be part of the measurements. CIFS overhead would be a factor in any type of timed transfer scenario. One client workstation will pull File1 from the share, a second client workstation will pull File2 and so on. Maximum outbound throughput will be considered reached when an additional client workstation pull does not increase observed bandwidth utilization.
A similar test will be performed by the client workstations pushing the file to the share.
The true upload and download speeds of the wired Ethernet will then be observed on the graphs produced by the polling software.
One concern I thought of with this scenario is the performance of the microSD card.
I will be using this one:
it is the SanDisk SDSDQUAN-016G-G4A. Here is a note from their website:
"Up to 48MB/s read speed; write speed lower. Based on internal testing; performance may be lower depending on host device, interface, usage conditions and other factors. 1MB=1,000,000 bytes."
That works out to 384 Megabits per second read speed under ideal conditions, but no posted write speeds.
If the bandwidth for file push is way lower than file pull microSD write speed may be at fault.
Let me know if there is a better card out there please.
Second: Benchmarking of True USB Bus speed.
My first thought was to use the same methodology as above using this:
It is a Gigabit Ethernet USB 2.0 adapter with Linux support. But then I thought about the theoretical maximum speed of the microSD as published is 384Mbps whereas theoretical USB max is 480Mbps.
In this case the microSD would be a theoretical bottleneck. Then updatelee mentioned dd to an external drive which would remove any microSD bottlenecks from the equation, especially when there are no published write speeds.
Taking UDL's advice I found this article:
http://www.binarytides.com/linux-test-drive-speed/
"USB 2.0 has a theoretical maximum signaling rate of 480 Mbits/s or 60 Mbytes/s. However due to various constraints the maximum throughput is restricted to around 280 Mbit/s or 35 Mbytes/s. Beyond this the actual speed achieved depends on the quality of the pen drives and other factors too."
Here's another:
http://raspberrypi.stackexchange.com/questions/4268/benchmark-usb-hdd
My only issue is what device to use as the test subject? I don't have anything on hand good enough.
You really want to test a device where the bottle neck is usb bus speed and not read/write times of the media itself.
Is there someone else that can run the USB test using dd?
If not I can try the Gig Ethernet adapter.
So the equation (Measured USB Max Speed) - (Measured Ethernet Max Speed) should give us the remaining throughput left over on the USB bus for a tuner.
Just a quick note. On Win32 Disk Imager I noted the following when reading and writing an image to the above mentioned microSD:
Read speed 33 MBps = 264 Mbps
Write speed 13 MBps = 104 Mbps
This laptop has a proper card slot.
So far it does not look like the card will be a bottleneck for the Ethernet tests.
Read speed 33 MBps = 264 Mbps
Write speed 13 MBps = 104 Mbps
This laptop has a proper card slot.
So far it does not look like the card will be a bottleneck for the Ethernet tests.
I don't have a way to connect a microSD to my ITX Box to test using dd.
I found a windows program to test it's speed using my laptop's card slot.
Read speed of around 300 Mbps (vs 384 Mbps published) and write speed of about 97 Mbps.
Once again, good enough for Ethernet testing. An inferior microSD card would definitely hurt Pi performance. Doing some research, there are some really really slow microSD cards out there.
I found a windows program to test it's speed using my laptop's card slot.
Read speed of around 300 Mbps (vs 384 Mbps published) and write speed of about 97 Mbps.
Once again, good enough for Ethernet testing. An inferior microSD card would definitely hurt Pi performance. Doing some research, there are some really really slow microSD cards out there.
Last edited:
Here is a test of the microSD on the PI2 itself (I don't know why I didn't think of this before, tired and overworked I guess).
Average read speed: 18.9 MBps or 151.2 Mbps - Half the speed of Windows test of 301.6 Mbps
Average write speed: 16.26 MBps or 130.13 Mbps - Faster than the Windows test of 96.7 Mbps
Read Testing
root@pi2:/shares# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/shares# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 56.9116 s, 18.9 MB/s
root@pi2:/shares# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/shares# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 56.9236 s, 18.9 MB/s
root@pi2:/shares# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/shares# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 56.9216 s, 18.9 MB/s
Average read speed: 18.9 MBps or 151.2 Mbps
Write testing
root@pi2:/shares# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 66.0036 s, 16.3 MB/s
root@pi2:/shares# rm largefile
root@pi2:/shares# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 65.5833 s, 16.4 MB/s
root@pi2:/shares# rm largefile
root@pi2:/shares# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 66.7144 s, 16.1 MB/s
Average write speed: 16.26MBps or 130.13 Mbps
EDIT:
I went ahead and ordered a few of these, from what I read there are somewhat the best
where the SanDisk I am using are somewhere around second best, we shall see.
Average read speed: 18.9 MBps or 151.2 Mbps - Half the speed of Windows test of 301.6 Mbps
Average write speed: 16.26 MBps or 130.13 Mbps - Faster than the Windows test of 96.7 Mbps
Read Testing
root@pi2:/shares# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/shares# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 56.9116 s, 18.9 MB/s
root@pi2:/shares# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/shares# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 56.9236 s, 18.9 MB/s
root@pi2:/shares# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/shares# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 56.9216 s, 18.9 MB/s
Average read speed: 18.9 MBps or 151.2 Mbps
Write testing
root@pi2:/shares# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 66.0036 s, 16.3 MB/s
root@pi2:/shares# rm largefile
root@pi2:/shares# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 65.5833 s, 16.4 MB/s
root@pi2:/shares# rm largefile
root@pi2:/shares# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 66.7144 s, 16.1 MB/s
Average write speed: 16.26MBps or 130.13 Mbps
EDIT:
I went ahead and ordered a few of these, from what I read there are somewhat the best
where the SanDisk I am using are somewhere around second best, we shall see.
Last edited:
I wrote this in memory of LLAP live long and prosper; RIP good ole' boy Leo Nimoy
So, if you'll all be set for the instruction "as read" byte by byte; Universal MIPS is.................................................................................................................................................................................................................................> this one; that doe, it does; but right now if you want even a clock hooked into it; the FRO has to be mounted outside of the single board you have mounted the tuner to; cuz;
And when you "hook it up" to the cable/dish/internet/antenna -> who is gonna call out a name for it?
PIdo
Really, I like the bigger chipset used like the last one that only did 8psk and h.264; because by the second build; all resistance's and tuning. When you add to it by having to re-think the "hole" thing; you might as well build each of the things as separate boxes; they like it!@which chip you gotta have....
Hey, just use the "audio" section to do it; you'll clean up the 75 ohm problem child (it is isolated from the clock)...
AND CUT IT UP INTO d#& artistry
Please send out as many as you have...C Banks rivet's are straight to the source.
College named port; source of Rum now booking the
1) cost factoring
2) build #
3) Bank account
Really, the only thing that works does...ATSC/NTSC/DVB-S2 8VSB/XXpsk/+
So, if you'll all be set for the instruction "as read" byte by byte; Universal MIPS is.................................................................................................................................................................................................................................> this one; that doe, it does; but right now if you want even a clock hooked into it; the FRO has to be mounted outside of the single board you have mounted the tuner to; cuz;
And when you "hook it up" to the cable/dish/internet/antenna -> who is gonna call out a name for it?
PIdoReally, I like the bigger chipset used like the last one that only did 8psk and h.264; because by the second build; all resistance's and tuning. When you add to it by having to re-think the "hole" thing; you might as well build each of the things as separate boxes; they like it!@which chip you gotta have....
Hey, just use the "audio" section to do it; you'll clean up the 75 ohm problem child (it is isolated from the clock)...
AND CUT IT UP INTO d#& artistry
Please send out as many as you have...C Banks rivet's are straight to the source.
College named port; source of Rum now booking the
1) cost factoring
2) build #
3) Bank account
Really, the only thing that works does...ATSC/NTSC/DVB-S2 8VSB/XXpsk/+
A few more tests:
Sandisk Ultra microSD HC Class 10 16GB
PI Model B (not +) Using supplied adapter
Average write speed: 13.6 MBps/108.8 Mbps
Average read speed: 18.6 MBps/148.8 Mbps
Pi2 - previous test for comparison
Average write speed: 16.26 MBps/130.13 Mbps <----- Significantly higher write speed with Pi2
Average read speed: 18.9 MBps/151.2 Mbps
Transcend SD HC Class 10 8GB
PI Model B (not +)
Average write speed: 10 MBps/80 Mbps <----- Significantly lower write speed than Sandisk Ultra in PiB
Average read speed: 18.2 MBps/145.6 Mbps
Sandisk Ultra microSD HC Class 10 16GB
PI Model B (not +) Using supplied adapter
Average write speed: 13.6 MBps/108.8 Mbps
Average read speed: 18.6 MBps/148.8 Mbps
Pi2 - previous test for comparison
Average write speed: 16.26 MBps/130.13 Mbps <----- Significantly higher write speed with Pi2
Average read speed: 18.9 MBps/151.2 Mbps
Transcend SD HC Class 10 8GB
PI Model B (not +)
Average write speed: 10 MBps/80 Mbps <----- Significantly lower write speed than Sandisk Ultra in PiB
Average read speed: 18.2 MBps/145.6 Mbps
Pi2 USB Bus Speed ~ 246.4Mbps
I found a Western Digital USB connected SATA drive Model Number WD10EADS published transfer rate of drive itself is 300Mbps.
Average read speed: 30.8MBps/ 246.4Mbps
Write speed was disregarded due to the added latency of writing.
(A better drive may also yield higher results)
So if the Ethernet interface takes all of 100Mbps (reports on the internet have people claiming speed in the high 80Mbps range) that still leaves 146Mbps for a tuner.
I think this also shows you don't want a USB drive connected to the same Pi as the tuner, as it could probably choke off the tuner under high transfer rate conditions. This is a perfect scenario for a second Ethernet connected Pi to act as a file server in Media Center/DVR situations. Transfer all the files you want and you wont oversubscribe the USB bus, you are limited to 100Mbps in this situation.
The project I am currently fiddling with has a separate box acting as the Media server.
Here is the raw data:
root@pi2:/mnt/usb/test# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 34.2244 s, 31.4 MB/s
root@pi2:/mnt/usb/test# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/mnt/usb/test# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 35.5252 s, 30.2 MB/s
root@pi2:/mnt/usb/test# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/mnt/usb/test# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 34.8383 s, 30.8 MB/s
I found a Western Digital USB connected SATA drive Model Number WD10EADS published transfer rate of drive itself is 300Mbps.
Average read speed: 30.8MBps/ 246.4Mbps
Write speed was disregarded due to the added latency of writing.
(A better drive may also yield higher results)
So if the Ethernet interface takes all of 100Mbps (reports on the internet have people claiming speed in the high 80Mbps range) that still leaves 146Mbps for a tuner.
I think this also shows you don't want a USB drive connected to the same Pi as the tuner, as it could probably choke off the tuner under high transfer rate conditions. This is a perfect scenario for a second Ethernet connected Pi to act as a file server in Media Center/DVR situations. Transfer all the files you want and you wont oversubscribe the USB bus, you are limited to 100Mbps in this situation.
The project I am currently fiddling with has a separate box acting as the Media server.
Here is the raw data:
root@pi2:/mnt/usb/test# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 34.2244 s, 31.4 MB/s
root@pi2:/mnt/usb/test# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/mnt/usb/test# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 35.5252 s, 30.2 MB/s
root@pi2:/mnt/usb/test# sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@pi2:/mnt/usb/test# dd if=./largefile of=/dev/null bs=8k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 34.8383 s, 30.8 MB/s
Last edited:
Nice work Fred!
You've certainly dived into this head first.
Interesting data on the SD cards.
So at the cost level of 2/3 Pi's maybe there are better choices out there?
You've certainly dived into this head first.
Interesting data on the SD cards.
Might end up with 3 Pi's by the time all the features are implemented!
Might end up with 3 Pi's by the time all the features are implemented!So at the cost level of 2/3 Pi's maybe there are better choices out there?
Actually probably a few more than that. Read over this and you might see where I am going:
http://www.satip.info/news
Yes it may sound crazy, yes someone is already doing it but, this may be interesting to try:
I'm going to try a prototype of a zero-coax, switch-less, diseqc-less, 22Khz-less, zero transmission loss system. How would you like to walk out to your dish, pop out your phone, tweak the signal and go on about your business? I been a Network Engineering consultant for Fortune 500 companies and governments integrating distributed systems of all types for over 20 years. This is just another system I think I can have fun with trying to bring it into the 21st Century with current technology. The key here is "distributed." Or more specifically a three tiered architecture.
I am thinking of bringing the tuner out to the lnbf, converting it to IP right there with a Pi, with near zero transmission loss, no more long coax runs. Daisy chained Cat 5 w/modified POE between dishes or 802.11n with wired power.
I am thinking of a central Media Server / TVHeadend ITX system.
I am thinking of frontends at the Televisions (Pi?).
I may also put a tuner at my Channel Master TV antenna and combine OTA and FTA channels.
There are bandwidth contention issues, interference issues, lack of time issues, programming skills issues, no experience with USB tuners issues, all kinds of issues to work out.
I have two PIs and a mini ITX system, thats enough to get started.
And positioning, I'm thinking a GPIO module.
This guy here can track and film moving planes with a Pi, I'm sure using GPIO to point to stationary satellites is not out of the realm of possibility:
https://blog.adafruit.com/2014/12/0...er-your-house-piday-raspberrypi-raspberry_pi/
Last edited:
I just had my first solar outage of the year, and I almost had a heart attack. And then I looked at my kapersky to count how many attacked.
What you are doing is an end to end; singled. end to end solution is already in equipment listed
If you send everybody equipment that wants "the additional singles" right into the system; then each of them add the "each" single device; and allow the Network System to grow. Each node on the system checks in it's bandwidth to the wireless device. Each provide each other the network nodes for each reception available as the channels list and guides selection. A slingbox does this; and so does a genie (single ended wirelessv is a cellphone size).
It is a fantastic discussion in FTA mode; as every device made these days is just a like!
Netflux has alot of satellite dishes; so will your network find the additional required in carriage is a monthly fee! and give away the rest!
Last edited:
I've started researching USB tuners, read lots of good posts here and over at Rick's site and I am ready to buy.
The Prof 7500 looks like it is no where to be found?
Is the TBS 5922 with CrazyCat drivers a good place to start?
Or the TBS 5980?
The Prof 7500 looks like it is no where to be found?
Is the TBS 5922 with CrazyCat drivers a good place to start?
Or the TBS 5980?
The TBS 5922 may be ok, assuming you write your own drivers, or use your own software. I bought one last week and it will not work with openelec. That is as far as I got. I still have more research and testing to do.
The 5922 is supposed to work. Ive been cruising around tvheadend.org for info too.
Apparently logging can be turned on to gain some additional info:
https://tvheadend.org/boards/4/topics/12417?r=12429#message-12429
Here is another source of info on a Pi 5922 issue:
http://www.tbsdtv.com/forum/viewtopic.php?f=45&t=9255
Specifically a post from updatelee saying:
"do you have dvb-usb-tbsqbox-id5922.fw in /lib/firmware ? Im guessing you dont."
List of TBS supported cards with CrazyCat Drivers at bottom of page:
https://github.com/ljalves/linux_media/wiki
Last edited:
- Status
Similar threads
