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:
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.
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?
