AmateurfunkRaspberry Pi

Pi-in-the-Sky IV: LoRa Tracker und Gateway

Posted wp_blogadmin

LoRa und LoRa Module im allgemeinen

Die Übertragungstechnik LoRa ist noch relativ neu; es gibt noch nicht sehr viele Erfahrungen durch Amatuerfunker (es ist kein „Dienst“ des Amateurfunks im rechtlichen Sinne, sondern konzessionsfrei nutzbar). Die eigentliche Technik steckt in einem Chip von Semtech (wie Sx1272/Sx1276) , dem Patentinhaber. Von HopeRF gibt es (ein lizenzierter Nachbau?) den Chip RFM96W, der auf verschiedenen Modulen enthalten ist – mit Namen wie RFM95/RFM98W. Diese Module unterscheiden sich nur in der Frequenz aufgrund der externen Beschaltung auf dem 16×16 mm Modul, der Chip ist überall der gleiche.

rfm95modul

Die meisten LoRa-Module senden mit 10mW (einstellbar im Chip) in Frequenzbändern um 434 MHz, 868 MHz oder 915 MHz. Es gibt viele Breakout Boards für diese Module mit unterschiedlich luxuriösem Drum-Herum, z.B. die Adafruit Featherwing Radio Module mit Mikrocontroller, USB Anschluss und Lora Modul inkl. SMA Lötanschluss.

In den Schweizer Shops habe ich bisher nur die 868 MHz Modelle gesehen. Vom Pi-in-the-Sky Liferanten habe ich ebenfalls die 868 MHz Platine gekauft. Für Funkamateure sind evtl. die 434 MHz Module interessanter, da sie auch im lizenzierten UHF Band senden könn(t)en.

Die Module enthalten alle Teile eines Senders und Empfängers vom Antenneneingang bis zur digitalen Ausgabe der Daten. Dies reduziert die Kosten ganz erheblich.

 

Rechtliches

Für die lizenzfreie Nutzung von LoRa sind einige rechtliche Rahmenbedingungen zu beachten. Es bestehen Einschränkungen

  • bezüglich der Frequenzlage: genau definierte Bänder
  • bezüglich der Leistung, in der Regel 10 mW oder 25 mW
  • bezüglich der Sendedauer (Duty Cycle): meistens nur 10% oder 1%

Eine solche Zusammenstellung ist in Arbeit.

 

LoRa Module speziell für Ballonmissionen

Die LoRa Funktechnik hat sich offenbar für Ballonflüge bewährt.

  • Gegenüber reinem RTTY bietet sie vor allem eine sehr viel höhere Empfindlichkeit, sodass LoRa Pakete noch weit unter dem Minimalpegel für RTTY empfangen werden können.
  • Ein weiterer Vorteil ist die einfache und flexible Konfigurierbarkeit für Fehlerkorrektur, Bandbreite und Spreading Factor. So lässt sich das System einfach auf die vorliegenden Daten anpassen – wichtige aber kleine Daten wie die Koordinaten zuverlässig übertragen, grosse, aber optionale Daten wie Bilder schnell aber weniger zuverlässig.
  • Weiterhin ist die LoRa Modulation relativ unempfindlich auf Frequenzverschiebungen, wie sie bei grossen Temperaturunterschieden (Quarze!) und Dopplereffekten auftreten. Laut Datenblatt soll LoRa Frequenzabweichungen bis 20%  der gewählten Bandbreite selber erkennen und korrigieren können.

Die erreichten Distanzen gehen offenbar bis 400km und mehr (Beispiel Report) ohne speziell aufwendige Empfangstationen. Grundsätzlich ist eine Sichtverbindung nötig (LOS, Line of sight). In grosser Höhe limitiert die Erdkrümmung die maximal mögliche Distanz (der sog. Radiohorizont->Wikipedia). Als Beispiel beträgt der Radiohorizont in 22km Höhe ca. 600 km.

Grundsätzlich unterliegt die Aussendung einem Pfadverlust resp. im Vakuum der Freiraumdämpfung (-> Wikipedia).

 

LoRa Tracker mit PITS

Ein Lora System mit dem PTS (Payload und Gateway Paar) ist eigentlich schnell gebaut. Das nötige findet man

  • im Manual vom PITS (Schluss) und auf der PITS Homepage
  • im Source Code auf Github
  • und im Blog von Dave Akermann („Making a LoRa Gateway“)

Nach der SW Installation gab ich dem Gateway eine statische Adresse, was etwas mühsam, siehe https://www.elektronik-kompendium.de/sites/raspberry-pi/1912151.htm.

Beim physischen Zusammenbau sollte man sorgfältig vorgehen. Mein Lora Shield war etwas durchgebogen und die aufgelötete Buchsenleiste mechanisch nicht solide befestigt. Durch das Aufstecken auf den PI wurde die Buchsenleiste hochgehoben und die Kontakte offenbar gelöst. Von aussen war das nach dem Zusammenbau nicht mehr sichtbar. Der Sender sendete einfach nichts und manchmal ein RTTY-ähnliches Signal. Nach einigem Haareraufen fand ich den Fehler und lötete die Buchsenleiste nochmal neu auf.

  • Tip: im Betrieb sollten mind. die LAN und eine der Data LEDs leuchten, beim Gateway mit Internet Anbindung auch die Internet LED
  • Die Data LEDs sind vertauscht (die dienen nur zur Information)

lora-gateway-aufbau2

Meine Minimal-Konfiguration für die Payload ist nur dies (Mode_1=1 für langsame SSDV Bildübertragung, Mode_1=3 ist schon sehr schnell):

LORA_Frequency_1=868.500
LORA_Payload_1=pi9tss
LORA_Mode_1=1

Auf der Frequenz 868.500 MHz darf mit 25mW und 1% Duty Cycle gesendet werden (36 Sekunden pro Stunde), nicht ideal. Für spätere Experimente werde ich in den Bereich 869.700 – 870 MHz wechseln bei 5 mW ohne Duty Cycle Restriktion.

Auf dem Gateway legen wir den Standort des Gateways fest (=Vehicle/Tracker im habhub)

##### Your details #####
tracker=HB9TSS
Latitude=46.600
Longitude=7.600
Antenna=(lab setup)

und die globalen Optionen (für Testzwecke EnableHabitat=N, damit nicht Testdatein nicht in habhub geschickt werden)

##### Config Options #####
EnableHabitat=N
EnableSSDV=Y
JPGFolder=ssdv
LogTelemetry=Y
LogPackets=Y
CallingTimeout=60
ServerPort=6004
#SMSFolder=./
EnableDev=N

und dann Frequenz, Modus und die AFC:

Config CE1 #####
frequency_1=868.500
mode_1=1
AFC_1=Y

Der Modus 1 ist im Code definiert:

IMPLICIT_MODE, ERROR_CODING_4_5, BANDWIDTH_20K8, SPREADING_6,  0,  1400, "SSDV"

Es stellte sich heraus, dass die Frequenz um 5 KHz daneben liegt. Es war kein Empfang bei 868.500 MHz möglich und die AFC korrgierte die Frequent automatisch auf 868.496 MHz herunter. Sobald man mit der Taste Shift-D die Frequenz auf 868.501 MHz  korrigierte, griff die AFC wieder und fand auf 868.505 MHz das Signal.

lora-gateway-mode1-ssdv

In SDRsharp sieht ein Mode 0 Signal so aus (man muss den Input Gain im SDRsharp von 30-35dB bei RTTY auf ca 5-10dB herunternehmen). Hier ein Video LoRa Empfang.

lora-sdr-mode0

Der Upload der Daten (Kordinaten, Telemetrie und Bilder) ins habitat erfolgt, sobald EnableHabitat=Y gesetzt wird. Zum Beweis hier die Bilder:

lora-habmap

lora-ssdv-hub

Definition der Telemetrie

Wenn man unter dem Namen der Payload die Telemetrie mit einem payload document definiert hat, werden die Daten auch richtig beschriftet und interpretiert (siehe frühere Blogs). Dabei sollte man aber sicherstellen, dass auf den 3 Funk“wegen“ RTTY, APRS und LoRa auch die genau gleich formatierten Daten geschickt werden, wenn man sie simultan ensetzt.

Man sieht oben im Bild den empfangenen String ohne die Daten des BME280 Sensors (nach der internen Temperatur 32.9, der internen Spannung 4.1 und dem Strom 0.175 kommt nichts mehr). Man muss also wie beim APRS oder RTTY im Code (lora.c) die Telemetrie noch erweitern. Hier die massgebliche Stelle:

 if ((Config.BuoyModeAltitude > 0) && (GPS->Altitude < Config.BuoyModeAltitude))
 {
 sprintf((char *)TxLine, "$$%s,%d,%s,%7.5lf,%7.5lf",
 Config.Channels[LORA_CHANNEL+LoRaChannel].PayloadID,
 Config.Channels[LORA_CHANNEL+LoRaChannel].SentenceCounter,
 TimeBuffer,
 GPS->Latitude,
 GPS->Longitude);
 }
 else
 {
 sprintf((char *)TxLine, "$$%s,%d,%s,%7.5lf,%7.5lf,%5.5" PRId32 ",%d,%d,%d,%3.1f%s%s%s%s%s%s%s",
 Config.Channels[LORA_CHANNEL+LoRaChannel].PayloadID,
 Config.Channels[LORA_CHANNEL+LoRaChannel].SentenceCounter,
 TimeBuffer,
 GPS->Latitude,
 GPS->Longitude,
 GPS->Altitude,
 (GPS->Speed * 13) / 7,
 GPS->Direction,
 GPS->Satellites,
 GPS->DS18B20Temperature[1-Config.ExternalDS18B20],
 ExtraFields1,
 ExtraFields2,
 ExtraFields3,
 ExtraFields4,
 ExternalFields,
 ExtraFields5,
 ExtraFields6);
 }

Die Felder werden kurz davor abgefüllt:

if ((Config.BoardType == 3) || (Config.DisableADC))
 {
 }
 else if (Config.BoardType == 0)
 {
 sprintf(ExtraFields1, ",%.3f", GPS->BatteryVoltage);
 }
 else
 {
 sprintf(ExtraFields1, ",%.1f,%.3f", GPS->BatteryVoltage, GPS->BoardCurrent);
 }
 
 if (Config.EnableBMP085)
 {
 sprintf(ExtraFields2, ",%.1f,%.0f", GPS->BMP180Temperature, GPS->Pressure);
 }
 
 if (GPS->DS18B20Count > 1)
 {
 sprintf(ExtraFields3, ",%3.1f", GPS->DS18B20Temperature[Config.ExternalDS18B20]);
 }
 
 if (Config.EnableLandingPrediction && (Config.PredictionID[0] == '\0'))
 { 
 sprintf(ExtraFields4, ",%7.5lf,%7.5lf", GPS->PredictedLatitude, GPS->PredictedLongitude);
 }
 
 if (Config.LoRaDevices[LoRaChannel].EnableRSSIStatus)
 { 
 sprintf(ExtraFields5, ",%d,%d,%d", Config.LoRaDevices[LoRaChannel].LastPacketRSSI,
 Config.LoRaDevices[LoRaChannel].LastPacketSNR,
 Config.LoRaDevices[LoRaChannel].PacketCount);
 }
if (Config.LoRaDevices[LoRaChannel].EnableMessageStatus)
 { 
 sprintf(ExtraFields6, ",%d,%d", Config.LoRaDevices[LoRaChannel].LastMessageNumber, Config.LoRaDevices[LoRaChannel].MessageCount);
 }

Als erste Anpassung geben wir die Batteriespannung auch 3-stellig aus:

sprintf(ExtraFields1, ",%.3f,%.3f", GPS->BatteryVoltage, GPS->BoardCurrent);

und dann übernehme ich 1:1 den angepassten Code aus tracker.c (RTTY Telemetrie). Man beachte, dass die gleichzeitige Verwendung von einem BMP180 und einem BME280 in diesem Code nicht vorgesehen ist. Es macht auch wenig Sinn.

 if (Config.EnableBMP085)
 {
  sprintf(ExtraFields2, ",%.1f,%.0f", GPS->BMP180Temperature, GPS->Pressure);
 }
  if (Config.EnableBME280)
 {
  sprintf(ExtraFields2, ",%.1f,%.0f,%.1f", GPS->BMP180Temperature, GPS->Pressure, GPS->Humidity);
 }

Damit sind die Extrafields zwischen RTTY/APRS und LoRa angeglichen, soweit es die entsprechenden Felder gibt. Hier die vom Lora Gateway empfangenen Pakete:

16:10:59 Ch1: $$pi9tss,2,00:00:00,0.00000,0.00000,00000,0,0,0,28.4,4.127,0.000,20.8,960,50.6*0CF7
16:11:00 Ch1: $$pi9tss,3,00:00:00,0.00000,0.00000,00000,0,0,0,28.4,4.127,0.175,20.8,960,50.6*21DD

Noch zu tun: Kontrolle des Codes beim LoRa Gateway Empfänger (gateway.c) resp. Kontrolle der Daten im habhub.

 

Export der Telemetrie aus dem Habhub

Die von den Empfangsstationen zusammengetragenen Telemetriedaten lassen sich aus dem habhub exportieren, z.B. in ein CSV (raw data und alle erkannten Einzelfelder). Diese Daten wurden mit RTTY übertragen.

"$$PI9TSS,120,20:19:22,46.69093,7.67960,00764,0,0,0,28.2,4.1,0.175,21.6,960,54.9*A045",HB9TSS,120,20:19:22,46.69093,7.6796,764,0.0,0,0,28.2,4.1,0.175,21.6,960.0,54.9
"$$PI9TSS,127,20:21:52,46.69094,7.68000,00744,0,0,6,28.1,4.1,0.175,21.6,960,54.6*BAAB",HB9TSS,127,20:21:52,46.69094,7.68,744,0.0,0,6,28.1,4.1,0.175,21.6,960.0,54.6
"$$PI9TSS,128,20:22:05,46.69095,7.68021,00728,0,0,5,28.1,4.1,0.175,21.6,960,55.0*C2E8",HB9TSS,128,20:22:05,46.69095,7.68021,728,0.0,0,5,28.1,4.1,0.175,21.6,960.0,55.0

 

Berechnung der Frequenz

Die Frequenzberechnung ergibt sich aus der Formel im Datenblatt:

F (24bit Zahl im Register) = (f_RF x 2^19) / F(OSC) = f_RF/(868 x 10^6) x 10^6 x 868 x 2^19 / (32 x 10^6)

F (24bit Zahl im Register) = (868/32)  x 2^19 = 14221312 = 2 x 7110656

Im Code gateway.c steht dementsprechend (f (in MHz) * 7110656 ) / 434.

 

Die Leistung

In lora.h werden die Konstanten für die Ausgangsleistung festgelegt:

// POWER AMPLIFIER CONFIG
#define REG_PA_CONFIG               0x09
#define PA_MAX_BOOST                0x8F
#define PA_LOW_BOOST                0x81
#define PA_MED_BOOST                0x8A
#define PA_MAX_UK                   0x88
#define PA_OFF_BOOST                0x00
#define RFO_MIN                     0x00

In lora.c wird der Wert PA_MAX_UK als Integer in das Register REG_PA_CONFIG = 0x09 geschrieben. Der Wert 0x88 = 136 dezimal ist binär  10001000.

  • Bit 7 ist gesetzt: 1 -> PA_BOOST pin. Maximum power of +20 dBm
  • Bits 6-4 definieren MaxPower =0. Damit wird Pmax=10.8+0.6*MaxPower = 10.8 [dBm], dies wird aber nicht weiter vewendet.
  • Bits 3-0 definieren OutputPower = 8. Damit ergibt sich Pout = 2 + OutputPower = 10 [Bbm]

Für 25 mW = 14 dBm müsste man 1000’1010 = 138 = 0x8A setzen (PA_MED_BOOST).

    case RF98_MODE_TX:
      writeRegister(LoRaChannel, REG_LNA, LNA_OFF_GAIN);  // TURN LNA OFF FOR TRANSMITT
      writeRegister(LoRaChannel, REG_PA_CONFIG, Config.LoRaDevices[LoRaChannel].Power);
      writeRegister(LoRaChannel, REG_OPMODE, newMode);
      currentMode = newMode; 
      break;

 

 Offene Punkte

Fragen blieben bei diesem ersten Experiment noch offen:

  • wie ist eine Korrektur der Frequenz möglich? Gibt es eine Kalibration auf dem Chip?
  • Die SSDV Bilder wurden auf dem Gateway nicht gespeichert (sollten unter /ssdv sein)

 

What next

Womit baut man sich am günstigtsen ein mobiles LoRa Gateway, wie z.B. die HAB Modem Tracker App für RTYY? Ideen:

  • man hängt das obige LoRa Gateway mit einem WLAN Dongle an den Hotspot seines Handys
  • Dave beschreibt einen LoRa Handheld Receiver, dem fehlt nur noch die Internetanbindung und der Lora Gateway Code
  • Internet: Mit einem ESP8266 und WLAN Anbindung an den Hotspot eines Handys
  • LoRa Gateway Code: müsste portiert werden auf den ESP resp. den AVR.
  • mit dem obigen Lora Gateway auf einem RPI V3 und einer Bluetooth Anbindung an den Hotspot eines Handys. Daten können zur Darstellung auch per Bluetooth an eine App auf dem Handy geschickt werden (z.B. eine APRS APP, siehe Aufbauvarianten hier im Blog von DJ7OO). Ein RPi V3 hat ein Bluetooth Modul, das man aber für den PITS deaktivieren soll…evtl. kann Bluetooth aber beim LoRa Gateway aktiv bleiben.

 

Quellen

Lora Hintergrundinformationen und Anwendungen

Lora für Tracker und Ballone

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.