RTL Bridge Gets an Update

RTL Bridge is a free Windows application that connects an RTL radio receiver dongle to Radio-SkyPipe and Radio-Sky Spectrograph data collection programs. You can read about it in the earlier post here.  I have been trying to make RTL Bridge a little easier to use by making it possible to update some of the receiver options on the fly, that is, without restarting the rtl_tcp.exe with new command line parameters.

In this version you need to stick with 128 or 256 as the FFT Size.  512 is causing an error.  You will see two new check boxes labeled RTL AGC and Tuner AGC.  Leave these unchecked for astronomical measurements. 

I had hoped to have spectrum stacking ability by now but it is harder than I thought, obviously.  Stacking would allow spectra wider than 2.4 MHz. 

If you just want the update go here, but if you are trying to write an application that works with rtl_tcp.exe (like I did) then you may be interested in how to send commands to it.

The Osmocom application, rtl_tcp.exe, actually handles all of the direct communications with the RTL receiver. Rtl_tcp.exe streams data over a TCP connection to RTL Bridge, but it can also receive commands that it then translates and passes on to the radio receiver to set the frequency, gain, sample rate, and other parameters.  The source code for rtl_tcp.exe can be found here.  Below is a copy of the first few lines of the code section that interprets the commands it receives from a client (RTL Bridge, SDR#, etc.) connected via TCP. 

switch(cmd.cmd) {

case 0x01:

// if the command byte is 01 then the parameter is the new frequency // send that to the appropriate routine to set the frequency of the receiver printf("set freq %d\n", ntohl(cmd.param));

rtlsdr_set_center_freq(dev,ntohl(cmd.param));

break;

case 0x02:

printf("set sample rate %d\n", ntohl(cmd.param));

rtlsdr_set_sample_rate(dev, ntohl(cmd.param));

break;

case 0x03:

printf("set gain mode %d\n", ntohl(cmd.param));

rtlsdr_set_tuner_gain_mode(dev, ntohl(cmd.param));

break;

case 0x04:

printf("set gain %d\n", ntohl(cmd.param));

rtlsdr_set_tuner_gain(dev, ntohl(cmd.param));

break;

case 0x05:

printf("set freq correction %d\n", ntohl(cmd.param));

rtlsdr_set_freq_correction(dev, ntohl(cmd.param));

break;

The command consists of a single byte with the command number (above represented by the case statements) and 4 bytes that represents any value associated with the command, a long integer.  This can hold the frequency, sample rate, etc. In RTL Bridge, I use the following VB6 code to send a command to rtl_tcp.exe : Dim FH as string Dim buf(4) as byte   FH = Hex$(RTL_Frequency)     While Len(FH) < 8         FH = "0" + FH     Wend     buf(1) = Val("&H" + Left$(FH, 2))     buf(2) = Val("&H" + Mid$(FH, 3, 2))     buf(3) = Val("&H" + Mid$(FH, 5, 2))     buf(4) = Val("&H" + Mid$(FH, 7, 2))     buf(0) = 1 ' This is the command byte - command 1 sets the frequency.     Socket1.WriteBytes buf, 5

(The last statement relies on SocketWrench control from Catalyst software.) Of course there are other ways to do this, but this is not a routine that is time critical so it is OK to use string parsing and the HEX$ function.  I did it this way because it made it easy to manipulate the byte order sent to rtl_tcp.exe.  From this you should be able to deduce a way to send the command.

Arduino to Radio-SkyPipe via Ethernet

Recently, I received an email from someone wanting to put Radio-SkyPipe (RSP) on a Raspberry Pi or some other microcontroller based platform.  He wanted a low power consumption system for a remote location.  I also have an off-grid location that I also would like to access remotely.  A microwave Internet link is available but I do not want to run a remote computer full time as it would severely tax the small solar panel system.  Maybe this will help both of us.

Some time ago I developed a connection to Radio-SkyPipe to an Arduino controller via a serial connection.  By placing enough "intelligence" in the Arduino to communicate directly with RSP using the UDS protocol, we eliminate the complexity of having a specially written UDS "driver" program that sits between RSP and the data collection device (the analog to digital converter on the Arduino).  If you haven't read that post please do.  It will make this post seem much more intelligible. Of course, the range of the serial connection is limited unless we use a modem (remember those?)  Fortunately, Arduino Unos support an Ethernet shield which can then be connected to a LAN or WAN.

Image of the official Ethernet shield taken from the arduino.cc website.

The official Arduino Ethernet shield costs about $38.  I advise that you buy an official board as I have heard stories of incompatibilities with some of the cheaper knock-offs. There is also a WiFi shield that can be purchased for Arduino but I do not have one to test.  I assume operation would be similar to the Ethernet shield.  For my purpose, I have a router at the remote location and can just plug into that directly. A SD card slot is available on the Ethernet shield and it could be very handy for storing data locally in case there is a network failure.  A 4 Gig SD card could handle more than 10 years worth of data from one channel at 10 samples/second.  The code I am passing on to you right now doesn't store the data locally, but perhaps I can add that feature in a future post.

You must include the Libraries needed by the Ethernet shield; SPI and Ethernet.


You must apply the right settings to your Ethernet shield.  There should be a sticker on the board that holds the MAC number for the chip.  You will need that.  You will also need the IP address that you want the board to use.  The gateway and subnet mask can be retrieved from your router. The docs say they are optional but I included them.

byte mac[] = {
  0x90, 0xA2, 0xDA, 0x0D, 0xFB, 0x03 };
IPAddress ip(192,168,1,60);
IPAddress gateway(192,168,1,1);
IPAddress subnet(255, 255, 255, 0);

// the default UDS port = 1377
EthernetServer server(1377);
Initialize the Ethernet device in your setup {  } routine
  Ethernet.begin(mac, ip, gateway, subnet);
  // start listening for clients
 
It was a simple matter to change the original serial code to the Ethernet version by replacing Serial.print() and similar statements with client.print().

I did have to move the workings of the old data fetch and send routine GETD() to within the main loop so the client object would be in scope to send the data back to RSP. So when you see two identical blocks of code it is because I could not keep them as a separate subroutine, probably because I am new to this.  It makes me feel like a baaaad programmer.

At first I had a problem getting RSP to re-connect to the Arduino after I had canceled a connection. It was necessary to add the following lines to break the connection from the Ethernet boards perspective.

     if (!client.connected()) {
        //Serial.println();
        //Serial.println("disconnecting.");
        client.stop();
      }

Note there are //Serial.print() statements peppered through the code.  These can be uncommented if you want to use them for debugging. Just uncomment the appropriate lines, and use the Arduino IDE Serial Monitor to get feedback as you work on your program.

 Of course, you will change the analog data read to whatever you want to record. This is just a bare bones program. You could add DHCP, additional channels, a local clock for timestamping data saved to SD card. A Telnet or Web Server interface could allow you log in and turn things off and on at the remote site. There are already libraries and example code out there to piece together a lot of functionality using not too much electrical power.  Let me know what you come up with.

Get the sketch here.




Obligatory 2D etch-a-sketch using a pot.

Fear of Failure in Amateur Science

We all get things wrong.  Let's skip the nearly endless list of reasons why, and just accept it at the outset.  Of course, we usually have no problem accepting that another person has made an error.  It is mostly ourselves that we struggle with.  We don't want to fail or have others see us as failures so we shield ourselves from these things by:

• Never doing anything with a possibility of failure...or
• Adopting an unwarranted sense of infallibility.

Of course, most amateur scientists love learning new stuff even at the price of being wrong about what they thought they knew.  Isn't that the rush we all look for, that tingle of discovery? Surely, most everyone into science understands that sensation. We all know that science is the endless process of finding out we were wrong or at least more ignorant than we had thought ourselves to be.

Sadly, this high rate of idea turnover, does not play too well in our fragile hominid psyches.  We also like certainty, and we especially like it if it is our own idea that we are certain about. So what's the problem?  If we get it wrong, we just switch on Turbo-Intelligence and leave our simian insecurities behind. Unfortunately, intelligence most often comes with a great deal of rationalizing ability. Turbo-intelligence is just that much worse.  It is much easier to come up with things to support your hypothesis than those that would unequivocally refute it.  (Note the different standards we require of each!)

When defending your position becomes more important to you than your love for truth, you have become not a scientist but rather a politician in a lab coat.  As hard as we try not to, we tend to make this mistake over and over again in our lives, and more to the point, in science.  As amateur scientists, we are more likely to lose our balance in this regard than a professional scientist who has endured years of scrutiny under the eagle eyes of their peers. But, even professional scientists succumb.  They can rationalize VERY well.

We can fight the problems arising from our very human fear of failure by being good citizen scientists, with an emphasis in 'citizen'. We should foster a climate in our science communities that encourages amateurs to share their efforts via the internet in Groups, personal, and community websites. Hiding away in a basement laboratory with no contact with other amateur scientists is one certain way to make sure our efforts will never be criticized.  It is also a way to almost ensure that our work will not be of the quality that it could be had we shared it with others. So come out and smell the formaldehyde.   We can tell each other we are wrong (or right!) in supportive and kind ways.  We must not tolerate harshness or rudeness by others in our groups. Arrogance of any type is the enemy of science.

Humbly Submitted!
JS

RTL Meets Radio-SkyPipe and RS Spectrograph

Eureka... sort of. 

I have written an application that allows you to use inexpensive RTL dongle radios to feed my strip chart program, Radio-SkyPipe (RSP), and my Radio-Sky Spectrograph (RSS), with wideband data.  The program is called RTL Bridge.  I have never claimed to be an imaginative program namer. It works like this:

 

I consider this experimental as of now, and invite others to test RTL Bridge with RSS and RSP.  If you think you want to try it read the help file here. You will need to install RSS if you have not done so and if you already have it installed, you will need the new update.  It is all in that help file. RSS is free by the way.  This could be the start of a nice hydrogen line study for very little money.