Hallo, ich hab die Frage zwar schon mal als Antwort auf einen anderen Thread im Hausbus-Forum gestellt, aber ich denke einfach das es hier eher hingehört und ich vllt auf eine Antwort hoffen kann. Tut mir leid,wenn ich durch den "Doppelpost" irgendwelche Forumsregeln missachten sollte...dann lösch ich den andern Beitrag. Ich kopier meine Frage einfach mal hier rein: "Hi, also ich wollte das ganze auch noch mal aufwärmen. Und zwar hab ich eine ähnliche Situation,aber ich muss zugeben dass ich in Sachen ZigBee-Module doch noch recht grün bin ;-) Ich habe zwei AVR's mit jeweils einem ZigBee-Modul von Amber Wireless. Nun wollte ich Messdaten von a nach b übertragen,unidirektional,also nichts großartiges. Nach längerem hin und her steht die Strecke auch und er schickt eifrig Werte, nur gibt es manchmal so Aussetzer von 1-2 secs wo nichts kommt und dann gehts wieder weiter. Hat da jmd ne Idee woran das liegt? Ist das einfach nur weil er mit dem Senden bzw. Empfangen nicht hinterherkommt oder etwas ganz anderes? Meine reinen Messdaten sind pro Paket 6 Byte, wieviel Pakete sind realistisch pro Sekunde? Wär klasse wenn mir da einer weiterhelfen könnte! Gruß"
Tim R. schrieb: > Tut mir leid,wenn ich durch den "Doppelpost" irgendwelche Forumsregeln > missachten sollte...dann lösch ich den andern Beitrag. Da du damit außerdem einen uralten Thread aufgewärmt hast, ohne dort etwas zum originalen Thema beizutragen, habe ich das mal gelöscht. > Werte, nur gibt es manchmal so Aussetzer von 1-2 secs wo nichts kommt > und dann gehts wieder weiter. > Hat da jmd ne Idee woran das liegt? Da wirst du wohl Ember mal fragen müssen... Vielleicht ist einfach auch nur der "Kanal voll" (also nicht durch dich, sondern durch anderweitige Aussendungen)? > Meine reinen Messdaten sind pro Paket 6 Byte, wieviel Pakete sind > realistisch pro Sekunde? Dazu kommen noch (vermutlich) 9 Octets für den MAC header, 2 Octets für den MAC footer (aka. CRC-16) sowie 5 Octets für Präambel und PHY header, macht 22 Octets oder 44 Symbole je 16 µs. Das sind 0,7 ms reine Übertragungszeit. Das vorangesetzte "clear channel assesment" (CCA) benötigt 128 µs zum Messen des (hoffentlich freien ;) Kanals sowie ein random backoff von im Mittel ca. 1 ms. Macht summa summarum etwa 2 ms für eine Übertragung, du könntest davon also so um die 50 Stück pro Sekunde unterbringen. Effektiver wärest du, wenn du deine Nutzlast vergrößerst, also ein paar Messungen ansammelst und dann absetzt.
Erst einmal vielen Dank Jörg! Jörg Wunsch schrieb: > Da du damit außerdem einen uralten Thread aufgewärmt hast, ohne > dort etwas zum originalen Thema beizutragen, habe ich das mal > gelöscht. Ja,mir ist leider erst danach aufgefallen,dass da ja das Jahr 2008 angegeben war. Ich hatte nur 13.08 gelesen ;-) Ich gelobe Besserung. > Da wirst du wohl Ember mal fragen müssen... Vielleicht ist einfach > auch nur der "Kanal voll" (also nicht durch dich, sondern durch > anderweitige Aussendungen)? Ok,erst probier ich mal den Kanal zu wechseln und dann, falls das wenig erfolgreich ist, kontaktier ich mal Amber. Gibts einen bestimmten Kanal der von z.B. WLan eher gemieden wird? > Dazu kommen noch (vermutlich) 9 Octets für den MAC header, 2 Octets > für den MAC footer (aka. CRC-16) sowie 5 Octets für Präambel und > PHY header, macht 22 Octets oder 44 Symbole je 16 µs. Das sind 0,7 > ms reine Übertragungszeit. Das vorangesetzte "clear channel > assesment" (CCA) benötigt 128 µs zum Messen des (hoffentlich freien ;) > Kanals sowie ein random backoff von im Mittel ca. 1 ms. Macht summa > summarum etwa 2 ms für eine Übertragung, du könntest davon also so > um die 50 Stück pro Sekunde unterbringen. Ehm, da muss ich nochmal nachfragen...gibts da noch einen Overhead den du grad nicht erwähnt hast oder meintest du um die 500 Stck/sec ? > Effektiver wärest du, wenn du deine Nutzlast vergrößerst, also ein > paar Messungen ansammelst und dann absetzt. Ja genau, ich hatte vor die 84 Byte die mir laut API als Nutzdaten zur Verfügung stehen mit 14 "Nachrichten" komplett auszunutzen.
Tim R. schrieb: > Gibts einen bestimmten Kanal der von z.B. WLan eher gemieden wird? Gugel mal nach »rf4ce channels«. Ich weiß nicht, ob das in Europa auch zutrifft, aber RF4CE benutzt die Kanäle 15, 20 und 25. > Ehm, da muss ich nochmal nachfragen...gibts da noch einen Overhead den > du grad nicht erwähnt hast oder meintest du um die 500 Stck/sec ? So direkt nach der Mittagspause war Kopfrechnen noch nie meine Stärke. ;-) >> Effektiver wärest du, wenn du deine Nutzlast vergrößerst, also ein >> paar Messungen ansammelst und dann absetzt. > Ja genau, ich hatte vor die 84 Byte die mir laut API als Nutzdaten zur > Verfügung stehen mit 14 "Nachrichten" komplett auszunutzen. 84 Byte nur? Dann scheint deren Overhead noch höher zu sein. Der gesamte Rahmen kann ja maximal 127 Octets lang werden, du darfst also von 43 Octets Overhead (+ Präambel und PHY header) ausgehen statt meiner angenommenen 11. Möglicherweise ist da ja noch ein kompletter Zigbee-Stack drüber (also NWK und APP brauchen auch noch Platz). Das wären dann 1,6 ms (statt 0,7), oder maximal so 300...400 davon pro Sekunde.
Jörg Wunsch schrieb: > Gugel mal nach »rf4ce channels«. Ich weiß nicht, ob das in Europa > auch zutrifft, aber RF4CE benutzt die Kanäle 15, 20 und 25. Ok,werd ich gleich mal machen. Ich hab grad mal in der Doku nachgeschaut und ich kann auch nur für die Kanäle eine 4 Byte-Bitmaske setzen aus denen er den für sich günstigsten Kanal raussucht. Ist da ein Haken an der Sache wenn ich mal die Maske komplett mit 1en fülle?Dann müsste er sich doch immer den besten aussuchen,oder? > So direkt nach der Mittagspause war Kopfrechnen noch nie meine > Stärke. ;-) Ach ,das macht garnichts...Ich hab nur grad an mir selbst gezweifelt ;-) > 84 Byte nur? Dann scheint deren Overhead noch höher zu sein. Der > gesamte Rahmen kann ja maximal 127 Octets lang werden, du darfst also > von 43 Octets Overhead (+ Präambel und PHY header) ausgehen statt > meiner angenommenen 11. Möglicherweise ist da ja noch ein kompletter > Zigbee-Stack drüber (also NWK und APP brauchen auch noch Platz). Das > wären dann 1,6 ms (statt 0,7), oder maximal so 300...400 davon pro > Sekunde. Ja,das mit den 84 Byte kommt drauf an welche API man benutzt(also auf dem Modul wird ein TI CC2480 benutzt). Bei der SimpleApi sind es eben diese 84 Byte. Bei der anderen die laut Datenblatt die komplette Funktionalität des ZigBee-Stack bietet sind es 128 Byte reine Nutzdaten. Wobei ich das nicht ganz versteh wenn du ja sagst,dass der komplette Frame nur 127 lang ist?! Ich dachte bisher das ZigBee das nicht splitten kann?!
Tim R. schrieb: > Ist da ein Haken an > der Sache wenn ich mal die Maske komplett mit 1en fülle? Dann müsste er > sich doch immer den besten aussuchen,oder? Vorausgesetzt, dass die Kanalbelegung über die Zeit gleichmäßig ist. > Wobei ich das nicht ganz versteh wenn du ja sagst,dass der komplette > Frame nur 127 lang ist?! > Ich dachte bisher das ZigBee das nicht splitten kann?! Da bin ich mir nicht sicher, so sattelfest bin ich mit Zigbee selbst nicht, ich kenne die PHY- und MAC-Schicht besser.
> Vorausgesetzt, dass die Kanalbelegung über die Zeit gleichmäßig ist. Ok klar,zumindest mal zu dem Zeitpunkt in dem die Kanäle gescannt werden. > Da bin ich mir nicht sicher, so sattelfest bin ich mit Zigbee selbst > nicht, ich kenne die PHY- und MAC-Schicht besser. Das ist das Problem,ich komm eigentlich auch aus einer ganz anderen Ecke und benutz die Module auch nur als Mittel zum Zweck...und die sind irgendwie vom Himmel gefallen, keine Ahnung wo die herkamen. ;-) Aber schon mal Danke für deine Hilfe...wenn du noch weitere Ideen hast,immer her damit :-) Ansonsten hab ich die Leute von AmberWireless mal eben per Email kontaktiert und bin mal gespannt ob sich da was tut.
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.