Ich habe nur welche gekauft, aber noch nichts damit aufgebaut.
Mein bisheriger Eindruck ist: Im Datenblatt steht niergends welcher
ATmega1281-Portpin mit welchem GPIOx des Moduls verbunden ist und der
Hersteller "kann" einem auch net weiterhelfen.

hi thomas,

schau mal: ZigBit_OEM_Module_Product_Datasheet.pdf (DOC.M-251~01v1.9)
S. 9

gruß alex

hier das pdf ;)

hi thomas,

hast du eigentlich das dev. bzw. eval kit gekauft oder nur module?

gruß alex

Nur Module (von Farnell)

> schau mal: ZigBit_OEM_Module_Product_Datasheet.pdf (DOC.M-251~01v1.9)
> S. 9

Hallo Alex,

vielen Dank für das PDF. Da stehen die Infos wirklich auf seite 9.
Auf der Website des Herstellers gibt es aber wohl nur das hier
http://www.meshnetics.com/ZigBit_OEM_Module_Produc...

Und da ist auf Seite 9 die gleiche Tabelle, aber ohne die ATmega1281
Angaben. Ich hatte den Hersteller diesbezüglich schon angeschrieben,
aber nicht wirklich eine brauchbare Hilfe erhalten?!?
Wo hast Du denn das Datenblatt her? Hast Du ein solches Entwicklungskit
erworben?

Gruß & danke nochmals,

Thomas

Ich selber habe noch nichts damit gemacht....hab da momentan leider
keine Zeit...würde mich aber auf jeden Fall interessieren.
Ich kenne die Module nur von der Hochschule Heilbronn....da gibt es
momentan Seminar- und Diplomarbeiten auf dem ZigBee-Gebiet.

Hallo Leute,

ich liebäugle mit den Modulen von Radiocrafts, da die Zigbee Module
haben, die sowohl mit dem AtMega als auch mit dem TI / Chipcon (Core
8051) bestückt sind.
Den 8051 kenne ich fast auswendig, in den AtMega müsste ich mich noch
einarbeiten.
Habe weder mit den einen noch anderen ZigBee Modulen Erfahrungen.
Wäre nett, wenn mal jemand darüber etwas erzählen könnte.
Compiler, Einstellungen, Fehler im Stack, Einbindung eigener
Applikationen, Reichweite, Antennen, Datenrate, Stromverbrauch etc. also
all das Zeug, was einem Anfänger Kopfschmerzen bereitet.

Frohes Fest.

@Reinhold Loose

ich arbeite mit den meshnetics modulen, haben auch den atmega 1281v.
zu programmieren an sicht ne easy sache.
der support von meshnetics, naja aber geht.
man muss allerdings dazu sagen, ich hab auch nur module und kein dev.
kit.
beim dev kit wäre ein support offiziel dabei.

Compiler, gcc mit avr studio, also einwandfrei.
einstellungen, hab eine weile dazu gebracht bis sie wirklich liefen.
nachdem ich allerdings die pingPong appl. bekommen hatte und dadruch
wussten was und wie zu setzen ist. kein problem mehr.
stromverbrauch bei mir bis jetzt 1mA im Sleep. 20mA Coordinator.
reichweite. hab wohl meinen dipol nicht ganz optimal, daher nicht
besonders weit(2 räume).

Hallo,

ich hänge gerade auch bei der Initialisierung der Verbindung zwischen
zwei Meshnetics Zigbee Modulen.

Ich habe auf beiden Modulen MAC, PAN_ID und die Logical_Adress gesetzt
und überprüfe ob das Modul auch im richtigen Modus (Coordinator oder
EndDevice) ist.

Konfiguraton:
Coordinator  logicalAddr 0x0
             macAddr  2
             ZIGBEE_COORDINATOR_TYPE

EndDevice    logicalAddr 0x15
             macAddr 3
             ZIGBEE_END_DEVICE_TYPE

Netzwerk     panID 0xD151

Das eine Modul (Coordinator) kann dann auch mit fw_joinNetwork() ein
Netzwerk anlegen. Jedoch gelingt es mir nicht, ein als End-Device
arbeitendes Modul mit diesem Netzwerk zu verbinden. Nach dem Aufruf von
fw_joinNetwork wird immer der Lost-Handler aufgerufen.

Wenn ich auf beide Module die Software für den Coordinator aufspiele,
kann jeweils nur das zuerst gestartete Modul ein Netzwerk eröffnen. Das
zweite reagiert auf fw_joinNetwork mit Lost.
Das sollte wohl auch so ein, da ja schon ein Koordinator für das Netz
exisitert und damit das Netzt nicht nochmal existieren kann.
Also scheint die Hardware zumindest ok zu sein.

Hat jemand eine Idee was noch fehlt, oder wo ich noch suchen könnte,
oder ein Minimalbeispiel mit funktionierender Netzverbindung?

Gruß Holger

Hi,

hab mein Problem inzwischen gelöst. Es lag an einem fehlenden Define im
Makefile.

@Jan F.
Zum UART Bootloader kann ich leider nix sagen. Ich arbeite über JTAG.

Gruß Holger

Holger M. wrote:
> Hi,
>
> hab mein Problem inzwischen gelöst. Es lag an einem fehlenden Define im
> Makefile.
>
> @Jan F.
> Zum UART Bootloader kann ich leider nix sagen. Ich arbeite über JTAG.
>
> Gruß Holger

Wir haben das Problem gelöst. Der Bootloader auf dem Boards hatte einen
weg. Haben den Bootloader über JTAG neu draufgespeilt. Nun funktioniert
der Bootloader prima.

@ Holger M

Wir haben auch das Problem, dass wir kein Netz aufgebaut bekommen. Wir
haben das mit dem SerialNet Programm, also über AT-Befehle ausprobiert.
Heute haben wir das Ping Pong Programm getestet und es baut sich auch
hier keine Netz auf.
Die WSN Demoapplikation funktioniert ohne Probleme. Die Hardware ist
also Ok.

@Jan F.:
Ich habe die PingPong Applikation nicht, kann dazu also nichts sagen.

Normalerweise sollte man aber davon ausgehen können, dass die
vorgefertigte Demo-Applikation auf den Modulen problemlos läuft.

Wurden die originalen Hex-Files aus der Demo auf das Modul geladen, oder
wurden die zuvor neu erstellt. Dann kann es evt. sein, das es einen
Adresskonflikt gibt, wenn dem Makefile nicht die richtigen Parameter
übergeben wurden. Beim Makefile der WSN-Demo, die in den freien
Downloads dabei ist kann/muss man beispielsweise die MAC-Adresse für die
einzelnen Module mit übergeben.
Aber wie gesagt, über die PingPong-Applikation kann ich nur spekulieren,
da ich nur die frei verfügbare Version des Stacks von Atmel habe und da
ist die nicht dabei.

Ansonsten kann ich nur sagen, dass wenn die Parameter MAC-Address,
PAN-ID und NWKlogicalAddress gesetzt sind sowie das Modul die richtige
Role haben (ein Coordinator, ein oder mehrerer Router bzw. EndDevices)
fünktioniert das Netz auf Anhieb. Mehr muss man garnicht setzen.

Beim setzen der Device-Role sollte man überprüfen ob die Role auch
verfügbar ist (oder sich sicher sein, dass dies der Fall ist). Je nach
dem welche der Libs des eZeenet Stacks eingebunden werden kann es
nämlich sein, dass das Modul z.B. kein Coordinator werden kann.

Außerdem ist nach einer Änderung der MAC-Adresse, oder der Role
innerhalb der Software ein Neustart des Stacks nötig. Dazu gibt es die
Funktion fw_warmReset(FALSE). FALSE sorgt dafür das die zuvor gesetzten
Werte erhalten bleiben.


Gruß Holger

Da sich hier doch einige mit den Zigbee Modulen vom Meshnetics
beschäftigen und nicht immer alles ganz rund läuft, habe ich mal einen
Eintrag im Wiki angelegt.

Meshnetics Zigbee

Dort können aufgetretene Probleme und vorallem deren Lösugen
dokumentiert werden.

Wer Lust und Zeit hat, darf also Inhalt beitragen.

Gruß Holger

Joan wrote:

> Wenn ich die ZigBit module an 3.3V häng, dann laufen die internen
> Oszillatoren wie im Datenblatt angegeben.. 4MHz an Pin 10 und 32kHz an
> Pin 7.

Wenn der 32-kHz-Quarz läuft, dann muss auch der AVR noch funktionieren.
Dieser Oszillator läuft nur an, wenn die Firmware ihm das sagt.

Sorry, ich habe mir die Teile noch nicht so genau selbst angesehen.
Wenn du JTAG zur Verfügung hast, ist es allemal einen Versuch wert,
meiner Meinung nach machen die Leute bei Meshnetics alles via JTAG.

Joan wrote:

> Dann werd ich mal versuchen weiter nach Anleitung ^^ (das pdf von weiter
> oben) die ISP via Fuses freizuschalten.

Wofür brauchst du das ISP denn?

Kann es sein, dass der SPI-Bus einfach mal so verwurschtelt ist (da
wird ja wohl der AT86RF230 dranhängen), dass man ihn nicht für ISP
benutzen kann?

> Wäre es für das Wiki wünschenswert die ATmega1281 <-> ZDM-A1281-A2
> Pinout als Tabelle zu beinhalten? Gäbs da Copyright probleme? Weil ich
> hab eins von den Modulen offen und konnte da alles durchklingeln..

Wenn du es selbst ausklingelst, kann es keine Copyright-Probleme geben.

Hallo,

ich habe noch nicht versucht  über ISP mit den Modulen zu kommunizieren
und kann deshalb auch eigentlich nichts dazu sagen.

Aber seid ihr sicher, dass das überhautp geht? Weil immerhin ist der
ISP-Anschluss im Datenblatt (Seite 9) als "Reserved for stack operation"
beschrieben.

Ich hattte das so verstanden, dass die Schnittstelle damit nicht nutzbar
ist. Ähnliche Erfahrungen habe ich zumindest mit anderen Modulen
gemacht.

Gruß Holger

Joan wrote:

> ..sieht also recht sauber aus und es sollte mMn funktionieren, den
> ATmega1281 allein anzusprechen, da das RST des RF230 ja vom ATmega
> gesteuert wird (mal weiter knobeln wie die SPI da beeinflusst wird).

Naja, wenn die Pins in der Luft hängen beim RESET (den du ja zum
Programmieren brauchst), dann könnte es sein, dass der RF230 sich
auf den SPI-Bus draufklemmt mit seinem Ausgangstreiber.

Ist das /RESET denn auch wirklich zum ATmega1281 geroutet?

Vorsicht, der AT86RF230 aktiviert seinen Ausgangstreiber an MISO bei
jedem select, auch wenn sein /RST aktiv ist.  Wenn du dir sicher
sein willst, dass der nicht in die Suppe spuckt und MISO hochzieht,
dann solltest du bei ihm sowohl /RST als auch SEL hochohmig auf Vcc
ziehen -- der ATmega fasst diese Leitungen ja nicht an, wenn er
selbst im reset ist.

Ja, /SS ist beim Programmieren egal, der ATmega überwacht MOSI und
SCK, wenn er im reset ist, und wenn er eine programming enable
Sequenz entdeckt, aktiviert er den MISO-Treiber.

So, Wiki ist um ein paar Schnipsel reicher.. hoffe das mit dem Bild geht
so (http://www.mikrocontroller.net/articles/Meshnetics_Zigbee)

Mit meinem Problem bin ich allerdings nicht viel weiter gekommen.
Ich habe mal die /RST und /SEL Pins vom RF230 direkt gesteuert
(high/low) und mir dazu die /MISO Leitung angesehen (ohne USBprog auf
der /MISO-Leitung).

..folgendes Ergebnis:

Fall   /RST   /SEL   /MISO
1      L      H      tristate
2      L      L      L (aktiv)
3      H      L      L (aktiv)
4      H      H      tristate

Fall 4 ist der mMn interessante Zustand, bei dem man per ISP proggen
können sollte.

Mit USBprog wurden die tristate /MISO-Pegel auf High gezogen
Im Beitrag eins drüber hab ich die Passage im RF230 Datenblatt falsch
verstanden: "..Note, when both SEL and RST are active, the MISO output
driver is also enabled"
Das meint wohl, wenn beide auf Low gezogen werden (Fall 2 = active) und
nicht, wie von mir gedacht (beide high = active = Fall 4).

Wenn ich jetzt keinen Knick im Hirn habe, müsste sich der ATmega im
ISP-Modus eigentlich die MISO Leitung schnappen können, da der RF230 ja
bei VCC anliegend /RST und /SEL high macht und damit /MISO tristate wird
->> free for all.

Laut JTAG ist die SPI Fuse auf enabled.

Weiß nicht, was man jetzt noch probieren könnte?
Vielleicht nen Fehler bei USBprog? ->
http://forum.embedded-projects.net/viewtopic.php?id=269

Grüsse
Joan

Warum bist du eigentlich auf das ISP so erpicht, wenn du doch mit
JTAG zurecht kommst?

Hab die Trägerboards für die Module schon in Auftrag gegeben, ohne JTAG,
mit ISP.. ;)

Olli S. wrote:

> Bei mir sind Alle Versuche mit ISP gescheitert, ...

Ich habe auf einem völlig anderen Board auch Probleme, bei einmal
aktivierter Applikation (die den AT86RF230 ja aktiviert) noch mittels
ISP zu programmieren.  Ein AVRISPmkII schafft es gerade so, ein JTAG
ICE mkII im ISP-Modus nicht.  Der Grund dürfte folgender sein: der
AT86RF230 ist nach einem Power-On im Status P_ON, in dem er die
Digitalleitungen mit schwachen Pullup/-down-Widerständen vorbelastet.
Sowie die Firmware des Controllers aber losläuft, aktiviert sie den
AT86RF230, und dieser schaltet die Pull-Widerstände ab (damit sie im
Betrieb keinen Strom mehr verbrauchen).  Dies erfolgt in der Annahme,
dass der Controller ja nun die Steuerung übernommen hat und daher alle
Digitalleitungen selbst auf definierten Pegeln hält.

Dummerweise bricht diese Annahme zusammen, sowie der Controller in
dieser Situation einen Reset bekommt (z. B. eben den Externreset vom
ISP-Interface).  In diesem Moment floaten die Leitungen, und bspw.
durch Übersprechen besteht nun die Gefahr, dass der AT86RF230 aus
Versehen aktiviert wird.

Wenn die Applikation wieder gelöscht wird (chip erase), funktioniert
dagegen das ISP ordentlich, da der AT86RF230 seinen Zustand P_ON nicht
verlassen kann.

Zwei mögliche Abhilfen sehe ich da.  Erstens kann man die Reset-Leitung
vor dem Zuschalten der Betriebsspannung auf Masse klemmen.  Damit
verlässt der Prozessor seinen Reset nie, und kann den AT86RF230 nicht
aktivieren.  Die ISP-Schnittstelle hat als einzige Bedingung, dass
mindestens 20 ms seit dem Reset vergangen sein müssen, bevor versucht
wird, die programming-enable-Sequenz runterzuschreiben -- eine Höchst-
grenze gibt es aber nicht.  Man kann also einige Sekunden später daher
kommen und das ISP aktivieren.  (Was nicht geht, ist die Wiederholung
der Sequenz, aber die braucht man normalerweise ja nicht.)

Eine andere Abhilfe wäre, dass die Firmware selbst einen `Programmier-
modus' kennt: nach einem Power-On-Reset erkundigt sie sich nach dem
Zustand eines Tasters o.ä., und wenn dieser aktiviert ist, schaltet
sie den AT86RF230 nicht scharf.  Damit sollte anschließend das ISP
auch ganz normal funktionieren.

Hallo zusammen,

ich finde das Teil hochinteressant, alleine schon deshalb, weil die
Hardware sozusagen gebrauchsfertig ist, ohne daß man sich, wie bei
Eigenkonstruktionen sonst nötig, im Detail z.B. mit dem RF-Design des
PCB herumschlagen muß.
Was ich jedoch bisher nicht zuverlässig in Erfahrung bringen konnte,
ist, welche Firmware denn nun im Lieferzustand drauf ist, insbesondere,
ob der Bootloader schon drauf ist (der Rest ist mir egal, weil ich
ohnehin eine eigene Applikation draufmache, aber ein vorhandener
Bootloader würde mir schon enorm helfen). In einem anderen Forum habe
ich den Eindruck gewonnen, daß bei früheren Lieferungen bereits Firmware
drauf war, irgendwann später aber nicht mehr.
Weiß jemand, wie es derzeit ist? Und, sollte Firmware drauf sein, liegt
wenigstens eine kleine Dokumentation bei, oder wie erfahre ich sonst
z.B., mit welcher Baudrate der Bootloader arbeitet, ob er Handshake
braucht und ob er srec- oder hex-Files verlangt?
Wäre dankbar für einen Hinweis.

Viele Grüße, Klaus

Christian C. wrote:
>
> ich habe meine beiden Module hier gekauft:
>
http://www.dataspherewireless.de/manufacturers/mes...
>
Was hast Du bezahlt? Ich wollte es dort auch versuchen, bin aber an der
Registrierung gescheitert, weil dort die UStID ein Zwangsfeld ist, ich
als Privatperson aber keine habe.
Gestern habe ich meine bei DigiKey bestellten Module bekommen. Ich hatte
4 bestellt, um in den Genuss der Versandkostenfreiheit zu kommen. Ich
habe dafür komplett incl. Einfuhrumsatzsteuer (das Zeug kommt aus den
USA, kam innerhalb von 3 Tagen) knapp 100 EUR bezahlt.

Um auch gleich meine oben gestellte Frage z.T. selbst zu beantworten:
außer den nackten Modulen war nix dabei, schließe aber aus der
Dokumentation des Entwicklungskits, daß Bootloader und SerialNet schon
drauf sind, habe ich aber noch nicht geprüft.
Da ich das für den Bootloader notwendige Gegenstück bootloader.exe nicht
bekommen kann, habe ich eine Source für Linux bei
http://pervasive.researchstudio.at/portal/projects/meshprog dafür
gefunden. Ich weiß noch nicht, ob ich mir ein Linux auf dem PC
einrichte, um es dort zu kompilieren und laufen zu lassen, oder
versuche, es für C#-Express anzupassen oder vielleicht nur die Methode
abschaue und in VB-Express realisiere (da kenne ich mich besser mit
aus).

Gruß, Klaus

hat es mittlerweile jemand geschafft son modul per SPI zu proggen?
hab mir 2 zigbit amp module zugelegt, bei denen gibts für den
transmitter ne extra VDD leitung, wenn ich die nicht anschließ dürft der
ja nicht in die suppe spucken

wenn ich versuch den atmega mit ponyprog einzulesen bekomm ich erst paar
fehler und dann wiederholt 0x00 - 0xFF in 2er schritten zurück

hab das modul auch mal aufgemacht, SPI leitungen führen alle zum atmega,
transmitter hat wie erwartet kein strom ...

LOL

"ATmega640/1280/1281/2560/2561 data sheet page 351 section 30.8.1 Serial
Programming Pin Mapping " - SPI pins != ISP pins ... umlöt

hallo ich hab da mal eine Frage,
ich hab hier ein dev-kit von MeshNetics und will jetzt die WSNDEMO
ausprobieren. Also sämtliche Platinen wurden mit dem bootloader
programmiert, ein Gerät hab ich durch die DIP-Schalter als coordinator
definiert. Dieser coordinator wird auch im wsn monitor erkannt und die
sensoren können auch ausgelesen werden, aber die anderen beiden
platinen, die als enddevices arbeiten sollen und sich in das zigbee netz
einklinken sollen, werden net erkannt. also sie kommen auch nicht in das
coordinator netz rein, weil die grüne LED einfach weiter blinkt.
So nun meine Frage, muss man ein vor dem programmieren irgendwas
anpassen? ich habe was von MAC adresse in Makefile gelesen, aber hab da
nix gefunden.
könnte mir da bitte jemand auf die sprünge helfen?
ich bedanke mich im voraus schonmal für eure mühe.

gruß

ok funktioniert mittlerweile alles, da scheint was mit den channel
einstellungen schief gelaufen zu sein.

Michael S. wrote:
> Hat jemand eine Library für die Meshnetics module für eagle oder für
> Target3001!  ? Oder einen Teil eines Layouts wo die Lötpads für die
> Module schon definiert sind ?
>
> Danke
> MIchael

Da kann ich helfen - für eagle.
In der Atmel.lbr am Ende unter ZDM A1281....

Gruß, Klaus

Rolf wrote:

> damit müssten es doch maximal 15 sendewiederholungen
> sein,oder?

Ja.

> und die maximale Anzahl an CSMA-Zugriffsversuchen ist 7?

Beim AT86RF230: ja.  Aber vorsicht, damit bist du nicht mehr
aufwärtskompatibel zum AT86RF231: dieser benutzt den Wert 7 als
Kennzeichen, dass die Übertragung ohne CSMA/CA zu starten ist
(das kann man beispielsweise für GTS gebrauchen), und der Wert 6
wurden dort als reserviert markiert.

Hallo Herr Bopp,
haben Sie ihr Problem schon gelöst? Wenn nicht, werde ich mich darum
kümmern.

Gruß aus Leo

Rolf wrote:

> der analog-comparator des aktiven moduls vergleicht ständig die
> spannung.

Würde ich nicht tun.  Guck dir mal den Stromverbrauch an (Bild 210
im Datenblatt): das Teil braucht >~ 50 µA.

Entweder machst du's wie von Axel vorgeschlagen, oder du misst die
Spannung bei einem irgendwie periodischen Aufwachen (das kann ja
sehr selten sein, Batteriespannungen brechen im Allgemeinen nicht
innerhalb von 5 Minuten zusammen :) mit dem ADC nach.

> dürfte das gehen oder ist es sinnvoller die kommunikation der beiden
> Atmega1281 über UART oder sonstiges zu erledigen?

Pin zum Aufwecken ist OK, aber falls du mehr zu erzählen hast, solltest
du trotzdem RS-232 oder I²C für die Kommunikation in Betracht ziehen.
Die RS-232-Leitung kann ja auch zum Aufwecken an einen interruptfähigen
Pin parallel geklemmt werden.

Rolf wrote:

>>Würde ich nicht tun.  Guck dir mal den Stromverbrauch an (Bild 210
>>im Datenblatt): das Teil braucht >~ 50 µA.
>
> Bild 210?kannst du mir die seite nennen-find unter 210 nichts?

Du hast aber auch ins Datenblatt des ATmega1281 geguckt, nicht in
das für den AT86RF230, ja?  Bei mir ist es Seite 413, aber ich muss
nicht zwingend die letzte Datenblattversion hier haben.  Die
Überschrift ist

Figure 210. Analog Comparator Current vs. VCC

> naja,über periodisches aufwachen: da müsste ich ja den ADC an die
> batterie des anderen moduls hängen um zu prüfen?!

Nein, der aktive Knoten (wie aktiv er auch immer ist, das weißt nur
du) ermittelt das über seinen eigenen ADC.

Rolf wrote:

> nur mal ne dumme frage nebenbei: welche schnittstelle ist zum
> programmieren mit dem avr-studio in C am geeignetsten?JTAG oder?

Ich glaube, bei den Zigbits sind die ISP-Anschlüsse nicht rausgeführt,
da bleibt dir nur JTAG übrig.

Rolf wrote:

> ich hab mir das BATMON-Register mal angeschaut.Das kann ich so wie es
> aussieht nicht nehmen,weil das nur im Basic Operating Mode geht.
> Ich möchte/muss jedoch den Extended Operating Mode nehmen aufgrund von
> Kanalprüfungen und Empfangsbestätigungen (ACK).Dort geht das mit BATMON
> nicht.

Wie du zu dieser Meinung kommst, kann ich nicht nachvollziehen.

Der BATMON läuft komplett neben dem eigentlichen Transceiver und ist
von dessen Wohl und Wehe beinahe komplett unabhängig.  Das Einzige,
was er sich mit dem Transceiver teilt ist, dass er im sleep-Modus
abgeschaltet wird und dass er einen Interrupt auslösen kann.

Wenn du dir die Prinzipskizze des BATMON ansiehst im Datenblatt, das
ist letztlich auch weiter nichts als ein DAC und ein Komparator,
allerdings muss der Komparator dort halt nicht schnell sein, sodass
er Strom sparend aufgebaut sein kann.

[ADC]

> Aber wenn ich mir den Stromverbrauch ansehe liegt der hier mit ca. 230µA
> @ 3,5V wesentlich höher als wenn ich das mit nem Analog-Comparator
> machen würde (60µA @ 3,5V)!

Du sollst doch aber nicht permanent messen!  Dann braucht der ADC
aber auch nur periodisch Strom, danach ist er wieder deaktiviert.

hallo.

hat hier jemand schonmal etwas auf den modulen mit dem Battery Monitor
(BATMON) programmiert?
ich habe probleme bei der fehlerfreien ausführung der entsprechenden
funktionen.
mfg,tommy

Tommy Tacker wrote:

> ich habe probleme bei der fehlerfreien ausführung der entsprechenden
> funktionen.

Wenn du jetzt noch erzählst, welche Probleme du hast, kann dir
vielleicht auch jemand helfen...

mit unten stehender funktion möchte ich meine batteriespannung
kontrollieren.jedoch kommt bei mir unten aufgeführtes "undefined
reference"-problem.tippfehler liegen nicht vor und alle lib-datein des
bitcloud-stacks sind auch in meinem makefile eingebunden.die header
rfBattery.h ist ebenfalls in meinen c-files eingebunden.

void appEndDeviceTaskHandler(void)
{
 batmonReq.voltage = RF_1V85_BAT_VTG;// setze Schwellwert auf 1,85V
 batmonReq.RF_BatteryMonConf = RF_BatteryMonConf;//
Confirm-Handler-Aufruf
 RF_BatteryMonReq(&batmonReq);
...
}

mein problem:
die funktion "RF_BatteryMonReq(&batmonReq);"
die dazu dient die werte zu setzen und bei erfolg den confirm-handler
aufzurufen bringt mir den fehler:

D:\Meshnetics Version 2.3.0\ZDK_Complete\Sample
Applications\kranhaken/kranenddevice.c:33: undefined reference to
`RF_BatteryMonReq'
make: *** [link] Error 1
Build failed with 1 errors and 0 warnings...

woran könnte es also liegen das der fehler auftritt???

Ich habe mir den Bitcloud-Kram mal geladen.  Ich finde da nirgends
eine Dokumentation die besagt, dass eine derartige Funktionalität
implementiert sei.  Es gibt zwar unter MAC_PHY ein rfBattery.h,
aber weder zugehörige Dokumentation, noch scheinen die entsprechenden
Funktionen in der Bibliothek zu sein.

Zwar ist die Benutzung des battery monitors im AT86RF230 relativ
simpel, aber es sieht nicht so aus, als würde dir BitCloud irgendwie
Zugriff auf die Hardware geben wollen.

Das das ganze Paket von Atmel supported wird, kannst du ja dort mal
nachfragen, was es damit auf sich hat.

ich habe mal den support von avr angeschrieben.

>Jörg Wunsch wrote:

>...aber es sieht nicht so aus, als würde dir BitCloud irgendwie
>Zugriff auf die Hardware geben wollen.

wäre das nicht etwas verwerflich,wenn die leute von meshnetics damit
werben,dass man mit bitcloud eigene anwendungen schreiben kann usw. und
dann sind funktionen,die im stack aufgeführt sind nicht nutzbar??!?

Tommy Tacker wrote:

> wäre das nicht etwas verwerflich,wenn die leute von meshnetics damit
> werben,dass man mit bitcloud eigene anwendungen schreiben kann usw. und
> dann sind funktionen,die im stack aufgeführt sind nicht nutzbar??!?

Entscheidend ist doch aber nicht, was in irgendeinem Headerfile mehr
oder minder zufällig herumsteht, sondern was dokumentiert ist.  Da
ist es nicht dabei.  Das Feature, was du benutzen willst, ist also
einfach (noch) nirgends ,,beworben''.  ,,Eigene Anwendungen schreiben''
ist ziemlich allgemein, und dass du das damit prinzipiell kannst,
wirst du ja kaum in Abrede stellen wollen.

Ja, man hätte wohl das Headerfile besser vor dem Release löschen sollen,
da es sich ja offenbar auf eine ,,Baustelle'' bezieht, die im Release
selbst noch nicht drin ist.  Aber für dich würde sich dadurch gegen-
über dem derzeitigen Stand rein gar nichts ändern.

leider hast du wohl recht.mir scheint das auch so,als ob nur die
funktionen anwendbar sind,die in der *.chm dokumentiert sind.

da ja am zigbit-modul die spi-schnittstelle für die kommunikation mit
dem transceiver besetzt ist,werde ich wohl gar nicht erst auf das
BATMON-register des transceivers zugreifen können,oder?

Tommy Tacker wrote:

> da ja am zigbit-modul die spi-schnittstelle für die kommunikation mit
> dem transceiver besetzt ist,werde ich wohl gar nicht erst auf das
> BATMON-register des transceivers zugreifen können,oder?

Ja, das sieht mir so aus, als wäre das nicht vorgesehen.  Das ist
in einem kompletten Stack ohnehin nicht ganz trivial.  Erstens
müsstest du ja sicherstellen, dass dein Zugriff auf den Transceiver
nicht mit möglichen Zugriffen des Stacks kollidiert.  Zweitens darf
der Transceiver sich nicht im Sleep befinden, denn dann kann man
auf seine Register nicht zugreifen.  Die Verwaltung des Sleep/Wakeup
wiederum kann man natürlich nicht am Stack vorbei machen, da der ja
seine Aktionen ebenfalls daran ausrichten muss.

Wenn man in die Bibliotheken reinschaut, dann findet man dort natürlich
die entsprechenden Funktionen, mit denen auf den Transceiver zugegriffen
wird.  Da sie aber nicht dokumentiert sind: use at your own risk.

hmm,ich persönlich finde das nicht so gut von meshnetics ein produkt auf
den markt zu bringen,wo die hälfte noch gar nicht fertig ist. :(

naja,wenigstens dürfte dann noch der AD-converter frei sein,um ihn für
die spannungsüberwachung zu nutzen!?

Tommy Tacker wrote:
> hmm,ich persönlich finde das nicht so gut von meshnetics ein produkt auf
> den markt zu bringen,wo die hälfte noch gar nicht fertig ist. :(

Hättest du es denn lieber, stattdessen gar nichts auf dem Markt zu
haben, weil ein solches Projekt nie wirklich endgültig fertig ist?
,,Die Hälfte'' ist ja auch eine ziemliche Übertreibung... nur weil
nun gerade dein Lieblingsfeature nicht dabei ist, dies so weit
aufzublasen, dass es 50 % ausmachen würde.

> naja,wenigstens dürfte dann noch der AD-converter frei sein,um ihn für
> die spannungsüberwachung zu nutzen!?

Ich glaube mich zu erinnern, dass ich beim Drüberfliegen dafür ein
API gesehen hätte, aber nachgucken kannst du selbst in der Doku.

>,,Die Hälfte'' ist ja auch eine ziemliche Übertreibung...

na klar ist das ne übertreibung,den genauen anteil an features die nicht
machbar sind muss ich ja nicht prozentual wissen :)

>Ich glaube mich zu erinnern, dass ich beim Drüberfliegen dafür ein
>API gesehen hätte, aber nachgucken kannst du selbst in der Doku.

meinst du damit extra eine API für spannungsüberwachung oder ADC
allgemein?
die wäre dann sicherlich in "adc.h" drin.

Tommy Tacker wrote:

> meinst du damit extra eine API für spannungsüberwachung oder ADC
> allgemein?

ADC allgemein, aber indem man Vcc als Referenz benutzt und Vbg
misst, kann man damit Vcc bestimmen.  Muss man allerdings kalibrieren,
da Vbg zu sehr streut.

Jörg Wunsch wrote:

>ADC allgemein, aber indem man Vcc als Referenz benutzt und Vbg
>misst, kann man damit Vcc bestimmen.  Muss man allerdings kalibrieren,
>da Vbg zu sehr streut.

naja,dass mit dem messen von Vbg ist auch wieder so eine sache.die adc.h
von BitCloud bietet dies auch nicht an. :( zumindest erscheint mir das
so.in der dokumentation des Stack kann nur bis zu "HAL_ADC_DIFF_CHANNEL7
(ADC3 - ADC2 with gain 200x).laut datenblatt des ATmega1281 müsste es in
BitCloud noch eine konforme Möglichkeit dem "1.1V(Vbg)" geben.tut es
aber nicht


noch zur Info:

ich habe atmel mal angeschrieben.die möglichkeit das BATMON-register zu
nutzen besteht im BitCloud nun definitiv nicht.

es ist geplant noch im april eine neuere version des Stacks raus zu
bringen.dabei soll ein direkter registerzugriff auf den transceiver
möglich sein.

Gr schrieb:

> Anybody english-speaking coud help with meshbean2 board and zigbit
> modules?

The Atmel AVR support?  Their official statement is that they are
continuing to support the modules, regardless whether they've been
obtained from Meshnetics directly, or now from Atmel.

Gr schrieb:
> May be someone have correnspondense between pinout m1281 and zigbit
> modules in meshbean2 boards?

Soweit ich mich entsinne, müsste das µracoli-Projekt (-> Google) diese
Module unterstützen.  Daher sollte es dort auch eine Liste des Pinouts
geben.  Stammte die nicht sogar aus diesem Thread hier?

(The main language of this forum is German.  Use embdev.net for
English-language fora.

As far as I remember, the µracoli project supposedly supports these
modules, thus it also ought to have a pinout mapping.  Didn't it even
show up above within this thread?)

Die Quelle fuer die interne Meshbean/Zigbit Verdrahtung stammt von hier
und funktioniert, sowohl mit den 2.4GHz als auch mit den 900 MHz
Modulen.

 - http://www.mikrocontroller.net/articles/Meshnetics_Zigbee
 - http://uracoli.nongnu.org/manual/usr/group__grpWdba1281.html
....
The source of the internal wiring was found on mikrocontroller.net [see
links above] and is working as well with the 2.4GHz and 900 MHz modules.

Cheers Axel

Das 1MHz signal auf CPU_CLK stammt vom AT86RF230 (CLKM). Die originale
Meshnetics Software verwendet dieses Signal als CPU Takt und stellt
diesen bei der Initialisierung auf 4MHz um (so war es jedenfalls mal).

Kannst du noch sagen, welche Fuse Werte du programmiert hast ? Solange
die JTAG Fuse nicht abgeschaltet ist, hast du mit einem Dragon oder
JTAG-ICE noch eine Chance.

MasterAlexei schrieb:

> Ich habe bei mir einen JTAG-ICE der ersten Generation noch.

Offiziell kann man damit den ATmega1281 nicht programmieren, und
zumindest den Flash wirst du damit keinesfalls programmieren
können (da hat sich an der JTAG-Behandlung was geändert gegenüber
dem ATmega128).

> Kann ich mit
> dem was machen? Mit welchem tool ist es möglich?

Für das Setzen der Fuse könntest du mal gucken, ab avrdude das kann.
Ich sehe auf den ersten Blick nichts, warum es den Dienst komplett
verweigern sollte, auch wenn diese Kombination `unsupported' ist
von der JTAG-Hardware.  Ggf. kannst du auch behaupten, du würdest
einen ATmega128 programmieren (der wurde ja vom alten ICE noch
unterstützt) und dann mit der Option -F den Test der Signatur
abschalten.

Welche Werte liest du denn aus ? Man koennte mit einer Interpretation
des aktuellen Zustandes anfangen, damit man hinterher nicht ganz
conFUSEd ist ;-)

Eine low fuse von 0xE0 müsste OK sein.

Jörg Wunsch schrieb:
> Eine low fuse von 0xE0 müsste OK sein.

Hurra! Es funzt wieder, ich kann den wieder lesen und programmieren.

Aber jetzt andere Problem. Wie kann ich die SerialNet Software zum
Laufen bekommen?
Was ich gemacht habe ist folgendes:
1. Reset Line auf Logic 1. also 3.2 Volts
2. den Modul mit Microcontroller über UART_TXT UART_RXD UART_CTS
UART_RTS Linien verbunden.
3. CTS ist als eingang bei dem uC.
4. RTS ist auf 0.
5. über RXD sende ich (mit der Hilfe uC, natürlich) ein "AT" Kommando
mit 0x0D am ende ("AT\n").
6. TXD bleibt auf 0.
(TXD RXD von der Seite des Modules gesehen, also pins 13 und 14
entsprechen).

Muss ich irgendwelche Bedingungen auchalten um die Kommunikation
zwieschen der Software SerialNet und meine uC zum laufen zu bekommen?

Ah ja. den Bootloader ist jetzt gelöscht.
Ich habe den HEX Datei von der Evaluation Software SerialNet genommen,
die mit Bitcloud ZDK 1.4.1 runtergeladen habe.

Hat jemand schon die Evaliation Software ausprobiert? Oder muss ich was
eigenes schreiben?

Danke in Voraus!

sagt mal, weiß jemand warum die homepage von meshnetics down ist?!

darum (Atmel übernimmt alle Rechte an MeshNetics ZigBee):
http://www.elektroniknet.de/home/kommunikation/new...

ok, aber wenn du dir das datum anschaust, dieser artikel ist vom feb. 09
- ganz schön alt.

Matze Niemand schrieb:
> ok, aber wenn du dir das datum anschaust, dieser artikel ist vom feb. 09
> - ganz schön alt.

Ja, und?  Meinst du, Atmel hätte das nun alles gleich wieder
verscherbelt deshalb?

Sie haben den Zigbit-Teil von Meshnetics gekauft und vermarkten und
supporten das weiter.  Meshnetics hat ja noch mehr gemacht, aber
der Rest scheint wohl bei der Firmenpleite den Bach runter gegangen
zu sein.

Dieser NYT-Artikel vom November 2008 scheint ja so ziemlich das
einzige zu sein, was dazu mal irgendwo noch veröffentlicht worden
war, wenn man von Atmels Übernahmeerklärung absieht:

http://www.nytimes.com/2008/11/17/world/europe/17russia.html

mir ist nicht ganz klar, was du eigentlich vor hast... naja, aber
erstmal, ich arbeite selber mit diesen zigbee teilen, zwar mit dem
ZDM-A1281-A2 (bzw deren derivaten) und nicht mit dem raven, aber in der
software müssste es da keine großen unterschiede geben.
allerdings, laß dir gesagt sein, diese teile sind ätzend:
- mal fallen sie aus, beim nächsten mal anschalten (nachdem der strom
weg war) gehen sie dann wieder
- mal muss man sie manchmal erst richtig "treten" bis sie die richtige
kennung im netz annehmen
- ... schön sind die nicht
aber es funktioniert und momentan gibts, nach meiner bescheidenen
meinung, nichts besseres... :)

was dir noch fehlt ist natürlich eine antenne :)
ansonsten kann es noch sein, das tx und rx an pin 13 und 14 am UART
vertauscht sind, was beim ersten anwerfen des bootloaders zu
verwirrungen führen kann :)
das AT25010A ist, laut google-ist-dein-freund.de ein eeprom mit SPI
anschluss:
http://www.atmel.com/dyn/products/product_card.asp...

Christian B. schrieb:

> Auf dieser Vorlage änderte ich die Pins zwischen AT86RF212 und
> ATmega1281.
> AT86RF212     RCB212        ATmega1281
> RST           PB5     -->   PA7
> IRQ           INT0    -->   INT5

Das könntest du nochmal in Axels µracoli verifizieren, denn er
unterstützt ja sowohl die RCBs als auch die Meshbeans.

Meiner Meinung nach arbeiten die Zigbits mit externem Takt, der
von CLKM des Transceivers geliefert wird, während die RCBs mit
internem RC-Oszillator arbeiten und CLKM zum Pin T1 routen, damit
man damit den Timer/Counter 1 betreiben kann.

> Mir ist irgentwie noch nicht klar, welche Hardware überhaupt auf den
> ATZB-900-B0 Modulen vorhanden ist. Beim RCB212 gibt es z.B. noch das
> AT25010A, das in der Datei "pal_board.c" ausgelesen wird.

Das ist eine Besonderheit der Boards von Dresden Elektronik, da
werden die statischen Daten für das Board abgelegt (beginnend von
der MAC-Adresse).  AVR Studio hat so eine hässliche Neigung, den
EEPROM des AVRs immer wieder ungefragt zu löschen, sodass man die
Lösung mit dem externen EEPROM bevorzugt hat.

Da dein Zigbit das nicht hat, musst du dort die MAC-Adresse im
internen EEPROM hinterlegen (falls sich nicht sogar schon da ist,
kannst ja mal reingucken).  Irgendwo im pal_board.h gibt's ein
#define das festlegt, ob ein externer AT25010A benutzt wird oder
nicht.

> Kann ich den im Wiki verlinkten Raven Board Schaltplan als Vorlage
> verwenden?

Nein, der Raven ist komplett anders gestrickt.

Christian B. schrieb:

> Wofür wird der DIG2 verwendet, bzw wird er überhaupt verwendet?

Der ist dafür gedacht, dass man über ein `input capture' von der
Timer-Hardware einen Zeitstempel bekommen kann für jeden empfangenen
Frame.  Wenn DIG2 passend programmiert wird, dann gibt er einen
positiven Impuls aus während der Zeit, in der ein Rahmen empfangen
wird.

Dieses Feature gibt's aber erst seit dem AT86RF231 und danach.  Keine
Ahnung, ob die 900-MHz-Zigbits das Pin zum Controller routen, die
alten mit dem AT86RF230 hatten dafür natürlich keine Chance.

>> Meiner Meinung nach arbeiten die Zigbits mit externem Takt, der
>> von CLKM des Transceivers geliefert wird

> Wenn ich die Fuses von den Modulen auslese, steht SUT_CKSEL auf
> Int. RC Oszillator. Dann arbeiten die Module doch auch mit dem
> Int. Oszillator, weil mit dem BitCloud Stack funktionieren sie,
> oder?

Gut, dann benutzen sie das doch nicht (mehr).  Hat möglicherweise nur
der erste Meshnetics-Zigbee-Stack so gearbeitet.  Laut der von dir
referenzierten Tabelle ist CLKM zumindest an XTAL1 des ATmega1281
geroutet.

> Mit welcher Frequenz wird T1 bei den ATZB-900-B0 Modulen getacktet?
> Richtet die sich nach dem Takt der CPU?

Da PD6 nicht beschaltet (bzw. nach außen geführt) ist, kann man den
Timer/Counter 1 dann nur sinnvoll mit einem Takt betreiben, den man
vom CPU-Takt ableitet.  Ist beim RC-Oszillator dann leider nicht so
genau, wobei man ihn zumindest regelmäßig vom 32-kHz-Timer
nachkalibrieren könnte.  Der Vorteil, CLKM an T1 zu routen (wie bei
den RCBs) ist halt, dass man einen quarzgenauen Takt für T/C1 hat,
allerdings nur während der Zeit, da der Quarzoszillator des
Transceivers läuft.

Ich kann leider nirgendwo erkennen, ob die ATZB-900-Module bereits mit
irgendeiner Firmware ausgestattet sind, d.h. sind sie sozusagen
jungfräulich und man muss erst den Stack noch draufbeamen, oder können
sie out of the Box via SPI oder UART in Gebrauch genommen werden, falls
man mit dem zufrieden ist, was evtl. bereits drauf ist?

Danke für einen kurzen Hinweis und viele Grüße
Klaus

Wenn du gar nichts findest, musst du mal Atmels Support befragen.  Ich
würde vermuten, dass die Teile mit einem Bootloader daher kommen, aber
ich hab' sie auch noch nicht selbst in den Fingern gehabt.

Christian B. schrieb:
> Wie könnte man den überprüfen, ob ein Bootloader auf den ATZB-900-B0
> Modulen drauf ist?

Ein JTAG ICE (oder einen AVR Dragon) benutzen und nachgucken?

> Die Module funktionieren nun mit dem IEEE 802.15.4 MAC Stack, aber
> leider nur im Non Beacon Enable Modus. Wenn im Makefile "BEACON_SUPPORT"
> definiert wird, verbinden sich Endknoten und Koordinator nicht mehr. Hat
> vielleicht jemand eine Idee wo der Fehler liegen könnte?

Ich würde mit einem Sniffer anfangen zu tracen.

Christian B. schrieb:
> Kann man
> den Mikrocontroller in einen Sleep Modus legen, wenn keine Kommunikation
> erwartet wird?

Könnte man sicherlich...

> Wie implementiert man das Aufwachen des Transceiver? Geschieht dies mit
> Hilfe von einem CPU-Takt abhängigen Timer?

Genau da liegt der Pferdefuß.  Der Timer wird (wenn ich mich recht
entsinne, hab gerade keine Lust nachzusehen) mit dem CPU-Takt
betrieben.  Bei den nicht-Zigbee-Boards kann er alternativ, solange
der Transceiver läuft, via CLKM vom 16-MHz-Quarz extern getaktet
werden.

Der MAC müsste wohl so erweitert werden, dass beim Schlafengehen
der nächste Timer, der in der Queue ansteht, vom CPU-Takt-abhängigen
Timer umgelegt wird auf einen Timer, der vom 32-kHz-Quarz betrieben
werden kann.  Nach dem Aufwachen muss man dann die verstrichene Zeit
in TCNT1 und dessen Überlaufzähler "nachtragen", damit die restlichen
eventuell gesetzten Timer wieder sinnvoll laufen.

Ist halt keine völlig triviale Änderung.  Falls einen das Glattziehen
der restlichen Timer nicht interessiert, genügt es eventuell als
"quick & dirty hack", den "Ein Beacon wird erwartet"-Timer durch
einen separaten Aufruf auf den Timer 2 (mit 32 kHz Taktung) zu schieben,
statt die generischen Systemtimer zu benutzen.

Nein, JTAG darfst du problemlos an lassen, aber OCDEN solltest du
unbedingt abschalten.  Sonst geht der Hauptoszillator nicht aus.

Christian B. schrieb:
> Kann es sein, dass die Fuse per Software
> gesetzt wird? (Z.B. wie bei der CKDIV8)

Die Controller-Firmware kann prinzipiell keine Fuses verändern,
das ist ja der Sinn der Teile.  Bei hinreichend neuen AVRs kann man
sie allerdings von der Firmware aus lesen.

> Wenn ich die OCDEN Fuse setze, ist sie nach dem Ausführen des Programms
> wieder abgeschaltet.

Nur, wenn du AVR Studio benutzt.  Das fummelt selbstständig an dieser
Fuse herum, und insofern ist sie natürlich durch Software (nämlich
durch AVR Studio) veränderbar. ;-)  Stromverbrauchsmessungen solltest
du ohne angeschlossenen Debugger und am besten auch ohne JTAG ICE
machen (das zieht nochmal ca. 200 µA aus der Target-Spannung, die für
den Betrieb der Pegelwandler benötigt werden).

8 mA ist ganz normaler Betriebsstromverbrauch des ATmega1281, da hast
du es noch nicht einmal geschafft, ihn in den idle sleep mode zu
bekommen.  Dort würde er (bei 8 MHz CPU-Takt) nur noch knapp 2 mA
benötigen.  Im powersave sollte er nur noch einige µA brauchen.  Wenn
du den BOD aktiviert hast, sind es leider (der ATmega1281 ist noch
kein Picopower-Typ) um die 20 µA.

Christian B. schrieb:
> Ich vermute, dass
> deine 200 µA mit angeschlossenem Netzteil gemessen wurden.

Sollte dem JTAG ICE eigentlich egal sein, woher es versorgt wird.
Möglicherweise irre ich mich bei meinen 200 µA auch, ist schon 'ne
Weile her, dass ich das zum letzten Mal gemessen habe.

Christian B. schrieb:
> Der Link Quality Indicator (LQI) soll laut 802.15.4 Standard eine
> Aussage über Stärke und / oder Qualität des empfangenen Pakets geben.
> Bereich :(0 bis 255)Gibt es einen Bezug zu der Empfangsleistung in dBm?

Der LQI-Wert und seine Skalierung ist eine rein interne Geschichte
im Stack (MAC/PHY).  Dort steckt typischerweise ein wenig knoff-hoff
der Stackentwickler drin, vor allem dann, wenn man darüber noch eine
Netzwerkschicht hat (ZigBee-NWK), denn diese benutzt typischerweise
die LQI-Werte für die Ermittlung einer optimalen Route.  Dafür wird
man in der Praxis nicht umhin kommen, den Korrelationswert des
Empfängers irgendwie mit der Signalstärke zu kombinieren, denn du
willst einerseits schlecht korrelierende Signale (die dann typisch
durch Mehrwegeempfang zustande kommen) möglichst nicht bevorzugen,
solange ggf. ein stabiler empfangbares Signal selbst mit geringerem
Pegel verfügbar ist, andererseits willst du aber natürlich auch ein
gut korrelierendes Signal kurz vor der "Erbrechensgrenze" erkennen
können.

> Ich würde gerne ein Paket über eine Strecke X mit der Sendeleistung Y
> übertragen und die vom Receiver Empfangsleistung messen. Ist dies mit
> dem LQI möglich?

Der LQI-Wert vom AT86RFxxx ist der Korrelationswert des Empfängers,
d. h. eine Signal_qualität_, nicht -stärke.

Dafür kannst du entweder eine Momentaufnahme mittels des RSSI-Wertes
benutzen (wird aller 1 µs aktualisiert, wenn ich mich recht erinnere)
oder du benutzt den ED-Wert.  Der wird entweder separat ermittelt
(ED-Messung) oder aber impliziert innerhalb der ersten 128 µs beim
Empfang eines jeden Rahmens.

Christian B. schrieb:

> Mit Controller-Firmware ist in meinem Fall das AVR Studio gemeint?

Nein.  Die Firmware ist das, was auf dem (Micro-)Controller selbst
läuft.  Die kann keine Fuses ändern.

> Bisher ging ich davon aus, dass Software generell keine Fuses verändern
> kann.

AVR Studio (oder AVRDUDE) ist halt auch nur "Software".

[CKDIV8]

> Demnach eine weitere Fuses die durch Software geändert und nicht nur
> ausgelesen werden kann.

Nein, CKDIV8 wird nicht durch die Firmware geändert.  Die einzige
Funktion von CKDIV8 aber ist es, den Reset-Wert des Registers CLKPR
von 0b0000 auf 0b0011 zu ändern und damit den Master-Takt durch 8
zu teilen.  Damit soll sichergestellt werden, dass der AVR unter
allen zulässigen Versorgungsspannungen einen Takt bekommt, mit dem
er auch arbeiten kann.  Die Applikation kann aber stets und immer
daher kommen und CLKPR neu schreiben; in dem Moment ist sie selbst
dafür verantwortlich, dass der Prozessor nicht übertaktet wird.

Unabhängig davon, was die Applikation mit CLKPR anstellt: der Wert
der Fuse CKDIV8 bleibt davon unbeeinflusst.  Den kann man nur mit
einem Programmiergerät von außen ändern.

>EU1, EU2, Wo liegen die Unterschiede (Region)?

Region nicht, im Datenblatt S. 109 ist erklaert, dass EU2 den Boostmode
verwendet und damit 1dB mehr Ausgangsleistung  erreicht und etwas mehr
Strom braucht .

>dass an Stelle des duty cycle ein LBT durchgeführt werden kann.

siehe S.88., Kap. 6.7, mit LBT kann die Dutycycle-Regelung umgangen
werden.

>PIB Attribute phyCCAMode  Mode 3 zuweise?
mode 3: Kanal ist frei, wenn Energy unter Schwelle "UND" kein Carrier,
ich denke das ist Ok. Lt. Datenblatt (6.7.1) soll die ED Schwelle bei
-82dBm
liegen, d.h. mit CCA_ED_THRESH = 7 (Resetwert) misst du bei je nach
Modulation bei -82 und -85 dBm, d.h. das sollte Ok sein.


SW-technisch ist beim LBT Mode zu beachten, dass,
wenn der Kanal vollstaendig belegt ist (Jammer), der LBT Mode nie mit
einem IRQ endet , d.h. die Controller SW sollte intern ein TMO mitlaufen
lassen, das. ggf. den LBT Versuch abbricht.

Christian B. schrieb:
> Befinde ich mich innerhalb der vorgegebenen Richtlinien, wenn ich dem
> PIB Attribute phyCCAMode  Mode 3 zuweise?

LBT ist das nicht, nein.  Lies dir einfach die Bedingungen für LBT
in der ETSI EN 300 220-1 durch.  Ist zu viel, als dass man das auf
drei Zeilen wiedergeben könnte.  Allein die Messzeit unterscheidet
sich drastisch von CCA gemäß IEEE 802.15.4.

Christian B. schrieb:
> Wenn der IEEE 802.15.4 MAC kein LBT nach ETSI Richtlinien implementiert
> haben sollte und man selber einen LBT Algorithmus schreibt bzw. die
> Funkanwendung so auslegt, dass der Duty Cycle von 1% erfüllt ist, muss
> diese Anwendung dann noch zusätzlich von der ETSI oder Bundesnetzagentur
> abgenommen werden?

ETSI oder BNetzA wirst du lange danach fragen, dir etwas abzunehmen. ;-)
Das eine ist ein Normungsgremium, das andere eine Überwachungsbehörde.
Aus dem täglichen Kommerzgeschäft sind die beide raus.

Du (*) musst eine Konformitätserklärung liefern, und du musst
dafür einstehen, dass sie korrekt ist.  Dazu musst du wissen,
welche Regelungen alle auf dich zutreffen.  Dementsprechend bist
du auch selbst verantwortlich, die Regelungen bezüglich duty cycle
und/oder LBT einzuhalten.  Irgendwelche Messlabors werden dir in
dieser Hinsicht ohnehin kaum einen Persilschein geben, sondern die
kümmern sich in aller Regel um die reinen HF-Eigenschaften.

(*) Mal in der Annahme, dass du der sogenannte "Inverkehrbringer"
bist.

Christian B. schrieb:
> Gilt das auch für den Verbindungsaufbau?

Diesen Begriff kennen die Regulierungsvorschriften nicht.

Ergo: es gilt für jeden einzelnen Sender.  Seine Funktion ist dabei
völlig egal.  Allerdings muss die Belegung nur über einen Zeitraum
von einer Stunde gemittelt werden, d. h. innerhalb dieser Stunde
darfst du maximal 36 s lang HF emittieren, oder aber du musst LBT
benutzen (im Rahmen der dafür zutreffenden Bedingungen).

Ja, der letzte Beitrag ist schon alt, aber meine Antwort ist evtl. doch
für einige interessant:

Ich habe es geschafft ein ZigBit ATZB-24-A2 per ISP zu programmieren.
Das ganze aus der Not heraus geboren, da mir aus irgend einem Grunde die
JTAG-Schnittstelle eines Moduls über Nacht abgeraucht ist ;-((

Folgender Aufbau:
AVROne!
ZigBit ATZB-24-A2
ISP-Frq: 100 kHz

SPI         ZigBit
-------------------------------
SCK    -->  SPI_CLK   (Pin 1)
MISO   -->  UART0_RXD (Pin 38)
MOSI   -->  UART0_TXD (Pin 39)
nRESET -->  RESET
VCC    -->  D_VCC
GND    -->  DGND

Damit konnte ich Fuses lesen/schreiben und das Teil neu programmieren.
Mehr als 200 kHz ISP hat nicht mehr zuverlässig geklappt.
Warum das Modul nicht mehr per JTAG kommuniziert, ist eine ganz andere
Frage. Ich habe es bestimmt 30 mal neu programmiert und bin dann nach
Hause gefahren. Am nächsten Morgen wollte der JTAG nicht mehr, obwohl
der MC einwandfrei lief. Zuerst dachte ich schon, es haben sich die
Fuses verstellt, aber die waren einwandfrei und wurden auch nie neu
geschrieben.
Wer dazu eine Idee hat - immer her damit. Die anderen Module
funktionieren nach wie vor einwandfrei am JTAG.

Viele Grüße,

Oliver