Moin, Ich habe vor, eine LoRa-Kommunikation aufzubauen. Dazu habe ich mir zwei NUCLEO-STM32WL55JC1-Boards und zwei eByte-Module wie im Thread Beitrag "Versorgung LoRa Waveshare SX1268 LoRa HAT" besorgt. Beide Systeme funktionieren untereinander einwandfrei. Jetzt würde ich sie gerne "mischen", da die STM32WL55JC1 nicht nur ein Modem sind, sondern auch programmiert werden können (Dual Core). Leider werden die eByte-Module "kryptisch" (in der Art einer LookUp-Table "AirSpeed in bps") konfiguriert, und bei den STM sämtlich Parameter einzeln gesetzt. Standardmäßig werden die eByte-Module mit einer AirSPeed von 2400 bps betrieben. Wie berechne ich die AirSpeed bzw. wie muss ich die STM-Parameter auswählen? Hilft da echt nichts außer alle Möglichkeite durchzuprobieren? Vielen Dank schon mal.
:
Bearbeitet durch User
Das Durchprobieren würde ich nicht empfehlen, es gibt sehr viele mögliche Kombinationen. Ich hatte https://www.thethingsnetwork.org/docs/lorawan/spreading-factors/ so verstanden, dass man für sein System drei Parameter festlegen muss: - Spreading Factor - Band width - Bit rate. Und natürlich die Frequenz. Ich kenn deine beiden Module / Softwarepakete nicht, aber bei den Demos der RFM95-Module mit Arduino war das relativ durchschaubar.
In dem angesprochen Thread steht auch schon, warum das nicht funktioniert: Die Ebyte-Module fahren ihr eigenes Protokoll über LoRa, das eine UART-Brücke bereitstellt. Soweit ich weiß, ist das nicht dokumentiert und daher ohne reverse engineering auch nicht mit Drittanbietermodulen oder deiner eigenen Programmierung kompatibel. Daher auch die etwas seltsame Konfiguration.
Kaufe dir zwei SX127x module und nimm die RadioLib https://github.com/jgromes/RadioLib Die EByte-Module mit dem T in der Mitte sind nicht brauchbar. Wenn, dann nimm M-Module. Das habe ich diverse im Einsatz mit ATMega328, Raspi und ESP32.
:
Bearbeitet durch User
Rahul D. schrieb: > Ich habe vor, eine LoRa-Kommunikation aufzubauen. LoRa ist nur eine Modulationsart. Für eine Kommunikation brauchst du auch noch ein Protokoll.
> LoRa ist nur eine Modulationsart. > Für eine Kommunikation brauchst du auch noch ein Protokoll. Nicht ganz, ich hab vor einiger Zeit so eine Kommunikation mit einem SX126x Modul aufgebaut und dafuer Teile(!) deren Beispielsoftware verwendet. Letztlich uebergibst du der Software dann ein Bytepaket und das sorgt dafuer das dieses Paket auch so an der anderen Seite ankommt. Irgendwelche Protokolle werden vor dir verborgen. Vanye
Helmut -. schrieb: > Kaufe dir zwei SX127x module Die STM32WLx5 enthalten den SX126x Chip mit im Gehäuse, und er wird genau so angesteuert bis auf ein paar Details. Die Radiolib unterstützt das auch. Also unnötig separate SX12xy zu kaufen. Vanye R. schrieb: > Letztlich uebergibst du der Software dann ein Bytepaket und das sorgt > dafuer das dieses Paket auch so an der anderen Seite ankommt. Das ist noch kein richtiges Protokoll, nur einzelne Pakete. Wenn eins nicht ankommt wird nicht neu übertragen usw.
Rainer W. schrieb: > Rahul D. schrieb: >> Ich habe vor, eine LoRa-Kommunikation aufzubauen. > > LoRa ist nur eine Modulationsart. > Für eine Kommunikation brauchst du auch noch ein Protokoll. OK: Eine Kommunikation über LoRa. Helmut -. schrieb: > Kaufe dir zwei SX127x module und nimm die RadioLib Nicht wirklich hilfreiche Antwort. Es geht um gemeinsame Parameter zweier unterschiedlicher LoRa-Module Wenn das die eine Lösung sein soll, schmeiße ich eher die eByte-Module aus dem Aufbau. Die Module sind dabei, weil sie sehr leicht am Raspberry Pi, per USB an einem Desktop-PC betrieben werden können und im "Lieferumfang" schon Testsoftware vorhanden ist. F. schrieb: > Die Ebyte-Module fahren ihr eigenes Protokoll über LoRa, das eine > UART-Brücke bereitstellt. Soll da noch eine Ebene vorhanden sein? In der Testsoftware wird ein Protokoll (mit fester Headerlnge) vom Host "manuell" zusammengesetzt und dann an das Modul geleitet. Man kann die eByte-Module wie die Samtech-Module konfigurieren, wobei man nicht direkt auf die Register der SX-Busteine zugreift, sondern wie oben angesprochen, können diese über das Konfigurationsprotokoll in gewissen Grenzen ausgewählt werden (unterschiedliche "AirSpeed").
Rahul D. schrieb: > Soll da noch eine Ebene vorhanden sein? > In der Testsoftware wird ein Protokoll (mit fester Headerlnge) vom Host > "manuell" zusammengesetzt und dann an das Modul geleitet. Kannst du das mal zeigen? Die Ebyte Module enthalten noch irgendeinen Mikrocontroller der die Serial -Befehle verwurstet vor dem Zugriff auf den SX126x. Der kann grundsätzlich was beliebig komplexes auf die LoRa-Pakete aufsetzen. Rahul D. schrieb: > Die Module sind dabei, weil sie sehr leicht am Raspberry Pi, per USB an > einem Desktop-PC betrieben werden können und im "Lieferumfang" schon > Testsoftware vorhanden ist. Die NUCLEO-WL55JC haben ja auch einen USB-Serialport, da kannst du auch relativ einfach deine eigene Umsetzung zwischen Serial<->LoRa basteln. Da du ja sowieso auch den STM32WLx5 nutzt musst du sowieso dort dein Protokoll implementieren, das kannst du dann auch nutzen für die PC-Anbindung, und über den Serialport die fertigen Nutzdaten schicken.
:
Bearbeitet durch User
Niklas G. schrieb: > Kannst du das mal zeigen? https://files.waveshare.com/upload/1/18/SX126X_LoRa_HAT_CODE.zip Darin liegt ein python-script, um das Modul an einem Raspberry Pi zu betreiben. Das "mauelle" Protokoll besteht aus einer (binärcodierten) 16Bit-Adresse, einer (binärcodierten) Kanalnummer und der Nutzlast. > Die Ebyte Module enthalten noch irgendeinen > Mikrocontroller der die Serial -Befehle verwurstet vor dem Zugriff auf > den SX126x. Der kann grundsätzlich was beliebig komplexes auf die > LoRa-Pakete aufsetzen. ja, genau. Niklas G. schrieb: > Die NUCLEO-WL55JC haben ja auch einen USB-Serialport, da kannst du auch > relativ einfach deine eigene Umsetzung zwischen Serial<->LoRa basteln. > Da du ja sowieso auch den STM32WLx5 nutzt musst du sowieso dort dein > Protokoll implementieren, das kannst du dann auch nutzen für die > PC-Anbindung, und über den Serialport die fertigen Nutzdaten schicken. Am Ende soll nur das LoRa-Modul auf einer selbstentwickelten Platine verwendet werde. Die NUCLEOS habe ich einfach nur, um möglichst schnell zu Ergebnissen zu kommen. Deren Testprogramm funktioniert auch zwischen zwei Knoten ("Ping" oder "Pong" wird je nach Modul über USB-UART ausgegeben). Das eByte-Modul ist einfach aufgrund seiner einfachen, kompakten Montage an einem Raspberry Pi interessant.
Rahul D. schrieb: > Darin liegt ein python-script, um das Modul an einem Raspberry Pi zu > betreiben. genauer: in "SX126X_LoRa_HAT_CODE\SX126X_LoRa_HAT_Code\raspberrypi\python\main.py"
1 | def send_deal(): |
2 | # |
3 | # the sending message format |
4 | # |
5 | # receiving node receiving node receiving node own high 8bit own low 8bit own |
6 | # high 8bit address low 8bit address frequency address address frequency message payload |
7 | data = bytes([int(get_t[0])>>8]) + bytes([int(get_t[0])&0xff]) + bytes([offset_frequence]) + bytes([node.addr>>8]) + bytes([node.addr&0xff]) + bytes([node.offset_freq]) + get_t[2].encode() |
Rahul D. schrieb: > Das "mauelle" Protokoll besteht aus einer (binärcodierten) > 16Bit-Adresse, einer (binärcodierten) Kanalnummer und der Nutzlast. Rahul D. schrieb: > data = bytes([int(get_t[0])>>8]) + bytes([int(get_t[0])&0xff]) + > bytes([offset_frequence]) + bytes([node.addr>>8]) + > bytes([node.addr&0xff]) + bytes([node.offset_freq]) + get_t[2].encode() Diese Nachricht wird dann eben vom Mikrocontroller des ebyte-Moduls verarbeitet. Weder bei LoRa noch bei LoRaWAN gibt es eine 16bit "node address", das ist also irgendwas ebyte-spezifisches, also Teil des Protokolls, das ebyte in die LoRa-Nutzlast rein setzt. Rahul D. schrieb: > Am Ende soll nur das LoRa-Modul auf einer selbstentwickelten Platine > verwendet werde. Welches Modul genau? Das von ebyte? Das schränkt dich dann auf das proprietäre ebyte-Protokoll ein. Wenn du ein Modul wie z.B. das Wio-E5 oder auch STM32WL5MOC nutzt kannst du den enthaltenen Mikrocontroller beliebig programmieren um beliebige Protokolle über LoRa oder auch FSK zu implementieren.
Niklas G. schrieb: > Diese Nachricht wird dann eben vom Mikrocontroller des ebyte-Moduls > verarbeitet. Weder bei LoRa noch bei LoRaWAN gibt es eine 16bit "node > address", das ist also irgendwas ebyte-spezifisches, also Teil des > Protokolls, das ebyte in die LoRa-Nutzlast rein setzt. Nope. Die wird vom Host verarbeitet. Niklas G. schrieb: > Welches Modul genau? Das von ebyte? Das schränkt dich dann auf das > proprietäre ebyte-Protokoll ein. Wenn du ein Modul wie z.B. das Wio-E5 > oder auch STM32WL5MOC nutzt kannst du den enthaltenen Mikrocontroller > beliebig programmieren um beliebige Protokolle über LoRa oder auch FSK > zu implementieren. Ein STM32-Modul, wie es auch auf dem NUCLEO-Board verwendet wird. Das Wio-E5 fliegt hier (neben ein paar ESP32-basierten Boards) auch schon rum. Wie geschrieben: Das Waveshare/eByte-Modul ist durch seine Bauform und den RapberryPi-kompatiblen Steckverbinder sehr praktisch. Andere Boards sind meistens nur per USB (oder TTL-UART) anbindbar. Das Waveshare-Board steckt hier jetzt auch einem RaspberryPi drauf, das auch noch andere Sachen verwendet wird. Vielleicht sollte ich mal erwähnen, dass ich mich schon länger mit dem Thema "LoRa" beschäftige.
:
Bearbeitet durch User
Rahul D. schrieb: > Nope. Die wird vom Host verarbeitet. Wo denn?! Das geht an node.send, das an self.ser.write(data), und damit direkt an Serial... Rahul D. schrieb: > Ein STM32-Modul, wie es auch auf dem NUCLEO-Board verwendet wird. Das Nucleo-Board hat kein Modul, sondern einen nackten STM32WL55JC plus diskretes Anpassungsnetzwerk und LP/HP-Umschaltung, da ist dann nur eine Metallabschirmung drauf gesteckt (kann man runter ziehen). Du müsstest also das Anpassungsnetzwerk nachbauen bzw. einen der IPDs einbauen, oder eben eines der erwähnten Module nutzen wo das alles integriert ist. Rahul D. schrieb: > Wie geschrieben: Das Waveshare/eByte-Modul ist durch seine Bauform und > den RapberryPi-kompatiblen Steckverbinder sehr praktisch. Okay, du möchtest es weiter mit dem R-PI nutzen und das dann mit dem Eigenbau-PCB kommunizieren lassen? Du könntest mal versuchen beim ebyte-Modul die Abschirmung zu entfernen und schauen was für ein Mikrocontroller da drunter steckt und ob die Programmierschnittstelle zugänglich ist, dann könntest du die Software ggf. ersetzen um beliebige Protokolle umsetzen zu können. Rahul D. schrieb: > Vielleicht sollte ich mal erwähnen, dass ich mich schon länger mit dem > Thema "LoRa" beschäftige. Ich auch, und radarange offenbar noch viel länger...
:
Bearbeitet durch User
Niklas G. schrieb: > Wo denn?! Das geht an node.send, das an self.ser.write(data), und damit > direkt an Serial... Guck dir mal die receive-Funktion an. Niklas G. schrieb: > Das Nucleo-Board hat kein Modul, sondern einen nackten STM32WL55JC plus > diskretes Anpassungsnetzwerk und LP/HP-Umschaltung, da ist dann nur eine > Metallabschirmung drauf gesteckt (kann man runter ziehen). Du müsstest > also das Anpassungsnetzwerk nachbauen bzw. einen der IPDs einbauen, oder > eben eines der erwähnten Module nutzen wo das alles integriert ist. Für mich ist das ein Modul oder ASIC. Für die Hardwareentwicklung habe ich jemanden mit mehr Ahnung - mir geht es erstmal darum, eine Funkverbindung über eine gewisse Distanz auf freien Frequenzbändern (mit den entsprechenden Beschränkungen) aufzubauen. Niklas G. schrieb: > Okay, du möchtest es weiter mit dem R-PI nutzen und das dann mit dem > Eigenbau-PCB kommunizieren lassen? > Du könntest mal versuchen beim > ebyte-Modul die Abschirmung zu entfernen und schauen was für ein > Mikrocontroller da drunter steckt und ob die Programmierschnittstelle > zugänglich ist, dann könntest du die Software ggf. ersetzen um beliebige > Protokolle umsetzen zu können. Oder es einfach so lassen und eine andere Lösung suchen. Ich scheine mich zu kompliziert auszudrücken. Meine Frage ist doch ganz einfach: Wie wird diese "AirSpeed", die Waveshare / eByte für ihre Modul angibt, aus Bandbreite und Spredingfactor berechnet? Es wäre schön, wenn mir jemand das schreiben könnte. Wenn "LoRa" drauf steht, erwarte ich, dass es egal ist, von welchem Anbieter es kommt. Oder gilt das nur für LoRaWAN? Niklas G. schrieb: > Ich auch, und radarange offenbar noch viel länger... Das ist ja schön, hilft aber nicht bei der Fragestellung.
Niklas G. schrieb: > Weder bei LoRa noch bei LoRaWAN gibt es eine 16bit "node > address", das ist also irgendwas ebyte-spezifisches, also Teil des > Protokolls, das ebyte in die LoRa-Nutzlast rein setzt. Nochmal: LoRa ist eine Modulationsart, d.h. die unterste Ebene im OSI Übertragungsmodell. LoRaWAN ist ein Netzwerkprotokoll und nutzt als Modlationsart LoRa. Die Übertragung einer Adresse gehört zum Protokoll. Und eByte nutzt ein eigenes Protokoll, auch unter Verwendung der Modulationsart LoRa. Warum wird das immer wieder durcheinander geschmissen?
:
Bearbeitet durch User
> Warum wird das immer wieder durcheinander geschmissen?
Warum sagen immer alle Bluetooth wenn sie BLE meinen obwohl das nichts
miteinander zutun hat? :)
Liegt wohl an den jeweiligen Firmen sich immer so verwirrende Namen
ausdenken.
Vanye
Rahul D. schrieb: > Guck dir mal die receive-Funktion an. Da sehe ich dass die 16bit-Node-Address vom Serial-Port kommt, d.h. der ebyte-Mikrocontroller extrahiert sie entsprechend dem proprietären ebyte-Protokoll aus den LoRa-Nutzdaten. Also genau umgekehrt zur send-Funktion. Rahul D. schrieb: > Für mich ist das ein Modul oder ASIC. Nach der Definition ist fast jeder aktuelle Mikrocontroller ein Modul, weil da mehrere einzelne ASICs in einem Gehäuse gebondet sind. Fakt ist, dass der nackte STM32WL55 wie er auf den Nucleo zu finden ist, nicht so einfach in ein eigenes PCB zu integrieren ist (layouttechnisch), aber sowas wie Wio-E5, STM32WL5MOC, Wio-E5 etc. aber schon. Gleiches gilt für den nackten SX126x Chip vs. fertige Module wie Wio-SX1262. Rahul D. schrieb: > Es wäre schön, wenn mir jemand das schreiben könnte. Was bringt das? Selbst wenn du die ebyte-Pakete empfangen kannst, kannst du sie immer noch nicht interpretieren. Die könnten sogar verschlüsselt sein. Rahul D. schrieb: > Oder gilt das nur für LoRaWAN? So ist es. Ist wie bei Ethernet: Nur weil ein Gerät einen Ethernet-Port hat, heißt das noch lange nicht, dass du damit kommunizieren kannst. Wenn da ein unbekannter Server läuft der ein unbekanntes (ggf. verschlüsseltes) Protokoll spricht, kannst du dem nichts mitteilen, wenn du nur einen "nackten" PC ohne spezielle Software hast, auch wenn dieser ebenfalls einen Ethernet-Port besitzt. Rainer W. schrieb: > Warum wird das immer wieder durcheinander geschmissen? Ist wie bei Java und JavaScript!
:
Bearbeitet durch User
Niklas G. schrieb: > Die könnten sogar verschlüsselt sein. "Könnten"... müssen aber nicht zwangsläufig. Niklas G. schrieb: > Da sehe ich dass die 16bit-Node-Address vom Serial-Port kommt, d.h. der > ebyte-Mikrocontroller extrahiert sie entsprechend dem proprietären > ebyte-Protokoll aus den LoRa-Nutzdaten. Also genau umgekehrt zur > send-Funktion. Ja, und wenn man sich eine eigene Send-Funktion bastelt, die die node.send aufruft, kann man die Nachricht auch ganz anders aussehen lassen. Soviel zum Thema "proprietären ebyte-Protokoll". Ich sehe das Problem momentan eher als "falsche Baudrate" / "Übertragungsparameter" bei UART-Kommunikation an. Aber ich habe ja keine Ahnung und micht nicht mit dem Thema beschäftigt... Wenn ich was empfangen kann, und weiß, was ich gesendet habe, kann ich vielleicht erkennen, was da schief läuft. [Offtopic] Wieso müssen hier eigentlich immer welche ihre "ach so tolle Lösung" als einzig richtige präsentieren? Wenn ich schreibe, dass ich jemanden an der Hand habe(, der mit Layouting sein Geld verdient), dann braucht man dazu nichts schreiben. Einfach mal die Überschrift und die Frage lesen (und verstehen, was da steht). Und, wenn das Bedürfnis zu antworten hat, etwas aber unklar ist, einfach mal eine präzise Frage stellen. [/Offtopic]
Rahul D. schrieb: > Ja, und wenn man sich eine eigene Send-Funktion bastelt, die die > node.send aufruft, kann man die Nachricht auch ganz anders aussehen > lassen Dann wird das ebyte Modul die Nachricht abweisen weil es sie nicht versteht oder irgendwas völlig verkehrtes machen. Na du kannst ja mal ein SDR nutzen um die ebyte Nachrichten zu analysieren, dann kannst du eventuell die LoRa Parameter reverse engineeren, und dann mit deinem LoRa Modul die Nachrichten empfangen. Dann kannst du vielleicht das proprietäre Protokoll analysieren... Oder feststellen dass es verschlüsselt ist. Rahul D. schrieb: > ] > Wieso müssen hier eigentlich immer welche ihre "ach so tolle Lösung" als > einzig richtige präsentieren Bei welcher Lösung wurde das gemacht?
:
Bearbeitet durch User
Niklas G. schrieb: > Dann wird das ebyte Modul die Nachricht abweisen weil es sie nicht > versteht oder irgendwas völlig verkehrtes machen. Ja, das ist natürlich möglich. Hat das schon mal jemand ausprobiert? Niklas G. schrieb: > Bei welcher Lösung wurde das gemacht? Stimmt. Es wurde ja nur vermutet, dass das nicht funktionieren kann.
Rahul D. schrieb: > Hat das schon mal jemand ausprobiert? Probier's doch aus. Der Python-Code verwendet offensichtlich den "Transparent Mode" plus "Fixed Transmission". Das Datasheet gibt sich darüber sehr wortkarg: "During fixed-point transmission, the module will identify the first three bytes of serial port data as: address high + address low + channel, and use them as wireless transmission targets." Der Code sender aber offenbar: - address high - address low - frequency - sender address high - sender address low - sender frequency - Payload Offenbar ist das Datasheet lückenhaft. Man fragt sich wie Sende- und Empfangsfrequenz unterschiedlich sein können aber naja. Kurios ist dass das serielle Datenpaket kein Längenfeld/Header hat, das Modul erkennt das Ende der Nachricht offenbar am Delay. Man muss also in Echtzeit senden (mit Raspberry PI und Python...?). Wenn du also Rahul D. schrieb: > kann man die Nachricht auch ganz anders aussehen > lassen. Dann kannst du irgendwelche sinnlosen Adressen angeben oder an nicht-unterstützte Frequenzen senden. Weiß nicht wie dir das helfen würde. Der Payload ist natürlich beliebig, der wird eben ins proprietäre Protokoll verpackt; dieses außen herum gepackte Protokoll wirst du damit nicht beeinflussen können.
Rahul D. schrieb: > Es war offensichtlich ein Fehler, danach zu fragen. Ich habe aber eine Antwort für dich: Mit LoRa kann man 2400 bps nicht erreichen. Mit folgenden Settings kommst du in die Nähe: - BW=31.25 kHz, SF6, CR4/5 => 2343 bps - BW=62.5 kHz, SF7, CR4/6 => 2278 bps - BW=41.67 kHz, SF6, CR4/7 => 2232 bps - BW=125 kHz, SF8, CR4/7 => 2232 bps - BW=250 kHz, SF9, CR4/7 => 2511 bps - BW=31.25 kHz, SF5, CR4/8 => 2441 bps - BW=500 kHz, SF10, CR4/8 => 2441 bps Es ist möglich dass die Spezifikation die "rohe" Bitrate meint ohne FEC (also das was zwischen Modem und FEC passiert). In diesem Falle kommen diese Konstellationen nah: - BW=15.63 kHz, SF5 => 2442 bps - BW=41.67 kHz, SF7 => 2278 bps - BW=250 kHz, SF10 => 2441 bps Beim Empfänger musst du die Coding Rate ja sowieso nicht einstellen, die habe ich nur der Vollständigkeit halber dazu geschrieben.
:
Bearbeitet durch User
Also, nochmal leicht erklärt: Zur Kommunikation muss man immer zwei Sachen festlegen: Erstens, wie man dafür sorgt, dass die Nachricht ankommt und zweitens, was die Inhalte der Nachricht bedeuten. Einfaches Beispiel: Ich kann das lateinische Alphabet lesen. Mit einem ungarischen Buch kann ich aber trotzdem nichts anfangen, da ich die Sprache nicht kann. Und so ist es auch hier: LoRa ist die Übertragungsschicht, hier sowas wie das lateinische Alphabet. Sobald du die LoRa-Parameter richtig eingestellt hast, können sich dein STM32WL und die Ebyte-Module gegenseitig empfangen und Nachrichten austauschen. Das Protokoll der Ebyte-Module ist aber unbekannt und auch nicht dokumentiert, daher weißt du nicht, was die Nachrichten bedeuten sollen. Die Ebyte-Module sind als UART-Brücke gedacht, die funktionieren nur untereinander. Das Protokoll (die "Sprache" in diesem Sinne) ist geheim, denn damit verdient die Firma Geld. Man kann nun natürlich viel Aufwand in das reverse engineering des Protokolls stecken, aber die Module sind nicht mal so wahnsinnig toll, dass sich das lohnen würde. Ich frage mich eher, was denn deine Anwendung ist und was du benötigst. LoRaWAN (ein Protokoll, das für die Verwendung mit LoRa entwickelt wurde) eignet sich relativ gut für viele Anwendungen, in denen man LoRa nutzen möchte, ist aber für Punkt-zu-Punkt-Verbindungen relativ witzlos.
F. schrieb: > . > Man kann nun natürlich viel Aufwand in das reverse engineering des > Protokolls stecken, Mit etwas Glück ist das Funk-Protokoll so primitiv wie das Serial-Protokoll oder die Dokumentation, also z.B. ein Header mit Node-Address plus Payload im Klartext. Dann müsste man zum Empfangen mit dem STM32WLX5 nur den Header abschneiden. Ist natürlich alles Spekulation. F. schrieb: > aber die Module sind nicht mal so wahnsinnig toll Sie haben halt einen tollen Pinheader der genau auf den R-PI passt...
F. schrieb: > Die Ebyte-Module sind als UART-Brücke gedacht, die funktionieren nur > untereinander. Das Protokoll (die "Sprache" in diesem Sinne) ist geheim, > denn damit verdient die Firma Geld. Das habe ich zwischenzeitlich dann auch verstanden (manchmal / häufig bin ich etwas begriffstutzig). Niklas G. schrieb: > Sie haben halt einen tollen Pinheader der genau auf den R-PI passt... Was spricht gegen eine Platine, die man einfach so auf ein Raspbi steckt? Raspberry Pis werden inzwischen ja nicht nur auf Steckbrettern verwendet.
Rahul D. schrieb: > Was spricht gegen eine Platine, die man einfach so auf ein Raspbi > steckt? Grundsätzlich nichts. Aber sich nur aufgrund des Steckers viel Arbeit und Unflexibilität auf Protokollebene einzuhandeln, naja. Sowas wie die Wio-E5 Mini Boards kriegt man bestimmt auch auf einen Pi gesteckt, z.B. mit Lochraster als Adapter. Gib mal Bescheid ob die Einstellungen für die Bitrate geholfen haben, das war ja deine eigentliche Frage.
Niklas G. schrieb: > Gib mal Bescheid ob die Einstellungen für die Bitrate geholfen haben, > das war ja deine eigentliche Frage. Danke, aber aa sich das Thema mit dem eByte-Ding erledigt hat, werde ich die Platinen nicht mehr benutzen, wodurch sich die Werte auch erledigt haben.
Rahul D. schrieb: > Danke, aber aa sich das Thema mit dem eByte-Ding erledigt hat, Ach jetzt doch? Dann war es ja doch kein Rahul D. schrieb: > Fehler, danach zu fragen.
Niklas G. schrieb: > Rahul D. schrieb: >> Danke, aber aa sich das Thema mit dem eByte-Ding erledigt hat, Nach der endlosen Diskussion (die ja offensichtlich auf meiner Engstirnigkeit gründete), war mir doch klar, dass das nicht so einfach gehen würde. Die Erklätrung von radarange (Beitrag "Re: LoRa-Parameter") war dann endgültig ausschlaggebend. Niklas G. schrieb: > Ach jetzt doch? Dann war es ja doch kein > > Rahul D. schrieb: >> Fehler, danach zu fragen. Hä? Doch, im Nachhinein war es ein Fehler, weil ich auch selber drauf hätte kommen bzw. hätte akzeptieren können (Beitrag "Re: LoRa-Parameter"), dass eByte ein proprietäres Protokoll verwendet. Ich war einfach mal wieder zu naiv.
Rahul D. schrieb: > Hä? Doch, im Nachhinein war es ein Fehler, weil ich auch selber drauf > hätte kommen bzw. hätte akzeptieren können Huh, na immerhin einsichtig, dann viel Erfolg beim Projekt... Solltest du das ebyte-Protokoll doch mal reverse-engineeren könntest du ja deine Erkenntnisse der Welt zur Verfügung stellen.
Wenn du wieder mal was mit echtem LoRa (und selbergeschriebenem Protokoll) machen willst, kann ich nur nochmals die RadioLib von JGromes empfehlen. Unterstützt diverse Lora-Module (auch die M-Serie von EByte) und Prozessoren. Wenn du mal schreiben würdest, welche Daten du übertragen möchtest, könnte man dir evtl. auch ein Protokoll empfehlen. Z.B. CayenneLPP eignet sich wunderbar, kurze Messdaten per LoRa zu übertragen. Verwende ich für meine solarversorgten Wetterstationssensoren.
Helmut -. schrieb: > kann ich nur nochmals die RadioLib von JGromes > empfehlen Die SX127x Chips sind eigentlich viel universeller als nur Lora. Als ich die Radio-Lib mal probiert habe wurde da aber nur Lora unterstützt. Es kann auch nie schaden die Register der SX127x Chips zu verstehen. Inzwischen Empfange ich mit den RFM95 Modulen auch meine historischen Sender (RFM02 FSK) sowie diverse OOK Modulationen. Das geht ziemlich gut. Ich weiß aber nicht ob das mittlerweile auch mit der Radiolib geht
Jürgen schrieb: > Helmut -. schrieb: >> kann ich nur nochmals die RadioLib von JGromes >> empfehlen > > Die SX127x Chips sind eigentlich viel universeller als nur Lora. Als ich > die Radio-Lib mal probiert habe wurde da aber nur Lora unterstützt. Es > kann auch nie schaden die Register der SX127x Chips zu verstehen. > Inzwischen > Empfange ich mit den RFM95 Modulen auch meine historischen Sender (RFM02 > FSK) sowie diverse OOK Modulationen. Das geht ziemlich gut. Ich weiß > aber nicht ob das mittlerweile auch mit der Radiolib geht Da du anscheinend die RadioLib nicht findest, hier ein Auszug, was die kann: Supported modules: CC1101 FSK radio module LLCC68 LoRa module LR11x0 series LoRa/GFSK modules (LR1110, LR1120, LR1121) nRF24L01 2.4 GHz module RF69 FSK/OOK radio module RFM2x series FSK modules (RFM22, RFM23) RFM9x series LoRa modules (RFM95, RFM96, RFM97, RFM98) Si443x series FSK modules (Si4430, Si4431, Si4432) STM32WL integrated microcontroller/LoRa module SX126x series LoRa modules (SX1261, SX1262, SX1268) SX127x series LoRa modules (SX1272, SX1273, SX1276, SX1277, SX1278, SX1279) SX128x series LoRa/GFSK/BLE/FLRC modules (SX1280, SX1281, SX1282) SX123x FSK/OOK radio modules (SX1231, SX1233) Supported protocols and digital modes: AX.25 using 2-FSK or AFSK for modules: SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, RFM2x, Si443x, LR11x0 and SX128x RTTY using 2-FSK or AFSK for modules: SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x, LR11x0 and SX128x Morse Code using 2-FSK or AFSK for modules: SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x, LR11x0 and SX128x SSTV using 2-FSK or AFSK for modules: SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, RFM2x and Si443x Hellschreiber using 2-FSK or AFSK for modules: SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x, LR11x0 and SX128x APRS using AFSK for modules: SX127x, RFM9x, SX126x, RF69, SX1231, CC1101, nRF24L01, RFM2x, Si443x and SX128x POCSAG using 2-FSK for modules: SX127x, RFM9x, RF69, SX1231, CC1101, nRF24L01, RFM2x and Si443x LoRaWAN using LoRa and FSK for modules: SX127x, RFM9x, SX126x, LR11x0 and SX128x Supports Class A and C (and Multicast over C). Pre-certified for Class A. See the wiki and notes for more information. Supported Arduino platforms: Arduino AVR - Arduino Uno, Mega, Leonardo, Pro Mini, Nano etc. NOTE: Arduino boards based on ATmega328 (Uno, Pro Mini, Nano etc.) and smaller are NOT recommended. This is because the ATmega328 MCU is very constrained in terms of program and memory size, so the library will end up taking most of the space available. mbed - Arduino Nano 33 BLE and Arduino Portenta H7 megaAVR - Arduino Uno WiFi Rev.2 and Nano Every SAM - Arduino Due SAMD - Arduino Zero, MKR boards, M0 Pro etc. Renesas - Arduino Uno R4 Adafruit SAMD - Adafruit Feather M0 and M4 boards (Feather, Metro, Gemma, Trinket etc.) nRF52 - Adafruit Feather nRF528x, Bluefruit and CLUE Espressif ESP32 - ESP32-based boards ESP8266 - ESP8266-based boards Intel Curie - Arduino 101 SparkFun Apollo3 - Sparkfun Artemis Redboard ST Microelectronics STM32 (official core) - STM32 Nucleo, Discovery, Maple, BluePill, BlackPill etc. STM32 (unofficial core) - STM32F1 and STM32F4-based boards MCUdude MegaCoreX - megaAVR-0 series (ATmega4809, ATmega3209 etc.) MegaCore - AVR (ATmega1281, ATmega640 etc.) Raspberry Pi RP2040 (official core) - Raspberry Pi Pico and Arduino Nano RP2040 Connect RP2040 (unofficial core) - Raspberry Pi Pico/RP2040-based boards Raspberry Pi - Arduino framework for RaspberryPI Heltec CubeCell - ASR650X series (CubeCell-Board, CubeCell-Capsule, CubeCell-Module etc.) PJRC Teensy - Teensy 2.x, 3.x and 4.x boards Silicon Labs EFR32 - Silicon Labs xG24, xG27 and other boards The list above is by no means exhaustive - RadioLib code is independent of the used platform! Compilation of all examples is tested for all platforms officially supported prior to releasing new version. In addition, RadioLib includes an internal hardware abstraction layer, which allows it to be easily ported even to non-Arduino environments. Und der Link dazu: https://github.com/jgromes/RadioLib
Helmut -. schrieb: > Und der Link dazu: https://github.com/jgromes/RadioLib Der alleine hätte völlig ausgereicht. Im Gegensatz zu deinem Zitat wird die Webseite auf dem aktuellen Stand gehalten und die dort vorhandenen Links sind in deinem verstümmelten Text völlig unter den Tisch gefallen.
:
Bearbeitet durch User
Wer mit Suchmaschinen umgehen kann, hätte das vorher schon gefunden. Aber anscheinend fehlt heutzutage neben Rechtschreibkompetenz, Zeichensetzungskompetenz auch immer mehr die Suchmaschinenverwendungskompetenz.
Niklas G. schrieb: > Sie haben halt einen tollen Pinheader der genau auf den R-PI passt... Dann schaut euch mal das Projekt "LoRaHAM" an. Das stammt von uns Funkamateuren aus dem DARC-Klub P14 und ich hab die Leiterplatten entworfen und gefertigt. Die sind für Funkamateure gedacht, weil LoRa im 433 MHz Band (70cm) mit bis 1 Watt HF, können aber natürlich lizenzfrei auch mit verminderter Sendeleistung arbeiten. Es gibt Module mit einem ESP32-S2, ESP32-S3 sowie für den Raspberry Pi (Dualband, 868 MHz 100 mW und 433 MHz 1 Watt gleichzeitig). Das 1 Watt Modul ist ein RFM98PW und kann natürlich mit der Radiolib betrieen werden. Momentan spielen wir mit Meshtastic auf 70cm. Wer gerne mal nach Ulm kommen möchte, kann auch gerne zum P14 OV-Abend vorbei schauen. Rechtzeitig Bescheid geben und ich bring ein paar Module zum Spielen mit. Sourcen gibts auf github.com/LoRaHAM
:
Bearbeitet durch User
Alexander W. schrieb: > Die sind für Funkamateure gedacht, weil LoRa im > 433 MHz Band (70cm) mit bis 1 Watt HF, können aber natürlich lizenzfrei > auch mit verminderter Sendeleistung arbeiten. 1. bin ich kein Funkamateur 2. hat es schon einen Grund, warum ich 868MHz oder 915MHz auswählen können will.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.