Wer kennt "LoRa" Long Range Telemetrie?

Status
Nicht offen für weitere Antworten.
R

Rolf_

Erfahrener Benutzer
#161
#161
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 :D

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

Gruß Rolf
 
K

klausklaus

Benutzer
#162
#162
@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
 
R

Rangarid

Erfahrener Benutzer
#163
#163
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?
 
K

klausklaus

Benutzer
#164
#164
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
 
Zuletzt bearbeitet:
R

Rangarid

Erfahrener Benutzer
#165
#165
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.
 
K

klausklaus

Benutzer
#166
#166
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
 
Zuletzt bearbeitet:
R

Rangarid

Erfahrener Benutzer
#167
#167
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

For maximum flexibility theuser may decide on the spread spectrum modulation bandwidth (BW), spreading factor (SF) and error correction rate (CR).Another benefit of the spread modulation is that each spreading factor is orthogonal - thus multiple transmitted signals canoccupy the same channel without interfering. This also permits simple coexistence with existing FSK based systems.
Zum Vergrößern anklicken....
Auf gut deutsch: Mehrfache Sendesignale auf dem selben Kanal sind kein Problem.
 
Q

QuadMax

Erfahrener Benutzer
#168
#168
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.
lora1.8_Bild2.png

Von oben:
lora1.8_Bild1.png

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.
Lora-complete.png

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

Gruß
QuadMax
 

Anhänge

AndreasL90

AndreasL90

Erfahrener Benutzer
#169
#169
Nach einem Tipp von Rolf_ hab ich im Code die Zeile geändert (Neues unterstrichen):
Code: 
static const int RXPin = [u]A[/u]5, TXPin = [u]A[/u]6;  //pins for soft serial
Damit klappts bei mir nun auch mit Software Serial! Absolut logisch eigentlich. :D
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! :)
 
AndreasL90

AndreasL90

Erfahrener Benutzer
#170
#170
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?
 
K

klausklaus

Benutzer
#171
#171
AndreasL90 hat gesagt.:
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?
Zum Vergrößern anklicken....
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
 
Zuletzt bearbeitet:
AndreasL90

AndreasL90

Erfahrener Benutzer
#172
#172
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...
 
AndreasL90

AndreasL90

Erfahrener Benutzer
#173
#173
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.
 
Zuletzt bearbeitet:
K

klausklaus

Benutzer
#175
#175
Zuletzt bearbeitet:
R

Rangarid

Erfahrener Benutzer
#176
#176
Im Datenblatt auf Seite 17 folgend sieht man sehr gut die Sensitivitätswerte bei verschiedenen SF und BW Einstellungen:
sens1.png
sens2.png
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.
 
AndreasL90

AndreasL90

Erfahrener Benutzer
#177
#177
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...
 
Zuletzt bearbeitet:
AndreasL90

AndreasL90

Erfahrener Benutzer
#178
#178
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.
 
Zuletzt bearbeitet:
R

Rolf_

Erfahrener Benutzer
#179
#179
AndreasL90 hat gesagt.:
...Ich hab heute die Reichweite mit den gegebenen Paramtern getestet und bin schwer beeindruckt...
Zum Vergrößern anklicken....
Ja, man muss es erlebt haben, sonst glaubt man es nicht :D

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
 
AndreasL90

AndreasL90

Erfahrener Benutzer
#180
#180
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.
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten