Embedded rtl-sdr setup


1. Basic setup
2. Wireless access




1.
To see in the new version of the osmocom rtl-sdr package http://sdr.osmocom.org/trac/wiki/rtl-sdr the new TPC version, I decided to try to realize my idea about a small embedded rtl-sdr setup.
The basic idea was to run the small rtl-sdr util on a small embedded box connected with the dbv-t dongle at near the antenna, and transmit the data on ethernet connection. The more processing and vizualization can be continue on the desktop/laptop machines.
To this setup I choosed my old small linux box, the NSLU2. It has 2 USB conncetors, network connection, and, more than 2 years ago I installed on it a Debian lenny version, on a 4 Gbyte pendrive.
The running version of linux:

LKGE25945:/home/src# uname -a

Linux LKGE25945 2.6.26-2-ixp4xx #1 Thu Nov 5 05:37:51 UTC 2009 armv5tel GNU/Linux

That time was used as a test setup for a "navigation computer" for a small boat, intelled on it a meteo software, gps and aprs daemon, a Blitzortung lightning detection client, and more. The summary of this can be read here: https://sites.google.com/site/nslu2navigation/
That time I installed on it the development packages, a "native" gcc compiler, to compile source packages directly on it.
Now I tryed to install on it the rtl-sdr software too:
The steps I used:

1. The dependency of the rtl-sdr is the libusb 1.0 version. I didnot find binary package to this armel architecture, I downloaded the source, and compiled it. This was standard procedure with the configure, make, make install commands.

2. On the osmoscom git repository, I didnot find a downloadable compressed (source) package, it can be access only through the git clone mechanism. On my NSLU2 I havenot git installed. I made the git clone on my desktop, and tar-zipped on it, and after I moved the fresh distribution package to the small box with wget.

3. The rtl-sdr packege offers two different way to configure and compile:
a. use the cmake. I tryed to find the binary for debian package to the armel architecture, it seems, it was, but now the repositories are empty for this old debian packages.
b. use the autotool. It run on my NSLU2, I choosed it. It is important to use the -i option, because without it send only errors connected to some m4 macro incompatibilities. I used this command, proposed here: http://sdr.osmocom.org/trac/wiki/rtl-sdr
autoreconf -i
after this you can use the standard method to configure, make and make install (if you would like).

4. to run the tcp version, I use this command:
LKGE25945:/home/src# ./rtl_tcp -a 192.168.1.77 -f 433920000 -s 400
 
The -a parameter is the IP address of this NSLU2 on my local LAN, I use the default port, which is 1234.
I used the 433.92 MHz ISM band for test, because there is nearby outside, a wireless temperature sensor, it sends a short strong signal at every seconds, usefull for test. Finally I choosed 400 ksample for digitization speed. I used the small GP antenna, found in the package of the dvb-t dongle. I dont apply the rtl_tcp file dump feature.

5. When started the rtp_tcp program, it recognized the dvb-t dongle, and start to listen to the default port for a client connection. It send this mesages on an ssh terminal:

LKGE25945:/home/src# ./rtl_tcp -a 192.168.1.77 -f 433920000 -s 400
listen addr 192.168.1.77:1234
Found 1 device(s).
Found Fitipower FC0012 tuner
Using Terratec Cinergy T Stick Black (rev 1)
Tuned to 433920000 Hz.
Tuner gain set to 5 dB.
listening...

6. On the desktop machine I made a simple gnuradio block to make connection to this small server, and receive this TCP stream.
It contains only a TCP source block, and a WX Waterfall/scope or FFT block to receive/visulaise the data stream.

7. If I start the desktop client machine this gnuradio block, on the server you can see this messages:

client accepted!
ll+, now 1
ll+, now 2
ll-, now 0
ll+, now 1
ll-, now 0
.......
.......
comm recv socket error
Signal caught, exiting!
worker socket error
Signal caught, exiting!
all threads dead..
listening...

You can see on this messages, sometimes the server drop the connection, and restart to listening mode.
Practically you need a permanent ssh terminal to monitoring the state of the client.

Conclusion:
Dont wait to much miracles from such a small setup, but its working:
On a small  embedded linux box you can compile and run an easy way the rtl-sdr software, specially the tcp version of it, and you can use this setup as a remote sdr receiver and TCP server. Ofcourse, on your embedded box you need at least min one USB connector to connect the rtl-sdr comaptible dvt-t dongle.
Not all the tryed gnuradio sink blocks were working at the same way. Sometimes the server dropped the connection to the client.
It seems, it need more works around this setup to get a stable version of it.


On the picture you can see my first, temporaly setup of the embedded rtl-sdr server, running on NSLU2 box.
You can see on the NSLU2 box the connections:
Top white cable is the ethernet LAN cabel. The small black box is the pendrive, holding the OP system.
The next small box is the dvb-t dongle, connected to a tv cabel to the Turstain antenne, working on 430 MHz.
The bottom black cabel is the power connection.


Here is the gnuradio block to test the TCP connection:




Mon Apr 30 10:03:50 CEST 2012
Janos Tolgyesi
hg5apz (at) gmail

My first notes about this topics are here, mainly in hungarian:
https://sites.google.com/site/myrtlsdr/
Jegyzetek az rtl-sdr-el valo ismerkedesem tapasztalatairol


2.
Wed May  2 11:50:08 CEST 2012

Following the propose of the Admin on the rtlsdr.com site,
( http://www.rtlsdr.com/, used this nice illustration,
http://www.rtlsdr.com/wp-content/uploads/2012/04/83c67deea9c15e306c4786ebee92d4a42ee38073_large1.jpg )
I reconfigured my basic setup, with more Tux support: this is a "near-movable" version, with wifi connection.

The Tux supports the wireless access of the embedded rtl-sdr server:



I said, "near-movable", because in this moment I didnot deal with the batteries powered solutions for the used small devices, but the connection to the embedded rtlsdr receiver was realized on wireless connection, used an old trick, how can bridgeing two parts of a wired LAN segments into one...
Originally I used this bridgeing to built "wireless cluster", if you search on this idea, you can find this, now never accessible server/link: http://157.181.66.70/wmlc/english.html. This was my server, and this was my web page, I have a local copy of it, I put here two pictures from this publication, clarifying, how I realized the wireless connection of a distributed, virtual machine. It seems, now the problem is similar... Ofcourse the "real" solution would be to build the rtl-sdr utils into an openWrt, and use only one box to serve the "remote sdr receiver", based on dvb-t dongle.

The remote connection:
My NSLU2 has only 2 USB connectors (maybe can extend it?) and I used one for the system software, connected on a usb pendrive. I use the second usb connector to connect the dbv-t dongle for the sdr receiver. Maybe can use another wifi-dongle to build wireless connection to this box, but now I doesnot try it: The small embedded box has its limitation with memory and the cpu power, to serve the high speed data transmission, maybe not the best idea to put top of this to serve the local wireless connection.
Here is, where come up the old idea, to bridgeing the two segments of a local lan  into one with two wireless AP.
I use two Micronet SP918BK modells:
http://members.chello.hu/b.globekom/micronet/

This small, cheap AP-s have the so called AP Bridge Point-to-Point Mode. This mean, based on this configurations, the two AP-s accept data transmission from the pearing device, based on the mutually used/configured MAC addresses.
This two pictures quoted from my old web page:
1. Setup and testing the minimal "segments" of this lan.


2. The configurations details used two cheap Micronet AP-s for this bridgeing.



The basic check of this "extension", it you can access the NSLU2 from a machine, sitting on the directly connected wires segment of the LAN.
In my example:
the router,s IP address: 192.168.1.1
the test (desktop machine) 192.168.1.110
the A participants AP of the bridge: 192.168.1.101
the "remote", B participants AP of the bridge: 192.168.1.100
the NSLU2 box, with rtl-sdr server: participants 192.168.1.77
(in my actual configuration the client is another desktop, running on it ubuntu, its name is ubu10, IP address is 192.168.1.114
The first test to access the remote rtl-sdr server from the first desktop machine:

[root@centos5 ~]# ping 192.168.1.77
PING 192.168.1.77 (192.168.1.77) 56(84) bytes of data.
64 bytes from 192.168.1.77: icmp_seq=1 ttl=64 time=9.28 ms
64 bytes from 192.168.1.77: icmp_seq=2 ttl=64 time=8.93 ms

--- 192.168.1.77 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 8.936/9.109/9.282/0.173 ms

Ok, its working, but it put some small more delay into the connection, comparing to the direct wired access...

In the next stepps I used the previous commands, to start the rtl-sdr server with the tcp version of the utils:

LKGE25945:/home/src# ./rtl_tcp -a 192.168.1.77 -f 433920000 -s 400
listen addr 192.168.1.77:1234
Found 1 device(s).
Found Fitipower FC0013 tuner
Using Terratec NOXON DAB/DAB+ USB dongle (rev 1)
Tuned to 433920000 Hz.
Tuner gain set to 5 dB.
listening...

and I used on ubuntu the same gnuradio blocks, to test the connections, and the receive conditions at the remote dvt-t dongle.

On the picture you can see the two small boxes, working together to serve the remote dvb-t dongle:
One is the Micronet AP, it has its own 2.4 GHz antenna, and connected to the NSLU2 with a small piece of TP network cabel, (with the two black ends at the connectors). This small cabel represents the "remote wired segment" of my LAN. The NSLU2 carries the dvb-t dongle, it has its own antenna too, at the top of a small piece of antenna "boom".



About the performace:

In this moment I dont able to say too much about this: the original, wired setup produced unwaited interrupts in the data transfers, sometimes it dropped the connection. Maybe you can improve this situation, for example to use the Trottle block from the gnuradio block sets...
The wireless segment in the local lan causes another unshure situations, depending of the 2.4 GHz propagations on the local conditions.
Another issues the interferences between the two radio systems: the wireless AP transmit on relative high power, near the sensitive wideband receiver, representing the tuner in the dvb-t dongle.

Here is a short part from the network monitoring between the rtl-sdr server and the gnuradio client, running on desktop: It can be help to calculate the possible transmit speed.

0:05:06.691011 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3400577:3402025, ack 1, win 2896, options [nop,nop,TS val 226695 ecr 121448], length 1448
10:05:06.692587 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3402025:3403473, ack 1, win 2896, options [nop,nop,TS val 226695 ecr 121449], length 1448
10:05:06.692705 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3403473, win 2761, options [nop,nop,TS val 121462 ecr 226695], length 0
10:05:06.694217 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3403473:3404921, ack 1, win 2896, options [nop,nop,TS val 226695 ecr 121449], length 1448
10:05:06.695886 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3404921:3406369, ack 1, win 2896, options [nop,nop,TS val 226696 ecr 121450], length 1448
10:05:06.696200 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3406369, win 2761, options [nop,nop,TS val 121463 ecr 226695], length 0
10:05:06.697674 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3406369:3407817, ack 1, win 2896, options [nop,nop,TS val 226696 ecr 121450], length 1448
10:05:06.697788 IP 192.168.1.77.1234 > ubu10.49839: Flags [P.], seq 3407817:3407873, ack 1, win 2896, options [nop,nop,TS val 226696 ecr 121451], length 56
10:05:06.697864 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3407873, win 2761, options [nop,nop,TS val 121463 ecr 226696], length 0
10:05:06.725398 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3407873:3409321, ack 1, win 2896, options [nop,nop,TS val 226702 ecr 121454], length 1448
10:05:06.761895 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3409321, win 2761, options [nop,nop,TS val 121480 ecr 226702], length 0
10:05:07.158920 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3409321:3410769, ack 1, win 2896, options [nop,nop,TS val 226745 ecr 121454], length 1448
10:05:07.159048 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3410769, win 2761, options [nop,nop,TS val 121579 ecr 226745], length 0
10:05:07.160590 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3410769:3412217, ack 1, win 2896, options [nop,nop,TS val 226745 ecr 121454], length 1448
10:05:07.160637 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3412217, win 2761, options [nop,nop,TS val 121579 ecr 226745], length 0
10:05:07.162232 IP 192.168.1.77.1234 > ubu10.49839: Flags [.], seq 3412217:3413665, ack 1, win 2896, options [nop,nop,TS val 226745 ecr 121454], length 1448
10:05:07.162284 IP ubu10.49839 > 192.168.1.77.1234: Flags [.], ack 3413665, win 2761, options [nop,nop,TS val 121580 ecr 226745], length 0


Modification of the rtl-sdr dongle to the direct sampling receive


Here is the description of this small modification:
http://cgit.osmocom.org/cgit/rtl-sdr/commit/src?h=steve-m/direct_sampling
Steve said, it need to connect a long wire to the 1 or 2 pin of the rtl2832 chip, and can use the modified rtl-sdr tool to tune below 30 MHz.
In my first version of the parctical modification used a 2 pin connector. The first pin I soldered on the back side of the PCB, to the GND point of the covers of USB connector. The second pin is on the top side, and I conected it to the 1.-th pin of the rtl2832, when it connected to the smd capacitor.


After a little modification you can close the original plastic cover again:



Wed Jun  6 10:15:14 CEST 2012
t.janos


Osmocom rtl-sdr running on raspberrypi:

raspberrypi working as an sdr server


This is my first test on raspberrypi with the runing osmocom rtl-sdr utils, specially the rtl_tcp server.
The command, starting the server:

root@raspberrypi:/home/pi/rtlsdr/rtl-sdr/build/src# ./rtl_tcp -a 192.168.1.111 -f 433900000 -g 1

It found the connected rtl-sdr dongle, and start to listening:

Found 1 device(s).
Found Fitipower FC0013 tuner
Using Terratec NOXON DAB/DAB+ USB dongle (rev 1)
Tuned to 433900000 Hz.
Tuner gain set to 1.000000 dB.
listening...

The client runing on the same lan, on the ubuntu, the gnuradio 3.5 version, with a simple receiver block, consistst of a tcp receiver module and a WX GUI Waterfall Sink module.
When start the receiver, the server on raspberry send this message, and start to send the data:

Use the device argument 'rtl_tcp=192.168.1.111:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
client accepted!
ll+, now 1
ll+, now 2
ll+, now 3
ll-, now 0
ll+, now 1
ll-, now 0
....
....
....

But shortly it hung up, with this error messages:

comm recv socket error
Signal caught, exiting!
worker cond timeout
Signal caught, exiting!
all threads dead..
listening...
Use the device argument 'rtl_tcp=192.168.1.111:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).

On the gnuradio waterfall gui we can see the data transfer, but without any received signal.
From this error messages it seems me, it need some network analysis to explore the error sources.
rpirtlsdr.jpg:
On the picture you an see the attached rtl-sdr dongle and the network cabel, to connect to my local network.
Near the SD card there is the usb cabel, power the rpi unit and the dongle.




Thu Jun 21 16:11:42 CEST 2012