Hi,
I have two machines running Linux with individual LimeSDRs. One is connected to the Internet, and the other isn’t. My goal is to be able to have the internet-less computer be able to connect to the internet through the other computer’s connection by sending TCP/IP data through the Limes. I know that TCP/IP over radio isn’t a new concept, but I can’t seem to find anything for the Lime. Has anyone had experience doing this or have pointers on where I could go?
Thanks!
Yes, it’s possible, and you can see how it can be done here: https://www.gnuradio.org/wp-content/uploads/2017/12/Dan-CaJacob-Building-a-Moderately-Complex-Modem-with-Spare-Parts.pdf
QRadioLink (http://qradiolink.org) contains a simple IP data modem, which allows any type of IP traffic to pass between radios (whether it’s TCP or UDP or something else). The modem transfers data at 250 kbit/s but the rate is effectively reduced by the IP overhead. The encapsulation is very basic though. You need to grant netadmin privileges to the application, and instructions can be found in docs/CONFIGURE file (setcap “cap_net_raw,cap_net_admin+eip” ./qradiolink).
The modem needs to operate in full duplex mode, so you need a different frequency for transmission and reception, called split (in kHz). The spacing between the frequencies has to be large enough for the TX not to desense the RX. For example, negative split of -10 MHz on one side, and positive split of +10 MHz on the other, with the main frequency tuned to the RX channel.
Regards,
Adrian
I’m not exactly sure what your end goal is, knowledge or utility, but if it is to have a long distance link to a remote computer. A cheaper, faster, less complex, lower power solution would be to use two satellite dishes pointing directly at each other and angled so that they are pointing at the ground, which does look a bit odd. But when you think about it, normally they are picking up satellites high above and are pointing horizontally, which is odd as well. But they are designed that way so that snow and leaves do not build up inside the dish which would happen if they were designed to point directly up. And then use two WiFi routers, and put their antennas where the LNB would normally go (possibly with a RP-SMA pigtail) . Just make sure that you are under your countries legal maximum allowed transmission power (EIRP) limits, e.g. For 802.11a on channels 149, 153, 157, 161 in the US that would have a maximum EIRP of 4000mW (+36dBm), but for 802.11a on channels 36, 40, 44, 48 only 200mW (+23dBm) again in the US. The limits are different from country to country, you would need to look up whatever laws apply where you are, and if you are over the legal limit, use an inline attenuator on each to bring your signal level to the legal limit.
EDIT: I should probably add that one of the routers will need to be configured as a “Wireless Bridge” (plug the term into your search engine of choice)
I’ve successfully built qradiolink and am running it as root, but can’t figure out how to use it for any tx-rx communications. To get more comfortable with the software, I had one instance running in RX mode and the other sending a file in TX mode (both using QPSK 2K). I can see the file being sent in the constellation plot, but the RX instance doesn’t seem to decode the data. I also don’t see anywhere to forward IP data and the software doesn’t open up a tunnel interface or anything so I’m really not sure how to go about this. There doesn’t appear to be any examples or documentation on how to use the software.
I just cloned Dan CaJacob’s code for the video you posted as well and will try to get that working.
The TCP/IP mode is the last option (QPSK 250K), and you need to enable it by doing the step described above. You should see a new tun/tap net interface once it is started. For QPSK 2K, if the constellation looks good but it does not decode, it is probably locked to a different phase, and if you fine tune around using the dial in the Tune page you will eventually get it to work. I’d recommend using the BPSK 2K or QPSK 10K modes since they are easier to tune correctly.
So this is what I have right now. The tun/tap interface has been opened on each device - I have one side set to 430 MHz with a +10 split, and the other side set to 440 MHz with a -10 split. I have the IPs set to 10.0.0.1 and 10.0.0.2. I’m sniffing both interfaces with wireshark and pinging the other host but it’s not being picked up.
Am I getting the tuning wrong? I thought that this is what a QPSK constellation plot should look like but I am just learning all of this so there’s a good chance I’m mistaken.
Judging by the quality of the constellation, signal levels appear to be a bit low. You want tighter dot grouping. This QPSK mode does not use any forward error correction, so try to increase TX gain a little.
Why it does not work? I think you are tuned at least on one window to the wrong phase difference (above or below the center of the signal). There is a blue light in the lower left corner which should come on when the modems are synchronized. So keep fine tuning around until the blue light comes on on both windows. After that you should see IP data packets flowing.
Thanks @adim . I did get QRadio working but ended up wanting to make a few modifications so I decided to try Dan CaJacob’s TCP/IP modem in GRC. However, I can’t seem to get it working properly.
The flowgraph is:
TX: TUN-interface --> IP encapsulator --> CCSDS encoder --> FEC extended Encoder --> QPSK modulator --> idle frame inserter --> Lime
RX: Lime --> RMS AGC --> FLL --> Polyphase Clock Sync --> CMA Equalizer --> Costas Loop --> --> Correlation Estimator --> Costas Loop --> Constellation soft decoder --> FEC Extended Decoder --> CCSDS Decoder --> IP decapsulator --> TUN-interface
When I replace the Limes with a channel model, everything works as expected and I can send data… the output looks like so (top right is what’s being transmitted, bottom left is received, bottom right is recovered constellation - ignore top left). This works consistently until noise voltage level reaches about .3.
However, when actually using the Limes (a few feet apart) to transmit, I get far different results. The received constellation somewhat resembles what is supposedly being transmitted, but it’s incredibly noisy and also spins around/pulses as if the phase and power level are constantly changing. I have to be within a foot for the signal to lock at all and even then it is not reliable (80% packet drop rate).
Anyone have an idea of what could be going wrong here? Is this most likely a problem with outside interference? The Lime itself? My flowgraph?
Ok, good to hear that. Out of curiosity, what did you want to modify? If it’s a new feature, I’d be interested, so you can submit a pull request any time.
As a note, meanwhile I have changed a few things in the modem. First, I investigated why the constellation was so noisy and found that the AGC was too agressive and distorted the signal, which I’ve now fixed. Also, I added convolutional encoding with Viterbi soft symbol decoding, dropping the power level needed by 3 dB with a code rate of 1/2. Changes are released in version 0.5.0
Regards,
Adrian
FYI, this is how the DQPSK constellation should look like now:
at 30 dB CNR:
And at 13 dB CNR (this is where the FEC starts working, notice the degraded SNR)
Eh it’s not so much a feature as a different application. The specific use case requires being able to play around with different error-correcting/scrambling techniques and also to be run completely from a command line eventually.
Also the reason for the buggy transmission posted above was simply interference from the Lime. I have both Limes inside of 3D-printed enclosures and one of the wires was touching a circuit component… moving the wire solved the issue. I don’t know how I didn’t see that happening before haha.
The changes look nice!! I’ll definitely try it out once I have some extra time.
Hey Rleh did you ever get back to getting everything working? I’m trying to accomplish the exact same task of TCP/IP using 2 Lime SDRs and was wondering if you had any pictures of your setup or any remaining debugging info that I could gleam?