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 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.
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)
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 🙂
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:
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:
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.
I’m going to describe some measurements and tunings that I did on these two mobile antennas:
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.
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.
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.
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
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
Scan time: 112ms
Ext att: 20dB
Int att: 29dB
Max Hold: ON
Channel Power band: 600KHz
The SX1278 was set with the following parameters:
Preamble length: 8
Spreading Factor: 12
Coding Rate: 4:5
Synch Word: 0x12
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.
WsprryPi is a very popular software which turns a Raspberry in a WSPR transmitter using a GPIO pin.
The software can also automatically transmit spots on different bands, ciclically, and it this is intetresting if a multi-band antenna is used. Nevertheless, the output of the raspberry is a square wave and it must be filtered in order to avoid interferences (and fights with other OMs!).
QRPLabs designed a set of LPF filters and a special switching board which can be used for selecting up to 5 LPF. The switch is designed to be interfaced directly to Ultimate 3/3S transmitter, but can be easily adapted to a raspberry using a simple bjt switch.
On QRPLabs website, is declared that Corrie M0XDK forked the original wsprrypi software and developed a special version that can drive the QRP Labs relay board, using GPIO pins from 7 to 11.
Once I built my LPF filters and my switch board, I tried to drive them using this WsprryPi version, but I couldn’t get success.
Analyzing the code, I understood that Corrie forked from a very old version, whic is compatible only with Raspberry 1. All the memory maps are not compatible for Raspy 2 or greater.
Once I built the filters, I started to build the QRPLabs relay switch for automatically select up to 5 different filters by my raspberry.
The board is designed to fit with Ultimate3/3S transmitter, but can be interface to other systems adding simple BJT switches, as suggested on QRPLabs website.
I put the 5 transistors, the bias resistors and striplines connector on a prototype PCB having the same dimensions of the switches board, and is connected below it using the headers provided in the relay kit.
For RF input, I used a short piece of RG142 coax cable, terminated with an SMA male to be plugged on the VNA for initial characterization. Later, I replaced the SMA with a 2pins female stripline contact which can be plugged directly on the Raspy headers. On the other side, I soldered the coax directly to the PCB pins.
Here below some pictures:
I repeated all the filter measurements previously done on the filters connected one by one to the VNA by means of PH2LB fixture, but this time using the relay board. Here below the results:
The in-band attenuation is very similar toe the previous results, so it demonstrates that the relay board introduces a very small attenuation.
The main difference is the out-of-band attenuation , which has a strange trend (decreases and increases again with frequency).
I don’t know why the isolation is worst than the expected. This could be due to some coupling effect on the PCB. I’m going to share the results on QRPLabs forum for understanding better.
If I come to some conclusion, I’ll write down here!
When I started experimenting with LoRa, I wasn’t sure it would thrill me (it did!), so I was looking for a minimal cost setup, without investing too much in hardware. In studying the possible solutions, I stumbled upon the Austrian LoRa OM site and found that there were schematics available for a very compact tracker that could also act as a Gateway. However, the funniest idea was to integrate the Lora with the 144.800VHF network already present on my digi / I-gate of which I am sysop, to create a cross-band and cross-protocol digipeater between VHF FSK1200baud and UHF LoRa. Still on the Austrians’ website, I discovered that there is a Software Modem that was created to interface with aprx, the software I have been using on my digipeater for over 10 years and which still remains one of the most versatile in the APRS field.
This configuration requires that the software that implements the TNC (in this case RPi-LoRA-KISS-TNC) and the software that takes charge of the packets to and from the TNC and then manages them according to the APRS protocol (in this case aprx) are connected to each other through the KISS protocol encapsulated in TCP-IP.
Using a tcp-ip link, the possible scenarios are the following:
Aprx (or equivalent) and RPi-LoRa-KISS-TNC installaed on the same host and linked by loopback 127.0.0.1:
Aprx (or equivalent) and RPi-LoRa-KISS-TNC installed on different hosts and maybe even distant from each other (interesting configuration):
My case is the first, that is software that run on the same raspberry, so a port of this type must be declared in the aprx.conf file:
The port must obviously be the same as the one declared in config.py of the RPi-LoRa-KISS-TNC.
I therefore decide to take this path and order an RFW96 module from aliexpress, to connect it to the raapberry SPI as indicated on the software installation how-to. After about 3 weeks, a couple of LoRa modules arrive from China. Unfortunately the Lora module has a very narrow pitch pinout, incompatible with the 2.54mm standard, so the ideal would be to use an adapter PCB. I ask the “IOT4PI” group for the PCB that was created for this purpose, but they tell me that they no longer have it available, so I decide to connect it to the raspy in a flying way. I proceed with some simple pieces of prototype jumpers (female square pins) and I can wire the LoRa module towards the raspberry following the Austrian scheme. I manage to solder a thin Teflon cable on the pads of the antenna output, and at the other end of the coax cable I fix a flying SMA. In the photo below the final result.
Both the software and the hardware worked immediately and I started conducting the first tests that immediately showed me the potential of this protocol. During the first period of experimentation I also had the opportunity to find and solve some small bugs on the software and to start communicating constructively with TOM, the author of the Software.
After this first phase, I came into contact with the Italian group SARIMESH, very active in the Lora experimentation, which has as its reference the very kind OM Michele I8FUC.
I learned that Sarimesh set their software to be compatible with both that of the Austrian group (baptizing it “OE_style”) and with the standard ax25. The idea is more than acceptable, because we should always avoid proprietary protocols and stick to the standard ones. However it must always be considered that the speed of the Lora is low and the ax25 produces a slight data overhead, so this trade-off is always in question.
From the need to maintain the ax25, the idea of expanding the RPi-LoRa-KISS-TNC was born.
During the first stages of debugging, I had already had the opportunity to understand the structure of the code written entirely in python and luckily Tom had also added some comments that made my work easier. Editing was easy enough and only took me a few hours of time.
The discrimination of the received packet is based on a packet header which was chosen by the Austrian OMs as their standard identifier, and consists of the 3 bytes “0x3C 0xFF 0x01”. Once I have received the packet, I check for the presence of this header. If present, then it is an “OE_Style” package to be processed with the functions already present in the code, otherwise it is a standard AX25 package.
To learn more about the structure of a standard AX25 frame, in addition to reading the protocol, I also recommend reading this excellent article, which also has a simulator that builds the frame in real time starting from editable fields.
Here below, a typical structure of a kiss frame is reported:
In case of ax25 package, the job is very simple: you take the package and encapsulate it in KISS.
KISS is a very simple protocol. In our case, what I do is simply:
Add at the beginning and at the end a byte “0xC0” of Frame start and Frame End;
After the first Start byte, I add a “0x00” byte. This packet is divided into two nibbles: the most significant is the port number (in the case of a single TNC it is “0”), while the least significant is the command. Again from the protocol, we see that the command “0” is the one that must always precede a data frame when it is passed from the tnc to the user. So basically this byte is always “0x00”.
Vice versa, the packet to be transmitted in Lora is received by the software, de-encapsulated by the kiss (thus eliminating the delimiters and the “0x00” byte described above) and transmitted as it is via LoRa RF.
While making these changes, I have also implemented these improvements:
Brought all the Lora configuration parameters (sync word, bandwidth, spread factor, preamble lenght, power, etc ..) into the config.py configuration file. Before, the parameters were hidden inside the code and it was a bit difficult to find them without a minimum of programming skills.
Added a printout of all these parameters at the start of the software, which is always useful to remind the user in what conditions the tnc was started.
Added printouts of the source call and the destination call of the standard ax25 packages, using the functions already present in the code.
Added log files to log both RF packets and system messages.
The configuration file is commented as much as possible to avoid user errors. A note on the “TX_OE_Style” parameter: it is a Boolean (therefore it can only assume a True / False status) which determines the transmission format. While in reception the TNC accepts both OE / ax25 formats, obviously in transmission we must necessarily choose one of the two, and this is done with this parameter.
Another obvious consideration: the parameters of the LoRa protocol (sync word, spread factor, etc.) will be the same in the case of OE_Style or ax25 packets, and it is not possible to differentiate them because the LoRa module only accepts a set of parameters to be initialized.
Here below, an example of cofig file:
You must also be careful to declare a valid path for the log files, and with the right write permissions, otherwise the software will fail on startup.
Below you will find some example screens in the various operating phases.
The following is the start-up screen with all the initialization parameters.Note the string announcing the successful connection between RPi-KISS-TNC and the client software, in this case APRX.
The following, is an ax25 packet receiver via KISS-TCP and transmitted by LoRa interface:
Here below, a OE_style packet riceived by LoRa channel and passed to aprx via KISS-TCP:
The previous packet (OE_style) received by aprx via KISS-TCP:
Packet received via LoRa in ax25 fromat and passed to aprx via KISS-TCP:
Here below, you can see as the austrian tracker is correctly receiving a beacon originated by aprx , passet to RPi-LoRa-KISS-TNC by KISS-TCP and transmitted o LoRa channel:
So far the software is behaving stably and has never crashed. Obviously anyone who wants to try it, test it and possibly contribute to the development with code modification or suggestions, is welcome!
The source is available on my github. The installation is described in the INSTALL.md file and is fairly straightforward. It plans to download, using the “git clone” command, the content from github to a local folder of the raspberry, and to download the python libraries of the LoRa module in a subfolder.
ATTENTION !: install.md says to go and modify the content of the pySX127x / SX127x / board_config.py file and change the mapping of one of the GP / IO pins of the raspberry dedicated to interfacing with the LoRa module :
This modification is in line with the connections provided in the wiring diagram, but there is nothing to prevent the original mapping from being changed, always consistently with the diagram, as long as the GP/IO lines are free and not used by other processes.
Take care also of the log files, which can become big. Configure logrotate for a correct storing strategy.
The log files are very useful because they store also corrupted packets which are not passed to and from aprx, but sometimes contain useful information.
I want to thank the original author, Tom OE9TKH who was the first creatorof the Software I expanded.