hallo! gibt es hier noch ein paar leute die mit dem zigbee modulen von meshnetics arbeiten? weclhe erfahrungen habt ihr mit denen gemacht?
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
hi thomas, hast du eigentlich das dev. bzw. eval kit gekauft oder nur module? gruß alex
> 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_Product_Datasheet.pdf 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
musst mal schaun, ich hab version april 2007, das auf der homepage ist oktober 2007 ;). da will wohl meshnetics dass wir in zukunft weniger über ihre (mich oft ärgernde) module wissen! ich hab das datenblatt mitte september runter geladen. hab leider auch kein dev kit was oft eine hilfe wäre. sollen wir mal hier unsere programme offen legen? hast du den bootloader? ohne ihn kommt man nicht sehr weit bzw. nur mit isp/jtag.
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 Alexander, kannst du mir die PingPong Application mal zukommen lassen, ich komme momentan mit den Modulen auch nicht richtig weiter, vielleicht würde das ja helfen. Danke.
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
Hi. Ich hab bei 3 ZigBit Modulen (ZDM-A1281-A2) versucht, per SPI und USBprog (mit 5V -> 3.3V levelshifter) die Signatur zu lesen.. aber keins funktioniert.. alle zeigen nur FF FF FF, was bei meinen anderen Atmels meistens Finito bedeutet :( Ich hab sie aber wie rohe Eier behandelt (waren nigelnagelneu von Farnell) und war auch beim Löten ganz vorsichtig?! Der USBprog liest zuverlässig: ATmega168, ATtiny13, ATtiny26 und ATtiny2313.. Levelshifter funktioniert hier auch problemlos (hier hab ich tlw. direkt an den Beinen gelötet..) 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. Die SPI hab ich wie im Datenblatt angegeben angeschlossen: Pin 1: SCK Pin 2: MISO Pin 3: MOSI Pin 8: RESET Pin 23: GND Pin 25: VCC Langsam gehen mir die Ideen aus, was falsch sein könnte.. Muss man die Teile irgendwie speziell ansprechen? Im Datenblatt steht nix davon.. Grüsse und Danke für jede Hilfe Joan
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.
J. Wunsch wrote: >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. Also sind die Module schon mit einer Programmierung ausgestattet? Ich bin bisher davon ausgegangen, dass ich den ATmega1281 im inneren direkt via SPI ansprechen kann.. und dass ich dann das eZeeNet und den ganzen anderen 802.15.4/ZigBee-API-HAL-Krams via Bibliothek in mein Programm in AVRStudio einbinde.. ist dem nicht so? Wie ist da vorzugehen? Steht das nur in der Doku der Eval-Kits? Als ich grad nochmal gestöbert hab, bin ich in Meshnetics pdf (http://www.meshnetics.de/dl.php?id=17) zur 'ezeenet soft api reference' auf S.76 auf die Sache mit JTAG gestoßen: "To use the internal RC-oscillator, fuse bits should be set as follows (see table below). Check ON the following options in Fuses Tab before downloading the images through JTAG".. Dh. ich werde als nächstes mein AVRICE mk2 nehmen und via den JTAG pins mal probieren ob ich was erreiche.. Danke schonmal für die bisherige Hilfe Jörg. Falls euch noch was einfällt, ich bin ganz Ohr :) Grüsse Joan
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.
JTAG funktioniert.. hab die Signatur auslesen können, dh. meine Module sind noch ganz *puh, 90€ nicht im Eimer* Dann werd ich mal versuchen weiter nach Anleitung ^^ (das pdf von weiter oben) die ISP via Fuses freizuschalten. Danke für die Tipps. 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.. Grüsse Joan
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: > Ich hab sie aber wie rohe Eier behandelt (waren nigelnagelneu von > Farnell) Für mich waren aber die Preisen von Farnell viel zu hoch. Digi-Key verkauft viel billiger, und hat ziemlich schnell geliefert. http://dkc1.digikey.com/de/digihome.html. Direkt von MeschNetics ist natürlich noch billiger. > 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.. Soll kein Problem sein, ich hab' so eine direkt von MeshNetics Support bekommen ;). Kann später mit deine vergleichen :) Gruß
J. Wunsch wrote: >Wofür brauchst du das ISP denn? "Dumm gelaufen" wär die richtige Antwort ;) Ich hab bisher alle Atmels so angesprochen und mich blind drauf verlassen, dass das geht.. dh, die Boards wo die Funktmodule drauf kommen haben die SPI als Programmierschnittstelle jetzt drauf und nicht JTAG. JTAG hatte ich keine Erfahrung mit - war für mich bisher nur die 'Debug-Schnittstelle'.. das man darüber auch programmieren kann wusst ich nicht. Aber so langsam fallen die Groschen. J. Wunsch wrote: >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? Hm.. hab mal weiter geklingelt und die SPI-Verknüpfelung des RF230 mit dem ATmega1281 angeschaut: (Datenblatt RF230 Seite 10 - http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf) ATmega1281.Pin10(SS) -----> SEL ----> RF230.Pin23(SEL) ATmega1281.Pin44(PA7) ----> RST ----> RF230.Pin08(RST) ATmega1281.Pin20(RESET) --> RESET --> ZDM-A1281-A2.Pin08(RESET) ..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). Holger wrote: >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. Hm.. Punkt für dich. Das hab ich komplett übersehen :( Insofern kann ich mir nur selbst Asche aufs Haupt streuen.. Allerdings hab ich das offizielle Datenblatt nicht so ernst genommen, da die UART-TXD/RXD Pins (13/14) in allen Zeichnungen und Tabellen vertauscht sind.. in genannter Tabelle stimmen nur die I/O und Description Spalten.. Dazu stimmt das Pad-Layout nicht ganz und die beiden Antenna Patterns für die PCB-Antenne widersprechen sich auch in ihrer Skalierung. (Meshnetics hab ich das alles schon gemeldet) Thomas wrote: >Für mich waren aber die Preisen von Farnell viel zu hoch. Digi-Key >verkauft viel billiger, und hat ziemlich schnell geliefert. >http://dkc1.digikey.com/de/digihome.html. Direkt von MeschNetics ist >natürlich noch billiger. Hatte noch was anderes dort.. mir gings nur darum dass nicht alle meine Module 'hops' sind ;) Aber danke für den Tip, werds mir merken. Ok, wegen dem PinOut.. ich fügs dann am WE ein.. kann ich auch gleich noch die SPI-Verknüpfelung fertig dokumentieren. Danke und Grüsse Joan
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.
So, ich weiß jetzt wieder wie ich drauf gekommen bin, dass es funzen müsste.. http://www.atmel.com/dyn/resources/prod_documents/S-RZ200SDK.pdf Seite 15, 4.2 Programming the Boards: "All the boards can be programmed under AVR Studio using the supplied In-System Programmer, AVRISP mkII, from Atmel [7]".. Im Nachhinein natürlich Blödsinn, weil die nicht die ZigBit Module auf den Boards haben, aber Hinweis genug für mich. Nun ziehe ich aber den Joker, die RZRaven Boards von Atmel selber. http://www.atmel.com/dyn/resources/prod_documents/doc8117.pdf Schaut man im Hardware User Guide für die LCD-Module nach, kommt man im Schaltplan auf Seite 12 im Bereich A-1 (Ränder der Zeichnung beachten) auf eine ISP-Buchse, die genau so verschaltet ist, wie ich die für das ZDM-A1281-A2 Modul weiter oben angegeben hab. Damit hätte ich also meinen Präzedensfall.. Hat jemand so ein RZRaven Set in der Evaluierung? Auf der Embedded hatten die ja welche für rund 99€ oder wars noch mehr?.. Mal sehen ob ich so eins bekommen kann.. Grüsse Joan
Ich hab mir jetzt mal das Timing/die Pegel während einem "Read Signature" beim Atmega168 und dann beim ZigBit Modul angeschaut.. für alle 4 Leitungen (MOSI, MISO, SCK und RESET). Beim 168'er läuft alles am Schnürchen. Beim ZigBit Modul von Programmer-Seite aus auch, dh. der RF230 innnen drin, hält die Leitungen jetzt nicht so dolle fest, dass da gar nix mehr geht, die Pegel sind einwandfrei.. also MOSI, SCK und RESET sind ok, aber MISO kommt nix, das ist immer high. Laut Datenblatt hält der RF230 SCK und MOSI low, MISO steht nix drin (http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf - Seite 7, Tabelle 4-4) - ich vermute daher tristate. Laut Datenblatt vom ATmega1281 hört dessen SPI-Schnittstelle im Falle SPI = Slave Modus und SS-Pin von AUSSEN high nicht zu - würde ja zu meinem Ergebniss passen (http://www.atmel.com/dyn/resources/prod_documents/doc2549.pdf - Seite 201, 21.1.1 Slave Mode: "When SS is driven high, all pins are inputs, and the SPI is passive, which means that it will not receive incoming data.". ABER! Gilt das auch für ISP? Im 1281-Datenblatt unter 'Serial Downloading' zu finden.. (Seite 351, 30.8 Serial Downloading). Dort ist nämlich nur von RESET, MISO, MOSI und SCK die Rede.. vom SS-Pin steht da kein Wort. Ich glaube also nicht, dass der SS-Pin für das ISP ne Rolle spielt.. wär auch Mist, wenns so wär. Jemand ne Idee? Grüsse Joan
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.
>Ist das /RESET denn auch wirklich zum ATmega1281 geroutet? ZigBit Pin 8 /RESET <----> ATmega1281 Pin 20 /RESET ..direkt verbunden (1,8 Ohm) >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. Hab den /RESET vom Mega1281 mal auf GND gelegt und den /RST und /SEL Pin am RF230 gemessen.. beide high. Wie's im RF230 Datenblatt steht, muss dann auch /MISO high sein (wie es auch ist) mit Pull-Up intern.. aber das sollte der Mega1281 doch ziehen können um sich der Außenwelt mitzuteilen?! >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. Ok. Wenn man ihn so 'blind' programmieren könnte wärs ja auch noch ne Überlegung wert.. mal morgen nen kleines Testprog machen. Testweise /MISO zwischen Mega1281 und RF230 auftrennen muss ich mal mit Mikroskop schauen.. mit dieser 3-fach Brille hier wird das garantiert nix. Mal 2 Bilder von dem offenen Modul: http://img187.imageshack.us/my.php?image=zdma1281a22ya3.gif http://img156.imageshack.us/my.php?image=zdma1281a21si8.gif Grüsse und schönen Sonntag Joan
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
Hallo, Bei mir sind Alle Versuche mit ISP gescheitert, aber mit der Hilfe des Bootloaders sollte sich trotzdem noch die Firmware aktualisieren lassen. Ist dann halt etwas unbequemer als mit JTAG. gruss Olli
Hallo, ich versuche immer noch, die Ping-Pong Anwendung zwischen zwei Modems zum Laufen zu bringen, aber das klappt irgendwie nicht. Kann hier jemand bitte mal seine Makefile-Einstellungen posten und eine kleine Schritt-für-Schritt Anleitung für den Test wäre natürlich auch prima. gruss Olli
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.
Könntet ihr kurz schreiben wo ihr die module bezogen habt ? Hab mir heute mal den meshnetics-shop angesehen, da sind Versandkosten von 49.99 Euro aufgeführt ?? Versenden die aus Deutschland oder kommen da noch Zollgebühren dazu ? Was für alternative Bezugsquellen kommen für einen Privatkunden noch in Frage ? Vielen Dank Michael
Da ist doch so ein Thread mit einer DigiKey-Sammelbestellung. Ohne jetzt Werbung dafür machen zu wollen (muss jeder selbst wissen ob er da mitmachen will), ist das zumindest eine Gelegenheit die relativ billig von DigiKey zu kriegen.
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
Hallo, ich habe meine beiden Module hier gekauft: http://www.dataspherewireless.de/manufacturers/meshnetics/meshnetics_zigbee_modules.htm Gruss, Christian
Christian C. wrote: > > ich habe meine beiden Module hier gekauft: > http://www.dataspherewireless.de/manufacturers/meshnetics/meshnetics_zigbee_modules.htm > 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
Pro Modul 18,59EUR (o. MwSt) Versandkosten 11,90EUR Gesamt für zwei Module: 58,41EUR (inkl. MwSt)
Hallo! wir haben auch so unsere Probleme mit der PingPong Application, es scheint kein Netz zustande zu kommen, blinken alle die ganze zeit nur grün... jemand eine Idee, ob man im Quellcode manuell Änderungen vornehmen kann, damit man sicher eine Verbindung herstellen kann? jemand mit ähnlichen problemen eine lösung gefunden? weitere frage: hat jmd. den quellcode von der ZBNDemo den er mir schicken könnte? da wir die Geräte für ein Projekt im Studium nutzen ist das sicher sehr sinnvoll. Meshnetics antwortet auf Emails leider nicht oder erst sehr spät... danke im voraus
liegt das mit der pingpong-application vielleicht an einer falschen einstellung der knoten zu controller/router/enddevice? wenn ich mir den Code so ansehe scheint ein enddevice nicht möglich zu sein, sondern nur controller/router auswählbar. oder stellt man alle auf 0? blick da nicht so durch :)
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.
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
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
hallo hat jemand zufällig die Peer-to-peer Data Exchange Application? Kann die nämlich leider nicht finden, obwohl im eZeeNet API Reference Manual steht, dass es dabei sein müsste. Wäre sehr dankbar dafür!
Guten Tag! Hat ZDM-A1281-A2 mit der Version 1.6.2.0 gekauft. Aber sie arbeitet korrekt (nicht verliert die Angaben bei der Sendung). Versuchte das letzte Durchnähen von der Web-Seite, aber sie arbeitet nicht. Ob jemand mir auf e-mail micro51@rambler.ru das Arbeitsdurchnähen für SerialNet.hex absenden kann.
hallo! weiss jemand die maximale anzahl an sendewiederholungen des AT86RF230 die möglich sind? dafür ist ja das register 0x2C zuständig,genauer die bits 4,5,6,7 (MAX_FRAME_RETRIES).damit müssten es doch maximal 15 sendewiederholungen sein,oder? und die maximale Anzahl an CSMA-Zugriffsversuchen ist 7? danke für antworten
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
hallo! ich hab auch mal eine frage zu den modulen. mein vorhaben ist es,wenn sich die batterieenergie eines ZDM-A1281-B0 (was dazu dient sensordaten zu übermitteln) dem ende entgegen neigt,dass dies einem benachbarten modul über eine gemeinsame verbindung (also nicht per funk) mitgeteilt wird. damit soll dieses zweite modul aus dem stromsparenden modus aufgeweckt werden und selbst anfangen daten aufzunehmen und zu senden. ich hab mir das so gedacht: der analog-comparator des aktiven moduls vergleicht ständig die spannung.sinkt diese kurz vor eine kritischen wert,wird z.B. ein portpin das als ausgang definiert ist auf 0 gesetzt. ->dem anderen (sich im stromsparenden modus befindliche) modul wird dies per externem interrupt (die beiden module sind über ein pin verbunden) mitgeteilt und es somit aufweckt. dürfte das gehen oder ist es sinnvoller die kommunikation der beiden Atmega1281 über UART oder sonstiges zu erledigen? danke für antworten...
Hallo Rolf, auf den Meshnetics Modulen sind AT86RF230 radios verbaut. Diese (und die anderen Atmel-Radios auch) haben intern einen Batterie Monitor. Per Register write kann man die Schwelle einstellen (1.7 ... 3.65V), ab der der Batteriemonitor Interrupt anschlägt. Am besten du suchst im Datenblatt des AT86RF230 nach BATMON. Wichtig ist noch zu wissen, dass der Interrupt des Batteriemonitors nach dem ersten auftreten abgeschaltet werden sollte, da er "gehäuft" auftritt, wenn die Spannung durch schwankenden Stromverbrauch des Moduls an der eingestellten Schwelle herumwackelt. Alternativ zum Interrupt kannst du auch das BATMON_OK Signal im Register 0x11 beobachten. Es ist allerdings ein Signal, d.h. wenn die Spannung beim Senden oder Empfangen kurz einbricht, bekommst du das in dem Register evtl. nicht mit. Also am besten, den ersten Interrupt abwarten und danach BATMON_OK ueberwachen. Gruss, Axel
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.
vielen dank für die schnelle antwort axel! und um das auf meine überlegung weiterzuführen: die ISR würde ich dann so konfigurieren,dass sie z.b. ein portpin setzt, was einen externen interrupt am anderen atmega1281 auslöst und ihn damit aktiviert? gruß,holger
ähh ich mein nätürlich rolf.keine ahnung wie ich grad auf den anderen name kam!? :)
Jörg Wunsch 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? >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. naja,über periodisches aufwachen: da müsste ich ja den ADC an die batterie des anderen moduls hängen um zu prüfen?! >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. also ich will den controller nur aufwecken.ihn selbst kann man dann so programmieren,dass er den transceiver und den sensor selbst aktiviert. gruß,rolf
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.
@ Jörg Wunsch: ich hab die seite gefunden.scheinbar hast du eine etwas ältere version...aber am stromverbrauch hat sich nicht geändert ;-) das mit dem periodischen aufwachen hab ich vorhin falsch verstanden,aber jetz weiss ich was du meinst. :) nur mal ne dumme frage nebenbei: welche schnittstelle ist zum programmieren mit dem avr-studio in C am geeignetsten?JTAG oder? ich bräuchte bei meiner anwendung den i²C zum sensordaten lesen und den SPI für die kommunikation mit dem transceiver. danke,rolf
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.
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. So gesehen bleibt mir nur der Vergleich mittels periodischem Aufwachen des ADC übrig um die Spannung zu überprüfen. 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)!
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! Ich hab die Meshbean Development Boards von Meshnetics und möchte aufgenommene Sensordaten vom End Device zum Coordinator übertragen. Die Daten sollen aber auf jedenfall über einen Router vom End Device zum Coordinator gelangen (also quasi eine Baumtopologie). Meine Frage ist nun,was ich da alles am Router programmieren muss? Reicht es etwa,das ich das Modul (z.B. über die DIP-Switches) als Router definiere?Oder müsste ich mit Hilfe der API´s Einstellungen z.B. in der Netzwerkschicht vornehmen?? Zwar ist in der WSN-Demo der Fall der Baumstruktur drin,aber mich verwirrt es halt ein wenig, wenn ich mir das Netzwerk mit dem WSN-Monitor anschaue und dort manchmal ein "Linie" vom End Device zum Router geht und manchmal direkt zum Coordinator!?In diesen beiden Fällen ändert sich dann automatisch auch die "Parent-Adresse" des End Device.Einmal halt 0x0000 (für Coordinator) und sonst gegebenenfalls eine Adresse für den Router. Kann mir da jemand weiterhelfen?Wäre nett. MfG,Sven
Hat jemand hier im Forum schonmal mit den Meshbean-Boards Sensorwerte über I²C eingelesen bzw. allgemein mit der Schnittstelle auf dem Modul gearbeitet? Also ich meine damit nicht die üblichen Beispielfunktionen mit dem Temperatur- bzw. Lichtsensor. Gerhard
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.
Hi! Anybody english-speaking coud help with meshbean2 board and zigbit modules?
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.
May be someone have correnspondense between pinout m1281 and zigbit modules in meshbean2 boards? Can one coordinator host 60 end-devices at the same time? may be someone have programing zigbit modules w/o zigbit net stack? thank
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
Hallo zusammen, habe gerade einen der meinen zwei ZigBit Modulen ans Himmel geschickt. Mit der ISP habe die Fuse bits geändert im PonyProg, seitdem findet PonyProg den Kontroller nicht mehr. Warum habe ich so getan? Weil ich nicht die Software SerialNet zum laufen bekommen konnte - ich hatte keine Reaktion an UART TXD RXD pins des Modules. ÜBERHAUPT. Sogar wenn ich mein Hostkontroller ins Reset setze, wird TXD Linie nicht mal auf 1 gehen, sondern bleibt auf 0 sitzen. Und jetzt ist die Frage - weisst jemand, wie man den Modul zum Leben wieder bringen kann? Und wie muss ich die UART Einstellungen setzen, um über UART Snitstelle mit den ganzem Modul zu sprechen.
Was aber interessant ist, auf dem Pin CPU_CLK ist ein Clock signa vom 1 MHz zu sehen.
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.
Hallo Axel, Danke für schnelle Antwort! Hier ist das Bild von PonyProg Fuse Dialog: http://masteralexei.homelinux.net/images/Fuse1281.jpg Wie man sieht, JTAGEN is auf 0 - also programmiert. Ich habe bei mir einen JTAG-ICE der ersten Generation noch. Kann ich mit dem was machen? Mit welchem tool ist es möglich? Danke in voraus, Es wäre super, falls das Modul geretet wird.
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.
Jörg Wunsch! Super! Danke! Also - fuse bits kann ich rauslesen mit dem avrdude 5.4 für Win32 und es scheint, dass die richtig rausgelesen werden. Jetzt wäre es die Mögligkei die reinzuschreiben, wollte aber erst fragen, welche Fusebits habt ihr in Ihren Modulen, damit ich den chip nicht komplett ins Nirvana schiecke. Am besten die Werte, wie die beim avrdude angenommen werden. Danke!!!
Welche Werte liest du denn aus ? Man koennte mit einer Interpretation des aktuellen Zustandes anfangen, damit man hinterher nicht ganz conFUSEd ist ;-)
das wurde rausgelesen E fuse - 0xFF H fuse - 0x88 L fuse - 0xEF Also - genau dass, was auf dem Bild von PonyProg Dialog.
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!
darum (Atmel übernimmt alle Rechte an MeshNetics ZigBee): http://www.elektroniknet.de/home/kommunikation/news/n/d/atmel-uebernimmt-alle-rechte-an-meshnetics-zigbee-1/
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
Hallo zusammen, ich wechsel mal den Thread, weil meine Frage hier besser hinein passt. Ich möchte gerne den IEEE 802.15.5 MAC-Stack auf die ATZB-900-B0 Module anpassen. Dazu bekam ich von Atmel die Info, das RCB212 als Vorlage zu nehmen. ( Beitrag "802.15.4 / ZigBee" am 11.01.2010). Bei dem RCB212 orientiere ich mich an diesem Schaltplan: http://www.dresden-elektronik.de/shop/media/products/0385317001215694416.pdf Leider konnte ich für die ATZB-900-B0 Module keinen Schaltplan finden, so dass ich mich an diesem Wiki http://www.mikrocontroller.net/articles/Meshnetics_Zigbee orientiere. Auf dieser Vorlage änderte ich die Pins zwischen AT86RF212 und ATmega1281. AT86RF212 RCB212 ATmega1281 RST PB5 --> PA7 IRQ INT0 --> INT5 Was muss noch alles angepasst werden? 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. Kann ich den im Wiki verlinkten Raven Board Schaltplan als Vorlage verwenden?
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?part_id=3033
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.
Matze Apa schrieb: > mir ist nicht ganz klar, was du eigentlich vor hast Habe eine Platine mit ATZB-900-B0 Modulen, Antenne und Steckerleisten erstellt. Daten können unter Verwendung des BitCloud Stacks übertragen und empfangen werden. Soweit funktionieren die Module, aber ich möchte den IEEE 802.15.4 MAC Stack verwenden. Dafür ist allerdings noch eine Anpassung des 802.15.4 MAC Stacks an die Module notwendig. Das RCB212 ist bereits angepasst und verwendet unter anderem AT86RF212 und ATmega1281. Ich möchte das RCB212 als Vorlage nehmen und so umschreiben, dass ich meine Module verwenden kann. Mich irritiert der DIG2 vom AT86RF212 (siehe http://www.atmel.com/dyn/resources/prod_documents/doc8168.pdf Seite 14) Der im Wiki beschriebene AT86RF230 hat den nämlich nicht. Wofür wird der DIG2 verwendet, bzw wird er überhaupt verwendet? @ Jörg Jörg Wunsch schrieb: > Irgendwo im pal_board.h gibt's ein > #define das festlegt, ob ein externer AT25010A benutzt wird oder > nicht. Danke, die Definition stand im Makefile Jörg Wunsch schrieb: > 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? Mit welcher Frequenz wird T1 bei den ATZB-900-B0 Modulen getacktet? Richtet die sich nach dem Takt der CPU?
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.
Wie könnte man den überprüfen, ob ein Bootloader auf den ATZB-900-B0 Modulen drauf ist? 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?
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.
Nun ich glaube, das ich beim Bootloader nicht helfen kann. Habe mit den Fuses experimentiert und den Speicher vieleicht überschrieben.
Jörg Wunsch 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. Der DIG2 wird nicht verwendet. Habe einen Schaltplan bekommen. Im Beacon Modus schaltet der Endknoten den Transceiver an, wenn der Beacon erwartet wird. Beim IEEE 802.15.4 MAC Stack ist zwischen den Beacons der Transceiver aus, aber der Mikrocontroller aktiv. Kann man den Mikrocontroller in einen Sleep Modus legen, wenn keine Kommunikation erwartet wird? Wie implementiert man das Aufwachen des Transceiver? Geschieht dies mit Hilfe von einem CPU-Takt abhängigen Timer?
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.
Habe mal getestet, ob ich im IEEE 802.15.4 MAC Stack den ATmega1281 in den Power Down Modus legen kann. Doch nachdem der Power Down Modus aktiviert sein soll, benötigt mein Modul immer noch 8 mA. In diesem Wiki http://www.mikrocontroller.net/articles/Sleep_Mode fand ich den Hinweis, dass die JTAG Schnittstelle deaktiviert werden soll. Das bedeutet doch, dass ich über ISP programmieren muss. Aber mit ISP gibt es ja anscheinend, wie in diesem Thread beschrieben Probleme. Wie bekommt man den ATmega1281 in den Power Down Modus?
Nein, JTAG darfst du problemlos an lassen, aber OCDEN solltest du unbedingt abschalten. Sonst geht der Hauptoszillator nicht aus.
Fuse OCDEN ist abgeschaltet. Kann es sein, dass die Fuse per Software gesetzt wird? (Z.B. wie bei der CKDIV8) Wenn ich die OCDEN Fuse setze, ist sie nach dem Ausführen des Programms wieder abgeschaltet.
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.
Danke für den Hinweis. Das JTAGICE zog sogar fast 4 mA. Das Netzteil war nicht eingesteckt und die Spannungsversorgung des JTAGICE kam über USB. Ich vermute, dass deine 200 µA mit angeschlossenem Netzteil gemessen wurden. Außerdem hatte ich noch einen Widerstand auf meiner Platine übersehen.
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.
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? 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? Wie könnte eine Alternative dieser Messung aussehen?
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.
Danke, der Mac Stack beinhaltet den sogenannten Build Switch "RSSI_TO_LQI_MAPPING" der wie du schon gesagt hast auf einer ED-Messung basiert. Das ist vermutlich schon das richtige. Ferner werde ich mir mal das RSSI-Kapitel im Datenblatt des AT86RF212 angucken. Noch mal zurück zu den Fuses. Jörg Wunsch schrieb: > 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. Mit Controller-Firmware ist in meinem Fall das AVR Studio gemeint? Bisher ging ich davon aus, dass Software generell keine Fuses verändern kann. Also quasi eine Art Hardware-Einstellung sind. Doch beim Mac-Stack verwendeten die CPU immer die 8 MHz. Auch wenn die Fuse CKDIV8 programmiert ist. Die Erklärung fand ich im Datenblatt des ATmega1281 auf Seite 51. Demnach eine weitere Fuses die durch Software geändert und nicht nur ausgelesen werden kann. Ist die CKDIV8 Fuse eine Ausnahme, oder gibt es noch weitere Fuses, die bewusst per Software geändert werden können.
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.
Im Datenblatt www.atmel.com/dyn/resources/prod_documents/doc8168.pdf des AT86RF212 wird auf Seite 107 in Tabelle 7-15 zwischen EU1 und EU2 differenziert. Wo liegen die Unterschiede (Region)? Der verwendete Frequenzbereich von 868,0 MHz bis 868,6 MHz ist neben der Sendeleistung auch durch eine duty cycle von 1% limitiert. Ich habe gelesen, dass an Stelle des duty cycle ein LBT durchgeführt werden kann. Befinde ich mich innerhalb der vorgegebenen Richtlinien, wenn ich dem PIB Attribute phyCCAMode Mode 3 zuweise?
>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.
Vielen Dank für die Tipps. Axel Wachtler schrieb: > mit CCA_ED_THRESH = 7 (Resetwert) misst du bei je nach > Modulation bei -82 und -85 dBm, d.h. das sollte Ok sein. Dies bezieht sich doch auf den "Energy unter Schwelle" Wert. Ist dieser Wert alleine auch ausreichend? Carrier Sence only ist vermutlich nicht ausreichend, da laut IEEE 802.15.4 nur Standard konforme Signale mit gleicher Modulation und Spreizung empfangen werden können.
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.
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?
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: > Der verwendete Frequenzbereich von 868,0 MHz bis 868,6 MHz ist neben der > Sendeleistung auch durch eine duty cycle von 1% limitiert. Gilt das auch für den Verbindungsaufbau? Wenn z.B. bei einem Koordinator, 20 Teilnehmer in etwa zur selben Zeit einen Activ-Scan durchführen, wäre es doch möglich, dass der Koordinator den duty cycle beim Senden der Antwort nicht einhalten kann. Muss der Anwender die Antworten des Koordinators vielleicht durch einen Timer verzögern?
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).
Hallo liebe Leute, es hat bisher wohl noch keiner Geschafft die ZigBits per ISP zu programmieren. Ich würde gerne ein Netz (3 Knoten) mit ZigBits aufbauen, also muss ich mir wohl einen JTAG zulegen. Kann da jemand was empfehlen? Viele Grüße Marcel
Wollte ja nichts mehr dazu schreiben, weil das alles so alt ist, aber nachdem auch dieses Jahr noch Meldungen dazu hinzu gekommen sind... Ich lese hier immer MSIO/MOSI/SCK und vermutete Kollision mit dem RF230, aber beim MEGA1281 gibt es genauso eine Besonderheit in der ISP-Belegung, wie beim MEGA64/128, da sind MISO/MOSI vom ISP am USART0 zu suchen und nicht am SPI wie bei den allermeisten anderen AVR. PE0 = PDI (programm data in) PE1 = PDO (programm data out) PB1 = SCK (clock) Da der RF230 eben nicht an PE0/1, sondern an PB2/3 hängt kann der da auch keine Signale beeinflussen. Falls der ISP in der Werksprogrammierung natürlich abgeschaltet ist nutzt das Wissen allerdings beim ersten eigenen Zugriff auch nichts. Was JTAG angeht - da kann ich aus preislichen Gründen einen Dragon empfehlen. Den habe ich mir damals extra wegen dem Bedarf nach JTAG für die Raven-Boards besorgt und bin ziemlich zufrieden.
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
Hallo, ich hab ein kleines Problem und zwar ich lege mein ZigBit in den Schlafmodus. Dadurch ist "alles" im Schlafmodus. Ich brauche aber eine Uhr, die nebenher trotzdem läuft. Damit ich die Uhrzeiten jederzeit abrufen kann. Hab leider keine Ahnung, ob das geht. Kann mir da jemand helfen? Danke im Voraus! MFG
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.