Hallo Ich habe auf Basis des RFM12 und einem ATmega32 ein kleines, leistungsfähiges und preiswertes Funkmodul entwickelt, das ich auf meiner Webseite für andere Bastler zur Verfügung stellen will. Bitte nicht falsch verstehen, ich will an dieser Stelle keine Werbung machen oder irgendeinen Profit herausschlagen! Das ganze ist ein reines Hobbyprojekt von mir. Ich habe nur immer wieder gesehen, dass hier viele Bastler Probleme mit dem RFM12 haben. Um der Community quasi etwas zurückzugeben habe ich Dokumentation, Schaltpläne und Sourcecodes online gestellt. -------------------------- Um was handelt es sich? Das Funkboard ist eine kleine Platine und setzt sich im Wesentlichen aus dem RFM12, einem ATmega32 und etwas Peripherie zusammen. Der AVR übernimmt die komplette Ansteuerung und verwandelt die Schaltung in eine Art Funkmodul-"Blackbox". Dieses kann man dann sehr einfach in den verschiedensten Projekten wiederverwenden. Externe Mikrocontroller (und ihre Programmierer ;-) ) müssen sich nicht mit der Ansteuerung des RFM12 auseinandersetzen. Das alles übernimmt der AVR. Man übergibt der "Blackbox" lediglich die zu übertragenen Daten. Initialisierungen, Puffern, Checksummen, Empfangsquittierungen, etc. läuft alles intern ab. Das ganze lässt sich natürlich in vollem Maße konfigurieren. Man hat per Software über den AVR Zugriff auf fast alle Einstellungen des RFM12 und des AVRs. Kernmerkmale: - 434MHz Sende-/Empfangsfrequenz - Halbduplexfähig - Reichweite bis einige hundert Meter - SMA Antennenanschluss vorgesehen - 32*34mm Abmessungen, steckbar durch 2 Stiftleisten im 2,54mm Raster - Funknetzwerk mit bis zu 125 Modulen möglich! - Ansteuerung über UART, I2C und SPI in Planung - Konfigurationen des AVRs und RFM12 ohne Neuprogrammierung änderbar - Übertragungssicherheit von nahezu 100%! - Schnelle Sende-Empfang-Umschaltzeiten von ca. 1,5ms - PC Terminalprogramm zum Testen und Konfigurieren - 3,2V - 5,4V Betriebsspannungsbereich - Ca 10mA Stromverbrauch (nicht gemessen), 2 Schlafmodis bis 25µA! Das ganze ist noch nicht ganz fertig. Funktionieren tut aber alles so weit wie beschrieben. Hoffe damit dem ein oder anderen helfen zu können. Über konstruktive Kritik freue ich mich natürlich besonders :-) Alles weitere unter: http://www.flashcraft.de Ein Bild der mit EAGLE 3D gerenderten Platine: http://flashcraft.de/images/user_images/funkboard/funkboard_start.png (Oberseite, RFM12 nur mit Bestückungsdruck sichtbar)
Hallo, das sollte keine prinzipielle Kritik sein, jedoch wäre es nicht zielführender, einen Mega48 oder so zu verwenden, als einen Mega32, der doch einiges mehr kostet. Ich denke nicht, daß für die einfache Aufgabe der Speicherplatz des Mega32 wirklich gebraucht wird, und daß ein Mega48 das auch problemlos schaffen könnte.
also deine Seite ist wirklich Spitze, vor allem die 57 seitige Doku, Respekt! Das ist eine gute Referenz wenn du dich nach dem Studium irgendwo bewirbst.
>Ich denke nicht, daß für die einfache Aufgabe >der Speicherplatz des Mega32 wirklich gebraucht wird, und daß ein Mega48 >das auch problemlos schaffen könnte. Na dann setz Dich mal hin und mach mal.
Nach dem ersten Überfliegen: Hochachtung: Sauberes Projekt und mehr als gut dokumentiert. Da kann sich so mancher einer eine Scheibe von abschneiden. Frage 1: Warum können die Datenpakete denn nur 50 Byte lang sein ? Damit wird der Anwendungsbereich doch ein wenig eingeschränkt (Okay, gebe zu, 10 Pakete a 50 Bytes gibt auch ca. 512 Bytes). Frage 2: CRCs sind ja schon implementiert. Gibt's noch Platz im Flash um z.B. Manchester encoding einzubauen, um die Clock and Signal recovery zu verbessern ? Gruß Manni
RESPEKT !!!! Tolles Projekt. Ich habe auch so ein paar Module rumliegen und hatte eine ähnliche Idee, aber keine Zeit ...
Vielen Dank erst einmal für eure Kritik :) gast wrote: > Hallo, > das sollte keine prinzipielle Kritik sein, jedoch wäre es nicht > zielführender, einen Mega48 oder so zu verwenden, als einen Mega32, der > doch einiges mehr kostet. Ich denke nicht, daß für die einfache Aufgabe > der Speicherplatz des Mega32 wirklich gebraucht wird, und daß ein Mega48 > das auch problemlos schaffen könnte. So einfach wars dann doch nicht ;) Ich habe auch lange überlegt welchen µC ich verwende. Ein Mega48 ist definitiv zu klein. Da kommt schon etwas an Code zusammen. Der Flash des Mega32 ist zu ca. 70% voll, macht also ca. 23kB. Kleinvieh macht auch Mist, und die Datenpufferung sowieso. Weil ich sowieso noch einige Mega32 in DIL herumliegen hatte und damit sofort mit einem 1:1 Testaufbau starten konnte fiel die Wahl dann auf den. Manni wrote: > Frage 1: Warum können die Datenpakete denn nur 50 Byte lang sein ? Damit > wird der Anwendungsbereich doch ein wenig eingeschränkt (Okay, gebe zu, > 10 Pakete a 50 Bytes gibt auch ca. 512 Bytes). > > Frage 2: CRCs sind ja schon implementiert. Gibt's noch Platz im Flash um > z.B. Manchester encoding einzubauen, um die Clock and Signal recovery zu > verbessern ? Zu 1: Ich werde beim Überarbeiten des Codes die maximale Paketgröße auf ca. 70-80 (oder höher) anheben. Das ist schnell gemacht. Ich wusste anfangs noch nicht wie ich mit dem Flash hinkomme. Darum habe ich die Paketgröße (die gleich mehrfach reserviert wird wegen interner Pufferung) anfangs recht moderat gewählt und sie bis zum Ende so belassen, auch weil ich meist nur kleine Paketlängen benötige. Aber wie gesagt, kein großer Akt die nach oben zu schrauben. Zu 2: Ca. 30% des Flashes sind noch frei. Da gibts noch viel Platz für Erweiterungen :) Manchester wäre denkbar. Ebenso wie eine Verschlüsselung der gesendeten Daten.
wär gut wenn das eindrücke bild einen link zum prject hätte
>So einfach wars dann doch nicht ;) >Ich habe auch lange überlegt welchen µC ich verwende. Ein Mega48 ist >definitiv zu klein. Da kommt schon etwas an Code zusammen. >Der Flash des Mega32 ist zu ca. 70% voll, macht also ca. 23kB. >Kleinvieh macht auch Mist, und die Datenpufferung sowieso. >Weil ich sowieso noch einige Mega32 in DIL herumliegen hatte und damit >sofort mit einem 1:1 Testaufbau starten konnte fiel die Wahl dann auf >den. Verstanden, code ist auch konfortabel geschrieben. Sollte interesse bestehen, ich wäre interessiert, so ein modul im 2-3 Euro bereich (ohne RFM12) zu entwickeln, und auch abzugeben, mit RFM12 aufgelötet.
Hallo Florian - klasse Projekt! Aber wie kommst du darauf, daß der Flash des Mega32 bereits zu 70% voll ist? Habe deine Sourcen gerade mal bei mir compiliert und ich komme da nur auf ca. 9KB!
Wenn Volker recht hat, dann passt ja noch ne Menge rein. Ist wohl nur eine Frage, welche Compiler Optionen man verwendet (-O0 bis -Os). Du hast den richtigen Weg gewählt: erst mal sehn, wie groß der Gesamtcode wird, und dann kann man die Datenpaketgröße immer noch anpassen !! Bin gerade dabei einen FEC Algorithmus mit Convolutional Encoder mit Constraint Length von bis zu 7 auf TX Seite und auf RX Seite mit einem Viterbi Dekoder zu entwickeln. Sollte schon in einen ATmega32 passen. Vielleicht kann man den dann noch da rein packen. Nochmals: Tolles Projekt und Respekt !!!! Gruß Manni
Hi, super Projekt! Hast Du vor, die Eagle-Files bereitzustellen oder bietest Du gar Platinen zum Kauf an? Ich hätte starkes Interesse ;-) Danke und Grüße, Jürgen
Schönes Projekt. Wie wäre es, den extra Quarz für den ATmega weg zu optimieren? Es ist ja ein Quarz beim Funkmodul vorhanden, dessen Taktsignal ja genutzt werden kann. Gruß
@ Volker Wie hast du den Code denn auf 9KB gebracht? Habe bei meinem AVRStudio Optimierung -Os eingestellt, dennoch bleibe ich bei 23kB hängen. aber in jedem Fall ist noch Platz für Erweiterungen :) @ Jürgen A. Habe im Moment selbst nur einen 1:1 Aufbau auf Lochraster und warte noch auf meine Prototypenplatinen die diese Woche kommen sollten. Funktionieren sollten sie sicher, allerdings sind sie noch nicht "für die Masse" ausgelegt, da werden noch Überarbeitungen anstehen um die Platinen einfacher und billiger herstellen zu können. Vorerst macht es also keinen Sinn das Layout freizugeben. @ 123 Der Quarz wurde absichtlich als externes und bedrahtetes Bauelement draufgepackt. Hintergrund ist vor allem die UART-Baudrate. Die auswählbaren Takte des RFM12 eignen sich für viele Baudraten nicht, mit einem externen Quarz kann man die Baudraten frei wählen. Betreibt man außerdem das Modul mit 3,3V darf der Takt des AVRs 8MHz nicht überschreiten. Dann müsste man den RFM12 Takt am DCLK auf (max) 5MHz setzen...wieder Problem mit Baudraten und 3MHz verschenkt falls man diese will/braucht
@Florian:
>Wie hast du den Code denn auf 9KB gebracht?
Ich gar nicht - habe nur das Makefile ausführen lassen ;-)
Das ist die Ausgabe von avr-size:
text data bss dec hex filename
8982 50 1456 10488 28f8 FUNKMODUL.elf
Okay, es sind dann doch etwas mehr als 10KB - hatte nur das reine
Textsegment betrachtet - aber 23?
Oder habe ich da was übersehen?
Gruß, Volker
@Florian: Vielleicht hast du eine von den verbuggten AVR-GCCs erwischt. Ansonsten: Super Projekt! Die Doku ist ja Wahnsinn.
Ich habe mir auch so ein Funkboard gebaut! Allerdings nur mit nem Mega8 und nem RS232 on Board : http://defencemercury1.dyndns.org/AlexanderDW/Bilder/IMG_2288.jpg Bestückt werden kann diese auch mit nem USB-Port. Spannungsversorgung kommt dann vom USB-Anschluss des PCs. Die Einzellplatine hat mich knapp 12 Euro zzgl MwSt. gekostet! Falls Interesse besteht, kann ich ne Ladung Platinen bestellen lassen! Grüße Alex
Florian Scherb wrote: > @ Volker > > Wie hast du den Code denn auf 9KB gebracht? > Habe bei meinem AVRStudio Optimierung -Os eingestellt, > dennoch bleibe ich bei 23kB hängen. > > aber in jedem Fall ist noch Platz für Erweiterungen :) Habs mir grad mal angeschaut. Dein .hex file aus dem rar ist ja nur 25kb gross, da kann dein Code garkeine 23kb sein. Das .elf aus dem rar sagt mit avr-size bei mir auch: text data bss dec hex filename 9058 50 1456 10564 2944 FUNKMODUL.elf Trotz allem, sieht nach ner netten Sache aus. Hab heute meine RFM*-Module bekommen, werde da wohl gleich mal was mit rumspielen. :)
Hast du evtl. Lust das Protokoll kompatible zu http://www.mikrocontroller.net/articles/RFM12_Protokoll_Stack zu machen? An dem verlinken Stack ist natürlich auch noch nicht alles fix, kann man sich also in der Mitte treffen. Dein AVR würde dann quasi Layer 1 und 2 übernehmen. Die PC Seite lässt sich auch günstig mit einem USBprog realisieren, falls man schon einen hat.
@ Manuel Stahl Euer Stack sieht sehr interessant aus, konnte Ihn aber aus Zeitgründen gerade nur überfliegen. Beteiligen kann ich mich leider aus Zeitgründen schon gar nicht. Mein Projekt ist zwar fast schon fertig, aber eben nur fast ;-) Und die letzten paar Prozent kosten immer noch deutlich Zeit. @ Simon K. und Volker Danke dass ihr da nochmal geschaut habt. Wegen der Größe muss ich wirklich mal schauen. Mir kommen da auch schwere Zweifel auf ob meine 23kB stimmen. Allerdings zeigt mir das auch mein Compiler an.
Nochmal ich ;-) Weil es einige Anfragen zur Platine gibt habe ich nun dazu einen kleinen Abschnitt auf meiner Webseite angefügt. Dort werde ich das dann laufend aktualisieren wenn sich in der Richtung etwas tut.
Hallo Florian Scherb Super Projekt! Habe versucht das Terminal herunter zu laden... Die Datei wird nicht gefunden. Schaust Du Bitte mal danach? Danke
Hallo Das Terminalprogramm ist noch in Entwicklung. Die erste zur Veröffentlichung freigegebene Version wird vermutlich erst zum Wochenende hin downloadbar sein. Solange ist der Link leider tot. Hat sich leider etwas hingezogen, darum verweist die Seite auch auf einen Deathlink. Aber die Zeit zum Ändern der Seite stecke ich dann doch lieber ins Programm ;-)
Respekt! finde das Projekt wirklich sehr gelungen. Vor allem die ausführliche Dokumentation ist sehr schön! Soetwas findet man nicht alzu oft. Wenn es Platinen dazu geben würde hätte ich auch Interesse!
Danke :) So, Terminalprogramm ist nun auch fertig :) Zwar noch etwas umständlich programmiert, da kann man noch gut was wegoptimieren aber es funktioniert soweit mal ganz gut. In den nächsten Tagen und Wochen beginnt dann der Feinschliff. ------- Zum Projekt: http://www.flashcraft.de
Soooo :-) Die Prototypen sind eingetroffen und getesetet worden. Gibt noch ein paar Bugs und Dinge die noch verbessert werden können aber im Großen und Ganzen bin ich doch recht zufrieden, die Spezifikationen erfüllt es :-) Was mir mehr Kopfzerbrechen bereitet ist der Verkauf von Leiterplatten (bestückt + restliche Komponenten zum selber Löten). Das lasse ich nun sehr wahrscheinlich bleiben, es wird also keine Leiterplatten oder teilweise fertige bis komplett fertige Funkboards zum Kaufen geben. Die ganze Rechtslage ist mir doch etwas zu heiß. Ich kenne mich mit dem Verkauf von "Bastlerzeug" nicht genug aus um einen Verkauf zu wagen. In jedem Fall wäre wohl ein Gewerbeschein nötig, da sich der Verkauf nur bei etwas größeren Stückzahlen lohnt (>50, die hätte ich jedoch wohl). Dazu kommen noch die EMV-Richtlinien, die bei einem Funkmodul ja mal mehr als heikel sind...usw. Unterm Strich zu viel Aufwand und Risiko für das Ganze,... Eigentlich schade,...
Wer auf ATMega 8 in DIL gehen möchte kann folgendes nachbauen Testboard: http://comwebnet.weimars.net/index.php?option=com_content&task=blogsection&id=2&Itemid=49
Schade, Florian! Vielleicht kannst du dich ja noch mit dem Gedanken anfreunden, dass ein Anderer die Boards verkaufen kann/darf. Einen Tipp habe ich dir ja schon per Email gegeben ;-) Falls nicht, stellst Du wenigsten das Layout zur Verfügung? Danke und Grüße, Jürgen
Hallo Wenn die Boards nicht verkauft werden werde ich auf jeden Fall das Layout online stellen, soviel ist sicher :)
Du könntest ja auch die nackten Platinen verkaufen...
abo .. mit der Hoffnung das jemand von dem Teil unbestueckte Platinen verkauft :D ..
Es steht letztendlich natürlich allen frei sich zu Sammelbestellungen für die Platinen zusammenzuschließen ;-) Genaueres werde ich dann aber auch nochmal durchgeben, wenns so weit wäre. Ich werde die Sammelbestellungen auf jeden Fall nicht koordinieren. Sorry. Ich bin schon mit der Entwicklung gut beschäftigt. Nebenher dann noch reihenweise Pakete zu verschicken, Überweisungen zu kontrollieren und Rabatte rauszuschlagen ist mir dann wirklich zu viel. Bei fertigen oder halbfertigen Modulen wäre das was anderes gewesen, aber weil mir das eben zu heiß ist lass ich das bleiben.
Wäre evtl. auch interessiert! Wurde das Layout für die Verbindung zwischen Funkmodul und Antenne für 433MHz optimiert? Beste Grüße, Tiga
Hallo Bei meinen Prototypen nicht. Kommt aber auch darauf an, was du genau meinst. Viel zu Optimieren gab es da jetzt nicht. Der Antennenausgang des RFM12 ist praktisch direkt an der SMA-Buchse dran. Nur ca. 3mm Leiterbahnweg, der so weit es ging mit Masseflächen vor anderen Signalleitungen abgeschirmt wurde. Von da an hängt dann alles weitere an der Antenne selbst. Die Massefläche selbst wurde nicht als Gegenpol ausgelegt, ist bei dem kleinen Ding auch kaum vernünftig zu schaffen...das ist dann dem SMA-Antennenaufbau überlassen.
Leider kenne ich mich mit dieser Problematik auch nicht besonders gut aus... Ich habe nur im Schaltplan gesehen das Du auch eine Stichleitung zum CON2 gezogen hast. Wie viel das schadet weis ich aber auch nicht genau. Aber die Lötbrücke vom RFM zum Board ist ja auch eher nur suboptimal (ich weis, "irgendwie" muss man das Signal ja rüber bringen ) - wahrscheinlich fällt es somit gar nicht so sehr ins Gewicht.
Achso, das meinst du. Die Lötbrücke ist denke ich weniger problematisch. Das RFM12 liegt direkt auf den verzinnten Kontakten der Platine auf. Das Lot muss keine lange Brücke bilden. Ja, die Stichleitung zu den Stiftleisten habe ich mit eingebaut wenn man andere Antennen verwenden will. MMCX-Stecker, BNC oder ein einfaches Drahtstück auf Lochraster. Wenn diese Möglichkeiten nicht verwendet werden, so kann man diesen "Stift der Stiftleiste" auch einfach weglassen. ;-)
Hast du mal überlegt, deine Entwicklung an das "Embedded Projects Journal" zu schicken? Eventuell könnte man ja auch über diesen Weg die Platine bzw. den Bausatz vertreiben. Ist nur so eine Idee, da es schade wäre wenn das Modul für andere nicht nutzbar / nachbaubar wäre. Sven
Das ist eine tolle Idee! Vielen Dank für diesen Hinweis :-) Sobald das ganze "Marktreife" angenommen hat werde ich mich mal damit befassen. Wäre wirklich klasse wenn sich darüber etwas erreichen liese.
Hallo zusammen, ich beabsichtige RFM-Funkmodule (vielleicht auch die DIL-Varianten) zu kaufen und suche aber noch einen passenden Aufbau (Layout, Bausatz,...) damit man nicht von "0" anfangen muß. Ziel ist die Anbindung an den µServer von Simon Küpper, das Board sollte also schön klein sein. Da mir das Pollin-Board zu groß ist, habe ich bisher 2 Möglichkeiten. 1) Board zu dem Artikel "AVR RFM12" http://www.mikrocontroller.net/articles/AVR_RFM12 2) Funkboard von Florian Scherb http://www.flashcraft.de/index.php/funkboard-uebersicht Die 2 wichtigsten Fragen: @Florian Wird es in naher Zukunft (vor Weihnachten:-) eine Platine in einem Shop geben oder wenigstens das Layout? @all Ich würde gerne die 8xxMHz Module verwenden. Läuft da die ganze Software auch mit? Jetzt bin ich natürlich etwas ratlos. Auf welches Pferd soll ich setzen? Für 2) spricht, dass mehr Leute dran mitgewirkt haben und es mehr Community-Unterstützung gibt. Dafür besticht 1) durch sehr gute Doku und macht daher einen wirklich soliden Eindruck. Gerne würde ich mal Eure Meinung dazu hören (ich hoffe, dass kann ich im Rahmen dieses Threads anstossen, es geht ja auch um technische details des Funkboards). Vielen Dank Grüße Jörg
@ Jörg T. Für was du dich letztendlich entscheidest hängt auch von deinen Ansprüchen und Wünschen ab. Die 2 Dinger sind zwar recht ähnlich, aber haben halt schon gewisse Unterschiede. Ich möchte da nicht buhlen ;-) @ All (und @ Jörg T.) Fakt ist, dass ich mein Layout in den nächsten Tagen online stelle. Dann kann es jeder verwenden. Ich hoffe, zumindest gibt es schon Interessenten, dass manche das Layout so abändern, dass man es auch durch einfachere (Ätz-)Prozesse herstellen kann. Ziel ist in jedem Fall, dass es nach einer Zeit verschiedene Layouts für verschiedene Ansprüche gibt. Zur Not setze ich mich selbst daran ;-) Arbeite gerade an einer endgültigen Version der Doku in der einige Käfer noch behoben werden. Selbiges beim Quellcode. Danach werde ich das ganze dann mal Embedded Projects o.ä. vorlegen. Evtl. wird es dann dort auch eingestellt werden. Wenn nicht als fertiger Bausatz, dann zumindest "einfach so". Ihr könnt gerne jetzt schon daran mitwirken und das Projekt für euch nutzen :) Aber ich muss hier nochmal ganz klar sagen, dass das Projekt noch nicht abgeschlossen ist. Der Faktor "Unbekannt" ist also noch da. Soll aber niemanden abhalten ;) Ich werde in den nächsten Tagen/Wochen erste Stresstests machen und mal schauen wie sich die Dinger im harten Bastleralltag so erproben ;-) Ob die 868-Module funktionieren würde mich ebenfalls interessieren. Ich besitze leider keines. Wäre super, wenn sich da jemand melden könnte der das weis.
Hallo Florian, was genau heisst "einfacherer Ätzprozess"? Das ist doch eine doppelseitige Platine, oder? Ist das Bild auf Deiner Website die Platine, die Du kürzlich aus der Fertigung erhalten hast? Ja, dass mit den 868MHz Modulen interessiert mich am meisten, da ich diese jetzt als erstes in Kürze bestellen will. Mit dem Board würde ich zur Not noch warten können (bis das Layout und die Doku bugfixed ist). Vielleicht gibt es ja eine Aussage von den Machern des anderen Boards und deren RFM12-Stack Implementation. Ich weiß ehrlich gesagt nicht einmal, ob die 400 und 800er Pin-kompatibel sind... Gruß Jörg
Von mir ist das andere hier genannte Board. Wichtig war dabei möglichst kleiner Footprint (deshalb ist der AVR auf der Rückseite) und dass man es direkt an USB anschließen kann. Allerdings sind mir ein paar Fehler (auf der Wikiseite dokumentiert) aufgefallen, die erst beim Fertigen zu sehen waren. Wenn jemand das Board nachbauen will sollte man da erst nochmal drübersehen.
Hallo Manuel, vielen Dank für die Infos. Die Hinweise bzgl. der kleinen "Bugs" hatte ich gelesen. Könntest Du Dich denn zu einer Aussage hinreissen lassen, ob man auch (ggf. mit welchem Aufwand) die 800er Module verwenden kann :-) Mir scheint, als gibt es mit den 800er Modulen allgemein noch nicht viel Erfahrung, oder? Gruß Jörg
Das Datenblatt ist jedenfalls das gleiche für alle Bänder: http://www.hoperf.com/pdf/RFM12.pdf Daher sollte auch das Pinlayout gleich sein und die Ansteuerung sowieso. Gibt sogar ein Register in dem das Band festgelegt wird.
1 | Configuration Setting |
2 | |
3 | Hex = 80 & xx |
4 | Bit-Syntax: 10000000 | el | ef | b1 | b0 | x3 | x2 | x1 | x0 |
5 | el (TX FIFO) = Sendepuffer für Datentransfer nutzen (1 = An / 0 = Aus) |
6 | ef (RX FIFO) = Empfangspuffer für Datenspeicherung nutzen (1 = An / 0 = Aus) |
7 | b... = Zu nutzende Basisfrequenz (00=315MHz / 01=433MHz / 10=868MHz / 11=915MHz) |
8 | x... = Interner Clock des Chips kann durch verschieben einer Kondensator-Anpass-Stufe bestimmt werden. |
9 | 0,5pF pro Schritt. Basis ist 8,5pF -> (0000=8,5 / 0001=9,0 / 0010=9,5 / ...) |
@Manuel, kommt denn eigentlich auch ein Normalsterblicher an einen svn-Zugang? Wegen Eagle-Layout etc. Gruß
ein eigenes SVN wollte ich nicht vielleicht habe ich das auch falsch verstanden mein Verständnis nach, ist ein Zugang in diesem Projekt auch erforderlich, wenn man "nur" Sourcen, Layout, etc. lesen will - ist das richtig? oft ist ja auch so, dass man ein Zugang benötigt, wenn man konstruktiv mitwirkt...
Wegen dem 868 RFM12 Modul nochmal... Ja, die Datenblätter, Pinlayout, Platine etc ist genau gleich. Aber bevor ich da jetzt einfach sage "433 Modul zu 868 Modul äquivalent" wäre eine Bestätigung von jemand der das tatsächlich schon ausprobiert hat natürlich besser. Dass die Datenblätter bisschen...naja...sind ist ja bekannt.
Super, klingt ja gut :-) Board Layout ist nun auch online.
Hey alle miteinander!! Ich wusste bis eben nichts von dem Thread hier, ich hab das hauptsächlich im Roboternetz verfolgt, dort gibt es quasi "den gleichen" thread. Da ich dort eine Sammelbestellung organisiert habe, möchte ich das natürlich auch hier anbieten. Angeboten werden original Flashcraft-Funkmodul-Platinen und zusätzlich biete ich an die Bauteile (ohne das RFM12) an. die Bauteile kosten etwa 10 euro (reichelt.de halt den einkaufspreis+versandanteil) das RFM12 gibts auch zu haben, werden auch nochmal für die mitbesteller bei pollin.de bestellt. das mit den bauteilen: entweder alle, oder keins, zwischendinger machen mir zu viel arbeit sorry... ansonsten, einfach die "bestellungen" an Pr0gm4n ( ät ) gmy.de (gmx.de halt...) ich hoffe, ihr nehmt zahlreich teil, dann können wir den preis noch weiter senken!! denkt bitte daran, bestellungen, die nicht per e-mail erfolgen kann ich leider nicht wahrnehmen und ihr habt mit dieser e-mail auch noch keinerlei verpflichtungen uns gegenüber auch wirklich teilzunehmen... LG Pr0gm4n
Hallo, verstehe ich nicht. Ich dachte das Layout wäre heute erst online gestellt von Florian? Gruß
Angehängte Dateien:
Verstehe an vielen Stellen nicht warum das so geroutet ist. Warum nicht die richtigen Pads für die SUB-D9 Buchse? Gibts doch als fertiges Bauteil.. Und ich verstehe nicht ganz warum da über den Antennenstecker geroutet wurde..nicht sehr elegant..
@Jörg T. Ist es auch. Zu dem Design selbst noch: Es funktioniert, allerdings ist es nicht gerade optimal geroutet, muss ich selbst zugeben. Mir ging es damals mehr darum das Ding überhaupts mal auf meinem Tisch liegen zu haben ;)
@Max: Ja das Routing ist nicht so toll geworden. Die SUB-D Kontakte sind aber Absicht (siehe Photo im Wiki) da man direkt eine Buchse anlöten kann.
Hallo, könnte bitte noch wer die "Top Seite" als Bild anhängen. Die "Bottom Seite" ist ja schon hier im Thread. Danke Peter
@Florian heisst das, man hat Dein Board layoutet und in einer Sammelbestellung in Auftrag gegeben? Warst Du auch daran beteiligt? Ist das dasselbe Board?
Oh, sorry, dachte das Layout sei das von Florian. Kann bitte wer Florians Board als Bilder einstellen. Ober und Unterseite. Vielen Dank, Peter
Hi Puchi, Florian hat sein Layout auf seiner Homepage http://www.flashcraft.de/index.php/projekt-funkboard-board-layout bereitgestellt. @all Sorry, dass ich hier mit meiner Anfrage doch etwas Verwirrung und Verwechselungen hereingebracht habe...
Hallo, danke, das wusste ich schon, hab jedoch kein Eagle. Also kann die schnell wer hochladen? Wäre euch sehr dankbar, Peter
Hab mir grad mal die Doku zur Datenübertragung durchgelesen. Ich persönlich finde Florian lehnt sich hier mit manchen Formulierungen etwas weit aus dem Fenster: -Sehr kurze Umschaltzeiten zwischen Senden/Empfangen (ca 1,5ms). Das entspricht bei 38400 Baud immerhin mehr als 7 Byte, also etwa ein kurzes Paket. (Ich weiß, das liegt am RFM12) -Nahezu 100% Datensicherheit. Bei Funk grundsätzlich nicht möglich. Nahezu 100% Sicherheit, dass Fehler erkannt werden? Naja, siehe Checksummen. Startzeichen: Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht verwendet? Checksummen: -Checksummen nach jedem fünften Byte. Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der Sender das nicht und sendet trotzdem das komplette Paket. -Checksummen durch Quersummenbildung. Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus mal zufällig passieren. Blackbox: Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht mehr nachträglich ändern. Das alles ist nicht böse gemeint, soll nur konstruktive Kritik sein.
@Manuel Stahl Da hast du stellenweise natürlich recht. Ich arbeite gerade auch noch an der Doku, dass sie formal passt und nicht "zu abgehoben" klingt :) Ich habe mich bei allen formulierungen auf andere Funkmodule in der Preisklasse um ca. 50€ pro Stück bezogen, von denen ich selbst welche hier habe. Quasi als Referenz. >> -Sehr kurze Umschaltzeiten zwischen Senden/Empfangen (ca 1,5ms). >> >> Das entspricht bei 38400 Baud immerhin mehr als 7 Byte, also etwa ein >> kurzes Paket. (Ich weiß, das liegt am RFM12) Ein Punkt wo ich die Doku überarbeiten werde, da gebe ich noch genaue Werte an. Grob kann man sagen 1,5ms. Ist im Vgl. zu anderen Modulen relativ wenig. Habe hier welche mit 2ms und 4ms. >> -Nahezu 100% Datensicherheit. >> Bei Funk grundsätzlich nicht möglich. Nahezu 100% Sicherheit, dass >> Fehler erkannt werden? Naja, siehe Checksummen. Muss ich dir auch recht geben. Mit dem Satz beziehe ich mich darauf, dass gesendete Daten mit allen Sicherheitseinstellungen nicht falsch am Empfänger interpretiert werden und dass "normale Bastlerumgebung" verwendet wird. >> Startzeichen: >> Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht >> verwendet? Welche Startsequenz meinst du genau? Das Startzeichen als Sicherheitsmerkmal ist natürlich nicht der Reisser. Aber, und das kommt auch noch in die Doku, sie macht die Arbeit beim Debuggen enorm leichter, da man sehr schnell einen Einstiegspunkt in die Übertragung findet. >> -Checksummen nach jedem fünften Byte. >> Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der >> Sender das nicht und sendet trotzdem das komplette Paket. Richtig. Wenn man jedoch Pakete mit 40, 50 Bytes versendet und "Bitdreher" passieren merkt das der Empfänger (und kann immer noch ein NACK senden). Sie werden immerhin dann nicht falsch interpretiert. >> -Checksummen durch Quersummenbildung. >> Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle >> Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus >> mal zufällig passieren. Den Punkt will und muss ich auch noch ändern. Die Checksumme soll dann aus zusätzliche arithmetischen Operation gebildet werden. Multiplikation, Addition usw. Dadurch wird sowas zumindest weitgehend unterbunden. >> Blackbox: >> Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht >> mehr nachträglich ändern. Da kann ich dir nicht ganz folgen? >> Das alles ist nicht böse gemeint, soll nur konstruktive Kritik sein. Finde ich super!! :) Das Ding ist ja auch nur ein Hobby-Projekt, also nichts in sich perfektes :) Und um zusätzliche Ideen und Vorschläge bin ich immer wieder froh.
Florian Scherb wrote: >>> Startzeichen: > >>> Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht >>> verwendet? > > Welche Startsequenz meinst du genau? > Das Startzeichen als Sicherheitsmerkmal ist natürlich nicht der Reisser. > Aber, und das kommt auch noch in die Doku, sie macht die Arbeit beim > Debuggen enorm leichter, da man sehr schnell einen Einstiegspunkt in die > Übertragung findet. 0x2D 0xD4, darauf kann man das RFM12 triggern lassen. Vorher fängt es gar nicht an was zu empfangen -> der µC muss nicht aufwachen. Vor den Sync sollte man aber noch zweimal 0xAA senden um den Takt auf die Flanken zu synchronisieren. >>> -Checksummen nach jedem fünften Byte. > >>> Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der >>> Sender das nicht und sendet trotzdem das komplette Paket. > > Richtig. Wenn man jedoch Pakete mit 40, 50 Bytes versendet und > "Bitdreher" passieren merkt das der Empfänger (und kann immer noch ein > NACK senden). Sie werden immerhin dann nicht falsch interpretiert. Aber NACK kann er doch auch erst nach dem kompletten Paket senden. Eine (evtl. auch längere) Checksumme tuts genauso. >>> -Checksummen durch Quersummenbildung. > >>> Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle >>> Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus >>> mal zufällig passieren. > > Den Punkt will und muss ich auch noch ändern. Die Checksumme soll dann > aus zusätzliche arithmetischen Operation gebildet werden. > Multiplikation, Addition usw. Dadurch wird sowas zumindest weitgehend > unterbunden. Nimm doch einfach nen Standard. In der util/crc16.h der avrlibc findet sich die Funktion _crc_ibutton_update() welche eine 8-bit CRC implementiert. >>> Blackbox: > >>> Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht >>> mehr nachträglich ändern. > > Da kann ich dir nicht ganz folgen? Du kannst z.B. den Addressbereich nicht nachträglich vergrößern oder ähnliches, da man bei der Verwendung einen Teil des Protokolls (in diesem Fall zwar nur ein kleiner) kennen muss.
Manuel Stahl wrote: > Florian Scherb wrote: > >>>> Startzeichen: >> >>>> Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht >>>> verwendet? >> >> Welche Startsequenz meinst du genau? >> Das Startzeichen als Sicherheitsmerkmal ist natürlich nicht der Reisser. >> Aber, und das kommt auch noch in die Doku, sie macht die Arbeit beim >> Debuggen enorm leichter, da man sehr schnell einen Einstiegspunkt in die >> Übertragung findet. > > 0x2D 0xD4, darauf kann man das RFM12 triggern lassen. Vorher fängt es > gar nicht an was zu empfangen -> der µC muss nicht aufwachen. Vor den > Sync sollte man aber noch zweimal 0xAA senden um den Takt auf die > Flanken zu synchronisieren. > Achso jetzt, das ist bereits drin. >>>> -Checksummen nach jedem fünften Byte. >> >>>> Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der >>>> Sender das nicht und sendet trotzdem das komplette Paket. >> >> Richtig. Wenn man jedoch Pakete mit 40, 50 Bytes versendet und >> "Bitdreher" passieren merkt das der Empfänger (und kann immer noch ein >> NACK senden). Sie werden immerhin dann nicht falsch interpretiert. > > Aber NACK kann er doch auch erst nach dem kompletten Paket senden. Eine > (evtl. auch längere) Checksumme tuts genauso. > An eine längere Checksumme dachte ich auch schon, ja. Und mit deinen Einwänden/Vorschlägen ist das wirklich eine Überlegung wert. >>>> -Checksummen durch Quersummenbildung. >> >>>> Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle >>>> Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus >>>> mal zufällig passieren. >> >> Den Punkt will und muss ich auch noch ändern. Die Checksumme soll dann >> aus zusätzliche arithmetischen Operation gebildet werden. >> Multiplikation, Addition usw. Dadurch wird sowas zumindest weitgehend >> unterbunden. > > Nimm doch einfach nen Standard. In der util/crc16.h der avrlibc findet > sich die Funktion _crc_ibutton_update() welche eine 8-bit CRC > implementiert. > Dass es dafür einen quasi-standard gibt wusste ich noch nicht. Werde ich mir aber anschauen. Danke! >>>> Blackbox: >> >>>> Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht >>>> mehr nachträglich ändern. >> >> Da kann ich dir nicht ganz folgen? > > Du kannst z.B. den Addressbereich nicht nachträglich vergrößern oder > ähnliches, da man bei der Verwendung einen Teil des Protokolls (in > diesem Fall zwar nur ein kleiner) kennen muss. Ja richtig. Allerdings, so denke ich mir, werden 125 IDs dicke für praktisch alles ausreichen. Das ist schon eine ganze Menge. Bin über deine Ratschläge auf jeden Fall sehr dankbar. Gerade wenn man da noch mehr Leistung rauskitzeln kann. Die meisten Änderungen, gerade CRCs und sowas wären ja auch relativ schnell gemacht. Ich teste gerade die Module auf Funktion. Die Kette PC-Terminal -> Funkboard ~~~~ Funkboard -> µC + Logic Analyzer funktioniert schon einmal ganz gut. Da kann man langsam an die Verbesserungen gehen.
Noch ein Nachtrag: Genau aus diesen Gründen bitte ich da manche auch (speziell "Pr0gm4n", soll kein Angriff sein!) etwas das Tempo runterzufahren. Solange die Software hier noch in der Entwicklung ist, ist es meiner Ansicht nach zu früh sich schon darauf richtig fest zu satteln und jetzt schon Bestellungen machen. Natürlich freut mich das, aber noch ist es einfach zu früh.
Habe mir das mit den Checksummen nochmal angeschaut und muss dir absolut recht geben. Stellenweise etwas sinnfrei ;) Ich werde das nun bei Zeiten mal umändern. Die "Zwischenchecksummen" werden rausgeworfen, spart Bandbreite. Stattdessen werden alle Pakete komplett abgerufen und die (evtl. größere) Checksumme am Ende ausgewertet. Rest bleibt unverändert. Durch die Kappselung (soweit man das bei C so nennen kann) bleibt das ganze aber nach außen hin komplett unverändert. Vielen Dank nochmal für die Tipps :)
Hallo Florian gibt es denn schon neues? Wie weit ist denn die software nun? gruß
Hallo Ludwig, in ein paar Tagen gibt es wieder Neuigkeiten. Die überarbeitete Dokumentation ist so gut wie fertig. Der Code (mit den neuen CRCs) ist ebenfalls fertig. Zum Wochenende hin gibts dann ein Update. Das Funkboard dürfte damit dann über die Betaphase hinauskommen. Die größten Unsicherheitsfaktoren sind nun beseitigt. Ich werde vielleicht ebenfalls am Wochenende mal Kontakt mit Embedded Projekts aufnehmen.
Hallo Florian, das mit embedded Projects wäre wirklich eine super Idee. Ich habe mir ersteinmal Funkmodule (868MHz) gekauft, in den Weihnachtsferien wollte ich mich wieder näher mit den Boards beschäftigen. Und natürlich irgendwann auch mal etwas aufbauen. Grüße Jörg
Neuigkeiten :-) Ab heute ist die überarbeitete Dokumentation online, die übersichtlicher, umfangreicher und leichter in der Handhabung ist. :-) Außerdem ist eine neue Version des Quellcodes online. Damit würde ich nun sagen hat das Projekt die Beta-Phase nun endlich hinter sich :) Oh und, bitte stört euch nicht an dem Datum in der Doku, eigentlich wollte ich sie erst morgen online stellen aber ich war dann doch zu faul das jetzt nochmal umzuändern.
Respekt! Wirklich ein sehr sauberes Projekt! Wie läuft das denn mit dem Terminalprogramm... kann man das in andere Visual Studio Programme miteinbinden? Würde es evtl. gerne als Grundgerüst in ein eigenes Programm einbauen wollen, was ich nach Weihnachten mal anfangen wollte. Ist das einfach zu machen? Ada83
Hallo und danke auch für das Lob :) Prinzipiell ist das natürlich ohne Weiteres möglich und auch dafür vorgesehen. Genau das Selbe habe ich später damit auch vor. Es ist schon eine gute Erleichterung, wenn man bereits die Routinen zum Auslesen der Konfigurationen drin hat und das nicht für ein spezielles Projekt nochmal schreiben muss. Das Programm ist aber nicht alzu dolle programmiert. Besonders die Routine für das Empfangen von Bytes ist momentan mehr provisorisch.
Hallo, auch von mir ein großes Lob. Selten ein so gut dokumentiertes Hobbyprojekt gesehen. Aber mal eine Frage. Nach dem Überfliegen der Doku habe ich gelesen, dass noch ein PIN des Atmega frei ist (PC5?). Könnte man diesen Pin nicht als Interruptquelle in den Betriebsarten I2C und SPI benutzen? Damit wäre es doch möglich auch in diesen Betriebsarten nicht nur zu pollen, sondern dem angeschlossenen µC mitzuteilen, dass neue Daten im Puffer liegen und diese abgeholt werden können. Mich würde ja in erster Linie die I2C Variante interessieren, da meine Schaltung, wo ich mir das Funkmodul gut vorstellen könnte schon 3 I2C Bausteine hat. Wann könnte man denn mit I2C rechnen? Gruß Sven
Hallo Die Idee ist sehr gut! Das wäre mit dem "überschüssigen Pin" machbar, ja. Und damit ein Pollmodus fast hinfällig. Wann es I2C geben wird kann ich leider nicht sagen. Momentan bin ich froh, dass ich die UART soweit abgeschlossen habe. Habe im Moment echt sehr viel um die Ohren. Es ist aber gut möglich, dass sich I2C und SPI noch etwas hinziehen wird. Muss erst wieder Zeit finden, demnächst stehen Prüfungen an, danach Seminare...puh :)
Ich kann nun sicher sagen, dass sich I2C und SPI noch ziehen wird... Ich schätze vor Mitte Februar werde ich da nicht dazukommen. Habe neben Studium vor allem auch noch ein kleines Miniprojekt welches ich noch durchboxen will ;-) Interessant zu wissen wäre auch viele Leute an einer I2C und SPI Lösung interessiert sind. Bisher scheinen die Meisten auf die UART abzuzielen??
Hi Florian, erstmal möchte ich mich den ganzen Lobesreden anschließen ... echt gut gemachtes Projekt =) Zu Schnittstellen: Wenn ich das in der Form nutzen würde, würde ich wohl auch U(S)ART bevorzugen, einfach schon wegen der von Haus aus gegebenen asynchronen Verwendbarkeit. SPI wäre für mich nur interessant, wenn das Modul selber irgendwie Pakete überträgt, so dass ich auf uC-Seite keine Pakete mehr von Hand auseinanderfriemeln müsste (bei USART habe ich ja erstmal normalerweise nur einen Byte-Stream). Wobei ich zugeben muss, dass ich mir das Protokoll bei dir noch nicht genau angeschaut hab ;) Was aus meiner Sicht noch interessant wäre, wäre die Frage, ob man quasi das ganze FW-Seitig relativ einfach in ein eigenes Projekt einbinden könnte, so dass man für den Funkteil kein dediziertes Modul (/Controller) braucht? Grüße, Chris
Christian Illy wrote: > Was aus meiner Sicht noch interessant wäre, wäre die Frage, ob man quasi > das ganze FW-Seitig relativ einfach in ein eigenes Projekt einbinden > könnte, so dass man für den Funkteil kein dediziertes Modul > (/Controller) braucht? Was meinst du mit "FW-Seitig". Komme gerade mit dem Kürzel nicht klar ;-) Wenn ich dich richtig verstanden habe willst du wissen, wie leicht sich der komplette Aufbau+Code, der für ein selbstständiges Board ausgelegt ist, in ein anderes Projekt komplett integrieren lässt? Im Prinzip sehr einfach. Was man beachten muss sind natürlich die Schnittstellen/Pinbelegung und die sonstigen Hardwareressourcen des Ziel-AVRs (Timers etc.). Von der reinen Softwareimplementierung sollte es kaum Probleme geben. Der Programmdurchlauf in der main besteht im Wesentlichen aus einer Init-Funktion und einer Endlos-Schleife die 2 Funktionen beinhaltet. Hier kann man sehr leicht neuen Code hinzufügen, der dann komplett abgekapselt vom Rest arbeitet. Man sollte lediglich darauf achten keine Zeit mit irgendwelchen delays zu vergeuden....
Hi Florian, mit FW-Seitig meinte ich, dass man die Firmware um eigene Funktionen erweitert bzw umgekehrt in eigene Firmware deine Routinen einbaut, damit das eigene Projekt um Funk erweitert wird (eben ohne die dedizierte Funk-Modul-HW von dir ;) ). Gerade bei sehr kleinen Aufgaben könnte ich mir vorstellen, dass man damit etwas an Kosten spart (eg Funk-Temperatur-Sensor). Die Antwort bestätigt das ja schon =) Grüße + schönes Wochenende noch, Chris
Also ich würde mich schon mal für I2C anmelden ;-) Ich bastle seit einigen Monaten an einer Alarmanlage für Einbruch, Brand, Bewegung und noch andere nette Sachen. Da ich allerdings bei den PICs in Assembler zu Hause bin und die UART schon verwendet wird (für RS485) würde ich das Funkmodul über I2C einbinden wollen. Das ganze eilt aber nicht, da es für mich mehr ein Zeitvertreib ist als ein Projekt unter Termindruck. Februar wäre also in Ordnung ;-) Gruß Sven
Ich hätte auch Interesse an einer I2C-Lösung. Die oben schon genannte Sache mit dem Interrupt-Pin wäre wirklich fein. Dann könnte man die Master-Slave-Topologie des Bussystems zumindest etwas "austricksen". Auch bei mir eilt es nicht, würde sowieso erst in einigen Monaten afür Zeit finden. Gruß Paul
Danke für euer Feedback. Das Interesse an I2C und SPI scheint erwartungsgemäß nicht so hoch zu sein wie für die UART. Trotzdem gibt es ja doch einige, für die die Lösung interessant wäre, und das ist ja die Vorraussetzung für die Implementation. Werde auch sehr wahrscheinlich die beiden Schnittstellen noch implementieren. Momentan ist es einfach nur ein Zeitproblem...
Die RS232 ist sicher erst mal wichtiger, da man diese problemlos an den PC bekommt und so erst mal mit dem Modul herumspielen kann. Möchte man das Teil aber durch einen anderen µC steuern würde ich I2C oder SPI für die Kommunikation benutzen. Die RS232 wird ja meist zum Flashen benutzt (bootloader) oder wie in meinem Fall um daraus einen Bus zu machen. Aber noch was anderes: Hier stand die Tage irgendwo, dass es die RFM12 nur noch bei Pollin geben soll. Sterben die jetzt aus? Gibt es einen Nachfolger? Weist du da was genaueres? Wäre ja dumm wenn es die in Zukunft nicht mehr geben sollte. Sven
Hallo Das habe ich auch gelesen und mich beunruhigt das auch etwas. Die RFM12s sind nunmal ziemlich preiswert und es wäre wirklich sehr schade wenn diese nun vom Markt verschwinden würden. Aber sind ja (noch) alles Gerüchte, die meines Wissens teilweise schon widerlegt worden sind.
Die Elektor hat die Dinger in einer der letzten Ausgaben drin, wär mal interessant wo die sie her haben. Ich weiß aber auch, das einige hier aus dem Forum schon direkt in China bestellt haben.
Den Artikel in der ELEKTOR habe ich auch gelesen. Ich denke nun nicht, dass die ELEKTOR einen Artikel über ein Produkt bringt, welches zu dem Zeitpunkt schon "vom Aussterben bedroht" ist.
ein anderes projekt... http://www.ulrichradig.de/home/index.php/avr/usb-funk http://shop.ulrichradig.de/product_info.php?cPath=23_25_31&products_id=105 und wenn schon seriell... warum nicht gleich... http://shop.ulrichradig.de/product_info.php?cPath=23_25_31&products_id=129
gibt es denn schon mehr bilder von den Modulen um sich einen besseren eindruck darüber machen zu können? Leider sind auf der Webseite immer noch keine verfügbar. gruß Ralf
@ Ralf Ja, einige Bilder werde ich bald online stellen sobald ich dazu komme :) Die Platine von Alex W. sieht gut aus ;)
Ich kann mich komischerweise nicht mehr im µ-Forum anmelden? Nunja... Also bezüglich der RFM Module habe ich mit deinem Vertriebler von HOPERF aus China geredet. Quasi direkt mit der Quelle. Er hat mir zugesichert, dass die RFM Module definitiv NICHT vom Markt genommen werden. Auch Pollin ist und bleibt ein Distributor dieser Module. Ich werde das auch noch einmal in einem extra Thread aufmachen, da ich schon einige Mails wegen der Thematik bekommen habe. An diewser Stelle auch einen herzlichen Dank an den User 'embedded', der mir die E-Mail-Adresse gegeben hat. Leider kann ich momentan keine PMs bearbeiten wegen meinem Login-Problem.
Hallo Florian, finde dein Projekt super. Nach genau soetwas habe ich gesucht. Ich hätte da eine Frage wegen dem MAX3221. Kann man da auch andere MAX-ICs verwenden oder muss es genau dieser Typ sein? Habe noch massenhaft andere Typen (MAX232) rumliegen und würde diese gerne verwenden wenn das möglich wäre... der Morgenmuffel
Es ist auch möglich andere Typen zu verwenden. Den MAX3221 habe ich desshalb verwendet, weil er die Aktivität des RX-Pins der Gegenstelle (zum Beispie ein PC) überwacht. Das eröffnet die Möglichkeit, den MAX bei nicht angeschlossener Gegenstelle zu deaktivieren. Außerdem lässt ishc der IC auch manuell über Steuerleitungen deaktivieren. Solche Möglichkeiten bietet ein "normaler" MAX232 einfach nicht. Will man die RS232 sowieso nicht verwenden kann man den MAX natürlich einfach weglassen. Will man nur die RS232 verwenden, so kann man einfach an RX/TX des AVRs den MAX232 klemmen. Die Anschlüsse INVALID, FORCEON, FORCEOFF sind dann irrelevant. Es reicht INVALID irgendein festes Potential zu spendieren. Will man RS232 und TTL UART verwendet wirds kniffliger. Entweder man löst alles über Jumper oder man nimmt zumindest einen MAX3222. Der lässt sich wenigstens noch manuell deaktivieren. Dann kann man den INVALID-Eingang am AVR mit Jumpern zu GND/VCC nachbilden und den ENABLE, der für den MAX3221 gedacht ist an den MAX3222 hängen. Sollte genauso funktionieren. Hoffe es ist etwas klarer geworden. Das Datenblatt des MAX3221 hilft auf jeden Fall weiter.
Moin zusammen, ich habe die Sammelbestellung für das Board verpasst. Ich würde das Board aber gerne nutzen. Mir ist die Boardgröße nicht ganz so wichtig. Daher würde ich auch ein einseitiges Board nutzen. Ich bin aber beim routen und designen von Platinen absolut unerfahren - daher frage ich hier, ob es schon Leute gibt, die die Schaltung auf eine einseitige Platine gebracht haben? Gruß Martin
Hallo Pr0gm4n bin vor kurzem dazu gestoßen. Wie weit ist Deine Sammelbestellung gediehen? Kann man sich noch beteiligen? Gruß Altprog
Moin, > bin vor kurzem dazu gestoßen. Wie weit ist Deine Sammelbestellung > gediehen? Kann man sich noch beteiligen? Ich hatte Ihn angeschrieben und war schon zu spät. Das scheint schon gelaufen zu sein - schade!
Hallo, sieht gut aus , das Modul ich bin im Moment dabei auch so etwas ähnliches zu machen. Gibt es eine Sammelbestellung für Platinen, hätte Interesse. Gruß Altprog
Gute Nachrichten! :) Ich habe ein Angebot eines Webshops erhalten (Name und Adresse möchte ich zunächst nicht nennen, da hier noch keine Nägel mit Köpfen gemacht werden), die mir anbieten die Funkboard-Hardware in Ihrem Webshop zum Verkauf anzubieten. Das ist natürlich eine sehr tolle Sache und sicherlich für einige hier attraktiv :) Gerade in den letzten Beiträgen kam die Frage dazu ja wieder auf. Bis zur Umsetzung würde es allerdings mindestens noch einen Monat oder länger dauern. In dieser Zeit bin ich doppelt froh um jedes Feedback! So kann schon vor dem eventuellen Verkauf ein gewisses Maß an Qualität durch andere User gewährleistet werden, was sicher im Interesse aller ist :-) Es trudeln immer mal wieder Feedback-E-Mails bei mir ein. Es wäre schön, wenn das so bleibt oder auch mehr werden. Eure Erfahrungen fließen direkt in das Projekt mit ein. So, dann noch wegen den Sammelbestellungen: Die laufen komplett ohne meinen Eingriff. Anfragen dazu also am besten direkt an die User hier schicken :-) Gruß Florian
Hallo Florian, gut Ding will Weile haben. Ich wäre auf jeden Fall an einem Board über einen Shop interessiert. Eine Sammelbestellung, die hier parallel zu dem Shop laufen würde, käme für mich nicht so in Frage. Da bei mir im Moment noch andere Projekte (schleppend) laufen (Dachbodenausbau, Rollosteuerung, AVR-Kamera), reicht mir die Aussage, dass es in absehbarer Zeit etwas "Offizielles" in einem Shop geben wird. Die Funkmodule (886MHz) habe ich zwar bereits in der Schublade, aber kurzfristig noch keine Zeit die mal (per STK500 o.ä.) anzuschließen, d.h. viel Unterstützung werde ich nicht leisten können (abgesehen von meiner fehlenden Kompetenz:-) Aber ich hoffe bei den anderen sieht es zeitlich besser aus... Grüße Jörg
eine tolle sache! wäre auch an dem board über den webshop interessiert.
Hallo Leute, ich habe mir die Software von Flashcraft.de mal runtergeladen. Mein AVRStudio prangert eine nicht gefundene Funktion namens configuration_status(unsigned char send_status) an. Die ist in Global.c extern deklariert aber in der configuration.c ist sie nicht zu finden. hab ich was verpeilt oder ist da ein Fehler ??
ok hat sich erledigt, ein c file war nicht mit eingebunden
Hallo, ich habe mehrere DIP RFM 12 Module zuhause liegen, und jetzt wollte ich fragen, ob es vielleicht auch eine DIP-Version geben könnte. das wäre super... sonst muss ich probieren mir selber eine platine zu machen. Ist es eigentlich eine schlechte idee sich die platine selber zu ätzen?, oder sollte sie schon professionell erzeugt werden?
Hallo Daniel, ich habe mit ein paar Leuten Kontakt gehabt, die vor hatten eigene Leiterkarten zu entwerfen. Teils für reine THT-Bestückung, teils für Mischbestückung, genaue Details kenne ich da selbst nicht. Einige meinten, dass sie Ihr Design evtl. als OpenSource bereitstellen würden. Allerdings kenne ich nichts genaueres, ob momentan damit Leute beschäftigt sind oder ob es bei dem Vorhaben blieb. Zur Not muss man dann doch selbst Hand anlegen. Selbst ätzen ist eigentlich kein Problem. Solange man seine benötigten Strukturbreiten schafft geht das natürlich. Das Design ist da nicht so anspruchsvoll. Viele hier (ich auch) haben mit einem Steckbrettaufbau begonnen. Und die parasitären Effekte darauf kann wohl keine selbstgeäzte Leiterkarte noch toppen ;-)
Hallo! Ich bastel derzeit an etwas das eine Drahtlose UART Verbindung benötigt. Das "Funkboard" ist genau das was ich suchte, vielen dank! Da aber RS232 uninteressant für mich ist bin ich gerade dabei ein Reines RFM12 Board mit Mega32 und FTDI-USB Wandler zu entwerfen, auf der andern Seite befindet sich dann ein RFM12 mit Mega32 und RS485 Baustein. Hat sich vielleicht schon jemand soetwas gebaut? Mfg, Peter
Angehängte Dateien:
-
IMG_2288.jpg
180 KB
Peter F. wrote: > Hallo! > Ich bastel derzeit an etwas das eine Drahtlose UART Verbindung benötigt. > Das "Funkboard" ist genau das was ich suchte, vielen dank! > > Da aber RS232 uninteressant für mich ist bin ich gerade dabei ein Reines > RFM12 Board mit Mega32 und FTDI-USB Wandler zu entwerfen, auf der andern > Seite befindet sich dann ein RFM12 mit Mega32 und RS485 Baustein. > > Hat sich vielleicht schon jemand soetwas gebaut? > > Mfg, > Peter USB mit RFM12 gibt es schon knapp ein Jahr von mir! Falls Interesse an solch einem Modul bzw der Platine besteht, könnt Ihr mich auch anschreiben. Ich bin auch dabei ein Prototyp mit dem RFM12BP zu entwickeln. Amateurfunker können dann ganz ganz einfach ein "PacketRadio" bauen. Ist halt ein anderes Übetragungsverfahren, aber mit 115kb. Die 10mW-Variante arbeitet seit 10 Monaten einwandfrei (Modem im Auto und im Haus, beim herfahren Protokollaustausch und Türöffner an der Eingangstüre ist angezogen...) Wenn sich genügen Leute finden lassen, kann ich auch mal ne Serie bestellen.
Hallo, da ich auch gerade an solchen Modulen interessiert bin, würde ich gerne näheres erfahren. USb-Anschluß wäre super. DC9JG (altprog)
Alternativ geht auch ein USBprog + RFM12. Ist halt möglicherweise nicht ganz so billig, dafür auch für andere Zwecke verwendbar.
Hallo! Alex W. (a20q90): Falls ich mich für deine Lösung entscheide lass ich von mir hören ;) Nen USB-Prog habe ich hier, nur noch keine RFM12, ich habe mir Florians Schaltplan mal genau angeschaut und habe ein paar Dinge gefunden die ich nicht verstehe bzw nicht in der Doku finde: Wofür ist der Jumper von PC4 zu VCC gedacht? Der 10k Pullup am Pin3 (FSK) des RFM12 aktiviert/deaktiviert den fifo des Moduls? Sollte man dem RFM12 nicht noch nen 100nF Kondensator spendieren? Vielen Dank schon einmal! Mfg, Peter
Angehängte Dateien:
-
transmitter.jpg
61 KB
Ahoi Hoi. Ob es so auch wirklich funktioniert kann ich nicht sagen, das wird sich zeigen wenn ich die Platine hab ätzen lassen. RFM-12 mit FT232 und Mega32 in THT, Quartz und USB-Buchse sind leider nicht mitgerendert, PovRay kennt die wohl nicht. Warum? Ich mag THT, SMT ist zwar schön aber irgendwie nicht mein ding ;-) Leider etwas groß aber irgendwas ist ja immer. Mfg, Peter
Nach langer Zeit melde ich mich auch einmal wieder zu Wort... Definitiv gibt es noch einige kleine Bugs. Habe mittlerweile eine Liste zusammen, die ich sobald ich Zeit finde ausmerzen möchte. Im Großen und Ganzen nichts gravierendes, aber auch Kosmetik muss sein ;) Der versäumte 100nF C am RFM12 gehört auch dazu. Dachte zunächst, dass ich ihn nur im Schaltplan falsch platziert habe, aber er fehlt wohl komplett. Kommt noch rein. Die Lösung mit dem FT232 finde ich super! Ähnliches habe ich mir auch schon einmal überlegt, aber mangels Zeit wieder verworfen. Vielleicht könnte man sich da ja mal kurzschließen, eine PM hast du jedenfalls einmal Peter ;) Werde vermutlich Anfang März wieder genug Zeit finden um das Projekt auf den neuesten Stand zu bringen.
So, ich habe mir nun vorgenommen, das bestehende Projekt um ein USB-Interface zu erweitern. In Zusammenarbeit mit Peter F. gibts dann vielleicht in absehbarer Zeit neben der bisherigen Version eine weitere mit USB :)
Hallo, plant jemand eine Sammelbestellung zu dem wirklich gelungenen Funkboard von Florian Scherb? Hätte großes Interesse :) Gruß Frank
Angehängte Dateien:
-
funk-usb.jpg
74 KB
Frank Spliethoff wrote: > plant jemand eine Sammelbestellung zu dem wirklich gelungenen Funkboard > von Florian Scherb? > > Hätte großes Interesse :) Es muss nicht unbedingt ein fertiges Board sein ;-) Wenn man nicht unbedingt auf die größe achten muss kann man das ganze auch sehr einfach auf Lochraster Zaubern, siehe Anhang. Florians Funkboard auf Lochraster inklusive USB-Interface (FT232 in grundbeschaltung nach Datenblatt). > Gruß > Frank Mfg, Peter
Hallo Florian! Zur info, du hattest in diesem langem thread ja mal nach feedback gebeten: Hatte deinen code schon mal runtergeladen, dank einiger fehler habe ich mich dann mit einem anderen code (rs-232 von benedikt) gespielt. Jetzt wollte ich mir aber auch mal dein werk ansehen, also nochmal runtergeladen, aber fehlerfrei kompiliert bei mir leider nix. geladen habe ich diesen hier: funkboard_quellcode_090109.rar das ganze mit - avr studio 4.16 build 628 - winavr20090313 geöffnet und kompiliert. Erst wurde bemängelt das eine configuration_status funktion fehlen würde, die ist auhc in der global.h definiert. diese habe ich dann in /misc/status_register.c gefunden und einfach unten in der configuration.c angehängt. nächster fehler: die funktion configuration_clkfrequency(void); wird in configuration.c erst implizit durch einen aufruf definiert, dann kommt die funktion weiter unten auch, steht aber in auch nicht in der global.h, also dort hinzugefügt: extern void configuration_clkfrequency(void); anschließend kompiliert mal alles fehlerfrei, warnings gibts es aber 19 stück. die sind mir jetzt mal egal, erst baue ich den code für die 868mhz version der module um, dann schau ich mir das weiter an! Grüße, Martin.
Hallo Florian, Auch von mir ein großes Lob: Projekt und Doku machen einen sehr guten Eindruck. Gibt's was neues zum Funkboard? Zum Modul mit und ohne USB? Ich habe mir die Eagle-Daten (Schematic und Layout) runtergeladen. SCH und BRD sind nicht konsistent. Ist das Absicht oder wirst Du die Daten noch aktualisieren? Im BRD sind Leitungen aus einzelnen Elementen zusammengesetzt, die unterschiedliche Namen haben. Liegt das daran, weil ich das BRD mit Eagle 5.5 öffne? Oder ist das so gewollt? Macht es Sinn, diese Platine herstellen zu lassen oder gibt es bald ein Update (evtl. mit USB)? Viele Grüße und Danke für die Mühe Der Manuel
Super Sache dein Funkboard, Florian Ich habe mich mit dem Funkmodul RFM12 beschäftigt und bin so zu einem Projekt gekommen. Nun interresiert es mich ob es eine Ätzbare Version gibt? Oder ob es jemand zufällig neu geroutet hat? Ätzbar bedeutet für mich: -Durchkontaktierungen durch selbstgelötete Silberdraht ersetzbar -Stiftleisten/Quarz etc. nur von der "unteren" Seite anlötbar -Doppelseiteig/Einseitig wäre dann egal
Hallo Florian Scherb, Deine Projektseite ist down: http://www.flashcraft.de ...laut denic aber noch in Deinem Besitz. Kannst Du hier mal für die Nachwelt den letzten Stand ins Forum uploaden? (Doku, Source Code, Layout) Danke
Hallo an alle, leider fehlt uns ja noch das aktuelle Terminalprogramm 1.0.2. Ich hatte heute mit Florian einen kurzen Kontakt (ist momentan voll im Streß), er hat mir zugesagt in 2 Wochen die Daten zu senden. Sobald die zur Verfügung stehen gibt´s ´nen Link. mfg Bernd
Bernd Jung schrieb: > Ich hatte heute mit Florian einen kurzen Kontakt (ist momentan voll im > Streß), er hat mir zugesagt in 2 Wochen die Daten zu senden. Sobald die > zur Verfügung stehen gibt´s ´nen Link. Hat er gesagt warum die Website down ist? Mfg, Peter
immer noch keine neuigkeiten??? Das ist echt schade. Erst wird man auf das Projekt durch den Artikel in Embedded Projects Journal heiß gemacht und dann gibts nirgends informationen dazu :-( schade naja ... weiter warten
Servus! Da ich es schon sehr oft erlebte, dass Informationen, die man im Internet erhält, jederzeit weg sein können, hab ich von diesem Projekt natürlich alles abgespeichert. So wie zum Beispiel die vielen "Mini-Projekte" von Elektor, die es als .pdf gratis zum Downloaden gab. Da hatte ich vor 4 Jahren verabsäumt sie zu speichern. :( (siehe Beitrag "Elektor-Miniprojekte" ) Aber hier Bitteschön, für Euch im Anhang, sind alle zu dem Projekt zugehörigen Dateien. Gruß Daniel M.
danke die... genau so bin ich sonst auch .. aber die seite war ja schon off bevor der artikel raus war :-(
danke dir... genau so bin ich sonst auch .. aber die seite war ja schon off bevor der artikel raus war :-( grüße Martin
Peter F. schrieb: > Hat er gesagt warum die Website down ist? > > Mfg, > Peter Hi, Providerprobleme. Q amad Danke für den Anhang. Wie ich vermutet hatte, ist der Link auf seiner Seite zum Download des Terminalprogrammes noch auf die Version 1.0.1 gesetzt; dementsprechend wurde auch nur diese Version gesichert. Was uns fehlt ist die 1.0.2 vom 23.11.2008 in dem die Bugfixes am DTR-Pin beseitigt sind. mfg Bernd
Servus! Das ist seltsam mit der Version 1.0.2 vom 23.11.2008, denn ich habe die Sicherung am 04.07.2009 gemacht. Eventuell hatte er zu dieser Zeit eine alte Kopie seiner Seite hochgeladen gehabt. Da ja ohnehin der Sourcecode vorhanden ist, spricht aber nichts dagegen, den Fehler selbst auszubessern. ;) (Das Visual Studio Express fürs Kompilieren bekommt man ja sogar gratis.) Gruß Daniel M.
Hallo Florian and all. Gibt es Neuigkeiten über dein Projekt, würde mich 'brennend' interessieren :) Habe ich es überlesen oder ist die Idee einen Bausatz bzw. ein fertig 'montiertes' Element in einem Webshop anzubietenim Sande verlaufen ? Als Anfänger gestattet mir bitte noch die folgenden 'dummen' Fragen : Könnte ich dein Funkboard auf der Empfängerseite so an einen weiteren MC anbinden wie bisher bei mir den Max232 und die empfangenen Daten per UART wie gehabt über Kabel RS232 handhaben ??? MfG und danke im Voraus, Oliver.
Hallo! Ich hab Florian mal angeschrieben und gefragt wie es um das Projekt steht, hier die kurzfassung aus zwei Emails, zusammenkopiert: > Das Projekt ist definitiv nicht tot. Ich werde mein Bestes geben! > (...) > Ich werde die Arbeit an dem Projekt sehr wahrscheinlich (im Rahmen > meines Studiums) wieder aufnehmen. > (...) > Dadurch wird auch der Code erweitert und verbessert werden. > (...) > Ich habe mich auch wieder daran gemacht die Webseite online zu bekommen. > Ich kann dir leider nicht sagen wie lange das dauern wird mit der > Webseite. (...) > Ich denke, aber dass ich relativ schnell jemanden finden werde. Aber mit > ca. 2 Wochen sollte man mindestens rechnen. Das hört sich doch ganz gut an, bis dahin also noch etwas warten ;-) Grüße, Peter
Hi, Leider ist die Seite noch immer off... War sie zwischendurch schon mal wieder online? Oder ist das Projekt jetzt wirklich gestorben? Wäre schade, ist ein super Projekt... Grüße Rudi
ich hab irgendwann mal an Florian geschrieben und auch von Ihm die Antwort bekommen, das er die Seite wieder online stellen will. Leider ist das schon ne ganze Weile her. Ich glaube mitlerweile nicht mehr daran, das die Seite noch mal wieder online geht. Vielleicht sollte man einfach das vorhandene Wissen zusammentragen und hier einen Artikel im Wiki erstellen?
Oder einfach die vorhandenen Seiten ergänzen: RFM12 AVR RFM12 RFM12 Protokoll Stack Pollin Funk-AVR-Evaluationsboard
Leider sieht es so aus.... echt schade. Für alle die trotzdem etwas von diesem Projekt haben wollen... Im Anhang findet ihr die benötigten Informationen. grüße martin
Würde auch die Möglichkeit bestehen, anstatt eines ATMega32 einen Atmega 48 zu benutzen? Ich benötige nur die UART Schnittstelle. Ein ATMega16 sollte doch auf jeden Fall gehen, oder?!?
Angehängte Dateien:
-
rfm12.png
18 KB
Hallo zusammen, hat sich nochmal jemand mit diesem Projekt beschäftigt und kann mir helfen? Ich bekomme das Board nicht zum laufen: Brick wall Ich übergebe dem Funkboard von einem Board mit einem ATMega128 die Werte 55 f0 48 61 6c 6c 6f in hex, so wie es im Quickstart Manual von Florian steht. Die Werte werden über die USART0 gesendet. Ich habe testweise einen max232 dazwischen gehangen und die Werte mit einem Terminalprogramm abgefragt. Es kommen genau die gewünschten Werte an! Also liegt es nicht an meinem sendenden Board! Dann zum Funkboard. Zuerst habe ich die lee Datei gebrannt und dann die hex File. Lege ich Spannung an, leuchten die 3 LEDs kurz auf und dann leuchtet die PowerGood LED dauerhaft. Soweit alles wie im Handbuch. Verbinde ich jetzt aber das Funkboard mit meinem ATMega128 Board leuchtet keine der RX/TX LEDs beim senden auf. Ich lege den MDSEL_pin vorher auf 0. Eigentlich sollte eine der LEDs ja beim senden flackern. Ich verwende ein selbst geätztes eigenes Funkboard mit einem ATMega32 DIL. Die Fuse Bits des ATMega32 have ich so: Highfuse: 0xD9; Lowfuse: 0xDF Danke für eure Hilfe!
Hast du denn generell die Funktionsfähigkeit deines selbst geätzen Boards getestet? Also ne eigene Hex aufspielen, die bei eingehenden UART befehlen mal die unterschiedlichen LEDs zum Leuchten bringt. Um auszuschließen, dass die UART Kommunikation auf deinem eigenen Board klappt und das der Atmega sie auch versteht. Baudrate 9600 8N1 alles soweit korrekt und kontrolliert am PC, gehe ich mal von aus. Hast du den wie beim Schnellstart beschrieben über MDSEL = 1 und 0x00 0x00 senden versucht das Statusregister auszulesen? Passiert dabei etwas? Soweit mal ein paar Denkanstöße, Andun
Also das Statusregister habe ich noch nicht ausgelesen, werde ich aber mal versuchen. 9600 8N1 stimmt soweit. Werde dann mal berichten ob ich das Statusregister ausgelesen bekomme.
Morgen, gibts mittlerweile mal wieder was Neues zu diesem Projekt? Mal nen neuen LP oder SW stand? Die Seite ist ja nun schon fast ein Jahr down. Die Dateien (brds) sind ja fehlerbehaftet. Hat sich irgendwer mal intensiver damit beschäftigt und mal eine lauffähige Version gebastelt? Grüße
Mark P. schrieb: > gibts mittlerweile mal wieder was Neues zu diesem Projekt? > Mal nen neuen LP oder SW stand? > > Die Seite ist ja nun schon fast ein Jahr down. > Die Dateien (brds) sind ja fehlerbehaftet. > Hat sich irgendwer mal intensiver damit beschäftigt und mal eine > lauffähige Version gebastelt? Ich hab mehrere lauffähige Versionen hier im betrieb. Die letzte Firmware die ich hab hatte 2 fehler, einen hab ich gefunden, den andern, mit dem lebe ich ;-) Für mich ist es zu spät ein anderes Funkmodul zu verwenden, deshalb werd ich das mittelfristig auf meine eigene Seite nehmen und Forken.
Terfagter schrieb: > Also das Statusregister habe ich noch nicht ausgelesen, werde ich aber > mal versuchen. > 9600 8N1 stimmt soweit. > > Werde dann mal berichten ob ich das Statusregister ausgelesen bekomme. Dazu sollt man sagen, die letzte Firmware die ich von der Seite hatte kennt den Befehl zum Status Register auslesen nicht! Grüße, Peter
kann jemand mal eine aktuelle und fehlerfreie version der software posten?
Hallo, mich würde auch ein lauffähiger Softwarestand interessieren. Hat jemand das Modul erfolgreich als Funkbrücke eingesetzt? Mfg HP
Hat das Board schonmal bei einem von euch funktioniert? Ich würde mir das Board gerne selber aufbauen und ätzen, aber vorher würde ich schon ganz gerne wissen, ob sich der Aufwand lohnt! Welche Version funktionierte?
Hallo, es ist bei mir schon eine Weile her, dass ich es eingebaut habe, aber ich benutze die Kombination als Funkbrücke. Ich habe meine Erkenntnisse hier zusammengefasst: http://www.subms.de/2009/09/17/flashcraft-funkboard/
Johannes Kreuzer schrieb: > Hallo, > > es ist bei mir schon eine Weile her, dass ich es eingebaut habe, aber > ich benutze die Kombination als Funkbrücke. > > Ich habe meine Erkenntnisse hier zusammengefasst: > > http://www.subms.de/2009/09/17/flashcraft-funkboard/ Funktioniert eigentlich bei euch noch die Seite vom TO?
TO??? Also die flashcraft.de Seite geht ja schon seid längerem nicht. Welche Seite meinst du?
Johannes Kreuzer schrieb: > TO??? > > Also die flashcraft.de Seite geht ja schon seid längerem nicht. Welche > Seite meinst du? TO= Thread Openener Ja genau die meinte ich. Hab jetzt zwar nicht explizit gesucht, aber gibts da noch irgendwo Unterlagen und Code drüber? Gruß, Sven
Martin J. schrieb: > Leider sieht es so aus.... echt schade. > > Für alle die trotzdem etwas von diesem Projekt haben wollen... > Im Anhang findet ihr die benötigten Informationen. > > grüße martin In diesem Beitrag etwas weiter oben in diesem Thread. (Namen von Martin J ist ein Link dahin)
Dankeschön! Auch wenns jetzt so aussieht als ob ich zu faul zum suchen oder lesen war;)
Hallo zusammen, ich habe das Funkboard auf einem Steckbrett aufgebaut. Als Prozessor benutze ich den ATMega32 und ich verwende keinen Max sondern habe eine direkte Verbindung zu einem anderen ATMega32. Wenn ich die Spannung jetzt zuschaltet, leuchten alle drei LEDs kurz auf und danach leuchtet nur noch die "Power-Good"-LED. Der andere ATMega 32 sindet jetzt alle 3 Sekunden den String aus dem QuickStart-Dokument von Florian. 0x55 0xFo 0x48 0x61 0x6C 0x6C 0x6F Der String kommt auch beim ATMega des Funkboards an, aber die Transmitt-LED zeigt nichts an. Auch auf den Pins NSEL, SCK, SDI, SDO des RFM12s wird etwas übertragen, alle 3 Sekunden, wenn ich sende (Oszi). Ich habe versucht das Statusregister auszulesen, aber da kriege ich überhaupt keine Antwort. Ich weiß, dass das Auslesen nicht funktioniert, aber ich habe gelesen, das schon irgendeine Antwort zurück kommt. Das gleiche Problem hatte ich auch schon, als ich mir alles auf einer selbst geätzten Platine vor einiger Zeit aufgebaut hatte. Der mdsel-Pin liegt über einen 2,2MOhm-Widerstand auf +5V. Die Fuses sind so gesetzt: hfuses: 0xD9 lfuses: 0xDF und es ist auch kein JTag aktiviert. Ich habe erst die eeprom-file gebrannt und dann die hex-Datei. Beides habe ich nicht verändert. Die Baudrate meines sendenden ATMegas ist 9600 und die des Funkboard-ATMegas sollte ja auch standartmäßig bei 9600 liegen. Warum zeigen die Übertragungs-LEDs nichts an? Was kann ich noch überprüfen? Ich bin langsam etwas ratlos! Vielen Dank für eure Hilfe.
Moin Also so wie es sich jetzt für mich anhört, kannst du also gar nicht mit deinem Atmega32 kommunizieren, oder? Dann würde ich vorschlagen, dass du dir ein kleines Programm schreibst und flasht, dass nur die Kommunikation testet. (Also z.B. jede Sekunde einen Satz ausgeben oder bei eingehenden Zeichen eine LED togglen) Damit könntest du erstmal ausschließen, dass es an deiner Schaltung liegt. Die Software des Funkboards ist für solche grundlegende Fehlersuche eher weniger geeignet. Ich hab mal zwei Programme angehängt, die ich für so etwas benutzt habe. (Ich habe jedoch damit das Funkboard angesprochen, als es lief, aber das Prinzip ist das gleiche) Du musst natürlich im makefile die CLK und in main.c evtl die Baudrate anpassen. Einfache Fehler wie eine falsche CLK, aufgrund falscher Fuses oder Crystals kann man so auch mit einer Uhr aufdecken und einer toggelnden LED. Viel Erfolg
Also, ich habe jetzt einen max232 direkt an RX/TX des ATMega32 des Funkboards angeschlossen und sende von einem Terminalprogramm aus, Auf den ATMega habe ich dein Programm (Johannes Kreuzer) gebrannt und natürlich vorher im makefile den atmega32 und 8Mhz eingestellt. Es passiert aber nichts. Das verwundert mich jetzt noch mehr. Mit dem Oszi sehe ich das die Daten am ATMega ankommen, es üpassiert aber trotzdem nix. Ich habe dein Programm auch mal soweit abgeändert, das der ATmega mir alles direkt als Echo zurück sendet. Er sendet aber nur ein Leerzeichen zurück?!? Die Baudrate von 9600 habe ich gelassen.
Ich nehme es zurück: Er sendet überhaupt nichts zurück!
So nach einigem Hin und Her funktioniert jetzt die Kommunikation zwischen Terminalprogramm und Funkboard problemlos. Die LED lässt sich auch am Board toggeln, wenn ich ein bestimmtes Zeichen über das Terminalprogramm sende. Eigentliche Software wieder aufgespielt: Jetzt sende ich über das Terminalprogramm den String aus dem QuickStart-Dokument, es wird aber trotzdem keine Aktivität angezeigt. Mit dem Terminalprogramm vom Foob kann ich auch zum Board connecten, wenn ich den MDSEL-Pin auf High ziehe. Was könnte ich denn sonst noch probieren? Die Transmitt-Aktivität der LEDs wird aber auch angezeigt, wenn kein zweites Board in der Nähe ist oder? Leuchtet die LED auch, wenn z.B. das RFM12 kaputt wäre?
Hallo, also kannst du jetzt auch die Konfigurationsregister auslesen und schreiben etc? Das wäre ja schonmal ein gutes Zeichen! Ich muss gestehen, dass ich im Moment nicht in der Materie drin bin, dass ich dir die Funktionsweise genau wieder geben kann. Dafür müsstest du sonst mal in den Quellcode des Funkboards schauen. Vielleicht kann dir jemand anderes dabei aber auch helfen.
Hallo, ihr da Ich bastele auch am Funkboard rum und habe mir Platinen gewrappt. Leider habe ich nirgendwo etwas über bekannte Fehler finden können, deshalb hier für alle meine Funde im Klartext: 1. Statusregister geht nicht Im downgeloadeten Sourcecode ist zwar eine Datei 'status_register.c' vorhanden, sie ist aber nicht ins Projekt eingebunden. Dazu (im AVR-Studio) im linken Fenster rechten Mausklick auf 'Source Files' und 'Add existing Sourcefile' auswählen und Datei zufügen. Neu kompilieren, ein Fehler weniger. 2. Das Terminalboard Hier ist die Leitung RTS unmittelbar verbunden mit dem Resetpin des ATMega. Bei einer Standard-RS232 Schnittstelle hat diese Leitung jedoch keinen TTL-Pegel. Hier muß unbedingt wie bei der DTR-MDSEL-Leitung ein Pegelwandler hin, wenn man neben den drei Leuchtdioden nicht auch noch einen Leucht-AVR haben möchte. Leider funktioniert das Terminalprogramm trotzdem nicht (Funkboard not connected). In der Quelldatei 'Initialize.c' habe ich die beiden Zeilen configuration_saveineeprom und configuration_loadfromeeprom auskommentiert, da beim ersten programmieren die eigene ID noch auf FF steht. Stattdessen gebe ich den beiden boards erst mal feste Adressen (gbl_config_idown = 1 bzw. 2). Wenn ich also von Board 1 zu Board 2 senden will, lauten die ersten beiden Bytes also 02 00, gefolgt von einigen wenigen ASCII-Zeichen. Hat der MDSEL-Pin 5V-Pegel, flackert auch die Sende-LED kurz auf, aber nicht immer, warum nicht, weiß ich auch nicht. Beim anderen Board flackert auch die Empfangs-LED kurz auf, an der seriellen Schnittstelle kommt die Nachricht manchmal ganz, häufiger in Bruchstücken oder gar nicht an, dafür gelegentlich aber die vorletzte (!) Nachricht. Ich vermute eine Macke in den FIFOs. Leider sind meine Kenntnisse in C ähnlich ausgereift wie in anderen C-Sprachen (Chilenisch, Chinesisch...) und es wäre toll, wenn mal ein Insider einige Augen darauf werfen könnte. Ok, das wars fürs erste, Gruß, Wen
Sorry, muß mich korrigieren: Im normalen Sende/Empfangsbetrieb muß der MDSEL-Pin auf 0V liegen. Wen
Also ich bin nicht weiter gekommen, bei meinem Problem. Wenn ich in Foobs Terminalsoftware "Update Terminal" drücke kommen diese Fehler rechts im Fenster: Connection to Funkboard okay! Device ID: 255 Channel number: 255 Startbyte: 255 DQD: 7 RSSI: -61dBm Bandwidth: ERROR RF12 baud: ERROR LED state: False Erscheint das bei euch auch? Hat noch jemand eine Idee?
Und wenn ich versuche das Statusregister auszulesen, also bei MDSEL=high 0x00 0x00 sende, dann kommt nur 0xB0 0x1A zurück! Das kommt aber auch zurück wenn ich irgendwas anderes sende und der MDSEL ist auf high...
Nabend, Hat noch jemand eine Platine oder ein ein fertiges funkboard das er mir verkaufen kann? Dann kann ich vllt besser verstehen wo mein Fehler ist. Oder wüsste sonst jemand wie ich noch vorgehen könnte um den Fehler einzugrenzen?
Langsam erreicht das Frustrationslevel seinen Höhepunkt. Ich habe mir eine fertige Platine von jemandem besorgt, der mal die Sammelbestellung durchgeführt hat. Hab dann ein neues! RFM12 Modul und einen neuen ATMega32 genommen und das Board aufgebaut. Ich habe aber keinen Max und auch den Spannungsregler nicht mit aufgebaut. Dann habe ich die Fuses auf 0xD9 (hfuses) und 0xDF (lfuses) eingestellt. Dann habe ich die FUNKMODUL.eep vom 19.01.2009 gebrannt und dann die FUNKMODUL.hex auch vom 19.01.2009. Nachdem ich dann die Versorgungsspannung aus- und wieder eingeschaltet habe, leuchten die LEDs ca. 1 sec auf und dann leuchtet nur noch die PowerGood-LED. Also genauso wie bei meinem auf Steckbrett aufgebautem Board auch. Ich setzte jetzt einen MAX232 dazwischen. Dann starte ich das Terminalprogramm und klicke unter "Commands(Prompts)" auf "Check connection to Funkboard". Als Antwort erhalte ich Connection to Funkboard okay! Ich kann auch auf "Software-Reset" beispielsweise klicken, dann startet das Board auch neu. Die meisten Sachen funktionieren nicht, aber das ist ja bekannt! Z.B. kann ich unter "Command(Settings)" auf Update Terminal! klicken und als Antwort erhalte ich: Device ID: 16 Channel number: 255 Startbyte: 255 DQD: 7 RSSI: -61dBm Bandwidth: ERROR RF12 baud: ERROR LED state: False Also kann man ja sagen, dass eine Kommunikation generell zwischen PC und Funkboard stattfindet und funktioniert. Wenn ich das Statusregister auslesen will (Ich sende 0x00 0x00) und den MDSEL-Pin auf 5V lege, erhalte ich als Antwort: 0x1A 0xB0 Ob das die richtige Antwort ist, sei mal dahin gestellt, aber es antwortet. Sende ich jetzt vom PC aus 0x55 0xF0 0x48 0x61 0x6C 0x6C 0x6F (Ohne CR, LF, 0 oder sonst was) passiert nichts. Es leuchtet keine der LEDs kurz auf. (MDSEL ist natürlich auf low!) Ich habe auch versucht mit einem anderen ATMega8 diese Bytefolge jede Sekunde einmal zu senden, es leuchtet aber auch hier keine LED auf. Es wäre schön, wenn mir jemand helfen könnte oder mir zumindest sagen könnte, ob es so ähnlich bei ihm ist?!?
Hallo, also ich habe - wie auf meiner Seite beschrieben www.subms.de - das Funkboard in Betrieb. Also meine Ausgabe vom "Flashcraft Funkboard Terminal" lautet: (MDSEL=1) Connection to Funkboard okay! Device ID: 16 Channel number: 5 Startbyte: 35 DQD: 3 RSSI: -103dBm Bandwidth: 134kHz RF12 baud: 38400 baud LED state: True Wenn ich mit 0x00 0x00 das Status Register anfordere erhalte ich 0xB8 0x1A (MDSEl=1) Wenn ich sonst Daten sende, funktioniert das auch! Die LEDs leuchten aber zugegeben, nicht jedesmal, auch wenn an der anderen Seite etwas passiert. (Also die Recieve LED blinkt nicht jedesmal, auch wenn er Daten empfängt) Ich muss zugeben, dass ich nicht wirklich weiß, wie ich dir weiterhelfen kann. Ich lade mal meine hex und eep aus dem Atmega32. Vll hilft dir die EEP für die Konfiguration.
Also im Anhang mal der komplette Inhalt des Atmega32, wie er auf meinen Funkboard verbaut ist. (Device signature = 0x1e9502) Ich hoffe, das hilft!
Ok. Ich probiere es gleich mal aus. Danke schonmal. Benutzt du das Terminal über die Adapter-Platine mit angeschlossener CTR-Leitung, oder nur mit RX/TX?
Moin Also ich benutze nur RX/TX und schalte MDSEL über einen Jumper und dabei ne LED, die mir den Zustand signalisiert. Übrigens habe ich jetzt mal ein bisschen auf die LEDs geachtet: Versuche auf jeden Fall das Senden MIT Ankowledge, da dann auch jedesmal die (bei mir gelbe) Recieve LED leuchtet. Die (rote) Transmit LED ist nicht so zuverlässig bei mir. Viel Erfolg
Ich habe noch was vergessen zu erwähnen. Ich habe kein zweites Funkboard auf gebaut. Ich habs schon ein paar Beiträge vorher gefragt: Leuchtet die Transmitt-LED trotzdem, auch wenn nur ein Board vorhanden ist? @Andun: Wenn ich mit ACK sende, aber nur ein Sende-Board zur zeit verwende, leuchtet die Receive-LED dann trotzdem mit auf?
Hab deine funk.eep und danach die funk.hex gebrannt. Es bleibt aber alles beim alten... Kriege beim Terminalprogramm jetzt folgende Ausgabe: Connection to Funkboard okay! Device ID: 255 Channel number: 255 Startbyte: 255 DQD: 7 RSSI: -61dBm Bandwidth: ERROR RF12 baud: ERROR LED state: False Da muss es ja an der ext. Beschaltung fast liegen?!? Aber es ist im Grunde ja nur der ATMega8 der jede Sekunde sendet angeschlossen oder nur der MAX232 zum PC hin. Aber es ist sehr merkwürdig, dass zwei Schaltungen die mit verschiedenen Mitteln aufgebaut sind, den selben Fehler aufweisen?!? Ich frage mich nur wirklich, was bei dir anders ist... Wenn ich die Settings über die Terminal-Software auslese, dann sagt er auch immer: Received configuration data (bitfield 1) from Funkboard is invalid! Ist das auch bei dir so?
Neuer Erkenntnisstand: Wenn ich die Settings im Terminalprogramm (z.B. die Werte, die du ein paar Beiträge vorher angegeben hast) an das Funkboard sende, dann akzeptiert das Board die Werte. Wenn ich die Werte jetzt zurücklese, stimmen sie mit den gesendeten Werten überein. Wenn ich jetzt MDSEL=0 lege, und irgendwas zum Board sende, dann flackert auch die Transmitt-LED auf! Wenn ich die Versorgungsspannung unterbreche und dann wieder zuschalte, ist aber wieder alles beim alten und die Settings stimmen wieder alle nicht. Könnte das also an den Werten im EEPROM liegen, das die nicht richtig gelesen und gespeichert werden? Irgendetwas muss ich ja beim brennen falsch machen, weil wir das gleiche Board haben, es aber bei dir läuft und bei mir nicht.
Hallo, ich vermute auch, dass es am EEProm liegt, da du eigentlich meine Einstellungen hättest übernehmen müssen, wenn du meine Eeprom Datei einspielst. Ohne Gegenstelle sollte natürlich nur die Transmit LED leuchten, da ja kein ACK gesendet werden kann. Wieso dein EEPROM sich nichts merkt, kann ich dir aber leider gar nicht sagen! Die Fusebits hast du ja anscheinend richtig. Meine siehst du im Archiv ja. Wenn ich die Settings mit dem Terminal Programm ("Update Terminal") auslese, zeigt er mir alles korrekt an. Da kommt keine Fehlermeldung ...
Nach Wochen habe ich die Lösung meines Problemes endlich gefunden. In der Doku stand klar geschrieben, das zuerst die eep und dann die hex gebrannt werden muss. D.h. ich habe die eep gebrannt und danach die hex, aber jeweils einzelnd im Brennprogramm ausgeführt. Jetzt habe ich aber beide Dateien auf einmal gebrannt, als ein Schritt und siehe da, ich kann die Settings ohne Fehler auslesen und bearbeiten. Endlich! Ich habs leider noch nicht ausprobiert, aber wenn ich die Settings ändere, werden diese dann auch übernommen, wenn ich die Spannung unterbreche? Ich hab hier mal irgendwas gelesen, das nichts im EEPROM gespeichert wird?!? Muss ich die Einstellungen, wie die ID dann vorher im EEPROM manuell eintragen und dann brennen?
Also der EEPROM bleibt auch bei Spannungsverlust erhalten. Er muss aktiv gelöscht werden. Dies geschieht zumeist beim flashen. (Also in den flash) Deswegen muss man den EEPROM hinterher befüllen. Die Firmware des Funkboards sollte die Einstellung anschließend permanent im EEPROM speichern und auch wieder abrufen können. Also kannst du die ID problemlos im Betrieb über die Befehle bei MDSEL=1 ändern. (Wie auch alle anderen Einstellungen) Funktioniert denn nun mit den richtigen Einstellungen das Board?
Ob es wirklich funktioniert, kann ich zur Zeit nicht überprüfen, weil ich ja nur ein Board aufgebaut habe, aber ich gehe davon aus. Jetzt flackert auch die Transmitt-LED immer auf, wenn ich etwas sende und die Settings lassen sich auch ohne Probleme aus-/einlesen. In den kommenden Tagen baue ich noch ein zweites Board auf, und dann sehe ich ob die Kommunikation funktioniert. Hast du eigentlich etwas am Code verändert? Weil dein Code 22kb groß ist (nur die hex Date)und der orginal Code 25kb groß ist?!
Ich habe bisher nichts an dem Code geändert. Ich habe ihn lediglich in den Atmega geflasht und dann anschließend wieder ausgelesen. Vll. wurden dabei Nullen gekürzt oder dergleichen. Ich habe aber noch ein Problem mit dem ACK - Modus: Ich sende zum Beispiel 0x10 als Datenzeichen. (Jeweils immer mit ID und ACK als führende 2 Byte) Manchmal passiert nun folgendes: Der Empfänger gibt ID+0x10 aus. Alles ok! Ich sende ID+ACK+0xAA und der Empfänger gibt nochmals ID+0x10 aus. Wenn ich jetzt irgendein Zeichen sende (ID+0x??), dann gibt mir der Empfänger mein ID+0xAA aus. Ich habe den verdacht, dass das ACK vom Empfänger nicht fehlerfrei zum Sender gelangt und dieser daher das Zeichen erneut sendet. Der Empfänger hat jedoch das Zeichen bereits ausgegeben und schreibt das nun doppelt gesendete Zeichen in den FIFO-Puffer. Wenn nun ein neues Zeichen gesendet wird, wird dem FIFO zuerst noch das alte Zeichen entnommen und dann erst das Neue. Kann diese Theorie irgendjemand bestätigen oder weiß dazu jemand was?
Wen Strauss schrieb: > Beim anderen Board flackert auch die Empfangs-LED kurz auf, an der > seriellen Schnittstelle kommt die Nachricht manchmal ganz, häufiger in > Bruchstücken oder gar nicht an, dafür gelegentlich aber die vorletzte > (!) Nachricht. Ich vermute eine Macke in den FIFOs. Leider sind meine > Kenntnisse in C ähnlich ausgereift wie in anderen C-Sprachen > (Chilenisch, Chinesisch...) und es wäre toll, wenn mal ein Insider > einige Augen darauf werfen könnte. Problem ist also bei anderen aufgetreten! Vllt. könnte jemand der ausreichende C-Kenntnisse hat dieses Problem beheben?!
Hallo, ah, ok. Hab den Thread nochmal überflogen... Das sollte man öfters tun! Ich habe mich in die Materie ein wenig eingearbeitet und der Firmware folgende Veränderungen durchgeführt:
1 | 1. Hinzufügen der status_register.c zum AVR-Studio Projekt. |
2 | 2. Das Status Register wird im Programm mit 0b1011 = 0xB kodiert! => An dieser Stelle scheint die Doku nicht zu stimmen. |
3 | |
4 | configuration.c |
5 | #306: uart_putc(0xD5); // anstelle von 0xD4, das dort falsch ist. |
6 | #363: hinzufügen des identifikationsbytes von 0xD8 |
7 | |
8 | received_data.c |
9 | #167: auskommentieren der id, des senden boards. |
Vorallem letztere Änderung hilft mit schon enorm, da ich das Funkboard eher als Brücke einsetze und mich die ID des senden Boards nicht interessiert. (Ist bei mir eh immer die 0x10). Diese ID wird in meiner weiteren Schaltung aber teilweise als Nutzdatum interpretiert und erzeugt dadurch einen Fehler. Bei einem kurzen und nicht systematischen Test ist mir dabei nun der FIFO-Bug auch nicht mehr begegnet. (Vll. ist er doch nicht so gravierend, oder ich hatte nur Glück) Vll. kann ja jmd an dem Code weiterarbeiten.
Also auch bei mir türmt sich der Frust so hoch wie der Schnee vor der Tür. Folgendes ist mir noch aufgefallen: In der Funktion 'initialize()' wird 'init_twi_slave(slaveadresse)' aufgerufen, die das Hardware-TWI initialisiert und das Interrupt-bit setzt. Da hier TWI jedoch hier softwareseitig realisiert wurde, ist 'init_twi_slave(slaveadresse)' komplett überflüssig und kann entfallen. Ebenso kann die Datei 'i2cslave.c' aus dem Projekt entfernt werden. Da ich vermutete, daß ein verfrühter Interrupt bei mir die Kommunikation mit dem Terminaladapter verhindert, habe ich alle 'sei()' in den von 'initialize()' aufgerufenen Routinen entfernt. Nur das letzte 'sei()' in 'initialize()' bleibt stehen. Ob damit das Terminalprogramm funktioniert, werde ich später prüfen. Jedenfalls klappt das Schreiben auf und das Lesen vom Eeprom damit fehlerlos. Der Empfang von Daten klappt auch, aber das Senden... Deshalb habe ich testweise eine neue 'main()' erstellt. Sie enthält außer 'initialize()' alles was in 'rf12_txdata(...)' steht, mit dem Unterschied, daß ich Daten (3 Byte) und eigene id fest vorgebe und nicht über *data auf einen Puffer zugreife. Noch ein Schleifchen ringsrum gebastelt, und siehe da, alle gesendeten Bytes kommen beim Empfänger auch an. Entfernung der beiden Boards: ca. 1m, Antenne: 2cm Draht. Liege ich jetzt ganz falsch, oder müsste ich den Fehler im senderseitigen Puffer suchen? Aber wie kommt es, daß es bei einigen Leuten offensichtlich problemlos klappt, während Andere sich die Haare raufen? Sind da unterschiedliche Dateiversionen im Umlauf? Ich habe die, die in diesem Thread zweifach genannt wurde. Na, ich werde jedenfalls weiter basteln und raufen. Fröhliche Weihnachten, Wen
Hallo Wen, mir ist noch nicht ganz klar, worin dein Problem besteht. Meinst du Terminaladapter das Terminal-Programm für den Rechner oder meinst du damit einen ganz normalen seriellen-(z.B.)USB-Wandler den du als Adapter verwendest?? Wie gesagt, benutze ich jetzt die Dateien, die ich auch zuletzt angehängt habe. (Die hex-Datei befindet sich dort - wie immer - im Unterordner 'default'. Diese Version ist meiner Kenntnis nach, die Aktuellste. Zum Terminal-Programm auf dem Rechner: Das funktioniert bei mir auch nicht fehlerfrei! (Allein schon aus dem Grund, dass ich MDSEL manuell setze) Der Einsatz als Funkbrücke mit 1 Byte Befehlen funktioniert bei mir jetzt jedoch einwandfrei. (Wobei mein Test nur darin besteht, dass mein Roboter Befehle bekommt, wie 0x03 = geradeaus, etc. das funktioniert nun) Schönes Fest wünsche ich auch!
Hallo Andun,
mit Terminaladapter meine ich eigentlich die komplette Kette von
'Terminalprogramm' - 'USB-Seriell-Wandler' - 'Adapterplatine PC to
Funkboard'. Eine Fehlerquelle ist möglicherweise auch der USB-Seriell
Wandler, der mit seinem Timing halt doch nicht exakt einer 'echten'
seriellen Schnittstelle entspricht. Den fehlenden Pegelwandler auf der
Adapterplatine hatte ich ja schon erwähnt. Im Terminalprogramm bekam ich
immer die Meldung 'Funkboard not connected', bis ich in der initialize.c
die Zeile //uart_puts("INIT"); mal testweise entkommentiert habe.
Danach hatte ich gelegentlich das Erfolgserlebnis 'Funkboard connected',
aber irgendwelche Einstellungen konnte ich trotzdem nicht ändern, obwohl
ich sie teilweise auslesen konnte. Deshalb habe ich alle Einstellungen
zunächst fest programmiert und verzichte momentan noch auf die
Änderungsmöglichkeit mit dem Terminalprogramm. Möglicherweise hat man
alle diese Probleme nicht, wenn man mit einem anderen Controller direkt
mit TTL-Pegel auf den UART des ATMega zugreift.
Mit Deiner Lösung verschenkst Du 99% der Funktionalität des Funkboards.
Um ein Byte zu übertragen braucht man auch keine 32kB Flash. Ein kleiner
Tiny2313 hätte allemal ausgereicht. Das soll jetzt keine Kritik sein,
denn wenn man so ein Board hat, möchte man es ja auch nutzen. Und wenn
man für seine Anwendung nur ein Byte braucht, ist das wohl auch in
Ordnung. Jedenfalls besser, als Funkboard wegwerfen und ATTiny neu
kaufen.
Für das, was mir vorschwebt, brauche ich aber mehr Funktionalität. Ich
möchte in jedem Raum meines Hauses die Temperatur messen, die
Solltemperatur einstellen können und auch noch eine Rückmeldung von der
Heizungssteuerung über ein LCD erhalten, und das alles drahtlos und
fehlertolerant. Dazu braucht's nun mal adressierbare Knoten und eine
bidirektionale Verbindung. Eigentlich sollte das Funkboard genau das
können...
Gruß, Wen
Kann ich eigentlich auch irgendwie kontrollieren, ob eines meiner RFM12 Module kaputt ist?! Ich sende von einem meiner Boards z.B. 0x00 0xF0 0x61 0x61 und die Transmitt-LED flackert, aber die Receive LED am anderen Board leuchtet nicht auf. Wenn ich mit der Terminal-SOftware das Board auslese steht bei ID 0. Sollte die nicht beim programmierfrischen Modul 0xFF oder so sein?
@Wen Strauss: Du hast natürlich recht, dass ich viele Funktionen verschenke. Da ich es aber schonmal habe ... @Bene Jan: Die "voreingestelle ID" laut Doku ist falsch. Das hatte ich auch schon mal festgestellt. (ich muss gestehen, dass ich nicht mehr genau weiß, welche ID nun voreingestellt ist. Aber ich würde an deiner Stelle versuchen die ID mal manuell zu setzen. (Also MDSEL=1 und dann laut Doku in das passende Register schreiben) 1. Trau ich einer ID 0x00 generell immer nicht so ganz (Abgerglaube und die Gefahr dass es mal als String-Ende erkannt wird) 2. Wenn du es erfolgreich ändern und über einen Spannungsverlust halten kannst, dann weißt du das der Atmega richtig funktioniert. Eine Möglichkeit die RFM Module zu testen ist mir nicht bekannt, muss es aber eigentlich auch geben. Auf jeden Fall könntest du testen, ob dir das Modul antwortest, in du es mit einer der Low-Level Funktionen direkt ansprichst. (Das würde ich aber erst machen, wenn das mit der ID auch nichts bringt) Übrigens sind in meinem Archiv von weiter oben zwei EEPROM Dateien: funk-s.eep => ID=0x11 und LEDs aus und funk-j.eep => ID=0x10 und LEDs an Falls du also mal eine fertige Konfiguration testen möchtest.
Hallo Wen, ich habe nochmal ein wenig über unsere Probleme nachgedacht und habe noch folgende Überlegung: Die Funktion radio_receive_data kurz zusammengefasst:
1 | Fülle die globalen Variablen gbl_radio_input_fifobuffer etc. mit den Daten aus dem RFM. |
2 | |
3 | Falls alles ok ist: |
4 | -- Sende ein ACK falls nötig |
5 | |
6 | -- Da nur Pollmodus: Sende direkt alles per UART |
7 | |
8 | Sonstige Fehlerbehebung ... |
Zuerst dachte ich daran, dass vll. der UART schneller aufgerufen wird, als die Daten verarbeitet werden. Dies würde dazu führen, dass Daten verloren gehen und nicht wie bei uns doppelt gesendet werden. Aber was passiert denn, wenn das ACK Signal gefordert wird, aber es bei dessen Übertragung zu einem Bitfehler kommt? Der Empfänger hat sein ACK vermeintlich gesendet und gibt den Inhalt der Nachricht aus. Der Sender empfängt das ACK nicht korrekt und sendet daraufhin seinen Inhalt noch einmal. Dies müsste der Empfänger doch nun auch wieder sofort ausgeben, oder? (Die beobachtete Verzögerung lässt sich in diesem Szenarion also nicht erklären) Dies soweit als Denkanstoß. (Ist ein Fehler im RFM Fifo denkbar?) Hast du das Problem inzwischen weiter eingrenzen können? Taucht es auch ohne ACK auf? Das würde helfen, dass Problem einzugrenzen. Hast du wiederholbare Bedingungen gefunden, bei denen das doppelte Senden auftaucht? Einen Guten Rutsch wünsche ich allen!
Hallo Johannes, Nachdem wir durch Herumstochern im Code tatsächlich die eine oder andere Kleinigkeit gefunden haben, aber das Board trotzdem noch nicht so läuft wie gewünscht, muß man wohl etwas systematischer vorgehen. Am 20.12. hatte ich ja schon damit begonnen und bin zur Vermutung gelangt, den Fehler im senderseitigen Fifo zu suchen. Ich war gerade dabei, diese Annahme zu vertiefen, als ganz ohne jede Vorwarnung und -ehrlich- ohne meine Schuld das Jahr plötzlich zu Ende war. In jedem Raum Matratzen und Schlafsäcke, der Geschirrspüler lief pausenlos und ein Stehplatz in der Küche war nur noch mit Ellenbogen zu ergattern. Aber auch dieses Naturereignis hatte mal ein Ende. Ich habe also Folgendes gemacht: In der main.c habe ich nach dem Initialisieren unterschiedliche Pakete entsprechend den Vorgaben gepackt, also den Startcharakter, die Target-ID, die eigene ID ohne ACK, die Nutzdatenlänge (3), die erste Checksumme, drei Datenbytes, zwei CRC-Bytes, zwei Dummybytes, insgesamt 12 Bytes. Diese Pakete (ca. 100) habe ich versendet, indem ich die Funktionen in rf12.c unmittelbar aufgerufen habe. Zwischen den Paketen habe ich eine Pause gelassen, die groß genug ist, um alle Bytes aus dem empfängerseitigen Fifo zu schieben. Ergebnis: Alle Pakete sind angekommen, keins war verstümmelt, keins doppelt. Senderseitig war nur der HW-Fifo des Funkmoduls beteiligt. Das scheint also zu funktionieren, ebenso wie sein Gegenstück auf der Empfängerseite. Dort folgt anschließend das SW-Paket-Fifo. Von hier gehts weiter in SW-UART-Fifo, nachdem Startcharakter, Checksummen etc. entfernt wurden. Das letzte Fifo ist das HW-UART-Fifo. Im Gegensatz zu den HW-Fifos, die nur sehr klein sind, sind die SW-Fifos nicht richtig gefordert worden, weil ja immer Pausen zwischen den Paketen waren. Deshalb der nächste Test: Drei Pakete ohne Pause dazwischen gesendet und anschließend eine dreimal so lange Pause wie oben. Ergebnis: das gleiche, alles einwandfrei empfangen, Fifo-Algorithmus scheint zu funktionieren. Jetzt wollte ich es genau wissen. Test drei: Alle Pakete pausenlos hintereinander gesendet. Ergebnis: Die ersten x Pakete einwandfrei, später dann fehlten jedes dritte bis fünfte Paket, aber keines war verstümmelt oder doppelt. Vom Timing hätte ich genau dieses erwartet. 12 Byte zu senden bei 57600 Bd dauert ca. 2,1 ms. Die Initialisierung zum Senden dauert auch noch jedesmal etwas. Von den 12 gesendeten Bytes kommen am Empfänger-UART nur noch vier raus (die Sender-ID und die drei Nutzbytes). Das dauert bei 9600 UART-Baudrate ca. 4.8 ms. Wenn der Fifo voll ist, sollte also etwa jedes dritte bis vierte Paket verloren gehen. Das stimmt ganz gut mit der Beobachtung überein. Anmerkung: Wenn man bei Sender- und Empfänger-UART mit der gleichen Baudrate arbeitet, sollte es zu einem solchen Fehler gar nicht erst kommen. Mein Fazit: Empfangsseitig würde ich dem Funkboard die Absolution geben. Der uns so störende Fehler ist wohl im senderseitigen Paket-Fifo zu suchen. Da die mir zur Fehlersuche zur Verfügung stehenden Hilfsmittel lediglich aus einer Kaffeemaschine und einer Schüssel Gehirnschmalz bestehen (beides nicht mehr neuwertig), rechne ich nicht mit einer superschnellen Lösung. An Deinen Einwand bezüglich der ACK-Funktion habe ich auch zuerst gedacht, aber meine ersten Tests waren auch alle ohne ACK nicht ok. Gruß, Wen
Hallo Wen, ja, diese plötzlichen Jahreswechsel kommen immer wieder unerwartet ... zum Glück war diesmal eines Anderen Wohnung betroffen ... :D Deine Ausführungen klingen schlüssig. Ich muss gestehen, dass ich jetzt keine weitere kluge Idee habe. Ich werde mir die Sende-Routinen bei Gelegenheit auch nochmal ansehen, bis dahin wünsche ich dir viel Erfolg! Johannes
Hallo zusammen, ist es möglich, dass die Webseite aktuell nicht (mehr) erreichbar ist? Ich erhalte beim Aufruf von "http://flashcraft.de/index.php/funkboard-uebersicht"; nur eine leere Seite... Ich würde mich gerne näher über das Projekt erkundigen, da ich mit dem RFM12 experimentieren möchte. Ist es möglich das Board irgendwo zu kaufen und könnte mir jemand vlt. die erwähnte 60 Seiten Doku zukommen lassen bitte? Vielen Dank! Markus
Hi, ein bischen weiter oben in diesem Fred findest du alles: Beitrag "Re: Nachbaubares Funkmodul auf Basis des RFM12" Ebenso in der Artikelsammlung... Gruß - Markus
Oh danke, da hatte ich wohl entweder zu wenig vom Ende zurück oder vom Anfang nach vorne gelesen ;-) Kann man denn das fertige Modul noch irgendwo bestellen oder muss man es selbst zusammen bauen?
Ich hab das noch nie irgendwo fertig gesehen, also alles DIY ;-) Gruß - Markus
Hallo an alle! Drei Sachen habe ich noch gefunden, die auch für andere interessant sein könnten. 1. Falsche Broadcastadresse Wer seine Datenpakete an die in der Doku angegebene Broadcastadresse hex55 gesendet hat, braucht sich nicht zu wundern, daß sie nicht angekommen sind. Die Empfangsroutine prüft nicht auf hex55 sondern auf hexAA. Wer jetzt meint, er müsse einfach seine Pakete an AA statt 55 senden, bekommt gleich die nächste Ohrfeige. AA liegt außerhalb des Adressbereichs und ist eigentlich ein 2A mit gesetztem ACK-bit. Und da 2A was anderes ist als AA werden diese Pakete vom Empfänger verworfen. Abhilfe: In der Datei rf12.c in der Routine rf12_rxdata unter Punkt vier AA in 55 ändern. 2. Streunende Timerinterrupts Das sind Interrupts, die auftreten, wenn sie gar nicht auftreten sollten. Ursache: Beim Initialisieren beispielsweise werden die Timer gestartet und eine Interruptbedingung festgelegt (z.B. Output Compare oder Overflow) aber die Interrupts noch nicht enabled. Nach einer gewissen Zeit treten die Interruptbedingungen ein, die entsprechenden Flags werden gesetzt, aber ein Interrupt wird noch nicht ausgelöst, weil sie noch nicht enabled sind. Tut man das schliesslich, kommt sofort der Interrupt (das entsprechende Bit ist ja gesetzt) obwohl man eigentlich ein paar Millisekunden warten wollte. Beim Timer2, der erst feuern sollte, wenn ein neues Datenpaket über den Uart empfangen wurde, heißt das, daß ein neues Paket gemeldet wird, obwohl noch nicht ein Byte empfangen wurde. Der Müll, der sich noch im Datenpuffer befindet, wird jetzt weiterverarbeitet... Vielleicht nicht schlimm, wenn man im Sende/Empfangsmodus ist, weil der Empfänger den Müll verwirft, aber im Konfigurationsmodus kann das allerhand Unsinn anstellen. Dieser Fehler tritt nicht nur einmal nach dem Initialisieren auf, sondern jedesmal, wenn zwischen disablen und erneutem enablen eine entsprechende Zeitspanne vergangen ist.Das betrifft alle verwendeten Timer. Abhilfe: Überall dort, wo ein Timer disabled werden soll, erst den Timer stoppen, dann den Interrupt disablen. Überall dort, wo ein Timer wieder enabled werden soll, erst den Zählerwert auf null zurückstellen, den Interrupt enablen und dann erst den Timer wieder starten. Ich habe das bei allen drei Timern gemacht. Seitdem leuchtet die Receive-LED viiiiel schöner. 3. Paketlänge Eigentlich kein Fehler im Funkboard, sondern in der Peripherie. Bei einem Paket sollten die einzelnen Bytes lückenlos hintereinander kommen. Ist das nicht der Fall, weil man wie ich einen USB-Seriell-Wandler hat, der zwischen den Bytes wahllos und zufällig Pausen läßt, passiert folgendes: Das erste Teilstück kommt vielleicht noch an, weil es den richtigen Startcharakter, eine gültige Empfängeradresse und die richtige erste Checksumme hat. Bei den restlichen Bröseln trifft das nicht zu und sie werden verworfen. Hat man nur genug von diesen Bröseln, die ja alle den Fifo vollstopfen, kommt es schnell zu einem Pufferoverflow, und man wundert sich, daß auf einmal Datenfragmente ankommen, die man schon gestern gesendet hat. Übrigens, eine serielle Buchse am Rechner ist kein Garant dafür, daß man auch eine "echte" serielle Schnittstelle hat. Bei vielen Rechnern, besonders Laptops, findet man stattdessen schon auf dem Motherboard einen USB-Seriell-Wandler. Ist halt billiger. Abhilfe: Eine echte Abhilfe wäre, auf USB zu verzichten, wo das nicht geht, mag folgendes akzeptabel sein. Ich habe das Timeout von Timer2 vergrößert, zunächst auf das 16-fache des ursprünglichen Wertes, als das noch nicht langte, auf das 64-fache (beim Starten des Timers die 1 nicht in CS0 sondern in CS1 resp. CS2 schieben). Auch zerstückelte Pakete kommen jetzt an. Natürlich hat diese Vorgehensweise auch große Nachteile. Man muß beim Senden die Pausen zwischen den Paketen entsprechend groß machen, sonst hat man das gleiche Problem mit umgekehrtem Vorzeichen. Bei 9600 Baud und 64-facher Timeoutzeit sind das immerhin 133 ms. Und ob das zusammen mit dem Acknowledge funktioniert, weiß ich noch nicht. Ok, wenn ich noch was Schlaues zu berichten habe, melde ich mich wieder. Gruß, Wen
Hallo wen Ich verfolge deine Beiträge sehr aufmerksam, weil ich dieses funkmodul auch benutze. Wollte mich nur mal bedanken, dass du dir die mühe machst und alle Fehler versucht zu finden... stellst du bei Zeiten auch einen Quelltext rein, bei dem die Fehler schon verbessert wurden?
Hallo, Auf einfachen Wunsch eines einzelnen Mitglieds (Bene Jan) habe ich das Paket noch mal mit allen Änderungen/Verschlimmbesserungen neu gepackt. Es ist noch eine readme mit dabei, die nicht als Bedienungsanleitung verstanden sondern wirklich gelesen werden sollte. Über Rückmeldungen und Erfahrungen würde ich mich freuen. Bis später, Wen
Hi Wen, vielen Dank für die Mühe die du dir machst. Hoffe ich komme jetzt bald mal zum Testen, hab auch noch zwei Module für ein Projekt rumliegen das ich hoffentlich bald mal umsetzen kann. Danke dir! Gruß - Markus
Er hat noch nicht gesehen, dass es die Funktion "E-Mail Benachrichtigung aktivieren" gibt. Um nun künftig Email-Benachrichtigungen bei neuen Posts zu bekommen, schreibt er einen Beitrag mit "abo" drin. --- Markus ---
Hallo an alle! Ursprünglich war es meine Absicht gewesen, das Funkboard als black box hinter einen ATTINY 2313 zu schalten. Allerdings hat der ATMEGA noch jede Menge Ressourcen frei. Flash ohnehin reichlich. Da ich weder einen MAX3221 noch einen ZLDO habe, auch noch jede Menge Portpins, nur SRAM ist mager. Florian hat zwei Arrays definiert (gbl_spi_receive_buffer und gbl_i2c_receive_buffer) die aber nirgendwo benutzt werden. Wenn man deren Definition im Quelltext auskommentiert, gewinnt man satte 140 Bytes. Damit kann man schon was anfangen. Ich werde wohl auf den Tiny verzichten und seine Aufgaben an den Mega delegieren. Dann brauche ich auch den UART und seine FIFOs nicht mehr, das gibt noch mal jede Menge freies SRAM. Ohne UART gibt's auch keine Probleme mehr mit USB-Seriell Wandlern. Kann mir vielleicht jemand verraten, warum ich mir die ganze Mühe gemacht habe? Gruß, Wen
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.