LC29H(XX) GPS/RTK HAT

ullisun58 said:
Bonjour Bernard,
How are you doing? Hope you are well. May I ask you which ESP Lora Dev-Kit you used?
My RoπLawnMow works well with the RTK LC29HDA but and the NTRIP Service. My next improvement should be to use my Base Station and transmitt the Correction Data via Lora. And by the way as you remember my first steps here in this Forum, you advised me tu use Ultrasonic Distance Sensors. Last week I changed the ToF to HC-SR04 the reason, the Sun was shining so intensive we never had during the last years and the ToFs didn't provide correct data because of that.
Best regards
Ulli
Click to expand...
I'm doing well, thanks. I tested with ESP32 Heltec LORA V2, but despite all my investigations, it was impossible for me to use LORA to send corrections at correct rate to the rover.
Data transimission speed in LORA is too slow for that.
I finally simply use 2 simple ESP32 with antenna, but you need to have WIFI on your garden and at the base location.
Code is a simple UDP server that send data to client

I have not yet tested the esp-now protocol, maybe it can do the stuff
 
Bernard said:
I'm doing well, thanks. I tested with ESP32 Heltec LORA V2, but despite all my investigations, it was impossible for me to use LORA to send corrections at correct rate to the rover.
Data transimission speed in LORA is too slow for that.
I finally simply use 2 simple ESP32 with antenna, but you need to have WIFI on your garden and at the base location.
Code is a simple UDP server that send data to client

I have not yet tested the esp-now protocol, maybe it can do the stuff
Click to expand...
Thanks Bernard for your fast reply, several month ago when i started my investigations with RTK i also read that Lora is not fast enough. View days ago i found more than one youtube videos, and they uses lora https://www.youtube.com/watch?v=EUVoXCHFp2c but that are not DIY RTK. But the transmission rate should be the same, also I assume that Momotion Mowers use Lora to transmit the correction Data.
But nevertheless, Thanks for your hints again.
 
Alternativ kannst du ja mal die ESPs im long-range-mode probieren. Angeblich sollst du damit bis zu 650m Reichweite haben. Selbst habe ich das noch nicht probiert. Wichtig ist, dass du beide ESPs (STA und AP) in den long-range-mode versetzt.
Anleitung gibt es hier.

Viel Erfolg
Jürgen
 
Silberstreifen said:
Alternativ kannst du ja mal die ESPs im long-range-mode probieren. Angeblich sollst du damit bis zu 650m Reichweite haben. Selbst habe ich das noch nicht probiert. Wichtig ist, dass du beide ESPs (STA und AP) in den long-range-mode versetzt.
Anleitung gibt es hier.

Viel Erfolg
Jürgen
Click to expand...
It's ESP-NOW
 
Hallo zusammen, ich werde wohl im Herbst / Winter mich mit LoRa mal befassen, bisher hatte ich da noch gar keine Berührungspunkte. Da definitiv der Mamotion zwischen Mäher und Basis seine Daten über LoRa austauscht, müsste es ja grundsätzzlich möglich sein. Vielleicht kann ich meinen Bekannten mal motivieren nachzuschauen welche HW Bausteine die Verwendet haben.
Mein Architektur Ziel wäre RTK Korrekturdaten von dem Steuerdaten zu entkoppeln also LoRa Basis spricht mit LoRa Mäher und alles andere bei meinem Pi im Mäher geht dann über normales WLAN. Und irgendwann benötigt man ( benötige ich) ja sowieso kein Notebook mehr beim Mähvorgang. Das kann ja alles autonom auf dem Pi im Mäher laufen. Nur für die Korrekturdaten benötigt er eine Verbindung.
Soweit mein Plan (Er ist heute wieder durch den Garten gefahren .... könnte stundenlang zusehen)
 

Hallo miteinander​

ich evaluiere derzeit die RTK Korrekturdaten (RTCM3) über Lora zu versenden und zu empfangen. Dazu habe ich ca 10 Minuten korrekturdaten von meiner Basisstation als binär File aufgezeichnet und speise diese sequentiell mit einem python Script in ein Heltec ESP LoRa V3 Board ein. Ich sunuliere also meine Basistation. Das Heltec Board sendet dann auf SF6 also schnellste Sequenz aber auch kürzeste Reichweite an ein Heltec ESP LoRa V3 Empfänger. Natürlich habe ich mich da tatkräftig von ChatGPT unterstützen lassen, denn binär Dateien und C++ ist alles nicht so meine Domäne.
Heute habe ich mal einen Reichweitentest mit den Modulen absolviert. Und habe das Ergebnis von ChatGPT analysieren lassen.
Der Zwischenstand ist schon ganz gut. Ich wollte ihn hier einfach mal teilen und werde weiterhin informieren.

Mein Gesamturteil zum Entfernungstest​

🟢 Die Funkstrecke funktioniert​

Das haben wir eindeutig bewiesen.​

🟢 SF6 erreicht mein gesamtes Grundstück​


Sogar mit:​
  • Sender im Haus
  • Empfänger draußen
  • RSSI bis etwa -100 dBm

🟢 Vollständige RTCM Pakete kommen zuverlässig durch​


Sogar bei schwächeren RSSI-Werten.

🟡 Nur Einzelne Pakete gehen unter schlechen Empfangssituationen verloren​

Hierzu muss im Empfänger noch eine Routine enstehen die dann die Paketreste nicht berücksichtigt.

🔵 Mein nächster Schritt​

  • Eine neue Empfangssequenz muss der Empfänger nur mit dem ersten Paket starten
  • Chunks müssen exakt aufeinander folgen
  • Fehlender Chunk → Runde verwerfen
  • Falsche oder alte Chunks ignorieren
  • Nur vollständige Runde als RTCM weitergeben
  • Dann erst den Vergleich SF6 gegen SF7
ChatGPT leistet da echt gute arbeit, da muss ich mich sputen, dass ich das noch umsetze so lange wie es kostenfrei ist.
Über erfolg / Misserfolg werde ich hier informieren und wenn die Strecke funktioniert dann lege ich die Scripte und eine Anleitung wieder auf meinem github account ab.
Gruß
Ulli
 
ullisun58 said:
Hierzu muss im Empfänger noch eine Routine enstehen die dann die Paketreste nicht berücksichtigt.
Click to expand...
Lora ist doch bidirektional, oder?
Dann kannst du vom empfangenen Paket eine Checksumme bilden und diese zurückschicken. Kommt eine falsche oder keine Checksumme zurück, dann wurde das Paket nicht richtig gesendet, und du kannst das gleiche Paket noch einmal senden. Hatte das mal vor einiger Zeit für eine serielle Schnittstelle mit sehr hoher Datenrate ausprobiert. Funktioniert einwandfrei.
Grüße
Jürgen
 
Silberstreifen said:
Lora ist doch bidirektional, oder?
Dann kannst du vom empfangenen Paket eine Checksumme bilden und diese zurückschicken. Kommt eine falsche oder keine Checksumme zurück, dann wurde das Paket nicht richtig gesendet, und du kannst das gleiche Paket noch einmal senden. Hatte das mal vor einiger Zeit für eine serielle Schnittstelle mit sehr hoher Datenrate ausprobiert. Funktioniert einwandfrei.
Grüße
Jürgen
Click to expand...
Danke Jürgen für Deinen Hinweis, ja ich denke LoRa geht in beide Richtungen. Für die Korrekturdaten einer eigenen Basistation ist das meines Wissens aber nicht erforderlich. Meine "sendet" nur jede Sekunde die RTCM3 Infos an alle die es wissen wollen, damit meine ich die Rover die die Daten empfangen. Wenn jetzt einer nocheinmal Daten anfordern würde, dann kämen ja u.U. alle anderen aus dem tritt. Und auch beim normalen Test mit RTK habe ich auch die Erfahrung gemacht, dass mein Mäher nicht jedes Paket empfangen muss und er hält trotzdem sein RTK-Fix. Nur wenn es z.B. mehr als 15 Sekunden nichts gibt, dann geht er auf Float zurück. Ich bin selber gespannt, ob mein Konzept da aufgeht, ich werde berichten. Was hast Du bei Deiner seriellen Schnittstelle für Entfernungen / Baudrate bei welchen SF's erzielt?
 
ullisun58 said:
Danke Jürgen für Deinen Hinweis, ja ich denke LoRa geht in beide Richtungen. Für die Korrekturdaten einer eigenen Basistation ist das meines Wissens aber nicht erforderlich. Meine "sendet" nur jede Sekunde die RTCM3 Infos an alle die es wissen wollen, damit meine ich die Rover die die Daten empfangen. Wenn jetzt einer nocheinmal Daten anfordern würde, dann kämen ja u.U. alle anderen aus dem tritt. Und auch beim normalen Test mit RTK habe ich auch die Erfahrung gemacht, dass mein Mäher nicht jedes Paket empfangen muss und er hält trotzdem sein RTK-Fix. Nur wenn es z.B. mehr als 15 Sekunden nichts gibt, dann geht er auf Float zurück. Ich bin selber gespannt, ob mein Konzept da aufgeht, ich werde berichten. Was hast Du bei Deiner seriellen Schnittstelle für Entfernungen / Baudrate bei welchen SF's erzielt?
Click to expand...
Hi.
Here my result , but certainly something is wrong !!!
Are you sure that you can send RTCM3 full data in less than 1 second over LORA.
My test fail at this point.
Also Lora max packet size is 255 byte , so you need to cut data and rebuild everything on receiver
 
ullisun58 said:
Danke Jürgen für Deinen Hinweis, ja ich denke LoRa geht in beide Richtungen. Für die Korrekturdaten einer eigenen Basistation ist das meines Wissens aber nicht erforderlich. Meine "sendet" nur jede Sekunde die RTCM3 Infos an alle die es wissen wollen, damit meine ich die Rover die die Daten empfangen. Wenn jetzt einer nocheinmal Daten anfordern würde, dann kämen ja u.U. alle anderen aus dem tritt. Und auch beim normalen Test mit RTK habe ich auch die Erfahrung gemacht, dass mein Mäher nicht jedes Paket empfangen muss und er hält trotzdem sein RTK-Fix. Nur wenn es z.B. mehr als 15 Sekunden nichts gibt, dann geht er auf Float zurück. Ich bin selber gespannt, ob mein Konzept da aufgeht, ich werde berichten. Was hast Du bei Deiner seriellen Schnittstelle für Entfernungen / Baudrate bei welchen SF's erzielt?
Click to expand...
ok, du machst multicast. Das ist etwas anderes. Dann kannst du aber die Checksumme mitsenden, dann erkennt der Empfänger selbst durch Vergleich der selbst berechneten Checksumme mit der empfangenen Checksumme, ob das Paket in Ordnung ist.
Ich nutze das Verfahren bei der Verbindung zwischen ESP und Hauptrechner und erreichen auf diese Weise einen fehlerfreien Transfer mit 460800 baud. Ggf. geht auch mehr. Habe ich aber nicht probiert, weil ich mehr nicht brauche.
 
Bernard said:
Hi.
Here my result , but certainly something is wrong !!!
Are you sure that you can send RTCM3 full data in less than 1 second over LORA.
My test fail at this point.
Also Lora max packet size is 255 byte , so you need to cut data and rebuild everything on receiver
Click to expand...
@Bernard I divide the RTCM Data in 4 parts. in SF6 one Part needs 112ms transfer time in SF7 it needs 184 ms transfer time. At the End this is fast enough. This is in the moment my develepment status. Next step is to combine all 4 parts in the receiver and check if it is the same as the RTCM3 message in the sender.
I will keep you informed. There are a lots of solutions into the market which are transfer RTCM Data via LoRa, hope this is not only a merketing story :)
 
Last edited:
Bernard said:
Hi.
Here my result , but certainly something is wrong !!!
Click to expand...
Hi Bernard, have a look in my log file.
this is e.g. 1 RTCM3 message which the LoRa Board received. In original it is 627 Byte others contains 633 Byte oder 651 Byte .
I would under line this is SF6 so the shortes range but enough for my area. 530qm I tested the larges Range SF12 but this needs 4s to transmitt 200 Bytes.

11:16:42.695 -> Neue Runde: 141 | 4 Chunks | RSSI: -96.0 dBm
11:16:42.699 -> Chunk 1/4 | 200 Bytes | gesamt 200
11:16:42.894 -> LoRa Paket: 208 Bytes
11:16:42.897 -> Chunk 2/4 | 200 Bytes | gesamt 400
11:16:43.097 -> LoRa Paket: 208 Bytes
11:16:43.101 -> Chunk 3/4 | 200 Bytes | gesamt 600
11:16:43.224 -> LoRa Paket: 35 Bytes
11:16:43.227 -> Chunk 4/4 | 27 Bytes | gesamt 627
11:16:43.233 -> Runde 141 komplett: 627 Bytes

If you like to have a look in my Code ( I am not an expert in C++) here you are :-)
 

Attachments

You must log in or register to reply here.
Back
Top