Wer kennt "LoRa" Long Range Telemetrie?
- Themenstarter klausklaus
- Beginndatum
- Status
Mit OSH Park habe ich mich noch nicht beschäftigt. Werde ich mir anschauen.
Da ich schon danach gefragt wurde, weil der Zip keine Lizenz beiligt:
Lora Telemetry Hardware is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International License.
Kurzum: Jeder darf es benutzen, auch kommerziell.
Einzige Einschränkungen sind ein Verweis und bei kommerzieller Nutzung die Offenlegung der Produktionspläne (share alike).
Open Source eben
.
Ich würde es im Moment noch ungern bei einem Platinenlieferanten veröffentlichen,
da sich das Design zu schnell verändert.
Wenn du dort jetzt schon bestellen möchtest, kannst du es gerne jetzt schon hochladen.
Ich habe hier noch ein paar Platinen der Version 1.4. :
1.47 Gramm unbestückt!
Und noch einen kleinen Stand zum flashen des Bootloaders mit integriertem Anschluss für einen ftdi Adapter.
Kam gestern an. *freu*
Ein reiner Platinen-Gruppenkauf hat den Nachteil, dass man den Arduino noch selbst flashen muss,
was ohne Adapter von den zwei 1,27mm Stiftleisten schwierig ist.
Mit normalem Lötkolben halte ich das Design auch nicht mehr für lötbar.
Da die meißten keine Heißluftanlage haben macht eine Bestückung bei der Platinen Fertigung in meinen Augen schon Sinn, allerdings muss man dann dort auch eine Mindestmenge abnehmen.
Da die Interessentengruppe im Moment jedoch viel zu klein ist, läuft es wohl auf eine reine Platinenbestellung raus.
Falls Interesse an den Platinen der V1.4 und einem Stand zum flashen besteht, gerne eine PN an mich.
Da ich schon danach gefragt wurde, weil der Zip keine Lizenz beiligt:
Lora Telemetry Hardware is licensed under a
Creative Commons Attribution-ShareAlike 4.0 International License.
Kurzum: Jeder darf es benutzen, auch kommerziell.
Einzige Einschränkungen sind ein Verweis und bei kommerzieller Nutzung die Offenlegung der Produktionspläne (share alike).
Open Source eben
.Ich würde es im Moment noch ungern bei einem Platinenlieferanten veröffentlichen,
da sich das Design zu schnell verändert.
Wenn du dort jetzt schon bestellen möchtest, kannst du es gerne jetzt schon hochladen.
Ich habe hier noch ein paar Platinen der Version 1.4. :
1.47 Gramm unbestückt!
Und noch einen kleinen Stand zum flashen des Bootloaders mit integriertem Anschluss für einen ftdi Adapter.
Kam gestern an. *freu*
Ein reiner Platinen-Gruppenkauf hat den Nachteil, dass man den Arduino noch selbst flashen muss,
was ohne Adapter von den zwei 1,27mm Stiftleisten schwierig ist.
Mit normalem Lötkolben halte ich das Design auch nicht mehr für lötbar.
Da die meißten keine Heißluftanlage haben macht eine Bestückung bei der Platinen Fertigung in meinen Augen schon Sinn, allerdings muss man dann dort auch eine Mindestmenge abnehmen.
Da die Interessentengruppe im Moment jedoch viel zu klein ist, läuft es wohl auf eine reine Platinenbestellung raus.
Falls Interesse an den Platinen der V1.4 und einem Stand zum flashen besteht, gerne eine PN an mich.
Zuletzt bearbeitet:
GPS-Vorschlag für den "LoRa"-Finder:
Ein Forumsfreund hat mich auf folgendes preisgünstiges M8N-GPS hingewiesen:
http://www.banggood.com/Ublox-NEO-M...tive-Shell-for-PIX-PX4-Pixhawk-p-1005394.html
Im Gegensatz zu manch anderem billigen China-M8N zeichnet sich das obige durch einen überraschend guten und schnellen Empfang (manch andere brauchen mehr als 10 Minuten, bis sie alle verfügbaren Sats empfangen) nach Kaltstart aus. Das hat nach Kaltstart etwa nach einer Minute spätestens einen 3D fix. Dazu ist es relativ klein (Durchmesser 4,5 cm, knapp 1 cm Höhe an der dicksten Stelle) und wiegt mit dem Kabel 20 etwa Gramm.
Eigentlich wird es für den Pixhawk angeboten (also Speisespannung 5 Volt, Rx,Tx 3,3 Volt).
Das GPS funktioniert aber einwandfrei mit 3,3 Volt Versorgungsspannung.
Zum Testen habe ich es an ein 3,3 Volt USB-UART angeschlossen. Auf dem PC ist die U-Blox Software https://www.u-blox.com/de/product/u-center-windows zum Parametrisieren erforderlich.
Die Farben (vorausgesetzt, die Chinesen ändern da nichts) der am Anschlusskabel herausgeführten UART1 Schnittstelle:
Rot = Vcc
Weiß = Rx
Gelb = Tx
Schwarz = GND
Die I2C Schnittstelle für den Magnetkompass brauchen wir hier nicht ( Grün = SCL, Blau = SDA).
Die Schnittstelle war werksseitig auf 38400 und NMEA eingestellt.
In der U-BLOX-GUI ist es die UART1-Schnittstelle. Beim Ändern keinesfalls bei "UART1 Input" UBX abwählen, dann könnte man sich erfolgreich ausschließen. An ein Fenster mit freiem Blick nach Süden wird rasch auch PNR 120 für das EGNOS Korrektursignal erkannt.
Gruß Rolf
Ein Forumsfreund hat mich auf folgendes preisgünstiges M8N-GPS hingewiesen:
http://www.banggood.com/Ublox-NEO-M...tive-Shell-for-PIX-PX4-Pixhawk-p-1005394.html
Im Gegensatz zu manch anderem billigen China-M8N zeichnet sich das obige durch einen überraschend guten und schnellen Empfang (manch andere brauchen mehr als 10 Minuten, bis sie alle verfügbaren Sats empfangen) nach Kaltstart aus. Das hat nach Kaltstart etwa nach einer Minute spätestens einen 3D fix. Dazu ist es relativ klein (Durchmesser 4,5 cm, knapp 1 cm Höhe an der dicksten Stelle) und wiegt mit dem Kabel 20 etwa Gramm.
Eigentlich wird es für den Pixhawk angeboten (also Speisespannung 5 Volt, Rx,Tx 3,3 Volt).
Das GPS funktioniert aber einwandfrei mit 3,3 Volt Versorgungsspannung.
Zum Testen habe ich es an ein 3,3 Volt USB-UART angeschlossen. Auf dem PC ist die U-Blox Software https://www.u-blox.com/de/product/u-center-windows zum Parametrisieren erforderlich.
Die Farben (vorausgesetzt, die Chinesen ändern da nichts) der am Anschlusskabel herausgeführten UART1 Schnittstelle:
Rot = Vcc
Weiß = Rx
Gelb = Tx
Schwarz = GND
Die I2C Schnittstelle für den Magnetkompass brauchen wir hier nicht ( Grün = SCL, Blau = SDA).
Die Schnittstelle war werksseitig auf 38400 und NMEA eingestellt.
In der U-BLOX-GUI ist es die UART1-Schnittstelle. Beim Ändern keinesfalls bei "UART1 Input" UBX abwählen, dann könnte man sich erfolgreich ausschließen. An ein Fenster mit freiem Blick nach Süden wird rasch auch PNR 120 für das EGNOS Korrektursignal erkannt.
Gruß RolfHabe nicht alles gelesen, nur mal die letzten Seiten überflogen. Diese Platine von Quadmax, kann man damit auch Fernsteuerung übertragen? Steht noch das Angebot für eine Sammelbestellung?
Ansonsten sind diese Platinen auch sehr interessant:
http://www.anarduino.com/miniwireless/
Ist LoRa mit Arduino integriert. Damit sollte es auf jedenfall auch gehen, ist halt ein bisschen größer...
Ansonsten sind diese Platinen auch sehr interessant:
http://www.anarduino.com/miniwireless/
Ist LoRa mit Arduino integriert. Damit sollte es auf jedenfall auch gehen, ist halt ein bisschen größer...
@Rolf
Die $10 neo6 schalten auch sehr schnell auf WENN sie noch aktuelle daten im speicher haben. Falls die interne batterie aber unten ist dann dauert das sehr lange, 10 min oder mehr. Mein neo6 das im bixler fliegt hat aufschaltzeiten von 30 bis 60 sekunden. Hast du erfahrungswerte für das neo7 und neo8?
@rangarid
Ich hab mal was funktionsfähiges für RC gehabt. Die modeumschaltung bei schlechtem empfang hab ich aber nicht gemacht. Dazu brauchts duplex und das hab ich nie probiert.
Speed war folgendermassen
// modefast BW 250khz, S 6, C 4_5 duration 10 ms
// modefast BW 125khz, S 6, C 4_5 duration 20 ms
// modeslow BW 62khz, S 10, C 4_5 duration 472 ms
Mit 1 sekunde latenzzeit kann man keinen flieger steuern. Man kann aber eine FC steuern, wegpunkte umschalten etc. Eine auto-umschaltung schnell/langsam für start/landung und strecke ist nötig.
Vorteil gegenüber den si4432 systemen (openlrs) is nur der langsam mode. Bei schnellen modes (9k6 und 4k8) dürften beide chips etwa gleiche performance haben (vermute ich).
Die $10 neo6 schalten auch sehr schnell auf WENN sie noch aktuelle daten im speicher haben. Falls die interne batterie aber unten ist dann dauert das sehr lange, 10 min oder mehr. Mein neo6 das im bixler fliegt hat aufschaltzeiten von 30 bis 60 sekunden. Hast du erfahrungswerte für das neo7 und neo8?
@rangarid
Ich hab mal was funktionsfähiges für RC gehabt. Die modeumschaltung bei schlechtem empfang hab ich aber nicht gemacht. Dazu brauchts duplex und das hab ich nie probiert.
Speed war folgendermassen
// modefast BW 250khz, S 6, C 4_5 duration 10 ms
// modefast BW 125khz, S 6, C 4_5 duration 20 ms
// modeslow BW 62khz, S 10, C 4_5 duration 472 ms
Mit 1 sekunde latenzzeit kann man keinen flieger steuern. Man kann aber eine FC steuern, wegpunkte umschalten etc. Eine auto-umschaltung schnell/langsam für start/landung und strecke ist nötig.
Vorteil gegenüber den si4432 systemen (openlrs) is nur der langsam mode. Bei schnellen modes (9k6 und 4k8) dürften beide chips etwa gleiche performance haben (vermute ich).
Zuletzt bearbeitet:
Kannst du deinen Code mal zum anschauen zur Verfügung stellen?
Welche Reichweite hattest du in den Modes 250khz und 125khz? Hast du da mal was gemessen? Ich möchte ehrlich gesagt garnicht long range fliegen sondern nur eine zuverlässige Alternative zu 2.4G RC haben. Deshalb wäre mir eigentlich schon die Reichweite von 2.4G ausreichend. Denke das sollte auch mit den schnelleren Modi erreichbar sein.
20ms ist jedenfalls sogar noch niedriger als jedes 2.4G System mit >= 8 Kanälen. Früher war ja ~22ms üblich. Aber selbst Frsky benutzt ja inzwischen 27ms für 8 Kanäle.
Welche Reichweite hattest du in den Modes 250khz und 125khz? Hast du da mal was gemessen? Ich möchte ehrlich gesagt garnicht long range fliegen sondern nur eine zuverlässige Alternative zu 2.4G RC haben. Deshalb wäre mir eigentlich schon die Reichweite von 2.4G ausreichend. Denke das sollte auch mit den schnelleren Modi erreichbar sein.
20ms ist jedenfalls sogar noch niedriger als jedes 2.4G System mit >= 8 Kanälen. Früher war ja ~22ms üblich. Aber selbst Frsky benutzt ja inzwischen 27ms für 8 Kanäle.
Für das Neo8: Der Unterschied liegt ja in den Antennen, Pufferbatterien und weiterer Peripherie um den UBLOX-Chip herum (Daher ist es egal, ob N6,7 oder 8). Die CSG in der 80 Euro Klasse sind da um Welten schneller als 20-40 Euro China Produkte. Erfahrung von verschiedenen Koptern , mit unterschiedlichen GPS aufgebaut und die objektiven Daten (Fixtyp, N-Sat, HDOP) im Log des Pixhawks ausgelesen. Daher ist mir das oben als positive Ausnahme aufgefallen.
Gruß Rolf
Gruß Rolf
Ich hängs an. Wo ist denn das wieder .. ich suchs noch.
btw 20ms ist die paket-sendedauer. Die frame time ist grösser.
Warum nimmst du dann nicht openlrs it dem si4432 chip? Fertig und schneller.
LoRa ist nicht besser als openlrs, nur der trade-off ist anders. Openlrs ist schneller, lora hat bessere reichweite. Wenn beide auf die gleiche geschwindikeit eingestellt sind haben sie vermutlich auch die gleiche reichweite.
btw 20ms ist die paket-sendedauer. Die frame time ist grösser.
Warum nimmst du dann nicht openlrs it dem si4432 chip? Fertig und schneller.
LoRa ist nicht besser als openlrs, nur der trade-off ist anders. Openlrs ist schneller, lora hat bessere reichweite. Wenn beide auf die gleiche geschwindikeit eingestellt sind haben sie vermutlich auch die gleiche reichweite.
Zuletzt bearbeitet:
Klar, aber im Moment sieht es so aus, als ob keine 30 Einheiten zusammen kommen.
Darunter könnte man zwar auch produzieren lassen,
allerdings sind selbst bei 30 Stück der größte Teil Fixkosten und darunter wird es schnell einfach zu teuer.
Meine sind kleiner, leichter und bieten die Möglichkeit eine Antenne mit SMA Anschluss anzuschrauben.
(Wobei man hier Äpfel mit Birnen vergleicht)
Darunter könnte man zwar auch produzieren lassen,
allerdings sind selbst bei 30 Stück der größte Teil Fixkosten und darunter wird es schnell einfach zu teuer.
Meine sind kleiner, leichter und bieten die Möglichkeit eine Antenne mit SMA Anschluss anzuschrauben.
(Wobei man hier Äpfel mit Birnen vergleicht
)
So, Hardware ist im Prinzip so weit. Fehlt nurnoch die Verkabelung, dann kann die kommenden Tage getestet werden. Anstatt der Lambda/4 Antenne wird noch eine SMA Buchse angelötet und ein Dipol (Senderseitig) bzw. eine Yagi oder ein Dipol (Empfangsseitig) verwendet.
Die Antennen werden vermessen und sind dann optimal abgestimmt. Damit beschäftigt sich ein Nachrichtentechnik-Student, der sich evtl. auch mit Impedanzanpassung beschäftigen will - ka was da geht.
Die Antennen werden vermessen und sind dann optimal abgestimmt. Damit beschäftigt sich ein Nachrichtentechnik-Student, der sich evtl. auch mit Impedanzanpassung beschäftigen will - ka was da geht.
Anhänge
Zuletzt bearbeitet:
Bin auch schon sehr gespannt. Es ist noch etwas andere Arbeit dazwischen gekommen, aber evtl. klappts diese Woche noch mit dem Test.
Klaus hat darauf hingewiesen, dass der Arduino Code und die darin verwendete TinyGPS++ Library lediglich die GPGGA (GPS) Message auslesen kann. Das MAX-M8Q gibt aber GNGGA (GPS+GLONASS) aus. Das sollte aber in U-Center konfigurierbar sein, oder?
Nächsten Monat planen wir, das System auf einer Experimentalrakete zu testen. Mal sehen, wie sich der Dopplershift auswirkt. Am Boden sollen die Daten live in Google Earth oder STK geplottet werden.
Klaus hat darauf hingewiesen, dass der Arduino Code und die darin verwendete TinyGPS++ Library lediglich die GPGGA (GPS) Message auslesen kann. Das MAX-M8Q gibt aber GNGGA (GPS+GLONASS) aus. Das sollte aber in U-Center konfigurierbar sein, oder?
Nächsten Monat planen wir, das System auf einer Experimentalrakete zu testen. Mal sehen, wie sich der Dopplershift auswirkt. Am Boden sollen die Daten live in Google Earth oder STK geplottet werden.
Wenn Du auf der GNSS Config Seite alle Systeme bis auf "GPS"das enable-Häckchen weg machst, zeigt die Textausgabe richtigerweise $GPGGA. dafür wird leider auch nur das amerikanische NAVSTAR empfangen. SBAS kannst Du noch dazu nehmen, aber sobald GLONASS aktiviert wird, zeigt die Textausgabe $GNGGA. Letztlich müsst man ja "nur" eine Auswerteroutine für die Textzeile mit Kommaseparierten Feldern schreiben oder in der Routine den Buchstaben ändern. Die Felder sind ja identisch.
U-Center lässt mich in der GNSS Config zwar die Häkchen vor GLONASS und Beidou entfernen, aber die Einstellungen lassen sich nicht speichern. Da kommen dann automatisch wieder die Default Einstellungen. (Ja, ich bin zuerst auf Send und dann auf Save Configuration - mit anderen Einstellungen klappt es wie gewohnt)
Sprich ich bekomme keine GPGGA Ausgabe hin; nur GNGGA. Hat jemand eine Idee woran das liegt?
Dann hab ich die Library wie hier beschrieben geändert: https://github.com/mikalhart/TinyGPSPlus/pull/11/commits/0767b8b774818c3909670a3bbbf06f8215184785
Da ja, wie du sagst, die Felder identisch sind, hab ich auch mal alle P zu N geändert.
Selbes Resultat: Am Sender wird "No GPS detected!" ausgegeben. (TX->RX zwischen GPS und Arduino ist korrekt angeschlossen)
D.h. gps.charsProcessed() ist kleiner 10. Heißt das nun, dass keine Daten empfagen werden oder dass sie nicht interpretiert werden können?
Edit: Das MAX-M8 zieht laut Datenblatt 25mA (@3V). Das RFM98W bis zu 120mA (@100mW). Der Spannungsregler vom Pro Mini kann angeblich mit bis zu 150mA belastet werden - sollte also passen?
Sprich ich bekomme keine GPGGA Ausgabe hin; nur GNGGA. Hat jemand eine Idee woran das liegt?
Dann hab ich die Library wie hier beschrieben geändert: https://github.com/mikalhart/TinyGPSPlus/pull/11/commits/0767b8b774818c3909670a3bbbf06f8215184785
Da ja, wie du sagst, die Felder identisch sind, hab ich auch mal alle P zu N geändert.
Selbes Resultat: Am Sender wird "No GPS detected!" ausgegeben. (TX->RX zwischen GPS und Arduino ist korrekt angeschlossen)
D.h. gps.charsProcessed() ist kleiner 10. Heißt das nun, dass keine Daten empfagen werden oder dass sie nicht interpretiert werden können?
Edit: Das MAX-M8 zieht laut Datenblatt 25mA (@3V). Das RFM98W bis zu 120mA (@100mW). Der Spannungsregler vom Pro Mini kann angeblich mit bis zu 150mA belastet werden - sollte also passen?
Zuletzt bearbeitet:
Ich würde lediglich die Zeile
#define _GPGGAterm "GPGGA"
in
#define _GPGGAterm "GNGGA"
ändern.
Bist Du sicher, dass die Änderungen abgespeichert wurden ?
Stimmen Baudrate und Protokollausgabe ? (Configure - PRT (Ports))
Die Positionsbestimmungen habe ich auf 1 HZ reduziert () und die NMEA Ausgabe bis auf $GNGGA weggeschaltet.
Zur Kontrolle ziehe ich das GPS ab und stecke es neu an, um in UBLOX zu checken, dass die Änderungen erfolgten.
#define _GPGGAterm "GPGGA"
in
#define _GPGGAterm "GNGGA"
ändern.
Bist Du sicher, dass die Änderungen abgespeichert wurden ?
Stimmen Baudrate und Protokollausgabe ? (Configure - PRT (Ports))
Die Positionsbestimmungen habe ich auf 1 HZ reduziert () und die NMEA Ausgabe bis auf $GNGGA weggeschaltet.
Zur Kontrolle ziehe ich das GPS ab und stecke es neu an, um in UBLOX zu checken, dass die Änderungen erfolgten.
Das Hauptproblem ist momentan, dass keine einzige Einstellung übernommen wird. (In den einzelnen Menüpunkten auf "Send", dann in CFG auf "Save current configuration" - ist doch korrekt, oder?)
Nach dem Trennen der Verbindung (erst in der Software, dann Abstecken) ist wieder Alles auf den Grundeinstellungen. Woran könnte das denn liegen?
In den Grundeinstellungen erfolgt nicht die gewünschte Datenausgabe - kein Wunder also, dass der LoRa Sender auch kein GPS erkennt...
Edit: Kann es sein, dass der Ublox Chip die Daten nicht speichert, wenn er stromlos ist? Also auch ohne angeschlossene Knopfzelle?
Edit2: OK; der M8Q hat scheinbar keinen Flash Speicher, sondern nur ROM. Und dafür muss tatsächlich eine Batterie vorhanden sein, damit die Eintstellungen nicht vergessen werden. Ich besorg mir eine entsprechende Batterie und dann sollte es klappen! ^^
Nach dem Trennen der Verbindung (erst in der Software, dann Abstecken) ist wieder Alles auf den Grundeinstellungen. Woran könnte das denn liegen?
In den Grundeinstellungen erfolgt nicht die gewünschte Datenausgabe - kein Wunder also, dass der LoRa Sender auch kein GPS erkennt...
Edit: Kann es sein, dass der Ublox Chip die Daten nicht speichert, wenn er stromlos ist? Also auch ohne angeschlossene Knopfzelle?
Edit2: OK; der M8Q hat scheinbar keinen Flash Speicher, sondern nur ROM. Und dafür muss tatsächlich eine Batterie vorhanden sein, damit die Eintstellungen nicht vergessen werden. Ich besorg mir eine entsprechende Batterie und dann sollte es klappen! ^^
Zuletzt bearbeitet:
- Status
