Hallo, wir setzen ZigBit-Module mit dem neuesten Atmel-MAC 2.5.1 ein. Die Applikation basiert auf dem "Star - No Beacon - Beispiel" und sendet alle 20ms (zurzeit noch alle 50ms) ein Telegramm mit 52 Bytes Nutzdaten in beide Richtungen. Prinzipiell funktioniert die Hard- und Software. Allerdings ist die Reichweite extrem eingeschränkt: Innerhalb geschlossener Räume (Büroumgebung) ist meist nach wenigen Metern die Übertragung gestört und im Freien treten regelrechte "Funklöcher" nach ein paar Metern auf (entfernt man sich weiter und verlässt das Funkloch, funktioniert die Übertragung wieder). Ich hatte eigentlich gehofft, dass die Problematik von Funklöchern durch Auslöschungen (Mehrwegeausbreitung) durch die 2 Chipantennen auf den ZigBit-Modulen nicht auftritt. Bevor wir die ZigBit-Module eindesigned habe, hatten wir Reichweitentests mit der "alten" Meshnetics Software (Range Measurement Tool) und den MeshBean2-Boards durchgeführt und sind auf Reichweiten von knapp 200m im Freifeld und auf 20...30m Indoor gekommen. Funklöcher konnten wir damit nicht lokalisieren. Interessant ist auch, dass mit der Meshnetics Software auf unserer Hardware ebenfalls Reichweiten bis zu 200m erzielbar sind - Fehler im Hardware-Design kann ich daher (vermutlich) ausschließen. Bei der Fehlersuche habe wir außerdem festgestellt, dass immer wieder sporadisch Telegramme komplett verlorengehen (ca. 1%) - auch auf kurzen Entfernungen (< 1m). Desweiteren treten gelegentlich "unexpected PLL_LOCK interrupts" auf. Leider ist die Dokumentation des Stacks und der Module seitens Atmel "sehr kompakt" und liefert kaum Anhaltspunkte für eine Fehlersuche. Gibts es in anderen Applikation ähnliche Phänomene ? Insbesondere bei Anwendungen, die fortlaufend bidirektional Daten (halbduplex, je 20...30kbit/s) übertragen ? Kann es sein, dass durch der Atmel-Frontend mit der ständigen Rx/Tx-Umschalterei Probleme hat (instabil wird) ? Hat jemand Erfahrungen mit den Modulen mit externer Antenne ? Ich habe mittlerweile Bedenken, ob die Atmel-Plattform die richtige Wahl war ... Allerdings habe ich bisher keine vergleichbare Alternative (kleine Abmessungen, Link-Budget 104dB, Stromaufnahme < 20mA, ...) gefunden.
Evtl. ist in der SW aus Energiespaargruenden das PHY_TX_PWR Register verstellt. Dazu mal versuchen, ob du in deiner Applikation direkt das Register auslesen kannst, also entweder mit "txpwr = pal_trx_bit_read(SR_TX_PWR);" oder mit "txpwr = pal_trx_reg_read(0x05) & 0x0f;" Je nach Transceiver sieht das Register 0x05 (PHY_TX_PWR) so aus:
1 | at86rf212.txt:0x05 PHY_TX_PWR: |
2 | PA_BOOST GC_PA[1] GC_PA[0] TX_PWR[4] TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0] |
3 | at86rf230a.txt:0x05 PHY_TX_PWR: |
4 | TX_AUTO_CRC_ON - - - TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0] |
5 | at86rf230b.txt:0x05 PHY_TX_PWR: |
6 | TX_AUTO_CRC_ON - - - TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0] |
7 | at86rf231.txt:0x05 PHY_TX_PWR: |
8 | PA_BUF_LT[1] PA_BUF_LT[0] PA_LT[1] PA_LT[0] TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0] |
Noch folgende Ideen: a) wie stehen die Fuses ? Welchen Clock nutzt du fuer den AVR? b) ... unexpected PLL_LOCK ... ist die Betriebsspannung Ok ? Sind die Module mal mechanisch/thermisch extrem belastet worden, d.h. evtl. Quartz defekt ? c) Ist das die originale Firmware aus dem Paket, wurde schon was geaendert ? Tritt das Problem auch mit einer "out of the box" Applikation auf ?
SHotz schrieb: > Ich hatte eigentlich gehofft, dass > die Problematik von Funklöchern durch Auslöschungen > (Mehrwegeausbreitung) durch die 2 Chipantennen auf den ZigBit-Modulen > nicht auftritt. Ähem, die Zigbit-Module haben kein antenna diversity drin! Das kann der AT86RF230 noch gar nicht, sowas gibt's erst beim AT86RF231. Die beiden Chips dort bilden einfach nur eine symmetrische Antenne, sodass kein Balun nötig ist. Vergleiche mit anderen Chip-Antennen haben allerdings gezeigt, dass die Zigbit-Module offenbar recht gut abstrahlen. Besser wirst du nur noch mit einer Antenne kommen, die dann auch wirklich in der Größen- ordnung von λ/2 groß ist — Physik lässt sich nicht überlisten. Ich glaube, bei Dresden Elektronik kann man ein Board kaufen mit AT86RF231 und zwei Antennen für antenna diversity. Das könntest du ja ggf. als Vergleich heranziehen.
Ach so: hast du eigentlich mal verschiedene Kanäle ausprobiert?
Axel Wachtler schrieb: > at86rf230b.txt:0x05 PHY_TX_PWR: > > TX_AUTO_CRC_ON - - - TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0] Der Registerinhalt ist 0, d.h. +3dBm (mehrfach sporadisch ausgelesen). Das Register SR_TX_PWR wird nur beim Hochlaufen über die tal_pib.c beschrieben. Die Sendeleistung haben wir auch schon nachgemessen - sie ist ok. Axel Wachtler schrieb: > a) wie stehen die Fuses ? Welchen Clock nutzt du fuer den AVR? Die Einstellung in der pal_config.h (basiert auf RCB_3_2_PLAIN-Beispiel)habe ich unverändert gelassen: LF: 0xE2 HF: 0x91 EF: 0xFE Axel Wachtler schrieb: > b) ... unexpected PLL_LOCK ... ist die Betriebsspannung Ok ? Sind die > > Module mal mechanisch/thermisch extrem belastet worden, d.h. evtl. > > Quartz defekt ? Die Betriebsspannung hatten wir überprüft (Ripple <30mV). Eine thermische Überlastung können wir ausschließen (wir haben >20 Prototypen, die alle das gleiche Verhalten zeigen. Axel Wachtler schrieb: > c) Ist das die originale Firmware aus dem Paket, wurde schon was > > geaendert ? Wir haben natürlich unsere Applikation auf den Stack gesetzt und Anpassungen für unsere Hardware durchgeführt (pal_config.h, pal_board.c, pal_irq.c). Ich kann natürlich nicht 100% ausschließen, dass noch irgendwo eine Konfiguration nicht passt, habe aber im Moment keine Idee mehr, wo ich noch ansetzen könnte. An die dresden Elektronik habe ich auch schon gedacht. Ich werde mal ein paar Boards bestellen (deren Funkmodule sind halt leider deutlich größer als die ZigBit-Module ...) Bzgl. der Chip-Antennen hatten wir anfangs auch Vergleichmessungen durchgeführt und sind zu dem Schluss gekommen, dass sie mindestens genauso gut funktionieren (eher sogar besser) wie die beiden anderen Varianten (Eval-Kit von Meshnetics mit PCB und Stummelantenne). Mich würde stark interessieren, ob schon mal jemand eine vergleichbare Applikation (halbduplex, alle 20bzw. 50ms ein Telegramm mit 50 Bytes -> ca. 20...30kbit/s) zufriedenstellend zum Laufen bekommen hat. Möglicherweise haben die Atmels ja auch mit dem ständigen Umschalten zwischen Rx und Tx ein Problem ? Wir sind für jegliche Tips dankbar ... Ein weiteres Phänomen konnten wir bisher auch noch nicht aufklären: Gelegentlich kommt es vor, dass die Boards nicht anlaufen und sich fortlaufend beim Neustart wieder resetten. Manchmal hilft ein mehrfaches Unterbrechen der Spannungsversorgung; teilweise laufen die Boards aber auch erst am nächsten Tag wieder normal an. Teilweise tritt das Reset-Problem auch tagelang nicht auf. Beim Debuggen "verschwindet" das Problem meist wie von selbst. Ein paar mal habe ich den Debugger in der Kalibrierungsroutine anhalten können ... ? Ich tippe weiterhin auf ein Softwareproblem, da unsere Hardware mit der Meshnetics-Software eine erheblich größere Reichweite hat.
SHotz schrieb: > An die dresden Elektronik habe ich auch schon gedacht. Ich werde mal ein > paar Boards bestellen (deren Funkmodule sind halt leider deutlich größer > als die ZigBit-Module ...) Klar, für eine brauchbare antenna diversity braucht man ja auch etwas Abstand zwischen den Antennen. Das kann man mit einem Mini- Modul nicht erreichen. > Mich würde stark interessieren, ob schon mal jemand eine vergleichbare > Applikation (halbduplex, alle 20bzw. 50ms ein Telegramm mit 50 Bytes -> > ca. 20...30kbit/s) zufriedenstellend zum Laufen bekommen hat. Wir schicken hier schon mal pro Stunde einige 100000 Frames durch die Kante. Davon kommt eine einstellige Prozentzahl nicht an. > Möglicherweise haben die Atmels ja auch mit dem ständigen Umschalten > zwischen Rx und Tx ein Problem ? Warum sollten sie? Ein 802.15.4-Transceiver muss ja innerhalb von 192 µs umgeschaltet haben (damit er das ACK senden kann), das schreibt der Standard vor. Da die PLL ohnehin die ganze Zeit auf der Empfangsfrequenz bleibt und dann beim Senden innerhalb von 16 µs auf die Sendefrequenz gezogen wird (steht im Datenblatt bei der Beschreibung der operating modes), kannst du davon ausgehen, dass die Umschaltung nicht das Problem ist. > Ein weiteres Phänomen konnten wir bisher auch noch nicht aufklären: > Gelegentlich kommt es vor, dass die Boards nicht anlaufen und sich > fortlaufend beim Neustart wieder resetten. Reset oder Sprung zur Adresse 0? Ersteres müsste sich über die Statusbits im MCUCSR rausfinden lassen (die man aber manuell löschen muss!, man könnte den Inhalt ja über LEDs ausgeben). Ein Sprung zur Adresse 0 ohne Reset ist sehr häufig die Folge eines Interrupts, für den es keine ISR gibt. > Ein paar mal habe ich den Debugger in der > Kalibrierungsroutine anhalten können ... ? Welche, die des RC-Oszillators? Der wird gegen den 32-kHz-Quarz kalibriert, kann es sein, dass der Quarz nicht richtig läuft? > Ich tippe weiterhin auf ein Softwareproblem, da unsere Hardware mit der > Meshnetics-Software eine erheblich größere Reichweite hat. Was wiederum sehr seltsam ist, denn viel kann die Software an der reinen Funkübertragung nicht tun. Um die Frage von oben nochmal zu wiederholen: habt ihr das mal auf verschiedenen Kanälen getestet? Nicht, dass da nur einer komplett mit anderen Dingen vermüllt ist. Last not least: für den Atmel-MAC kannst du dort sicher auch Support bekommen. Zuvor solltest du jedoch die aktuelle Version benutzen, ich sehe auf der Website die Version 2.5.2.
Jörg Wunsch schrieb: > Um die Frage von oben nochmal zu wiederholen: habt ihr das mal auf > > verschiedenen Kanälen getestet? Nicht, dass da nur einer komplett > > mit anderen Dingen vermüllt ist. Ja, wir haben mehrere System parallel im Einsatz (jedes sucht sich zu Beginn einen freien Kanal). Jörg Wunsch schrieb: > Wir schicken hier schon mal pro Stunde einige 100000 Frames durch > > die Kante. Davon kommt eine einstellige Prozentzahl nicht an. Wie groß ist dabei der Abstand ? Jörg Wunsch schrieb: > Last not least: für den Atmel-MAC kannst du dort sicher auch Support > > bekommen. Zuvor solltest du jedoch die aktuelle Version benutzen, > > ich sehe auf der Website die Version 2.5.2. Ok, die Version 2.5.2 werde ich mir mal runterladen. Den Atmel-Support habe ich bereits kontaktiert - leider reagieren die nicht so schnell wie ihr (ich warte seit Freitag auf eine Antwort und werde morgen mal nachhaken ...)
SHotz schrieb: > Wie groß ist dabei der Abstand ? Der ist bei uns nicht so groß, aber das spielt für die Umschalt- geschwindigkeit ja nun keine Rolle. > Den Atmel-Support habe ich bereits kontaktiert - leider reagieren die > nicht so schnell wie ihr (ich warte seit Freitag auf eine Antwort und > werde morgen mal nachhaken ...) Hast du die richtige Adresse genommen (avr@...)? Normalerweise solltest du erstmal automatisch eine Ticket-Nummer bekommen.
Jörg Wunsch schrieb: > Wir schicken hier schon mal pro Stunde einige 100000 Frames durch > > die Kante. Davon kommt eine einstellige Prozentzahl nicht an. Habt ihr herausfinden können, wo (bzw. warum) die Frames verlorengehen ? Ich habe festgestellt, dass der Stack über die ENTER_CRITICAL_SECTION / ENTER_TRX_REGION Makros die Interrupts teilweise bis zu 0,5ms sperrt. Ist der AT86RF230 nicht empfangsbereit, wenn über die SPI der letzte Frame abgeholt wird (dauert über die 4MBit/s-SPI bei 70 Bytes * 8 Bit = 560Bit ca. 150µs) ? Ansonsten wüsste ich nicht, was der Stack sonst so "lange" macht ? Da wir ein starres Ping-Pong Verfahren haben (d.h. alle 20 bzw. 50ms ein Request, auf das die andere Seite antwortet), sollten Kollisionen in unserer Applikation nicht auftreten.
Hallo Jungs, ich möchte mal ein paar weiter Denkansätze in die Runde schmeißen. (1) "HW" Die früheren Messungen, die du beschreibst, wurden mit den Modulen "MN-ZB24-A2" gemacht, richtig? Die Module, die du jetzt einsetzt sind aber sicherlich "AT-MN24-A2", stimmts? Die Meshnetics-Module beinhalteten aus verschiedensten Gründen den AT86RF230A, die Atmel-Module den AT86RF230B. Meiner Meinung nach funktioniert der Atmel-MAC nur bis zur Version 2.1 oder 2.2 mit dem RF230A. Könnte das ein Problem sein? (2) "SW" Bitcloud basiert auf einem eigenen MAC (geschrieben von Meshnetics, keinerlei Verwandschaft zum Atmel-MAC, Parallelentwicklung), da sollte eure Applikation doch portierbar sein. Man muß ja keine Router nehmen. Falls die "Reichweitenprobleme" da nicht auftauchen ist es der Atmel-MAC und nicht das Atmel-Modul(falls ATZB-24-A2 eingesetzt wird). MfG, Tino
Tino Schurzmann schrieb: > (1) "HW" > > Die früheren Messungen, die du beschreibst, wurden mit den Modulen > > "MN-ZB24-A2" gemacht, richtig? > > > > Die Module, die du jetzt einsetzt sind aber sicherlich "AT-MN24-A2", > > stimmts? ... beides korrekt. Tino Schurzmann schrieb: > Die Meshnetics-Module beinhalteten aus verschiedensten Gründen den > > AT86RF230A, die Atmel-Module den AT86RF230B. > > > > Meiner Meinung nach funktioniert der Atmel-MAC nur bis zur Version 2.1 > > oder 2.2 mit dem RF230A. Könnte das ein Problem sein? Die Meshnetics-Software (openmac) läuft auf der A und auf der B-Revision zufriedenstellend. Zu Testzwecken haben wir ein MeshBean2-Board mit einem Atmel-Modul (AT86RF230B) bestückt -> lief zufriedenstellend (wie auch auf unserer Hardware). Eine Portierung unserer Applikation auf den Meshnetics-Stack wäre zwar mit einem gewissen Aufwand machbar, aber der wird ja nicht mehr supported ... Welchen Stack setzt ihr denn jetzt ein ?
SHotz schrieb: > Habt ihr herausfinden können, wo (bzw. warum) die Frames verlorengehen ? Nö, allerdings habe ich mich verschrieben. Ich meinte eine "einstellige Zahl" (also nicht Prozent, sondern 1E-5 ungefähr). > Ist der AT86RF230 nicht empfangsbereit, wenn über die SPI der letzte > Frame abgeholt wird (dauert über die 4MBit/s-SPI bei 70 Bytes * 8 Bit = > 560Bit ca. 150µs) ? Man kann halt nur entweder einen Frame per SPI lesen oder aber das IRQ-Status-Register per SPI lesen, um die Interruptquelle zu ermitteln. Ist aber nicht tragisch, der IRQ geht ja deshalb nicht verloren, sondern er wird danach bearbeitet. Du musst ja ohnehin 40 Symbole (= 560 µs) warten, bevor du den nächsten Frame senden darfst (minLIFSperiod).
SHotz: Ne, ich meinte nicht den OpenMac. Bitcloud nutzt einen eigenen MAC. Der ist eben für den Zigbee-Stack optimiert worden und hat Timing-bedingt einige Optimierungen erfahren. Wenn es nicht um BitCloud und keine HAL-Sachen geht, dann ist unser aufgeborter 2.4er MAC im Einsatz. Da sind aber haufenweise eigene Fixes und Anpassungen drin. Hilft dir also so nicht weiter. all: Würden 128RFA-Module die Probleme mindern?
Tino Schurzmann schrieb: > Würden 128RFA-Module die Probleme mindern? Schwer zu sagen, solange keiner analysiert hat, was denn genau das Problem ist. Kommen die Frames nicht an, kommt die Firmware nicht hinterher, sie zu lesen, was sonst noch?
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.