Running your LimeSDR on GNSS_SDR on Ubuntu 17.10

[martywittrock]

LimeSDR Users and Members,

Anyone wishing to use their LimeSDR for GPS data collection and then take that data and replay it in the analysis tools for GNSS_SDR or SoftGNSS, all you need to do is the following:

1.) Install LimeSuite and all the MyriadRF drivers as you normally would from the MyriadRF instructions using the PPAs, and that follows:

sudo add-apt-repository -y ppa:myriadrf/drivers
sudo apt-get update
sudo apt-get install limesuite liblimesuite-dev limesuite-udev limesuite-images
sudo apt-get install soapysdr soapysdr-module-lms7

Once you get that done, verify that your LimeSDR is capable of being seen by LimeSuite by doing the following in a Terminal window:

SoapySDRUtil --find

or

LimeUtil --find

And see if your LimeSDR responds. If it does, then follow the directions on the GNSS_SDR site here -----> http://gnss-sdr.org/build-and-install/

…where all you have to do is type (or copy / paste) the following into a Terminal window:

$ sudo apt-get install gnss-sdr

This will install the ENTIRE package for GNSS_SDR and even the gr-osmoSDR drivers necessary to link it up with the LimeSDR.

Once the GNSS_SDR package installs, then find take the example .conf file that appears in the ‘HackRF’ section of the following webpage (toward the bottom) -----> http://gnss-sdr.org/conf/

…and copy/paste the .conf example they have for HackRF into a text file in Ubuntu (using Leafpad, or some other text editor).

Once you do that, you’ll need to change the HackRF arguments to LimeSDR arguments to allow the gr-osmoSDR drivers to connect to the LimeSDR. There is a line in the .conf file that shows the following:

WAS:
;# Next line enables the internal HackRF One bias (3.3 VDC)
SignalSource.osmosdr_args=hackrf,bias=1

CHANGE IT TO…
;# Next line enables the LimeSDR
SignalSource.osmosdr_args=driver=lime,soapy=0

Save the .conf file as limesdr_GPS_L1.conf and put it on your desktop of your Linux Ubuntu installation.

Once you complete that, then all you have to do to torch off your LimeSDR with GNSS_SDR is to type the following on the Terminal window that has been directed to the Desktop (so it can see the .conf file):

$ gnss-sdr --config_file=limesdr_GPS_L1.conf

…Then sit back and relax, because the LimeSDR will be acquired and will start pulling down all the ‘birds’ it can see in the sky (provided you have your LimeSDR attached to a preamplified patch antenna and it’s attached to the RX1_L port of the LimeSDR - - RX1_L was confirmed by member @osqzss).

This is how I got it running…I still need to confirm that the data I’m seeing is good, but the GNSS_SDR program seems to think it’s seeing the GPS satellites fine because it’s actually locking them in and showing data that it’s collecting data from it…So I have to believe that RX1_L is the winner for what antenna port it’s seeing the GPS sats on.

Have fun with this - I’m am…!!

73 de Marty, KN0CK

[osqzss]

Thank you for the instructions. The GNSS-SDR is now running nicely on my Ubuntu 17.10 in VirtualBox.

The only difference is the RX connection. I can only see the GPS signals through the RX1_L port.

Is there any way to select a specific RX antenna port in the osmosdr_args or with the SoapySDRUtil?

I found the following discussion in the discourse, but it didn’t give me a clear answer.

Parameter needed to switch RX input in gnuradio for limesdr

Hi All, doing my fist steps with limesdr i was wonder how to switch rx or tx channel beween RX1, RX2 or TX1, TX2 in the gnuradio soapysdr sink. thanks for helping in advance, br Robert

[martywittrock]

@osqzss,

Thanks for the update on the antenna port - that’s a great find…! I was sure I was getting data correctly on the RX1_H port, but I’ll try the RX1_L port that is optimized for 700 MHz but can perform at GPS frequencies (1575.42 MHz and 1227.6 MHz). Here are the port specs on the LimeSDR:

TX1_1 and TX2_1 optimal performance 30 MHz <-> 1.9 GHz
TX1_2 and TX2_2 optimal performance 2 GHz <-> 2.6 GHz
RX1_L and RX2_L optimal performance 700 MHz <-> 900 MHz
RX1_H and RX2_H optimal performance 2 GHz <-> 2.6 GHz
RX1_W and RX2_W optimal performance 700 MHz <-> 2.6 GHz

GNSS_SDR leans hard on gr-osmoSDR to operate and from the thread you sent that driver does default to RXx_L but apparently there is a second stream that works the RXx_H antenna but it’s a little harder to control (and from the specs wouldn’t be much better since it’s optimized for WiFi). The only hope we’d have is to have RXx_W where it would fall in the sweet spot of its range for GPS, but not controlled natively from gr-osmoSDR and by default set to ‘2’ (zero based) for this antenna list:

RX Antennas: NONE=0, LNAH=1, LNAL=2, LNAW=3

I’ll look into this some more over the next day or two and see if I can make any headway because this will (somewhat) affect receive, but not enough to really cause you to lose everything - it just won’t be too sensitive (when we’re fighting for signal being above the noise floor with 30dB of gain between the patch antenna and Lime). Again, I’ll go have a look in gr-osmoSDR to see if there’s a way to put this in the GNSS_SDR script to select the right antenna - - stay tuned.

73 de Marty, KN0CK

P.S. - I gave you credit/citation on my original post for finding the RX1_L port as the active port for GNSS_SDR, too - thanks again for that.

[martywittrock]

@osqzss,

Okay - I’ve clawed through gr-osmoSDR enough to be dangerous and I’m going to suggest this change to the .conf file as an added attribute that you can modify as follows (the ‘sampling_frequiency’ line is the one to look for…put the antenna selection after it):

SignalSource.sampling_frequency=2000000
SignalSource.ant=3

This should select antenna ‘3’ which should select the Wideband antenna on the LimeSDR. gr-osmoSDR allows for antenna selection, so give it a try and let me know how this goes. I tested the setup that I posted on in a different location and I’m setting up the LimeSDR for GPS here at the house, too. I should have my setup together by tomorrow morning if everything goes right. Again, your observations will be before mine, so let me know if anything blows up or works. If it blows up, just revert back to your prior .conf file and we’ll keep working on it.

Just so you know, for the Lime-Mini there is no antenna port selection other than its default and it’s not ‘2’…So this will even be more important for me to check this on the Lime-Mini with the correct antenna enumeration (which I’m assuming for the Lime-Mini is ‘1’).

73 de Marty, KN0CK

[osqzss]

I’m not able to select the RX port with the SignalSource.ant parameter. RX1_L is still the only active port for GNSS-SDR.

[martywittrock]

@osqzss,

Thanks for checking that out for me in advance. I’ll work this some more and possibly @hahnpv may know the underpinnings of GNSS_SDR and how those system calls are made with hardware. More to follow on this - Stay tuned…

73 de Marty, KN0CK

[hahnpv]

@martywittrock and @osqzss,

Admittedly I only found out from Marty a few days ago that OsmoSDR had Soapy support. I believe this change is fairly recent. gnss-sdr has a light wrapper around gr-osmosdr, code is here:

gnss-sdr/gnss-sdr/blob/master/src/algorithms/signal_source/adapters/osmosdr_signal_source.cc

It does not appear to expose an antenna parameter likely because (excepting USRP, which has its own interface (uhd_signal_source)) there are no radios supported by gr-osmosdr that have multiple antennas. Looks like a code change would be required. I don’t know whether it would be more worthwhile to expose an antenna parameter no one else uses or create a soapy_signal_source.

Takuji: I saw the latest SS-520 successfully achieved orbit. I don’t know if you had a payload on that mission but in either case congratulations! Smallest orbital launcher by far, a nice encouragement to small rocket teams everywhere.

philip

[osqzss]

philip,

OsmoSDR supports setAntenna function of SoapySDR.
http://git.osmocom.org/gr-osmosdr/tree/lib/soapy/soapy_source_c.cc

I simply added the following line to the source and rebuild the GNSS-SDR.

osmosdr_source_->set_antenna(“LNAW”, 0);

It works just fine with any RX1 port name, and I can get rigid position fix status.

[edit]
I added a new configuration parameter for RX antenna selection. You can change the antenna by adding the following line in your .conf file.

SignalSource.antenna=LNAW

All the related source files are available in the “next” branch of the GNSS-SDR repository.

[hahnpv]

Excellent! I would suggest a gnss-sdr pull request so we can have this functionality going forward!

[osqzss]

The changes have been merged into the “next” branch of the GNSS-SDR repository.

Add LimeSDR antenna selection support

[martywittrock]

@osqzss,

THAT’S COOL…!! Thanks for adding that functionality into GNSS_SDR. I did the ‘apt-get install gnss-sdr’ when I did the original installation for it. Can you get the hand puppets out and let me know how to install your branch of GNSS_SDR? I would like to do that so I can check it out at the house tonight (once I get done plowing snow… :-/). Please do keep me advised on this at your soonest.

EDIT: I’m also assuming that the .conf file on github should be used, too, for this new change, right? Please let me know on that, too.

73 de Marty, KN0CK

[osqzss]

Marty,

In order to get access to this functionality, you need to build the GNSS-SDR from source in the “next” branch. GNSS-SDR team provides very complete instructions on their website.

Build and install GNSS-SDR

Before building the GNSS-SDR with SoapySDR support, you might need to install the Pothos framework and toolkits.

pothosware/PothosCore

Once you have SoapySDR support drivers for OsmoSDR on your machine, install all the dependencies required to build the GNSS-SDR.

$ sudo apt-get install build-essential cmake git libboost-dev \
   libboost-date-time-dev libboost-system-dev libboost-filesystem-dev \
   libboost-thread-dev libboost-chrono-dev libboost-serialization-dev \
   libboost-program-options-dev libboost-test-dev liblog4cpp5-dev \
   libuhd-dev gnuradio-dev gr-osmosdr libblas-dev liblapack-dev \
   libarmadillo-dev libgflags-dev libgoogle-glog-dev \
   libgnutls-openssl-dev libgtest-dev libmatio-dev \
   python-mako python-six

Then clone the repository, build the source code in the “next” branch with the ENABLE_OSMOSDR option.

$ git clone https://github.com/gnss-sdr/gnss-sdr
$ cd gnss-sdr/build
$ git checkout next
$ cmake -DENABLE_OSMOSDR=ON ..
$ make
$ sudo make install

You can find a sample configuration file with the antenna selection feature in the conf directory.

gnss-sdr/gnss-sdr/blob/next/conf/gnss-sdr_GPS_L1_LimeSDR.conf

[martywittrock]

@osqzss,

MAGNIFICENT…!! THANK YOU SO MUCH for getting this ALL together as a neat bundle for the LimeSDR. I’ll set out tonight to put this all together and test it out on a LimeSDR and then a Lime-Mini and report back. I’m energized about getting this together because this application for the Lime-Mini will certainly augment well with all the other development projects going on with it, too.

More to follow as I have this built up, but I can’t thank you enough for pushing forward with the antenna selections for the LimeSDR to make GNSS_SDR even better than before with the Lime.

73 de Marty, KN0CK

[martywittrock]

@osqzss,

Couple of questions regarding your observations of GNSS_SDR running with the Lime…When yours is running looking at satellites with a patch antenna on your setup and with LNA_W, I see that GNSS_SDR initially sets up the gains (at least what I’m seeing) as follows:

PGA = 31
LNA = 15
TIA = 2

Then the satellites will start with a lock on whatever channel and with a ‘IIF Block’, let’s say it’s Channel 6, and it’ll be good for about 2 or 3 seconds and then I’ll see a ‘Loss of Lock’ on the same channel. This happens a lot during the time GNSS_SDR is running. I checked the validity of the LNA_L port (since I’m not on the new build yet) and with SDRConsole running at 1574.42 MHz and with a acceptable patch antenna (and bias-tee) I’m seeing GPS signal activity, but when I switch to Linux and run GNSS_SDR it’ll lock the channel in fine for a few seconds and then have a loss of lock for the same channel.

What’s your observations of this and do I need a 10 MHz reference input on my LimeSDR or what do you think I’m seeing over here that needs corrective action?

I’m still doing this on the ‘Traditional LimeSDR’ and haven’t quite gone to the Mini yet. I want to iron out the bugs in my setup before I start with the Lime-Mini next.

Let me know - I’m interested in knowing if this is a setup issue or some other anomaly.

73 de Marty, KN0CK

[osqzss]

Marty,

I’m using a typical GPS patch antenna with LNA. You need a bias-tee to feed the antenna, but no external reference is required. The on-board clock is good enough for GPS signal reception.

If you have another LimeSDR, try LimeGPS as a signal source and directly feed the signal to the other LimeSDR running GNSS-SDR.

GitHub - osqzss/LimeGPS: Real-time GPS signal simulator for LimeSDR

You need 50-60dB attenuation to emulate the GPS signal power level received on the ground.

[martywittrock]

@osqzss,

MANY THANKS for the update and the additional tool in the LimeGPS - that will definitely help. I’ve decided to also obtain a 34dB amplifier/filter (for GPS) for my (already) preamplified patch antenna - so I should have plenty of gain between the antenna and preamp to see most anything skyward. But I will try out the transmitter, too, to see if I can emulate the ‘birds’ for troubleshooting purposes until my preamp arrives tomorrow (thank God for Amazon).

Not to repeat a question, but when you’re looking at the GNSS_SDR messages in terminal, are you seeing any instances of a channel unlock at all when your setup is running? If you can copy/paste about 5 seconds (or more would be appreciated) of the screen activity in the any portion after the initial setup that would be greatly appreciated so I can see what ‘normal’ activity looks like. My LimeSDR is currently not optimal since I’m still running on the RX1_L antenna port - - but that will all change this evening when I compile the branch you have on Github.

I’m wondering if the LimeGPS program that you attached can work with the Beta Lime (V1.2). Can you advise if this can work with the V1.2 Limes and (certainly) can work with the V1.4 LimeSDR?

Please let me know on the above if you can - it’ll really help with some of my troubleshooting, too. Many thanks in advance for the info - I greatly appreciate the help…!!

73 de Marty, KN0CK

[osqzss]

Marty,

I’ve uploaded the log files of the GNSS-SDR messages to my Google drive:
https://drive.google.com/drive/folders/1lOyI6btIOxsV2Tn-krzCOHANzNOGj4-_?usp=sharing

Since the view of sky from my room is very limited, I used my LimeGPS simulator to feed the other LimeSDR running the GNSS-SDR to capture the log_LNAL.txt messages. The signal was fed to the receiver through the LNAL antenna port.

I could duplicate your symptoms when running the GNSS-SDR with no signal input. You can find the GNSS-SDR messages during the test in the log_no_signal.txt file.

I have a couple of v1.4 LimeSDR boards but no beta version. I guess the LimeGPS simulator should work if the Beta Lime is supported by LimeSuite.

[martywittrock]

@osqzss,

Again, MANY THANKS for putting those log files up there so I could review them - that did help A LOT. From what I can see I’m not getting enough signal to activate GNSS-SDR to lock on channels and resolve any position reports. So I’m going to have to play with that on my setup, but I’ll also play with the LimeGPS transmit to see how that works on my setup, too. But the log files helped immensely - thanks for doing that for me.

At this time I’m using your recipe for installing GNSS-SDR and the LimeGPS transmit - compiling GNSS-SDR as I type this.

More to follow as I have it - MANY thanks again, and stay tuned…

73 de Marty, KN0CK

[martywittrock]

@osqzss,

I tried building the LimeGPS transmit app to what your directions mention from Github but I wasn’t sure if it compiled at all. Do you have a build procedure on this you can share with me. Unzipping (or cloning) the subdirectory and doing a make didn’t seem to produce anything. Not sure what I’m doing wrong on this, and it’s compiling in Ubuntu (Artful). I’d like to make the LimeGPS to simulate to my receive setup before I apply the preamp and patch antenna for real GPS receive with the LimeSDR and the Lime Mini. I’m using ‘sudo LimeGPS’ as the means to start the application - is the syntax not right? Please advise on that.

Let me know if there’s anything further than just a ‘make’ for this - thanks VERY much in advance for your help with this, @osqzss

73 de Marty, KN0CK

[osqzss]

Marty,

If the ‘make’ command doesn’t work, type the following line directly in the terminal.

$ gcc -O2 -Wall -o LimeGPS limegps.c gpssim.c -lm -lpthread -lLimeSuite

This should create ‘LimeGPS’ executable.

In order to run the software, you need at least to specify a GPS broadcast ephemeris file. Try the following command to run the LimeGPS.

$ ./LimeGPS -e brdc0350.18n

You can observe the emulated GPS RF signal on the TX1_1 port.