Hobbyist Open Source Satellite Receiver - Raspberry Pi 2???
- Thread starter Titanium
- Start date
- Latest activity Latest activity:
- Replies 390
- Views 68K
- Status
http://www.mumudvb.net/doc/mumudvb-2.0.0/WEBSERVICES.html
Here is the info needed to build an OSD on a STB. All the normal info, freq, pol (HVLR), sr, signal, channel name, number, pids, plus snr, ber, and bandwidth usage. EPG data is also available.
"... formatted in simple XML documents (UTF-8) or in JSON.The output can be easily parsed in PHP for example."
Here is the info needed to build an OSD on a STB. All the normal info, freq, pol (HVLR), sr, signal, channel name, number, pids, plus snr, ber, and bandwidth usage. EPG data is also available.
"... formatted in simple XML documents (UTF-8) or in JSON.The output can be easily parsed in PHP for example."
Been messing around with a few players at the command line. The most promising so far is omxplayer. It is supposedly optimized to take full advantage of the Pis GPU.
In Raspian type the following:
omxplayer -o hdmi yourfavourite.mp4
then ssh into the Pi, run top and be amazed at the low cpu utilization. Quality looks good. I had a video running at 4% cpu but not sure of its resolution.
I dont have a 1080p tv so If someone out there has a 1080p tv, run a 1080 mp4 and post cpu results and general quality impressions.
I am not sure yet if omxplayer can do http streams, but I think it can do udp.
Of course a a front end of sorts would be needed to control it but pieces of this project could be used:
http://blog.donaldderek.com/2013/06/build-your-own-google-tv-using-raspberrypi-nodejs-and-socket-io/
Also getting familiar with mumudvb as well a looking at dvblast on the headend.
In Raspian type the following:
omxplayer -o hdmi yourfavourite.mp4
then ssh into the Pi, run top and be amazed at the low cpu utilization. Quality looks good. I had a video running at 4% cpu but not sure of its resolution.
I dont have a 1080p tv so If someone out there has a 1080p tv, run a 1080 mp4 and post cpu results and general quality impressions.
I am not sure yet if omxplayer can do http streams, but I think it can do udp.
Of course a a front end of sorts would be needed to control it but pieces of this project could be used:
http://blog.donaldderek.com/2013/06/build-your-own-google-tv-using-raspberrypi-nodejs-and-socket-io/
Also getting familiar with mumudvb as well a looking at dvblast on the headend.
I have mumudvb running as a service:
edit /etc/default/mumudvb
change the following to false:
DONTSTARTMUMU=false
run the following commands
chmod 666 /dev/dvb/adapter0/frontend0
chmod 666 /dev/dvb/adapter0/demux0
chmod 666 /dev/dvb/adapter0/dvr0
service mumudvb start
service mumudvb status -> will tell you if the service is running
cat /var/log/syslog ->will show the errors enountered if it does not start.
Try to start the service before doing the chmods and you will see the errors.
Disable the IR sensor and report Signal and SNR in dBm: (TBS cards only)
/etc/modprobe.d/tbs.conf
options tbsfe dbm=1
options isl6423 dbm=1
options dvb_usb disable_rc_polling=1
So far the cpu at least on the ITX box looks good. I can watch 1 channel or 5 at the same time, the cpu stays at 4%. They claim the cpu is not the bottleneck, as it has a light cpu footprint, but network throughput will be the limiting factor.
Looks pretty promising for the Pi2. See attached state file giving stats on all transponder channels.
For example RTA AFGHANISTAN consumes 199KBps or about 1.5Mbps
Mumudvb, with a single tuner, can only see one transponder at a time. When switching between transponders/sats, the hard part is that the player has to be able to kill and restart the mumdvb process on the headend with new tuning parameters (when the tuner and player are not separate its easier). If that process is figured out, there is still a big lag when the thread restarts with new tuning parameters and the tuner initializes. I'm not sure there is a way around the lag. Tuning is not very dynamic.
I think I was operating under the false assumption that the tuner would present all channels on the sat at once.
If all you needed to watch was a single transponder per dish for everyone in the house it would be simple, one tuner/Pi/Wifi adapter at each dish. That is a viable option for me as that's the way its working out now. I put up a dish to get a channel or two on a single transponder. As far as multiple viewers/multiple dishes/transponders (or just multiple viewers watching different transponders on a single dish), you will still need one tuner per viewer, dual output lnbfs, multiswitches etc... Switching between lnbfs is easy using built in diseqc commands. The tuners could still be placed in the diseqc enclosure at the dishes with wifi connection to STBs, eliminating coax to and throughout the house.
Multiple transponders per dish
Single transponder per dish
edit /etc/default/mumudvb
change the following to false:
DONTSTARTMUMU=false
run the following commands
chmod 666 /dev/dvb/adapter0/frontend0
chmod 666 /dev/dvb/adapter0/demux0
chmod 666 /dev/dvb/adapter0/dvr0
service mumudvb start
service mumudvb status -> will tell you if the service is running
cat /var/log/syslog ->will show the errors enountered if it does not start.
Try to start the service before doing the chmods and you will see the errors.
Disable the IR sensor and report Signal and SNR in dBm: (TBS cards only)
/etc/modprobe.d/tbs.conf
options tbsfe dbm=1
options isl6423 dbm=1
options dvb_usb disable_rc_polling=1
So far the cpu at least on the ITX box looks good. I can watch 1 channel or 5 at the same time, the cpu stays at 4%. They claim the cpu is not the bottleneck, as it has a light cpu footprint, but network throughput will be the limiting factor.
Looks pretty promising for the Pi2. See attached state file giving stats on all transponder channels.
For example RTA AFGHANISTAN consumes 199KBps or about 1.5Mbps
Mumudvb, with a single tuner, can only see one transponder at a time. When switching between transponders/sats, the hard part is that the player has to be able to kill and restart the mumdvb process on the headend with new tuning parameters (when the tuner and player are not separate its easier). If that process is figured out, there is still a big lag when the thread restarts with new tuning parameters and the tuner initializes. I'm not sure there is a way around the lag. Tuning is not very dynamic.
I think I was operating under the false assumption that the tuner would present all channels on the sat at once.
If all you needed to watch was a single transponder per dish for everyone in the house it would be simple, one tuner/Pi/Wifi adapter at each dish. That is a viable option for me as that's the way its working out now. I put up a dish to get a channel or two on a single transponder. As far as multiple viewers/multiple dishes/transponders (or just multiple viewers watching different transponders on a single dish), you will still need one tuner per viewer, dual output lnbfs, multiswitches etc... Switching between lnbfs is easy using built in diseqc commands. The tuners could still be placed in the diseqc enclosure at the dishes with wifi connection to STBs, eliminating coax to and throughout the house.
Multiple transponders per dish
Single transponder per dish
Last edited:
On the player side:
(Standalone streaming player)
I used the following information provided by mumudvb on the headend.
Sat is 97W
Channel number 14 : THE UNIV. NETWORK
Unicast link : http://192.168.0.3:5000/bysid/2040
Multicast ip : :0
On the command line on the player PI I issued the following command:
omxplayer -r -o hdmi http://192.168.0.3:5000/bysid/2040
CPU was around 8.3 % mem at 1.7% and stream was smooth and flawless.
GIven the CPU data of both headend and player, and measured bandwidth of the USB bus I think the Pi2 would work as an all in one STB.
(Standalone streaming player)
I used the following information provided by mumudvb on the headend.
Sat is 97W
Channel number 14 : THE UNIV. NETWORK
Unicast link : http://192.168.0.3:5000/bysid/2040
Multicast ip : :0
On the command line on the player PI I issued the following command:
omxplayer -r -o hdmi http://192.168.0.3:5000/bysid/2040
CPU was around 8.3 % mem at 1.7% and stream was smooth and flawless.
GIven the CPU data of both headend and player, and measured bandwidth of the USB bus I think the Pi2 would work as an all in one STB.
Last edited:
I just noticed with omxplayer you can pause the live TV stream (p key or spacebar). Its cool but I'm not sure where its queuing the program on the SD card and what the effect of that is. It restarts right where you left off!
EDIT: It looks like it starts caching it in RAM, pause the stream and total memory used climbs slowly, then stops. then it must start caching to SD.
EDIT: It looks like it starts caching it in RAM, pause the stream and total memory used climbs slowly, then stops. then it must start caching to SD.
Found TBS5922 driver source code here:
https://github.com/ljalves/linux_media/blob/latest/drivers/media/usb/dvb-usb/tbs-qbox22.c
https://github.com/ljalves/linux_media/blob/latest/drivers/media/usb/dvb-usb/tbs-qbox22.c
Update:
I am trying to compile just the TBS open source driver for the tbs5922, not the whole freakin kernel tree.
I'm struggling through the process,but I am at the point where I have the kernel sources in place, I run make on the tbs driver source,
everything goes without error but the driver tbs-qbox22.ko is not produced.
root@pi2:/usr/src/linux-rpi-3.18.y# make drivers/usb/misc/dvbxtras/tbs-qbox22.ko
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CC drivers/usb/misc/dvbxtras/tbs-qbox22.o <------ .o is produced.
MODPOST 0 modules <------------------------------------------------- No .ko file produced ! ARRGGHH!!!!!
Getting close.
I am trying to compile just the TBS open source driver for the tbs5922, not the whole freakin kernel tree.
I'm struggling through the process,but I am at the point where I have the kernel sources in place, I run make on the tbs driver source,
everything goes without error but the driver tbs-qbox22.ko is not produced.
root@pi2:/usr/src/linux-rpi-3.18.y# make drivers/usb/misc/dvbxtras/tbs-qbox22.ko
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CC drivers/usb/misc/dvbxtras/tbs-qbox22.o <------ .o is produced.
MODPOST 0 modules <------------------------------------------------- No .ko file produced ! ARRGGHH!!!!!
Getting close.
Queue the bell sound......ding ding ding!!!
root@pi2:/usr/src/linux-rpi-3.18.y# make drivers/usb/misc/dvbxtras/tbs-qbox22.ko
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CC [M] drivers/usb/misc/dvbxtras/tbs-qbox22.o
MODPOST 1 modules
CC drivers/usb/misc/dvbxtras/tbs-qbox22.mod.o
LD [M] drivers/usb/misc/dvbxtras/tbs-qbox22.ko <<<<<<<<<<<<<<<<<<<<<<<<<<Whoop Whoop!!!!
root@pi2:/usr/src/linux-rpi-3.18.y# make drivers/usb/misc/dvbxtras/tbs-qbox22.ko
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CALL scripts/checksyscalls.sh
CC [M] drivers/usb/misc/dvbxtras/tbs-qbox22.o
MODPOST 1 modules
CC drivers/usb/misc/dvbxtras/tbs-qbox22.mod.o
LD [M] drivers/usb/misc/dvbxtras/tbs-qbox22.ko <<<<<<<<<<<<<<<<<<<<<<<<<<Whoop Whoop!!!!
Here are the instructions I have come up with so far: (remember they dont work!)
Driver building Process
TBS Open Source Drivers
Next, We try to compile only tbs-qbox22, not every ding dang driver in the world!
To be contniued...........
Driver building Process
TBS Open Source Drivers
Code:
sudo apt-get update && sudo apt-get upgrade
apt-get install linux-headers-3.18
apt-get install patchutils
cpan Proc::processTable
cd /usr/src
wget https://github.com/raspberrypi/linux/archive/rpi-3.18.y.tar.gz
tar xvfz rpi-3.18.y.tar.gz
export KERNEL_SRC=/usr/src/linux-rpi-3.18.y
also add to /root/.bashrc to make permanent
cd /usr/src/linux-rpi-3.18.y
cp /usr/src/linux-headers-3.18.0-trunk-rpi2/Module.symvers Module.symvers
ln -s /usr/src/linux-rpi-3.18.y/ /lib/modules/3.18.7-v7+/build
cd /lib/modules/3.18.7-v7+/build
make clean
make mrproper
gzip -dc /proc/config.gz > .config
make prepare
make oldconfig
make modules_prepare
Now get the TBS open source drivers:
mkdir /tbsopen
cd /tbsopen
git clone https://github.com/ljalves/linux_media.git
The driver source for tbs-qbox22 is in drivers/media/usb/dvb-usb
/tbsopen/linux_media/drivers/media/usb/dvb-usb/tbs-qbox22.c
/tbsopen/linux_media/drivers/media/usb/dvb-usb/tbs-qbox22.hNext, We try to compile only tbs-qbox22, not every ding dang driver in the world!
To be contniued...........
Last edited by a moderator:
From what I can tell, the running kernel and source I used to compile are different, thats why the TBS driver failed to load.
I am have trouble finding kernel source for 3.18.7-v7+.
Code:
root@pi2:~# uname -r
3.18.7-v7+
root@pi2:~# modinfo /root/tbs-qbox22.ko
filename: /root/tbs-qbox22.ko
license: GPL
version: 0.2
description: Driver for TBS QBOX22
author: Bob Liu <Bob@turbosight.com>
srcversion: A5A3B59B65C4D7F5FDB43CF
alias: usb:v04B4p5922d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v734Cp5922d*dc*dsc*dp*ic*isc*ip*in*
depends:
intree: Y
vermagic: 3.18.9-v7 SMP preempt mod_unload modversions ARMv7
parm: debug:set debugging level (1=info 2=xfer (or-able)). (debugging is not enabled) (int)
parm: adapter_nr:DVB adapter numbers (array of short)
root@pi2:~#I am have trouble finding kernel source for 3.18.7-v7+.
Last edited by a moderator:
OK I did not want to go this route but....I am using the source code to compile a new kernel.
That way the module will match the kernel version. There is no source code to be had for the latest raspian kernel 3.18.7-v7+
I will post new instructions at that time when I hopefully get everything going.
The problem is you go to 10 different sites and they tell you 10 different ways to do it.
That way the module will match the kernel version. There is no source code to be had for the latest raspian kernel 3.18.7-v7+
I will post new instructions at that time when I hopefully get everything going.
The problem is you go to 10 different sites and they tell you 10 different ways to do it.
If you compile a custom kernel, watch out doing apt-get update/upgrade later on, it will probably change your custom kernel unless you exclude it.
When you compile it, is it given out any specific errors? You've probably already said it somewhere, but are you using Rasbian, Debian, etc? Are you doing all this from CL or from a term within X?
I'll probably get yelled at by someone for suggesting this and you should use sudo, not sudo su, but for the one session when you compile try and use sudo su and see if it works. I was having a problem the other day with permissions on the Pi2 compiling something that shouldn't have been a problem, but was. Might also be GCC or something needs to be manually updated even though you did update/upgrade, any errors during update/upgrade?
When you compile it, is it given out any specific errors? You've probably already said it somewhere, but are you using Rasbian, Debian, etc? Are you doing all this from CL or from a term within X?
I'll probably get yelled at by someone for suggesting this and you should use sudo, not sudo su, but for the one session when you compile try and use sudo su and see if it works. I was having a problem the other day with permissions on the Pi2 compiling something that shouldn't have been a problem, but was. Might also be GCC or something needs to be manually updated even though you did update/upgrade, any errors during update/upgrade?
ARaine,
Every thing is compiling fine. I log in as root so no su or sudo issues! I built the driver using 3.18.y kernel source but I am running 3.18.7-v7+.
The driver compiled just fine but it does not match the running kernel version, the reason for Error: could not insert module tbs-qbox22.ko: Invalid module format when inserting the tbs=qbox22.ko module. There is a disconnect between the rapberry pi foundation's releases and available source code.
There is no 3.18.7-v7+ kernel source that I can find.
The only way to get this to work I can see is to use the 3.18.y kernel source mentioned in above posts, build, install and run that kernel,
and build all modules with the source that matches the running kernel. My new kernel has been compiling for a few hours now.
And like you mentioned DO NOT UPGRADE THE KERNEL EVER!
I never run a gui or X and do everything at the command line.
I am using the latest Raspian Debian Wheezy from here: http://www.raspberrypi.org/downloads/
Every thing is compiling fine. I log in as root so no su or sudo issues! I built the driver using 3.18.y kernel source but I am running 3.18.7-v7+.
The driver compiled just fine but it does not match the running kernel version, the reason for Error: could not insert module tbs-qbox22.ko: Invalid module format when inserting the tbs=qbox22.ko module. There is a disconnect between the rapberry pi foundation's releases and available source code.
There is no 3.18.7-v7+ kernel source that I can find.
The only way to get this to work I can see is to use the 3.18.y kernel source mentioned in above posts, build, install and run that kernel,
and build all modules with the source that matches the running kernel. My new kernel has been compiling for a few hours now.
And like you mentioned DO NOT UPGRADE THE KERNEL EVER!
I never run a gui or X and do everything at the command line.
I am using the latest Raspian Debian Wheezy from here: http://www.raspberrypi.org/downloads/
As far as su vs sudo.
The rule of not logging in as root has validity when you are a sysadmin working on a production system in
a situation where a mistake would cost great financial loss. A raspberry Pi is not such a system it is
actually the opposite. Go ahead and log in as root. Forget the su this and sudo that, its too much to deal with.
Part I.
Get Running Kernel with matching source.
In preparation for building drivers.
As a little bonus, the linux source also had the Tevii 660 source code that I changed, I need to find the 662 firmware, rename it to dvb-usb-s660.fw and see if the thing works. The driver is being recognized on the Pi2:
Next Part will be to get the TBS-5922 driver working on the Pi2, now that the kernel matches the source.
The rule of not logging in as root has validity when you are a sysadmin working on a production system in
a situation where a mistake would cost great financial loss. A raspberry Pi is not such a system it is
actually the opposite. Go ahead and log in as root. Forget the su this and sudo that, its too much to deal with.
Part I.
Get Running Kernel with matching source.
In preparation for building drivers.
Code:
I Login as root:.[/SIZE][/SIZE][/SIZE][/SIZE]
[SIZE=5][SIZE=4][SIZE=5][SIZE=4]uname -r
result: 3.18.7-v7+
apt-get update
apt-get upgrade
apt-get install bc
cd /usr/src
wget https://github.com/raspberrypi/linux/archive/rpi-3.18.y.tar.gz
tar xvfz rpi-3.18.y.tar.gz
cd /usr/src/linux-rpi-3.18.y
make bcm2709_defconfig
**************************************************
SUPER SECRET OPTIONAL EXPERIMENTAL UNPROVEN STEP!
Try to get Tevii S662 working:
nano /path/to/linux-rpi-3.18.y/drivers/media/usb/dvb-usb/dw2102.c
#ifndef USB_PID_TEVII_S660
#define USB_PID_TEVII_S660 0xd662 <---change this to 662 from 660
#endif
**************************************************
make
mv /lib/modules/3.18.7+ /lib/modules/3.18.7+.bak
mv /lib/modules/3.18.7-v7+ /lib/modules/3.18.7-v7+.bak
make modules
make modules_install
sudo cp arch/arm/boot/zImage /boot/kernelnew.img
nano /boot/config.txt
add the following:
kernel=kernelnew.img
shutdown -r now
uname -r
root@pi2:~# uname -r
3.18.9-v7
http://www.raspberrypi.org/documentation/linux/kernel/building.mdAs a little bonus, the linux source also had the Tevii 660 source code that I changed, I need to find the 662 firmware, rename it to dvb-usb-s660.fw and see if the thing works. The driver is being recognized on the Pi2:
Code:
[ 4.862267] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[ 4.877855] usb 1-1.4: Direct firmware load for dvb-usb-s660.fw failed with error -2
[ 4.891469] dvb-usb: did not find the firmware file. (dvb-usb-s660.fw) Please see linux/Documentation/dvb/ for more details on firmware-problems. (-2)
[ 4.911159] usbcore: registered new interface driver dw2102Next Part will be to get the TBS-5922 driver working on the Pi2, now that the kernel matches the source.
Last edited:
This is using S660 firmware for now, until I find S662 firmware.
Promising but looks like the frontend did not attach.
Promising but looks like the frontend did not attach.
Code:
[ 1416.818223] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
[ 1416.919186] usb 1-1.4: New USB device found, idVendor=9022, idProduct=d662
[ 1416.919212] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1416.919230] usb 1-1.4: Product: DVB-S/S2 Box
[ 1416.919247] usb 1-1.4: Manufacturer: Jactek
[ 1416.919263] usb 1-1.4: SerialNumber: 000000031
[ 1416.920569] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[ 1416.920743] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[ 1416.920761] dw2102: start downloading DW210X firmware
[ 1417.048111] dvb-usb: found a 'TeVii S660 USB' in warm state.
[ 1417.048356] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 1417.048634] DVB: registering new adapter (TeVii S660 USB)
[ 1417.176124] dvb-usb: MAC address: ff:ff:ff:ff:ff:ff
[ 1417.204667] Invalid probe, probably not a DS3000
[ 1417.204706] dvb-usb: no frontend was attached by 'TeVii S660 USB'
[ 1417.248088] Registered IR keymap rc-tevii-nec
[ 1417.248708] input: IR-receiver inside an USB DVB receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.4/rc/rc0/input1
[ 1417.249060] rc0: IR-receiver inside an USB DVB receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.4/rc/rc0
[ 1417.249081] dvb-usb: schedule remote query interval to 150 msecs.
[ 1417.249102] dvb-usb: TeVii S660 USB successfully initialized and connected.- Status
Similar threads
