Wer kennt "LoRa" Long Range Telemetrie?

Vielen vielen Dank für Deine Hilfe, ist mir schon peinlich, dass ich das nicht mehr "auf der Pfanne" hatte. Hatte die nicht gebrauchten Zeilen im Quellcode rausgeschmissen und dann ganz vergessen, dass Du den Code mitgeschickt hattest. Hatte Dein zipfile zur Sicherheit auch noch da und mir den GGA Teil rauskopiert.

Funktioniert einwandfrei

Ohne Deine Hilfe hätte das nicht geklappt. Vielen Dank nochmal.

Gruß Rolf

@Rolf

OK Prima, freut mich, dass es funktioniert.

Inzwischen konnte ich auch noch in meinem PN-Ordner sehen, dass ich Dir die Files bereits im letzten November geschickt hatte.

Gruß Klaus

Seh ich das richtig, dass die LoRa Module im Lora-Modus ein eingebautes Checksum haben? Dann ist es ja eigentlich nichtmehr nötig, die Daten selber zu checken oder? Wenn Daten nicht korrekt sind, werden die dann einfach verworfen?

Hallo,
Stuart Robinson hat einen neuen Thread mit dem Titel: "Easy Build - LoRa Long Range Lost Model Tracker" ins Netz gestellt: http://www.rcgroups.com/forums/showthread.php?t=2643322

Unter der URL: https://goo.gl/IeEiC1 geht es dabei zur Dropbox. Hier findet man einige Fotos, sowie seine aktuellen Softwareversionen und verschiedene auch neuere PDF's, wie z.B.:
“Long Distance Tracking and Monitoring with LoRa - Introduction - March 2016”
und "Self Tracking with LoRa - Bluetooth to Android - Jan 2016"
Letztere enthält auch Hinweise auf eine mir bis dahin nicht bekannte Android-App mit dem Namen "AlpineQuest". Sie ermöglicht u.a. die Darstellung zugelieferter NMEA-Positionsdaten auch unter Verwendung von Offline-Kartenmaterial.

@Rangarid
Im Detail habe ich das nicht untersucht, aber es schon richtig, dass empfangene Daten dann unterdrückt werden, wenn sie als gestört übertragen erkannt wurden.

Wenn es z.B. um einzelne GPS-Navigationsdaten geht und diese erst wieder auf der Empfangsseite zu kompletten NMEA-Protokollen zusammengefügt werden, dann ist an dieser Stelle in der Regel auch eine neu kalkulierte Prüfsumme anzufügen. Ohne sie würden die meisten auswertenden GPS-Programme streiken.

Gruß Klaus

Hab mir eben mal den Code von cesco1 genauer angeschaut. Da wird in der Tat CRC ausgewertet. Funktioniert auch sehr gut. Das spart dann schonmal Daten, die Übertragen werden müssen.

Bekomme bei 8 Kanälen RC, die übertragen werden müssen eine Update Rate von ~80 frames/Sekunde hin mit der Einstellung Bw 250, Spread 6, CR 4/5.

Was ich mich jetzt noch frage ist, wie man zwischen verschiedenen Sendern/Empfängern unterscheiden kann. Man kann natürlich ein paar Zeichen als Kennung extra mit übertragen, die dann im RX überprüft werden. Somit könnte man schon zwischen verschiedenen Sendern unterscheiden. Was ich mich dann aber frage ist, wie kommt der RX damit klar, wenn mehrere TXe rumspammen....

Kann mal jemand testen, was passiert wenn mehrere Sendeeinheiten senden und nur ein Empfänger zuhört? Meine Erwartung wäre, dass die Daten dann kunterbunt durcheinander reinkommen.

Hallo Rangarid,
soweit mir bekannt ist, gibt es einen Tx-Steuerbefehl zur Festlegung der verwendeten TX-Destination ( 0-255 ) und für erfolgreiche Datenübertragungen muss dieser mit einem auf der Empfangsseite verwendeten TX-Sourcebefehl übereinstimmen.

Inwieweit sich mehrere auf der gleichen Frequenz mit unterschiedlichen Adresscodes arbeitende Einheiten in die Quere kommen, das lässt sich sicher nur durch praktische Tests ermitteln. Gefühlsmäßig bin ich dabei allerdings erst einmal sehr skeptisch.

Gruß Klaus

In der RadioHead Bibliothek gibt es einen 4byte Header der besteht aus FROM, TO, ID, FLAGS. Diese werden allerdings im Payload selbst übertragen, also im eigentlichen Datentransfer.

Habe deshalb bei mir jetzt mal eine RX_ID und eine TX_ID eingeführt, die ich beide mit übertrage. Dadurch geht die Framerate von 80-82 auf 76-77 runter. Ist für mich kein großer Verlust, daher mach ich es jetzt so.

Im Datenblatt vom RFM95 steht noch drin

Auf gut deutsch: Mehrfache Sendesignale auf dem selben Kanal sind kein Problem.

kleines Hardwareupdate

Die Platine ist jetzt zwar um knapp 5 mm gewachsen,
dafür lässt sich die SMA-Buchse jetzt mechanisch bestmöglich befestigen.


Von oben:


Außerdem habe ich die Platine gleich zu einem Set zusammengefasst.
Enthalten ist 2x das Board selbst, 1x ein 1,28mm auf 2,54mm Adapter
und 1x Adapter zum Flashen des Bootloaders.


Die Größenangaben sind in Meter, da mein 3D Programm nicht in Bruchteilen von Millimetern arbeiten kann.
Im Anhang die Eagle Dateien.

Gruß
QuadMax

Nach einem Tipp von Rolf_ hab ich im Code die Zeile geändert (Neues unterstrichen):
Damit klappts bei mir nun auch mit Software Serial! Absolut logisch eigentlich.
Auch die von Rolf angesprochene Änderung der TinyGPS++ Library scheint zu klappen; ein Test steht aber noch aus. Ich berichte weiter...

@QuadMax
Sehr schön; sieht gut aus!

So, bei mir klappts jetzt auch - vielen Dank für die Hilfe!

Wenn ich im Sketch der Senderseite den Delay in der Funktion displayInfo von 7000 auf 1000 senke müssten die Daten doch im Sekundentakt gesendet werden, oder? Gibt's dabei einen Haken?

Hallo Andreas,
ich vermute einmal, dass sich Deine Anfrage auf den Sketch "LoRa_Tracker_TX2" u.Ä. bezieht. Die Sendefolge setzt sich dabei aus dem Delaywert am Ende des Loops und der Zeit zusammen, in der der Sender "On Air" ist und seine Daten aussendet ( hierbei leuchtet die TX-LED ). Mit den angegebenen TX-Parametern ergibt sich dabei ein Gesamtwert von etwa 10 Sekunden. Das bedeutet, dass die Sendefolge bei einem Delaywert 1000 immer noch bei etwa 4 Sekunden liegen wird und Folgen unter ca. 3 Sekunden mit den hier verwendeten Parametern nicht möglich sind.

Ergänzung: Habe gerade noch einmal nachgeschaut: Mit den benutzten Parametern: lora_BW41_7, lora_SF12, lora_CR4_5 ergibt sich eine OnAir-Zeit von etwa 3,2 Sec.
Bei z.B. SF8 und ansonsten identischen Parametern würden es dagegen nur 234mS sein.
Ein lineares Verhältnis besteht auch zwischen den Werten für Bandbreite ( BW ) und den OnAir-Zeiten. So reduziert sich die OnAir-Zeit bei z.B. dreifacher Bandbreite (125KHz) auf ein Drittel des vorgenannten Wertes und liegt nur noch bei ca. 1 Sec.

Klaus

Hallo Klaus,

ich nehme an, dass mit einem Spreading Factor von SF=8 die Reichweite reduziert wird. Ist das korrekt?

Ansonsten bin ich noch auf der Suche nach einer Windows Software, mit der die NMEA Daten live dargestellt werden können. (Falls jemand eine kennt...?)
Google Earth klappt leider nicht auf Anhieb; ich vermute, dass die vom Arduino ausgegebenen NMEA Daten nicht dem Standard Entsprechen, den GE erwartet. Evtl. liegt das Problem auch darin, dass die GPS Zeit bei jedem Paket hardgecoded mit "000000" ausgegeben wird. Die Zeit auch zu übertragen würde wiederrum mehr OnAir Zeit bedeuten...

Zur Darstellung in Google Earth (funktioniert nun):
Ich hab verschiedene Wege, die empfangenen Daten in GE zu visualisieren, getestet. Darunter die in GE eingebaute Funktion des real-time trackings (Tools -> GPS -> Realtime) oder moving map addons (z.B. Earth Link, GooPs, ...). Das Alles hat nicht wirklich funktioniert, leider. In Matlab/Simulink war schnell ein Modell zusammengebaut, das auch funktioniert, aber die Visualisierung war nicht wirklich ansprechend.
Die jetzige Lösung ist vllt. für den Ein- oder Anderen interessant und wirklich einfach. Und zwar lässt sich in U-Center ebenfalls GE öffnen (View -> Google Earth), wo die empfangenen Positionsdaten auch schön angezeigt werden, auch in 3D. Die Daten können darin auch abgespeichert werden. Was will man mehr?

Werde heute mal versuchen die Datenrate hochzuschrauben und ein paar Tests im Freien zu machen. Die momentan verbauten Draht-Antennen tausche ich gegen SMA Buchsen und eine SRH771 von Diamond bzw. 3-Element Yagi von Arrow Antennas.

Hallo Andreas,
auf der Seite: http://www.rcgroups.com/forums/showthread.php?t=2643322 stellt ein KB1RLI ein Windows-Programm vor, das Deinen Vorstellungen ggf. entsprechen könnte. Die angegebene Link scheint erst einmal nur zu einer Programmsimulation zu führen, aber sicherlich gibt es dazu demnächst auch noch mehr Informationen.

Gruß Klaus

Ja, so ist es. Für das Link-Budget ergibt sich zwischen SF12 und SF8 ein Unterschied von 10db.

Die meisten infrage kommenden Berechnungen sind mit dem "LoRa Modem Calculator Tool" von SEMTECH durchführbar: http://sx1272-lora-calculator.software.informer.com/0.0/

Gruß Klaus

Im Datenblatt auf Seite 17 folgend sieht man sehr gut die Sensitivitätswerte bei verschiedenen SF und BW Einstellungen:


So kannst du schauen, welche Konfigurationen ähnliche Sensitivität haben. BW125 mit SF12 hat zb nur 3db weniger als BW 64 mit SF12 und sollte durch die doppelte Bandbreite schon fast doppelt so schnell sein.

Danke für die Tipps! Der Calculator ist wirklich hilfreich... Die Werte für "Time On Air" entsprechen denen aus der Praxis. Beim Erhöhen der Bandbreite auf BW125 ergibt sich eine "Time On Air" von einem Drittel (ca. 1s) und 4dB weniger Sensivität.

Zum Test mit den Default werten: Ich hab heute die Reichweite mit den gegebenen Paramtern getestet und bin schwer beeindruckt. Der Sender (SRH771) stand in einer 2m Vertiefung und im am weitesten entfernten Punkt (600m) waren zwischen TX und RX (3-element Yagi; nicht wirklich exakt ausgerichtet) mehrere Gebäude und die Autotür. Dabei gabs immernoch ein PacketSNR zwischen +2db und +6db und das mit dem Noisefloor hier am Campus (TUM).
Der nächste Schritt ist ein Test mit erhöhter Bandbreite...

Erster Test mit BW125 und delay(1000): Geht gut; Updates kommen wie berechnet ca alle 2s rein. Reichweitentest steht aus... (Werde ich nachreichen)

Ansonsten gibts momentan das Problem, dass ich keine Höheninformationen mehr bekomme. Ab- und an sporadisch (seltenst) schon. Da muss ich der Ursache mal auf den Grund gehen...
Edit: Der GNSS Empfänger gibt an U-Center die Höhe aus. Das Problem muss also woanders liegen.

Ja, man muss es erlebt haben, sonst glaubt man es nicht

Zur Rocket Locator App: Habe da leider in der ersten Euphorie eine missliche Fehlfunktion übersehen. Die Übertragung klappt einwandfrei, alle 11 Sekunden etwa gibt es einen "Ping" als Bestätigung für den neu eingegangenen NMEA Datensatz. Aber leider wird der nicht aktualisiert. Das Programm zeigt durchgehend lediglich den ersten empfangenen Positionsdatensatz an. Muss da noch was rumspielen. Vielleicht liegt es ja nur an CR+LF oder nur CR als EOL-Zeichen. Man steckt nicht drinnen und die Homepage ist leider weiter vom Netz.
Im Log findet sich jeweils:
GPS Connected
$GPGGA,000000,..... usw. (auch mit neuer Position - angezeigt wird aber nur die erste eingegangen Position)
GPS Disconnected

Gruß Rolf

Wegen dem Problem mit der Höhe: Ich hab den OutputString seriell am TX ausgeben lassen und darin bleibt die Höhe konstant auf 0 (siehe dritter Wert):

>> OutputString is 48.26675,11.67075, 0,0.00,*

Wie Oben beschrieben gibt der GNSS Empfänger in U-Center aber eine Höhe aus; am Empfänger liegt es also nicht.
Anmerkung: 0.00 steht dabei für die Batteriespannung VBat. Es wurde keine Batterie verwendet, daher ist der Wert gleich Null.
Hat jemand eine Idee, woran das liegen könnte?

Edit: Hab eben nochmal den unveränderten original Code, wie ich ihn von Klaus bekommen hab, geladen. Auch damit bleibt die Höhe auf 0.