Hallo, ich habe leider auch nach längerer Suche noch einige Unklarheiten zu den Restriktionen im 868MHz Band. Das konkrete Problem für mich ist das Remot Firmware Updgrades der Knoten bei LPWAN Netzen im 868MHz Band. Hier ist die 1% Belegungdauer eine große Hürde bei größeren Netzen. Soweit ich verstehe gelten die 1% nur wenn man ohne störungsmindernde Maßnahmen auf dem selben Kanal sendet wie es zB LoraWAN mit ALOHA ohne weitere Maßnahmen machen würde. Stimmt das soweit? Jetzt gibt es für Lora ja noch alternative MAC Layer wie Symphony Link: https://www.link-labs.com/symphony Dieser hat laut deren Werdung diese Limitierung nicht, weil Frequency Hopping mit CSMA gemacht wird. Weiters ist das ganze Netz auch noch im TDMA synchronisert, was für mich im Ganzen schon sehr durchdacht und auch für größer Deployments sinnvoll erscheint. Durch diese Maßnahme sollten dann auch Remote Firmware Updates bei >1000 Devices und >200kB Firmware gut machbar aus. Leider ist das ganze aber proprietär und die Module 3 mal so teuer wir bei LoraWAN Des weiteren habe ich auch noch das RadioShuttle Protokoll gefunden: http://www.radioshuttle.de das sieht sehr neu aus und so wirklich viele Informationen dazu habe ich noch nicht gefunden. Allerdings scheint das frei verfügbar zu sein und man ist nicht von einem Hersteller bei Hardware und Software abängig. Hat dieses Protokoll auf die 1% Limitierung? Dann würde es noch Weightless P geben, hier habe ich aber am wenigsten gefunden, vielleicht kann hier jemand etwas zur MAC und Belegungsdauern bzw Firmware Upgrade Möglichkeiten geben. Was in diesem Bereich auch immer ein Thema ist, sind minimal garantierte Payload größen und confirmed messages. Sigfox scheidet für uns aus, weil wir das Netz selbst betreiben wollen bzw keine Traffic Kosten anfallen sollen. Das ganze Thema scheint mir für größerer IoT Deployments nocht nicht so richtig gelöst bzw gibt es nicht die optimale Lösung zumal NB-Iot ja auch noch in der Kinderschuhen ist, weniger von der technologischen Seite, als eher von Providern. lg Thomas
Die Groesse eines Netzes fuer eine Update sollte ja nicht wirklich eine Rolle spielen, ausser jeder Update muesse vom Master initiiert werden. Muss er das ? Falls ja, wozu ?
Trollfinder schrieb: > Die Groesse eines Netzes fuer eine Update sollte ja nicht wirklich > eine > Rolle spielen, ausser jeder Update muesse vom Master initiiert werden. > Muss er das ? Falls ja, wozu ? Naja, wenn der Gateway die 1% Restriktion hat, ist der Downlink begrenzt, jetzt kann ich mehrere Gatways installieren, höhere Datenraten für weniger Airtime verwenden oder mittle Muticast snychronisieren. Und das gibt es bei LoraWAN nicht wirklich, Symphony Links sollte das können.
Nun, aber ein Update muss ja nur einmal ueber das Gateway. Das koennen die Stationen ja auch unter einander per Meshrouting weitergeben. Ichgehe mal davon aus, dass sich nicht alle stationen sehen. Und diewelchen, die sich nicht sehen, koennen ja parallel zu den anderen senden.
Und falls der Master viele auf's mal sieht kann er ein Update ja auch als Multicast rauslassen, und viele empfangen es gleichzeitig.
Meshrouting würde ich wegen Komplexität und Energieverbrauch bei den Knoten gerne vermeiden. Das erngieffizient zu implelmentieren halte ich für sehr schwierig bei Systemen mit +5 Jahren Batterielebensdauer. Multicast ist natürlich eine Lösung, aber auch da kann ich bei Lora mit einem Gateway keine 200kByte pro Stunde senden bei 1% max Belegungsdauer. Das ganze auf Applikationsebene zu handlen ist natürlich möglich, aber je mehr in den Schichten darunter für mich erledigt wird, desto lieber ist mir das. Die Frage für mich ist, geht das mit ander LPWAN Systemen besser? Aber die Frage mit den 1% ist für mich noch immer nicht ganz klar, kann Symphony Links das umgehen?
Allenfalls sollte man sich auch ueberlegen wie klotzig und protzig eine Firmware denn sein muss... brauch ich da zB eine Floatlib, um fuer debugzwecke ein printf() ausfuehren zu koennen ?
Angehängte Dateien:
Ich lese mich auch gerade etwas in die Materie ein. ThomasH schrieb: > ich habe leider auch nach längerer Suche noch einige Unklarheiten zu den > Restriktionen im 868MHz Band. > Das konkrete Problem für mich ist das Remot Firmware Updgrades der > Knoten bei LPWAN Netzen im 868MHz Band. Hier ist die 1% Belegungdauer > eine große Hürde bei größeren Netzen. Dein Konzentrator kann mit mehr Leistung senden und hat 10% DutyCycle, so sollten sich auch Firmwareupdates überspielen lassen. ThomasH schrieb: > Soweit ich verstehe gelten die 1% nur wenn man ohne störungsmindernde > Maßnahmen auf dem selben Kanal sendet wie es zB LoraWAN mit ALOHA ohne > weitere Maßnahmen machen würde. Stimmt das soweit? Ja. Wenn du Listen before Talk (LBT) machst, dann kannst du quasi zu 100% der Zeit deine Datenpakete versenden. Wenn ich einen meiner Nodes aktiviere, dann springt der in den Standardeinstellungen in den oberen drei Frequenzen rum. 868,1 868,3 und 868,5MHz. Der sendet also auf den drei Kanälen die in allen Konzentratoren laut Richtline freigeschaltet sein müssen. Mit der ALOHA-Methode hat man also 3% Dutycycle. Du hast 9 Uplink-Frequenzen (Node->Konzetrator) und eine Downlink-Frequenz (Konzetrator->Node). Also "confirmed messages" gibt es und kann genutzt werden. Payload ist zwischen 51 bis 222Byte.
Mike J. schrieb: > ThomasH schrieb: >> Soweit ich verstehe gelten die 1% nur wenn man ohne störungsmindernde >> Maßnahmen auf dem selben Kanal sendet wie es zB LoraWAN mit ALOHA ohne >> weitere Maßnahmen machen würde. Stimmt das soweit? > > Ja. Wenn du Listen before Talk (LBT) machst, dann kannst du quasi zu > 100% der Zeit deine Datenpakete versenden. > Kann mir jemand sagen wie man beim RN2483 erkennt ob der Kanal gerade frei ist (LBT). Kurt
Kurt schrieb: > RN2483 Beim iM880B-L kann man jedenfalls einen Pegel einstellen, wenn das Modul nichts hört was lauter als z.B. -60dBm ist, dann gilt der Kanal als leer.
Mike J. schrieb: > Kurt schrieb: >> RN2483 > > Beim iM880B-L kann man jedenfalls einen Pegel einstellen, wenn das Modul > nichts hört was lauter als z.B. -60dBm ist, dann gilt der Kanal als > leer. Das ist aber grosszügig! Beim RN2483 (LoRa-Betrieb) habe ich keine Möglichkeit gefunden die Feldstärke zu lesen, nur das S/N-Verhältnis. Und das auch erst nachdem ein Telegramm empfangen wurde. Kurt
Mike J. schrieb: > Dein Konzentrator kann mit mehr Leistung senden und hat 10% DutyCycle, > so sollten sich auch Firmwareupdates überspielen lassen. Das hört sich schon machbar an, allerdings steckt da der Teufel glaube ich eher im Detail. Denn wie synchronisiere ich alle Klasse A Devcices im Downlink und was mache ich bei Fehlern, am besten wahrscheinlich öfters schicken. Im Prinzip sollte ein Gateway bei 10% in 360s bei SF7 schon so 200kB schicken können und dann in der Stunde nichts mehr. Das ginge in den 10% Kanälen noch dazu mit 27dBm. Bietet LoRaWAN die Möglichkeit Klasse A Devices auf Klasse B oder C umzustellen dann Boadcast an alle zu verschicken? Bzw wie sieht es mit der Software für LoraWAN aus, gibt es da schon was fertiges, oder muss man sich da alles noch selbst stricken? Mike J. schrieb: Wenn ich einen meiner Nodes aktiviere, dann springt der in den Standardeinstellungen in den oberen drei Frequenzen rum. 868,1 868,3 und 868,5MHz. Der sendet also auf den drei Kanälen die in allen Konzentratoren laut Richtline freigeschaltet sein müssen. Mit der ALOHA-Methode hat man also 3% Dutycycle. Da ist aber auch ein 0,1% Kanal dabei, oder verstehe ich da was gerade nicht? Wenn ich alles maximiere, düfte ich 11,1%/h senden?
Angehängte Dateien:
-
Frequenzen_Datenrate.png
83 KB
ThomasH schrieb: > Da ist aber auch ein 0,1% Kanal dabei, oder verstehe ich da was gerade > nicht? Wenn ich alles maximiere, düfte ich 11,1%/h senden? Wie gesagt, ich lese mich da gerade noch ein. Scheinbar gelten für Europa wirklich nur die drei Kanäle als Uplink. :-/ Scheinbar ist der 0,1% Kanal gar nicht mit dabei. Die 869.525 wird ja nur als Downlink (vom Konzentrator -> zum Node) genutzt, also wenn man eine Bestätigung (confirmed message) benötigt ob das Datenpaket auch angekommen ist schaltet der Node kurz auf Empfang mit der Frequenz 869,252MHz und wartet bis die Bestätigung (Ack) gekommen ist. Mann kann bei meinem Modul (STM32L151CX + SX1272) auch noch die Anzahl der Sendeversuche bestimmen. Ich hatte folgende Informationen in einem Forum gefunden:
1 | Uplink: (vom Node zum Router) |
2 | 868.1 – SF7 BW125 bis SF12 BW125 |
3 | 868.3 – SF7 BW125 bis SF12 BW125 und SF7 BW250 |
4 | 868.5 – SF7 BW125 bis SF12 BW125 |
5 | 867.1 – SF7 BW125 bis SF12 BW125 |
6 | 867.3 – SF7 BW125 bis SF12 BW125 |
7 | 867.5 – SF7 BW125 bis SF12 BW125 |
8 | 867.7 – SF7 BW125 bis SF12 BW125 |
9 | 867.9 – SF7 BW125 bis SF12 BW125 |
10 | 868.8 - FSK |
11 | |
12 | Downlink: (vom Router zum Node) |
13 | Uplink channels 1-9 (RX1) |
14 | 869.525 – SF9 BW125 (RX2 nur als Downlink erlaubt) |
Bin mir nicht sicher was nun stimmt. :-( Will dir nichts falscher erzählen. Von ST gibt es eine LoraWAN-Grundsoftware für den STM32. http://www.st.com/en/embedded-software/i-cube-lrwan.html Diese Software werden die Leute von der "IMST GmbH" bestimmt als Grundgerüst genutzt haben.
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.