I have a couple of ideas in mind that involve connecting an ADALM-Pluto SDR to a phone or tablet. Usually, the Pluto is connected to a PC through USB, and the Pluto acts as an Ethernet device, so that network communications between the PC and Pluto are possible. I want to have the same thing running with my Android phone, which is an unrooted Xiaomi Mi 11 Lite (model M2101K9AG, if anyone is curious).
As usual when trying to do something slightly advanced with Android, this hasn’t worked on the first go, so I’ve spent some time debugging the problem. Long story short, in the end, the only thing I need to make this work is to run
on the Pluto once and reboot (these settings are saved as uBoot environment variables to persistent storage), then enable Ethernet tethering on the phone every time that I connect the Pluto. I can go to the web browser in the phone and check that I can access the Pluto web server at 192.168.89.1.
Hopefully the rest of this post will give useful information about how everything works behind the scenes, as your mileage may vary with other Android devices (or if you try with an iOS device, of which I know next to nothing).
I haven’t seen many people doing this, so the documentation is scarce. PABR did a set up with LeanTRX, the Pluto and an Android phone, but they were running the Pluto in host mode and the Android phone in device mode, and I’m doing the opposite. Note that when you connect a Pluto and phone together, the roles they take will depend on the USB cable. My phone has USB-C, so I’m using a USB-C plug to type-A receptacle cable (USB-C OTG cable) together with the usual USB type-A plug to USB micro-B plug cable (the cable provided with the Pluto). There is also this thread in the ADI forums, but it doesn’t really say anything about Ethernet over USB.
A frequency error of a couple of Hz is typical when working with SDRs unless special care is taken. Many SDRs allow choosing the sample rate and centre frequency with great flexibility, but the drawback is that the frequencies that are achieved are often not exactly the ones we indicated. Fractional-N synthesis PLLs are used to generate the sampling clock and local oscillator, so there are small rounding errors in the generated frequencies.
With enough knowledge of how the SDR hardware works and how it is configured, it is possible to determine these frequency errors exactly, as a rational number \(p/q\) that we can calculate explicitly, multiplied by the reference frequency of the SDR. Then we can use this exact value to correct our measurements.
I have asked Mario Lorenz DL5MLO and Kurt Moraw DJ0ABR the details of how the beacons are generated in the Bochum groundstation. Two ADALM Pluto‘s are used: one generates the CW and BPSK beacons, and the other generates the 8APSK multimedia beacon. With the data they have given me, I have been able to compute the frequency separation of the 8APSK and BPSK beacons exactly, and the result matches well my experimental observations.
In this post we will look at how the fractional-N synthesis calculations for the Pluto can be done. Since the Pluto uses an AD9363 RFIC, these calculations are applicable to any product using one of the chips from the AD936x family, and to the FMCOMMS3 evaluation board.
Before starting the measurements with QO-100, I have taken the time to use the Vectron GPSDO to measure the Allan deviation of my DF9NP GPSDO over several days. This post is an account of the methods and results.
A while ago I spoke about feeding an external reference to the LimeSDR USB. Now I wanted to use an external reference with the LimeSDR Mini that I have in my QO-100 groundstation to lock all the system to GPS. Preferably I wanted to use 27MHz as the reference, since this is what I am using in my LNB, so this would save me from having to run 10MHz or another frequency to the groundstation.
I wasn’t so sure how well this would work, since there are a few threads with questions in the MiriadRF forums, but I haven’t seen any explaining things in a clear way. There are different anecdotes of things that worked or didn’t work for several people, but not that many definitive answers. Among all the threads, this one seems mostly helpful.
Somewhat surprisingly, everything has worked well on the first try. I am now using a 27MHz external reference with my LimeSDR Mini. Hopefully this post will be of help to other people.
Here I want to show a technique for measuring the gain of a dish that I first learned from an article by Christian Monstein about the Moon’s temperature at a wavelength of 2.77cm. The technique only uses power measurements from an observation of a radio source, at different angles from the boresight. Ideally, the radio source should be strong and point-like. It is also important that the angles at which the power measurements are made are known with good accuracy. This can be achieved either with a good rotator or by letting an astronomical object drift by on a dish that is left stationary.
A couple weeks ago, I did a demo where I showed the LimeRFE radio frequency frontend being used as an HF power amplifier to transmit WSPR in the 10m band. Another demo I wanted to do was to show the LimeNET Micro and LimeRFE as a standalone 2.4GHz transmitter for the QO-100 Amateur radio geostationary satellite.
The LimeNET Micro can be best described as a LimeSDR plus Raspberry Pi, so it can be used as an autonomous transceiver or remotely through an Ethernet network. The LimeRFE has a power amplifier for 2.4GHz. According to the specs, it gives a power of 31dBm, or a bit over 1W. This should be enough to work QO-100 with a typical antenna.
You may have seen the field report article about the QO-100 groundstation I have in my garden. It is based around a LimeSDR Mini and BeagleBone Black single board ARM computer. The groundstation includes a driver amplifier that boosts the LimeSDR to 100mW, and a large power amplifier that gives up to 100W. The LimeSDR Mini and BeagleBone Black give a very similar functionality to the LimeNET Micro, but the LimeNET Micro CPU is more powerful.
The idea for this demo is to replace my QO-100 groundstation by the LimeNET Micro and LimeRFE, maintaining only the antenna, which is a 24dBi WiFi grid parabola, and show how this hardware can be used as a QO-100 groundstation.
The LimeRFE is intended to work as an RF frontend for the LimeSDR family, although it can work coupled with any other SDR or conventional radio. As such, it has power amplifiers, filters and LNAs designed to cover the huge frequency range of these SDRs. It is designed to cover all the Amateur radio bands from HF up to 9cm, and a few cellular bands.
As anyone will know, designing broadband RF hardware is often quite difficult or expensive (Amateur radio amplifiers and LNAs are usually designed for a single band), so packing all this into a single unit is a considerable feat. The output power on most bands is around a couple watts, which is already enough for many experiments and applications. The block diagram of the LimeRFE can be seen below.
In this post I show a brief overview of the LimeRFE and demonstrate its HF transmission capabilities by showing a WSPR transmitter in the 10m band, using a LimeSDR as the transmitter.
Some days ago, Guillaume F4HDK emailed me to introduce me his latest project, NPR (New Packet Radio). This is an open-source modem designed to carry IP traffic over the 70cm Amateur radio band, with data rates of up to 500kbps. The goal of this modem is to be used for the Hamnet Amateur radio IP network, to give access to end users where coverage on the 2.3GHz and 5GHz bands is poor due to the terrain.
Guillaume knew that I had worked on IP over 70cm with my CC1101 and Beaglebone black project, so he wanted to know what I though about NPR. After reading all the available documentation, I found NPR very interesting. Indeed, Guillaume has come up with clever ways of solving some of the difficulties I foresaw when planning out my experiments with the CC1101.
The most important aspect about NPR is that it is already a finished product that people can build as a kit and start using. My experiments with the CC1101 were a mixture of proof of concept and play around, and never progressed from that stage due to lack of interest in my local Amateur community. However, Guillaume has put a lot of time, thought and effort in developing NPR. Of course the project can evolve further, but it is usable in its present stage. In what follows, I do a detailed analysis of the technical aspects of NPR.
I have replaced the dish I had for receiving Es’hail 2 by a new one. The former dish was a 95cm offset from diesl.es which was a few years old. I had previously used this dish for portable experiments, and it had been lying on an open balcony for many months until I finally installed it in my garden, so it wasn’t in very good shape.
Comparing with other stations in Spain, I received less transponder noise from the narrowband transponder of QO-100 than other stations. Doing some tests, I found out that the dish was off focus. I could get an improvement of 4dB or so by placing the LNB a bit farther from the dish. This was probably caused by a few hits that the dish got while using it portable. Rather than trying to fix this by modifying the arm (as the LNB couldn’t be held in this position), I decided to buy a new dish.