Um 2020 wurden Bausätze einer LoRaWAN-Platine verteilt, diese hier: https://web.archive.org/web/20210924125131/https://iot-usergroup.de/projekte/workshop-nucleon-basenode-bauen/ Leider konnte ich meinen Bausatz nicht komplettieren, da im Internet nur sehr unvollständige Anleitungen verfügbar sind. Gibt es hier User, die das Projekt komplett aufbauen konnten und die Informationen für die Fertigstellung zur Verfügung stellen können? Gruß sprotte24
Angehängte Dateien:
-
LoraPlatine.JPG
58 KB
Dietrich J. schrieb: > Leider konnte ich meinen Bausatz nicht komplettieren, da im Internet nur > sehr unvollständige Anleitungen verfügbar sind. Wo ist das Problem?
Wo hakt's denn? Das ist ein Arduino Pro Mini, ein RFM95-Modul und ein BME280. Ist jetzt keine Raketentechnik, da die passenden Firmwareteile zusammenzuklicken.
Dietrich J. schrieb: > ... und die Informationen für die Fertigstellung zur Verfügung stellen können? Was fehlt dir an Informationen? Die auf dem Board verbauten Module sind doch alles ausreichend gut dokumentierte Standardkomponenten. Helmut -. schrieb: > Ist jetzt keine Raketentechnik, da die passenden Firmwareteile > zusammenzuklicken. Noch einfach ist es, sie von GitHub herunter zu laden. https://gitlab.com/iotssl/nucleon-nodes
:
Bearbeitet durch User
Angehängte Dateien:
-
Nucleon-Platine.jpg
380 KB
Helmut -. schrieb: > Wo hakt's denn? Das ist ein Arduino Pro Mini, ein RFM95-Modul und ein > BME280. Ist jetzt keine Raketentechnik, da die passenden Firmwareteile > zusammenzuklicken. - Als erstes soll ja der Arduino Nano eingebaut werden. Aber was sehe ich auf der Basis-Platine, von mir rot eingerahmt im beigefügten Bild? Auf dem Einbauplatz unter dem nano gibt es 2 Widerstände R1 und R2. Die sehe ich weder im Lieferumfang noch dokumentiert. Hätte ich den nano nun erstmal eingelötet, hätte ich ein Problem. - Im Lieferumfang gibt es einen Chip, ein PIC Typ 12F683. Ist der nun schon programmiert? - Ich finde keinerlei Schaltbilder. - Wie funktioniert "github"? Sagt mir nichts, kenne ich noch nicht: Wenn ich das aufrufe, sehe ich keinen nützlichen Einträge. Der ursprüngliche Verteiler, ein Frank R. aus Tarp, hat bisher auch nicht geantwortet. Eine andere Teilnehmerin vor Ort sagte, sie habe das Projekt mit tatkräftiger Hilfe anderer User fertiggestellt, kennt sich aber auch nicht damit aus. Zu meiner Überraschung finde ich in sehr kurzer Zeit viele Antworten, hätte ich nicht erwartet. Vielen Dank an alle, die geantwortet hatten. Ich habe durchaus schon zahlreiche Bausätze fertiggestellt, angefangen von großen Bausätzen von Heathkit bis zu selbstgebautem Quadrokopter. L G sprotte24
:
Bearbeitet durch User
Dietrich J. schrieb: > - Im Lieferumfang gibt es einen Chip, ein PIC Typ 12F683. > Ist der nun schon programmiert? Wo soll der hin? Dietrich J. schrieb: > - Ich finde keinerlei Schaltbilder. Auf der Archive.org-Seite von Wijnand (https://web.archive.org/web/20210924125131/https://pcbs.io/user/Wijnand) findet man zumindest Layouts (u.a. mit einem Achtpinner). Dietrich J. schrieb: > - Wie funktioniert "github"? Sagt mir nichts, kenne ich noch nicht: > Wenn ich das aufrufe, sehe ich keinen nützlichen Einträge. Github ist ein Speicher im Internet für (Software-) Projekte. Da müsste irgendwer seinen Quellcode(-Projekt) unter einem sinnvollen Namen abgelgt haben. Wenn nicht, ist dein Projekt nicht für Anfänger (?) geeignet. Es gibt aber haufenweise Projekte mit Arduino und den HopeRF-Modulen im Internet zu finden.
Dietrich J. schrieb: > - Wie funktioniert "github"? Sagt mir nichts, kenne ich noch nicht: > Wenn ich das aufrufe, sehe ich keinen nützlichen Einträge. Tada: https://gitlab.com/iotssl/nucleon-nodes/tree/master/Weather/Weathernode_02 Das Ding liegt nicht im Archiv, sondern noch so im Internet.
Rahul D. schrieb: > Dietrich J. schrieb: >> - Wie funktioniert "github"? Sagt mir nichts, kenne ich noch nicht: >> Wenn ich das aufrufe, sehe ich keinen nützlichen Einträge. > > Tada: > https://gitlab.com/iotssl/nucleon-nodes/tree/master/Weather/Weathernode_02 > > Das Ding liegt nicht im Archiv, sondern noch so im Internet. Unsere lokale IoT-Gruppe hatte sich leider schon länger aufgelöst. Schade. Wenn auf Github verwiesen wird, dann ist das ja nicht schlecht. aber warum dann nicht auf den passenden Eintrag? Sen Sinn des 12F683 erkenne ich immer noch nicht. Könnte damit zu tun haben, das man den Stromverbtrauch minimieren will bei Akkubetrieb? Einen Stromlaufplan finde ich auch bei Github nicht. Bald stellt sich die Frage, ob ich das Projekt, was dem Wheathernode wohl gleichkommt, aufgen sollte und die Bauteile, u.a. war GPS und BME280 dabei und der Funkmodul von Hopf, anderweitig verbauen sollte. Schade. L G Dietrich will nicht aufgeben
Dietrich J. schrieb: > Sen Sinn des 12F683 erkenne ich immer noch nicht. Der ist auf dem von dir gezeigten Board doch auch gar niocht vorhanden. Das Teil ist eine Falschlieferung. Dietrich J. schrieb: > Bald stellt sich die Frage, ob ich das Projekt, was dem Wheathernode > wohl gleichkommt, aufgeben sollte und die Bauteile, u.a. war GPS und > BME280 dabei und der Funkmodul von Hopf, anderweitig verbauen sollte. > Schade. Die Platine ist wohl nur zweiseitig (Vermutung meinerseits). Da kann man den Schlatplan selber "re-engineeren".
Rahul D. schrieb: > Die Platine ist wohl nur zweiseitig (Vermutung meinerseits). Dreiseitige Platinen sind auch eher selten ;-) Dietrich J. schrieb: > Aber was sehe ich auf der Basis-Platine, von mir rot eingerahmt im > beigefügten Bild? > Auf dem Einbauplatz unter dem nano gibt es 2 Widerstände R1 und R2. > Die sehe ich weder im Lieferumfang noch dokumentiert. Dann guckst du dir einmal an, was dort für Signale liegen. https://www.rs-online.com/designspark/what-is-arduino-pro-mini-a-getting-started-guide A4 und A5 sind SDA und SCL vom I²C-Bus für den Sensor. Wie du auf der Platine siehst, sind die beiden Widerstände als Pull-Up nach VCC verdrahtet. Vom Wert sind die unkritisch - irgend etwas im Bereich 2.2 bis 4.7 kΩ tuts bestimmt. Eventuell hat der Sensor auch schon welche drauf und es ist nicht erforderlich, die beiden zu bestücken. Den Arduino Pro Mini könntest du auch steckbar montieren, wenn du den Platz nach oben hast (Buchsenleiste auf Trägerplatine, Arduino mit Stiftleisten). Blind nachbauen ohne eine Handgriff-für-Handgriff-Anleitung funktioniert nicht. Da müsstest du dir schon den Schaltplan ggf. selbst zeichnen und verstehen, was dort vor sich geht.
:
Bearbeitet durch User
Rainer W. schrieb: > Dreiseitige Platinen sind auch eher selten ;-) dann eben "doppelseitig" oder "zweilagig". :P
Dietrich J. schrieb: > Wenn auf Github verwiesen wird, dann ist das ja nicht schlecht. > aber warum dann nicht auf den passenden Eintrag? Weil in dem Blog-Artikel zur Software genau darauf verwiesen wird. https://web.archive.org/web/20210925142846/https://iot-usergroup.de/projekte/der-sketch-fuer-den-nucleon-basenode/
1 | git clone https://gitlab.com/iotssl/nucleon-nodes.git |
Dietrich J. schrieb: > - Ich finde keinerlei Schaltbilder. Wenn du die andere Seite der Platine auch noch zeigst, wäre es wohl kein Problem, das Schaltbild zu rekonstruieren. Vielleicht lässt sich dann auch die Frage zum 12F683 beantworten. Welche Version des Boards hast du genau? Rahul D. schrieb: > Auf der Archive.org-Seite von Wijnand > (https://web.archive.org/web/20210924125131/https://pcbs.io/user/Wijnand) > findet man zumindest Layouts (u.a. mit einem Achtpinner). Das ist aber nicht das Layout von Dietrich. IoT Pro-Mini/RFM95 v4.2 hat zusätzlich einen R3 unter dem Pro Mini.
:
Bearbeitet durch User
Rainer W. schrieb: > Das ist aber nicht das Layout von Dietrich. > IoT Pro-Mini/RFM95 v4.2 hat zusätzlich einen R3 unter dem Pro Mini. Habe ich auch nicht behauptet. Das wäre aber ein Layout wo der PIC drauf passen könnte. Der ist also "über".
Angehängte Dateien:
-
Nucleon-Platine2.jpg
390 KB
Hier die Rückseite. Keine neuen Erkenntnisse und auch keine Version. Ich melde mich später erneut. Gruß sprotte24
Dietrich J. schrieb: > Keine neuen Erkenntnisse ... Doch - zusammen mit der Vorderseite hast du die komplette Verdrahtung der Module und kannst den Schaltplan zeichnen. Der PIC ist damit definitiv raus und die Platine ist nur zweilagig. Dietrich J. schrieb: > Als erstes soll ja der Arduino Nano eingebaut werden. Beinahe - für das Board ist ein Arduino Pro Mini 8MHz mit 3.3V vorgesehen.
:
Bearbeitet durch User
Die Widerstände zwischen A4 und A5 sind garantiert I2C-Pullups. Such dir einen Wert raus, der passt, sagen wir mal 4.7 kOhm? Allerdings: Technologisch ist die Plattform mittlerweile schon sehr altbacken, der Arduino braucht einen großen LoRaWAN-Stack, der nur wenig Platz für eigenen Code lässt. Wenn du schon so große Probleme damit hast, diesen doch recht einfachen Bausatz mit relativ unproblematischer Konfiguration in Betrieb zu nehmen, schlage ich dir vor, einfach auf eine fertige Plattform zurückzugreifen, die modernere Ansprüche erfüllt. So sparst du dir jede Menge Ärger und kannst trotzdem experimentieren.
F. schrieb: > Such dir einen Wert raus, der passt, sagen wir mal 4.7 kOhm? Erstmal könnte man gucken, ob auf dem Drucksensormodul nicht schon geeignete Widerstände drauf sind. Man könnte einfach messen, z.B. von SCL bzw. SDA nach VDD.
Falls du vorhast, das LoRaWAN von TTN verwenden zu wollen: lass es sein. Neuerdings gehen nur noch Sensoren, die das volle LoRaWAN-Protokoll beherrschen, incl. Empfang von Nachrichten. Das bekommst du aber nicht in den Pro Mini. Sonst werden die Sensoren vom Netzwerk gesperrt. Dein eigenes Netzwerk kannst du aber damit aufbauen (so wie ich).
:
Bearbeitet durch User
Helmut -. schrieb: > Falls du vorhast, das LoRaWAN von TTN verwenden zu wollen: lass es sein. > Neuerdings gehen nur noch Sensoren, die das volle LoRaWAN-Protokoll > beherrschen, incl. Empfang von Nachrichten. Das bekommst du aber nicht > in den Pro Mini. Sonst werden die Sensoren vom Netzwerk gesperrt. Dein > eigenes Netzwerk kannst du aber damit aufbauen (so wie ich). Wenn man ganz wenig eigenen Code hinzufügt, hat das zumindest früher relativ knapp gepasst. Es sei denn, ich erinnere mich falsch. Einen Knoten mit nicht-spezifikationskonformem LoRaWAN-Stack wird man übrigens in keinem LoRaWAN verwenden können.
F. schrieb: > Wenn man ganz wenig eigenen Code hinzufügt, hat das zumindest früher > relativ knapp gepasst. Hast du dafür ein Beispiel, dass auch mit der aktuellen TTN V3 noch funktioniert? Die Warnung bei TTN zu alten V2 Devices lässt einschneidende Änderungen in V3 erahnen, auch wenn nicht genauer ausgeführt wird, was "no longer maintained" für bestehende Geräte bedeutet. https://www.thethingsnetwork.org/docs/devices/node/quick-start/
Rainer W. schrieb: > Hast du dafür ein Beispiel, dass auch mit der aktuellen TTN V3 noch > funktioniert? In Ermangelung passender Hardware kann ich das leider aktuell nicht testen, ohne herumzubasteln. Wenn man aber die "MCCI LoRaWAN LMIC Library"[1] nimmt, kann man in der Arduino-IDE ja mal ein Beispiel reinladen und das für den Arduino Uno kompilieren. Das TTN-OTAA.ino-Beispielprogramm braucht etwa 24K Speicher und 1.4K RAM, allzu viel bleibt da also nicht mehr für Eigenes übrig, aber wenn man gut programmiert, reicht es durchaus für einen Sensor. Nur: Moderne Hardware ist kostengünstig und völlig problemlos. Da lohnt es sich doch sehr, diese zu verwenden. So ein Arduino-Board, dessen Zusammenbau und Inbetriebnahme schon bei wirklich einfacher Schaltung und offensichtlicher Komponentenauswahl Probleme bereitet, halte ich daher für relativ ungeeignet, da es weit entfernt von einer Plug-and-Play-Lösung ist. Letztere gibt es aber mittlerweile tatsächlich (z.B. von M5Stack, seeed, Heltec, auch neuere Arduino-Boards, ...) [1] https://github.com/mcci-catena/arduino-lmic
F. schrieb: > Nur: Moderne Hardware ist kostengünstig und völlig problemlos. Da lohnt > es sich doch sehr, diese zu verwenden. Es geht um das vorhandene Board und mindestens die letzten 4 Jahre der technischen Entwicklung sind dort deshalb nicht umgesetzt. Wann war doch gleich die Umstellung bei TTN? https://www.thethingsnetwork.org/forum/c/v2-to-v3-upgrade/102
Rainer W. schrieb: > F. schrieb: >> Nur: Moderne Hardware ist kostengünstig und völlig problemlos. Da lohnt >> es sich doch sehr, diese zu verwenden. > > Es geht um das vorhandene Board und mindestens die letzten 4 Jahre der > technischen Entwicklung sind dort deshalb nicht umgesetzt. Wann war doch > gleich die Umstellung bei TTN? Die Frage ist doch, worum es hier geht. Die Bauteile sind zwar bereits vorhanden, aber wenn es hauptsächlich darum geht, eine Anwendung mit LoRaWAN zu realisieren, dann ist es meines Erachtens nach geschickter, ein paar Euro auszugeben und neue Hardware zu beschaffen. Damit geht das nämlich deutlich besser, zumal es ja auch Probleme damit zu geben scheint, den Bausatz überhaupt aufzubauen. Das muss einfach mittlerweile nicht mehr sein, es gibt schöne fertige Lösungen, die einfach zu verwenden sind. Dann kann man sich weitgehend auf die Anwendung konzentrieren. Wie gesagt: Soweit ich informiert bin, gibt es einen echten LoRaWAN-Stack, der auch auf dem Atmega328 läuft, dort allerdings sehr wenig Platz für die eigene Anwendung lässt. Wenn das reicht, dann ist ja alles in Ordnung. Falls nicht, wird es ziemlich nervig und dann halte ich moderne Hardware, bei der das kein Problem ist, für zielführender, zumal diese mittlerweile ebenso gut programmierbar ist wie der Atmega328 und auch kostengünstig. Wenn es also nicht spezifisch darum geht, die vorhandene Hardware um jeden Preis zu nutzen, würde ich mir einfach was Neues besorgen. Aber da mag es unterschiedliche Meinungen geben.
Helmut -. schrieb: > Falls du vorhast, das LoRaWAN von TTN verwenden zu wollen: lass es sein. > Neuerdings gehen nur noch Sensoren, die das volle LoRaWAN-Protokoll > beherrschen, incl. Empfang von Nachrichten. Das bekommst du aber nicht > in den Pro Mini. Sonst werden die Sensoren vom Netzwerk gesperrt. Dein > eigenes Netzwerk kannst du aber damit aufbauen (so wie ich). Verstehe nicht warum hier eine -1 steht. Hier gibt es auch was zum nachlesen: Beitrag "LoRA, Meshtastic, TTN, Helium?" Fakt ist eins: TTN hat bis zur V2 dumme Nodes zugelassen die nur gesendet aber nicht empfangen haben. Halt das was man für simple Sensoren so braucht. Das war zwar nicht ganz standardkonform und man hat es in meinen Augen auch bewusst nicht an die große Glocke gehängt. Damit hat man unzählige Bastler "benutzt" um Verbreitung zu erlangen. Jetzt wo man sich erwachsen fühlt kriegen die Mitstreiter der ersten Stunden einen Tritt vors Schienbein und alle alten Nodes gehen mit V3 nicht mehr. Widerlich. Damit erzwingt man dass das 868MHz Band noch mehr zugerotzt wird. Die Herren benehmen sich als ob ihnen das Band allein gehört. Wenn das so wäre, hätte der Zwang zum 100% Standard seine Berechtigung. Aber dieses Band ist nun mal nicht nur für TTN und jedes Byte zuviel was ueber die Luft geht ist eins zuviel. Temperatursensoren mit nutzlosem Rückkanal sind einfach nur zum kotzen.
F. schrieb: > Das muss einfach mittlerweile nicht mehr sein, es gibt schöne fertige > Lösungen, die einfach zu verwenden sind. Dann kann man sich weitgehend > auf die Anwendung konzentrieren. Ja klar wenn man jetzt damit anfängt. Es haben aber unzählige Leute ihre Anwendungen vor Jahren gebaut und können jetzt von vorn anfangen. Und sie lernen daraus, dass der einzige Nutzen von TTN darin besteht ein eventuell vorhandenes Gateway zu verwenden. Ein eigenes zu betreiben ist in jeder Hinsicht raus geschmissenes Geld vom Stromverbrauch mal ganz zu schweigen. Da ist es besser man verzichtet auf das WAN bei Lora und baut sich sein eigenes kleines GW mit eigenem Protokoll. Jedenfalls erlebt man damit keine TTN Überraschungen.
Jürgen schrieb: > Damit erzwingt man dass das 868MHz Band noch mehr > zugerotzt wird. Ist der Sinn von ADR nicht dass die Nodes bei guter Empfangslage kürzer und mit weniger Leistung senden, sodass das Band eben weniger belegt wird? Wenn das einmal eingestellt ist, kommt ja auch gar keine Antwort mehr und es bleibt bei einzelnen Daten-Nachrichten, welche dann auch so schnell wie möglich sind.
Jürgen schrieb: > Fakt ist eins: TTN hat bis zur V2 dumme Nodes zugelassen die nur > gesendet aber nicht empfangen haben. Halt das was man für simple > Sensoren so braucht. Das war zwar nicht ganz standardkonform und man hat > es in meinen Augen auch bewusst nicht an die große Glocke gehängt. Das ist Quatsch. In einem WAN mit vielen Teilnehmern braucht man unbedingt bidirektionale Kommunikation, nicht zuletzt, um die Signalisierung zu steuern. Das alte TTN-Backend war nicht gut, das hat unter anderem nicht-konforme Knoten nicht identifiziert. Jeder andere Netzbetreiber schmeißt Deinen Knoten sofort raus, wenn nicht gleich dich komplett. > Damit hat man unzählige Bastler "benutzt" um Verbreitung zu erlangen. > Jetzt wo man sich erwachsen fühlt kriegen die Mitstreiter der ersten > Stunden einen Tritt vors Schienbein und alle alten Nodes gehen mit V3 > nicht mehr. Widerlich. Nochmal für Dich zum Mitschreiben: Jeder Knoten, der LoRaWAN-konform ist, geht auch noch mit V3. > Damit erzwingt man dass das 868MHz Band noch mehr > zugerotzt wird. Die Herren benehmen sich als ob ihnen das Band allein > gehört. Wenn das so wäre, hätte der Zwang zum 100% Standard seine > Berechtigung. Aber dieses Band ist nun mal nicht nur für TTN und jedes > Byte zuviel was ueber die Luft geht ist eins zuviel. Temperatursensoren > mit nutzlosem Rückkanal sind einfach nur zum kotzen. Das Band gehört allen, daher können es auch alle nutzen. Was denkst du, wieviele Heizkostenverteiler und Wasseruhren per LoRaWAN funken? Die großen Abrechungsunternehmen haben überall ihre Gateways und Endgeräte verteilt, da sind selbst zwei Dutzend Temperatursensoren im TTN nichts dagegen. Als Netzwerkbetreiber muss TTN dafür sorgen, dass im Netzwerk nur Geräte unterwegs sind, die spezifikationskonform arbeiten, sonst kommt es zu Netzwerkstörungen. Das mag man am Anfang noch etwas laxer handhaben, sowohl durch geringe Netzwerkauslastung (da fällt's nicht auf) als auch durch noch nicht ausgereifte Backend-Software, aber eine dauerhafte Situation ist das nicht. Wenn jedes Byte, das über die Luft geht, eins zuviel ist, frage ich mich, warum du überhaupt LoRaWAN nutzen willst. Der Header sind ganze 13 Byte. Die paar Nachrichten in Rückrichtung, um den Knoten zu konfigurieren und regelmäßig zu überprüfen, ob die Codierung angepasst werden muss, sind da ernsthaft kaum der Rede wert. Du hast also ganz offensichtlich nicht den Sinn eines Netzwerks und speziell nicht eines WAN verstanden. Jürgen schrieb: > Ja klar wenn man jetzt damit anfängt. Wenn ich richtig gelesen habe, geht es hier darum, dass jemand einen neuen Knoten aufbauen will. > Es haben aber unzählige Leute ihre > Anwendungen vor Jahren gebaut und können jetzt von vorn anfangen. Nein. Was vor Jahren richtig funktioniert hat, funktioniert jetzt immer noch. Was vor Jahren nicht ordentlich gebaut wurde, geht halt irgendwann mal kaputt. "Von vorne anfangen" ist auch ein wenig übertrieben, der meiste Arduino-Code ist mit geringen bis keinen Anpassungen einfach auf moderne Plattformen mit spezifikationsgetreuen Stacks übertragbar. > sie lernen daraus, dass der einzige Nutzen von TTN darin besteht ein > eventuell vorhandenes Gateway zu verwenden. Ein eigenes zu betreiben ist > in jeder Hinsicht raus geschmissenes Geld vom Stromverbrauch mal ganz zu > schweigen. Da ist es besser man verzichtet auf das WAN bei Lora und baut > sich sein eigenes kleines GW mit eigenem Protokoll. Jedenfalls erlebt > man damit keine TTN Überraschungen. Du hast den Sinn eines WAN nicht verstanden. Du wirst bei allen anderen LoRaWAN-Betreibern mit deinem nicht-spezifikationskonformen Knoten rausgeschmissen. Selbst eine selbst betriebene Chirpstack-Instanz wird wahrscheinlich erst einmal den Äther vollmüllen in dem Versuch, deinen Knoten zu konfigurieren. Wenn du mit LoRa-Modulation irgendeine Anwendung entwickeln willst, ist das natürlich kein Problem, mit LoRaWAN hat das dann aber absolut nichts mehr zu tun, es ist ein völlig anderer Anwendungsfall. Die Diskussion ist da also echt reichlich sinnlos.
F. schrieb: > Damit geht das nämlich deutlich besser, zumal es > ja auch Probleme damit zu geben scheint, den Bausatz überhaupt > aufzubauen. Die Aufbauprobleme wären wohl nur bei einem Fertiggerät geringer, sorry. Der Bausatz ist in seiner Komplexität nun wirklich beherrschbar. Es kommt also auf die Anwendung an, ob man TTN-Kompatibilität benötigt oder auch mit einem etwas weniger anspruchsvollen eigenen Gateway leben mag. Die automatische, pegelabhängig Konfiguration bei LoRaWAN ist für Pflege und Durchsatz des Netzes ganz schön, aber bei einer fester Funkstrecke nicht erforderlich. Ansonsten gehört das Frequenzband allen. Keiner zwingt einen dort zu kompatiblem LoRaWAN und das Linkbudget von LoRa ist unabhängig vom WAN, aber das ist ein anderes Thema.
Es gibt meines Erachtens nach ganz praktische Gründe für die Verwendung von LoRaWAN. Die ganze Middleware ist schon fertig und funktioniert. Wenn ich mein eigenes Anwendungsprotokoll umsetzen will, muss ich den Knoten, mein Gateway und alles drumherum selber machen, bei Verwendung standardisierter und üblicher Komponenten und Technologien entfällt das, es bleibt mehr Zeit für die Anwendungsentwicklung übrig. Mit TTN treibt man das sogar auf die Spitze, weil das alles eine cloud-Lösung ist, ich mich also mit absolut gar nichts mehr bei meinem Gateway und meiner Anwendung beschäftigen muss. Aber das ist viel persönliche Präferenz und sicher auch nicht immer der Weisheit letzter Schluss.
F. schrieb: > Als Netzwerkbetreiber muss TTN dafür sorgen, dass im Netzwerk nur Geräte > unterwegs sind, die spezifikationskonform arbeiten, sonst kommt es zu > Netzwerkstörungen. Das mag man am Anfang noch etwas laxer handhaben, > sowohl durch geringe Netzwerkauslastung (da fällt's nicht auf) als auch > durch noch nicht ausgereifte Backend-Software, aber eine dauerhafte > Situation ist das nicht. Wie soll es zu Störungen kommen wenn ein Knoten normgerecht sendet? Die ganze ADR geschichte macht aber auch nur Sinn, wenn die Nodes das empfangene über den Sleep Zustand hinaus speichern. Häufig sieht das ja so aus bei den Nodes: Spannung an, messen, senden, Spannung aus. Jetzt kommt die 1 oder mehrere Sekunden warten bis zum aktiven Empfangen noch dazu. Und wenn das was da hin und her ausgehandelt wird nicht persistent gespeichert wird, geht die Eierei mit jedem mal Strom einschalten von vorn los. Und das ist häufiger anzutreffen als den Stack-Entwicklern lieb sein kann. > Wenn jedes Byte, das über die Luft geht, eins zuviel ist, frage ich > mich, warum du überhaupt LoRaWAN nutzen willst. Der Header sind ganze 13 > Byte. Die paar Nachrichten in Rückrichtung, um den Knoten zu > konfigurieren und regelmäßig zu überprüfen, ob die Codierung angepasst > werden muss, sind da ernsthaft kaum der Rede wert. Ich will ja nicht. Hab es nur mal versucht um die Technik dahinter zu verstehen. Wohlgemerkt mit richtigen Nodes und V3. Allerdings habe ich auch die Diskussionen darüber verfolgt. Und es geht nicht um LoraWAN sondern konkret um TTN. Die haben die Leute am Anfang verarscht und ausgenutzt ohne ausreichend darüber zu informieren. Das werfe ich denen vor. Nicht mehr und nicht weniger. Das es auch andere kommerzielle LoraWAN Netze gibt weiss ich auch. Um die geht es mir aber nicht. > > Du hast also ganz offensichtlich nicht den Sinn eines Netzwerks und > speziell nicht eines WAN verstanden. Waraus schließt du das? Wo steht denn geschrieben dass man den LoraWAN Stack und speziell TTN nicht kritisieren darf? Oder sind wir schon soweit dass jeder der das kritisiert zwangsweise keine Ahnung hat? Jeder muss nur für sich entscheiden ob ihm das WAN was bringt. Um von stationären Nodes zu Hause Sensordaten zu empfangen ist das in meinen Augen völlig überzogen. Erst recht wenn es keine nutzbaren Gateways gibt und man selbst eins betreiben muss. Irgendwie stagniert der Ausbau bei TTN sowieso. Ich sehe jedenfalls nichtg dass das eine große Zukunft hat.
Jürgen schrieb: > Wie soll es zu Störungen kommen wenn ein Knoten normgerecht sendet? Von welcher Norm sprechen wir hier? Wenn die Teilnehmer am Netzwerk der Spezifikation entsprechen, dann gibt's auch keine spezielleren Störungen. Jürgen schrieb: > Die ganze ADR geschichte macht aber auch nur Sinn, wenn die Nodes das > empfangene über den Sleep Zustand hinaus speichern. Häufig sieht das ja > so aus bei den Nodes: Spannung an, messen, senden, Spannung aus. Jetzt > kommt die 1 oder mehrere Sekunden warten bis zum aktiven Empfangen noch > dazu. Und wenn das was da hin und her ausgehandelt wird nicht persistent > gespeichert wird, geht die Eierei mit jedem mal Strom einschalten von > vorn los. Und das ist häufiger anzutreffen als den Stack-Entwicklern > lieb sein kann. Nodes brauchen persistenten Speicher. Das, was du als "häufig" beschreibst, ist ziemlicher Unsinn und wird hauptsächlich von Leuten betrieben, die sich irgendeine nicht-spezifikationskonforme Lösung zusammengebastelt haben. ADR hin oder her, du brauchst persistenten Speicher für den Framecounter. Der ist wichtig, um Replay-Angriffe und Verarbeitung mehrfach empfangener Daten zu verhindern. Der Framecounter steigt kontinuierlich und wird natürlich beim Join zurückgesetzt. Nun kannst du jedes Mal, wenn der Knoten eingeschaltet wird, einen Join durchführen, der braucht aber erstens einen Rückkanal und zweitens sollte er gerade deswegen auch nicht zu häufig durchgeführt werden, da das die Gateways stark belastet (hoher SF, dadurch Verbrauch von viel Airtime). Aus praktischen Gesichtspunkten sind zu viele joins auch nicht geschickt, da jedes Mal neue Schlüssel erzeugt werden und dafür ein vom Knoten generierter nonce benötigt wird, Wiederverwendung ausgeschlossen. Kurzum: Das ist nicht geschickt, Knoten so zu entwickeln und Knoten, die sich ihren Frame Counter nicht merken oder ständig join requests absetzen, werden in jedem anderen LoRaWAN sicher schnellstmöglich rausgeschmissen. LoRaWAN ist kein besonders robustes Netzwerk, da muss man sich schon darauf verlassen, dass sich die einzelnen Teilnehmer benehmen. Jürgen schrieb: > Und es geht nicht um LoraWAN > sondern konkret um TTN. Die haben die Leute am Anfang verarscht und > ausgenutzt ohne ausreichend darüber zu informieren. Das werfe ich denen > vor. Nicht mehr und nicht weniger. Die TTN-Community ist leider noch schlimmer als hier, man mag es kaum glauben. Es gibt da ganz furchtbare Besserwisser, die leider oft auch wahnsinnig aggressiv auftreten. Wenn das Leute verschreckt, habe ich volles Verständnis, ich habe auch schon Erkenntnisse nicht geteilt und Informationen entfernt, weil die mir blöd kamen. Nur: Es gab schon sehr lange entsprechende Warnungen und Hinweise, dass Dinge, die nicht spezifikationskonform sind, in Zukunft nicht mehr funktionieren könnten. Zu Beginn gab es eine Erkundungsphase, in der viel erlaubt war, damit es irgendwie voran geht. Aber irgendwann ist die auch vorbei und dann muss man eben einsehen, dass nur noch Dinge funktionieren, die spezifikationskonform sind. Nicht-spezifikationskonforme Knoten sind ein Problem für das Netzwerk und es ist absolut sinnfrei, ein Legacy-Netzwerk zusätzlich zu betreiben, das hauptsächlich schlecht funktioniert und dadurch viel Arbeit macht. Ich finde die zunehmende Kommerzialisierung von TTN sehr schade und hoffe, dass das nicht überhand nimmt. Jürgen schrieb: > Waraus schließt du das? Wo steht denn geschrieben dass man den LoraWAN > Stack und speziell TTN nicht kritisieren darf? Oder sind wir schon > soweit dass jeder der das kritisiert zwangsweise keine Ahnung hat? TTN verwendet LoRaWAN, ein Protokoll für ein WAN basierend auf LoRa. Wenn deine Anwendung kein WAN braucht, schön und gut, aber dann ist es doch recht sinnfrei, TTN für irgendwelche Dinge zu kritisieren, die der Sicherstellung der Betriebsfähigkeit des TTN-WANs dienen. Du brauchst kein WAN, das wissen wir. TTN und deine selbstgebaute LoRa-Lösung benutzen beide das 868MHz-Band mit LoRa-Modulation, mehr Gemeinsamkeiten gibt's aber nicht. Das ist so, wie zu sagen: Autofahren ist blöd, mal lieber mit Kreide auf der Straße. Kann man machen, ist aber irgendwie nicht so ganz zielführend.
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.