Archiv der Kategorie: Raspberry Pi

Amateurfunk, APRS, Arduino, Code, LoRa, Raspberry Pi, Unterwegs, WLAN

LoRa APRS Tracker auf ESP32 Basis

Schreibe einen Kommentar

In meinem Blog habe ich häufig Raspberry-basierte Lösungen und Anwendungen beschrieben. In letzter Zeit (in den letzten 1-2 Jahren) entstehen in der Community aber immer mehr Lösungen auf Basis von ESP8266 bzw. dem quasi-Nachfolger ESP32, also basierend auf einem „Mikroprozessor“ und nicht einem vollständigen Linux-System, wie es beim Raspberry der Fall ist. Das finde ich sehr toll, weil damit die Pflege des vollständigen Linux-Systems hinfällig wird und ich leider auch schon viele SD-Karten tauschen musste, die mit der Zeit kaputt geworden sind. Immerhin sind die Rapsberrys oft im Außenbereich den Temperaturschwankungen und Änderungen der Luftfeuchtigkeit des Wetters und der Jahreszeiten ausgesetzt.

ESP32 basierter APRS LoRa iGate von OE5BPA

Als Client, Node, Tracker, Endgerät – wie auch immer man es nennen möchte – ist der ESP8266 schon länger im Einsatz. Neu ist, dass nun mit dem ESP32 Prozessor ein leistungsstarker Kern verfügbar ist, der auch Anwendungen ermöglicht, die früher einen Raspberry oder ähnliche Geräte erfordert hätten. Immerhin hat der im Jahr 2016 vorgsetellte ESP32 beeindruckende Leistungsdaten (für einen stromsparenden Mikroprozessor): 160 bis 240 MHz auf einer Dual-Core-Plattform mit 520 KB SRAM. Eingebaut sind WLAN (802.11 b/g/n) mit Bluetooth und zahlreiche Schnittstellen, auszugsweise zB.: GPIOs, 12bit ADC und 8bit DAC, SPI, I²S, I²C, UART, Unterstützung für SD/eMMC, Ethernet, CAN 2.0 uvm. Das Datenblatt gibt dazu mehr Auskunft.

Nachdem in diesem Leistungsbereich jetzt neue Anwendungen ermöglich werden, freut es mich besonders, dass Initiativen wie LoRa APRS davon profitieren und handfeste Lösungen auch für den Gateway-Einsatz (als iGate) verfügbar sind, aktiv entwickelt und laufend verbessert werden.

OM Andi OE1ROT stellt auf seinem Blog einerseits einen Tracker mit TTGO T-Beam (433 MHz!) vor, als auch die nun verfügbaren Gateways auf ESP32 Basis. Ich möchte hier in meinem Blog nicht nochmal alles beschreiben, Andi hat das bereits sehr ausführlich getan, daher verlinke ich diesmal nur zu seinem Eintrag:
https://www.aronaut.at/2020/11/lora-aprs-gateway-mit-esp32-boards/

Die Projekte werden auf Github in diesem Bereich gehostet: https://github.com/lora-aprs
Die iGate Software wird von Peter OE5BPA hier aktuell angeboten:
https://github.com/lora-aprs/LoRa_APRS_iGate

Die TTGO T-Beams sind zB. hier bei Amazon erhältlich: TTGO T-Beam ESP32 mit LoRa für 433 MHz (ggf. OLED Display nicht vergessen)

APRS, HAMnet, Hausautomatisierung, LoRa, Raspberry Pi, SDR

günstiger Raspberry Pi PoE HAT für 802.3af – Erfahrungen

3 Kommentare

In meinen Projekten betreibe ich viele Raspberries, die über PoE mit Strom versorgt werden. (Für eine Erklärung zu PoE siehe hier).

Ich nutze viele PoE Converter, um die nominal 48V von PoE bzw. PoE+ gemäß 802.3af / 802.3at auf 5V zu übersetzen und über Micro-USB dem Raspberry bereitzustellen. (Bei Raspi 4B ab jetzt natürlich häufiger mit USB-C).

Die neueren Raspberry-Modelle (3B+ und 4B) unterstützen ein offizielles Raspberry PoE HAT Modul. Dazu wurden 4 weitere PINs auf dem PCB des Raspberry Pi gesetzt und vom PoE HAT genutzt:

mitte/rechts: die 4 PINs für PoE

günstiges PoE HAT

Ich betrachte in diesem Blog nicht das offizielle PoE HAT, sondern eine günstige Alternative ohne Lüfter:

die günstige Alternative zum offiziellen PoE HAT

Im Gegensatz zum offiziellen PoE HAT gibt es hier zwar keine vorgesehene Position für einen Lüfter, allerdings sind die GPIO PINs verlängert bzw. werden durch das günstige PoE HAT durchgereicht. Ich kann also weitere HAT Aufsteckmodule nutzen.

Gekauft habe ich das Modul bei Aliexpress, es ist auch zB. über Amazon erhältlich:

Aufbau und Test

Ich habe es auf einen Raspberry 3B+ gesteckt und an ein Kabel, das von einem Ubiquiti EdgeSwitch 8 150W mit PoE+ versorgt wird.

Mein Ziel ist, einen LoRaWAN Gateway zu testen, der über PoE versorgt wird und LoRaWAN über ein IMST ic880a Board abwickelt. Um das ic880a Board am Raspberry GPIO zu betreiben ist ein Adapterboard nötig, das ich vom Verein OpenIoT erhalten habe.

Raspberry mit bereits aufgestecktem PoE HAT, OpenIoT Adapterboard und IMST ic880a (oben)

In Kombination sieht das „Sandwich“ dann so aus:

Die Module sind halbwegs stabil, ein gutes Gehäuse sollte dennoch her. Es sind leider keine Bohrungen für Distanzhalter vorgesehen.

Ich habe das Board mit einem Ubiquiti EdgeSwitch getestet, der EdgeSwitch unterstützt den PoE+-Standard und gibt mir auch die aktuelle Leistung je Port an:
im Leerlauf zieht ein Raspberry 3 B+ mit Raspbian Lite (Buster) nach einer frischen Installation etwa angezeigt 3,6 Watt.

Wenn ich das LoRaWAN Concentrator Board aufsetze und neu starte, wechselt die Anzeige zwischen 6,1 und 6,5 Watt:

PoE Verbrauch mit IMST ic880a LoRaWAN concentrator board in Betrieb

Auch auf einem Raspberry 4B hat sich das günstige PoE HAT problemlos betreiben lassen.

Temperatur

Bemerkenswert ist, dass das Gerät sehr heiß wird, wenn das IMST Board, das ja die Leistungsaufnahme ggü. dem Raspberry verdoppelt, angeschlossen wird. Die Angabe auf dem PoE HAT sind 2,5A – also 12 Watt. Wir nutzen hier zirka die Hälfte und es geht schon heiß her. Die Core Temperatur zeigt etwa 60 Grad bei Nutzung mit dem IMST Board. Dabei ist natürlich auch der Prozessor unter mehreren Aufsteckmodulen versteckt und hat wenig Luftzirkulation. Ohne LoRaWAN-HATs hat es etwa 53 Grad im Bereich der CPU.

Die Werte frage ich über vcgencmd ab:

stefan@lorawangw:~ $ vcgencmd measure_temp
temp=59.6'C

Fazit

Einen Langzeittest habe ich noch nicht gemacht, ich werde den Artikel hier dann aber mit den Erkenntnissen erweitern.

Das Modul funktioniert sehr gut, erspart mir in Zukunft hoffentlich einen weiteren externen Adapter, um PoE über MikroUSB oder USB-C dem Raspi zu geben.

Beobachten möchte ich die Temperatur, weil als Nebenwirkung des Boards der Raspi auffällig heiß wird.

Links zu den Modulen

Hier eine Übersicht der im Beitrag vorgestellten Artikel/Produkte:

Arduino, Funkfeuer, Hausautomatisierung, Raspberry Pi, Unifi

Übersicht über Power over Ethernet (PoE)

9 Kommentare

Bei vielen Anwendungen nutze ich Power over Ethernet (= PoE). Ist doch praktisch: ein Netzwerkabel wird für die Anwendung oft sowieso benötigt, dann kann man es auch gleich nutzen, um das Endgerät mit Strom zu versorgen. Außerdem ist oft keine Steckdose, wo man sie benötigen würde. Ich habe grundsätzlich nur gute Erfahrungen damit gemacht, teilweise entstehen durch die Nutzung von PoE auch neue Möglichkeiten. Es gibt jedoch verschiedene Standards und Varianten – und die müssen zusammenpassen. Hier also eine kleine Übersicht, die meinen Wissensstand und meine Erfahrungen widerspiegeln.

Im Wesentlichen sehe ich zwei große Varianten an PoE:

  • Passives PoE und
  • PoE nach 802.3af oder 802.3at (auch aktives PoE genannt, bzw. PoE+ bei 802.3at)

Beachtet, dass diese Varianten nicht miteinander kompatibel sind.

Passives PoE

Bei passivem PoE werden mehrere Adern des 8-poligen-Gigabit-Ethernet-Kabels für die Übertragung von Strom genutzt. Meist werden die Adern 4+5 für + und 7+8 für – genutzt. Hier wird einfach Strom von einem Netzteil (auch Injector genannt) durchgeschickt. Grundsätzlich sollte man hier vorsichtig sein, dass man (a) die richtige PoE-Variante einsetzt, (b) die korrekte Spannung überträgt und (c) das Endgerät das unterstützt. Sonst könnte es passieren, dass eine Netzwerkkarte defekt wird, wenn ihr einfach über diese PINs der Strom geschickt wird.

Es gibt viele gängige Varianten, die sich meist durch die Spannung unterscheiden. Bei Ubiquiti und Mikrotik findet man meist 24V passive PoE, in anderen Anwendungen (zB. Videokameras) kommt oft 12V zum Einsatz. Vereinzelt sieht man 5V, hier habe ich die Erfahrung gemacht, dass bei größeren Kabellängen (bereits so ab 10m) der Spannungsabfall relevant wird, von 5V würde ich also abraten bei passive PoE.

In den meisten Anwendungen sieht man, dass ca. 2,1 bis max. 2,5 Ampere übertragen werden. Je nach Spannung kann man also leicht ausrechnen, wieviel Leistung mit dieser Variante zur Verfügung gestellt werden kann. Bei 24V mit 2,1A sind das bereits gut 50 Watt, bei 12V die Hälfte.

Passives PoE heißt also so, weil es einfach Strom durchschickt, ohne weiterer Überprüfung oder Logik.

PoE & PoE+ nach 802.3af und 802.3at

Man sieht an der Überschrift: diese Variante ist genauer standardisiert. Die IEEE hat im Standard 802.3af und 802.3at genau spezifiziert, wie PoE durch das Netzwerkkabel geschickt wird und viele Hersteller nutzen diesen Standard. Das erhöht natürlich die Kompatibilität und so wird es möglich, einen PoE-fähigen-Switch mit beliebigen Endgeräten zu verbinden.

PoE und PoE+ orientieren sich an 48V (Nominalspannung), tatsächlich sieht der Standard 36V bis 57V vor. Das ist schon vernünftig aufgrund der Robustheit bei längeren Ethernet-Verbindungen.

Meines Wissens nach unterscheiden sich PoE (IEEE 802.3af) und PoE+ (IEEE 802.3at) vor allem aufgrund der maximal vorgesehenen Leistung. Diese wird beim Anschluss des Kabels „detektiert“, dafür gibt es einen ausgeklügelten Mechanismus, der den Widerstand des Engerätes misst und darüber erfährt, welchen Standard und welche Leistungsklasse das Endgerät unterstützt. Tolle Sache, va. ist hier auch abgesichert, dass ein Endgerät ohne PoE-Funktion keinen Schaden nimmt und nicht einfach Spannung durchgeschickt wird, wie bei der passiven Variante.

Grundsätzlich würde ich, wenn möglich, dieser Variante von PoE den Vorzug geben.

Falls euch Details zu den Modi, Spannungen, der Detektion und den Leistungsklassen interessiert, möchte ich auf die Wikipedia-Seite verweisen, da diese sehr ausführlich darüber aufklärt: https://de.wikipedia.org/wiki/Power_over_Ethernet

Anmerken möchte ich noch, dass es auch bei IEEE 802.3af/at eine passive Variante gibt, dort werden die PINs 1+2 für + und 3+6 für – genutzt. Vor allem günstigere Injectoren und Splitter setzen darauf. Bisher habe ich keine Probleme damit gehabt. Splitter nach dem 802.3af/at-Standard haben in allen Kombinationen mit Injectoren & Switches funktioniert.

PoE bei Switches

Es gibt von verschiedenen Herstellern zahlreiche Switches, die PoE unterstützen. Die meisten setzen auch hier auf den 802.3af/at-Standard.

Ich finde es sehr praktisch, dass man von Switches aus direkt die Endgeräte mit Strom versorgen kann. Meistens sind diese Endgeräte WLAN Access Points oder IP Kameras. Ich nutze es aber auch gerne für Raspberry Pi oder Arduinos (und andere IoT-Geräte oder Sensoren).

Ein wesentlicher Vorteil hierbei ist, dass man am Switch (meist per Webinterface) den Port PoE-mäßig resetten kann. Wenn also eine IP Cam nicht mehr reagiert, kann ich bequem einen Restart auslösen. Das ist vor allem praktisch bei weit entfernten Standorten und erhöht die Betriebssicherheit immens. Manche Switches können auch Endgeräte per PING überwachen, und wenn diese ein paar Minuten nicht mehr erreichbar sind, resetten sie PoE am Port automatisch.

Bei einer Sache muss man jedoch achtgeben: PoE Switches haben meist ein „Power Budget“, also eine maximale Leistung (in Watt), die sie auf einzelnen Ports oder insgesamt(!) bedienen können. Es kann also sein, dass auf einem 24-Port-PoE-Switch, der zB. 70 Watt Power Budget unterstützt, nicht auf jedem Port eine Kamera mit PoE versorgt werden kann. Das sollte man sich vorher überlegen und danach den richtigen Switch mit der richtigen Leistung wählen.

PoE Adapter für DIY-Projekte

Ich werde oft gefragt, welche PoE-Injectoren (= führt die Spannung in das Netzwerkkabel und enthält manchmal direkt das Netzteil) ich verwende und wie ich die Endgeräte anschließe, zB. Raspberry PI.

Ich führe hier also ein paar Geräte an, die kostengünstig sind und mit denen ich gute Erfahrungen gemacht habe. Die Teile sind Großteils bei Amazon erhältlich oder – wenn man mehr Zeit für die Lieferung hat – auch bei Aliexpress.

PoE Injector & Splitter

zB. bei Amazon:


Allgemein, Linux, Raspberry Pi

5″ Display für Raspberry Pi

2 Kommentare

Immer wieder muss ich meinen Monitor abstecken, um ihn an einen Raspberry anzuschließen. Das nervt.

Nachdem ich mehrere aufsteckbare LCD-Module probiert habe, bin ich mittlerweile an Treiberinstallationen und anzupassenden Kernels verzweifelt.

Jetzt habe ich eine einfache Lösung gefunden: natürlich ist HDMI die richtige Schnittstelle. Da braucht man einfach gar nichts zu konfigurieren, weil’s eh Standard ist.

Auf Aliexpress habe ich ein günstiges 5″ HDMI Display mit 800×480 Pixel Auflösung um € 22,- gefunden. Dieses Display hat auch eine Touch-Oberfläche, die ich aber nicht verwende. (Da befürchte ich wieder Treiberinstallationen und Kernelanpassungen…) Angeschlossen wird es über HDMI, es hat dazu einen Stecker/Adapter, der die beiden HDMI-Ports ganz einfach verbindet.

Das Display habe ich nach ein paar Wochen Lieferzeit erhalten und sofort auf einen Raspberry Pi 3 gesteckt. Funktionert hat es von Anfang an, allerdings nicht in voller Auflösung – es war rechts immer ein Teil unbenutzt. (Ich vermute, dass der Raspberry von 640×480 Pixel (VGA) ausgegangen ist und nicht die vollen 800px Breite genutzt hat. Durch drei Zeilen, die man in der /etc/boot.txt hinzufügt, lässt sich das beheben; ab dem nächsten Reboot wird der Bildschirm vollständig genutzt.

Diese Zeilen hänge ich der /etc/boot.txt an:

hdmi_group=2
hdmi_mode=87
hdmi_cvt 800 480 60 6 0 0 0

Den Tipp habe ich übrigens von hier. Da findet man auch die Anleitung für die Aktivierung der Touchscreen-Funktion.

Wer keine 3-5 Wochen auf den Screen warten möchte, bekommt ihn hier auch auf Amazon.de.

Als Eingabemethode verzichte ich ja auf die Touchscreen-Funktion. Dafür will ich eine Bluetooth-Tastatur oder vielleicht ein Android Handy als Bluetooth-Tastatur nutzen.

Links

Allgemein, Amateurfunk, APRS, Code, Linux, LoRa, Raspberry Pi, WLAN

LoRa APRS Gateway mit Raspberry Pi Zero W

3 Kommentare

In einem anderen Beitrag habe ich darüber berichtet, dass wir erfolgreich über LoRa-Modulation APRS-Pakete gesendet haben und wie ein APRS-Tracker mit Arduino zu bauen und programmieren ist.

Nun habe ich von Sascha (www.iot4pi.com) ein fertiges, von ihm konstruiertes Board, für einen LoRa APRS Gateway bekommen. Wie er diese Boards erstellt und zusammenbaut, hat er übrigens auf seiner Seite näher beschrieben:
www.iot4pi.com/de/bau-des-lora-gateway-shield

Die Software, das Image für die SD-Karte (ich habe ein 8 GB-Karte zur Hand), findet ihr hier zum Download:
www.iot4pi.com/de/raspberry-pi-projekte-software/lora-aprs-gateway

Nachdem man die SD-Karte in den Raspberry gesteckt und das Gehäuse mit dem Raspberry darin geschlossen ist, bootet man den Raspberry zum ersten Mal.

Ich habe in der /etc/network/interfaces sofort eine statische IP-Adresse eingetragen.

Die Konfiguration des Gateways fwird in der Datei /home/pi/iot4pi/APRS.conf vorgenommen. Im Wesentlichen muss man nur folgende Zeilen anpassen:

APRS_IS_CALL:OE1SCS-10
APRS_IS_PASSCODE:12345
LATITUDE:4811.48N
LONGITUDE:01623.23E

Wichtig ist auch, dass man zur Netzwerkanbindung das WLAN am Raspberry Zero W konfigurieren muss. Dazu tragt man in der Datei /etc/wpa_supplicant/wpa_supplicant.conf folgende Zeilen ein:

country=AT
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="meinwlan"
    psk="meinpasswort"
}

Da der Gateway nicht für den Außeneinsatz geeignet ist, habe ich mir eine kleine flache Fensterdurchführung zugelegt, mit der ich die Antennenleitung ans Fensterbrett bekomme und dort mit einer 70cm-Magnetfußantenne für 433 MHz verbinde.

Einkaufsliste LoRa APRS Gateway auf Raspberry Pi Zero W

Optional, für den Anschluss an einen Monitor:

Amateurfunk, Code, Linux, LoRa, Raspberry Pi

günstiger 1ch LoRa Gateway: RFM95W direkt zu Raspberry verkabelt

3 Kommentare

Obwohl ich der Meinung bin, dass vollwerte LoRaWAN-kompatible Gateway wirklich Sinn ergeben, beschäftige ich auch mit den preiswerten Single Channel (1ch) Gateways. Für Entwicklungen zu Hause ist das ja eine günstige Option.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Hier habe ich eine Anleitung gefunden, mit der tatsächlich um € 13,90 für das LoRa-Modul ein Raspberry Pi supereinfach zu so einem 1ch-Gateway wird: https://www.hackster.io/ChrisSamuelson/lora-raspberry-pi-single-channel-gateway-cheap-d57d36

Achtung, die Anleitung im Link oben empiehlt die Änderung zur amerikanischen Frequenz (902,3 MHz). In Europa bleiben wir bei 868,1 MHz! (Das ist eh der Standardwert) In meiner Anleitung ist auch die IP-Adresse der europäischen Server von TTN enthalten.Die Schritte sind recht einfach:

  • Man bestellt das LoRa RFM95W-868S2 Transceiver Modul.
  • man teilt 4 Jumper Wire Kabel in der Hälfte, sodass auf einer Seite eine Buchse (female) und auf der anderen Seite der blanke Draht ist.  7 davon lötet man an diese Position am Transceiver Modul: DI00, 3.3V, MISO, MOSI, SCK, RESET, NSS und GND (neben MISO)
  • Als Antenne verwenden wir hier zwei Drähte, die 83mm Länge haben und an die Positionen ANA und GND (neben ANA!) gelötet werden. Als Draht wird ein 18ga empfohlen, das ist in unseren Breiten ein 1mm Drahtstück.
  • Nun verbindet man diese mit den PINs am Raspberry GPIO:
    3.3V -> PIN1, GND -> PIN6, DI00 -> PIN7, RESET -> PIN11, NSS -> PIN22, MOSI -> PIN19, MISO -> PIN21 und SCK -> PIN23
  • jetzt kann auch schon die Software installiert werden. Es wird git, wiringpi und der Code für den Single Channel Gateway benötigt:
sudo apt install git wiringpi
git clone https://github.com/tftelkamp/single_chan_pkt_fwd
  • im raspi-config-Tool muss nun die SPI-Schnittstelle aktiviert werden (im Menü „Interfacing Options“ -> „SPI“:
sudo raspi-config
  • nach einem Reboot (wird von raspi-config vorgeschlagen) konfiguriert man die Einstellungen in der main.cpp des single_chan_pkt_fwd Codes:
// Set location
float lat=48.1906;
float lon=16.3867;
int alt=200;

/* Informal status fields */
static char platform[24] = "1ch Gateway";
static char email[40] = "meine@email.adresse";
static char description[64] = "RFM95W directly wired";

// define servers
#define SERVER1 "52.169.76.203"
  • Der Code kann nun mit make compiled werden:
make
  • Nun können wir den Gateway das erste Mal starten:
./single_chan_pkt_fwd
  • Die EUI, die hier gezeigt wird, müssen wir nun bei der Console von TheThingsNetwork als EUI eines neuen Gateways eintragen. Dieser wird sofort angezeigt und übermittelt auch auf Anhieb die Daten, die er empfangen hat.

Ich lege mir meist noch ein Startkommando zurecht, bei dem ich auch den Output in die Datei /var/log/ttn-single-chan-pkt-fwd.log schreibe. Dazu füge ich in der /etc/rc.local folgendes hinzu (am Ende, aber vor dem „exit 0“):

/home/stefan/single_chan_pkt_fwd/single_chan_pkt_fwd >> /var/log/ttn-single-chan-pkt-fwd.log 2>&1

Nach einem Reboot wird so die Software automatisch ausgeführt und ein Logfile angelegt.

Amateurfunk, Code, Linux, LoRa, Raspberry Pi

GPS am Dragino LoRA HAT

2 Kommentare

Mit dem Dragino LoRa GPS HAT auf meinem Raspberry Pi 2 betreibe ich einen Single Channel Gateway, wie in meinem anderen Beitrag beschrieben.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Nun möchte ich auch die GPS-Funktion ausprobieren! Vielleicht kann ich es zur Zeitsynchronisierung nutzen? Naja, vielleicht im Vergleich zu NTP für meine Anforderungen etwas viel Aufwand. Aber schauen wir mal…

Als Antenne verwende ich eine Magnetantenne (für zB. Autos) mit 3m Kabel.

Die serielle Schnittstelle ist am Raspberry mit der Console belegt und muss erst freigegeben werden, bevor wir GPS-Daten empfangen können:

In der Datei /boot/cmdline.txt entfernen wir den Eintrag für

console=/dev/ttyAMA0

Danach beenden und deaktivieren wir das Service für die serielle Ausgabe:

# systemctl stop serial-getty@ttyAMA0.service
# systemctl disable serial-getty@ttyAMA0.service

Nun installieren wir gpsd & Co:

# apt-get install gpsd gpsd-clients python-gps

Folgende Zeilen bleiben in meiner /etc/default/gpsd als Konfiguration:

START_DAEMON="true"
USBAUTO="true"
DEVICES=""
GPSD_OPTIONS="/dev/ttyAMA0"
GPSD_SOCKET="/var/run/gpsd.sock"

Nach einem Reboot kann ich cgps aufrufen:

An diesen Anleitungen habe ich mich orientiert:
für Raspberry Pi 2
für Raspberry Pi 3 funktioniert es ein bißerl anders.

Amateurfunk, Code, Hausautomatisierung, Linux, LoRa, Raspberry Pi, Unterwegs

LoRa Single Channel Gateway

19 Kommentare

Mit Freunden baue ich einen Multi-Channel-Gateway, der auf sämtlichen LoRa-Kanälen empfangen und senden kann – und das mit allen SF (Spreading Factors). So ein Gateway kostet knapp 400 Euro in Summe – das ist mir zum Spielen für zu Hause zu teuer.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Single Channel Gateway = günstig

Die günstige Variante, die streng genommen nicht LoRaWAN-kompatibel ist, weil sie nur eine Frequenz und einen Spreading Factor unterstützt, ist ein Single Channel Gateway. Dieses hört auf einen vordefinierten (aber konfigurierbaren) Kanal mit einem vordefinierten Spreading Factor (auch konfigurierbar) und sendet die Daten an The Things Network.

Als Basis nehme ich einen Raspberry Pi 2, der aktuell eh auf eine Aufgabe wartet. Das LoRa & GPS HAT von Dragino nutze ich für die LoRa-Übertragungen. Das HAT habe ich um € 29,- bei Tindie erstanden. In Summe bin ich bei Kosten von weniger als € 65,-.

Einsatzgebiet

Wie beschrieben ist ein Single Channel Gateway kein vollständig LoRaWAN-kompatibler Gateway. Er hört nur auf eine Frequenz (Kanal) und versteht nur einen SF. Nachdem meine Sensoren abwechselnd auf drei Frequenzen senden, stelle ich den Single Channel Gateway auf eine Frequenz ein – und ich stelle mich darauf ein, nur jedes dritte Paket zu empfangen. (Da bei LoRa ja ein Counter mitläuft, kann ich das leicht nachprüfen.)

Falls ich einmal einen Sensor permanent installieren möchte, würde ich ihn fix auf die eine Frequenz stellen, die der Gateway (oder mehrere?) auch nutzt. Damit wäre ein kleines LoRa-Netzwerk möglich, das aber nur auf einer Frequenz funktioniert.

Installation

Es ist ganz einfach:

  1. aktuelle Raspian-Version installieren und Raspberry vorbereiten (resize disk, SSH-Zugriff für Fernzugriff aktivieren, Passwort und IP-Einstellungen ändern)
  2. alles aktualisieren und wiring-pi installieren:
apt-get update && apt-get dist-upgrade
apt-get install wiringpi

3. in raspi-config das SPI Interface aktivieren & rebooten

4. die Single Channel Gateway Software von Github laden und installieren:

wget https://github.com/tftelkamp/single_chan_pkt_fwd/archive/master.zip
unzip master.zip

und ein paar Parameter in der main.cpp konfigurieren:

// SX1272 - Raspberry connections
int ssPin = 6;
int dio0  = 7;
int RST   = 0;

// Set spreading factor (SF7 - SF12)
sf_t sf = SF7;

// Set center frequency
uint32_t  freq = 868100000; // in Mhz! (868.1)

// Set location
float lat=48.0;
float lon=16.0;
int   alt=200;

/* Informal status fields */
static char platform[24] = "Single Channel Gateway"; /* platform definition */
static char email[40] = "meine@email.at"; /* used for contact email */
static char description[64] = "Dragino LoRa GPS HAT Raspberry 2"; /* used for free form description */

// define servers
#define SERVER1 "52.169.76.203" // The Things Network: router.eu.thethings.network #define PORT 1700 // The port on which to send data

Danach mit „make“ builden:

make

Und schon kann ich den Gateway starten:

./single_chan_pkt_fwd

Einrichten bei The Things Network

Nun erstelle ich den Gateway in der TTN Console:

  • Register Gateway
  • dann wähle ich „I’m using the legacy packet forwarder“. Somit kann ich die Gateway EUI eingeben, die mir beim Start meines Single Channel Gateways angezeigt wurde.
  • die Description kann frei gewählt werden
  • der Frequency Plan ist Europe in meinem Fall und der
  • Router EU. Das ist auch die IP-Adresse, die wir oben in der main.cpp definiert haben. (Details siehe hier: https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway)
  • mehr muss man nicht tun (natürlich ist es schön, die GPS-Position und Höhe einzugeben)

Das war’s! Bei „Data“ kann ich zusehen, wie die Daten ankommen, und binnen kurzer Zeit bestätigt sich die Vermutung, dass ich jeden dritten Counter sehen werde:

Stückliste zum Nachbauen

  1. Raspberry Pi (2 oder 3)
  2. Dragino LoRa GPS HAT, alternativ hier beim Hersteller mit längerer Lieferzeit zu erstehen: https://www.tindie.com/products/edwin/loragps-hat/
  3. ev. eine coole Antenne? (nicht unbedingt nötig, es ist eine beim LoRA GPS HAT dabei)
Amateurfunk, Arduino, Code, Linux, LoRa, Raspberry Pi

LoRa TTN Gateway Pakete mit tcpdump mitprotokollieren

Schreibe einen Kommentar

Über die Schnittstellen bei TTN (The Things Network) kann man eine Menge Daten auslesen – natürlich die Inhalte (Payload) der Applikationen und einige technische Werte.

Konkret interessiert mich zB. der RSSI (Eingangssignalstärke) der vom LoRa Gateway empfangenen Pakete. Im Webinterface kann man in der TTN Console im Bereich Gateway mitschauen und erhält hübsche JSON-Objekte, in denen alles enthalten ist. Ich habe aber keine Schnittstelle gefunden, mit der ich es auslesen kann – weder live noch nachträglich (als gespeicherte Werte).

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Nachdem ich mir das Protokoll schon angeschaut habe, war mir klar, dass es die Daten unverschlüsselt überträgt. Es nutzt übrigens UDP für die Kommunikation zu den TTN Network Servern auf Port 1700.

Also habe ich meiner /etc/rc.local (vor dem „exit 0“!) folgenden Eintrag hinzugefügt:

/usr/sbin/tcpdump -Aq port 1700 >> /var/log/ttn-tcpdump-gateway.asc &

Damit wird nach jedem Reboot in die Datei /var/log/ttn-tcpdump-gateway.asc per tcpdump in ASCII die Inhalte aller Verbindungen zu Port 1700 gespeichert:

Mich interessieren eigentlich nur Übertragungen und Statusmeldungen. In beiden kommt „rx“ vor:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx

Die Meldungen beginnen immer mit 41 Zeichen (Byte) Header, die kann man wegschneiden:

cat /var/log/ttn-tcpdump-gateway.asc | grep rx | cut -c 41-

Wenn nach „rxpk“, der Meldung für ein empfangenes Paket suche, erhalte ich nur Meldungen, die der Gateway über LoRa empfangen hat:

cat /var/log/ttn-tcpdump-gateway.asc | grep rxpk | cut -c 41-

Hier hat man nun je Zeile ein JSON-Objekt mit sämtlichen Details zur Kommunikation:

{"rxpk":[{"tmst":4242060820,"time":"2017-04-15T14:55:05.977557Z","chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-10.5,"rssi":-115,"size":24,"data":"QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"}]}

wird zB. mit http://jsonviewer.stack.hu/ zu

{
  "rxpk": [
    {
      "tmst": 4242060820,
      "time": "2017-04-15T14:55:05.977557Z",
      "chan": 1,
      "rfch": 1,
      "freq": 868.300000,
      "stat": 1,
      "modu": "LORA",
      "datr": "SF9BW125",
      "codr": "4/5",
      "lsnr": -10.5,
      "rssi": -115,
      "size": 24,
      "data": "QK4XASaAvxEBoUDxzpcOkO+F6T1TVsvg"
    }
  ]
}
Amateurfunk, App, Arduino, Code, Linux, LoRa, Raspberry Pi, Unterwegs

LoRa Sensor mittels Arduino und LoRa Shield

16 Kommentare

Über einen Freund bin ich vor ein paar Wochen auf das Thema LoRa bzw. LoRaWAN aufmerksam geworden.

Vor allem seit ich The Things Network (https://www.thethingsnetwork.org) kenne und somit über die Community eine Möglichkeit besteht, die Technologie sinnvoll zu nutzen, bin ich interessiert mich damit mehr zu beschäftigen.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt uns auf Twitter (@TTN_Vienna), für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Ein LoRa Sensor ist ein Endgerät, das über das LoRa-Protokoll in ein Netzwerk Informationen funkt. Empfangen werden die Pakete üblicherweise von einem Gateway. Bis zur Auswertung der Pakete sind noch Network Server und Application Server nötig, die in meinem Fall über TTN (The Things Network) bereitgestellt werden.

Da ich auch mit Freunden einen Gateway bauen möchte, brauchen wir natürlich einen LoRa Sensor, um unseren Gateway zu testen. Als günstige Variante habe ich Arduino + LoRa Shield für Arduino gefunden.

Nachtrag Juli 2017: wir haben mit dem Aufbau einer Community bei The Things Network in Wien begonnen. Das Ziel ist die Schaffung eines freien und offenen Netzes für IoT. Nachdem ich mehrfach auf meinen Blog hin angeschrieben wurde, es den Personen aber nicht bewusst war, dass sich hier was tut, möchte ich auf folgende Links verweisen: folgt und auf Twitter (@TTN_Vienna) für Updates und Infos zu den nächsten Treffen oder besucht die Wiener Community Seite!

Zutaten

Falls jemand entspannt an das Projekt herangeht und mit 5-6 Wochen Lieferzeit aus Shenzhen (China) kein Problem hat, gibt es das LoRa Shield auch kostengünstiger (€ 18,70 am 1.4.2017) über Tindie zu kaufen. Hier beachtet bitte, dass Shipping (+ € 6,12 nach Österreich) und ggf. Zoll dazukommen.

Bitte beachtet bei Bestellungen immer, dass ihr die 868 MHz-Variante auswählt! Nur diese darf in der EU betrieben werden bzw. wird hier funktionieren!

Von der Vorgehensweise halte ich mich an diese Anleitungen:

  1. ein tolles Youtube-Video, das genau den hier beschriebenen Aufbau erklärt: LoRa Node with Arduino and Dragino Shield connected to TTN LoRaWAN von Andreas Spiess
  2. Software (Arduino Sketch) „Hello World“ von https://github.com/SensorsIot/LoRa
  3. LMIC library von IBM, angepasst für Arduino: wird vom Arduino Sketch benötigt

Vielen Dank an die Kollegen von TTN Zürich, die diese Anleitungen und Programme zur Verfügung stellen!

Zusammenbau

Das LoRa Shield muss nun nur mehr auf den Arduino gesteckt werden. Die Antenne wird an den SMA-Anschluss geschraubt.

Konfiguration

Nun lädt man den Arduino Sketch („Hello World“, siehe Link oben) ins Arduino IDE und muss ein paar Werte anpassen. Dazu erstellt man eine „Application“ in der Console von TTN und legt ein Gerät („Device“) an. Eine Over-The-Air-Activation (OTAA) ist nicht möglich, daher muss man manuell ABP wählen und die Werte vom Webinterface abschreiben. Diese werden von TTN automatisch generiert.

  1. NWKSKEY: der Network Session Key muss im korrekten Format in die geschwungenden Klammern { } eingefügt werden.
  2. APPSKEY: ebenso der Application Session Key und zum Schluss die
  3. DEVADDR, also die Geräteadresse im korrekten Format.

TTN bietet im Webinterface übrigens die Werte bereits im richtigen Format an. Im Zweifelsfall muss man auf „< >“ klicken, dann werden die Werte in anderen Formaten dargestellt und können mit copy & paste übernommen werden. Das gewünschte Format ist „msb“.

Ansonsten musste ich keine weiteren Änderungen am Code durchführen.

Trotzdem habe ich den zu übertragenden Text von „HI“ auf „stefan test“ geändert: dazu habe ich die Payload in der Variable „message[]“ in Zeile 57 angepasst:

  // Payload to send (uplink)
  static uint8_t message[] = "stefan test";

Nun habe ich den Sketch kompiliert und auf den Arduino übertragen. Unmittelbar darauf hat er begonnen, alle 20 Sekunden kurz zu blinken, wodurch ich mich bestätigt gefühlt habe, dass es funktioniert und nun alle 20 Sekunden die Meldung „stefan test“ mittels LoRa übertragen wird.

Überprüfen am Gateway

Einen Gateway hatten wir parat und er hat sofort die Pakete empfangen. Über die „Traffic“ Funktion in der TTN Console kann man die ankommenden Pakete gleich sehen.

Man sieht hier mehrere Pakete, die im Abstand von ca. 25 Sekunden ankommen. Die Frequenz wechselt bei jedem Paket, weil mehrere Kanäle genutzt werden: 868,1 – 868,5 – 868,3 usw.

Folgendes JSON Objekt mit allen Details erhält man aus der TTN Console beim Gateway Traffic:

{
  "gw_id": "eui-b827ebfffe6f377d",
  "payload": "QI4cASaAaAABhVJosx+GBwUwHBqp4DGG",
  "f_cnt": 104,
  "lora": {
    "spreading_factor": 9,
    "bandwidth": 125,
    "air_time": 205824000
  },
  "coding_rate": "4/5",
  "timestamp": "2017-03-29T05:57:06.352Z",
  "rssi": -25,
  "snr": 11.2,
  "dev_addr": "26011C8E",
  "frequency": 868100000
}

Es enthält sämtliche Details zur Übertragung. Ein paar Werte möchte ich kurz hervorheben:

  • gw_id: zeigt die ID des Gateways, der das Paket empfangen hat
  • payload: sind die übertragenen Daten in verschlüsselter Form
  • f_cnt: ist der Counter und gibt die Anzahl der Pakete wider
  • lora.spreading_factor: zeigt hier den Spreading Factor 9, der im Sketch eingestellt ist
  • rssi: zeigt die Signalstärke des empfangenen Pakets am Gateway an (hier: -25 dbm)
  • snr: das Signal/Rausch-Verhältnis
  • dev_addr: die Geräteadresse, die von TTN vergeben wurde und ich als DEVADDR im Sketch hinterlegt habe.
  • frequency gibt die Frequenz in Hertz an

Wir sehen, dass das Paket einwandfrei übertragen wurde und sogar sehr gut (-25 dbm) empfangen wurde. Bei diesem Test war der Abstand vom Sensor zum Gateway aber auch im Bereich von 5 Metern.

Optimierungen

Als Spreading Factor ist 9 eingestellt. Um die Reichweite zu erhöhen, kann man auch zB. SF12 einstellen. Das geht im Arduino Sketch auf Zeile 90:

  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF9, 14);

Falls man die Pakete weniger oft übertragen möchte (alle 20 Sekunden ist zum Testen super, aber dauerhaft verbraucht es zu viel Airtime), kann das in Zeile 39 anpassen:

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 20;