LoRa port for TARPN node: Difference between revisions

From TARPN Wiki
No edit summary
No edit summary
 
(27 intermediate revisions by the same user not shown)
Line 11: Line 11:


I'm going to assume you already have the Raspberry Pi configured with Raspberry Pi OS, and connected to your local network (the same network as your TARPN node). You'll want to assign a static IP to it (rather than DHCP), so you can ensure your TARPN node will be able to find it on the network after restarts.
I'm going to assume you already have the Raspberry Pi configured with Raspberry Pi OS, and connected to your local network (the same network as your TARPN node). You'll want to assign a static IP to it (rather than DHCP), so you can ensure your TARPN node will be able to find it on the network after restarts.
A few notes:
* This has only been tested with the "Lite" [https://www.raspberrypi.com/software/operating-systems/ Raspberry Pi OS image], not either of the "with desktop" images. They might work, but have not been tested.
* '''This definitely does not work on a Pi that has TARPN installed.''' Something in the TARPN setup script is incompatible with the LoRa bonnet. We may be able to fix this in the future, but it would require significant debugging to figure out what TARPN setup step breaks the LoRa bonnet functionality.


=== Get LoRa bonnet working ===
=== Get LoRa bonnet working ===
Line 111: Line 115:


=== Turn it into a TCP KISS TNC ===
=== Turn it into a TCP KISS TNC ===
See [https://github.com/IZ7BOJ/RPi-LoRa-KISS-TNC-2ndgen/blob/main/INSTALL.md the github project] for more info.
See [https://github.com/IZ7BOJ/RPi-LoRa-KISS-TNC-2ndgen/blob/main/INSTALL.md the original github project] this is forked from for more info.
# sudo apt install git aprx python3-rpi.gpio python3-spidev python3-pil python3-smbus
# sudo apt install git aprx python3-rpi.gpio python3-spidev python3-pil python3-smbus
# git clone https://github.com/IZ7BOJ/RPi-LoRa-KISS-TNC-2ndgen.git
# git clone https://github.com/VanceVagell/RPi-LoRa-KISS-TNC-2ndgen.git
# cd RPi-LoRa-KISS-TNC-2ndgen
# Edit config.py and update the frequency (search for "frequency"). You can/should customize the frequency to anything in the 33cm band (but at least 500kHz from the band edge).
# git clone https://github.com/mayeranalytics/pySX127x.git
# Optional: The default config.py settings are for balanced speed and range. If your connection is strong, you can increase bandwidth up to 500000 (500kHz) which will significantly improve speed. 500kHz is roughly equivalent to 9600 baud, and 62500 is roughly equivalent to 1200 baud. If you need even more distance, you can also increase spreadingFactor above 7 (to say 8 or 9), which will make it transmit more slowly but be received much better. There are other settings in config.py that can affect range and speed as well, but this is a good starting point.
# sudo mv board_config.py pySX127x/SX127x/board_config.py
# sudo mv LoRa.py pySX127x/SX127x//LoRa.py
# Replace config.py with these contents. You can/should customize the frequency to anything in the 33cm band (but at least 500kHz from the band edge):
<nowiki>
## Config file for RPi-LoRa-KISS-TNC 2nd generation
 
## Lora Module selection
sx127x = True #if True, enables sx127x family, else sx126x
 
## Display enable and font
disp_en = False
font_size = 8
 
## Log enable and path
log_enable = True
logpath='/var/log/lora/lora.log' #log filename. Give r/w permission!
 
## KISS Settings
# Where to listen?
# TCP_HOST can be "localhost", "0.0.0.0" or a specific interface address
# TCP_PORT as configured in aprx.conf <interface> section
TCP_HOST = "0.0.0.0"
TCP_PORT = 10001
 
## Hardware Settings
# See datasheets for detailed pinout.
# The default pin assignment refers to PCB designed by I8FUC.
# The user can wire the module by his own and change pin assignment.
# assign "-1" if the pin is not used
 
# Settings valid for both SX126x and SX127x
busId = 0 #SPI Bus ID. Must be enabled on raspberry (sudo raspi-config). Default is 0
csId = 1 #SPI Chip Select pin. Valid values are 0 or 1
irqPin = 22 #DIO0 of sx127x and DIO1 of sx126x, used for IRQ in rx
 
# Settings valid only for SX126x. Default pin assignment refers to the PCB schematic /doc/LoRa_RPi_Companion_2022.pdf
resetPin = 6
busyPin = 4
# If txen and rxen are disabled (=-1), then DIO2 will be set as RF Switch control
txenPin = 0 #In Ebyte modules, it's used for switching on the tx pa.
rxenPin = 1 #In Ebyte modules, it's used for switching on the rx lna
 
# If Lora module has a TCXO, the following parameter must be True
# If True, the DIO3 line will be set as control voltage of the TCXO
tcxo=False
 
## LoRa Settings valid for both SX127x and SX126x modules
frequency = 910300000 #frequency in Hz
preamble = 8 #valid preable length is 8/16/24/32
spreadingFactor = 7 #valid spreading factor is between 7 and 12
bandwidth = 500000 #possible BW values: 7800, 10400,15600, 20800, 31250, 41700, 62500, 125000, 250000, 500000
codingrate = 5 #valid code rate denominator is between 5 and 8
appendSignalReport = False #append signal report when packets are forwarded to aprs server
outputPower = 17 #maximum TX power is 22(22dBm) for SX126x, and 17 (17dBm) for SX127x . Higher values will be forced to max allowed!
TX_OE_Style = False #if True, tx RF packets are in OE Style, otherwise in standard AX25
#sync_word = 0x1424 #sync word is x4y4. Es: 0x12 of 1st gen LoRa chip --> 0x1424 of 2nd gen LoRa chip
sync_word = 0x12
crc = True #defines if CRC is calculated and transmitted in the header. Note that modem works in explicit mode
 
#LoRa Settings valid only for SX126x
RX_GAIN_POWER_SAVING = False #If false, receiver is set in boosted gain mode (needs more power)</nowiki>
 
'''The default settings above are for maximum throughput shorter-range links.''' If you want to go farther (at much slower speeds), try decreasing the bandwidth to 62500 and increasing the spreadingFactor to 8 (this will concentrate more power in a narrower signal, and slightly increase the encoding spread which takes longer to transmit the signal). These are the 2 most important values (bandwidth and spreadingFactor) in terms of throughput and range.


Note that if you're using a ham band other than 33cm you may need to use lower bandwidth settings to adhere to [https://www.ecfr.gov/current/title-47/part-97#p-97.307(f)(6) FCC requirements for spread spectrum transmissions] (<100kHz bandwidth below 33cm). You can use the full 500kHz 33cm and above.
Note that if you're using a ham band other than 33cm you may need to use lower bandwidth settings to adhere to [https://www.ecfr.gov/current/title-47/part-97#p-97.307(f)(6) FCC requirements for spread spectrum transmissions] (<100kHz bandwidth below 33cm). You can use the full 500kHz 33cm and above.


This github project needs more modification to work with TARPN, since it was originally written only for APRS packets and will break with any other kind. It also assumed ~400MHz, whereas the Adafruit bonnet is 33cm (902-928MHz). Here is how to update it (TODO these should be in a forked github project to remove these steps):
Create log placeholders that the library expects to exist:


# nano pySX127x/SX127x/board_config.py '''(Change low_band = True, to False for 33cm support)'''
# nano pySX127x/SX127x/LoRa.py '''(Search for “43” and change multiple occurences to 915MHz)'''
# nano LoraAprsKissTnc_sx127x.py '''(Ditto, there's only 1 occurence in this one)'''
# sudo mkdir /var/log/lora
# sudo mkdir /var/log/lora
# sudo touch /var/log/lora/lora.log
# sudo touch /var/log/lora/lora.log
# Replace KissHelper.py with this contents (this extends it to handle all KISS packets not just APRS, and makes it a little more tolerant of unexpected failures rather than just stopping the process at the first weird packet, and segments too-large packets):
<nowiki>
#!/usr/bin/python3
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.
# Inspired by:
# * Python script to decode AX.25 from KISS frames over a serial TNC
#  https://gist.github.com/mumrah/8fe7597edde50855211e27192cce9f88
#
# * Sending a raw AX.25 frame with Python
#  https://thomask.sdf.org/blog/2018/12/15/sending-raw-ax25-python.html
#
#  KISS-TNC for LoRa radio modem
#  https://github.com/IZ7BOJ/RPi-LoRa-KISS-TNC
import struct
import datetime
import config
KISS_FEND = 0xC0  # Frame start/end marker
KISS_FESC = 0xDB  # Escape character
KISS_TFEND = 0xDC  # If after an escape, means there was an 0xC0 in the source message
KISS_TFESC = 0xDD  # If after an escape, means there was an 0xDB in the source message
def logf(message):
    timestamp = datetime.datetime.now().strftime('%Y/%m/%d %H:%M:%S - ')
    if config.log_enable:
      fileLog = open(config.logpath,"a")
      fileLog.write(timestamp + message+"\n")
      fileLog.close()
    print(timestamp + message)
MAX_SEGMENT_LENGTH = 200 # for segmented packets
segments = []
def encode_kiss_AX25(frame,signalreport): #from Lora to Kiss, Standard AX25
    global segments
    if len(frame) > MAX_SEGMENT_LENGTH + 1:
        logf("Warning: Discarded very long frame, even longer than a segmented frame. Likely corrupted.")
        return
    # If this is a data segment, process it as such.
    if len(frame) >= MAX_SEGMENT_LENGTH + 1 or len(segments) > 0:
        if frame[0:1] == b'0':
            if len(segments) == 0:
                logf("Start of segmented data, caching to recombine.")
            else:
                logf("Continuation of segmented data, adding to cache.")
            segments.append(frame[1:MAX_SEGMENT_LENGTH + 1])
            return
        elif frame[0:1] == b'1':
            if len(segments) == 0:
                logf("Warning, corrupt segmentation, received end segment with no prior segments. Discarding.")
                segments = []
                return
            else:
                logf("End of segmented data, adding to cache and returning complete packet via KISS.")
                segments.append(frame[1:])
                frame = bytearray()
                for segment in segments:
                    for b in segment:
                        frame.append(b)
                segments = []
    packet_escaped = []
    for x in frame:
        if x == KISS_FEND:
            packet_escaped += [KISS_FESC, KISS_TFEND]
        elif x == KISS_FESC:
            packet_escaped += [KISS_FESC, KISS_TFESC]
        else:
            packet_escaped += [x]
    kiss_cmd = 0x00  # Two nybbles combined - TNC 0, command 0 (send data)
    kiss_frame = [KISS_FEND, kiss_cmd] + packet_escaped + [KISS_FEND]
    try:
        output = bytearray(kiss_frame)
    except ValueError:
        logf("Invalid value in frame.")
        return None
    return output
def decode_kiss_AX25(frame): #from kiss to LoRA, Standard AX25
    result = b""
    if frame[0] != 0xC0 or frame[len(frame) - 1] != 0xC0:
        logf("Kiss Header not found, abort decoding of Frame: "+repr(frame))
        return None
    frame=frame[2:len(frame) - 1] #cut kiss delimitator 0xc0 and command 0x00
    return frame
class SerialParser():
    '''Simple parser for KISS frames. It handles multiple frames in one packet
    and calls the callback function on each frame'''
    STATE_IDLE = 0
    STATE_FEND = 1
    STATE_DATA = 2
    KISS_FEND = KISS_FEND
    def __init__(self, frame_cb=None):
        self.frame_cb = frame_cb
        self.reset()
    def reset(self):
        self.state = self.STATE_IDLE
        self.cur_frame = bytearray()
    def parse(self, data):
        try:
            for c in data:
                if self.state == self.STATE_IDLE:
                    if c == self.KISS_FEND:
                        self.cur_frame.append(c)
                        self.state = self.STATE_FEND
                elif self.state == self.STATE_FEND:
                    if c == self.KISS_FEND:
                        self.reset()
                    else:
                        self.cur_frame.append(c)
                        self.state = self.STATE_DATA
                elif self.state == self.STATE_DATA:
                    self.cur_frame.append(c)
                    if c == self.KISS_FEND:
                        # frame complete
                        if self.frame_cb:
                            self.frame_cb(self.cur_frame)
                        self.reset()
        except Exception as e:
            logf("Exception in SerialParser.parse(), callback NOT called.")
            logf(str(e))
</nowiki>


Start/test your TCP-based KISS TNC with this command (you should see it print out the config values and say it's listening for connections, with no errors listed):
Start/test your TCP-based KISS TNC with this command (you should see it print out the config values and say it's listening for connections, with no errors listed):
Line 348: Line 140:
#Lora parameters:
#Lora parameters:
frequency= 910300000
frequency= 910300000
preamble= 32
preamble= 8
spreadingFactor= 7
spreadingFactor= 7
bandwidth= 500000
bandwidth= 500000
codingrate= 5
codingrate= 5
APPEND_SIGNAL_REPORT= False
APPEND_SIGNAL_REPORT= False
outputPower= 17
outputPower= 15
TX_OE_Style= False
TX_OE_Style= False
sync_word= 0x12
sync_word= 0x12
Line 360: Line 152:
2023/08/15 00:27:18 - KISS-Server: Started. Listening on IP 0.0.0.0 Port: 10001
2023/08/15 00:27:18 - KISS-Server: Started. Listening on IP 0.0.0.0 Port: 10001


2023/08/15 00:27:18 - LoRa radio initialized. Waiting for LoRa Spots...
2023/08/15 00:27:18 - LoRa radio initialized. Waiting for LoRa Spots...</nowiki>
</nowiki>


When you run the TNC for long-term use, you'll want to run it with "nohup sudo python3 Start_lora-tnc.py &" which will disassociate it with your linux account and run it in the background until manually terminated. In the future, we should wrap this in a systemd service, or you can start it in crontab.
You'll want this to start every time the LoRa pi reboots, so follow these steps (TODO replace this crontab approach with systemd):
# sudo crontab -e (If you've never used crontab it will ask you to select you preferred text editor, I use nano)
# Paste this line at the end of the crontab file, and save:
<nowiki>
@reboot /usr/bin/python3 /home/pi/RPi-LoRa-KISS-TNC-2ndgen/Start_lora-tnc.py &</nowiki>


=== TARPN configuration ===
=== TARPN configuration ===
Line 377: Line 172:
while true
while true
     do
     do
       sudo socat pty,link=/dev/ttyS0,b115200,raw,echo=0,mode=777 tcp:192.168.1.90:10001,forever,interval=10
       sudo socat -T 600 pty,link=/dev/ttyS0,b115200,raw,nonblock,echo=0,mode=777,wait-slave tcp:192.168.1.90:10001
       printf "LoRa port /dev/ttyS0 disconnected, waiting 1 second and bringing it up again.\n"
       printf "LoRa port /dev/ttyS0 disconnected, waiting 1 second and bringing it up again.\n"
       sleep 1
       sleep 1
     done
     done</nowiki>
</nowiki>


* Start the fake serial device with "./lora-port-up.sh &" and it will show up as /dev/ttyS0 like a serial TNC would be. (You might want to do this in crontab or something, so it always runs on node restart.)
* chmod +x lora-port-up.sh
* Start the fake serial device with "./lora-port-up.sh &" and it will show up as /dev/ttyS0 like a serial TNC would.
 
You'll want this LoRa virtual device to appear on device reboot, you can do this with crontab (TODO replace this crontab approach with systemd):
# crontab -e (If you've never used crontab it will ask you to select you preferred text editor, I use nano)
# Paste this line at the end of the crontab file, and save:
<nowiki>
@reboot nohup /home/pi/lora-port-up.sh &</nowiki>


Then you can edit your TARPN node.ini to configure port 11 as follows:
Then you can edit your TARPN node.ini to configure port 11 as follows:
Line 394: Line 195:
frack11:2000
frack11:2000
kissoptions11:disable
kissoptions11:disable
neighbor11:KV4P-3
neighbor11:KV4P-3</nowiki>
</nowiki>


Of course, assign "neighbor11" to the callsign/ssid of the node you plan to connect to via LoRa on your new port 11.
Of course, assign "neighbor11" to the callsign/ssid of the node you plan to connect to via LoRa on your new port 11.


=== Performance ===
=== Performance ===
With the above config.py settings, a throughput test on my own TARPN node with a "bench setup" (2 LoRa transceivers right next to each other), I achieved 135bytes/sec. That's about as good as a very solid 9600 baud link with a NinoTNC and high quality mobile radios.
==== 915MHz LoRa, bench test ====
With 500kHz bandwidth and spreadingFactor of 7 in config.py, a throughput test on my own TARPN node with a "bench setup" (2 LoRa transceivers right next to each other), I achieved 135bytes/sec. That's about as good as a very solid 9600 baud link with a NinoTNC and high quality mobile radios.
 
Both LoRa nodes used a 1/4 wave vertical antenna made of magnet wire (no counterpoise or ground plane).
 
==== 915MHz LoRa, quarter mile ====
With 62.5kHz bandwidth, spreadingFactor of 8, and coding of 6, the module worked very well at a distance of about 1/4 mile. I live in a valley, and put one LoRa transceiver in my attic (3rd floor) and I tested it from a nearby hill. That worked well. I also walked down a flat road that's level with my house (no intervening hills) and that also worked well. I did not do a throughput test, but at these settings it's roughly equivalent to a 1200 baud typical TNC link.
 
Both LoRa nodes used a 1/4 wave vertical antenna made of magnet wire (no counterpoise or ground plane).
 
==== 915MHz LoRa, transceiver 60' up a tree ====
[[File:PXL 20230915 204140878.MP.jpg|alt=LoRa "port" enclosed in a waterproof project box with a homebrew groundplane antenna.|thumb|LoRa "port" enclosed in a waterproof project box with a homebrew groundplane antenna.]]
 
For the next test, I put the LoRa + pi "port" about 60 feet up in a tree, with a homebrew groundplane antenna instead of the quarter wave vertical (i.e. piece of wire). The idea was to give the test a better chance at success. I also added a [https://www.amazon.com/dp/B095JTW6XM 5dBi rubber duck antenna] to my portable TARPN node's LoRa port, so it was a little better than the piece of wire as well.
 
Observations:
* I ran my first set of tests at 64.5kHz bandwidth and 8 spreadingFactor.
* My house is surrounded by hills on most sides (I live in a valley), and I could not get any signal to the south, southwest, or southeast. I tried many different spots, from about 2 miles away, all the way down to about a half mile down the road. None worked, no packets received.
* On a lark, I also tried 500kHz bandwidth and 7 spreadingFactor. This did not help, which was not surprising since the same power was more spread out.
* I was FINALLY able to get packets to arrive when I was 1/3 mile north of my house. There are no hills to the north of my house.
 
Overall, 33cm is clearly heavily blocked by hills (all VHF and UHF is to some extent, but 33cm is clearly far more sensitive than either 2m or 70cm to hills, I have other TARPN links on those bands that work OK for several miles).
 
==== 915MHz LoRa, transceiver 60' up a tree, avoiding hills ====
 
In the next test, I drove north / northeast from my house, where there are no hills higher than my house's elevation. I drove to one location at 1.5 miles, and another at 4 miles.
 
Unfortunately, neither of these locations could receive the 33cm LoRa signal (8 spreadingFactor, 62.5kHz bandwidth, 6 coding rate). In fact, the only location I've been able to receive the signal (other than literally at my home QTH) is 1/3 mile straight north. This tells me two things:


It can probably be made to go much faster with additional optimization. It's unclear if the KISS service running in Python represents a cap on the throughput, or if it's just the settings.
# Trees / forest likely attenuate 33cm signals fairly strongly, since other locations within ~1/3 mile of my home QTH did not work
# Hills are a complete no-go for 33cm signals


Although the distance of this link hasn't been tested yet, the LoRa module claims to work between 4km and 40km (from city to perfectly flat ideal conditions). 33cm has the nice property of easily going through windows and walls, so it should be especially good for suburban links, or between nodes with a fairly clear shot.
So a LoRa link for TARPN could be an excellent inexpensive option if you live in a flat area and/or have a clear line-of-site to your nearest TARPN neighbor. For example, I'd expect it to work pretty well in a suburban housing district without hills, letting neighbors link up. Or if you're in a part of the US that just isn't very hilly (e.g. farmland area). Where I live is hills everywhere, and I'm in a valley!

Latest revision as of 18:31, 24 September 2023

A complete TARPN 1-port node using LoRa. The smaller device is the LoRa KISS TNC Transceiver, and the larger Raspberry Pi is the TARPN node. It requires about 1.5 watts to run, just plug it into a USB power source.

KV4P has been experimenting with adding LoRa ports to his TARPN node. LoRa is very desirable for TARPN because LoRa transceivers are very inexpensive yet have good range, are very small and low-power, and reduce the overall setup cost of a new link.

Materials:

This assumes you already have a TARPN node. With this experimental guide, you'll be building a LoRa radio that shows up on your network as a TCP-based KISS TNC, which we'll wrap in a virtual serial port so TARPN ports 11 or 12 can be configured to access it like a normal TNC.

I'm going to assume you already have the Raspberry Pi configured with Raspberry Pi OS, and connected to your local network (the same network as your TARPN node). You'll want to assign a static IP to it (rather than DHCP), so you can ensure your TARPN node will be able to find it on the network after restarts.

A few notes:

  • This has only been tested with the "Lite" Raspberry Pi OS image, not either of the "with desktop" images. They might work, but have not been tested.
  • This definitely does not work on a Pi that has TARPN installed. Something in the TARPN setup script is incompatible with the LoRa bonnet. We may be able to fix this in the future, but it would require significant debugging to figure out what TARPN setup step breaks the LoRa bonnet functionality.

Get LoRa bonnet working

You can read more about these steps on this Adafruit page.

  1. sudo apt install python3-pip
  2. sudo pip3 install --upgrade setuptools
  3. sudo pip3 install --upgrade adafruit-python-shell
  4. wget https://github.com/adafruit/Adafruit_CircuitPython_framebuf/raw/main/examples/font5x8.bin
  5. wget https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/raspi-blinka.py
  6. sudo python3 raspi-blinka.py (this will require reboot at the end)
  7. sudo pip3 install adafruit-circuitpython-ssd1306
  8. sudo pip3 install adafruit-circuitpython-framebuf
  9. sudo pip3 install adafruit-circuitpython-rfm9x
  10. create this test script rfm9x_check.py, which you should run ("python3 rfm9x_check.py") to prove your bonnet is properly connected and working:
# SPDX-FileCopyrightText: 2018 Brent Rubell for Adafruit Industries
#
# SPDX-License-Identifier: MIT

"""
Wiring Check, Pi Radio w/RFM9x

Learn Guide: https://learn.adafruit.com/lora-and-lorawan-for-raspberry-pi
Author: Brent Rubell for Adafruit Industries
"""
import time
import busio
from digitalio import DigitalInOut, Direction, Pull
import board
# Import the SSD1306 module.
import adafruit_ssd1306
# Import the RFM9x radio module.
import adafruit_rfm9x

# Button A
btnA = DigitalInOut(board.D5)
btnA.direction = Direction.INPUT
btnA.pull = Pull.UP

# Button B
btnB = DigitalInOut(board.D6)
btnB.direction = Direction.INPUT
btnB.pull = Pull.UP

# Button C
btnC = DigitalInOut(board.D12)
btnC.direction = Direction.INPUT
btnC.pull = Pull.UP

# Create the I2C interface.
i2c = busio.I2C(board.SCL, board.SDA)

# 128x32 OLED Display
reset_pin = DigitalInOut(board.D4)
display = adafruit_ssd1306.SSD1306_I2C(128, 32, i2c, reset=reset_pin)
# Clear the display.
display.fill(0)
display.show()
width = display.width
height = display.height

# Configure RFM9x LoRa Radio
CS = DigitalInOut(board.CE1)
RESET = DigitalInOut(board.D25)
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)

while True:
    # Clear the image
    display.fill(0)

    # Attempt to set up the RFM9x Module
    try:
        rfm9x = adafruit_rfm9x.RFM9x(spi, CS, RESET, 915.0)
        display.text('RFM9x: Detected', 0, 0, 1)
    except RuntimeError as error:
        # Thrown on version mismatch
        display.text('RFM9x: ERROR', 0, 0, 1)
        print('RFM9x Error: ', error)

    # Check buttons
    if not btnA.value:
        # Button A Pressed
        display.text('Ada', width-85, height-7, 1)
        display.show()
        time.sleep(0.1)
    if not btnB.value:
        # Button B Pressed
        display.text('Fruit', width-75, height-7, 1)
        display.show()
        time.sleep(0.1)
    if not btnC.value:
        # Button C Pressed
        display.text('Radio', width-65, height-7, 1)
        display.show()
        time.sleep(0.1)

    display.show()
    time.sleep(0.1)

Turn it into a TCP KISS TNC

See the original github project this is forked from for more info.

  1. sudo apt install git aprx python3-rpi.gpio python3-spidev python3-pil python3-smbus
  2. git clone https://github.com/VanceVagell/RPi-LoRa-KISS-TNC-2ndgen.git
  3. Edit config.py and update the frequency (search for "frequency"). You can/should customize the frequency to anything in the 33cm band (but at least 500kHz from the band edge).
  4. Optional: The default config.py settings are for balanced speed and range. If your connection is strong, you can increase bandwidth up to 500000 (500kHz) which will significantly improve speed. 500kHz is roughly equivalent to 9600 baud, and 62500 is roughly equivalent to 1200 baud. If you need even more distance, you can also increase spreadingFactor above 7 (to say 8 or 9), which will make it transmit more slowly but be received much better. There are other settings in config.py that can affect range and speed as well, but this is a good starting point.

Note that if you're using a ham band other than 33cm you may need to use lower bandwidth settings to adhere to FCC requirements for spread spectrum transmissions (<100kHz bandwidth below 33cm). You can use the full 500kHz 33cm and above.

Create log placeholders that the library expects to exist:

  1. sudo mkdir /var/log/lora
  2. sudo touch /var/log/lora/lora.log

Start/test your TCP-based KISS TNC with this command (you should see it print out the config values and say it's listening for connections, with no errors listed):

  • sudo python3 Start_lora-tnc.py

This is what you should see:

########################
#LORA KISS TNC STARTING#
########################
#Lora parameters:
frequency= 910300000
preamble= 8
spreadingFactor= 7
bandwidth= 500000
codingrate= 5
APPEND_SIGNAL_REPORT= False
outputPower= 15
TX_OE_Style= False
sync_word= 0x12
crc= True
########################
2023/08/15 00:27:18 - KISS-Server: Started. Listening on IP 0.0.0.0 Port: 10001

2023/08/15 00:27:18 - LoRa radio initialized. Waiting for LoRa Spots...

You'll want this to start every time the LoRa pi reboots, so follow these steps (TODO replace this crontab approach with systemd):

  1. sudo crontab -e (If you've never used crontab it will ask you to select you preferred text editor, I use nano)
  2. Paste this line at the end of the crontab file, and save:
@reboot /usr/bin/python3 /home/pi/RPi-LoRa-KISS-TNC-2ndgen/Start_lora-tnc.py &

TARPN configuration

TARPN only supports serial TNCs, so first we need to "fake" a serial TNC that actually connects to our TCP-bsaed LoRa KISS TNC using the "socat" command.

  • sudo apt install socat
  • sudo nano lora-port-up.sh
  • Use these contents but replace the IP address to your LoRa KISS TNC's address:
#!/bin/bash
printf "Bringing up LoRa port as /dev/ttyS0\n"
while true
    do
      sudo socat -T 600 pty,link=/dev/ttyS0,b115200,raw,nonblock,echo=0,mode=777,wait-slave tcp:192.168.1.90:10001
      printf "LoRa port /dev/ttyS0 disconnected, waiting 1 second and bringing it up again.\n"
      sleep 1
    done
  • chmod +x lora-port-up.sh
  • Start the fake serial device with "./lora-port-up.sh &" and it will show up as /dev/ttyS0 like a serial TNC would.

You'll want this LoRa virtual device to appear on device reboot, you can do this with crontab (TODO replace this crontab approach with systemd):

  1. crontab -e (If you've never used crontab it will ask you to select you preferred text editor, I use nano)
  2. Paste this line at the end of the crontab file, and save:
@reboot nohup /home/pi/lora-port-up.sh &

Then you can edit your TARPN node.ini to configure port 11 as follows:

usb-port11:ENABLE
portdev11:/dev/ttyS0
speed11:115200
txdelay11:1
frack11:2000
kissoptions11:disable
neighbor11:KV4P-3

Of course, assign "neighbor11" to the callsign/ssid of the node you plan to connect to via LoRa on your new port 11.

Performance

915MHz LoRa, bench test

With 500kHz bandwidth and spreadingFactor of 7 in config.py, a throughput test on my own TARPN node with a "bench setup" (2 LoRa transceivers right next to each other), I achieved 135bytes/sec. That's about as good as a very solid 9600 baud link with a NinoTNC and high quality mobile radios.

Both LoRa nodes used a 1/4 wave vertical antenna made of magnet wire (no counterpoise or ground plane).

915MHz LoRa, quarter mile

With 62.5kHz bandwidth, spreadingFactor of 8, and coding of 6, the module worked very well at a distance of about 1/4 mile. I live in a valley, and put one LoRa transceiver in my attic (3rd floor) and I tested it from a nearby hill. That worked well. I also walked down a flat road that's level with my house (no intervening hills) and that also worked well. I did not do a throughput test, but at these settings it's roughly equivalent to a 1200 baud typical TNC link.

Both LoRa nodes used a 1/4 wave vertical antenna made of magnet wire (no counterpoise or ground plane).

915MHz LoRa, transceiver 60' up a tree

LoRa "port" enclosed in a waterproof project box with a homebrew groundplane antenna.
LoRa "port" enclosed in a waterproof project box with a homebrew groundplane antenna.

For the next test, I put the LoRa + pi "port" about 60 feet up in a tree, with a homebrew groundplane antenna instead of the quarter wave vertical (i.e. piece of wire). The idea was to give the test a better chance at success. I also added a 5dBi rubber duck antenna to my portable TARPN node's LoRa port, so it was a little better than the piece of wire as well.

Observations:

  • I ran my first set of tests at 64.5kHz bandwidth and 8 spreadingFactor.
  • My house is surrounded by hills on most sides (I live in a valley), and I could not get any signal to the south, southwest, or southeast. I tried many different spots, from about 2 miles away, all the way down to about a half mile down the road. None worked, no packets received.
  • On a lark, I also tried 500kHz bandwidth and 7 spreadingFactor. This did not help, which was not surprising since the same power was more spread out.
  • I was FINALLY able to get packets to arrive when I was 1/3 mile north of my house. There are no hills to the north of my house.

Overall, 33cm is clearly heavily blocked by hills (all VHF and UHF is to some extent, but 33cm is clearly far more sensitive than either 2m or 70cm to hills, I have other TARPN links on those bands that work OK for several miles).

915MHz LoRa, transceiver 60' up a tree, avoiding hills

In the next test, I drove north / northeast from my house, where there are no hills higher than my house's elevation. I drove to one location at 1.5 miles, and another at 4 miles.

Unfortunately, neither of these locations could receive the 33cm LoRa signal (8 spreadingFactor, 62.5kHz bandwidth, 6 coding rate). In fact, the only location I've been able to receive the signal (other than literally at my home QTH) is 1/3 mile straight north. This tells me two things:

  1. Trees / forest likely attenuate 33cm signals fairly strongly, since other locations within ~1/3 mile of my home QTH did not work
  2. Hills are a complete no-go for 33cm signals

So a LoRa link for TARPN could be an excellent inexpensive option if you live in a flat area and/or have a clear line-of-site to your nearest TARPN neighbor. For example, I'd expect it to work pretty well in a suburban housing district without hills, letting neighbors link up. Or if you're in a part of the US that just isn't very hilly (e.g. farmland area). Where I live is hills everywhere, and I'm in a valley!