My “all in one” APRS digipeater on Raspberry Hat

After extensively testing the Vp-Digi on my solar-powered APRS digipeater, I developed a self-contained solution for implementing an APRS digipeater that combines the outstanding performance of this STM32-based node with the compactness of a VHF RTX module like the SA818V.
The SA818 is a low-cost and high-performance integrated walkie-talkie module with a built-in high-performance microcontroller, narrow-band RF transceiver, and a standard UART interface at 3.3V, making it perfectly compatible with the Raspberry Pi’s native UART.
The output power is unfortunately quite low, just 1 watt, but sufficient for applications where the station is a “fill-in” digipeater that is listened to by igates in very favorable positions.
The module also features a non-volatile memory that allows you to store all your settings and retrieve them each time you power it on.
The Raspberry Pi, however, has only one serial port, which must therefore be used, via user-adjustable jumpers, both for initial programming of the RTX module and for interfacing to the BluePill running VP-DIGI.
In addition to the external BluePill circuitry already mentioned in the VP-DIGI project, which includes filters and audio input and output matching, a harmonic filter is also required on the SA818 output to meet spurious emissions regulations.
After some research, I replicated the filter from this project: https://sites.google.com/site/kamhien2017
BTW, many thanks to Suryo, who designed the filter, for the support during construction and optimizations.

The interesting feature of this project is the double use of the board. It can be used in conjunction with the raspberry, or in stand-alone. In the first case, direwolf, aprx, or similar softwares can be used to implement an igate, if the RPI is connected to the internet. In the second case, a digipeater can be easily done. Only a USB power connection is needed.

Moreover, the board can act as kiss modem, and in this case the kiss port is the USB of the bluepill.

At the beginning of the project, I intended to fit all the components within the Raspberry Pi’s footprint, but then I decided to enlarge the board and work more comfortably. It’s probably possible to fit everything on a double-sided PCB the same size as the RPI, but the routing is a bit laborious and requires the use of very small SMD components and several via holes to connect from one side to the other.
For a first prototype, I decided to work with PTH components and a PCB that’s about twice the size of the RPI.
The PCB can be connected to the RPI via the classic 2×20 connector and spacers aligned with the holes at the corners of the RPI.

Here below, some 3D pictures of Kicad:

Some picture of the board are reported here:

The schematic is very simple and can be found below:

raspy_hatDownload

The blue pill can be connected to the main board by mean of two 20pin socket strips.

All the material can be easily found on ebay or Aliexpress. The total cost is about 25€.

For tuning purposes, I placed a sloder-jumper at the filter input, together with a miniature RF socket (IPEX). During the tuning, a solder joint can be made in order to connect the input filter to the port of a VNA. After the tuning, the joint can be moved to the output of the SA818.

The filter worked perfectly at first attempt, without any tuning. Here below, the S21 can be seen.

The attenuation of the 2nd harmonic is about 41dB, and the in-band attenuation is about -0,6dB, which is very good.

A jumper can be used to switch between High and Low power of the SA818. Another jumper is used to activate the digipeater mode, as already implemented in the schematic diagram of Vp-Digi.

Two Jumpers are placed on the TXD and RXD lines of the Raspy. Putting the jumper between pin 1 and pin 2 of the strips, the Raspy Uart will be connected to the SA818 UART, for the first programming.

Once the programming is finished, the jumpers can be moved between pin 2 and pin 3 in order to connect the Raspy Uart to the VP-Digi Uart, allowing the creation of a Serial Kiss port that can be used by all the most popular APRS Softwars.

The SA818 can be easily programmed using Raspberry console and this nice command tool: https://github.com/0x9900/SA818

Before install this nice application, python3 must be installed on the raspberry:

sudo apt install python3-pip -y
sudo pip install sa818

The embedded UART of the Raspberry must be enabled:

sudo raspi-config

navigate to Interface Options > Serial port select “No” for login shell over serial, then “Yes” at the end for enabling, then reboot to apply the modifications.

Alternatively, add:

enable_uart=1

to the /boot/config.txt file (or /boot/firmware/config.txt for newer OS).

If everything is OK, if you connect the hat to the raspy and type:

sa818 --port /dev/ttyS0 radio --frequency 144.800 --squelch 0 --bw 0
sa818 --port /dev/ttyS0 volume --level 8 

you will set the SA818 to work properly in conjunction with the VP-Digi, and you should get this answer from the application:

I measured the output power of the SA818 and is very close to 1W declared on the datasheet. In Low power mode, it’s about …

Here below, the measurement made with my TinySA and a 30db attenuator.

Low power, is about -25dBm:

High power is about 30,4dBm:

Here below, the measurement made on the 2nd harmonic shows about -55dBc attenuation referred to the carrier:

After the success of the filter, I experienced a problem in the audio part. Unfortuntately, I didn’t noticed that the maximum audio level of the SA818 is too low for correctly driving the Analog Input of the STM32 microcontroller.

In fact, the max out of the SA818 reported on the datasheet is 700mV:

While the input of the bluepill is referred to 3.3V , and the user manual of VP-Digi suggest to adjust the audio level so that most packets have a signal level of around 50%. In my case, with the trimmer fully clockwise, the audio level of the packet was about 20%.

To fix this, I added an audio amplifier between the audio out of the SA818 and the input stage of the VP-Digi audio interface.

I bought this compact PCB based on LM386 IC:

I removed the pin strip and sticked the board on the bottom of my PCB, and I made connection with small wires for wirewrap:

After the installation, I noticed the the audio level was always too high. On the datasheet, I read that the gain is internally set to 20 but it can be modified from 20 to 200 by placing a resistor and capacitor between pins 1 and 8:

I removed R1 from my board and the I finally had a good audio decreasing SA818 audio level to 2 (“sa818 –port /dev/ttyS0 volume –level 2”) and with both the trimmer of my board and the trimmer of LM386 adjusted more or less in the center!

To adjust the audio level, connect to Vp-digi via serial port using minicom and go in “monitor mode” as suggested by the VP-Digi manual, then just listen for some incoming packets for tuning:

 minicom -D /dev/ttyS0 -b 9600
 

After, the tuning, the audio level should be around 50% and the positive and the negative percentage (values between brackets) should be the same:

The board is actually under test and it seems to be very stable.

I will start to develop a new PCB layout with SMD components, which allow to reduce the overall pcb dimensions, and will include the LM386 that now is applied externally.

I’m preparing some sensitivity test, for comparing this board with a standard RTL-SDR dongle, but I will publish the results as soon as I get the attenuators from aliexpress necessary for the tests, so stay tuned… 🙂

73’s

IZ7BOJ

Update 1/6/2026

I got the attenuators and I did some simple sensitivity tests.

It’s worth noting that the method is very rudimentary, but the scope is to have some “quick and dirty” numbers.

A Vector Signal Generator would be needed for a professional test.

The setup was made of a remote station which transmits a beacon every 30seconds, and a local station including both my receiver under test and a nooelec RTL-SDR dongle. After the antenna, there are a fixed and an adjustable attenuator, then a power splitter which delivers the signal to the receivers.

On the RTL-SDR side, I used rtl-fm software for raw data, and direwolf decoder.

The variable attenuator is increased until one of the two receiver begins to lose packets.

Here below, the results are reported:

Every row of the table refers to an observation period of 10minutes, which corresponds to 20 transmitted beacons.

The column “att” refers to the value set on the variable attenuator and it’s our reference in dB for the sensitivity

“Dec vpdigi” shows the packet decoded by the receiver under test, while “dec rtlsdr” says the packets decoded by rtlsdr dongle, which is our reference.

While the tx station was transmitting, I started to increase the attenuation on the rx side until some packets were lost, and stopped when no packets were decoded anymore.

It seems that the dongle sensitivity decreases faster than my board. You can see this behaviour considering the orange area, which represents the zone with packet loss.

In green you can see 100% decoding and in red 0% decoding.

If we consider the 50% packet loss, the dongle is about 4.5dB more sensitive than my board, but if we consider higher packet loss, like 2 or 3 packet decoded, the difference is only 1dB.

I think it could depend by different slope of analog and digital filters of the rf front-ends.

An important difference is that with RTL-SDR we have a full 16-bit (or even 32-bit) software pipe, which is used to pass the audio data from the rtl-fm software and the modem (direwolf in this case).

With STM32F103C8T6 used on the VP-DIGI , we have a 12-bit ADC with all it’s non-idealities and noise, and the ENOB would probably be at most 10 bits (in some optimistic case).

VP-Digi is quite a “crude” design with close-to-zero control of the analog signal path. Amplifying the signal in an early stage to reach close to 3.3V peak-to-peak is crucial for limiting the noise and making use of these 9-10 effective bits.

All in all, ENOB and uncontrolled electrical design are the major factor for sensitivity degradation.

At the end of this analysis, I would consider the results acceptable.

My “Land-Sea-Air” i-Gate

The flexibility and power of ARM series processors and Raspberries is well known, and the Raspberry PC is now increasingly popular in both the professional and amateur radio sectors.

For more than 10 years now, my I-Gate APRS has been running on this platform thanks to the well-known aprx software, without any stability problems (with UPS ,practically no reboot is necessary for entire months).

The use of cheap SDR dongles, such as the famous RTL-SDR, is widely used for decoding APRS traffic, so I also wanted to experiment with the use of this SDR on my node, and I must say that the sensitivity comparisons compared to Classic Radio System+TNC Hardware are amazing.

In parallel with the classic aprs on 144.800MHz at 1200baud, I started experimenting with the LoRa protocol in UHF. Precisely with the intention of maintaining the raspberry+aprx pair as the reference HW, I developed a KISS-TNC that allows Semtech LoRa modules to be interfaced with aprx via kiss-over-tcp protocol.

The Software is available at the following link: https://github.com/IZ7BOJ/RPi-LoRa-KISS-TNC-2ndgen .

Still remaining in the field of geo-localization, I wanted to extend the experimentation to maritime traffic, so I implemented a gateway that transfers AIS traffic to the famous amateur portal aprs.fi.

Different software are ready to use in Windows and involve the use of a radio connected to the PC’s audio input, while in my implementation I used an SDR dongleand open-source applications described in this article.

To view local traffic both in a table and on a map, I developed a web dashboard, also described in the same article.

But if up to this point I have talked about ground stations and ships… at this point the only thing missing… is AIR! And so I added the third SDR stick dedicated to decoding ADS-B signals, the data of which is always available on the dashboard developed by Skyaware.

The block diagram of the node is available below, and I’m going to describe it afterwards.

As is easy to see, the antennas in use are only a dual-band collinear and an antenna dedicated to ADS-B, bought for a few euros from Aliexpress and encapsulated in a 20mm PVC tube.

The signal coming from the collinear is first sent to a Notch filter which eliminates the 88-108MHz band of Broadcast FM broadcasters.

In fact, the RF front-end of the cheapest SDRs does not have any preselector filter, so they are desensitized in the presence of strong signals such as those of FM radios.

The output signal from the filter is then divided into VHF and UHF bands by a duplexer. For reasons of compactness and not having to manage large powers (the Lora module has only 1Watt output), I chose a mini V/U duplexer that uses SMD components, purchased from Ebay and built by the Hungarian Janilab.

At this point the UHF signal is routed to the Lora module, first passing through a quartz filter calibrated at 433MHz, purchased from aliexpress.

I wanted to try this filter because the front-end of the LoRa modules, especially the Ebyte E22-400M30S which has an LNA inside, does not have any filter at its input and therefore it is easy for it to saturate in the presence of strong signals in the UHF band .

Since the 1200Baud APRS and the AIS signals both travel in the VHF band, although on slightly different frequencies, I used a power splitter easily available from Aliexpress to split the VHF signals between the SDR receivers dedicated to the aforementioned protocols.

Below are some photos of the igate assembled inside a Gewiss 38x 30x 12cm box:

Here below, the same picture with indications of the building blocks:

It’s worth to be noted that the diplexer is inside a white heat shrink tube:

So far the whole system has proven to be very stable and reliable, and the CPU load is under 50%, as can be seen by running the “top” command on the Raspberry:

As you can see, the processes affected by aprs, ads-b and ais, highlighted by the red dot, use approximately 60% of the CPU.

Since there is still some power available, the next step will be to try adding a fourth satellite decoding stick 🙂

Ah, I forgot the most important thing: the igate homepage can be reached at http://iz7boj.dyndns.org/ . From it you can choose which dashboard to open and which information to view.

Hoping to have done something pleasant by sharing this experience, I greet all OM colleagues and wish you much fun!

Alfredo IZ7BOJ

My AIS receiving station

As an APRS enthusiast, I often saw various boats tracked on aprs.fi .
Reading the origin of the packets, I became aware of the AIS system that I didn’t know before, and I understood that in some areas of the Italian coast there are ham gateways that receive the AIS system and forward the packets to the APRS-Internet Service.
After some insights in the AIS standard, I tried to understand if there is a setup within the technical and economic reach of a mean radio amateur, and in fact there are many, based both on Windows or Linux platform, on classic radios (with a “flat” output suitable for 9600baud) but also on SDR. And among these I discovered that, once again, there are solutions based on the legendary RTL-SDR dongle!
Already having a raspberry on which all my ham services running (aprs digi, Lora digi, WSPR receiving station), I decided to look for a software solution that once again can run on raspberry.
In various searches, I also came across the solution of dear Michele I8FUC, but in the end the one that seemed simpler and more efficient to me was that of KB9IQX, based on RTL-AIS, a special version of famous RTL-fm software customized for reception of AIS signals, which sends audio to the GNU-AIS decoder.
The peculiarity of the solution adopted by KB9IQX is the way in which the digital audio stream passes from RTL-AIS to GNUAIS, called “named pipe” (refer here for further information).
Following step by step the instructions given by KB9IQX, I managed to obtain an AIS receiving station at the first attempt, without any hitch. As antenna I used a V/UHF dual band collinear Diamond X510 and the results were already good. On the other hand also I8FUC uses a collinear and has an excellent reception coverage.

However, since the radio operator always wants to experiment and improve himself, I didn’t stop at the first option and I wanted to build an antenna perfectly resonating on the AIS frequencies (162MHz).

Being my station on the Adriatic coast, I don’t need too much directional antenna. It is enough to Suppress the back lobe, coming from the hinterland. I started to search for a 3 element Yagi and I’ve found a project by VA3RR on the internet.
The antenna has a decent forward/back ratio, good bandwidth and can be fed directly into 50Ohm without any impedance transformer.
Lengths refer to elements mounted on non-conductive booms. In the case of a metal boom, there are formulas that take into account the shortening, but I didn’t want to complicate my life and I decided to use an insulating boom too.
The AIS signals have vertical polarization, therefore the directive should be mounted on an insulating support to avoid spurious coupling with the pole on which it is mounted.
The diameter of the elements is 5mm in the simulation, but then I used 3mm rods that I had available in my garage. Below in the article I describe the results.
Here’s the NEC2 input file, if you want to play with the design.  I used 4NEC2 by Arie, which is shareware:

CM Orr 3 element yagi scaled for 162 MHz
CM  9 = reflector , 2 = driven , 5 = reflector 
CE   
GW  9   11   0.00000  0.000000   0.48150   0.00000   0.00000  -0.48150   0.00250
GW  2   11   0.33500  0.000000   0.44000   0.33500   0.00000  -0.44000   0.00250
GW  5   11   0.60500  0.000000   0.39600   0.60500   0.00000  -0.39600   0.00250
GE  0
LD 5 9 1 13 5.8001E7
LD 5 2 1 13 5.8001E7
LD 5 5 1 13 5.8001E7   
FR  0    1    0    0   1.62E+02  0.00E+00  0.00E+00  0.00E+00  0.00E+00  0.00E+00
EX  0    2    6    01  1.00E+00  0.00E+00  0.00E+00  0.00E+00  0.00E+00  0.00E+00
RP 0 37 37 1000 -90 0 10 10
PQ -1
PT -1
'FR 0 20 0 0 162 1
XQ
EN   

Here are the theoretical dimensions:

Below there is the radiation pattern:

Here are some photos taken during my construction.

The construction technique and the materials used are the same described in this other article that I wrote some time ago.
I used pvc pipes and accessories for electrical materials. The box in the center of the radiator is also electrically sealed. Still in the same box, I housed a small RF choke to suppress any parisitic currents that could flow outside the coaxial shield, due to the symmetry at the feed point.
I made the choke with a few coils of RG174 coaxial cable (or similar.. the one I had in the garage 🙂 ) around a small piece of 20mm diameter PVC pipe.

The RF connector is a SO239 because it was the one I had available, but nothing prevents you from using an “N”. In both cases, I always recommend the type with a square flange, to be fixed with 4x M3 screws and bolts to the wall of the box. Connectors without a flange tend to rotate once tightened, risking breaking the connections inside the box.
At the point of attachment to the pole, I reinforced the boom by inserting a small 20mm piece inside the 24mm PVC tube to avoid crushing.

Every element is hloded on the boom by a PVC clip (type suitable to fix the PVC pipes on the walls), which I drilled with 3mm tip. Be sure to be perpendicular during drill. It’s better to use a column drill for this operation.

When all 3 elements are on the boom , they can be fixed on the boom with small screws, as reported in the picture below. Be sure that all 3 elements are aligned in parallel before fixing them (carefully view the antenna on the front).

After building the antenna, I performed the calibration comfortably in my garage (during the winter it is not pleasant to do it outdoors!).

Considering that I preferred to leave about 2cm more length on the radiator than the theoretical length calculated on the NEC (shortening is always done in time, lengthening is a little more difficult…), the first tests showed a resonance at about 150 MHz, so more than 10MHz than expected. After various shortenings, I finally reached the resonance at 162MHz with a length of 85cm, therefore 3cm less than the theoretical one.

Once installed, the antenna immediately showed excellent results and improvements compared to the collinear one.
A notch filter to eliminate 144.800MHz transmissions from my aprs tx-igate would further improve AIS reception, avoiding completely saturating the SDR dongle. But this is Work in progress..
To complete my receiving station, I thought that, in addition to forwarding data to aprs-is, it would be nice to know in real time which vessels are under coverage , so I thought of a web interface similar to the one already developed for stats view of my igate aprs.
With minor readjustments of the code, it was easy enough. Unlike the aprs web interface, which processes an aprx log file in ASCII format, this time data is read doing queries to a MySQL database (MariaDB), also installed on the raspberry following this simple guide. This is possible thanks to the fact that GNUAIS implements mySQL in native way.
As already done for aprs, I left a summary table of raspberry system information.

Here below, some pictures of the web interface:

Note that a lot of “n/a” are displayed because not all the ships informations are transmitted in every AIS spot.

Every marker is numbered and refers to the table. I didn’t put ship names near the markers because the map could become unreadable, especially in case of ships close to each other.

Clicking on every MMSI number, a new tab will open and show ship on aprs.fi in the user’s browser.

Also ships details on marinetraffic are available clicking on “ship details”.
The source code of the page is available at this address: https://github.com/IZ7BOJ/GNUAIS-web-interface

The Web interface installed on my raspberry can be reached at this address: http://iz7boj.dyndns.org/ais/ (the page opens slowly due to some problems on wifi link between home, where the ADSL modem is installed, and AIS receiver site)

Hoping to have provided some interesting ideas to OMs interested in the AIS system, I wish everyone good experimentation
73’s
Alfredo IZ7BOJ

Simple variable attenuator using PE4302

During sensitivity measurements of my LoRa modules, I needed a variable attenuator in order to find the minimum level that can be demodulated. To do this, a resolution of at least 1dB is preferrable.

I started to search something ready to use and I found some interesting solutions on aliexpress. Nevertheless, I always search the comprimise between “ready to use” solution and something not fully ready but which represents the opportunity to try and learn new things. So I bought a simple PCB equipped with PE4302 Integrated Circuit by Peregrine Semiconductors, already connectorized.

On aliexpress, there is also a version of the PCB with DIP-Switch selector, but it’s not very comfortable to to decimal 6-bits convertions and move the switches with a small screwdriver during tuning phases while searching the sensitivity level! I want something with up/down buttons and a small display in order to see the attenuation set.

Then I had an ESP32 evaluation board in my drawer, which was unused for a long time..so I added an OLED 128×64 I2C display for other few euros and started to write the simple code which drives the display, adjusts the attenuation value by pushing up/down buttons and converts the decimal value to the 6-bits port of the attenuator.

A simple web interface is also available for the remote control of the attenuator.

The final result, assembled on a prototype board, is reported below:

The OLED display is powered by the 3V3 provided by the ESP32, and its SCL and SDA lines are wired respectively to pins 39 and 42 of ESP32.

The Up and Down Buttons are connected respectively to pins 35,34 of ESP32, and pull-upped to 3V3 through 10K resistors. The buttons close the lines to ground when pressed.

The bit from LSB to MSB of the PE4302 are connected to pins 23,25,26,27,33,32 of ESP32, ant the 3V3 is taken from ESP32 too.

By the way, all the pin assignment can be changed in the code and on the PCB, if you want.

The source code is available here.

The Wifi SSID and password must be edited in the source file before uploading.

Some serial prints are available in order to see debug infos. For example, serial can be used in order to see the IP that ESP32 obtained from the wifi dhcp server:

Once the IP is known, it could be entered in the browser navigation bar in order to open the control page:

The default value is 0, but a value up to 31.5dB can be entered by keyboard or pressing arrows of the input box.

In the example below, 31.5dB is entered.

Then, a page that confirms the command reception is displayed:

The new attenuation value will be immediately shown on the OLED display also.

I’ve done some measurements with my miniVNA and the linearity and precision of the PE4302 is good.

I hope that this project is useful for you and I’m available for further clarification.

73’s

Alfredo IZ7BOJ

SX1278 vs. Ebyte E22-400M30S Lora modules: receiving performances evaluation with test on the field

In this article i did some tests on the road with my 100mW and 1W trackers and I concluded that the price difference worthts the range improvement.

Once that I know that the tx performances are much better for Ebyte module, I started the receiving tests.

For the comparison, I connected to the same base antenna two Lora Igates based on raspberry and my python Kiss TNC . The first uses a Semtech SX1278 (1st generation) module, the second uses an Ebyte E22-400M30S module. The two igates are connected to the same antenna with a power splitter bought for few euros from Aliexpress. Here below a picture of the setup. The splitter is visible in the lower-right corner.

The first test session has been done between two fixed station. The first station had the two i-gates previously described, which shared the same antenna. The second was a fixed station, some kilometers away, with a SARIMESH tracker and external antenna. The igates have been set as receive-only stations, while the tracker transmitted beacons at different power levels.

The sarimesh tracker allows the power regulation between -9 and +22dBm at 1dBm step. In order to reach the lower limit of sensitiviy, ad additional 10dB attenuator was added during the tests.

The final purpose of this first session, was to plot RSSI and SNR at receiving side for various tx levels, for both semtech and ebyte module.

It’s worth to remember that the Ebyte module has a LNA in the rx part, which is not present in the case of sx1278 module.

Here below, the table of received values and the plots:

Please note that the case “32dBm” was obtained removing the 10dB attenuator.

As you can see, the Ebyte RSSI curve is shifted about 7dB upwards with reference to sx1278, which is presumably the internal LNA Gain, while the Ebyte RSSI curve (the most important one) is about 2dB worse than the sx1278! Moreover, the Ebyte SNR curve is clamped at 5dB when tx power>18dBm, while the sx1278 SNR continue to grow up to 12dB.

So, it seems that the LNA doesn’t improve the performances, but let’s go on with other tests.

At the end, the final goal of this test session is to determine which of the two modules loses fewer packets when they work in the lower part of the rx characteristics, at the limits of their sensitivity.

To do this, I did a test “on the road”. I kept the same configuration on I-gate side, with two i-gates which share the same antenna by the power splitter. This time, the transmitting station is mobile. I brought a tracker in my car while I was going to work. My QRL is 75Km far away from my QTH, so there are parts of tracks which are at limit of igate range and are received at limit of the sensitivity or below (lost).

The two igates logged indipendently all the received packets. Comparing the packets with time-stamp, it’s easy to do interesting some statistics.

Here below, the results:

Here below, I report the meaning of the colours:

• Red: packets received by Ebyte and lost by sx1278 (sx1278 loose)
• Gray: packets lost or corrupted by both modules (“don’t care” case)
• Light green: packet lost by Ebyte but received with CRC error by sx1278
• Dark green: packet lost by Ebyte but correctly received by sx1278

The conclusion is that sx1278 loses less packets than Ebyte module. And the lesson learned is “an LNA close to the RX instead of antenna, can worse the RX sensitivity rather than improve it”!

Moreover, in case of Electromagnetic polluted site, the LNA can saturate the receiver if not properly filtered. I don’t know if a filter is present before LNA and its characteristics, but the operating frequency of ebyte module is 410~493MHz. It’s a very wide band and it could be very easy to catch strong signals!

I hope these measurements could be useful to other OMs.

73’s

Alfredo IZ7BOJ

Description of my hamradio mobile station

Initial note: this article is available in italian here

Traveling a lot, I often found myself operating in mobile, mainly in V / UHF.
Not wanting to “rape” my car by drilling the hood and installing a fixed antenna, I have always used magnetic base antennas.
If on the one hand this type of antenna is practical to install and leaves the car aesthetically “clean” when it is not mounted, on the other hand it has the disadvantage of the passage of the cable, which remains hanging in the passenger compartment and is an obstacle especially when you are not alone in the car.
Wanting to find a more pleasant and less precarious solution, I started thinking about how to fix things a little more professionally.
The requirements of my mobile station are these:

• Use of magnetic base antenna;
• Passage of cables as little as possible dangling and visible;
• Use of the FT2-D and stable positioning on the dashboard, with visible display;
• Installation of a linear V / UHF amplifier that can be activated by means of a switch and installed invisibly;
• Listening to the audio being received via the car radio system;
• “Hands-free” system in transmission.

Below I will show point by point which solution I have adopted.

1) The magnetic base has a diameter of 20cm, therefore stable and safe even over 100Km / h. The antenna I’ve always used is the diamond NR770R:

2) As you can see in the figure, to limit the dangling of the cables, a low-loss coaxial was inserted in the blue dotted path, from the radio to the driver’s side pillar. At that point a female SMA connector is exposed, and this is unfortunately unavoidable.

3) For the stable installation of the FT2-D, I used a metal bracket that clings to the fins of the car’s air vents. It is a somewhat particular bracket that I bought online a few years ago, but of which I cannot find the references. I have always found myself very well and if necessary it can be removed easily, because it is held up with elastic clips. At the same time it is stable and has always handled a Kenwood TH-D72 and now an FT-2D without any problems.

4) The linear I have chosen is the following.

It has the advantage of having the automatic selection of the V / UHF band through radio frequency sensing, so I installed it on the passenger side as shown in the images, already in the ON position. Remote ignition will be shown later

5) To listen to the audio through the car speakers, I brought the audio output of the FT-2D to the auxiliary input on the front of my car stereo. The quality is obviously excellent when compared to the radio speaker, which becomes almost unusable with the noise of the car

6) The hands-free system was the most complex part of the system. The activation of the PTT via VOX, although it is available on the radio, I do not like very much, also because with the noise of the car it is subject to unwanted activations and the adjustment is delicate. To have your hands free and not to incur a penalty (the highway code FORBIDES driving with microphones in hand!) The only solution was a “bistable” toggle switch, therefore without automatic position return, installed as much as possible behind the wheel, so you can take your right hand off the wheel for just a moment. I thought of installing the microphone capsule near the driver’s side sun visor, near the pillar, so that the capsule was not very visible but at the same time was able to collect the voice well. In the following photos, there are the details of the capsule.

Then I thought that the capsule could also be useful for the bluetooth speakerphone I use for my mobile phone. I noticed that the microphone capsule of the car radio is of very bad quality and collects a lot of noise and creaks, and the interlocutor hears very badly. So I thought of sharing the same microphone capsule between the FT-2D speakerphone and the radio speakerphone, simply by adding a switch that selects one or the other (simultaneous use is practically impossible).
Below you will find the general scheme that better clarifies the interconnections of the system.

As for the linear, PTT and MIC IN selection switches, I installed switches in black plastic boxes inside a high 1DIN glove box. The photo below clarifies the details.

To facilitate the attachment and detachment of the SMA connectors, which are very inconvenient to screw and also fragile, I purchased this adapter: Spectrum 8001-SM21-02 (datasheet below)

data_sheet_8001-sm21-02Download

which allows the SMA to become like a Jack, thanks to its internal elastic fins. It’s not exactly cheap, but it’s incredibly convenient. I have been using it for years and it still shows no signs of letting up, it still holds up stably. I used this connector both on the radio and on the coaxial connection on the riser.

In this video, you can see how fast the attack and detachment is:

Finally, here is a video that highlights how it takes less than a minute to mount the antenna and radio and start transmitting:

Hoping to have given some useful ideas to some other OM, I greet all the “mobile” OMs like me 🙂

73 ‘

Alfredo IZ7BOJ

Comparison of APRS Tracks with 1Watt and 100mW LoRa trackers

I’m enjoying the performance of LoRa with my APRS trackers and my I-Gate based on Raspberry+Aprx+Phython-Kiss-Tnc .

I’ve built two trackers:

• SARIMESH tracker equippend with eByte E22-400M30S 1Watt module
• Tracker “D” by lora-aprs.at equipped with SX1278 (100mWatt) LoRa module

I was very curious about 1Watt tracker performances, so I thought a way to compare the range improvements “on the field”.

I decided to test the two trackers on the road that I drive every day for going to work, from Trani to Mola di Bari. About 75Km in a flat aera on the Adriatic coast of the South of Italy.

The I-gate is installed in Trani, my QTH, and uses a Diamond X-510 collinear antenna installed in a country cottage.

The trackers have been used in my car, with a Diamond NR770R perfectly tuned as described in another article.

The first trackers have been used on two consecutive days with very simila weather conditions, and this should have limited the influence of the EM propagation on the results.

The beacon interval was set to 30second in order to have enough “samples” of the track.

The LoRa Parameters are the following:

• BW:125KHz
• SF:12

Note: the period is very short and violates the “best APRS practices” for avoiding channel congestion, but I’m the only LoRa Station in my area and I think I didn’t cause trouble to anyone. Don’t use 30seconds interval on standard 144.800MHz channel!

The main goal of the comparison is to have some statistics, like the number of received beacon and CRC errored beacons, and to do a “visual” comparison of the tracks on aprs.fi.

I could count the “CRC errored” packets in RPI-LoRa-TNC-KISS logs. The software doesn’t forward this packets to aprs-is server, but keeps them in log.

Here below, the tracks of 1Watt tracker and 100mWatt tracker:

1Watt tracker aprs track

100mW tracker APRS track

Here below, some statistics:

Here below, the coverage simulation made by Radiomobile Online:

At this point, I do my notes, conclusions and considerations:

• In general, I’m very excited and surprised about the performance of LoRa modulation. With FSK1200 @144.800MHz, the coverage of my Igate is about 40Km and never arrived into Bari. Here below, I highlighted the coverage tests of my VHF digi, with same antennas on igate and on the car:

• I’m impressed by some beacons received in the centre of Bari, surrounded by very high buildings. Here below an example:

• The duration of 1Watt track is longer than the other, due to higher traffic on the road in some points. The slowdowns happened mainly in areas well covered by my Igate, and this partially explains the higher number of beacons received from 1W tracker
• I tried to have the same style at the guide of my car, but the traffic was different and this has influence on the tracks.
• The packet loss is completely different in the two cases, and this is explained by more than 10dB of gain in case of 1W tracker
• The absence of beacons in some “gray area” of the ring road of Bari is confirmed in both cases and it could depend by the orography of the land.
• Looking at the logs, the S/N has some margin at Mola di Bari (the end of the track), so I’ll try to go more on south and find the limit where beacons are not received anymore. I could have nice surprises!
• The Ebyte 1Watt module is worth the price and makes more fun with experiments.

I hope these results could be useful to LoRa experimenters.

73’s

Alfredo IZ7BOJ

VSWR Measurements on my mobile antennas

I’m going to describe some measurements and tunings that I did on these two mobile antennas:

• DIAMOND NR770R
• D-ORIGINAL TORNADO-MAG-VU

Diamond NR770R

Here below the antenna characteristics from Diamond website:

I’ve been using this antenna for long time with my VW Polo. I described my mobile setup here.

I installed the antenna on a 16cm diameter magnetic base, as you can see in the picture:

The antenna is quite long and it’s quite showy on my car. My wife doesn’t like it too much 🙂

Anyway I use it when I travel alone and want to to some range test with APRS.

Here below the characterizations of SWR and S11 in 2m and 70cm band:

• 

• 

• 

• 

As you can see,the resonance in 2m band is quite perfect with reference to 144-146MHz interval, while the resonance in 70cm band is too much moved up, and the VSWR in 430-436MHz interval is >2:1 , which is very bad.

I tried to tune the UHF part of the antenna stretching the segment below the trap, (I noted some spare length inside the base), but It was not enough to move the resonance more than 10MHz below.

I also noted that the trap is not a parallel resonant, because the upper element influences the resonance of 70cm instead of being completely isolated. At that point, I tried to add a wire at the tip of the antenna in order to tune the 70cm, at least. Here below, a detail of the tip 🙂

At the end of tuning, I moved the resonance exactly where I want (see marker 3 of the picture below). The frequency that I’m using very frequently is 433.775MHz, which is the standard Lora operating frequency.

Here below, the results after tuning:

Unfortunately, the resonance in 2m band is too low, but I’ll try to balance the length of the upper and lower elements in order to reach perfect resonance in both 2m and 70cm band.

If I can make it, I’ll update the article.

D-ORIGINAL TORNADO-MAG-VU

I bought this antenna mainly for aesthetic reasons, not for performance. The antenna looks good on my black car:

Here below, the antenna characteristics:

Here below, the measurements made with my NanoVna:

• 

• 

• 

• 

As you can see, the resonance in 2m band is too low, and in 70cm band is too high (marker 3).

Nevertheless, the VSWR is still good, but it could be the effect of the very bad quality cable. 4meters of RG174 attenuates a lot and lowers the VSWR becaus dissipates both forward power before reaching the radiating element and the reflected power from the radiating elements up to the VNA port.

The attenuation for 4meters, considering the declared value at 400MHz, is 62,34/100*4=2,49dB.

Moreover, I noted that thw VSWR curve moves a lot when I move and touch the cable, and this is not good, because is the evidence of currents flowing on the external of the cable braid, and the evidence that the cable shielding is not very good.

I’ll try to replace the RG174 with a better cable and repeat the measurements.

I hope these results could be useful for other OMs who are going to select a mobile antenna to buy.

73’s

Alfredo IZ7BOJ

Power and Current characterization on Ebyte E22-400M30S Lora Module

In another article I described the power characterization on Semtech SX1278 (first generation) Lora Module and, in conclusion, I say that the measurements are very aligned with the datasheets.

In this article I’ve written the results of the same kind of characterization performed on Ebyte E22-400M30S.

First of all, it is worth remembering that this Ebyte Module is composed by a Semtech SX1268 and a couple of LNA/PA which should improve the RX sensitivity and bring the output power up to 30dBm (1Watt). Said that, I deduce that the PA gain should be about 8dB and should be added every time we set the output power using SPI commands directed to the SX1268.

The objective of this characterization is exactly the verification of this gain, as well as the current consumption. For this activity, I used the function “setTxContinuousWave” wich is very useful for tests because sets the module in CW mode (tone). In this way, it’s very easy to measure the power with my TinySA Spectrum analyzer without any other trick. The input of the TinySA was protected by a 30dB external attenuator during the measurements (the max input power is +10dBm). Moreover, I enabled the instrument internal attenuator because I noticed a lot of artifacts on the spectrum without it.

I wrote a simple python script which can be run on a raspberry connected to the Lora module by SPI bus, and sets the module in CW at the following power steps: 10,14,17,20,22 dBm (these are the allowed steps in python library which does not offer very fine resolution for the power).

The script keeps the module transmitting 10 seconds for every power step, and this allowed me to make screenshots and measurements.

Here below some pictures of my setup:

Here below there is the table and the plots of the power consumption and the output RF power:

It is evident that the output power is quite aligned with the specifications although the PA gain is subject to a little bit of compression passing from 10dBm to 22dBm driving power. The compression is evident comparing the measured curve (blue) with the orange one, which is the expected value calculated from the power setting + the theoretical gain which is supposed to be constant and equal to 8dB.

It is worth to note that I have not measured and then compensated the loss of the small pigtail from upx micro connector of the module to the SMA female. In my experience it should be less than 0.5dB

Very important note about the power supply

The characterization has been performed by powering the raspberry with a laboratory power supply, and compensating the voltage drop across up to the lora module ! I’ve noticed a huge Voltage drop across common USB cables. When the module was set to the maximum output power, the voltage on the module Vcc pins dropped to 4,65V. Increasing the voltage provided to the raspberry to 5,33V , the voltage on the Lora module was exactly 5V and the output power increased from 18.1dBm to 19.1dBm!

If you want to use the raspberry 5V, be sure to use a very good quality power supply and cable.

Another Very important note about the over current protection

The first characterizations showed a limitation to about 23dBm. I did a lot of investigation and, a the end, my friend Michele I8FUC discovered that the problem was the OverCurrent Protection (OCP) setting. Unfortunately, the datasheet doesn’t declared a maximum value and the python library doesn’t have any limit for it. During the experiments, I set an OCP value which exceeded the limits and caused a “wrap-around” and the final effect was a very low current limit, which was the opposite of my intent.

Once the OCP was set again to the default value of 140mA, the problem was fixed and the output was very near the datasheet value.

I just made a pull request to the author of the library in order to limit the ocp value and prevent other users to waste a lot of time.

I did some experiments to find out the OCP register depth and it is 6 bits. Every step is 2.5mA, sto the maximum value is 157.5mA. Don’t exceed this limit. In my experiments, thresholds higher than 80mA doesn’t affect the output power.

Conclusions:

I didn’t compare the receiver performances versus SX1278 module, anyway I think that the module is a very good and compact solution to increase the output power and have more fun with Lora. In my humble opinion, the cost is adequate considering the performances.

It is worth considering that the management of the Ebyte module is more complicated than SX1278 because it needs additional pins for switching the LNA and the PA (rx_enable, tx_enable). Also busy pin is not present in SX1278.

Moreover, I noticed some incompatibility issue between Lora APRS trackers/igates based on SX1278 and on Ebyte E22-400M30S. In particular, some SX1278 trackers based on Austrian FW (OE5BPA or https://www.lora-aprs.at/ ) are not correctly received from igates based on Ebyte modules (lot of CRC errors). Nevertheless, this problem is still under investigation and I reported it here only for reference.

I hope these measurements can be useful to other passionates that are going to use it for their projects

73’s

Alfredo IZ7BOJ

Power and current measurements on SX1278 Lora Module

I was doing debugging on RPI-Lora-KISS-TNC python software because I was quite sure that the output power was setting was not working properly. For this debugging, I had to check the output power at different settings, so I decided to take this occation for a characterization. I connected a current meter on the power line and I took both power and current readings at different levels.

For the power measurement, I used a TinySA spectrum analyzer and the “Channel Power” automatic measurement, which integrates the power reading over the whole channel bandwidth declared by the user.

I put a 20dB attenuator on the Lora module output because the maximum input level of the TinySA is +10dBm and the expected max signal is about +17dBm.

The TinySA settings are reported below:

• Span: 1.8 MHz
• RBW: 336KHz
• Scan time: 112ms
• Ext att: 20dB
• Int att: 29dB
• Max Hold: ON
• Channel Power band: 600KHz

The SX1278 was set with the following parameters:

• Frequency: 433.775MHz
• Preamble length: 8
• Spreading Factor: 12
• Coding Rate: 4:5
• Bandwidth: 125KHz
• Synch Word: 0x12
• PA_Select: 1

Here below a picture of my setup:

The output power of the SX1278 module can be set acting on RegPaConfig register. The datasheet for this register is shown below:

We have 4 bits available for power setting, so 16 steps available from 0000 to 1111. In my case, PA_Boost is set to 1, and in any case can be set by the user chancing “PaSelect” in config.py file.

There is also a possibility to reach +20dBm setting valie “0x87” in “RegPaDac” register, but the duty cycle should be kept under 1%. I didn’t try it because I preferred to do the characterization in standard configuration.

I also took the occasion to fix a bug in the SX1278 library available on github, because the function “get_pa_config” was doing a wrong conversion in dBm in case of PA_BOOST=1.

The result of the characterization is reported below:

In addition to tx power consumption, a measurement during continuous rx mode has been done, and the result was about 12mA.

The output plot is very linear. Small compression is visible only in the last two power steps. The results in general are in line with the datasheet, although no plot is provided.

Here below, the power consumption in tx and rx mode are reported. I highlighted in yellow the reference values.

I hope these measurements can be useful to other OMs and makers.

73’s

Alfredo IZ7BOJ