Induktives Laden mit Qi

Samsung S7 hat induktiv voll geladen

Ich beziehe mich bewusst nicht nur auf Handys bzw. Smartphones, weil ich glaube, dass dieses induktive Laden viele andere Anwendungsmöglichkeiten bietet. Ich möchte ja auch den Akku eines tragbaren LoRaWAN-Sensors künftig induktiv laden, aber das ist ein anderes Thema…

Dass es die Möglichkeit gibt, Smartphones induktiv aufzuladen, ist mir schon länger bewusst. Ich habe aber auch gesehen, dass es mehrere Standards gibt, die nur eingeschränkt (wenn überhaupt) kompatibel erscheinen. Im letzten Urlaub habe ich einiges zu dem Thema gelesen und bin nun auf den Zug aufgesprungen und sehr begeistert.

Hauptgrund war, dass es nun einen von allen Herstellern anerkannten und kompatiblen Standard gibt und meine Bedenken hinsichtlich Gesundheitsproblemen durch permanente Strahlung zerstreut wurden.

Funktionsweise

Induktives Laden läuft: 53%. Ca. 1 h 22 min bis voll geladen

Wie funktioniert das induktive Laden? Im Prinzip werden eine Ladeschale (oder Halterung) benötigt, die mit einer Stromversorgung (meist USB) verbunden ist und ein Endgerät (Smartphone), das induktives Laden unterstützt. Sobald man das Smartphone auf die Ladeschale legt, beginnt das Handy zu laden.

Dabei bedient man sich einer Technologie, die von Transformatoren her längst bekannt und im Einsatz ist: eine Spule in der Ladeschale induziert ein Magnetfeld und dieses wird von einer Spule im Smartphone wieder in elektrischen Strom umgewandelt.

Spezifikation

Das Wort „Qi“ bedeutet auf chinesisch „Lebensenergie“ und ist vielleicht von Qi Gong her bekannt. Hier beschreibt der Name die proprietäre Technologie des Wireless Power Consortiums. Nachdem sich der konkurrierende Standard „Powermat“ der „Power Matters Alliance“ zurückgezogen hat, ist nun Qi der de-facto Industriestandard.

Die Übertragung findet im Bereich der Langwelle von 110 bis 205 kHz mit nominal 19 Volt statt. Es gibt mehrere Leistungsklassen von 5-15 Watt (Low Power) bis 120 Watt (Medium Power). Ich glaube, dass dadurch in naher Zukunft auch Anwendungen für andere Geräte mit höherem Energiebedarf ermöglicht werden. Die Übertragung funktioniert meist bei einem Abstand im Bereich einzelner Millimeter. Die Effizienz der Übertragung liegt je nach Gerät bei 60-90%, ist also immer verlustbehafteter im Vergleich zum Laden über Kabel.

Besonders gut hat mir gefallen, dass der Standard auch eine Datenübertragung zwischen den Geräten definiert. Diese ist mit 2 kbit/s spezifiziert und ermöglicht den Informationsaustausch zwischen den Qi-Komponenten. Damit ist nun auch klar, dass der Sendeteil (zB. die Ladeschale) nicht permanent ein starkes elektromagnetisches Feld erzeugt, sondern erst mit höherer Leistung beginnt, sobald ein kompatibles Endgerät erkannt wurde, die Datenverbindung hergestellt ist und die Geräte vereinbart haben, welche Ladung (zB. Leistung) durchgeführt wird.

Kann mein Smartphone Qi und was mache ich, wenn nicht?

Die einfachste Möglichkeit herauszufinden ob das eigene Smartphone Qi unterstützt ist wie üblich: ausprobieren, oder im Handbuch nachlesen. 😉

Samsung Smartphones sind beispielsweise seit dem Samsung S6 Qi-fähig und Apple-Geräte seit dem iPhone 7.

Es ist aber auch möglich, das eigene Smartphone nachzurüsten. Dazu gibt es recht günstig dünne induktive Ladeempfänger, die man zB. in der Schutzhülle des Handys verstecken kann. Diese Empfänger werden zB. per USB Micro (oder Typ C) an das Smartphone angeschlossen. Das Handy merkt eigentlich nicht, dass es induktiv geladen wird, sondern erkennt natürlich nur, dass es an einem „Ladekabel“ hängt. Der USB-Port ist damit natürlich auch belegt – das sollte man beachten. Die Empfänger sind so dünn und oft so passgenau, dass sie zwar einerseits kaum sichtbar/spürbar sind, andererseits aber kaum Spielraum haben und man immer die Hülle herunternehmen muss, falls man den USB-Port anders nutzen möchte.

Ladeempfänger ist zu lang und verdeckt den Fingerprint Sensor teilweise

Außerdem empfehle ich sehr, nachzusehen ob der Ladeempfänger von der Form für das eigene Smartphone passt. Bei meinem ersten Kauf für mein Nexus 5X habe ich einen zu großen Empfänger gekauft, der verdeckt fast die Hälfte des Fingerprint-Scanners. Den verwende ich nicht, also stört es mich nicht, aber hätte ich besser aufgepasst, hätte ich was Passendes um’s gleiche Geld bekommen.

Ergebnisse im Test

Mittlerweile habe ich ein paar Ladeschalen und ein paar Qi-fähige Endgeräte getestet, sowie eine handvoll Handys nachgerüstet.

Es funktioniert alles einwandfrei. Man muss sich daran gewöhnen, dass die Ladezeiten länger werden, weil die meisten kostengünstigen Qi-Geräte 800mAh oder vielleicht 1000mAh schaffen. Damit brauchen moderne Handyakkus schon rein rechnerisch 4-5 Stunden für eine volle Ladung. Aufgrund des Verlusts in der Übertragung wird das nochmal erheblich mehr. Über Nacht ist das aber normalerweise kein Problem.

Ich erwähne die längere Ladezeit nur deswegen so explizit, weil ich das Gefühl habe, dass bei kabelgebundenen Lademöglichkeiten gerade die Erwartungen sehr hoch gesteckt werden, nämlich „mehrere zig“-Prozent in einzelnen Minuten laden zu können. Dort kommen auch Ströme von 4,6 Ampere zum Einsatz, die über den USB-Port in den Akku „gedrückt“ werden. (Vgl. Qualcomm Quick Charge 3 oder 4+).

Eine berichtenswerte Erfahrung habe ich aber auch gemacht: ich habe mir eine Ladeschale ins Büro gelegt. Tagsüber bin ich öfters in Besprechungen und dann meist nur 20 Minuten kurz am Platz die neuen Emails durchschauen. Früher habe ich dabei nie oder selten das Handy angesteckt und aufgeladen. Heute lege ich es regelmäßig bei diesen kurzen Aufenthalten auf die Ladeschale. Und das führt dazu, dass ich tagsüber immer wieder nachlade und so an manchen Tagen eigentlich kaum noch unter 90% auf der Akkuanzeige komme…

Eine weitere Erkenntnis ist, dass man manche Smartphones relativ genau platzieren muss, damit das Laden funktioniert. Die Spulen müssen möglichst übereinander liegen. Ein Samsung S6 zum Beispiel funktioniert auf einem meiner getesteten Ladeschalen (es handelt sich um dieses Modell) nur, wenn ich es eher rechts platziere. Mittig funktioniert es nicht und links auch nicht. Andere Smartphones funktionieren mittig und rechts, aber links auch nicht. Daran habe ich mich aber recht schnell gewöhnt und lege die jeweiligen Geräte mittlerweile ohne viel Nachdenken richtig auf.

Folgende Geräte sind auf den Fotos in diesem Blog gezeigt:

Fazit

Ich liebe es! Einziger Wermutstropfen ist der Energieverlust bei der Übertragung. Das ist sehr schade und Verschwendung. Von der Zuverlässigkeit, Kompatibilität und Geschwindigkeit (für mich ausreichend) alles super!

Meldung eines Samsung S7

5″ Display für Raspberry Pi

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

LoRa APRS Gateway mit Raspberry Pi Zero W

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:

SD-Karte mit Linux kopieren

Ich muss wieder öfter SD-Karten backupen und kopieren, daher notiere ich mir hier ein für alle Mal die Kommandos unter Linux dazu. Vielleicht hilft’s noch wem.

Erstellen eines Backups

sudo dd bs=4M if=/dev/sdb | gzip > ./sd-card-img.gz

Zurückspielen eines Backups

sudo gzip -dc sd-card-ah2-rpi2-1ch-dragino.img.gz | sudo dd bs=4M of=/dev/sdb

Kopieren einer Karte

sudo dd bs=4M of=/dev/sdb of=/dev/sdc

 

WordPress Updates über Kommandozeile

Mittlerweile nutze ich für mehrere Projekte WordPress. Ich bin recht zufrieden, die Blogs laufen teilweise schon fast 3 Jahre und ich habe kaum Probleme.

Leider laufe ich immer wieder in Probleme beim Update über das Webinterface. Eine Alternative scheint zu sein, Updates per Kommandozeile auszuführen. Dazu gibt es das Werkzeug „wp-cli“, das ich hier kurz vorstellen möchte.

Installation von wp-cli

Das Werkzeug wird von dieser Adresse gedownloadet und getestet: https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ php wp-cli.phar --info

Wenn alles OK ist, installiere ich es als /bin/wp und setze das Execute-Bit:

$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /bin/wp

Nun kann ich es systemweit als „wp“ aufrufen. Für Aktionen sollte es als User laufen, mit dem auch WordPress betrieben wird. Dazu starte ich es über sudo und mit Hinweis auf den Installationspfad der WordPress-Dateien:

root@wp:~# sudo -u wp -i wp --path=/var/www/html --info
PHP binary: /usr/bin/php5
PHP version: 5.5.9-1ubuntu4.22
php.ini used: /etc/php5/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/wp
WP-CLI packages dir: 
WP-CLI global config: 
WP-CLI project config: 
WP-CLI version: 1.4.1

Updates

Updates spiele ich nun mit Hilfe von wp-cli ein. Damit lassen sich auch mehrere Updates über mehrere Installationen automatisieren. Mit dem Suffix „–all“ muss man nicht einzeln die Plugins anführen, sondern kann alle Plugins in einem Durchgang aktualisieren.

Plugins kann man mit diesem Kommando auf einmal updaten:

sudo -u wp -i wp --path=/var/www/html plugin update --all

Themes werden auf diesem Weg alle aktualisiert:

sudo -u wp -i wp --path=/var/www/html theme update --all

Und die Core Version von WordPress wird mit diesem Kommando auf den neuesten Stand gehoben:

sudo -u wp -i wp --path=/var/www/html core update

 

APRS über LoRa mit Dragino LoRa/GPS shield für 70cm-Band

In den letzten Monaten habe ich mich sehr viel mit LoRa und LoRaWAN beschäftigt. Bei den zahlreichen Treffen hat mir die Amateurfunk-Community erzählt, dass LoRa auch ein guter Ersatz für das FSK/AFSK basierte APRS sein könnte und an einer Implementierung arbeiten.

Das halte ich für eine tolle Idee! APRS hat mich – wie ihr an anderen Beiträgen meines Blogs erkennen könnt – schon immer sehr interessiert!

Es handelt sich also nur um den Ersatz der Modulation durch LoRa und nicht um eine vollwertige LoRaWAN-Implementierung, die ja auch das ganze Umfeld der Datenverarbeitung mit einschließen würde. Daher ist man auch hinsichtlich QRG (Frequenz) flexibel. Die Hardware für LoRa ist ja für 868 MHz, 433 MHz und 912 MHz erhältlich. Der Bereich um 912 MHz ist in der EU nicht frei nutzbar. Im „kommerziellen“ Einsatz (LoRaWAN) ist 868 MHz die Wahl für Europa.

Funkamateure sind sowieso im Bereich um 433 MHz „zu Hause“, das ja für viele Anwendungen als 70cm-Band bekannt ist und dort seitens Amateurfunk als Primärdienst genutzt werden kann.

Damit ist für mich die Trennung der Anwendungen und Frequenzen auch schlüssig umsetzbar:

  • LoRaWAN nutzen wir (kommerziell) auf 868 MHz und
  • LoRa für APRS im 430-439 MHz Bereich als Amateurfunkdienst!

APRS Tracker

Das Ziel ist also, einen APRS-Tracker zB. für’s Auto mit LoRa-Modulation im70cm-Band zu schaffen. Die Daten sollen dann wie andere APRS-Anwendungen über zB. aprs.fi zur Verfügung stehen.

Auf der Webseite von DJ7OO (http://www.kh-gps.de/lora.htm) wird sehr viel zu dem Thema erklärt. Die Software basiert auf Codeteilen, die von Stuart Robinson (ua. auf dieser Website https://www.rcgroups.com/forums/showthread.php?2454546-Arduino-LoRa-Long-Range-Lost-Model-Tracker) veröffentlicht wurden. Bitte beachtet die Lizenz, die hier kommerzielle Nutzung auch von Codeteilen ohne ausdrücklicher Zustimmung von Stuart untersagt.

Die meisten OMs haben ihre Sender auf Basis von Arduino Pro Mini erstellt. Dazu benötigt man noch ein paar Kleinteile, ua. ein GPS-Modul und den RFM98W LoRa-Chip.  Ich gestehe, das Löten vermeide ich, wenn es leicht möglich ist – daher habe ich nach einer andere Hardware-Lösung gesucht.

ohne löten: Dragino LoRa/GPS shield

Mit den LoRa/GPS-Shields von Dragino habe ich ja bereits in anderen Projekten gute Erfolge erzielt. Diese Shields sind natürlich auch für 433 MHz erhältlich. Ich kaufe übrigens meistens über Tindie. Es funktioniert zuverlässig, die Lieferung dauert ca. 3 Wochen:
https://www.tindie.com/products/edwin/loragps-shield-for-arduino/

Das Tolle ist, dass man dazu nur noch einen Arduino Uno benötigt, zusammensteckt und für viele Anwendungen eine fertige Lösung hat!

Als Basis für meinen Code habe ich die Version von Sascha (iot4pi.com) und Karl OE1KEB gewählt, die für den Arduino Pro Mini geschrieben ist:
https://github.com/IoT4pi/LoRa-APRS-Sender
(Den Link zu meinem Fork für’s Dragino LoRa/GPS findet ihr  unten.)

Die Software benutzt SoftSerial, um auf die GPS-Daten zuzugreifen. Dazu benötigt man zwei Jumper Wire Kabel (M-F). Am Dragino LoRa/GPS Shield werden die Jumper bei TX_GPS und RX_GPS entfernt und mit den digitalen Eingängen 3 und 4 verbunden werden.

Bitte beachtet, dass nur lizenzierte Funkamateure diesen Funkdienst benutzen dürfen, es wird auch ein Funkrufzeichen (Call) benötigt, das eingestellt werden muss!

Die von mir für das Dragino LoRa/GPS Shield abgeänderte Software findet ihr hier:

https://github.com/schulti/LoRa-APRS-Sender

Bitte ändert euren Call und ggf. die SSID („-12“)  in dieser Variable:

String Tcall="OE1SCS-12"; //your Call Sign

Die Software muss nun nur noch auf den Arduino raufgeladen werden und schon kann man testen. Der erste GPS-Fix dauert leider ein bißerl – da muss man etwas Geduld haben. An einer blinkenden LED sieht man, dass ein GPS-Fix vorhanden ist.

Ein Blick auf die Webseite https://aprs.fi hat den Tracker sofort gezeigt:

Auch die Rohdaten sehen vernünftig aus. Meine Pakete wurden von OE1XBR-10 empfangen:

Nun bin ich also zusätzlich zur 2m APRS Antenne über 70cm LoRa APRS unterwegs. Zusätzlich habe ich einen GPS Mapper für LoRaWAN (868 MHz):

Für’s Autodach habe ich eine Magnetfußantenne für 433 MHz und einen aktiven GPS-Empfänger bestellt. Das Shield hat eine GPS-Antenne eingebaut. Es schaltet von selbst um, sobald es erkennt, dass eine externe Antenne angesteckt wird.

Damit lassen sich ganz einfach Vergleichsfahrten zwischen den Technologien durchführen, zB: unten links LoRa-APRS-70cm mit APRS-2m im Vergleich (Argent Data OpenTracker+):

Einkaufsliste für den LoRa/GPS APRS Tracker

Die Bauteile sind um gesamt € 42,- erhältlich, um weitere €  15,- gibt’s die Antennen für’s Autodach dazu:

Optional:

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

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.

GPS am Dragino LoRA HAT

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.

LoRa Single Channel Gateway

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)

Empfehlung für eine LoRa Outdoor Antenne

Bei meinen Experimenten rund um das Thema LoRa haben wir natürlich mehrere Antennen probiert: die mitgelieferten Antennen sind total in Ordnung, auch die Magnetfußantennen für’s Auto haben sich bewährt, aber die größte Begeisterung habe ich für eine Außenantenne von WiMo entwickelt:

Die WiMo 18006.02 Groundplane für 800-1000 MHz um € 25,- hat es mir angetan.

Sämtliche Pakete kommen damit bis zum ca. 1km entfernten Gateway. Vorher waren es nur ca. 30%. Die Verbesserung ist damit ideal! Nach Herstellerangaben hat die Antenne 0 dBD (dBi?) Gewinn.

Ich habe sie über ein 1m Low Loss H-155 Kabel an eine Fensterdurchführung für GSM gehängt. Das 1m-Kabel hat SMA (für die Fensterdurchführung) und N-Stecker für die Antenne direkt drauf.

Am Foto ist sie mit einer Doppelkreuzschelle befestigt, so wie die Montage am Mast vorgesehen ist.

Stückliste zum Nachbestellen:

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!

Hobby, Technik, Erfahrungsberichte, …