mikrocontroller.net

Forum: HF, Funk und Felder ZigBit und MAC 2.5.1 - Reichweitenprobleme


Autor: SHotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
at86rf212.txt:0x05 PHY_TX_PWR:
PA_BOOST GC_PA[1] GC_PA[0] TX_PWR[4] TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0]
at86rf230a.txt:0x05 PHY_TX_PWR:
TX_AUTO_CRC_ON - - - TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0]
at86rf230b.txt:0x05 PHY_TX_PWR:
TX_AUTO_CRC_ON - - - TX_PWR[3] TX_PWR[2] TX_PWR[1] TX_PWR[0]
at86rf231.txt:0x05 PHY_TX_PWR:
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]

Autor: A. W. (uracolix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so: hast du eigentlich mal verschiedene Kanäle ausprobiert?

Autor: SHotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SHotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SHotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tino Schurzmann (Firma: A.N.Solutions GmbH) (pacman78)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: SHotz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Tino Schurzmann (Firma: A.N.Solutions GmbH) (pacman78)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.