Ich habe mich wieder mal mit dem RFM12 beschäftigt. Herausgekommen ist eine drahtlose RS232 Übertragung mit einer einfacher FEC (forward error correction). Die Software ist sehr einfach gehalten und funktioniert nach folgendem Prinzip: Das Modul befindet sich im fast immer Empfangsmodus, die RX LED leuchtet. Trifft ein Byte über Funk ein, wird das komplette Paket empfangen und über den UART weitergeleitet, falls dieses fehlerfrei empfangen wurde. Außerdem leuchtet dann die OK LED. Trifft ein Byte über den UART ein, wird es gespeichert und ein 100ms Timer gestartet. Solange können neue Bytes eintreffen, die dem Paket hinzugefügt werden. Nach 100ms oder falls eine entsprechende Anzahl an Daten erreicht ist, wird das Modul auf Senden geschaltet (TX LED an) und das Paket gesendet. Wenn gleichzeitig das andere Modul sendet, gehen Daten verloren. Danach wird wieder auf RX umgeschaltet. Das Paket ist einfach aufgebaut: Anzahl der zu übertragenden Bytes, Daten und die Summe aller Bytes als Prüfsumme. Alle Daten werden über einen einfachen Hamming Code übertragen, um eine gewisse Fehlerkorrektur zu haben. Sollte die Prüfsumme am Ende falsch sein, wird das Paket einfach weggelassen (und die OK LED geht aus). Das ganze ist keine ordentliche Lösung, funktioniert aber recht gut. Meine Erfahrungen mit dem Modul sind, dass entweder die Daten alle korrekt, oder komplett falsch ankommen (da andere Sender dazwischengefunkt haben). Das erkennt dann die Prüfsumme. Die Reichweite liegt bei >100m, solange keine anderen Sender in der Nähe sind.
Hast du ggf nen Schaltplan dazu? (Oder hab ich das jezt im Zip übersehen??)
Einen Schaltplan habe ich (noch) nicht gezeichnet, kann ich aber machen. Die Belegung der LEDs ist in der leds.h festgelegt, das RFM12 hängt am SPI Port (PORTB). Mehr braucht man nicht. Ich betreibe den AVR mit dem 10MHz Takt des RFM12.
Hier nochmal das ganze mit leicht optimierten Puffereinstellungen und Schaltplan. Auch die Funktionen der LEDs haben sich leicht geändert. Ich habe das ganze jetzt mehrere Stunden quer durchs Haus senden lassen: Es gab keine Datenfehler außer wenn der 433MHz Sender vom Funkthermometer gleichzeitig sendet. Die Module sind also relativ robust was die Datenqualität angeht.
Joar da wird shcon einiges an Fehlerkorrektur drinnestecken :) Wenn ich mal Zeit hab werd ich das mal versuchen aufzubauen, im Momment ist leider imemr viel zu tun wegen Studium :(
Ich habe das ganze heute Nachmittag mal etwas getestet: Ein Modul ist mit dem PC verbunden, beim anderen sind TXD und RXD verbunden. Das Modul sendet also alle Daten zurück. Beide Module sind etwa 25m und 2 Stockwerke entfernt. Nach 4 Stunden hatte ich folgendes Ergebnis: 36412 gesendete Pakete zu je 64Bytes, davon empfangen: 36386 Das ergibt eine Verlusterate von 0,071%. Beschädigt kamen keine Pakete an. Falls also ein Fehler aufgetreten ist, wurde das Paket garnicht erst weitergeleitet.
Wenn ich das aufgebaut hab kann ich mich ja mal etwas an der Weiterintwicklung der Firmeware beteiligen, da ich diese Semester eh gerade Computernetworks (unter anderem gehts da halt auch um Wireless Kommunikation) und InformationsTheorie/Kanalkodierung (sozusagen das drunterliegende) Man könnte ja noch ne Art ACK System einführen (wird ja eh gepuffert, dann kann man auf dem "Rückweg" ein ACK huckepack tragen und ggf den Buffer neu übertragen oder nen Fehler ausgeben) Was mir gerade so einfällt: das wäre dann nen 1A WireLess ISP (Bootloader vorausgesezt, bzw eine AVR der das in ISP umsezt)
Ich habe eine Version mit Rückantwort gerade ausprobiert: Es funktioniert so naja. Das Problem ist, das bei einer Neuübertragung der Empfangspuffer des Senders überläuft wenn er weiterhin mit Daten vom PC beschäftigt wird. Ich habe ein ganz einfaches System eingebaut: Nach jedem empfangenen Packet sendet der Empfänger ein OK oder beschädigt Zeichen zurück. Sollte innerhalb von 50ms nichts beim Sender ankommen wird das Paket vom Sender automatisch nochmal übertragen. Nach 5 Versuchen geht eine Error LED an. Die Pakete werden fortlaufend nummeriert, für den Fall, dass lediglich die OK Antwort vom Empfänger nicht ankam. Ein weiteres Problem ist, wenn beide Seiten gleichzeitig das Senden anfangen. Noch ein Nachtrag zur bisherigen Version: In der rf12.c muss bei BUFF_SIZE der gleiche Wert eingestellt werden wie in der main.c. Das habe ich in der letzter Version falsch gemacht: In der rf12.c muss ebenfalls 64 eingestellt werden, sonst kann es zu Datenverlust kommen !
Heute Nacht lief der Sender mit der Empfangsbestätigung: Von 27200 Paketen (je 127Bytes) kam 1 Paket nicht an, da der UART Empfangspuffer überlief. Dadurch wurden 507Bytes beschädigt. Um den Sender zu stören, habe ich einen weiteren Sender laufen lassen, der alle 10s etwa 1s lang sendet. Mit der alten Software ohne Korrektur hatte ich dann etwa 8,3% Verlust. Ich glaube ich ersetzte den Hamming Code durch irgendetwas effizienteres (oder lasse diesen ganz weg). Gibt es irgendeine Codierung, die etwa 50% overhead erzeugt, aber trotzdem 1 Fehler pro Byte korrigieren kann ?
Lass den Hamming weg, das wird das Modul eh intern schon machen. Man aknn nicht einen Fehler, sondern mindestens(!) einen Korrigieren, mehr ginge nur mit Softdesicion problem ist nur: Wird der Empfang durch ein anderes Modul gestört, nüzt (meist) die beste Fehlerkorrektur nix! Man könnte höchstens noch mit der Symbolrate rumspielen aber ob das alles was bringt? Leztendlich kommt ja schon das fertige DigitalSignal "raus" Benedikt hast du ICQ oder sowas und magst mir deine Nummer vieleicht mal per mail/PN senden?
Hier der Code mit Neuanforderung der Daten: Er funktioniert an sich problemlos, solange der UART Empfangspuffer (momentan 512Bytes) nicht überläuft. Sobald die Übertragung allerdings bidirektional wird, und beide Seiten gleichzeitig senden kann es zu Problemen kommen. Anonsten sollten die Daten fehlerfrei ankommen. Ich hatte trotz 10%iger Kanalstörung nur 0,004% Verluste und das auch nur weil der Puffer übergelaufen ist. Die 4 LEDs haben nun folgende Bedeutungen: - RX - TX - Fehler oder Neuübertragung - Power Die todo Liste ist bei diesem Code lang: - Wenn beide Module gleichzeitig senden müssen sie sich irgendwie einig werden wer zuerst senden darf. - Eine Flusskontrolle muss eingebaut werden (theoretisch gibt es in den UART Routinen eine CTS Funktion, aber diese habe ich noch nie getestet). Außerdem ist das dann keine echte transparente RS232 Brücke. - Der Hamming Code braucht zuviel Übertragungsbandbreite. Irgendein anderer Code (der z.B. nur etwa 50% overhead erzeugt) wäre besser. Ganz ohne funktioniert es nicht, da zumindest Füllbits eingefügt werden müssen, da der Empfänger ausreichend Pegelwechsel benötigt um den Takt sauber wiederherzustellen (es kann ja sein, dass der Benutzer nur 0x00en oder 0xFFen sendet). Anstelle sinnloser Füllbits ist eine sinnvolle Codierung besser: Man verschwendet dadurch keine kostbare Bandbreite. - Was tun wenn nach n Versuchen die Daten immer noch nicht gesendet sind ? - Die Latenzzeit der Daten beträgt worst case 500ms selbst wenn keine Übertragungsprobleme auftreten (mit Übertragungsproblemen können die Daten um einige Sekunden verzögert werden, falls sie doch noch ankommen).
Für das gleichzeitige Senden würde ich folgendes vorschlagen: - Das Modul chekct ob der Kanal frei ist (Listen befor Talking) - Wartet eine zufällig Zeit (Random Backoff delay) - wartezit bis senden auf 50ms reduzieren ggf lieber eine großen Sende/Empfangsbuffer und dafür weniger Daten/Paket senden. ggf. XON/XOFF Protokoll? Das kann normal jedes Terminal. es sind ja noch ein paar Pins frei am AVR, ggf könnte man sogar ne Hardwareflußkontrolle implementieren, wer das nicht will kann dann einfach RTS und CTS brücken (so wie mans normal auch macht) und verliert dan ggf halt etwas das wäre dann aber noch transparent (vieleicht wäre auch durch DipSchalter Protokoll/Übertragungsrate wählbar machen?) Sollte nach X - Wiederholungen keine Antwort kommen könnte man einfach einen Fehler ausgeben auf die UART und alle Daten verwerfen. (ggf. durch LEDs zu signalisieren)
Benedikt K. wrote: > ...Eine Flusskontrolle muss eingebaut werden (theoretisch gibt es in den > UART Routinen eine CTS Funktion, aber diese habe ich noch nie getestet). > Außerdem ist das dann keine echte transparente RS232 Brücke. Warum dann nicht das altbekannte Software-Handshake (XON/XOFF) nutzen. ein XOFF über die serielle Schnittstelle (zum PC) ausgeben, sobal der Sendebuffer bei 400 Zeichen angekommen ist und ein XON, sobald er wieder unter 100 Zeichen ist. Damit sollten einem halbwegs kontinuierlichen Datenfluss nichts mehr im Wege stehen. Siehe http://de.wikipedia.org/wiki/Datenflusskontrolle#Software-Flusskontrolle.2C_Software-Handshake.2C_Software-Protokoll_oder_X-ON.2FX-OFF Dies wird meines Wissens defaultmäßig von vielen Kommunikationsprogrammen unterstützt. Selbst von Hyperterminal. Oder habe ich hier etwas wesentliches außeracht gelassen? Gruß, Klaus
Das Problem ist aber: Ich möchte das ganze nicht mit Terminalprogrammen verwenden, sondern das ganze soll quasi ein drahtloses RS232 Kabel sein. Im Idealfall sollte daher garkein Handshaking vorhanden sein, damit sich das Kabel möglichst transparent verhält. Ich werde aber mal ein CTS Handshaking implementieren, da das meiner Meinung nach das am weitesten verbreiteste ist, und das ganze oft hardwaremäßig von vielen größeren UARTs unterstützt wird.
Ich habe das ganze mal noch weiter entwickelt. Theoretisch sollten jetzt 19200Baud bidirektional möglich sein. Bei jeder Empfangsbestätigung werden automatisch vorhandene Daten mitgesendet. Dadurch teilt sich die Bandbreite auf beide Richtungen gleichmäßig auf, und die Bandbreite wird besser ausgenutzt. Weiterhin habe ich das ganze Programm etwas aufgeräumt und die Hamming Kodierung entfernt um die vorhandene Bandbreite besser auszunutzen. Stattdessen bekommen 0x00 und 0xFF einfach ein 0xAA Füllbyte hinterhergeschickt, um den Bittakt im Empfänger zu synchronisieren (bei vielen 0x00 oder 0xFF hintereinander gibt es ansonsten Probleme.) Für diesen Tip möchte ich mich bei Läubi bedanken. Die meisten Einstellungen der Paramater für den RF12 werden jetzt anhand der eingestellten Baudrate (laut Datenblatt) optimal eingestellt. Die Sende/Empfangsfrequenz ist in 4 gleichmäßig im zulässigen Frequenzband unterteilten Frequenzen mit je 325kHz Bandbreite unterteil, die sich (zumindest theoretisch) gegenseitig nicht stören dürften. In einer Richtung sind die vollen 19200Baud möglich (wenn es keine Störungen auf dem Funkkanal gibt). Werden Daten in beide Richtungen übertragen, kommt aus irgendeinem Grund ab und zu zu Problemen und schlimmstenfalls springt das ganze in einen Modus in dem viele Daten beschädigt oder garnicht ankommen. Vielleicht findet jemand den Fehler, ich suche jetzt schon seit Stunden, aber finde keinen. Ebenso merkwürdig ist der Fehler beim CTS Handshake: Aus irgendeinem Grund ist der Bytezähler nicht synchron zu den wirklick vorhandenen Bytes im Puffer. So passiert es, dass durchschnittlich etwa 1Byte pro 1kByte verloren geht. Naja, nicht wirklich verloren, die Daten sind schon noch im Puffer, nur der Puffer weiß das nicht, da der Zähler auf 0 steht. Sendet man weitere Daten, dann werden die fehlenden Daten gesendet. Dieses Problem liegt definitiv am UART Empfangspuffer und hat nichts mit dem eigentlichen Sender zu tun. Daher habe ich CTS und RX_COUNT (beides ist für CTS notwendig) in der UART.h deaktiviert. Wenn all diese Probleme gelöst sind, kann man einen Schritt weiter gehen, und eine automatische Kanalbelegung und Baudratenwahl einbauen, je nachdem wie die Übertragungsbedingungen sind. Zusammen mit Läubi haben wir ein paar Ideen überlegt: Man könnte z.b. 1x pro Sekunde ein "Keep Alive" Paket senden (falls keine Daten zu senden sind) um zu prüfen ob der Empfänger noch da ist. Falls keine Antwort nach mehreren Anfragen kommt, wechseln Sender und Empfänger nach einen festen Schema die Kanäle. Hier muss man sich noch genau überlegen, wie man es schafft, dass sich beide irgendwie finden, wenn z.B. einer der beiden neu eingeschaltet wird.
Neue Version: Das CTS Problem ist behoben, die Flusskontrolle ist jetzt eingebaut und aktiv. Auch die bidirektionalen Transfers sollten jetzt problemlos funktionieren. In meinen Tests habe ich in einer Richtung 160kByte mit CTS Flusskontrolle gesendet, und gleichzeitig in der Gegenrichtung 100Bytes alle 0,1s ohne Flusskontrolle. Beide Daten kamen immer vollständig und richtig an (solange keine längeren Störungen durch andere Module vorhanden waren). Die Datenrate lag dabei bei 1,6kByte bzw. 1kByte/s, was insgesamt etwa 21kBit/s reine Nutzdatenrate ergibt. Sollte die Übertragung gestört werden, sinkt die Datenrate, da die übertragenen Daten neu übertragen werden müssen.
Tach auch! Ich habe mir für die Funk-Geschichten mal ein Protokoll ausgedacht und bin gerade dabei eine art netzwerk-stack dafür zu bauen ;) Protokoll siehe hier: http://www.das-labor.org/wiki/AirLAB_Protokoll_Version_0
@Sören H. Wie weit bist du ? Dein Protokoll sieht gut durchdacht aus. Ich hatte auch überlegt ob ich ein etwas komplizierteres einbaue, aber das macht bei einer simplen 2 Punkt Verbindung mit mittelmäßiger Datensicherheit eigentlich keinen Sinn, daher habe ich es gelassen und stattdessen nur 1 Pakettyp eingebaut der 1 Statusbyte und ansonsten 0-128Bytes Nutzdaten enthält. Das hat den Vorteil, dass ich gleichzeitig die Empfangsbestätigung und Nutzdaten senden kann, und sich die Bandbreite so automatisch gleichmäßig auf beide Richtungen aufteilt, da beide aufgrund der Bestätigung immer abwechselnd senden. Im Anhang ist eine neue Version, bei der sich die Einstellungen per DIP Schalter an PortC vornehmen lassen. So kann man leicht die Baudrate und einen von 4 Funkkanälen einstellen ohne die Software anpassen zu müssen. Je höher die Baudrate, desto geringer wird die Reichweite.
Hallo an alle, an dieser Stelle mal - HELP! Ich hatte vor einiger Zeit angefangen diesen Treat hier mitzulesen und auch drüber nachzudenken. Dummerweise war es mir jetzt eine Weile nicht möglich und ich habe völlig den Überblick verloren was Stand der Dinge ist. Gibt es eine "Projektseite" auf der man den momentanen Stand sehen kann? Ich bräuchte nur etwas was sich wie ein serielles Kabel verhält (allerdings mit Fehlerkorrektur) - Handshaking nicht nötig. Ist die Entwicklung schon so weit gediegen? Für den Fall das ich auch was helfen kann: Ich muss demnächst bei PCB Pool bestellen und habe noch Platz auf der Platine - doppelseitig, DK, Verzinnt aber kein Stoplack. Wenn hier jemand an einem vernünfitgen redesign arbeitet bin ich gerne bereit es mit auf die Platine zu setzen, selbige machen zu lassen, wenn sie da ist die anderen Platinen auszufräsen und dem mit demjenigen per post zukommen zu lassen. Sorry das ich jetzt hier nach einer "Zusammenfassung" frage aber in 2 Treats zusammen knapp 400 Einträge lesen ist heftigst zumal hier einige bestimmt mehr Übersicht haben. Grüße! Tobi
Geht mir grad genauso, deswegen weiß ich nicht genau, wie Benedikt jetzt das Protokoll integriert hat, aber ich habe da auch eine Idee: Ein Ping/Pong Protokoll. Sprich: Die beiden Funkmodule spielen sich gegenseitig die Sendeerlaubnis zu. Es kommt dann ein kleiner Header in das Protokoll, mit der Länge der Nutzbytes in diesem Paket. Kommt nun an Transceiver1 ein Datenpaket über das UART, wird es einfach in den TX-Buffer geschrieben - fertig. Jetzt wartet Transceiver auf das nächste empfangene Paket. Guckt nach, ob Bytes im Paket sind. Wenn ja - legt er die Bytes in den RX-Buffer und startet einen Interrupt-gesteuerten UART-Versand. Danach kommt nun sein eigener TX-Buffer an die Reihe. Transceiver1 erstellt jetzt ein Paket und lädt die Bytes aus dem TX-Buffer in das Paket, und sendet das Paket. Das ganze passiert jetzt innerhalb Transceiver2. Also: Wenn keine Daten versendet werden, spielen sich die beiden Transceiver einfach nur leere Pakete zu. Haben sie was zu senden, hängen sie es an. Kommt was an - wirds über den UART ausgegeben. Ich hab nur gerade die böse Ahnung, dass Benedikt das bereits so integriert hat. Aber sicher bin ich mir nicht. PS: Ein Problem hat man bei der Variante noch: Welcher Transceiver startet den ersten Sendeprozess um den Ping/Pong Prozess anzustoßen...
Da sich vermutlich an dieser Software demnächst kaum noch viel an den Features ändern wird, hier mal die zusammenfassung der letzten Version: Die Software stellt eine transparente RS232 Verbindung dar, verhält sich also im Prinzip wie ein RS232 Kabel, allerdings mit einer Laufzeit von worst case wenigen 100ms. Die Baudrate ist über DIP Schalter an PortC von 1200 bis 115200Baud einstellbar (siehe dazu auch Software mit den Zusatzbemerkungen.) Hohe Baudraten werden zwar unterstützt, das Modul wird aber mit maximal 50kBaud betrieben. Man kann die 115200Baud also nicht voll ausnutzen. Bei so hohen Datenraten sind die Fehlerrate und die Reichweite meiner Meinung nach zu schlecht, daher diese Einschränkung. 20m 19200Baud voll ausgenutzt mit Halbduplex über 20m sind aber bei mir zumindest kein Problem. Über die DIP Schalter lässt sicher außerdem eine von 4 möglichen Frequenzen einstellen (alle innerhalb des zulässigen 433MHz Bandes). Die Daten werden mit einem einfachen Protokoll übertragen: - Status (momentan nur als Empfangsbestätigung genutzt) - Anzahl der zu übertragenden Bytes - Paketnummer (um Mehrfachübertragungen zu erkennen) - Nutzdaten Nach jeder Übertragung wird eine Empfangsbestätigung gesendet. Falls diese ausbleibt, wird automatisch das Paket nochmal gesendet, solange bis die Bestätigung eintrifft, oder die Anzahl einen eingestellten Wert überschreitet. Die Empfangsbestätigung wird nur gesendet, wenn die Daten fehlerfrei empfangen wurden. Da das ganze im Ping-Pong Verfahren läuft, und in jedem Paket Nutzdaten enthalten sein können, kommt jeder der beiden Teilnehmer abwechselnd dran um seine Daten loszuwerden. Dadurch teilt sich die Bandbreite auf beide Richtungen gleichmäßig auf. Sollte der 512Byte große Eingangspuffer zu mehr als der Hälfte gefüllt sein, wird ein Pin aktiv der mit CTS verbunden werden kann, um so ein einfaches Handshaking zu ermöglich.
Hi Benedikt! Ersmal danke da Du dir a) die Mühe gemacht hast diesen Riesenhaufen Arbeit zu machen und b) hier alles zusammengefasst hast. Noch ein paar fragen - Geschrieben in AVRGCC vermute ich? Gibt es fertig compilierte HEX files? - Ich bin halt Codevision Anhänger Welche Hardware wird benutzt? Die von Manuel? Gibt es ein Simpel Moduld was kein USB hat oder kann das bestehende ohne USB genutzt werden? Nochmal Sorry fürs blöd fragen aber eine Zusammenfassung ist sicherlich von vielen begrüßt. Sollte ich das mit dem rework des designs besser in den Threat posten in dem das "originaldesign" auch ist? Tobi
Benedikt, wodurch wird denn der "Ping-Pong"-Prozess angestoßen? Durch den, der als erstes was zu senden hat? Was ist wenn beide genau gleichzeitig senden? ;)
Man könnte den Ping Pong prozess anstossen indem wirklich beide zufällig senden jedoch mit unterschiedlichen "Wartezeiten" für die Initiallisierung. Wenn es auf der Luftstrecke kracht dann wartet einer z.B. 200 ms und der andere 500 ms (vielleicht "zufällig"?) bevor er es erneut probiert so das dann einer irgendwann senden kann und der andere es empfängt und bestätigt. Kam mir nur grad so in den Sinn.
Tobias A. wrote: > Man könnte den Ping Pong prozess anstossen indem wirklich beide zufällig > senden jedoch mit unterschiedlichen "Wartezeiten" für die > Initiallisierung. > Wenn es auf der Luftstrecke kracht dann wartet einer z.B. 200 ms und der > andere 500 ms (vielleicht "zufällig"?) bevor er es erneut probiert so > das dann einer irgendwann senden kann und der andere es empfängt und > bestätigt. > > Kam mir nur grad so in den Sinn. Wenn ich beiden unterschiedliche Wartezeiten einprogrammiere, brauche ich ja wieder 2 "verschiedene" Programme. Zufällig: Auch problematisch, da man keine gescheite Zufallsquelle ohne weiteres in nem Mikrocontroller hat.
Hmmmm... die AVRs haben doch ne seriennummer, oder? Können die die selbst lesen? Damit könnte man doch dann was machen, oder? Ausserdem denke ich das das Problem nur dann wirklich kritisch wird wenn beide Module 100 gleichzeitig angeschaltet werden bzw. die zyklen synchron sind. Alternativ könnte man auch mehrere Wartezeiten nehmen und die durchtesten. Alternativ hochzählen so im Stil von For i = 1 to 25 Begin delay_ms(20 * i) End Weil die wahrsch das man dann beide Module synchron hat ist dann sehr gering und notfalls muss man eins mal resetten. Oder man treibt es noch weiter und bringt es dazu sich selbst zu resetten indem man den C am RC des Reset pins mit einem Widerstand und Portpin richtung masse entläd. Die R und C toleranzen sollte dann spätestens ausreichen damit sich das einpendelt. Wie gesagt das kam mir nur so in den Sinn.
Benedikt K. wrote: > Dadurch teilt sich die Bandbreite auf beide Richtungen gleichmäßig auf. Wenn ich den bisherigen Thread und den Rest Deiner Beschreibung richtig verstanden habe, stimmt das nicht ganz. Die Bandbreite wird dann gleichmäßig aufgeteilt, wenn von beiden Seiten ständig Daten gesendet werden. Sobald eine Seite die Pakete aber nicht bis zur maximalen Größe auffüllt, steht die restliche Bandbreite der Gegenseite zur Verfügung. > Sollte der 512Byte große Eingangspuffer zu mehr als der Hälfte gefüllt > sein, wird ein Pin aktiv der mit CTS verbunden werden kann, um so ein > einfaches Handshaking zu ermöglich. Um die Transparenz der Strecke weiter zu erhöhen, könnte man auf beiden Seiten noch die RTS-Leitung des angeschlossenen Geräts überprüfen und in die Flußsteuerung einbeziehen.
Moin, also ich habe schon ein einfaches Ping-Pong gebaut und die Datenpakete und crc16 implementiert. Ich schätze am Ende der Woche wird dann alles fertig & nutzbar sein. Ich werd's dann in ein öffentliches svn stellen und hier verlinken. Zum Thema Device IDs: Ich habe mir schon nen Wolf danach gesucht, die Device ID von nem AVR rauszubekommen, allerdings ohne Erfolg. Allerdings gibt es noch drei evtl. brauchbare Alternativen: 1. Device lauscht erstmal für ein paar Sekunden und guckt, welche Device IDs es denn schon so gibt. Dann fängt es an zu senden und fragt, ob jemand die Adresse bereits hat (via Ping), wenn ja, zählt es die Adresse solange hoch, bis niemand mehr antwortet und nimmt sich dann die Adresse. Dann weiss man allerdings nach einiger Zeit garantiert nicht mehr, welches Gerät welche adresse hat und bräuchte zusätzlich eine Namensauflösung. Aber auch den Namen muss man dem Ding erstmal geben, womit wir wieder am Anfang des Problems wären ;) 2. Man speichert im EEPROM einfach die ID. 3. Man compiled für jedes device die Software neu und generiert sich eine ID aus den Macros _TIME_ und/oder _DATE_ (und brennt diese dann ins EEPROM)...
Tobias A. wrote: > Hmmmm... > > die AVRs haben doch ne seriennummer, oder? Können die die selbst lesen? > Damit könnte man doch dann was machen, oder? Eine Seriennummer nicht. Aber die Idee ist garnicht mal so schlecht: Ich kann mit meinem AVRISP MKII ein Calibration Byte anzeigen lassen. Das könnte ich sogar in die letzte Flashzelle schreiben (so wie das idR auch gemacht wird). Für den einen Prozessor war das für 8MHz zum Beispiel 0xC2 und für den anderen 0xC4.... Hm! > Ausserdem denke ich das das Problem nur dann wirklich kritisch wird wenn > beide Module 100 gleichzeitig angeschaltet werden bzw. die zyklen > synchron sind. Könnte doch durchaus passieren... > Alternativ könnte man auch mehrere Wartezeiten nehmen und die > durchtesten. Alternativ hochzählen so im Stil von > > > For i = 1 to 25 > Begin > delay_ms(20 * i) > End > > Weil die wahrsch das man dann beide Module synchron hat ist dann sehr > gering und notfalls muss man eins mal resetten. Nuja, eben. Man muss einfach eine Unterscheidung zwischen den Mikrocontrollern haben, obwohl das gleiche Programm drin ist. Sag du mal einem Käufer dieser RS232 Funkbrücke "Ja, resetten sie mal die eine Seite" ;) PS: Habe das gerade auch in meine TRW24G 2,4ghz Funkmodule mal implementiert. Im moment habe ich noch eine Präpro-direktive "INITIATE". Für einen Controller setze ich die einfach, für den anderen nicht. Da ich das ganze aber eher als "Modul" in meine Software hängen will, wäre ne möglichst einfache Lösung schon nicht schlecht.
Sören H. wrote: > Zum Thema Device IDs: > Ich habe mir schon nen Wolf danach gesucht, die Device ID von nem AVR > rauszubekommen, allerdings ohne Erfolg. Die kann man nur per Programmer auslesen, und selbst wenn: Aller AVRs eines Typs haben die gleiche ID, also bringt das nichts. Mehrer IDs machen bei 2 Teilnehmern recht wenig Sinn. Sobald es mehr werden braucht man die, das ist klar, aber in den meisten Fällen reicht eine einzige Punkt zu Punkt Verbindung. Simon Küppers wrote: > Benedikt, wodurch wird denn der "Ping-Pong"-Prozess angestoßen? Durch > den, der als erstes was zu senden hat? Was ist wenn beide genau > gleichzeitig senden? ;) Dann gibt es Probleme. Allerdings habe ich den Timer der als Timeout für eine Nochmal-Übertragung dient absichtlich auf 2ms Auflösung eingestellt. Dies ergibt eine hohe Warscheinlichkeit, das eines der Module etwas früher sendet als das andere und dass es danach wieder klappt. Tobias A. wrote: > Noch ein paar fragen - > Geschrieben in AVRGCC vermute ich? Gibt es fertig compilierte HEX files? > - Ich bin halt Codevision Anhänger Ja. main.hex in der Zip. > Welche Hardware wird benutzt? Die von Manuel? Meine, siehe Zip Datei. > Gibt es ein Simpel Moduld was kein USB hat oder kann das bestehende ohne > USB genutzt werden? Meines läuft mit RS232, man kann es also mit TTL RS232, mit einem MAX232 oder einem FT232 verwenden. Reinhard Max wrote: > Benedikt K. wrote: >> Dadurch teilt sich die Bandbreite auf beide Richtungen gleichmäßig auf. > > Wenn ich den bisherigen Thread und den Rest Deiner Beschreibung richtig > verstanden habe, stimmt das nicht ganz. Die Bandbreite wird dann > gleichmäßig aufgeteilt, wenn von beiden Seiten ständig Daten gesendet > werden. Sobald eine Seite die Pakete aber nicht bis zur maximalen Größe > auffüllt, steht die restliche Bandbreite der Gegenseite zur Verfügung. OK, stimmt. Hatte ich etwas dumm beschrieben. Der wo mehr sendet bekommt mehr Bandbreite, aber der wo weniger sendet wird seine Daten trotzdem los. Ist etwas schwierig zu beschreiben. >> Sollte der 512Byte große Eingangspuffer zu mehr als der Hälfte gefüllt >> sein, wird ein Pin aktiv der mit CTS verbunden werden kann, um so ein >> einfaches Handshaking zu ermöglich. > > Um die Transparenz der Strecke weiter zu erhöhen, könnte man auf beiden > Seiten noch die RTS-Leitung des angeschlossenen Geräts überprüfen und in > die Flußsteuerung einbeziehen. Muss ich mal versuchen. Allerdings wird das ein wenig Arbeit, da ich dazu die UART Routinen großteils umschreiben muss, und auch das RTS Signal über Funk an den Sender weiterleiten muss, damit dieser nicht weiter sendet. Es kann also noch ein weilchen dauern, denn ich habe ehrlich gesagt keinen Bedarf dafür, da ich keinerei Hardware besitze die dieses Feature benötigt.
Hi Benedikt danke >> Welche Hardware wird benutzt? Die von Manuel? >Meine, siehe Zip Datei. Sind die Layout files frei verfügbar? Tobi
Wenn es ein Layout geben würde, dann würde ich dieses hier reinstellen. Momentan ist alles auf Lochraster aufgebaut.
Hi Benedikt - ist es ok wenn ich ein Layout gemäß deines Schaltplans erstelle und hier reinstelle? Tobi
Kannst du gerne machen. Seh mal PD3 als CTS Eingang vor mit dem andere Geräte den Empfänger ausbremsen können. Davon abgesehen, denke ich nicht, dass sich demnächst die Pinbelegung ändert. Um ganz sicher zu gehen, könntest du noch FFIT an PB0 legen, falls das Modul auch mal Interruptgesteuert betrieben wird.
Soll ich die Version mit oder ohne Dip Brücke machen? Nur so generell: was meinst Du zu folgendem? Keine Dipbrücke dafür ein extra Pin der dem Mega entweder in einen Konfigmodus versetzt so das die Daten die via rxd reinkommen zum Konfigurieren verwendet werden können. Z.B. Mega Pin auf High - normaler Betrieb - daten werden ans Sendemodul weitergereicht und emfpangene daten vom Sendemodul an TXD ausgespuckt. Mega Pin auf Low - konfigurations betrieb - gesendete Zeichen werden zum setzen von Baudrate etc verwendet und quittiert. Nur ein Vorschlag, bin natürlich auch gerne gewillt eine der exisitierenden Versionen umzusetzen. Tobi
Mir ist es egal, ich kann sowas einbauen. Bei dem DIP Schalter hatte ich mir nur folgendes gedacht: Man kann jederzeit ohne spezielle Software die Einstellungen verändern. Denn die Erfahrung zeigt: Immer genau dann wenn man die Konfigurationssoftware braucht, hat man sie nicht.
Das kommt auf die Gestaltung des Konfigurationsmodus an. Wenn er Textbefehle akzeptiert reicht als Konfigurationssoftware ein Terminalprogramm, was heute bei praktisch allen Betribssystemen zum Bordwerkzeug gehört.
>Bei dem DIP Schalter hatte ich mir nur folgendes gedacht: Man kann >jederzeit ohne spezielle Software die Einstellungen verändern. und es ist eine sichtbare Kontrolle der eingestellten Baudrate da. ohne irgendwelche Ports zu belegen. Ich finde die Dipschalter-Variante durchaus Praktisch. aber das ist wohl sicher Ansichtssache. Respekt Benedikt! Wigbert
Wigbert P. wrote: > und es ist eine sichtbare Kontrolle der eingestellten Baudrate da. > ohne irgendwelche Ports zu belegen. Belegen die DIP-Schalter denn keine Portpins? ;)
Ok, richtig. Ich fand das eben praktischer, als noch LED's einzubauen. und erst noch Software-Einstellungen durchführen zu müssen. Ist vielleicht auch Anwenderbedingt. >aber das ist wohl sicher Ansichtssache!! egal "Jedem das Seine" Wigbert
@ Reinhard genau das hatte ich auch im Sinn Man lässt das Modul bei Startup in einer bestimmten baudrate laufen und ändert sie dann bei bedarf via textcommando.
@ Benedikt <Kannst du gerne machen. Seh mal PD3 als CTS Eingang vor mit dem andere <Geräte den Empfänger ausbremsen können. Davon abgesehen, denke ich <nicht, dass sich demnächst die Pinbelegung ändert. Um ganz sicher zu <gehen, könntest du noch FFIT an PB0 legen, falls das Modul auch mal <Interruptgesteuert betrieben wird. Warum PD3 und nicht 2 so wie im schaltplan? Warum FFIT and PB0 wo doch der Prozessorinterrupt auf PD2 und PD3 liegt? oder meinst Du es umgekehrt - das modul interrupten?
Das passt schon so: PD0 RXD PD1 TXD PD2 CTS PD3 RTS PB0 FFIT Ich nutze den Input Compare Interrupt als Externen Interrupt. So habe ich alle RFM12 Pins an PortB und nirgendwo anderst.
ok wird gemacht. Morgen gegen mittag sollte ich fertig sein. Will gleich mal ins Bett.
Angehängte Dateien:
-
rfm12schematic.JPG
1000 KB
ok konnte es doch nicht lassen hier mal der Schaltplan
Angehängte Dateien:
-
rfm12layout.JPG
130 KB
und hier das Layout bei einer 1.6 mm Platine muss ich nochmal gucken wie das mit den 50 Ohm für die Antenne wird. Aber bei dem Modul wage ich eh zu bezweifeln was passiert wenn man vom Modul auf die Trägerplatine wechselt. Ich hab grad die Formel für Microstrip Transmission Line nicht im Hinterkopf. Irgendwer generelle Kommentare? Ich mag das mit der Konfiguration via Terminal Programm anstatt DIP Schalter. (Wenn Du willst Benedikt mach ich noch ein 2. Layout) Macht die Sache kleiner und billiger (weniger PCB platz und die DIP Brücke spart man auch)
Tobias A. wrote:
> Irgendwer generelle Kommentare?
IEH. Benutzt du keine oktagonalen Vias? ;)
Sieht ansonsten nett aus, aber ich würde dir das .png Bildformat statt
.jpg empfehlen bei Schaltplänen/Boards.
Jut nacht!
Wie wird der mega8 programmiert ? Ich sehe nirgends eine Verbindung zu den ISP Pins.
Hi Benedikt ja Du hast recht das ist mir gestern entfallen - wollte ich noch machen. Magst Du mir mal einen Gefallen tun und gucken ob Deine Schaltung noch mit sagen wir 5 bis 10 k in Serie in den Datenleitungen funktioniert? Dann schnall ich die zwischen Funkmodul und ATMEGA und den Programming header direkt dran. Je nachdem werd ich auch noch die LEDs draufsetzen. @ Simon doch auch. Mir war nur grad nach eckig :-) Hast aber natürlich recht - anders siehts besser aus. Tobi
Tobias A. wrote: > Hi Benedikt > > ja Du hast recht das ist mir gestern entfallen - wollte ich noch machen. > Magst Du mir mal einen Gefallen tun und gucken ob Deine Schaltung noch > mit sagen wir 5 bis 10 k in Serie in den Datenleitungen funktioniert? > Dann schnall ich die zwischen Funkmodul und ATMEGA und den Programming > header direkt dran. Das brauch ich garnicht auszuprobieren, denn es geht ziemlich sicher nicht. Was sollen die denn bewirken ?
Hallo Benedikt und Tobias >mach ich noch ein 2. Layout bevor Du Dich in Unkosten stürzt. Ich werde Benedikts Vatiante(mit Dip-Schalter) aufbauen. Benedikt ich hoffe Du bist einverstanden. Dabei werden Dip-Codier-Drehschalter verwendet. Es wird ein Max 3232 o.ä. drauf sein(weil ich das so brauche) Das ganze sollte über ein kleinen Akku(Grösse hängt vom Gehäuse ab) versorgt werden. Und Platinenantenne. Und Gehäuse. Schön wäre es, wenn eine AKkuspannungsanzeige im Code mit eingearbeitet würde.Die 4 LED's leuchten bei 100%, 3 bei 75%,2 bei 50%,1 bei 25% Wenn ein Taster gedrückt ,Sprung in Akkukontrolle.Spannung extern mit Spannungsteiler einstellbar. 2ADC Pins wären ja noch frei. Vielleicht hast Du Benedikt an einen Regentag mal Langeweile. Wigbert
Hi Benedikt die bewirken folgendes: Die Ausgänge des AVR gehen direkt zum programming header und von da aus über einen Widerstand zum Funkmodul. Wenn man nun programmiert und sagen wir ein "high" auf einer Programmerleitung liegt das Funkmodul aber ein "low" zieht würde es ohne die Widerstände "krachen" und es könnte sein, das irgendwas beschädigt wird. Mit den Widerständen sind die Ausgänge der Funkmoduls quasi pullup bzw pulldown je nachdem wie sie grad "stehen". Wenn die Schaltung oben funzt, werd ich noch ein "Master"Modul entwickeln was dann via FTDI chip eine USB verbindung herstellt. @ wigbert ok dann mach Du das. Arbeitsteilung ist immer gut :-) Ich würde allerdings (wenn ich Dir widersprechen darf) sagen das es vielleicht erstmal wichtiger ist die Latenzzeiten etwas zu drücken anstatt das ganze weiter aufzublasen - es sollte ja einfach sein. Ich weiss sowieso nicht wie busy der Mega 8 ist. Wenn der ziemlich ausgelastet ist, ist mit extra programm für andere anwendungen reinbrennen eh nicht viel und man braucht einen 2. µC. (nur daten ins nirvana senden macht ja auch keinen Sinn) und mit dem könnte man dann die Batterieüberwachiung machen. Das hier sollte ja wenn ich es richtig verstehe ein sehr spartanisch gehaltenes, schnick-schnack freies (wie Hornbach G) modul werden was als Funkbrücke fungiert. Tobi
Tobias A. wrote: > Wenn man nun programmiert und sagen wir ein "high" auf einer > Programmerleitung liegt das Funkmodul aber ein "low" zieht würde es ohne > die Widerstände "krachen" und es könnte sein, das irgendwas beschädigt > wird. Häng einfach einen Pullup an nSEL, so wie ich es gemacht habe. Dann ist das RFM12 abgeschaltet und man kann auf den Pfusch mit den Widerständen verzichten. Das funktioniert sicher und ist weniger Aufwand.
"man kann auf den Pfusch mit den Widerständen verzichten." Das ist von einer Atmel appnote aber ok. Ich werd dann gleich die änderungen vornehmen.
Hi Tobi, die Entwicklung dieser Funkbrücke ist wohl soweit abgehakt. Ich möchte wohl so ähnlich wie Benedikt ein "drahtloses RS232 Kabel" mir herstellen, mehr eben nicht. Schnickschack kann hilfreich sein, wie Baudrateneinstellung, na ja und manchmal hätte ich gerne gewusst, schaffst Du den Download mit den Akku oder nicht.Ich wollte eigentlich nur wissen ob ich Pins auf den Board vorsehen kann oder nicht. Aber wenn das nicht geht, auch nicht weiter schlimm. Wigbert
Angehängte Dateien:
-
rfm12layout.png
21 KB
und das layout damit gewinne ich allerdings keinen HF design oder EMV preis.. ist 35 x 35 mm. Die Maße kommen daher damit es in eine meiner Schaltungen passt. Erstmal gucken obs geht - redesign wird dann später gemacht. Tobi
Mag noch jemand daran kritisieren oder Anmerkungen machen bevor ich es auf die Platine schmeisse und wegschicke? (Willst Du auch 2 Benedikt?)
Falls Du es noch etwas kleiner bekommen möchtest, könntest Du den ATmega und das Vogelfutter auf die Rückseite setzen und den ISP-Stecker neben den Antennenanschluß legen.
@ Tobias A. Wie du selbst schon sagtest: HF mäßig ist das Layout nicht so optimal. Vor allem die Masseeverbindung des könnte man sicherlich noch verbessern. z.B. C4 sitzt doch direkt neben dem GND Pin des RFM12. Der Umweg über die Massefläche ist da unnötigt. Ich bin jetzt auch kein HF Profi, aber wäre es nicht für den Anschluss der Antennenbuchse günstiger, wenn auch auf der Oberseite noch eine GND Verbindung zu dieser vorhanden wäre ? Ich brauche von den Platinen keine, ich kann selber ätzen.
Hallo Benedikt, noch eine Frage zu den Dipschalter. Bei 4 Pins kriege ich mehr als 7 Schalterstellungen hin. Auch beim Dualcode würden 3 reichen. Schaltet ein Dipschalter die Baudratenumschaltung zu? Irgenwie kann ich das nicht erkennen. Die Kanäle sind klar. Wigbert
Ich sehe gerade, da bin ich um ein Bit verrutscht: PortC0-2: Baudrate PortC3-4: Kanal PortC5: unbenutzt
Hi Benedikt - ja man könnte es noch oben mit Massefläche machen aber 480 MHz sind ja noch nicht soo schnell.. auf der "Arbeit" arbeiten wir mit bis zu 8.5 GHz.. da gehts dann richtig ab. Kannst Du auch durchkontaktieren Benedikt? Ich bin mit dem Layout soweit und kann Dir gerne das EAGLE file zukommen lassen wenn Du dir 2 Prototypen bauen willst. Falls Du nicht DKen kannst kann ich auch einfach 2 mehr mit auf die Platine setzen und Dir dann per post zukommen lassen. Wie gesagt ich sehe das hier als Prototyp - wenn alles klappt dann werd ich das nochmal weiter optimieren und auch die von Dir angesprochenen Masseflächen hinzufügen. Ich habs halt wirklich spartanisch gehalten mag es aber so. Auch grad mit der Softwareconfiguration (in der Hoffnung das Du die dann noch implementierst). Grüße Tobi
Angehängte Dateien:
-
rfm12_modul.jpg
120 KB
Leider kann ich keine doppelseitigen Platinen ätzen, daher habe ich mir diese Platine im Anhang gebastelt. Angefangen habe ich mit 3 Drahtbrücken, mittlerweile habe ich das ganze auf 1 Brücke optimiert. Diese Platine hat alles was ich brauche: Es sind einige PortC und PortD Pins rausgeführt, um LEDs anzuschließen, ebenso der ISP Port und das ganze ist kompakt. Allerdings bin ich in letzter Zeit dazu übergegangen, die Platine größer zu machen, da dies eine bessere Reichweite ergibt (Groundplane).
Hi Benedikt - das sieht mal richtig gut aus! >Allerdings bin ich in letzter Zeit dazu übergegangen, die Platine größer >zu machen, da dies eine bessere Reichweite ergibt (Groundplane) Schon mal probiert ein Coaxkabel mit dem schirm auf Masse zu legen und den Innenleiter an den ANT Ausgang? Das ganze bisschen weggeführt von der Platine und dann aufgedröselt so das der Schirm einen, der Innenleiter den anderen Arm eines Dipols gibt? Ok man bräuchte generell einen Balun weil der Dipol sonst "schielt" aber ich denke es sollte besser sein als ein Monopol... (die Diskussion sollte man vielleicht sogari m HF Forum führen). Das würde die Platine klein halten. Bei "meinem" Design ist ein SMA stecker vorgesehen das man sich eventuell eine geätzte Antenne aufschrauben kann bzw was extern an einem Kabel anschliessen. Alternativ lässt man den SMA weg und lötet nur ein Stück Draht ein. Wärst Du dann eventuell gewillt die Software für "mein" Layout anzupassen? Sprich "Konfiguration via serieller Schnittstelle"? Wie oben schon erwähnt? Falls ja geht die Platine morgen raus - musste noch eine andere Platine mit auf den Nutzen setzten deshalb die Verzögerung. Tobi
Tobias A. wrote: > Schon mal probiert ein Coaxkabel mit dem schirm auf Masse zu legen und > den Innenleiter an den ANT Ausgang? Das ganze bisschen weggeführt von > der Platine und dann aufgedröselt so das der Schirm einen, der > Innenleiter den anderen Arm eines Dipols gibt? Ok man bräuchte generell > einen Balun weil der Dipol sonst "schielt" aber ich denke es sollte > besser sein als ein Monopol... (die Diskussion sollte man vielleicht > sogari m HF Forum führen). > Das würde die Platine klein halten. Muss ich mal ausprobieren. Was wäre, wenn ich das Kabel 15 cm lang abisolieren, und den Schirm in 4 Teile auftrennen würde, die im 45° Winkel schräg nach unten stehen ? Die würden doch dann die GND Plane für die Antenne darstellen ? > Wärst Du dann eventuell gewillt die Software für "mein" Layout > anzupassen? > Sprich "Konfiguration via serieller Schnittstelle"? Wie oben schon > erwähnt? Ich bin gerade dabei. Sind 19200 Baud OK ?
Hier nun die Software: Wird der Config Pin auf GND gelegt, startet das Modul im Config Mode. Dann wird ein einfaches Menü dargestellt, über das sich Baudraten und Funkkanal einstellen lassen. Sowohl mit Hyperterminal als auch hterm funktioniert das Menü. Die Baudrate im Config Mode ist auf 19200Baud eingestellt. Die Eingabe der Ziffern wird durch ein folgendes Return oder Leerzeichen beendet.
Hallo Benedikt, nur damit ich es richtig verstehe. Wenn alle Dip-Schalter 0 sind, kann ich mit Config Pin die Software-Einstellung vornehmen. Es ist also beides möglich? Der Code sieht wenigsens so aus. Wigbert
Hi Benedikt 19200 klingt gut! Ich hab noch nicht in den Code geguckt, aber "merkt" der Avr sich die Einstellungen? Das mit der von Dir beschriebenen Antenne sollte auch klappen. Ich meine zumindest das schon mal irgendwo gesehen zu haben. Ich komme nur grad nicht auf den Namen. Alternativ kann man die HF mit dem kabel auch irgendwo hinführen wo man eh eine Metallfäche im Gerät hat und dann dort den Monopol hinsetzen. Aber für eine allgemeine Anwendung ist es wie Du schon implizierst schön wenn man eine Antenna hat die alleine funktioniert und nicht auf zusätzliche Teile an einem Gerät angewiesen ist. Tobi
Wigbert P. wrote: > nur damit ich es richtig verstehe. > Wenn alle Dip-Schalter 0 sind, kann ich mit Config Pin die > Software-Einstellung vornehmen. Es ist also beides möglich? Der Code > sieht wenigsens so aus. Nicht ganze: Es funktioniert nur eine von beiden Möglichkeiten. Es wäre zwar möglich beides gleichzeitig einzubauen, aber das macht keinen Sinn. Tobias A. wrote: > Ich hab noch nicht in den Code geguckt, aber "merkt" der Avr sich die > Einstellungen? Ja, wird im EEPROM gespeichert. Standardeinstellung: 19200Baud.
Hallo Benedikt,
>Ja, wird im EEPROM gespeichert
also kann ich code check4 für die Dipschalter-Variante nicht benutzen?
Wigbert
Wenn du in der Software //#define USE_SOFTCONFIG // DIP Schalter/Jumper an PortC 0-4 #define USE_DIPSWITCH // DIP Schalter/Jumper an PortC 0-4 statte dem schreibst, was momentan drin steht schon. Allerdings ist diese Version dann identisch mit der check3 Version.
Hallo Leute, anbei mein Platinenentwurf der „Bidirektionalen Funkbrücke mit Baudrateneinstellung“ Die Platine sollte aus 2 seitigen beschichteten Epoxyd gefertigt werden, und hat die Abmaße 56mm x 56mm. Die IC’s sollten mind. 5mm vom RF12 Modul entfernt angeordnet werden und der Antennenanschluss so kurz wie möglich. Bedien-, Anzeige- und Schnittstellenbauteile werden seitlich herausgeführt. Das Ganze wird in einem Gehäuse, 100mm x 65mm x 25mm einschließlich 2 Stück 1,2V Akkus, Platz finden. Als Grundlage der Schaltung wurde Benedikts Beispiel verwendet. Die 5V Spannungsversorgung wird mit einen MAX1674 aus der Akkuspannung erzeugt. Bei Tiefentladung schaltet der IC die Spannung ab. Über ein Klinkenstecker kann die Schaltung extern versorgt werden. Bei der Einstellung Lad. ist ein Anschluss eines intelligenten Ladegerätes am selben Stecker möglich und der Ladevorgang wird eingeleitet. Es wurde bewusst 5V Betriebsspannung gewählt da die 10 MHz Takterzeugung bei der Vielzahl der einstellbaren Baudraten die wenigste Fehlerrate besitzt. Eine schnelle Baudratenumschaltung wird durch ein BCD-Codierschalter gewährleistet. Die Kanalwahl wird mit DIP-Schalter durchgeführt, da ein Kanalwechsel nur bei Störsendereinfluss bzw. den Einsatz mehrerer Funkbrücken notwendig ist. Den notwendigen Pegel der RS232-Schnittstelle stellt ein MAX232A….zur Verfügung. Die LED’s sind Low-Current-Typen. Über ISP kann der Controller programmiert werden. Der Antennenanschluss wurde 3pol.(2xGND) ausgeführt. Da die Antenne mit 10cm Koaxialkabel eingespeist wird, habe ich keine Lust noch Verluste am Stecker zu erzeugen. Deshalb wird die Ader mittig angelötet und der Schirm mit Hilfe einer übergestülpten Hülse an den beiden GND-Pins angelötet. Die Platinenantenne(eine Art Magnetantenne) wird nicht im Gehäuse integriert sein, sondern oben drauf. Aus folgenden Gründen: Bei ungünstiger Lage würde die Platine und deren Bauelementen die Antenne Abschirmen, bei ablegen auf metallenen Untergrund würde es bei der Antenne zu Wirbelströmen kommen. Von den Einsatz einer Groundplane (Drahtantenne) nehme ich Abstand, da die Radials ( Massefläche als Gegengewicht) mit zunehmender Miniaturisierung zu klein ausfallen. Die Antenne wird dann immer schwerer beherrschbar. Vielleicht hat jemand noch Verbesserungen und die endgültige Bauteilanordnung wird dann noch mal überarbeiten. Wigbert
Hi wenn Du keine Steckerverluste willst warum ziehst Du nicht einfach die Leiterbahn zum Rand der platine und lötest da das Kabel an? Für so was gibts sogar spezielle SMA stecker mit denen das geht. Beim Kabel einfach mittelpin an den Antennausgang und schirm auf die Massefläche. Ist besser als irgendwas impedanztechnisch unkontrollierbares wo das Kabel dann in dem Loch steckt und der Schirm irgendwie draussen drumherumgelötet ist. Nur als Anregung - generell muss ich sagen gefällt mir die Platine sehr gut. Konnte auch keine Fehler im Design entdecken - ausser eventuell nem Filter hinter dem Schaltregler? Längs L und parallel C filter? Ich weiss nicht wie der RFM12 auf ne "noisy" Spannungsversorgung reagiert. Grüße Tobi
Hallo Tomas, dank Dir. Hatte eigentlich den Stecker weglassen wollen. Werde mal sehen ob ich einen passenden industriellen Übergangsanschluss finde. Das Filter war im DBL nicht zu erkennen und Schaltungsbeispiele waren im Netz ehr dürftig. Wigbert
Hi datenblatt ist ja auch quasi nur Minimalbeschaltung. Kannst es ja eventuell mal vorsehen und im Ernstfall hinzufügen und sonst halt einfach das L mit ner Brücke kurzschliessen. Grüße Tobi
Hallo gemeinde. Ich habe 2 RFM12 Module, und wollte damit eine einfache RS232 Kommunikation aufbauen. Leider sind wir nach 3 Wochen schon so langsam am aufgeben, udn kommen einfach nicht weiter. Wir nutzen einen RFM12 als Dauersender, der ständig Daten in einer schleife raus schickt, und einen anderen um die Daten zu empfangen. Leider bekommen wir vom RX rein garnichts zurück. Wir können zwar die gesamte Konfiiguration setzen, sowei das Statusbyte auslesen, aber in bezug auf das RX-Command bekommen wir ständig nur 0len zurück. Ausprobiert haben wir mitlerweile sämtliche Codes, die hier gepostet wurde, sowie einige andere beispiele in bascom. keine scheinen zu funktionieren. Selbst die SPI Routine haben wir per hand nach geschrieben, um etwailige fehler dort drin auszuschliessen. Ebenfalls erfolglos. Wir haben auch die MISO leitung mit einem Pullup versehen. Nach dem Anlegen des CS Signals zieht der RFM12 die MISO auch herunter, jedoch ohne Daten zu schicken. Beim Statusbyte klaps allerdings problemlos. Leider ist das RFM12 Datenblatt vom Hersteller nicht besonders umfangreich. Deshalb haben wir uns teilweise auch mit dem Datenblatt vom RFM1 und anderen weiter informiert. Dort konnte man informationen über die its im Statusbyte auslesen, was im RFM12 nicht drin stand. Desweiteren ist mir aufgefallen, das auf der Platine RFM12S steht, udn nciht RFM12B oder RFM12 ... ist das ein unterschied?, gibt es hierfür ein gesondertes Datenblatt, das ich noch nicht gefunden habe? Kennt jemand dieses Problem eventuell? MfG TPM
Diese Programme hier funktionieren definitv. Wenn es bei dir nicht geht, hast du beim Aufbau irgendwas falsch gemacht. Wie schnell läuft dein AVR ? Falls er mit mehr als 10MHz versorgt wird, musst du den SPI Prescaler hochsetzen, das RFM12 kann maximal 2,5MHz verdauen.
Nun .. ich habs mit 4 SPI Varianten probiert. Einmal Soft-SPI einmal Hardware-SPI, einmal das SPI selbst gecodet, und einmal via PC ne SPI Routine. Was mich wundert ist einfach, das ich die ganze Konfiguraton setzen kann, auch das Statusbyte ausgelesen bekomme, aber keien Daten mit dem RX Befehl zurück erhalte. Ich versuch jezt einmal 2MHz max. Clockrate. Aber, ich bezweifel, das es was bringt, da ich es schon mit allen Potenzen ab 100KHz probiert hab, aber erfolglos. Wie gesagt, wenn nicht emhr als 2,5MHz verdaut werden können, dann versuch is es mal mit 2MHz clock. Vorerst mal Danke. MfG TPM
Hallo, nicht aufgeben, davor stand ich auch schon und nach einem Bier und einmal schlafen ging es weiter. zB hatte ich angenommen, dass der Fifo 16 Bytes gross ist und wunderte nicht, dass da nur 0 rauskam. Lade Dir mal den C Code runter, den ich gepostet habe und analysiere ob die Einstellungen und Verfahrensweisen die gleichen sind. Lese den Status vor jedem Senden aus und ebenso einmal nach der Empfangsumschaltung. Bei diesen Dingern scheint es auf jedes Detail anzukomen. Ausserdem reduziere die Empfindlichkeit der LNA und RSSI um 1-2 Punkte, sonst fängt sich der Empfänger nur Müll ein und erkennt ggf. die 2DD4 nicht. Viel Glück! PS: mein PIC Programmer (China Clone) gibt grad auf, ist ihm zu warm hier mit 36 Grad in der Dachstube. Nach Eisspray tat er es wieder.... alles schon sehr seltsam.
Christian Julius wrote: > Lese den Status vor jedem Senden aus und ebenso > einmal nach der Empfangsumschaltung. Bei diesen Dingern scheint es auf > jedes Detail anzukomen. Ich lese den Status nie aus, nur das erste Bit, bei mir funktioniert es trotzdem. Es ist also nicht unbedingt notwendig. > Ausserdem reduziere die Empfindlichkeit der LNA und RSSI um 1-2 Punkte, sonst fängt sich der Empfänger nur Müll ein und erkennt ggf. die 2DD4 nicht. Auch dieses Problem hatte ich noch nie. Ich vergleiche mal deinen Code mit meinem, irgendwo muss da ein gravierender Unterschied sein.
Hallo Benedikt, leider sind die Möglichkeiten dieses Forums begrenzt sonst würde ich mal ein paar Bilder schicken, was mein PIC-Baby hier so an Lichtsignalen und Texten ausgibt. Kann gut, sein, dass sich das Modul auch EMV einfängt, denn ist alles Lochraster mit Fädeldraht und dazu noch mit 30-40 Mhz Prozzis drauf. Vielleicht liegt es wirllich daran, ob das jemand mit SPI oder ohne gelöst hat oder ob man nur das erste Bit ausliest. Ich weiss es nicht. Fakt ist: Die Module funktionieren, man kann damit Daten senden und empfangen. Grad mal mit dem Brett in der Hand losmarschiert, den Sender aufs Autodach mit guter Groundplane und einem Schweissdraht als Antenne: ca 100m klappt es, dann ist auf wenige Meter weiter schlagartig Schluss, es gibt da eine sehr scharfe Reichweitengrenze. Mit gescheiter Antenne schätze ich mal müssten 200m Freiluft drin sein. Antennen kann man sich aus einer BNC Doppel Buchse mit Einbaukragen gut selbst bauen, vier Stäbe als Masse an die Löcher des Kragens löten, schräg nach unten, einen Stab in die BNC Buchse hinein und unten dann 50 Ohm BNC Kabel einstecken. (Fotoapparat hat meine Frau grad leider mitgenommen) Ich werde den sender morgen mal mit in die EMV Messkammer in der Firma mitnehmen, mal schauen wieviel dbm er so rausspuckt direkt an der SMA HF Buchse. Für mich bleiben noch die Fragen übrig: 1. Welche Einstellung für die FSK Bandbreite des Senders und welche für die bandbreite des Empfängers sind richtig bei den verschiedenen Baudraten? Da unterscheiden sich Beispiele und Datenblätter, die Beispiele sind alle mit 0x9850 initalisiert beim Sender und 134 khz beim Empfänger. 2. Wieso floaten bei mir die Bits dermassen rum und wieso tut es das FFIT Bit nicht? Das DQD und das RSSI funktioniert doch auch, also ist die Auslesung richtig. Die perfekte Abstimmung ist ohne Dämpfertzwerk und professionellen Geräten kaum machbar und die wird mir die EMV Abteilung kaum leihen, wenn die Stunde in der Absorberkammer (da passen auch Autos rein) dort mit 250€ berechnet wird. Also losmarschieren, Distanz messen, Parameter ändern und das slange bis man maximale Reichweite hat. Hier mal der Sendecode von mir, auf das Lesen des Statusregisters. Nehme ich den Befehl weg kommt kein nIRQ Signal als Reaktion auf ein Byte an das TX Register
1 | // >>>> TX: Senden einer Bytefolge + Checksumme <<<<<
|
2 | // <2 x 0xAA>, <Anzahl Bytes>, <Bytes>... <Bytes>, <Checksumme>, < Dummy>
|
3 | |
4 | #define RF_TX_ON 0x8239
|
5 | #define RF_TX_OFF 0x8209
|
6 | |
7 | void RFTX_Send(byte* data, byte size) |
8 | {
|
9 | byte check; |
10 | byte i; |
11 | |
12 | SSPSTAT_CKE = 1; |
13 | disable_interrupts(GLOBAL); |
14 | |
15 | RF_GetStatus(); // Notwendig, sonst klappt Senden nicht (seltsam!) |
16 | RF_CMD(0x8238); // Transmitter EIN |
17 | |
18 | RF_SendByte(0xAA); // Präambel ins Latch, lockt die PLL |
19 | RF_SendByte(0xAA); // Präambel ins Latch, lockt die PLL |
20 | RF_SendByte(0xAA); // Präambel ins Latch, lockt die PLL |
21 | |
22 | RF_SendByte(0x2D); // FIFO Schlüssel 2DD4 (öffnet das Tor) |
23 | RF_SendByte(0xD4); |
24 | |
25 | // --- Ab jetzt benutzerdefiniert ---
|
26 | |
27 | RF_Sendbyte(MASTER_START); |
28 | RF_Sendbyte(size); // Anzahl folgender Bytes senden (incl Checksumme) |
29 | check = size; |
30 | for (i=0; i<size; i++) // Datensatz senden |
31 | {
|
32 | RF_SendByte(*data); |
33 | check += *(data++); |
34 | }
|
35 | |
36 | RF_Sendbyte(check); // Checksumme |
37 | |
38 | RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer |
39 | RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer |
40 | RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer |
41 | RF_CMD(RF_TX_OFF); // TX off |
42 | |
43 | disable_interrupts(GLOBAL); |
44 | }
|
Christian Julius wrote: > Hallo Benedikt, > > Vielleicht liegt es wirllich daran, ob das jemand mit SPI oder ohne > gelöst hat oder ob man nur das erste Bit ausliest. Ich weiss es nicht. Ich habe es schon mit SPI und ohne laufen lassen. Das kann ich also ausschließen. Deine Initialisierung sieht gut aus. Es gibt zwar einige Unterschiede zu meinem Code, aber die sind alle unbedeutend. Du verwendest Interrupts, ich polle nur das erste Bits. Dies könnte der Unterschied sein. Ich wollte es mal mit Interrupts ausprobieren, bin aber noch nicht dazu gekommen. 100m Reichweite sind auch in etwa mein Messergebnis. Mit hoher Bandbreite und hohem Frequenzhub komme ich weiter als mit den Angaben aus dem Datenblatt. Das ist klar: Es wird mehr Bandbreite ver(sch)wendet, daher fallen Störungen nicht so sehr ins Gewicht. > 2. Wieso floaten bei mir die Bits dermassen rum und wieso tut es das > FFIT Bit nicht? Das DQD und das RSSI funktioniert doch auch, also ist > die Auslesung richtig. Bei mir wackeln alle Bits auch total rum, nur das FFIT Bit funktioniert wunderbar. Und das ist eigentlich das einzigste was mich auch interessiert.
Noch ein Zusatz speziell für Martin W. Wenn Du das Modul in den RX Mode gesetzt hast, alle benötigten Teileinheiten eingeschaltet sind und es richtig angeschlossen ist, dann lösche mal testweise das Flag welches den Fifo abschaltet und die Empfangsdaten auf den Data Pin ausgibt. Das Modul kann auf zweierlei Art betrieben werden, musste Dir mal im Datenblatt von HOPE raussuchen welche Bits das sind. Mit einem Oszi müsstest Du auf diesen Pin dann ein Datenchnos sehen, nämlich digitales rauschen. Auf der Clock Leitung nach aussen ebenfalls einen decodierten Clock. Dann weisst Du, dass Dein Empfänger arbeitet. Wenn Du nun schrittweise den LNA Gain und RSSI Threshold reduzierst, dann wird dieses Rauschen weniger bis es ganz verschwindet. Lege den nIRQ Pin auf einen Interruptsfähigen Pin des uC oder polle meinetwegen auf einem anderen Pin. Wenn das Modul die 2DD4 Squenz empfängt und in den Fifo schreibt geht dieses Signal auf Low und sofort wieder auf High, wenn der Fifo ausgelesen wurde. Nimm dazu das B800 Kommando, das geht schneller. So long, Christian (Autoschrauber und Scirocco Sammler)
Angehängte Dateien:
Bei mir wackeln alle Bits auch total rum, nur das FFIT Bit funktioniert wunderbar. Und das ist eigentlich das einzigste was mich auch interessiert. -------- Na toll, ich wackel grad auch, wenn ich die Dose Faxe hier auf habe, bei der Hitze hier im Rheinland kriegt man ja einen an der Waffel.... Hier ist übrigens die Lösung für Dein Reichweitenproblem. Mit dem Ding habe ich seinerzeit ca 10km geschafft, gespeist von einem Analog Modul von Radiometrix. ;-)))
Mit dem RX Commando (&hB800) sollten doch die Empfangenen Daten, bzw auch schrott, je nachdem, was grad auf der Welle reitet, auf der MISO leitung zurück kommen .. oder täusche ich mich da? ... so, wie das Statusbyte auf der MISO leitung ab dem ersten 0 Bit zurück geliefert wird. MfG TPM
Martin W. wrote: > Mit dem RX Commando (&hB800) sollten doch die Empfangenen Daten, bzw > auch schrott, je nachdem, was grad auf der Welle reitet, auf der MISO > leitung zurück kommen .. oder täusche ich mich da? Ja, du täuschst dich. Das Modul läd die Daten nur dann ins FIFO wenn das 2DDA Syncword empfangen wurde. Alternativ kann man das auch umstellen, dass das Modul jeden Mist ins FIFO läd, aber das macht eigentlich keinen Sinn. Du kannst es ja mal ausprobieren: Im FIFO Mode Register al auf 1 (always fill) setzen. Dann sollte der FFIT Pin sofort aktiv werden. Christian Julius wrote: > Na toll, ich wackel grad auch, wenn ich die Dose Faxe hier auf habe, bei > der Hitze hier im Rheinland kriegt man ja einen an der Waffel.... Ich habe hier gerade angenehme 22°C bei mir im Keller... > Hier ist übrigens die Lösung für Dein Reichweitenproblem. Mit dem Ding > habe ich seinerzeit ca 10km geschafft, gespeist von einem Analog Modul > von Radiometrix. ;-))) Nett. Wiviel Leistung liefert dieser Verstärker ? Ich habe schon seit Wochen eine halbfertige Platine mit einem 868MHz RFM12 und einer Handy Endstufe mit 3,5Wspitze hier liegen. Ich denke mal 0,5W Dauerleistung wird das Ding schon schaffen...
Benedikt K. wrote: > Nett. Wiviel Leistung liefert dieser Verstärker ? > Ich habe schon seit Wochen eine halbfertige Platine mit einem 868MHz > RFM12 und einer Handy Endstufe mit 3,5Wspitze hier liegen. Ich denke mal > 0,5W Dauerleistung wird das Ding schon schaffen... 7Watt ;) FFIT: Thx. .. probier ich mal MfG TPM
7W Class D Endstufe von Mitsubishi. Die aus dem Handy tun es aber auch, wenn man die Anschlussbelegung herauskriegt. Aber immer schon die Vdd abkoppeln, viele Drosseln einbauen und NIE vergessen die Antenne anzuschliessen, denn sonst raucht es, wie das Modul da oben, nur 47€ für ein Neues gebe ich nicht mehr aus.
isch will ja kein spielverderber sein... aber mehr als 10mw sind auf 433 nicht erlaubt.... ... außer ihr habt sowas http://de.wikipedia.org/wiki/Amateurfunkzeugnis
http://www.ero.dk/ http://www.bundesnetzagentur.de/media/archive/298.pdf http://www.ero.dk/documentation/docs/doc98/official/pdf/REC7003E.PDF 2 sehr interessante "Blätter" JimJim XUN Alternativ kann man auf 800MHz mit 500mW senden, ohne Duty, wenn man einiges aus den Vorschriften (Siehe oben) beachtet. Hatte da schon interessante gespräche mit der Bundesnetzagentur in Bonn. MfG TPM
Angehängte Dateien:
-
PIC00003__640_x_480_.jpg
58 KB
Wir sind ja alle gebildet und daher weiss ich auch dass man nicht unerlaubt funken darf. Trotzdem liegt dieses Steinchen hier noch seit 3 Jahren herum..... ein 20W Nachbrenner für 430 Mhz Funken. Nur leider kein Datenblatt mehr auftreibbar.
Christian Julius wrote: > Trotzdem liegt dieses Steinchen hier noch seit 3 > Jahren herum..... ein 20W Nachbrenner für 430 Mhz Funken. Nur leider > kein Datenblatt mehr auftreibbar. Schau mal hier .. anderer Typ (warscheinlich anderer Frequenzgang) aber selber baustein -> http://www.alldatasheet.com/datasheet-pdf/pdf/4756/MOTOROLA/MHW720A1.html MfG TPM
Hi, danke für den Link, scheint der Gleiche zu sein, nur minimal anders. Die stammen aus den 90igern hatte sie mal für 1€ bei ebay geschossen und seitdem liegen sie hier rum. Nachteil ist, dass die Dinger in Sekunden hinüber sind, wenn das Design und die Kühlung nicht perfekt stimmt und zudem brauchen sie 250mW Eingangsleistung. Des weiteren muss an den Ausgang ein entsprechendes Bandpassfilter geschaltet werden, das erst einmal dimensioniert sein muss, denn eine Class D Endstufe verursacht nackt wohl ganz erhebliche Oberwellenanteile. Meist gibt es einen Steuereingang für die Leistung. Und fürs testen muss man das eigene Zimmer wohl komplett mit Akufolie auskleiden, denn sonst rücckt einem schneller als lieb ist der Messwagenfuhrpark der ReTP auf die Pelle und das wird sehr sehr teuer. Ohne H Messgeräte zudem sehr schwierig. Einzige Anwendung, die ich sehe wäre eine Alarmalage für meine Halle, wo meine Youngtimer stehen, die ist ca 5km weit weg von mir. Aber da passt schon die Dogge des Landwirts auf, dass kein böser Bube meine Schätzchen klaut ;-) Ich glaube es reicht ein kleiner HF Transistor in Emitterschaltung aus, wenn man diese Minimodule auf ein klein wenig mehr aufbohren will, mit 15mW kommt man schon fast 1km weit. Eine Endstufe mit Bandpassfilter für 100mW habe ich als Schaltplan noch hier liegen, arbeitet mit BFR 193 Transen, die hatte mir mal ein Hersteller solcher Module zugefaxt. Werde das RFM12 heute mal in die EMW Kammer stecken und schauen wieviel da rauskommt, auf 10mW ERP darf man ja kommen.
die motorola module sind recht fein, hab selbst ein paar im einsatz., aber wie gesagt für den anwendungsfall etwas überdimensioniert. bin ja mal gespannt was bei deiner messung rauskommt...
Ich habe hier auch noch so ein Ding rumliegen. Sieht genauso aus, auch von Motorola, hat nur eine dumme Bezeichnung: 33Z01, Datecode: 9316. Stammt aus einem alten D1 Autotelefon. Laut Datenblatt sollten die RFM12 etwa 6mW liefern. Kennt jemand eine einfache Richtantenne (muss keine super Richtantenne sein, mir würde schon eine reichen die nur in 180° sendet und emfpfängt, hauptsache unkompliziert zu bauen) ?
Benedikt K. wrote: > Ja, du täuschst dich. Das Modul läd die Daten nur dann ins FIFO wenn das > 2DDA Syncword empfangen wurde. Alternativ kann man das auch umstellen, > dass das Modul jeden Mist ins FIFO läd, aber das macht eigentlich keinen > Sinn. Du kannst es ja mal ausprobieren: Im FIFO Mode Register al auf 1 > (always fill) setzen. Dann sollte der FFIT Pin sofort aktiv werden. 1A mit Sternchen! ... ENDLICH bekomm ich Datenchaos zurück ... und ich dachte schon, ich bin blöde ,) ... Der rest sollte dann wohl auch gehen, wenn der passende Code vorran gesendet wird. VIELEN DANK! MfG TPM
@benedikt: such mal nach quad oder doppelquad im google .... http://www.darc.de/g25/anleitungen.html
Hallo, habe grad mal einen Schwatz mit unserem HF Freak gemacht, der auch lizensierter Funkamateur ist und hier die EMV Messungen betreut. Diese Module sind seiner Ansicht nach durch Hobbybastler gar nicht zu dimensionieren, da muss man schon Stehwellenmessgeräte und Wobbler haben, um die Ausgangsimpedanz von typisch 1 Ohm auf 50 Ohm zu bringen. Besser wäre es 1:1 fertige Lösungen nachzubauen. Sonst kann es passieren, dass die Module auf allen Frequenzen rausbrüllen. Kam natürlich die eindringliche Warnung, dass er jeden Störer seiner Bänder zur Anzeige bringen wird :-) EMV Absorber Kammer heute leider nicht benutzbar, mal die Tage schauen.... Gruss, Christian
Christian Julius wrote: >Eine Endstufe mit Bandpassfilter für >100mW habe ich als Schaltplan noch hier liegen, arbeitet mit BFR 193 >Transen, die hatte mir mal ein Hersteller solcher Module zugefaxt. Wie kan man einfach Edstufe auf Transceiver einfügen? Wie steht dan mit RX-Teil Eingang-Impedanz/Störungen? Grüße aus Croatien !
@ Christian Julius hmm... das stimmt nicht ganz. grundsätzlich sind die module sogar recht einfach zu handeln. ein freund von mir (auch afu) hat schon ein paar endstufen mit den dingern aufgebaut. und ich müsst mich jetzt schon sehr täuschen, aber normalerweise haben die dinger 50 Ohm ein und ausgangsimpedanz. das mit den störern auf den bänder stimmt natürlich :) das is mit den 10mw geräten schon schlimm genug. aber wenn du mit 7w rausbrüllst, wird jeder amateurfunker im umkreis von 10km sofort nachschaun was da los ist...
Also ich weiss ja nicht... das mit den Richtantennen mag ja für 2.4 GHz praktikabel sein für Heimanwendungen aber bei grob 400 MHz ist alles 6x grösser und wird dann gross und unhandlich. Gleichzeitig sammelt man sich mit der Antenne noch jede Menge "dreck" von andern Bändern auf und die blasen auch munter in das RFM12 rein und keiner weiss was die internen Filter des Moduls aushalten bzw welche Frequenzen die Filtern und ruck zuck ist das ding hinüber. Ich weiss sowieso nicht was ich von dieser etwas undefinierten Ausgangsimpedanz des Moduls halten soll. Wenn ja wenigstens ne 50 Ohm Leitung bis zum Rand des Moduls gehen würde oder im idealfall nen SMA Verbinder dran wäre würd ich ja mal nix sagen aber so... ich weiss nicht.. Man müsste mal bisschen rumprobieren aber dieser Lötübergang von dem halben Bohrloch auf eine darunterliegende Platine scheint mir Impedanztechnisch doch etwas undefiniert zu sein. Zum Verstärkerproblem - ja es gibt da was was erkennt ob es grad "rein" oder "raus" geht. Such mal nach WLAN verstärker - da hatte ich vor einiger Zeit mal nachgefragt. Tobi
Hallo, hatte grad nochmal Rücksprache mit unserem Amateuerfunker. der hat mir diese Nachbrenner empfohlen: MAR-1SM (DC bis 1 Ghz) + 17db. http://www.minicircuits.com/pdfs/MAR-1SM+.pdf Die blasen auf ca 15mW-202mW auf und garantieren, dass vielleicht 10mW ERP an der Antenne anstehen, das wäre dann auch legal. Habe den Disti mal angeschrieben, was die Dinger kosten. Klappt natürlich nur, wenn ein Modul nur sendet, empfangen geht dann damit nicht mehr. Gruss, Christian
Das mit der Impedanz ist halb so wild: Die Länge der Leiterbahn beträgt wenige mm, daher ist das ganze noch weit von der Wellenlänge entfernt. Eine falsche Impedanz bewirkt also fast nichts. Auch wenn es vielleicht nicht ganz ordentlich ist, für <5€ ist das schon OK. Bei dem Preis wäre ja alleine der SMA Stecker teurer. Die Module sind halt einfach nur dafür ausgelegt, dass man ein Stück Draht dranlötet, mehr nicht. Eine Richtantenne sammelt bei ordentlicher Ausrichtung übrigends meistens weniger Störungen ein, als eine normale Antenne, da die Signale nur aus einer bestimmten Richtung empfangen werden.
Hi Benedikt mit der Richtantenne geb ich dir recht - vorausgesetzt das der Störstrahler nicht zufällig grad in Hauptstrahlrichtung liegt. Mit der Leitungslänge hast Du recht.. ich denke immer noch in einigen GHz... frag mich nicht warum mir das bei Leiterbahnen immer entfällt.. @ Christian http://www.minicircuits.com/cgi-bin/modelsearch?search_type=model&model=MAR-1SM&tb_no=TB%2d411%2d1%2b guckst Du da.. ca 1.30 USD / stück. Mach 2 Euro draus dann ist es realistisch. Wenn ich in England was von Minicircuits kaufe ist es meisst Pfund gleich USD preis und zwischen Pfund und Euro steht ein Faktor 1.5 also einfach das auf der Webseite ungefähr mal 1.5 rechnen und Du hast den Preis. Tobi
Hallo, habe grad mit der Fa Municom telefoniert, die wäre bereit, da Gigacom pleite ist auch Endkunden zu beliefern, Dollar = Euro, Mindestbestellwert sind 50€. Einzelstück ca 2€. (1,03€ Listenpreis) Wer will denn noch solche Minibooster haben? Und wieviele? Die sind Plug & Play, also ideal geeignet. Gruss, Christian
Ich hätte prinzipiell interesse an den Dingern, Anzahl muss ich mir noch überlegen, rechne aber mal mit 5-10Stück, wenn der Preis nicht (oder nicht viel) über 2€ liegt.
Nur welcher ist jetzt der bessere? http://www.minicircuits.com/products/amplifiers_monolithic.html Ich meine der MAR 4SM+ bringt 12dbm am Ausgang, der 1SM nur 2,5db. Kosten beide das gleiche. Oder? Ich sage der Frau dann Sie soll 50€ vollmachen, vorrausgestzt es finden sich Leute, die noch welche brauchen, weil mehr als 10 brauche ich auch nicht.
Hi Christian, hätte Interesse an 5 Stück der o.g. Verst. Wigbert
Wenn ich richtig gerechnet habe, schafft der MAR4 etwa 18mW, der MAR1 dagegen nur 1,8mW. Es wäre also kein Verstärker, sondern ein Abschwächer. Leider sagen mir die meisten Daten nichts. Könnte mich mal jemand aufklären, was "N.F. (dB)" und "VSWR (:1), Out" bedeuten ? VSWR ist mir an sich klar, aber was bedeuted der Wert im Zusammenhang mit Ausgang ? "IP3 (dBm)" müsste die Verzerrung sein ?
Hätte auch interesse an 5 stk. ... kommt da eventuell ne sammelbestellungs-thread? MfG TPM
Hallo! Wenn ihr die Verstärker bestellt dann nehm ich auch 4 Stück. Hias
Werde heute abend mal einen Thread starten und Interessenten sammeln. Ich bestelle dann über die Firma die Dinger nachdem die mir ein Angebot gemacht haben. Bezahlung bitte per Vorkasse (zB Paypal) da ich hier niemanden persönlich kenne und das Risiko auch auf 50€ sitzen zu bleiben minimieren will.
Hi nochmal, habe grad mit dem FAE der Firma telefonoiert. Also die Module passen auf die Applikation, wenn vorne ein Sinus reingeht kommt der hinten auch verstärkt raus, jedoch nicht mehr mit 50 Ohm sondern weniger, das sollte klar séin. Um den wieder auf 50 Ohm zu bringen muss ein Anpassnetzwerk dran, was im einafchsten Falle aus einem Pi- Glied besteht aber eben dimensioniert werden will. So ist das nunmal in der HF Technik. Ob man an den Ausgang eine Antenne direkt machen kann weiss ich nicht, da müssten dann mal die HF Freaks hier sich zu Worte melden. Gruss, Christian
also erst ma wärs interessant zu wissen welche leistung die rfm12 module überhaupt von haus aus haben. laut datenblatt ja um die 6mw. von 6 auf 18mw zu verstärken bringt nämlich unterm strich fast garnix (faustformel vierfache leistung für doppelte reichweite)
Die BR-27 von ITE (OOK Modulation) haben ein ERP von 15mW und mit einem -103dbm Empfänger an einer abgestimmten Antenne habe ich damit 500m erreicht. Das Geheimnis der Reichweite liegt übrigens im erzielbaren Gewinn der Antenne, nur kriegt man die nicht für 2€ sondern muss schon 60€ auf den Tisch legen. Und 400m statt 200m sind mir schon 2€ wert.
Mich würde das Netzwerk interessieren das zur 50 Ohm Anpassung nötig ist. Außerdem, wie schauts mit der Rückkoppelung aus? (transceiver) Hias
Angehängte Dateien:
-
PIC00019.JPG
83 KB
Hallo Matthias, hier erst einmal ein Link für das Impedance Netzwerk, wobei noch nicht klar ist welche Impedanz dieser Verstärker am Ausgang hat. http://bwrc.eecs.berkeley.edu/Research/RF/projects/60GHz/matching/ImpMatch.html für das Entkopplungsnetz stelle ich hier einen Schaltungsvorschlag ein RX=Empfänger, TX = Sender). es werden also zwei Antennen werden, da die Pins im Chip miteinander verbunden sind. Nur befindet sich der Verstärker hinter dem Netzwerkwerk. Da ich RFM01 und RFM02m verwende ich das für mich weniger wichtig, ich will entweder nur senden oder nur empfangen. die Werte betragen: C1 = 5,6pf C2 = 5.6pf L1 = 22nH D1 = BAV 70 H1 = 50 Ohm Microstripline (2.7mm auf 1.6mm FR4 Epoxy mit Groundplane) Bei geätzen Platinen muss die HF also über eine 2,7mm breite Leiterbahn geführt werden, auf der Unterseite ist eine Groundplane. Für Bastelzwecke ist dieses allerdings nebensächlich, da muss man eh mit Verlusten leben.
Last but not least ein paar Erfahrungen mit den RFM12 von heute bei "Distanzmessungen", die auf einem Feldweg stattfanden. Laptop im Auto um den PIC schnell umzuprogramieren (die Leute hätten mich für gaga gehalten, die da vorbeigingen als ein Irrer mit einer Platine und dem Akku in der Hand losmarschierte ;-) Die angegebene Optimalbandbreite von 30khz ist sicherlich so nicht richtig, mehr Bandbreite des Senders ist so als wäre das Signal "lauter", die Reichweite nimmt deutlich spürbar zu. Habe sie jetzt senderseitig auf ca 90 khz eingestellt, den Empfänger auf 145 khz. Damit kann man locker noch 40 Kanäle spezifizieren mit je 250 khz Abstand. Mit den in den Codebeispielen angegebenen Einstellungen für LNA gain und RSSI Threshold (alles auf Maximum) ist das DQD Bit immer an, d.h. der Empfänger zieht sich jeden Müll rein. Trotzdem erkennt der die 2DD4 Sequenz noch. geht man mit dem Empfänger los so merkt man, dass die Fehlerraten langsam immer grösser werden, ich habe ca 150m auf Sicht erreicht bis gar kein Signal mehr vorhanden war. Stellt man den LNA gain um 1 herunter und ebenfalls den RSSI Threshold um 2 Punkte, so dass das DQD Bit im Takt des Senders blinkt ergeben sich andere Verhältnisse. Der Empfang liegt bis ca 100m bei 0% Fehlerrate, danach reisst er auf ca 5m schlagartig ab auf 0. Im Sinne einer fehlerfreien Datenübertragung durchaus gewünscht. So, das wars auch, gute Nacht! Gruss, Christian
Christian Julius wrote: > Laptop im Auto um > den PIC schnell umzuprogramieren (die Leute hätten mich für gaga > gehalten, die da vorbeigingen als ein Irrer mit einer Platine und dem > Akku in der Hand losmarschierte ;-) Ging mir genauso. Ich bin auch eine Runde ums Haus gefahren. > Die angegebene Optimalbandbreite von 30khz ist sicherlich so nicht > richtig, mehr Bandbreite des Senders ist so als wäre das Signal > "lauter", die Reichweite nimmt deutlich spürbar zu. Habe sie jetzt > senderseitig auf ca 90 khz eingestellt, den Empfänger auf 145 khz. Damit > kann man locker noch 40 Kanäle spezifizieren mit je 250 khz Abstand. Das deckt sich gut mit meinen Versuchen: Ein hoher Frequenzhub des Senders bringt mindestens doppelte Reichweite wie die Werte aus dem Datenblatt. Welche Bandbreite hast du beim Empfänger ingestellt ? 145kHz gibt es nämlich nicht. Mein Problem ist: Wenn man 90kHz Modulation verwendet, und sagen wir mal 19200Baud, dann ergibt das insgesamt etwa 2x 110kHz, also 220kHz Bandbreite des gesendeten Signals. Daher müsste man eigentlich mindestens 220kHz einstellen. Oder liege ich dabei falsch ? Wo sind die HF Speziallisten die sich mit sowas auskennen ? > Der Empfang liegt bis ca 100m bei 0% > Fehlerrate, danach reisst er auf ca 5m schlagartig ab auf 0. Im Sinne > einer fehlerfreien Datenübertragung durchaus gewünscht. Wenn man aber sowiso einen Fehlerkorrektur eingebaut hat, kann man auch falsche Werte empfangen. Damit gewinnt man zusätzlich 50m Reichweite die ab und zu funktionieren.
So, dieser "Elsa" hat mir geantwortet auf meine Mail warum die Bits floaten. Verstehe er nicht. Rev 3.0 wäre bugfrei. Ich solle den Source einschicken. Das Lo des nIRQ Pins wäre übrigens an das Lesen des Status gekoppelt, liest man es geht der Pin nach High. Witzig: Die Chinesen dort haben alle Dienst-Namen, damit die Europäer sie sich besser merken können: Elsa, Tank, Spyder etc. In echt heisst der Typ Hai Wu Fin Cheng oder so ;-)
Ich hab mal ein paar Details ergänzt. 'eb = Vergleichbar mit BrownOutDetection -> Erkennt eine zu geringe Betriebsspannung, und schaltet dann in den RESET Modus (1 = An / 0 = Aus) Steht das irgendwo ? Ich dachte das erzeugt nur einen Interrupt nach draußen, aber das Modul arbeitet normal weiter.
BrownOut .. hmm .. bi ich mir nicht ganz sicher, aber soweit ich das "herausfiltern" konnte, scheint sich das Modul in den Sleep Mode zu versetzen. Will ich jezt aber keinerlei Garantien darüber abgeben!! Wie gesagt, die Infos sind doch recht dürftig, zumindest das, was ich hier hab. TXT: Danke fürs weiter auffüllen ... vieleicht wird das hier mal zu einer guten Register-Beschreibung ;) wäre sicher auf für andere hilfreich. Weis jemand eventuell, was die fest definierten Werte (-unknow-) zu bedeuten haben? .. kann da leider garkeien Infos zu finden. MfG TPM
Hallo, wenn das Ov Bit gesetzt wurde heisst das nicht, dass nicht weiter empfangen werden kann, nur dass die Daten sich ständig überschreiben. Was anderes: Habe grad mein RFM12 durch einen abgerutschten Tastkopf gehimmmelt, VDI Pin und GND kamen zusammen -> Modul mausetot! Pollin sagte Lieferzeiten von 14 Tagen, so wie das letzte Mal auch. Ähmmmm..... hat vielleicht jemand noch ein RFM12 in der smd Variante und könnte mir dieses morgen in einen Briefumschlag stecken? Mir seine Kontodaten per Mail mitteilen, so dass ich die 8€ bezahlen kann? Sonst ist bei mir die nächsten 2 Wochen nämlich Pause, ich hatte nur 2 Stück bestellt. Gruss, Christian
Ich hab noch ein paar Details geändert. Was die Bits die fest auf 1 und 0 sind bedeuten, kann ich auch nicht sagen. Dazu findet sich nirgends etwas.
Benedikt K. wrote: > Was die Bits die fest auf 1 und 0 sind bedeuten, kann ich auch nicht sagen. > Dazu findet sich nirgends etwas. Auch nicht bei dieser anderen Firma (ich komme gerade nicht auf den Namen), von denen Hope offensichtlich sowohl die Chips als auch die Doku abgekupfert hat? Deren Doku schien mir noch etwas vollständiger zu sein, als die von Hope, es könnte aber auch sein, daß Hope von einem früheren Versionsstand der Chips ausgegangen ist, der manche Funktionen noch nicht (dokumentiert) hatte. @Martin: Kannst Du die Liste bitte entweder zu einem Attachment machen oder so editieren, daß alle Zeilen <80 Zeichen haben. So wie es im Moment ist, muß man (zumindest mit Firefox) immer sehr weit nach rechts scrollen, um an die "Antwort"-Links zu kommen.
Bei Integration stehen auch nur die Bits als 1 oder 0 im Datenblatt. Und das mit dem Code ist wirklich ein dummer Bug in dem Forum. Ein Troll könnte das bewusst ausnutzen indem der sehr langen Code postet...
Benedikt K. wrote:
> Bei Integration stehen auch nur die Bits als 1 oder 0 im Datenblatt.
Hmm - das riecht nach Bugs im Chip oder undokumentierten Features.
Einfach mal anders setzen und schauen, was passiert? ;)
Ich frage mich auch die ganze Zeit schon, ob es bei den Modulen nicht
auch undokumentierte Kommandos gibt, denn so ein richtiges System konnte
ich hinter den Bit-Kombinationen, die das jeweilige Kommando
identifizieren, bisher nicht entdecken.
Bei Integration gibt es noch Zusatzbefehle wie PLL Geschwindigkeit. Den gibt es beim RF12 nicht, nur beim RF02. Ob dieser Befehl auch beim RF12 vorhanden ist kann ich leider nicht ausprobieren, man bräuchte einen guten Spectrum Analyser um zu erkennen, wie schnell sich die Frequenz bei der FSK ändert. Wenn es die anderen Bits beim Integration ICs schon fehlen, wie gut hat HopeRF die ICs dann nachgebaut ? Wobei, das wäre nicht das erste IC, das mitsamt der nicht dokumentierten Befehle nachgebaut wurde...
@Reinhard ... kann leider keine Texte Editieren .. is nur n Löschbutton vorhanden. Aber, macht ja nix .. kanns ja nochmal schreiben ;) ... Da ich gerne alle Register, und deren Funktion verstehen möchte, hab ich eine kleine Liste erstellt, die jedes Bit in jedem Register genau erklären soll. Leider hat das original RFM12B Datenblatt keine wirklich genaue spezifikation der einzelnen Funktionen, bzw. Bits. definiert. Und die anderen Datenbläter vom RF12 (ohne M) reichen leider auch nicht ganz aus, dasmit ich genau verstehe, was die da eigentlich machen!. Daher würde ich euch bitten, meine liste etwas z vervollständigen, soweit ihr das schaft! Schonmal VIELEN VIELEN Dank im vorraus, fürs komplitieren ;) ... Ne andere Firma hat das entworfen? .. jezt würd mich echt interessieren, wer das is .. vieleicht kann man mit denen Kontakt aufnehmen. Das wär ja der hammer. .. Eventuell könnte man danna uch herausfinden, was diese Fixen 0 und 1'sen zu sagen haben .. vieleicht ist das von HOPE n fester wert, so wie bei Pollin mit dem Band, nur mit irgend einer anderen einstellung. PS: Jezt hab ich doch n Bearbeiten Button! .. nice ;) Eventuell gibts das nur beim lezten Posting ... gut zu wissen. PPS: Hab die aktuelle Version vom TXT angehängt. MfG TPM
Wo kriege ich denn jetzt ganz schnell ein RFM12 her ??? Habe "Sendepause" ;-((((((
ich würd dir schon aushelfen, aber meine module sind noch irgendwo zwischen china und warten drauf versendet zu werden :)
Dann würde ich mich gern mal für 10 Stück anmelden :-) Quanta Costa?
Hi, ich versuche grad das RFM02 zum Laufen zu kriegen. Das DQD Bit des letzten verbliebenen RFM12 wird getriggert aber die Daten kommen nicht an. Ich frage mich was in den Hope Codebeispielen die Code CC00 und D040 (Rate/2) bedeuten? Die sind im Datenblatt nicht dokumentiert? Pollin hat ja nu abgekupfert kotz Und ist 4800 baud nun C847 oder C823?
Wo hast du all diese Einstellungen her ? Die gibt es beim RF02 nirgends... Im RF02 Datenblatt ist alles richtig beschrieben. Die Baudrate wird beim RF02 andersts berechnet als bei den anderen Modulen. Hat eigentlich jemand Zugang zu einem Spektrum Analyser oder einem anderen Messgerät mit dem man die Leistung messen kann ? Mich würde mal interessieren, wieviel Leistung wirklich aus einem RFM12 rauskommt, ob diese sich bei 3V Betriebsspannung ändert, und ob die Modulation sich auf die Leistung auswirkt. Meinen Messungen nach ändert sich zwischen 2V und 5V nämlich rein garnichts an der Ausgangsleistung. Weiterhin wäre interessant, ob die Module bei 50Ohm wirklich die größte Leistung liefern.
Klar gibts die! I den beispielen von der Hope HP. D040 ändert laut Oszi das Tastverhältnis des nIRQ Pins für Pollingbetrieh, sobnst snd es scharfe Peaks für Interrupteingänge. Was CC00 macht weiss ich auch noch nicht. Habe um 4 Uhr heute morgen augfgegeben gähn Die Signale sind mit dem Oszi vermessen, der Abstand zwischen den Peaks stimmt aber, also ist die Datenrate richtig, beim rfn12 sind 47 4800 baud, beim rfm02 sind es 23, also die Hälfte. Nur empfangen tue ich nicht, der Fifo geht nicht auf grübel Analyser etc habe ich alles.... kosten rund 300€ für die Stunde Benutzung, es sei denn ich warte mal bis ganz lange nach Dienstschluss und überrede unseren Funk Amateur, dass er mal mitkommt in die Absorberkammer. Der ist ganz begeistert von diesen Basteien :-)
1 | /**********************************************************
|
2 | copyright (c) 2006
|
3 | Title: RF02 simple example based on PIC C
|
4 | Current version: v1.0
|
5 | Function: Package send Demo
|
6 | Processor PIC16F73
|
7 | Clock: 10MHz Crystal
|
8 | Operate frequency: 434MHz
|
9 | Data rate: 4.8kbps
|
10 | Package size: 23byte
|
11 | Author: Robben
|
12 | Company: Hope microelectronic Co.,Ltd.
|
13 | Contact: +86-0755-86106557
|
14 | E-MAIL: hopefsk@hoperf.com
|
15 | Date: 2006-11-10
|
16 | ********************************************************/
|
17 | |
18 | void main() |
19 | {
|
20 | uint ChkSum=0; |
21 | |
22 | RF2_Init( ); |
23 | |
24 | WriteCMD( 0xCC00 ); |
25 | WriteCMD( 0x8B61 ); |
26 | WriteCMD( 0xA640 ); |
27 | WriteCMD( 0xD040 ); |
28 | WriteCMD( 0xC823 ); |
29 | WriteCMD( 0xC220 ); |
30 | WriteCMD( 0xC001 ); |
31 | |
32 | while(1) |
33 | {
|
34 | WriteCMD( 0xC039 ); |
35 | |
36 | WriteFSKbyte( 0xAA ); |
37 | WriteFSKbyte( 0xAA ); |
38 | WriteFSKbyte( 0xAA ); |
39 | WriteFSKbyte( 0x2D ); |
40 | WriteFSKbyte( 0xD4 ); |
41 | |
42 | |
43 | usw.. |
Christian Julius wrote: > Klar gibts die! I den beispielen von der Hope HP. D040 ändert laut Oszi > das Tastverhältnis des nIRQ Pins für Pollingbetrieh, sobnst snd es > scharfe Peaks für Interrupteingänge. Was CC00 macht weiss ich auch noch > nicht. Die Beispielcodes habe ich direkt wieder gelöscht, da diese derart voller Fehler waren. Fragt sich nur ob die Befehle nicht existieren, im Datenblatt vergessen wurden, ober absichtlich gestrichen wurden. Frag doch mal Elsa, was der zu den Befehlen und den Unterschieden zwischen Datenblatt und Beispielcodes meint. > Analyser etc habe ich alles.... kosten rund 300€ für die Stunde > Benutzung, es sei denn ich warte mal bis ganz lange nach Dienstschluss > und überrede unseren Funk Amateur, dass er mal mitkommt in die > Absorberkammer. Der ist ganz begeistert von diesen Basteien :-) Du musst dazu ja nicht unbedingt in die Absorberkammer: Einfach das Modul direkt an den 50Ohm Eingang klemmen (notfalls über Abschwächer, falls der Spektrum Analyser nicht soviel Spannung verkraftet). Das reicht ja um zumindest die Bandbreite, Leistung usw. zu messen. Ich kann mit meinem selbstgebauten Spektrum Analyser leider nur Relativmessungen machen. Auf dem Spektrum sind die Signale um etwa 20dB schwächer wenn ich Daten senden, als wenn ich nur den unmodulierten Träger sende. OK, ist irgendwie klar, da die Energie nun auf einen größeren Frequenzbereich aufgeteilt ist, aber 20dB kommt mir etwas viel vor. Es kann natürlich auch sein, dass mein Spectrumanalyser Mist misst.
Benedikt K. wrote: > Martin W. wrote: >> Mit dem RX Commando (&hB800) sollten doch die Empfangenen Daten, bzw >> auch schrott, je nachdem, was grad auf der Welle reitet, auf der MISO >> leitung zurück kommen .. oder täusche ich mich da? > > Ja, du täuschst dich. Das Modul läd die Daten nur dann ins FIFO wenn das > 2DDA Syncword empfangen wurde. Alternativ kann man das auch umstellen, > dass das Modul jeden Mist ins FIFO läd, aber das macht eigentlich keinen > Sinn. Du kannst es ja mal ausprobieren: Im FIFO Mode Register al auf 1 > (always fill) setzen. Dann sollte der FFIT Pin sofort aktiv werden. Mir ist gerade aufgefallen, das du hier schreibst, 2DDA, jedoch im Datenblatt 2DD4 steht .. is das n druckfehler im blatt, oder hast du dich vertipt? PS: hab das TXT nochmal etwas erweitert. MfG TPM
Benedikt, frag bDu den Elsa doch mal, ich habe da derzeit etwas viel angefragt :-) Und immer schon eine Firmensignaur unter die Mail schreien und immer "we" sagen, das kiingt besser. Es dürfte sich um eine undokumentierte Funktion handeln, wenn wenn der uC keinen INMT hat, dann ist es schwierig einen Peak von 1,6us Länge abzutasten. Gruss, Christian
Ist ein Schreibfehler von mir. A und 4 sehen ja nahezu gleich aus.
Angehängte Dateien:
-
rfm12_lcd.jpg
78 KB
Christian Julius wrote: > Es dürfte sich um eine undokumentierte Funktion handeln, wenn wenn der > uC keinen INMT hat, dann ist es schwierig einen Peak von 1,6us Länge > abzutasten. Kannst du mal genau beschreiben, was der Befehl deiner Meinung nach bewirkt ? Was man also wie einstellen muss, damit ich das mal ausprobieren kann. Im Datenblatt von Integration steht nichts zu dem Befehl. Wenn das also eine undokumentierte Funktion ist, dann haben die das IC gut nachgebaut. Ich habe mal ein wenig die RF12 Software mit einer LCD Ansteuerung kombiniert. Dieses kleine Modul lässt sich per RS232 ansteuern und zeigt den Text dann auf dem LCD an. Weshalb ich das Bild eigentlich zeige: Die Mini Antenne funktioniert erstaunlich gut. Etwa 30m quer durchs Haus sind bei 19200Baud kein Problem, solange der Metallrahmen des LCDs nicht zwischen Sender und Antenne ist. Die HF muss also von hinten kommen.
Benedikt K. wrote:
> Die Mini Antenne funktioniert erstaunlich gut.
Hast Du die irgendwo ausgeschlachtet oder selst gewickelt?
Falls selber gewickelt, bin ich sicher nicht der einzige hier, der gerne
näheres darüber erfahren würde (Drahtlänge, Windungszahl, Steigung,
etc.)
Bei Pollin oder im Baumarkt gibt es oft so eine Funktürklingel (diese hier: http://www.mitglied.lycos.de/bk4/433MHz.htm ). Von der habe ich die Antenne abgeschaut: Etwa 18mm lang, 15 Windungen, gewickelt auf 2,5mm. Der Draht müsste in etwa 0,8mm² sein. Ich habe den nächstbesten genommen den ich rumliegen hatte. Das ganze ist sicher nicht optimal, und verbesserungsfähig, aber ich denke es ist ein guter Einstiegspunkt.
Hallo! Ich bin auch noch auf der Suche nach einer Antenne. Ich braucht auf alle Fälle was robustes. Wie schauts mit der Reichweite bei einer solchen gewickelten Antenne im Vergleich zu sowas aus: http://catalog.digikey.com/scripts/partsearch.dll?Detail?name=ANT-433-PW-QW-ND Oder auch das hier: http://catalog.digikey.com/scripts/partsearch.dll?Detail?name=ANT-433-SP-ND Was hat sichs mit dieser Groundplane. Kann mir das bitte jemand erklären.HF is ned mein Gebiet ;). Hias
Die 1/4 Wave Antenne ist auf jedenfall besser, aber natürlich auch größer. Wie gut die Planarantenne ist, weiß ich nicht. Groundplane ist die Gegenelektrode zur Antenne. Bei 433MHz sollte diese im Idealfall mindestens 30cm groß sein (ich bin aber auch nicht so der HF Profi, daher keine Garantie dass das richtig ist). Gemessen an den Kosten und dem Aufwand ist die Spulenantenne meiner Meinung definitiv brauchbar.
Für 868Mhz gibts im Attachment eine Dimensionierung einer Wendelantenne. Irgendwo habe ich auch noch eine Diemnsionierung für 433Mhz. Gruß Hagen
Hier wieder mal ein Stück Software. Da die Paketisierung usw. bisher auf 2 Dateien verteilt war (main.c und rf12.c) war die Software nur schlecht für andere Projekte verwendbar. Das habe ich jetzt behoben, und die Benutzung stark vereinfacht: RF12 inititialisieren: rf12_init(); RF12 konfigurieren: rf12_config(RF_BAUDRATE, CHANNEL, POWER, RX_GAIN); Daten übertragen: rf12_putc(wert); wert=rf12_getchar(); Dann gibt es noch 2 Funktionen die anzeigt ob Platz im Sendepuffer bzw. Daten im Empfangspuffer sind. Das ganze Interface läuft nur über einzelne Bytes ab. Die Paketbildung, Fehlerprüfung usw. macht die Software in der rf12.c von alleine. Als Beispielprogramm habe ich eine RS232 Funkbrücke geschrieben. Da die gesamte Steuerung intern in den RF12 stattfindet, ist dieses Programm nun nur noch 5 Anweisungen groß. Das ganze läuft jetzt im Hintergund über einen Interrupt gesteuert. Das macht das ganze flexibler, allerdings kann der Interrupt recht lange dauern, da auch die Bestätigung im Interrupt gesendet wird. Ist keine saubere Lösung, aber das kommt noch. Daher garantiere ich auch nicht, das alles fehlerfrei ist, die langen Tests kommen noch. Da der Interrupt High Level aktiv sein muss, wird INT1 mit einem Inverter davor verwendet.
Hallo, ich habe es inzwischen aufgegeben das RFM02 dazu zu bewegen mit dem RFm12 eine Verbindung einzugehen, mir fällt nichts mehr ein. Das DQD Bit des RFM12 blinkt, es kommt also was an aber das war es auch. Ansonsten ist es ein Stochern im Dunklen, wenn man nicht messen kann, was wirklich gesendet wird. Dieser Befehl D040 bewirkt, dass das NIRQ Signal, welches den Mastertakt für die Datenbits angibt, wann diese bereits zur Aufnahme sind, einen 50% Duty Cycle hat, statt nur dünne Peaks. Zwischen den Peaks messe ich 2ms, das ist die Zeit, die ein Bit bei 4800 baud braucht, stelle ich um sind es wieder 2ms aber es ist eben kein Peak mehr, sondern ein breiter Streifen auf dem Oszi. Die werden wohl gemerkt haben, dass langsame Prozessoren oder solche die mit Batterie bei 32 khz betrieben werden es nicht schaffen 1,6us im Polling Betrieb abzutasten. Der Chip ist definitiv ein Nachbau, die Struktur haben auch die Nord-IC Chips, ausserdem kann man ja Lizensen für IP's kaufen, das sind ja bloss VHDL Codes bzw in diesem Falle noch Analog Cores, die da verbaut wurden. Da kann einfach nichts mehr falsch sein...
1 | // TX: Datenbyte raussenden (1=warten, 0=sofort senden (nur erstes Byte))
|
2 | void RF_SendByte(byte data) |
3 | {
|
4 | byte i; |
5 | |
6 | for (i=0;i<8;i++) |
7 | {
|
8 | while (!NIRQ); // warte auf steigende Flanke |
9 | while (NIRQ); // warte auf fallende Flanke, dann neues Bit |
10 | |
11 | if (data&0x80) |
12 | SDO = 1; |
13 | else
|
14 | SDO = 0; |
15 | |
16 | |
17 | data = data<<1; |
18 | }
|
19 | |
20 | }
|
21 | |
22 | // >>>>> TXRX: Initialisierung des Moduls <<<<
|
23 | //
|
24 | // BR = 344827/(R+1)/(1+cs*7) [baud] cs=1 => 8 cs=0 => 1
|
25 | //
|
26 | |
27 | // >>>> TX: Senden einer Bytefolge + Checksumme <<<<<
|
28 | // <2 x 0xAA>, <Anzahl Bytes>, <Bytes>... <Bytes>, <Checksumme>, < Dummy>
|
29 | |
30 | #define RF_TX_ON 0xC039 // Synth,PLL,Osc = AN
|
31 | #define RF_TX_OFF 0xC020 // Osc bleibt an
|
32 | |
33 | void RFTX_Send(byte* data, byte size) |
34 | {
|
35 | byte check,cmd; |
36 | byte i; |
37 | |
38 | if (size>254) |
39 | size = 254; |
40 | |
41 | RF_CMD(RF_TX_ON); // Transmitter einschalten |
42 | |
43 | NSEL = 0; |
44 | SPIRF(0xC6); // Data Transmit Command |
45 | SCK = 0; |
46 | SSPCON_SSPEN = 0; // SPI abschalten, Bits werden manuell geschoben |
47 | // NIRQ muss jetzt low sein!
|
48 | |
49 | RF_SendByte(0xAA); // Präambel ins Latch, lockt die PLL |
50 | RF_SendByte(0xAA); // Präambel ins Latch, lockt die PLL |
51 | RF_SendByte(0xAA); // Präambel ins Latch, lockt die PLL |
52 | |
53 | RF_SendByte(0x2D); // FIFO Schlüssel 2DD4 (öffnet das Tor) |
54 | RF_SendByte(0xD4); |
55 | |
56 | // --- Ab jetzt benutzerdefiniert ---
|
57 | |
58 | RF_Sendbyte(MASTER_START); |
59 | RF_Sendbyte(size); // Anzahl folgender Bytes senden (incl Checksumme) |
60 | check = size; |
61 | for (i=0; i<size; i++) // Datensatz senden |
62 | {
|
63 | RF_SendByte(*data); |
64 | check += *(data++); |
65 | }
|
66 | |
67 | RF_Sendbyte(check); // Checksumme |
68 | |
69 | RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer |
70 | RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer |
71 | RF_SendByte(0xAA); // Dummy, nachschieben als Pipelineputzer |
72 | |
73 | NSEL = 1; |
74 | SSPCON_SSPEN = 1; // SPI abschalten, Bits werden manuell geschoben |
75 | |
76 | // RF_CMD(RF_TX_OFF); // TX off
|
77 | }
|
Christian Julius wrote: > ich habe es inzwischen aufgegeben das RFM02 dazu zu bewegen mit dem > RFm12 eine Verbindung einzugehen, mir fällt nichts mehr ein. Passt deine Baudrate ? Die wird beim RF02 nämlich anderst berechnet. > Der Chip ist > definitiv ein Nachbau, die Struktur haben auch die Nord-IC Chips, > ausserdem kann man ja Lizensen für IP's kaufen, das sind ja bloss VHDL > Codes bzw in diesem Falle noch Analog Cores, die da verbaut wurden. Nord-IC ?
Hi, wie wird denn die Baudrate anders berechnet? Ich kenne die Formeln, da ist nur ein Bit anders (cs). Wichtiger wäre zu wissen wann der NIRQ Takt das Bit erwartet, auf der steigenden Flanke oder auf der fallenden? Was ich auch nicht kapiere ist, dass der Empfänger mit seinem DQD Bit zappelt, auch wenn ich die Frequenz des Senders grob ändere. Ansonsten: http://www.nordicsemi.no
Welches IC soll den Hope RF ICs entsprechen ? nRF905 ? Die DQD und die VDI Bits sind bei mir nutzlos, die zappeln wie wild. Ich nutze daher eigentlich nur das FFIT Bit. Beim RF02 werden die Daten bei der fallenden Flanke übernommen.
Hello! Wen chips RFxx, Integration-s IA42xx oder IA44xx "clones" sind, auf link : http://www.integration.com/IA_MSC-DKSW1_download.shtml registration aufmachen und aus: https://www.integration.com/cgi-bin/docserv downloaden : CD1 (070702_1151).zip ( hm! 73,8 MB file). Da exist fein Win-config-tool, Chip-Configurator fuer IA422x,IA432x IA442x chips : WDS.exe ! Gruß ! Bengez M.
Das DQD Bit funktioniert wunderbar, wenn Du LNA und RSSI heruntersetzt, was eigentlich auch Sinn der Sache ist. Ist so wie die Squelch Taste an einer Funke. Findest Du einen Fehler in meinem Code für RF02?
http://www.nordicsemi.no glaub ich nicht .. das die von dem sind .. dort finden sich zwar chips, aber die arbeiten alle nur auf max. 3 bänder, ab 433MHz der Post von @Bengez M. jedoch, scheint passender zu sein. Die Componenten arbeiten nämlich auf 4 Bänder, beginndend bei 315MHz. Desweiteren können diese chips auch bis 256KBaud transferrate, als die von nordic mit nur 70K MfG TPM
RF12 ist Integration-s IA4420 oder IA4421 clone mit 50 ohm RX/TX imedance match! Gruß ! Bengez M.
ich glaube, es sind eine dieser beiden Chips http://www.integration.com/docs/IA4420-DS.pdf http://www.integration.com/docs/IA4421-DS.pdf MfG TPM
@ Martin W.
Bitte Win-config-tool downloaden , Chip-Configurator
fuer komplete family : IA422x,IA432x und IA442x chips,
WDS.exe
probieren, func excellent !!
Gruß !
Bengez M.
Genau: IA4221 = RF02 IA4320 = RF01 IA4420/1 = RF12 Sind in der ZIP Datei brauchbare Programme oder Infos ? Ich hab leider nur ISDN, daher ist mir die Datei etwas groß...
Könnte mal jemand die WDS.exe (falls diese nicht zu groß ist) posten, damit ich nicht alles runterladen muss ?
@Benedikt : Könnte mal jemand die WDS.exe (falls diese nicht zu groß ist) posten, damit ich nicht alles runterladen muss ? Leider : WDS.exe ist cca. 11MB gross ! Gruß aus Croatien! Bengez M.
@Benedikt >Könnte mal jemand die WDS.exe (falls diese nicht zu groß ist) posten, >damit ich nicht alles runterladen muss ? CD1 (070702_1151).zip und CD2 (070702_1151).zip sind excellente utility soft-package fuer arbeit mit Integration-s IA422x,IA432x und IA442x chips ! Gruß ! Bengez M.
@Begenz M. Die von dir beschriebene Datei existiert in dem ZIP file nicht. MfG TPM
@ Martin W.
>Die von dir beschriebene Datei existiert in dem ZIP file nicht.
Look in path : \CD1 (070702_1151)\Software\Chip Configurator\WDS
Setup.exe
Gruß !
Bengez M.
Bitteschön. Bei mir stürzt das Prog leider ab, wenn ich einen Chip auswähle. PS: Das ist eine VB.NET Anwendung. Folglich wird die laufzeitumgebung dafür benötigt. MfG TPM
@Martin W.
>Bei mir stürzt das Prog leider ab, wenn ich einen Chip auswähle.
WDS.exe exiestiert auf mein Acer-notebook und desk-comp.(WinXP)!
Func OK !
Bengez M.
Hallo, ich habe spasseshalber mal bei beiden Firmen nachgefragt, ob die Kopien aus China denn legal sind. Auf die Antworten bin ich mal gespannt. Die Sache ist nämlich die, dass wenn hier jemand Chips bestellt hat und die Frachtpapiere weisen diese als Clone aus, dann war es das mit den Chips, die wandern dann in den Shredder und die Kohle ist weg. Hintergrund ist auch der, dass wir hier im Prüfinstitut immer wieder Bauteile aus China haben, die exakte Nachbauten sind aber keinesfalls das Datenblatt einhalten. Da diese Bauteile auch in Sicherheitsanlagen wandern ein lebengefährliches Spielchen. Gruss, Christian
@Benedikt Respekt, respekt ! Hast du WDS.exe endlich ausprobieren! @Christian Julius Bin auch gespant was wird ELSA aus China antworten ! Informiren weiter, bitte ! Grusse! Bengez M.
Christian Julius wrote: > Die > Sache ist nämlich die, dass wenn hier jemand Chips bestellt hat und die > Frachtpapiere weisen diese als Clone aus, dann war es das mit den Chips, > die wandern dann in den Shredder und die Kohle ist weg. Was ist dann mit den ganzen TS358, TS34063 usw. ? Was sollte denn in den Frachpapieren stehen ? Second Source, oder garnichts ? Bei mir läuft die WDS.exe. Es gibt zwischen den IA ICs und den RF ICs kleine Unterschiede, vor allem beim RF02: - kein Tasterinteface - kein EEPROM Modus - kein OOK Oder sind die Sachen nur nicht im Datenblatt beschrieben ? Diese funktionen "auszubauen" hätte ja immerhin ein kleines Redesign erfordert. Ich habe gerade mal ein paar Antennenmessungen gemacht. Die RSSI Spannung liegt bei dem getesteten Modul bei 500mV ohne Signal und etwa 1100mV mit maximalem Signal. Der Empfänger war etwa 3m vom Sender entfernt, die Sendeleistung daher auf minimal eingestellt, Modulation aus (also Dauersignal). Mit einem 17cm langen Draht ist die Leistung maximal (etwa 850mV am Empfänger). Die Helixantenne (diese mini Kupferspule) bringt nur etwa 550mV, also fast nichts. Interessant ist, dass selbst mit dieser eine Übertragung quer durchs Haus möglich ist. Allerdings liegt in der anderen Ecke vom Haus das Signal auch nur bei etwa 550mV, und das ist genau auch der Punkt wo die Empfangsprobleme anfangen. 20mV RSSI Spannung entsprechen etwa 1dB. Die 17cm Drahtantenne ist also um etwa 15dB besser als die Mini Spule. Jetzt wären mal die anderen Antennen interessant, die es u.a. bei Digikey gibt (also Chip und Planarantenne). Leider habe ich diese (noch) nicht, daher kann ich diese nicht messen. Ich werde aber sowiso erstmal bei der 17cm Drahtantenne bleiben, da diese an Einfacheit und Reichweite nur schwer zu überbieten ist.
Hab hier ne schöne sammlung von Anleitungen fürs herstellen von Antennen, für genau diesen Chip 4420 .. Die PDFs finden sich auch in Downloadverzeichnss von http://www.integration.com/docs/ Hier gibts die File's jezt als Rar: http://www.file-upload.net/download-340202/IA_ISM_ANT_Design.rar.html MfG TPM
Angehängte Dateien:
-
rfm12_mess.jpg
50 KB
Die Antennen sehen nicht schlecht aus, vor allem die Back IFA gefällt mir. Aber die scheint nur für 868MHz geeignet zu sein, da sie ansonsten zu groß wird. Leider sind die Dinger relativ kritisch in der Dimensionierung, und ohne geeignetes Messequipment nur schwer selbst zu bauen, da man für jede Änderung eine neue Platine ätzen muss. Dazu kommt noch, dass die Dimensionierung auch noch vom Platinenmaterial abhängt, zu dem nicht unbedingt die Daten vorhanden sind. Ich bin mal etwas mit einem tragbaren RFM12 + LCD durchs Haus gewandert. Mit einem 17cm langen Draht ist das Signal etwa 10-15dB stärker als mit der kleinen Drahtspulen Antenne. Die Reichweite ist geschätzt also mindestens doppelt so hoch. In 20m erreiche ich unter günstigen Bedingungen noch 700mV am RSSI Pin. Das RSSI Bit ist bei minimalem Schwellwert immer gesetzt, egal ob der Sender an ist oder nicht. Eine Stufe höher das gleiche. Erst ab der 3. Stufe ist das RSSI Bit gelöscht, wenn der Sender aus ist. Allerdings ist mit dieser Einstellung die Reichweite stark eingeschränkt. Je nach Empfangsposition bekomme ich ab etwa 10m vereinzelt schon ein gelöschtes RSSI Bit, während mit dem Schwellwert auf minmal oder eine Stufe darüber selbst in 20m unter ungünstigen Bedingungen die Daten noch mit hoher Warscheinlichkeit richtig ankommen. Das Clock Recovery Bit, zusammen mit Data quality detector ist eine bessere Anzeige, ob ein gültiges Signal anliegt. Dies erreicht man durch die VDI Einstellung medium. Da aber auch ohne gültiges Signal, die einzelnen Bits ab und zu erscheinen, ist wohl die Slow Einstellung oder alternativ ein Filter am VDI Signal die bessere Wahl, wenn man dieses Signal wirklich als Indikator für gültige Daten nutzt. Ich werde bei meiner Software jetzt folgende Einstellungen verwenden, da diese meiner Meinung nach optimal sind für eine hohe Reichweite: LNA Gain: 0dB Bandwidth: 200kHz RSSI: -97dB Frequenzhub: 90kHz
Angehängte Dateien:
-
rfm12_19200baud.gif
20 KB
Kann es sein, dass die RFM12 Moduls sehr breitbandig senden ? Ich habe mal ein paar Messungen gemacht (Frequenzhub 90kHz, Daten mit 20000Baud), das Spektrum sieht aber sehr viel breiter aus. (Es kann natürlich auch sein, dass mein Spektrum Anaylser Mist misst.)
Angehängte Dateien:
-
433MHz_ook.gif
19 KB
Hier zum Vergleich ein anderer 433MHz Sender von einer Funksteckdose.
Hallo, lässt sich dieses Forum eigentlich für Trolle sperren? Bzw gibt es hier aktive Moderatoren, die gelegentlich säubernd eingreifen, um den anonymen Dünpfiff hier zu begrenzen? Grundsätzlich gilt aber: Don't feed the Trolls, diese armen Menschen haben oft niemanden, der mit ihren redet, daher versuchen sie wenigstens negative Aufmerksamkeit zu erzeugen um überhaupt beachtet zu werden. Es ist mein Beruf Fragen zu stellen, auch sehr unbequeme, ich darf das, dafür werde ich bezahlt :-) Wir werden sehen was die Firmen antworten, das sind Fragen die jeder Kunde auch stellen würde. Warum teuer in den US kaufen, wenn man es zigfach billiger aus China haben kann? Es ist ja auffällig, dass die beiden Datenblätter absolut identisch sind bis ins kleinste Detail. HOPE hat keine deutschen Niederlassungen, es ist eine Tochter der Shenzen Electric Company, einem sehr grossen Hersteller elektronischer Waren, sie werden bei keinem deutschen Disti geführt, verkaufen ihre RF Module ausschliesslich über Pollin. Und Pollin versorgt mehr die Bastler und Schnäppchenjäger. Auch das stellt HOPE her: ------- MAR series RF wideband transistor We can Supply all series of MAR SMD low power low noise high frequency transistors to replace the brand of Philips,NEC,Toshiba and Motorola etc.. ------- Die MAR Series sind bekanntlich ein Produkt der Minicircuits US. Was China alles fälscht steht hier, das stimmen selbst die Bezeichnungen der Hersteller überein wie IRF, Philips, MAR usw. Und Hope mischt da kräftig mit, die sind mehrfach genannt. http://www.made-in-china.com/products-search/hot-china-products/Transistor.html Fälschungen der IRF Transistoren: http://www.made-in-china.com/showroom/chickenv2/product-detailuMFxQsNUCEcS/China-MOSFET-Transistor-IRF540N-IRF740-IRF840-.html Im letzten Fall, den ich dienstlich erlebte wurden zwangsgeführte Sicherheitsrelais eines grossen deutschen Herstellers gefälscht und ebenso die Zertifikate und Prüfsiegel, diese Relais habe ich, sie sind wertloser Schrott, der im Falle eines Versagens Menschenleben kostet. Über Umwege kamen sie nach Deutschland, versehen mit allem was die Fälscherwerkstatt der Chinesen hergibt, damit sie so aussehen wie von einem bekannten deutschen Hersteller. Was chinesische Technik oftmals taugt habe ich ja im Falle des Geländewagens Landwind erlebt, dem wir glücklicherweise zusammen mit dem ADAC die Markteinführung hier versauert haben, damit es nicht noch mehr Tote im Verkehr gibt. Aber vielleicht findet ein Herr "Senf" das ja gut und hat seine Freunde daran wenn andere zu Schaden kommen. Das aber nur nebenbei und etwas OT, sehe grad, dass hier saubergemacht wurde ;-) Christian Julius
Angehängte Dateien:
-
PIC00002__800_x_600_.jpg
70 KB
Hallo Benedikt, das macht der D040 Befehl beim RF02 aus dem NIRQ Taktsignal für die Bits. Gruss, Christian
Back to topic. Thema Antenne. http://www.tfs.net/~petek/rockets/RDF/70ant.html Diese habe ich gerade eben nachgebaut. Das ging ziemlich flott und die Antenne ist, wie soll ich es am besten beschreiben, einfach nur spitze: Das Signal mit dieser Antenne ist ohne Sendersignal um etwa 5dB schwächer als mit der 17cm Drahtantenne, die unerwünschten Hintergrundstörungen werden also gut unterdrückt (wenn nicht gerade der Störer in der gleichen Richtung liegt). In 20m Entfernung quer durchs Haus, ist der Empfänger mit dieser Antenne immer noch übersteuert (zumindest das RSSI Signal): Das RSSI Signal hängt bei 1130mV fest, genau dem gleichen Wert wie direkt neben dem Sender. Die Antenne ist also um etwa 20dB besser als die 17cm Drahtantenne ! Wie groß die Reichweite ist, habe ich noch nicht ausprobiert, ich komme mir nämlich etwas komisch vor, wenn ich mit einer 70cm langen Yagi Antenne und einer Platine in der Hand die Straße entlang laufe... Ich möchte nicht wissen, was die Nachbarn denken, wenn sie mich so sehen. Mit 2 solcher Antennen sollte die Reichweite ziemlich hoch sein (ich schätze mal 500m oder mehr).
Interessant. Muss ich demnächst unbedingt mal ausprobieren. Bewirkt der Befehl sonst noch was ?
Hallo, netter Nachbau, allerdings fehlt etwas: Das Anpassglied vom 200 Ohm Dipol auf das Koax Kabel. Eine Parallelschaltung aus zwei 75 Ohm Kabeln würde passen, jedoch muss die Länge berechnet werden. Hier ist noch eine Bauanleitung, allerdings für das 2m Band. http://www.mydarc.de/dk7zb/5-el-2m/5Element.htm Was ich noch nicht verstanden habe ist: Sehe ich das richtig oder sind die beiden Litzen des Koax elektrisch miteinander über den Stab verbunden? Was dieser bfehl sonst noch bewirkt weiss ich nicht, der Chip kann leider nicht viel sagen :-((( Werde gleich mal mit der 40 herumspielen, die D0 ist j das Kommando.
Feierabend, RFM02 kaputt, Kurzer gegen 12V... ich habs echt drauf derzeit :-(((
Christian Julius wrote: > netter Nachbau, allerdings fehlt etwas: Das Anpassglied vom 200 Ohm > Dipol auf das Koax Kabel. Eine Parallelschaltung aus zwei 75 Ohm Kabeln > würde passen, jedoch muss die Länge berechnet werden. Denke ich nicht: bei deinem Link werden beide Stäbe angesteuert. Bei meinem Link besteht der gespeiste Stab aus einer Schleife auf einer Seite. Das dient vermutlich als Anpassung. Ich werde mir jetzt noch eine zweite Antenne bauen und dann mal schauen wie weit ich komme. Wenn die Reichweite bei >200m liegt, kann ich in die Wildniss, dann sieht mich (hoffentlich) niemand mit der Antenne.
Besser ist das in der Wildnis, sonst sind die Herren mit den jackenm die nach hinten zugeknöpft werden nicht allzu weit ;-) Löte grad den letzen Chip ein, den ich noch habe...
Lieber die Jungs mit der Jacke, als die Jungs mit der Antenne auf dem Dach. Letzeres wird nämlich schnell teuer...
OT: >>Im letzten Fall, den ich dienstlich erlebte wurden zwangsgeführte >>Sicherheitsrelais eines grossen deutschen Herstellers gefälscht und >>ebenso die Zertifikate und Prüfsiegel, diese Relais habe ich, sie sind >>wertloser Schrott, der im Falle eines Versagens Menschenleben kostet. Redest du von Fa. P*lz? Pollin hat schon ein Problem mit Patentverletzungen gehabt. Die kleine Aderendhülsen-Quetschzange im letzten Sonderkatalog haben sie wegen solcher Probleme zurückziehen müssen... Zum Thema: Bin gerade auch am Basteln mit zwei RFM12. Zeichne gerade das Layout. Ich will sie zur Datenübertragung zwischen einer Außen-Wetterstation und einem Webserver verwenden. Welchen Mindestabstand sollte man zwischen Modul und µC verwenden? Gruß Elektrikser
So fertig, wird mal Zeit Adapterplatinen zu machen, das nervt auf Dauer mit dem Silberdraht auf der Lochraster.... Ok, ich probiere noch ein wenig, morgen kommen meine Frau und die Kiner wieder, dann geht nichts mehr über das WE.
Angehängte Dateien:
-
Umweg.JPG
300 KB
Hallo Leute, anbei mal eine Umwegleitung. Das Bild hat wohl schon Altertumswert. Die Verkürzungsfaktoren sind wohl zu erfahren. Vielleicht kann es jemand gebrauchen. Wigbert
@Christian Julius (Firma privat) (elektroniker1968) : Du Pfeife, habe ich geschrieben die sitzen in Deutschland. Lesen kanner also auch nicht. Man sieht sich im Leben immer 2 mal. Bis demnächst.
Klasse! Sowas Ähnliches habe ich auch noch in meinen alte Röhrenbüchern. Da der PIC auch grad zerschossen wurde dauert es jetzt etwas länger, muss dringend mal wieder bei ebay auf die Jagd nach PICs gehen, die gehen mir langsam aus...
Hi Christian, richtig. Und lass doch nicht Deine Wut an den Pics aus, überrasch uns lieber weiterhin mit Deinen konstruktiven Beiträgen. Es gibt immer neidische Zeitgenossen. Wigbert
Angehängte Dateien:
-
roehren.jpg
150 KB
Wigbert, ich entspanne grad mit Mozarts "Kleiner Nachmusik", natürlich stilecht :-)
@Wigbert P. ... Hui .. is die seite zufällig aus dem Buch "Antennen" (zeitraum: DDR) ? PICs mag ich nicht .. die hab ich früher immer zerlegt, wie grass, das im Wind bricht. Ich nutz nur noch AVRs, die sind robust, das is teilweise schon wahnsinn. (PS: Habs mal nen Mega8 udn nen Tiny2313 mit knapp über 50MHz angetacktet ... hrrr .. das macht spass! Power ohne ende) MfG TPM
Angehängte Dateien:
-
PIC00003.JPG
160 KB
Errrrrrrrrrrrr gäääääääääääääääht ! DAS SCHEISS DING GÄÄÄÄÄÄÄÄHT! (O-Ton Der Sachse, 200 Puls) RFM02 und RFm12 reden miteinander und ich habe es nicht mal bemerkt! Gucke grad auf dei Anzeige und da laufen die Zahlen. Verändert habe ich nichts, vielleicht war der eine RFM02 einfach defekt. Sapperlot und Kruzifix, da gehn ma gleich mal gschwind in den Keller und machen uns ein Bierchen auf ;-)
Hallo Maritin,
>@Wigbert P. ... Hui .. is die seite zufällig aus dem Buch "Antennen"
(zeitraum: DDR) ?
ok, aber manchmal sind auch die einfachsten lösungen, die besten.
Man hat ja das Material der Umwegleitung sowieso über.
Die Yagi ist ja sowieso kompakt und da ist das eine "bequeme"
Lösung. Und spielen tut das Ding allemal.
Wigbert
Klaus, wie schaut es mit den RFm12 aus? Kann man in die Lieferung noch einsteigen?
Appropro RSSI ... kann es sein, das das RFM12 garkein RSSI ausgang besizt, und ich folglich garkeine Signalstärke messen kann, abgesehen vom DRSSI Bit im Status-register ?!? @Wigbert .. ? .. verstehe deine Antwort in bezug auf meine Frage nicht :] MfG TPM PS: TXT nochmal etwas überarbeitet, udn n grossen fehler behoben g (Dezibel/meter) meiomei .. so ein schmarn von mir ... tz tz tz
@christan: ne du... ich bin da dabei Beitrag "Sammelbestellung RFM12" und steffen hat schon vor längerer zeit bestellt.
Martin W. wrote: > Appropro RSSI ... kann es sein, das das RFM12 garkein RSSI ausgang > besizt, und ich folglich garkeine Signalstärke messen kann, abgesehen > vom DRSSI Bit im Status-register ?!? Jain. Er existiert, aber nur auf dem Modul. Auf einer Seite sind 2 SMD Kondensatoren. Davon ist es der vorderste Kontakt direkt an der Ecke. Christian J. wrote: > RFM02 und RFm12 reden miteinander und ich habe es nicht mal bemerkt! > Gucke grad auf dei Anzeige und da laufen die Zahlen. Verändert habe ich > nichts, vielleicht war der eine RFM02 einfach defekt. Mit dem D040 Befehl aktiv ?
Hallo, kurz eine Info, da sich alle Firmen gemeldet haben. Sehr erfreulich! Hope kauft einfach nur die die's bei Integration ein und baut sie in Module ein. Sie dürfen jedoch keine die's einzeln verkaufen ohne Erlaubnis. Der freundliche Herr von Integration rief mich grad noch an und fragte ausdrücklich, ob irgendwo die's aufgetaucht seien, da scheint auch viel Misstrauen zu sein. Der Befehl D0xx ist undokumentiert, das ist richtig, nähere Infos darüber bekomme ich nächste Woche. Ende gut alles gut ;-) Gruss, Christian
Benedikt K. wrote: > Martin W. wrote: >> Appropro RSSI ... kann es sein, das das RFM12 garkein RSSI ausgang >> besizt, und ich folglich garkeine Signalstärke messen kann, abgesehen >> vom DRSSI Bit im Status-register ?!? > > Jain. Er existiert, aber nur auf dem Modul. Auf einer Seite sind 2 SMD > Kondensatoren. Davon ist es der vorderste Kontakt direkt an der Ecke. Perfekt .. danke.. werd ich mal ein wenig rummessen müssen @Christian J. ... bin schon auf die Antwort gespannt. MfG TPM
Interessant. Hätte ich jetzt eigentlich nicht erwartet. Das heißt, die DIEs im RFM12 sind eigentlich von Integration hergestellte IA4421, oder habe ich das falsch verstanden, und HopeRF hat nur die Lizenzen zum Nachbauen gekauft ? @wigbert Sehe ich das richtig, dass der Abstand zwischen gespeistem Element und Reflektor 15cm beträgt ? Auf dem Foto und bei allen anderen Yagis die ich gefunden habe, sieht es nämlich so aus, als wenn der Abstand zwischen Direktor und Reflektor etwa 15cm beträgt, und das gespeiste Element dazwischen liegt.
Hallo Benedikt, hier die Anrwort: Christian, HopeRF buy our die products and mount them on boards which they sell as modules. HopeRF are not allowed to sell packaged parts or die directly without authorization from IAI. There are a few examples where this arrangement is in place. Regards, Nick Ich war grad eben mal in unserer Absorberkammer und habe mir eine Yagi Antenne (3m) mal genau angeschaut. Du darfst natürlich kein Holz als Boom verwenden, die Stäbe werden in Metall eingebettet, so dass Ohmsch 0 Ohm überall bestehen. Ein Dipol hat immer 240 Ohm und muss durch einen Balun angepasst werden, einfach 50 Ohm Kabel aus dem Baumarkt entsprechend verarbeiten.
Angehängte Dateien:
-
gamma.JPG
140 KB
Hallo Benedikt, ich hab die 4 El. Yagi nach meiner "Baumappe" für 70cm 5W digit. Betriebsart(Packet) funktionstüchtig im Einsatz. Die Abmaße stammen aus "Rothammel" Antennenbuch. Also die 150mm sind Abstand Dipol-Reflektor. Abstände Dipol-Direktoren sind unterschiedlich. Anbei mal eine Anpassung mit Trimmer. Wigbert
Hallo, falls jemand hat wäre eine leicht verständliche Anleitung für diesen Balun von Nutzen, wie man den wickelt und baut - möglichst mit Bildern ;-)
Christian Julius wrote: > Ich war grad eben mal in unserer Absorberkammer und habe mir eine Yagi > Antenne (3m) mal genau angeschaut. Du darfst natürlich kein Holz als > Boom verwenden, die Stäbe werden in Metall eingebettet, so dass Ohmsch 0 > Ohm überall bestehen. Das hatte ich mich auch schon gefragt, ob das notwendig ist, denn die ganzen Dachantennen bestehen ja alle komplett aus Metall. Andererseits sind die Elemente alle Lambda/2, demnach ist die Spannung im Mittelpunkt immer 0, also dürfte es wohl egal sein, oder ? > Ein Dipol hat immer 240 Ohm und muss durch einen > Balun angepasst werden, einfach 50 Ohm Kabel aus dem Baumarkt > entsprechend verarbeiten. Ich dachte dieses gebogene Element dient als Anpassung ? Ähnlich wie bei einer J Antenne. Selbst wenn die Antenne nicht optimal angepasst ist, die Antenne ist definitiv um ein vielfaches besser als die 17cm Drahtantenne: Sender mit 17cm Drahtantenne, minimale Sendeleistung. In 20m Entfernung (quer durchs Haus) erreiche ich mit der Yagi nach der Anleitung von wigbert noch etwa 850mV. Das ist mehr als ein Empfänger mit 17cm Drahtantenne 2m neben dem Sender ! @wigbert Danke. Es scheint irgendwo bei 6 Elementen eine Änderung in der Bauweise zu geben.
Angehängte Dateien:
-
PICT0026.JPG
130 KB
Hallo Benedikt,
mal mit meinen bescheidenen Wissen:
>Ich dachte dieses gebogene Element dient als Anpassung
Es gibt Faltdipoldipole(gebogener gstreckter Dipol Breite = Lamda/2 *
Verkürzungsfaktor R0=240 Ohm) und Halbwellendipole(Stabform).
Beim Habwellendipol+gestreckten Dipol hast Du in der Mitte
Spannungsnulldurchgang und Strombauch, deshalb mittige Befestigung an
Metallträger möglich und beide Halbwellendipolhälften verbunden.
Faltdipol dann Übertrager zur Anpassung.
Die Gammaanpassung verschiebt den Anpasspunkt dahin, wo 50 Ohm
anliegen.
Aber das weisst Du ja alles.
Wer eine kleinere Antenne sucht sollte mal nach:
HB9CV
googeln
Wigbert
Wigbert P. wrote: > Es gibt Faltdipoldipole(gebogener gstreckter Dipol Breite = Lamda/2 * > Verkürzungsfaktor R0=240 Ohm) und Halbwellendipole(Stabform). OK, ganz langsam. Antennentechnik ist alles andere als mein Fachgebiet. Halbwellendipol ist ein einfacher Stab (in diesem Fall etwa 34cm lang) Faltdipol ist das ganze als gequetschter Kreis, also so ne Art Schlaufe, ebenfalls 34cm lang ? > Beim Habwellendipol+gestreckten Dipol hast Du in der Mitte > Spannungsnulldurchgang und Strombauch, deshalb mittige Befestigung an > Metallträger möglich und beide Halbwellendipolhälften verbunden. Möglich bedeutet also nicht unbedingt notwendig ? > Faltdipol dann Übertrager zur Anpassung. > Die Gammaanpassung verschiebt den Anpasspunkt dahin, wo 50 Ohm > anliegen. Das ist soweit klar. Ohne SWR Meter ist die Anpassung für mich aber nur schwer möglich. Jetzt die große Frage. Was wird hier verwendet: http://www.tfs.net/~petek/rockets/RDF/70ant.html Das sieht auch wie der Faltdipoldipol aus, aber eine Hälfte ist auf Lambda/4 gekürzt und wird gespeist. > Aber das weisst Du ja alles. Schön wäre es, dann bräuchte ich hier nicht soviele dumme Fragen stellen. > Wer eine kleinere Antenne sucht sollte mal nach: > HB9CV > googeln Habe ich gestern schon gemacht, aber im Vergleich zur Yagi sieht die sehr kompliziert aus und muss auch wieder abgestimmt werden. Ich glaube ich muss mir doch mal ein SWR Meter bauen.
Hi Benedikt, ich melde mich heut Abend zu den Fragen. Muss jetzt weg. Wigbert
Angehängte Dateien:
-
rfm12_tx_434.27MHz.gif
20 KB
OK, schonmal Danke ! Ich habe mal ein paar Messungen zur Bandbreite gemacht: Ein RFM12 als Dauersender, ein RFM12 als Spektrumanalyser (Frequenz gesweeped, RSSI Spannung gemessen). So sieht ein Dauersignal auf 434,27MHz aus wenn ein RFM12 auf 67kHz Bandbreite eingestellt dieses misst. Aufgrund der Bandpassfunktion des Basisbandfilters, ist das RSSI Signal schwächer, wenn die Sendefrequenz und Empfangsfrequenz genau übereinstimmen.
Hallo Benedikt, >Faltdipol aus Parallelschaltung zweier Halbwellenstücke mit geringen gegenseitigen Abstand D (D<0,05 Lamda) ist der Schleifendipol(Faltdipol) entstanden. Mitte des Halbwellendipols V = 0, I = groß. Fußpunktwiderstand grösser als ein eifacher gestreckter Dipol Bandbreite grösser als ein eifacher gestreckter Dipol > Möglich bedeutet also nicht unbedingt notwendig es ist üblich Yagi-Antennen in Ganzmetallausführung aufzubauen. Sämtliche Antennenelemente sind in ihrer geometrichen Mitte (U=0) ohne Isolation direkt und leitend auf den Antennenträger zu montieren. Diese Bauart bringt elektrisch keine Nachteile hat mechanisch und hinsichtlich Blitzschutz Vorteile. Ich hab schon Yagis auf Holzleisten aufgebaut gesehen. auszüge aus "Antennenbuch" >Was wird hier verwendet: hab ich noch nie gesehen, muss ich mir erst übersetzen. >im Vergleich zur Yagi sieht die >sehr kompliziert aus und muss auch wieder abgestimmt werden. nun wo eine Pa da sollte auch ein SWR-Meter sein. Ansonsten ist die HB9CV aus Baumarktteilen zu fertigen. konnte meine Anleitung auf die Schnelle nur nicht finden. Wigbert
Hallo, eine Idee unsere HF Reaks: Einfach im Baumarkt eine aktive DVBT Antenne kaufen, die +15db macht und schon ist der superempfindliche Empfänger fertig. Kosten 20€ das Stück an 75 Ohm Buchsen.
Hab im TXT jezt 2 neue Kommandos hinzu gefügt, die ich noch vergessen hatte. Einmal das PLL-Config-Command sowie das Syncron-Pattern-Command. Damit kann man zum einen die Oszilatorparameter und zum anderen den Syncronisations-Wert für den Datenfilter festlegen. MfG TPM
Re.HB9CV Ich wusste ich hab die Bauanleitung noch. aus FA 05.01 Wigbert
Hier auch noch was über einfache Helix Antennen und Whip's. 70cm Yagi's kosten 39€ bei ebay, da lohnt der selbstbau nicht.
Hallo Martin, >@Wigbert .. ? .. verstehe deine Antwort in bezug auf meine Frage nicht wollte sagen Du hast recht. @Benedikt >ist das RSSI Signal >schwächer, wenn die Sendefrequenz und Empfangsfrequenz genau >übereinstimmen. damit könnte ich die genaue Frequenzabstimmung prüfen. aber woher weiss ich, ob ich völlig daneben liege, oder genau drauf. Abgesehen vom Datenempfang. Wigbert
Christian J. wrote: > Hier auch noch was über einfache Helix Antennen und Whip's. 70cm Yagi's > kosten 39€ bei ebay, da lohnt der selbstbau nicht. Naja, ich habe 45 Minuten für eine mit 6 Elemente gebraucht, inkl. Werkzeug und Bauteilsuche. Also das lohnt sich meiner Meinung nach schon. Wigbert P. wrote: >>ist das RSSI Signal >>schwächer, wenn die Sendefrequenz und Empfangsfrequenz genau >>übereinstimmen. > > damit könnte ich die genaue Frequenzabstimmung prüfen. > aber woher weiss ich, ob ich völlig daneben liege, oder genau > drauf. Abgesehen vom Datenempfang. Das ganze war ohne Modulation. Mit Modulation ist das Basisbandsignal ja ein Recheck und keine Gleichspannung. Daher gibt es dieses Abfall nicht. Um also das RSSI Signal sinvoll nutzen zu können, muss der Sender ein FSK Signal senden (z.B. abwechselnd 0 und 1) und der Empfänger wird auf maximales RSSI Signal abgestimmt. Das Bild hatte ich nur gemacht, um den Frequenzganz der Filter sehen zu können.
Benedikt, kann ich die RSSI Spannung messen. Wie hoch ist die. Mich würde mal die Feldstärke bei Bandbreitenänderung interessieren. Wigbert
Ja, die kann man messen. Laut Datenblatt entsprechen -100dBm etwa 300-600mV und -65dBm etwa 1000-1300mV. Bei mir geht die Spannung von etwa 450mV bis 1150mV.
hmm .. ich kann irgend wie den Punkt auf der RFM12 Platine nicht finden, wo ich das Analoge RSSI abgreifen kann. .. ich bekomm entweder 0V oder 5V raus .. an allen möglichen anschlüssen auf der platine ... an einem kondensator hab ich noch die Quarzfrequenz messen können, aber kein RSSI. MfG TPM
Benedikt K. wrote: > Hier: > http://www.mikrocontroller.net/attachment/22519/rfm01.JPG ahaaa .. danke .. hmm .. komisch .. da bekomm ich n ziemlich merkürdiges Signal raus .. nix lineares, oder irgend n rauschsignal .. da liegt eher eine mischung aus rechteck und dreieck an. und das extrem regelmässig. MfG TPM
genau Benedikt, ich messe ohne Messender(Dauerträger) 0,9V mit Empfang ohne Antenne 1,5V(na ja 1,5m zu Sender) mit Stabantenne 1,6V. Alles gegen GND richtig? kann man da rumlöten ? Wigbert
also beim Text senden, springt natürlich der Spannungswert im Zickzack. Wie koppel ich das Signal aus ohne den RFM12 zu versauen, dann den Effektivwert auf einer Balkenskala od. ähnlich bringen. Wigbert
naja.. .. also .. mein meinem RFM12 sende ich garnichts ... ich nehme ihn nur her, und empfange umgebungsrauschen, ohne irgend was explizit empfangen zu wollen .. trotzdem zeigt er das ziemlich linear an ... MfG TPM
Ich meine wenn der RFM12 den Text empfängt, also kein monotonen Trägerempfang. bekommt ja nur kurzzeitig ein Signal zum Auswerten. Wigbert
naja.. ich ging gerade davon aus, das der RSSI anschluss auch ein RSSI liefert, udn nicht nur dann, wenn er etwas empfängt .. schliesslich ist es ja eine art Feldstärkemessung. .. dazu noch analog ... das sollte aus meiner sicht ein massives rauschen drauf sein, und kein stetig lineares (taktähnliches) rechteck (oder sowas ähnliches) sein .. .. ?!? MfG TPM
Hallo Martin,
mein Oszi zeigt auch teilweise undefiniertes Zeug an.
aber nach Benedikt:
>Ja, die kann man messen.
hab ich ein Multimeter rangehangen, war das nicht richtig ?
Wigbert
Angehängte Dateien:
Ich habe an den RSSI Pin einfach einen Tiefpass aus 10k und 10nF gehängt. Bei einem statistisch zufälligen Datensignal ergibt das natürlich ein Rauschen an dem Pin, genauso wenn kein Signal anliegt. Das mit dem Dreieck/Rechteck kann ich auch erklären: Das müssten die Daten sein, die empfangen werden. Das Bild zeigt deutlich, dass noch Reste der FSK Frequenz und der Daten auf dem Signal vorhanden sind (was ja auch klar ist). Das RSSI Signal auswerten, wenn nur kurze Datenpakete empfangen werden, ist also nicht ohne weiteres möglich. Eine Möglichkeit wäre aber einfach mit einer Diode die die Spitzenspannung in ein RC Glied läd. So macht man das ja auch bei einem VU Meter für Audio. Ach ja, bevor jemand fragt: Der Peak bei 433,8MHz kommt aus der USB Leitung an die das Modul angeschlossen ist. Keine Ahnung wiso, es ist aber so. Man sieht aber deutlich die beiden Frequenze 434,36MHz+/-90kHz.
mir ist gerade aufgefallen, das das Modul bei aktivem Daten-Request (Hex:b800) irgend n schmarn mit dem RSSI signal macht ... wenn ich die abfrage des fifos stoppe, dann habe ich ein lineares signal, das bei aufgedrehtem V/Div ziemlich rauscht. wenn ich lese-routine wieder aktiviere, dann fängt es wieder mit dem "rechteckigem dreieck" (kann ich nicht anders beschreiben) an. sieht auch irgend wie so aus, als wenn irgend ein kondensator geladen, udn wieder entladen wird .. irgend was kleineres .. vieleicht 10n oder sowas ... MfG TPM
Martin W. wrote:
>irgend was kleineres .. vieleicht 10n oder sowas ...
Der Kondensator an dem du das Kabel angelötet hast, hat 4,7nF, das
könnte also passen.
Ich frage mich aber trotzdem, wiso er das macht. Nur mal damit ich das
richtig verstanden habe: Das Signal ist solange stabil, bis du das FIFO
ausliest ? Ob das FIFO aktiv ist oder nicht, hat keinen Einfluss ?
Hallo, mal so ein Tipp, da ich die Auswertung des RSSI nicht so ganz verstehe, denn das Signal ist einfach nur Murks, ebenso das RSSI Bit im Status, das wackelt auch wie verrückt. Das Riesenproblem bei diesen Modulen ist, dass der zuständige Controller binnen 0,2ms (!) auf einen Datenempfang reagieren muss, egal was er gerade macht. Meiner ist sehr beschäftigt, auch mit Dingen die bis zu 0,1s dauern, zB Infrarot oder Display bzw MMC Zugriffen. Und dabei sind die INTs abgeschaltet. Ich frage in der Zustandsmaschine der Hauptschleife des Empfängers einfach immer wieder das DQD Bit ab. Der Sender wird mit aktiviertem Synthesizer als reiner Müllsender betrieben, der den Fifo nicht auslöst aber das DQD Bit bedient. Das kann der Empfänger erkennen und sich auf den Empfang einstellen, der kurze Zeit später kommt. Alles nicht ganz einfach, bei Duplex wird es noch schwieriger :-( Christian
Christian J. wrote: > Das Riesenproblem bei diesen Modulen ist, dass der zuständige Controller > binnen 0,2ms (!) auf einen Datenempfang reagieren muss, egal was er > gerade macht. Naja, 0,2ms sind für einen µC eine ewig lange Zeit, immerhin etwa 3000 Befehle. > Meiner ist sehr beschäftigt, auch mit Dingen die bis zu > 0,1s dauern, zB Infrarot oder Display bzw MMC Zugriffen. Und dabei sind > die INTs abgeschaltet. Wiso schaltest du die INTs ab, die sind genau für solche Fälle gedacht ? > Ich frage in der Zustandsmaschine der Hauptschleife des Empfängers > einfach immer wieder das DQD Bit ab. Das DQD ist aber auch nicht besonders aussagekräftiger. Meinen Messungen nach ist nur das gefilterte VDI Signal einigermaßen zuverlässig: Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" Mach das ganze doch einfacher: Bau etwas ähnliches wie ich ein, so dass die Daten gesendet werden, der Empfänger bestätigt den Empfang. Wenn keine Bestätigung kommt, wird einige 10ms später nochmal gesendet. Damit sind dann auch 100ms Empfangsblockade kein Problem. Allerding setzt sich auf diese Art die 100ms Blockade auf alle folgenden µC fort (d.h. der sendende µC ist dann auch für 100ms ausgelastet.)
Hi, die INTs sind sehr wohl ein Problem, da die bidirektionalen SPI Datenströme mit Timeout der Slaves arbeiten, damit die nicht hängen, wenn der Master spinnt. Und es sind 7 Slaves ;-) Habe mal versucht im INT auch mit der SPI zu arbeiten, das gibt totales Chaos nach einiger zeit. Das DQD Signal ist bei mir sehr stabil, wenn man den Filter etwas heruntersetzt.
OK, das ist ein Problem. Da hilft dann nur Soft SPI für das RFM12. Hast du bei DQD die Werte runtergesetzt, oder bei RSSI ?
Angehängte Dateien:
-
PIC00006.JPG
41 KB
Hi, also ich habe LNA auf voll gelassen aber RSSI um 2 Punkte runter. Dann blinkt DQD im Takt des Trägers. Aber mal was anderes, lustiges ;-) Antenne ist ja feritig, wie im Bild zu sehen. Habe mal aus Spass eine schnelle Routine laufen lassen, die immer 1 Byte auf allen Frequenzen eng um 433,92 Mhz schnell nacheinander sendet. bandbreite auf Maximum eingestellt. Antenne ans Fenster gestellt und mal so den Nachbarn zugeschaut :-) Ähmm..... die kriegen ihre Autos mit den Funkschlüsseln nicht mehr auf oder nur nach zigmal drücken ;-) prust *grins* Nettes Spielzeug!
Christian J. wrote: > also ich habe LNA auf voll gelassen aber RSSI um 2 Punkte runter. Dann > blinkt DQD im Takt des Trägers. Allerdings verschenkst du damit Reichweite. Bei mir steht RSSI um 1 Punkt runter, und mit der Yagi Antenne sind 200m innerhalb bebautem Gelände kein Problem. Später werde ich mal die andere Richtung in Richtung Wildniss testen. > Ähmm..... die kriegen ihre Autos mit den Funkschlüsseln nicht mehr auf > oder nur nach zigmal drücken ;-) prust *grins* Würde ich auch gerne mal machen. Mein Nachbar hat eine Garage mit Funkfernbedienung. Ich wollte schon lange mal schauen ob ich den Code kopieren kann, aber leider hat dessen Kleinkind die Fernbedienung eines abends vom Balkon geworfen, so dass die Garage mittlerweile nur noch per Hand geöffnet wird.
Hallo Leute, ein breitbandigen Träger setzen und Fernsteuerungen stören. Das ist nun wirklich Mist was Ihr macht. Wie weit seid ihr dann noch von der Funküberwachung entfernt? Wigbert
Mit 2 von den Yagis bin ich mittlerweile bei 400m. Weiter konnte ich nicht testen, denn dann bin ich hinter einer Bergkuppe und der Empfang ist weg.
Nur mal Anmerkung, ein Forum ist eigentlich nicht so der richtige Platz für ein Zwiegespräch. Wärs nicht besser, Ihr unterhaltet Euch per E-Mail weiter und postet nur dann was, wenn es auch allgemein brauchbare Ergebnisse gibt ? Das wäre zumindest für Beispielthreads wesentlich günstiger. Ich denke mal, daß unter diesen vielen privaten Plaudereien kaum noch jemand, der auch an dem Thema interessiert ist, die wirklich informativen Perlen herauspicken kann. Ich würde diesen Thread daher als verbrannt (durch uninformativen Müll totgepostet) ansehen. Peter
Mag sein.... ... aber das ist Hobby und kein wiss. Projekt und solange nur ein Thread zugespamt wird ist das ok. Schlimmer wirds, wenn zu jedem Pups ein neuer Thread aufgemacht wird. Und die Nachbarn mal zu ärgern, naja.... wenn ich meinen Humor nicht hätte, dann wäre ich bei diesem trockenen E-Technikerberuf mit lauter ernsten Ingenieuren um mich herum schon längst in der Klapse gelandet. Also, lass uns unseren Spass hier, es wird ja niemand gezwungen Themen zu lesen, die nicht seinem Geschmack entsprechen. Und an der Grenze zu Legalität ist das sowieso spätestens seit der Bestellung der HF Nachbrenner, die schon alle verkauft sind ;-)
Ich komme zwar nicht mehr mit, da ich die wichtigen Infos in dem Thread nicht mehr finde. Aber mit den Garagentoröffnern könntet ihr Pech haben. Hörmann sendet z.B. auf 35MHz... Bei den Autos sieht es anders aus. Kann jemand von euch bitte einen Artikel in der Wiki eröffnen und das wesentliche dort verewigen? Ich suche mir mittlerweile den Wolf... Danke im voraus! Gruß Elektrikser
>>Kann jemand von euch bitte einen Artikel in der Wiki eröffnen und das >>wesentliche dort verewigen? Das ist nur leider mit Arbeit verbunden, Arbeit die niemand bezahlt und die einem persönlich nichts bringt, alles Wissenswerte steckt im Code oder ich habe es als pdf ausgedruckt bzw. in meinen "Tips & Tricks" Ordner ausgedruckt. Wissen auf Webservern, digitales Wissen überhaupt ist schnell vergänglich, da lohnt es einfach nicht. Nächstes Jahr sind die Module überholt, dann kommt was Neues.... und dafür die viele Arbeit? Vielleicht fängst Du ja mal an, wenn Du ein Wiki bedienen kannst... ;-)
Einen Wiki Eintrag werde ich nicht erstellen, da ich dazu weder Zeit noch Lust habe. Da sich auch sowiso keiner für die Software interessiert (was ich daran merke, dass die Software noch einige größere Bugs hat, sich aber noch niemand beschwert hat, dass die Software nicht läuft), ist es ja auch egal, wenn in dem Thread ein wenig über andere (durchaus für alle interessanten) Themen über das RFM12 diskutiert wird.
Kann mit Fragen erst kommen, wenn meine Platinen fertig werden. Da noch andere Projekte wichtiger sind, dauert das bestimmt noch. Gruß Elektrikser
ich verfolge den tread jetzt schon längere zeit und habe nix gegen zwigespräche :)
Klaus Seufzger wrote: > ich verfolge den tread jetzt schon längere zeit und habe nix gegen > zwigespräche :) OT: Dito :-) Ziemlich interessant.
@Benedikt Ich habe mir auch einige der Module besorgt. Ich interessiere mich für die Software! Für RS232 habe ich auf jeden Fall Verwendung und möchte auch Funkthermometer Luftfeuchtemesser und verschiedene elektrische Steckdosen damit ansteuern (weiss halt noch nicht ob das prinzipiell möglich ist). Möchte aber auch selbst etwas entwickeln und mit Bluetooth und/oder WLAN etwas zusammenbrauen. Irgendetwas zusammenzulöten damit es, wenn es funktioniert in der Ecke liegt, das ist nicht mein Ziel und war noch nie so. Ich persönlich brauche immer relativ viel Zeit, bis ich genau weiss wie ich etwas realisiere. Die Realisation selbst ist dann in ganz wenig Zeit gemacht. Aus diesem Grund habe ich mir nichtmal die Mühe gemacht etwas runterzuladen, nicht weil deine Software möglicherweise Bugs enthält sondern weil ich noch nicht weiss was ich damit anfangen kann. Die meisten Blödmänner attestieren mir jetzt dass ich minderbemittelt bin. Ich bin nur anspruchsvoll das ist alles. EIn paar Bugs stören mich nicht eher schon, dass ich da von deiner Arbeit rumschnorre....
Hi die Platinen sind endlich gekommen. Werde versuchen sie heute abend mal aufzubauen und zu testen. Benedikt hatte ja freundlicherweise was geschrieben was sich via Software configurieren lässt. Ich sag bescheid wie es läuft. Grüsse Tobi
Hallo, eben kam die Antwort von integration zu undokumentierten Features des RFM02, wie zB D040. Leider kein weiterer Kommentar dazu, weil für die Funktion dieser Features keine Haftung übernommen wird. Wenn sie erst einmal bekannt sind berufen sich Kunden darauf. Tja, schade.... Gruss, Christian
Schade. Vielleicht kann Integration weiterhelfen ? Da die ICs ja von Integration stammen: RF02 sollte auch OOK können, und sogar mit einem EEPROM alleine, ohne µC laufen. Der wäre somit ein schöner Ersatz für die einfachen AM Sender.
Hallo Benedikt
>Da sich auch sowiso keiner für die Software interessiert
das ist nicht ganz die Wahrheit.
Also bei Deinen Code "Funkbrücke mit Baudrateneinstellung"
benutzt Du bei niedriger Baudrate schmalere Bandbreite.Mehr nicht
notwendig?
Verstärkung -6dB richtig? warum ?
DRSSI -103 db bedeutet das nicht kleinster Wert ? Warum ?
Zwischenzeitlich hattest Du andere optimale Werte reingestellt.
Sollte ich das ändern ?
Wigbert
Wigbert P. wrote: > Also bei Deinen Code "Funkbrücke mit Baudrateneinstellung" > benutzt Du bei niedriger Baudrate schmalere Bandbreite.Mehr nicht > notwendig? Das hatte ich anfangs gemacht, da ich dachte die optimalen Werte aus dem Datenblatt wären optimal. Allerdings ist mit denen die Reichweite teilweise um den Faktor 2 kleiner als mit mehr Bandbreite (ist ja irgendwie klar: Mehr Bandbreite heißt eine Störung auf einer Frequenz hat weniger Einfluss.) > Verstärkung -6dB richtig? warum ? Wo steht das ? Ich finde das nirgends. > DRSSI -103 db bedeutet das nicht kleinster Wert ? Warum ? Das ist der kleinste Wert. Dadurch reicht der schwächste Pegel aus, damit Daten empfangen werden. Allerdings darf dann wirklich kein anderer Sender in der Nähe sein, damit das funktioniert. Daher kann man ja die Umgebungsbedingungen einstellen. > Zwischenzeitlich hattest Du andere optimale Werte reingestellt. > Sollte ich das ändern ? Wenn du willst, die bringen etwas mehr Reichweite. Demnächst gibt es aber noch eine ganz neue Version, mit besserer CRC und ein paar behobenen Fehlern.
Benedikt,
damit ich das richtig verstehe:
>-environment*6dB
Ich dachte LNA ist doch die Empfangsemfindlichkeit
DRSSI dachte ich ist die Analogausgabe der Feldstärke.
Also mit DRSSI stelle ich die Empfindlichkeit ein.Mit grösserer Gefahr
des "Zumüllens"
und was macht dann LNA (Gain heisst doch Gewinn)
Wigbert
Achso, jetzt weiß ich was du meinst. Es gibt RSSIseth und LNA. Das erste ist der Schwellwert, den das Signal mindestens haben muss um Daten zu empfangen. LNA ist der Verstärker davor. Ich lasse den Schwerwellert immer auf dem emfpindlichsten (mittlerweile eine Stufe darüber), und verändere die Verstärkung, denn diese verstärkt ja auch die Störungen mit, wenn welche vorhanden sind. Vermutlich kann man aber auch genausogut den RSSI Schwellwert verändern.
Benedikt,
wohl die wichtigsten Fragen:
Der RSSI-Pin(Analogwert der Feldstärke) steht in welchen
Zusammenhang zur Eingangsfeldstärke (proportional.....Formel?)
Zum Eichen eines S-Meters notwendig.
>Demnächst gibt es aber noch eine ganz neue Version, mit besserer CRC und....
mein Boardentwurf kann der bleiben, oder wird an der Hardware
entscheidendes verändert.
Wigbert
Die Hardware wird bleiben, zumindest bei der RS232 Funkbrücke. Laut Datenblatt entsprechen 300-600mV etwa -100dBm und 1000-1300mV -65dBm. @ Martin W. Die Recht und Dreiecke die du am RSSI Pin siehst, kann es sein dass das die Daten sind ? Ich erhalte bei mir nämlich auch Rechtecke, das sind aber die einzelnen Datenpakete vom Sender.
Hallo, habe nach Benedikts Einstellungen ein Reichweitentest gemacht. Durch 2 Gebäude ca 100m (Fahrzeuge stehen zw. den RFM12) fehlerlose Übertragung. Als Sendeantenne: http://www.mikrocontroller.net/attachment/24329/PICT0017.JPG Als Empfangsantenne Drahtantenne. wirklich erstaunlich. Übrigens wer ein Multimeter mit Bargraphanzeige hat kann am RSSI-Pin die Feldstärke verfolgen. Hatte max.4 Balken. Kein Balken > kein Empfang. Einstellung Wechselspannung, da sich der Pegel pos.+ neg. gegenüber dem Grundrauschen verhält. Wigbert
Wigbert, auch wenn es schon gesagt wurde, habe ich heute sät nachmittag noch mit einem Herr Dutton von Integration telefoiert (auch wenn ich dem als Begründung für meinen Wissensdrang das Blaue vom Himmel heruntergelogen habe, denn Hobbyisten supporten die nunmal nicht) LNA ist ein einstellbarer Analogverstärker, der all das was er sieht verstärkt. Der RSSI Threshold ist die Schaltwelle ab der ein gültiger Träger detektiert wird. Es ist egal, welchen Wert man anpasst, das Ergebnis ist das Gleiche aber der Chip braucht mehr Strom bei empfindlicher Einstellung, denn der Datenmüll erzeugt viele Schaltungen. Legt man den Müll auf den Datenpin statt den Fifo zu nutzen kann man das schön sehen. Die Gefahr bei sehr hoher Empfindlichkeit ist, dass 2DD4 häufiger kommt, mehr aber auch nicht. Ich fahre sehr gut mit reiner Reduzierung der beiden Werte um jeweils einen Punkt, dann habe ich auch ein zuverlässiges DQD Bit, um den Träger zu erkennen. Der Reichweitenverlust ist leider nicht unerheblich, runde 50m sind es schon, da 3db ja einer Verdoppelung entsprechen aber im Sinne einer Übertragung, die nahezu 0% Fehler hat nehme ich das in Kauf. Gruss, Christian
Wichtiger Hinweis für die RFM02 Module Integration: "The RATE/2 comment is there since in thiscase the IA4221 chip will sample the FSK pin both at rising and falling edges of the 50% duty cycle signal on nRES this way keeping the same datarate as set by the datarate command." D.h. wenn das D040 Kommando für langsame uC benutzt wird, muss das Bit auf der steigenden Flanke an den Chip gesendet werden UND das nächste Bit auf der fallenden Flanke, sonst halbiert sich die Baudrate, was ich auch bemerkt habe. Gruss, Christian
Hallo Christian,
den reichweitentest hatte ich nur gemacht, um zu sehen ob sich
die "Balkenanzeige" verringert. Musste echt dafür laufen.
>Reduzierung der beiden Werte um jeweils einen Punkt
Wenn ich Dich richtig verstehe würdest Du für
LNA -6dB
RSSI -97dBm
empfehlen.
Wigbert
Interessant. Weist du wie man das D040 Kommando wieder abschaltet ? Mit D000 ? Die LNA und RSSI Einstellungen sind abhängig vom Verwendungszweck. Wenn das ganze z.B. nur eine drahthlose Tastatur mit max 5m Reichweite werden soll, dann würde ich beide Werte etwas hoch setzen, damit man nicht jeden Müll empfängt. Ich habe mir eine Frequenz ausgesucht, auf der wirklich nichts los ist. Dann ist selbst bei einem Punkt über dem empfindlichsten das DQD Bit stabil. Allerdings ist dieser Zustand selten in stark bebauter Umgebung. Ich lasse daher die Einstellungen auf dem empfindlichsten Level (bzw. RSSI eines runter) und verwerfe die Pakete bei denen das Syncwort fälschlicherweise empfangen wurde (das passiert etwa einmal alle 2-10h) spätestens bei der Prüfsumme.
Benedikt hab dir gerade mal ne PN gesendet ;)
Benedikt K. wrote: > @ Martin W. > Die Recht und Dreiecke die du am RSSI Pin siehst, kann es sein dass das > die Daten sind ? > Ich erhalte bei mir nämlich auch Rechtecke, das sind aber die einzelnen > Datenpakete vom Sender. Das glaube ich nicht .. dafür ist das Signal viel zu gleichmässig. Das sieht aus, wie von nem Generator generiert. es schwankt nicht. Zudem habich garkeinen Sender laufen, der daten schickt. auch mitm Scanner kann ich keine Quelle ausmachen, die auf dieser Frequenz was ausstrahlt. @Wigbert P. Ichhabe hier ... https://www.mikrocontroller.net/attachment/24947/RFM12.txt ... ein paar beschreibungen zum LNA und RSSI .. aber nur für den RFM12 .. sollte allerdings für RFM1 und 2 auch gelten. MfG TPM
Hallo Wigbert, sobald meine bestellten Chipse eintreffen werde ich die Routinen so umschreiben, dass Sender und Empfänger einen Komm.Test machen werden, der Sender reduziert seine Stärke stufenweise, der Empfänger seine Empfindlichkeit und beide messen dann die Fehlerraten und entscheiden sich für eine ideale Konstellation. Das wird zwar einiges an Hirnschmalz erfordern das zu realisieren aber es ist auf jeden Fall eine Herausforderung ein dynamisch arbeitendes System zu haben, das sich der Umgebung anpasst. Freue mich schon drauf das zu coden ;-) Gruss, Christian
Hallo Martin, hab das Ding schon gesucht, dank Dir. Hallo Christian, Dein Vorhaben ist sicher gut gemeint, aber wenn Du die Funkbrücke, wie ich über ein längeren Zeitraum nutzt und Störer auftreten, würde das System sich immer wieder Synchronisieren........... Bin aber schon gespannt. Wigbert
Ich hatte mir auch schon den Kopf zerbrochen, wie man das ganze ordentlich lösen kann. Es gibt einfach zu viele Fälle die Probleme bereiten können, vor allem wenn es mehr als 2 Teilnehmer sind (A in Reichweite von B, C in Reichweite von B, aber A und C außer Reichweite usw.). Oder solche Fälle wie, dass ab und zu ein Funkthermomenter mal für wenige 100ms dazwischenfunkt. Danach ist ja wieder alles OK. Ich dachte an ein regelmäßig Statuspaket als Keep Alive Signal. Wenn dieses für ein paar Sekunden ausbleibt wird automatisch ein Suchmodus gestartet. Bei Integration gibt es eine Funktastatur als Beispiel für diese ICs. Die nutzen 3 Frequenzen um die Daten 3x zu übertragen + ein Suchsystem. Da kann man vielleicht einiges abschauen.
noch ein Clone, das Datenblatt gibt diesesmal mehr an Infos her. Zu kaufen für 3.95 bei CSD -> http://www.csd-electronics.de/de/index.htm Gruß Hagen
Stimmt, das IC entspricht dem RF12(=IA442x). Letztere sind ja keine Clones, sondern identisch. Und TXC10x ist der RF02, RXC10x der RF01...
Hi Benedikt, ich habe zu Hause eine Application Note, in welcher der Aufbau von Funknetzen mit vieles Nodes beschrieben wird, die Telegramme durchreichen, bis sie den richtigen Mode treffen, auch wenn dieser ausser der Reichweite des Masters ist. Kommt ein neuer Node hinzu webt sich dieser in das Netz mit ein und bekommt eine IP zugewiesen. Gucken ob ich das noch finde oder schon gelöscht habe, war jedenfalls recht komplex. Aufbau war mit Solarzellen. Gruss, Christian
hört sich extrem interessant an, sowas ging mir auch schon durch den kopf, aber dürfte ziemlich aufwändig zu realisieren sein das stabil hinzubekommen?
@Benedikt: hast du mal den Sync-Pattern Befehl getestet ? Falls der bei den RFM12 Modulen funktioniert dann ist der TRC102 richtiger. Allerdings findet man nur im TRC101 Datenblatt das Umrechnungsdiagram vom RSSI Signal von Volt zu dB. Auf Seite 10 oder 11 wenn ich mich recht erinnere. Gruß Hagen
ich habe mir auch mal ein Angebot für den IA4420/IA4421 machen lassen. Die Teile kosten ab 97 Stück (Stange ) 2,60 EUR incl. MwSt. Ist also immer noch teurer, als so ein Modul. Den Quarz sollte man auch mit 0,40 EUR noch einrechnen.
Hi, die App.note ist leider weg, ging wohl beim Aufräumen mal verloren. Wie ich mich erinnere bestand die allerdings nur aus Software mit dem ARM Controller. Der Aufwand gleichberechtigte Nodes miteinander reden zu lassen, so dass sie Nachrichten weiterleiten ist allerdings enorm, vor allem was Buskollisionen angeht, denn jeder Empfänger muss ja horchen wann die Bahn für ihn frei ist. Neu ist die Idee auch nicht, es gab mal so eine Produktidee mit einem kostenlosen Telefon, je mehr Leute das Gerät haben umso grösser spannt sich das Netz auf, wobei jede Station wieder als Relais wirkt. Lassen wir das lieber, keine Lust auf 2 Jahre programmieren :-) Gruss, Christian
achja für alle die noch rfm12 module brauchen und noch etwas zeit haben.... Beitrag "Re: Sammelbestellung RFM12"
Hallo, welche Senderbandbreite fahrt ihr denn? Ich habe da auf 90khz stehen, also 9850 eingeschrieben, den Empfänger dann entsprechend größer (irgendwas um 130 khz). Macht es Sinn diese dynamisch mit der Baudrate zu verändern oder liebe ein Werte für alle? Möchte meine Routinen möglich universell haben. Gruss, Christian
Ich lasse die 90kHz immer stehen. Die Baudrate wird bei mir nie über 65000 Baud liegen, da dann ziemlich schnell die Reichweite kleiner wird. Den Empfänger habe ich auf 200kHz stehen. Weiß jemand ob die Bandbreite +/-200kHz beträgt, oder insgesamt 200kHz, wenn man 200kHz einstellt ? Die Modulation macht +/-90kHz wenn man 90kHz einstellt.
Hi, können wir vielleicht mal einen neuen Thread für alle allgemeinen Themen aufmachen, damit es nicht so lange wird? Mit Codesammlung hat das ja alles nicht mehr viel zu tun. CJ
Hallo, anbei noch ein Scan des RFM12 als Senders, die eingestellte Frequenz passt exakt.
@ Wigbert Kannst du evtl. die *.Sch *.brd von RS232-Funkbr_cke.rar hier posten ?! Danke
@W. Przybilla (przybilla) Mail angekommen? Wigbert
Angehängte Dateien:
-
rfm12.jpg
60 KB
Hallo Benedikt, ich habe mir zwei von deinen Platinen mit Mega8 und RFM12 + Mutterplatinen aufgebaut. Inzwischen funktioniert die Übertragung auch schon :-) Leider habe ich noch ein großes Problem. Die Module wollen den Mega8 einfach keine 10MHz gönnen. Beide blieben sturr auf 1MHz. Deshalb habe ich erstmal zum internen 8MHz Takt gegriffen. Nur leider ist das ja vor allem bei hohen Baudraten nicht das gelbe vom Ei. Bei 19k2 klappts noch. Hast du eine Ahnung woran das liegen könnte? Bis zu welchen Baudraten funktioniert die Übertragung eigentlich noch gut? Ich habe hier einen Fall wo ich 57k6 übertragen müsste. Falls das klappt, welche RFM12 Baudrate wäre zu empfehlen? Vielen Dank für die Software und das PCB! Gruß Björn
Björn Biesenbach wrote: > Mutterplatinen aufgebaut. Inzwischen funktioniert die Übertragung auch > schon :-) Leider habe ich noch ein großes Problem. Die Module wollen den > Mega8 einfach keine 10MHz gönnen. Beide blieben sturr auf 1MHz. Eigentlich dürfte das nicht sein: Entweder der Takt wird korrekt eingestellt, oder es dürfte garnichts funktionieren. > Bis zu welchen Baudraten funktioniert die Übertragung eigentlich noch > gut? Ich habe hier einen Fall wo ich 57k6 übertragen müsste. Falls das > klappt, welche RFM12 Baudrate wäre zu empfehlen? Wenn du einen externen Quarz verwendest, sollte nahezu jede Baudrate möglich sein. Das RFM12 kann bis etwa 125kBaud, allerdings ist die Reichweite dann ziemlich gering. Ich habe es allerdings noch nicht ausprobiert. Bis etwa 50kBaud funktioniert es aber ziemlich gut.
Tach ich hab auch das problem mit dem 1MHz das aus dem RFM12 rauskommt. Gibts dazu ein workaround (ausser avr direkt takten?) Tobi
Hab jetzt doch mal einen Wiki-Artikel angelegt und https://www.mikrocontroller.net/attachment/24947/RFM12.txt integriert. Ich finde das Forum für konkrete Problemlösungen auch nicht so gut, man findet irgendwann einfach nix mehr. http://www.mikrocontroller.net/articles/RFM12
Hallo zusammen, Nach nächtelanger Fehlersuche habe ich nun endlich das RFM12-Modul im IRQ-Betrieb zum Laufen bekommen. Als Hardware verwende ich ein Breedboard mit RFM12 und das Pollin-Board. Danke an HagenRe für den Tip. Mein größtes Problem war die Auswertung des IRQ-Signals. Da ich auf dem Pollin-Board keine größeren Modifikationen vornehmen konnte war der Einsatz eines Inverters ausgeschlossen. Darum hatte ich mit dem MCUCR-Registern gearbeitet und Die Trigger auf steigende Flanken eingestellt. Heute hat es endlich zum Erfolg geführt. Weil evtl noch andere an dieser Stelle hängen hier die Änderungen am Code: rf12_init:
1 | FFIT_DDR &= ~(1<<FFIT); // Muss eingestellt werden zur späteren Abfrage, FFIT vorher per #define eingebunden |
2 | RF_PORT = (1<<CS); |
3 | RF_DDR &= ~(1<<SDO); |
4 | RF_DDR |= (1<<SDI)|(1<<SCK)|(1<<CS); |
5 | //DDRD&=~8; // Die Settings wurden doch schon gemacht - bringt nur Fehler deshalb raus...
|
6 | //PORTD|=8;
|
In der ISR habe ich dann noch folgende Schleife eingebaut
1 | while ((FFIT_PIN & (1<<FFIT))) |
2 | {
|
3 | ...
|
4 | }
|
Nun funktioniert die Übertragung per IRQ bei mir auch perfekt. Da die ISR nur noch 1x pro Paket aufgerufen wird ist die Schleife notwendig. Ansonsten kann man sich mit diesen Settings den Inverter sparen.
Den Inverter kannste dir auch Sparen, wenn du nicht den Level-Int brauchst, sonder auf Flanke triggern kannst. Z.B. per PCINT oder auch per echtem ext.Int. Dann kannste direkt das FFIT Signal reinfüttern und brauchst im Prinzip die Schleife nimmer, da das FFIT solange feuert, wie Daten im Puffer sind. Man ruft dann pro Int einfach nur ein Byte ab. Gruß Fabian
Hallo, ich bin gerade dabei meine ersten Erfahrungen mit den RF12 868MHz Modulen zu machen und benutze die zweite Softwareversion vom 19.06.2007. Habe das ganze auch versucht auf die 868MHz Module abzustimmen. Dafür habe ich folgende Änderungen gemacht:
1 | main.c |
2 | rf12_setfreq(RF12FREQ(868.50)); // Sende/Empfangsfrequenz auf 868,50MHz einstellen |
3 | |
4 | rf12.h |
5 | #define RF12FREQ(freq) ((freq-860.0)/0.005) // macro for calculating frequency value out of frequency in MHz
|
6 | |
7 | rf12.c |
8 | void rf12_init(void) |
9 | rf12_trans(0x80E7); // Enable FIFO zweiten Character(von rechts) von D auf E gestellt 433 auf 868 MHz |
sonst habe ich alles so gelassen wie es war. Er scheint zu senden, jedenfalls leuchtet die TX LED kurz auf. Nur beim Empfänger leuchtet die RX LED von Anfang an. Auch wenn der Sender nicht läuft. Freue mich über jede Hilfe. Bye, Christian
Es gibt eigentlich keinen Sender und Empfänger. Beide sind gleichwertig. Wenn also bei einem die LED von Anfang an leuchtet, ohne dass dieser etwas sendet/empfängt, dann würde ich auf einen Fehler im Aufbau tippen.
Jup, sind beide gleichwertig. Habe mich wohl falsch ausgedrückt. Die RX-LED leuchtet bei beiden Modulen von Anfang an. Laut Code soll die doch eigentlich nur leuchten, wenn er Daten im RF12 RX Puffer hat. Gruß, Christian
ehemals Christian M. So, ich konnte es noch genauer eingrenzen. Er führt die Funktion
1 | unsigned char rf12_rxdata(unsigned char *data) |
aus und bleibt dann in der
1 | for (i=0; i<number; i++) |
Schleife hängen. Alles was danach kommt wird nicht mehr ausgeführt. Darum geht die RX-LED auch nicht mehr aus, da dieser Befehl danach kommt. Aber zwei Sachen verstehe ich nicht. Erstens sollte er garnicht in diese Funktion reinkommen, da er noch nichts empfangen hat und somit der Buffer leer sein sollte. Zweitens blinkt die TX-LED die ganze Zeit, was ja zeigt, dass das Programm noch läuft. Da man ja keine parallel laufende Tasks hat, dürfte das nicht der Fall sein wenn er in im for-Loop hängen bleiben würde. Bin also gerade ziemlich ratlos und müde... Würde mich echt über hilfe freuen. Meistens sehen 4 oder mehr Augen mehr ;-) Gruß, Christian
Hi, ich habe da nochmals ne Frage. Ich habe eine der ersten Versionen auf nem ATMega32 und 868MHz Modul zum laufen gebracht. Jetzt versuche ich aber schon seit Tagen die "rfm12_rs232_rxtx_check_int.zip" zum laufen zu bringen. Aber immer wenn ich den INT1 verwenden will, läuft nix mehr. Es scheint, als ob das Programm nicht läuft. Danach habe ich einfach mal probiert, in die Version die bei mir schon läuft den INT1 einzubauen. Aber da ist das selbe Problem. Ich habe folgende Einstellungen vorgenommen:
1 | MCUCR |= (1<<ISC11); |
2 | GICR |= (1<<INT0); |
3 | sei(); |
4 | |
5 | .
|
6 | .
|
7 | .
|
8 | |
9 | ISR(INT1_vect) |
10 | {
|
11 | cli(); |
12 | LED_PORT |= (1<<LED_READY); |
13 | sei(); |
14 | }
|
Nein, die LED bleibt aus und es wird auch kein Text mehr über den Seriellen Port ausgegeben, was ohne Interrupt wohl geschied.
Christian Mertens wrote: > Ich habe folgende Einstellungen vorgenommen: > [c] > MCUCR |= (1<<ISC11); > GICR |= (1<<INT0); > sei(); Du schaltest INT0 ein, verwendest aber INT1...
Okay, da habe ich wieder mal den Wald vor lauter Bäumen nicht gesehen. Dann versuche ich jetzt mal deine int-Version zum laufen zu bringen. Ich danke dir.
Zudem solltest du dir das cli(); und sei(); in der ISR sparen ;-) A) Das macht schon der Compiler für dich rein. B) Das 'kann' zu Problemen führen, da die Interrupts schon freigegeben werden solange die ISR noch aktiv ist. Das vom Compiler generierte sei(); ist so gelegt/optimiert, dass Interrupts wirklich erst wieder möglich sind wenn der Programmzähler wieder im unterbrochenen Programmteil steht.
Benedikt K. wrote: > Back to topic. Thema Antenne. > http://www.tfs.net/~petek/rockets/RDF/70ant.html > > Diese habe ich gerade eben nachgebaut. Das ging ziemlich flott und die > Antenne ist, wie soll ich es am besten beschreiben, einfach nur spitze: > Das Signal mit dieser Antenne ist ohne Sendersignal um etwa 5dB > schwächer als mit der 17cm Drahtantenne, die unerwünschten > Hintergrundstörungen werden also gut unterdrückt (wenn nicht gerade der > Störer in der gleichen Richtung liegt). In 20m Entfernung quer durchs > Haus, ist der Empfänger mit dieser Antenne immer noch übersteuert > (zumindest das RSSI Signal): Das RSSI Signal hängt bei 1130mV fest, > genau dem gleichen Wert wie direkt neben dem Sender. Die Antenne ist > also um etwa 20dB besser als die 17cm Drahtantenne ! > Wie groß die Reichweite ist, habe ich noch nicht ausprobiert, ich komme > mir nämlich etwas komisch vor, wenn ich mit einer 70cm langen Yagi > Antenne und einer Platine in der Hand die Straße entlang laufe... Ich > möchte nicht wissen, was die Nachbarn denken, wenn sie mich so sehen. > > Mit 2 solcher Antennen sollte die Reichweite ziemlich hoch sein (ich > schätze mal 500m oder mehr). @Benedikt, der von dir gepostete Link funktioniert leider nicht (mehr) http://www.tfs.net/~petek/rockets/RDF/70ant.html kannst Du das PDF noch mal bitte einstellen danke je
das ging ja flott... noch eine Frage zum Anschluss der Antenne am RFM12 - Koaxkabel direkt an PIN8 oder muss noch eine Anpassschaltung dazwischen? Wie hast Du dies bei Dir realisiert - vielleicht hat ja Deine Frau den Foto schon wieder herausgerückt...;-) Gruß je
Ich habe direkt ein kurzes BNC Kabel angelötet. Ich habe keine Ahnung, ob die Anpassung gut ist, ich denke aber das RFM12 müsste irgendwas um die 50 Ohm Impedanz haben. Zumindest liefert es an 50 Ohm etwa +4dBm, was auch der Maximalleistung laut Hersteller entspricht.
Hallo Benedikt, Funkbrücke mit DIP, noch mal zu den LED's: "Retransmitt" LED leuchtet wenn keine Datenübertragung von statten geht? "Error" LED leuchtet wenn das Modul sich aufgehangen hat? kann das nicht mehr wiederfinden. Wigbert
Wigbert Picht wrote: > "Retransmitt" > LED leuchtet wenn keine Datenübertragung von statten geht? Die leuchtet wenn eine Übertragung fehlerhaft war und nochmal gemacht wird. > "Error" > LED leuchtet wenn das Modul sich aufgehangen hat? Die leuchtet wenn die nochmalige Übertragung selbst nach mehreren Versuchen immer noch nicht gekplappt hat. Also der Empfänger komplett außer Reichweite ist, oder nicht läuft.
Dank Dir Benedikt, war wohl von mir schon in Vergessenheit geraten. Wigbert
Hallo, könnte man den BS170 (invertieren der Interruptanforderung vom RFM12 aus) auch weglassen und statt dessen den Interrupt von pegelgetriggert auf flankengetriggert umschalten, oder müsste man dafür die ganze Software überarbeiten? Wäre der Transistor auch für den Betrieb an 3.3V geeignet? Im Datasheet finde ich lediglich Diagramme für eine Gate-Source-Spannung von 4V. Gruß Dirk Schlage
Man müsste die Software überarbeiten. Es soll funktionieren, irgendwo hat jemand mal geschrieben, dass er es gemacht hat. Ansonsten nimm halt einen beliebigen anderen NPN Transistor mit Vorwiderstand. Der funktioniert dann sicher mit 3,3V. Der BS170 sollte auch funktionieren, da ja kaum Strom fließt.
Danke für die rasche Antwort. Ich werde vieleicht erst einen npn probieren. Welche Vorteile hast dur dir von dem FET versprochen? Dirk
Bei den neueren AVRs kannste den Inverter weg lassen und einfach den Pin-Change-Interrupt benutzen... Gruß Fabian
Sorry,
habe mich in meinem ersten Post unklar ausgedrückt.
Genau das hätte meine Frage sein sollen. Ich will eigentlich einen
Mega48 benutzen. Da aber doch ein unterschied zwischen pegelgetriggert
und
flankengetriggert ist, hier nochmal die Frage.
Benutzt jemand von euch den Code von Benedikt, und welche Änderungen
waren
nötig, um ihn mit flankengetriggert zum Laufen zu Bringen.
Gruß
Dirk
Hallo, ich verwende den Code von Benedikt ohne Inverter. Habe dazu den den Code wie folgt abgewandelt:
1 | void rf12_rxmode(void) |
2 | {
|
3 | rf12_trans(0x82C8); // RX on |
4 | rf12_trans(0xCA81); // set FIFO mode |
5 | _delay_ms(.6); |
6 | rf12_trans(0xCA83); // enable FIFO: sync word search |
7 | rf12_trans(0); |
8 | MCUCR |= (1<<ISC01)|(1<<ISC00); // Status lesen um Bits zu löschen |
9 | GIFR=(1<<INTF0); |
10 | GICR|=(1<<INT0); // Rising Level Interrupt für FFIT |
1 | ISR(SIG_INTERRUPT0) |
2 | { static unsigned char bytecnt, status, number, id, rf_data[MAX_BUF], rx_lastid=255,crcl; |
3 | static unsigned short crc; |
4 | while ((FFIT_PIN & (1<<FFIT))) |
5 | {
|
6 | ...
|
7 | }
|
Durch die Änderung ist der Interrupt nun aber länger aktiv, so dass mehrere Chars bereitstehen können. Die zusätzliche while-schleife erledigt dies (darin läuft der alte Code). Den Rising-Level Interrupt muss man für den Empfangsmodus aber seperat aktivieren, s.o.. FFIT_PIN und FFIT muss jeweils per #define definiert werden.
1 | #define FFIT_PORT PORTD
|
2 | #define FFIT_DDR DDRD
|
3 | #define FFIT_PIN PIND
|
4 | #define FFIT 2
|
An dieser Stelle muss ich Benedikt ein großes Lob für seinen gut aufgebauten Code aussprechen. Habe diesen mittlerweile in verschiedenen Hobbyprojekten auf einem PSoc und anderen Architekturen am Laufen. Das RF12-Modul bietet damit eine prima Schnittstelle zwischen den verschiedenen Welten. Gruß Lorenz
Danke Lorenz. Ich habe den Code jetzt umgestellt, wie du beschrieben hast. Ich verwende einen Mega88. Ein paar Registeranpassungen waren nötig. Ausserdem habe ich den Code wieder von INT0 zurück auf INT1 umgestellt. Leider hängt sich der Controller jetzt in der Init-Routine nach TIMSK1=(1<<OCIE1A); auf.
1 | void rf12_init(void) |
2 | {
|
3 | unsigned char i; |
4 | // RF_PORT=(1<<CS);
|
5 | CS_PORT=(1<<CS); |
6 | RF_DDR&=~(1<<SDO); |
7 | // RF_DDR|=(1<<SDI)|(1<<SCK)|(1<<CS);
|
8 | RF_DDR|=(1<<SDI)|(1<<SCK); |
9 | CS_DDR|=(1<<CS); |
10 | DDRD&=~8; // INT1 als Eingang schalten |
11 | PORTD|=8; |
12 | SPCR=(1<<SPE)|(1<<MSTR); |
13 | |
14 | TCCR1A=0; |
15 | TCCR1B=(1<<WGM12)|1; |
16 | OCR1A=((F_CPU+2500)/500)-1; |
17 | TIMSK1=(1<<OCIE1A); |
Mit dem Mega48 erlebt man immer wieder Überraschungen, wenn man Code vom
Mega8 einsetzen will. Vieleicht hätte ich lieber einen Mega16 oder
Mega32 nehmen sollen.
Gruß
Dirk
Christian J. wrote: (I can read German, but not speak/write it well..) > ich habe spasseshalber mal bei beiden Firmen nachgefragt, ob die Kopien > aus China denn legal sind. Auf die Antworten bin ich mal gespannt. Die > Sache ist nämlich die, dass wenn hier jemand Chips bestellt hat und die > Frachtpapiere weisen diese als Clone aus, dann war es das mit den Chips, > die wandern dann in den Shredder und die Kohle ist weg. Hope RF has licensed their dies and IP to a small number of chip manufacturers, and the ones mentioned in this thread are indeed 'legal'. Tschuss, Fred
Fred Van kempen wrote: > Hope RF has licensed their dies and IP to a small number of > chip manufacturers, and the ones mentioned in this thread > are indeed 'legal'. Also diesem Post nach: Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" ist es genau umgekehrt. Integration ist der Originalhersteller der Dies und verkauft die an HopeRF, die dann die Module daraus bauen.
Wie genau sieht die Minimalbeschaltung für die Software aus? In der Version ..int ist FFIT mit PD3 und in Version 4 mit PB0 beschaltet. Kann ich die Version 4 auch ohne die Beschaltung verwenden? Außerdem wüsste ich gerene, wass ich mit CLK machen muss wenn ich den AVR mit einem 8MHZ Quarz beschaltet habe. Nebenbei, stört es wenn ich anstelle von R1 eine LED mit 1K Vorwiderstand verwende? Von was für unentdeckten Fehlern spricht Benedikt im Post vom 22.07.2007 08:02? Und zu guter Letzt, funktioniert die software wenn CTS(PD2) unbeschaltet und RTS(PD3) mit einer LED (von Vcc) beschaltet ist? Der Hintergrund ist der, dass ich mir vor längerer Zeit mal recht erfolglos eine Funkübertragung mit zwei 433MHZ Modulen von Conrad gebaut habe und die Platine jetzt mit möglichst wenig Anpassungen auf die RFM12 Module umrüsten möchte.
Malte __ wrote: > Wie genau sieht die Minimalbeschaltung für die Software aus? > In der Version ..int ist FFIT mit PD3 und in Version 4 mit PB0 > beschaltet. Kann ich die Version 4 auch ohne die Beschaltung verwenden? Ja. Das mit dem Interrupt ist nur bei der int version so. > Außerdem wüsste ich gerene, wass ich mit CLK machen muss wenn ich den > AVR mit einem 8MHZ Quarz beschaltet habe. Offen lassen > Nebenbei, stört es wenn ich anstelle von R1 eine LED mit 1K > Vorwiderstand verwende? Nein, aber leuchten wird die LED nicht, da dies ein Eingang ist. > Von was für unentdeckten Fehlern spricht Benedikt im Post vom 22.07.2007 > 08:02? In der void save_settings(void) Funktion fehlt noch diese Zeile: eeprom_write_byte((void *)1,0xAA); Ohne diese werden bei der SOFTCONFIG Konfiguration die Daten nicht als gespeichert erkannt und jedesmal neu die Standardwerte geladen. > Und zu guter Letzt, funktioniert die software wenn CTS(PD2) unbeschaltet > und RTS(PD3) mit einer LED (von Vcc) beschaltet ist? RTS wird von der Software noch nicht unterstützt. Du kannst die Pins also beide offen lassen. Du darfst dann nur nicht zu schnell die Daten senden, denn wenn die Verbindung schlecht ist, liegt die Datenrate nur bei wenigen kBit/s oder noch weniger. Und wenn der Empfangspuffer dann überläuft, gehen Daten verloren.
Ich have geschrieben: > > Hope RF has licensed their dies and IP to a small number of > > chip manufacturers, and the ones mentioned in this thread > > are indeed 'legal'. und Reinhard Max schrieb: > Also diesem Post nach: > Beitrag "bidirektionale RS232 Funkbrücke mit RFM12" > ist es genau umgekehrt. Integration ist der Originalhersteller der Dies > und verkauft die an HopeRF, die dann die Module daraus bauen. Das ist korrekt. OK, now back to English, as my German writing is very bad :) It is correct- Integrated makes the dies, and sells a chp version of those dies. HopeRF has a license to integrate those dies into modules, the ones we all know. As we are planning on doing European sales and support for them (yes, guys, which includes samples !) we did request a copy of their agreement with Integrated.. they are 'legal' indeed, and not a cloning house (of which there are MANY in that area..) Gruss, Fred
Fred wrote: > As we are planning on doing European sales and support for them (yes, > guys, which includes samples !) Please keep us updated on this, and let us know who 'we' is. ;)
gibt es denn nochmal eine zusammenfassung des aktuellen codes und der schaltungen?
Vielen Dank, die Funkbrücke funktioniert jetzt. :-)
Hallo, ich will die Funkbrücke mit einem mege168 und einem RFM12B-868 aufbauen. Bekomme beim übersetzen aber die Fehlermeldung TIMSK undefined. Da ich von C keine Ahnung habe, bräuchte ich mal einen Tip. Gruss Peter
ok, Datenblätter verglichen, der Mega8 hat TIMSK und der Mega168 TIMSK0 bis TIMSK2. Wenn ich es in TIMSK0, 1 oder 2 ändere, gibt es keine Fehlermeldung. Muss ich einen bestimmten TIMSK nehmen? Da der RFM12B ja nur max 3,8V kann, wollte ich den 168er nehmen, weil der für diesen Bereich ausgelegt ist. Der normale 8er ja nicht. Danke. Gruss Peter
Du musst dir die Bedeutungen der einzelnen Bits im Register ansehen und danach entscheiden. Es gibt von Atmel sicher auch ein Datenblatt wie man von einem ATMEGA8 auf einen ATMEGA168/88 o.ä. migriert, also was geändert werden muss.
Angehängte Dateien:
-
rfm.jpg
390 KB
Hi all, See attached - I added this little board to our PCB run of yesterday. Small carrier board designed to easily "use" the RFM12 modules: - single 5x2-pin connector (2.54mm) for VCC, GND, SPI and I2C - single 10x1-pin connector (2.54) for plugging onto a breadboard (the VDD generated by this PCB is also on the breadboard conn) - DIP switch for the FSK and RESET lines (with pullup) - space for RFM12B DIP and SMD versions, as well as RFM12BP If anyone is interested, let me know ! Cheers, Fred
Hallo zusammen, was muss in der letzten Version .check4.korr. alles geändert werden um die RFM12S-868 zu betreiben? Das was Christian schrieb Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" passt irgendwie nicht mehr, da wesentlich mehr angaben der Frequenz enthalten sind... Gruß Clyde
@ Fred (gast) Your PCB are little bit wrong by designing concepts. The GND-Field on many places are not connected to the gound. On a HF-Designed board u need to scatter or rastersize the complete GND field (if u can't connect it to gnd) or u must connect each field to the gnd. if u can't do the last then u cant place the filled poligon on this section. If u use Eagle-CAD then u can use the "Name" command in the PCB-Designer, click on the poligon and give it the name of your GND (on most .sch its "GND"). Then the rastnest will fill only fields are connected to the GND. If u place not connected fields on the PCB then HF can let the PCB intrude and go over the spi/data-lines to the MCU CPU ... The result are hang or crash the software in the controler or (by powerfull HF) destroy any components where EM-senstiv. Greez
Hallo, kann mir niemand evtl. nen Tip geben, was ich ändern muss und vorrauf zu achten ist, wenn man ein 868 Modul anklemmt? Ich habe die befürchtung, das etwas kaputt gehen kann, wenn die Software falsche oder unvollständige Einstellungen vornimmt... Gruß Clyde
Hallo, ich hätte auch gern mal vom Programmautor einen Hinweis, worauf beim Wechsel von Controller (Mega168 gewünscht) und Frequenz (868MHz) zu achten ist... Vilen Dank! MfG Pit
Ich kann nicht viel dazu sagen, da ich diese Software bisher nur mit den 433MHz Modulen ausprobiert habe. Der Betrieb im 868MHz Bereich ist nämlich nicht so einfach, wenn man es richtig machen möchte (LBT, Einhaltung der Sendezeit usw.). Klar, es funktioniert trotzdem aber ich möchte nicht dafür verantwortlich sein wenn es Ärger deswegen gibt. Anpassen muss man die Umrechnung Frequenz -> Einstellwert, und der Frequenzbereich des RF12 muss auf 868MHz gesetzt werden.
Hi, das ist ja wirklich ein Super-Thread. Wer noch aktuelle (=Überarbeitete) Datenblätter für die Chips sucht, sollte mal hier schauen: https://www.silabs.com/products/wireless/EZRadio/Pages/default.aspx Den ehem. Hersteller "Integration" gibt es wohl nicht mehr bzw. wurde übernommen. Si4021 = IA4221 = RF(M)02 (Transmitter) Si4320 = IA4320 = RF(M)01 (Receiver) Si4420/21 = IA4420 = RF(M)12 (Transceiver) Es gibt dort wohl sogar Software für die Berechnung der Register. Die CDs inkl. Datenblätter und Software gibt es hier: ftp://ftp.integration.hu/ Viel Spass... Markus
Hallo Pit! Habe vorige Woche den Code von Benedikt - die Version aus dem ersten Post - auf m168 mit 20mhz in betrieb genommen, dabei ist nur zu beachten das die spi-frequenz die 2.5mbit nicht überschreitet, das hatte ich erst nicht gemacht und bekam nur ca. 10% der daten durch. Da ich die 868er Module habe, musste ich den code natürlich ein wenig anpassen... schau dir mal im Datenblatt vom RFM12 an mit welchen kommandos die trägerfrequenz vorgegeben wird, ich musste nur diese anweisung an mehreren stellen im code anpassen, ist im prinzip der austausch von einem word welches an das rfm12 geschickt wird. Zum setzen der frequenz ist die formel auch anzupassen, ich habe mir auf die schnelle mal einen passenden wert aufgrund der formeln im datenblatt ausgerechnet und 'hardcoded', die formel im code durch 860-f/0,005 zu ersetzen ist aber auch rasch geschehen. Sonst funktioniert die sache super, vom 1. Stock aus den dachboden (3 stockwerke) oder ins letzte eck vom keller, es kommt zwar zu retransmissions, aber selbst mit einem retry-counter von 2 ging bisher trotzdem alles fehlerfrei durch, bin echt zufrieden mit diesem Code - An dieser Stelle auch mein DANK an Benedikt! Aber aufgrund der Hinweise - wo finde ich infos zum thema 868mhz, soweit ich es bisher verstand sind dort keine dauerträger erwünscht, sonst kann ich mich austoben, oder ist sonst noch was zu beachten? nachdem ich aus wien komme ist natürlich auch die frage ob hier alles 1:! aus .de anwendbar ist? Die sendeleistung würde ich wenn die module demnächst in den mk eingebaut werden hochdrehen soweit von den modulen unterstützt. Danke auch für die Info - bin auch für passende Links dankbar, in diesem endlosthread habe ich diese hoffentlich nicht übersehen! lG, Martin.
Martin S. wrote: > Aber aufgrund der Hinweise - wo finde ich infos zum thema 868mhz, soweit > ich es bisher verstand sind dort keine dauerträger erwünscht, sonst kann > ich mich austoben, oder ist sonst noch was zu beachten? Das Band 868-870 ist in Bereiche unterteilt, für die jeweils die maximale Sendeleistung und Belegungsdauer festgelegt sind: http://de.wikipedia.org/wiki/Short_Range_Devices Noch genauer steht es in den entsprechenden Allgemeinzuteilungsverfügungen der Bundesnetzagentur: http://www.bundesnetzagentur.de/media/archive/6709.pdf http://www.bundesnetzagentur.de/media/archive/4470.pdf > nachdem ich aus wien komme ist natürlich auch die frage ob hier > alles 1:! aus .de anwendbar ist? Für den Bereich 869,3-869,4 schreibt die BNetzA, daß er nur noch in Deutschland genutzt werden darf, daher denke ich, daß der Rest europaweit einheitlich ist. Aber schau besser mal beim ösrerreichischen Pendant zu unserer BNetzA vorbei, da gibt es sicher auch Informationen über die bei Euch gültigen Allgemeinzuteilungen. > Die sendeleistung würde ich wenn die module demnächst in den mk > eingebaut werden hochdrehen soweit von den modulen unterstützt. Dabei solltest Du aber das erlaubte Maximum beachten, das für die Frequenz gilt, die Du nutzt.
Hallo Reinhard, Danke für die Tipps, habe über Google für Österreich noch immer nicht viel gefunden, unsere Regulierungsbehörde hat leider keine so tolle webseite... viele verweise auf richtlinien,... letztendlich habe ich ein eu-dokument gefunden http://www.bmvit.gv.at/telekommunikation/recht/downloads/en2006de771.pdf in welchem per 1.6.2007 diverse richtlinien in länderrecht umzusetzen ist. ev. auch für andere länder interresant, daher poste ich das mal hier! dazu noch eine änderung dieser entscheidung aus 2008, umsetzbar bis 1.10.2008, denke also das wir hier das aktuellste dokument haben: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:151:0049:0054:DE:PDF Sollte somit überall in der eu gültig sein, oder? lG, Martin. ps.: spiele noch immer mit Benedikts Code, nachdem 57600 in eine richtung halbwegs fehlerfrei funktioniert, der durchsatz durch hamming aber schwindet & uni-direktionale kommunikation wenn eine seite ständig sendet kaum geht, bastel ich eine version in der man per #define hamming code deaktivieren kann. in meinem fall gibt es auf anwendungsebene prüfsummen und retransmissions sind egal da die daten zeitkritisch, d.h. später nicht mehr aktuell sind. Wenn Interresse besteht kann ich den code - wenn ich damit mal fertig werde - gern hier posten!
Hallo Zusammen, ich habe jetzt das 433Mhz antelle des 868 Modul laufen. Klappte von Anfang an und lief auch immer wieder mal. Habe keine Dauerbetrieb sondern momentan einfach zu testen. Allerdings hatte ich gestern abend Probleme, keine Verbindung. Soeben habe ich es dann über Soft-Config nochmal konfiguriert. Hat dann auch hinterher funktioniert, allerdings war die Konfig bei Modul 1 ok, aber bei Modul 2 waren erst nur Hyroglyphen und hinterhen immer noch komische Zeichen... Hyroglyphen lassen ja noch auf falsche Baudrate schliessen, aber kann es sein, das die gespeicherten Daten mit der Zeit verloren gehen bzw. verstümmelt werden? Hat jemand ähnliches durch? Gruß Clyde
Ich weiß es gerade nicht wirklich... Aber es war unmittelbar nach dem Einschalten schon, nachdem die Module ca. 1-max 2 Tage ausgeschaltet waren. Auch Resets haben nix gebracht oder Spannungslos schalten... Das ist da etwas merkwürdig gewesen... seit 40 Min läuft es wieder ohne Probleme, nachdem ich neu Soft-Konfiguriert habe...
Clyde H. wrote: > Ich weiß es gerade nicht wirklich... > Aber es war unmittelbar nach dem Einschalten schon, nachdem die Module > ca. 1-max 2 Tage ausgeschaltet waren. > Auch Resets haben nix gebracht oder Spannungslos schalten... Dass der EEPROM seine Daten vergisst, habe ich bei diversen Projekten auch hin und wieder. Deswegen baue ich inzwischen immer eine Checksumme (zb einfach die Config noch mal Bitweise invertiert ablegen, wenn der Speicherplatz kein Problem ist) ein, anhand der die Config überprüft wird und im Fehlerfall auf die Ausgangswerte zurückgestellt wird.
Hi, im ZIP-Paket ist ein Schaltplan abgebildet (rfm_simple). In diesem ist XTAL1 vom Mega16 mit CLK vom RFM12 verbunden. Meine Frage: in meiner Schaltung benutze ich einen externen Quarz. Wie gehe ich dann mit diesem Anschluß am CLK-Pin des RFM12 um? Wie muss ich in meinem fall das RFM12 beschalten? Danke
> Wie gehe ich dann mit diesem Anschluß am CLK-Pin des RFM12 um? Genau das hatte ich auch gefragt, die Antwort gibt es etwas weiter oben: Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"
Ich denke, dass es dann egal ist, welchen Quarz ich am Atmega benutze.
Hier eine minimal aktualisierte Version: Die Takt Umschaltung 1MHz->10MHz führte vereinzelt zu Problemen beim AVR. Als Abhilfe wird die Umschaltung jetzt Stufenweise 1MHz->2MHz->5MHz->10MHz durchgeführt.
Hi, Klasse dass dein Paket noch immer weiter verfeinert wird, Benedikt. Meine Frage: Ich habe an meinem Atmega32 (7,3728MHz extern) eine Servo und einen Drehimpulsgeber angeschlossen. Mit dem Drehimpulsgeber lässt sich die Servo bewegen. Diese Verbindung möchte ich nun über das RFM12 "verlängern". So ungefähr: Impulsgeber -> Atmega32 -> RFM12 ........ RFM12 -> Atmega32 -> Servo In wie weit kann ich die rf12.c / .h nutzen bzw. was müsste ich in der rf12.c / .h anpassen um diese getrennt nutzen zu können? Danke schonmal, Ralf
Dann wäre dieser Version besser: http://www.mikrocontroller.net/attachment/48080/rfm12_just_rxtx.zip Das ist im Prinzip obige Version ohne das ganzen UART Zeug.
Hey Klasse! Aber sind in dieser Version nicht noch einige Bugs drinn? Das File ist ja im ersten Post angehängt und wurde schon 5 Mal ergänzt. Kannst du mir das vielleicht noch sagen? Danke
Guten Morgen, hab gerade nochmal nachgesehen und habe "rfm12_rs232_rxtx_check5" mit "rfm12_just_rxtx" verwechselt. Ich verteile meine Schaltung heute mal auf 2 Boards und hänge die rfm12-Module dazwischen. Als Antenne müsste es für den Anfang ein 16 - 17cm langes Kabel tun. Gruß, Ralf
HILFE Also, irgendwie will keins der beiden Boards. Ablauf: Die LED_POWER geht an, wenn ich dann über die UART (vom PC) was schicke, geht die LED_RETRANS an und ne Sekunde später die LED_ERR. Im PC auf der Receive-Seite kommen dann ein paar Mal "0x01" an. Angepasst habe ich die SPI-Ports und die LED-Ports in der rf12.c auf den Atmega32. Die F_CPU habe ich überall auf 8MHz angepasst. Den RFM12-CLK-PIN habe ich NICHT mit meinem Atmega32 verbunden, da ich diesen normalerweise mit einem externen Quarz betreibe. Aber für den Test habe ich auf internen Clock (8MHz) umgeschaltet. Die UART geht. Habe ich getestet indem ich nach der uart_init() nen String sende. Als Antenne habe ich ein 17cm langes Stück Kabel angelötet. Die SPI ist richtig angeschlossen. Hat einer ne Idee, was ich übersehe?
Ralf R. schrieb: > Also, irgendwie will keins der beiden Boards. > Ablauf: Die LED_POWER geht an, wenn ich dann über die UART (vom PC) was > schicke, geht die LED_RETRANS an und ne Sekunde später die LED_ERR. Das klingt schonmal gut. Das heißt das wohl der Sender und die Software an sich funktionieren. > Im PC auf der Receive-Seite kommen dann ein paar Mal "0x01" an. Der Empfänger scheint also nichts zu empfangen. Sender und Empfänger haben die gleichen Einstellungen was Frequenz, Baudrate usw. angeht?
Ja, haben sie. 2 identische Bords mit der selben Software geflasht. Meine LEDs sind zwar low-aktiv, aber das macht ja nix. Einfach umgedreht anschauen. Habe gerade mal in die Routine zum Senden über die UART ne Debugausgabe reingehängt: Wenn ich "test" vom PC Richtung Board schicke, wird die Senderoutine 4 mal durchlaufen. Für jeden Buchstaben einmal. Meine LEDs (low aktiv): #define LED_TX PORTC_4 // TX LED #define LED_RX PORTC_3 // RX LED #define LED_RETRANS PORTC_2 // Retransmit LED #define LED_ERR PORTC_1 // Error LED #define LED_POWER PORTC_0 // Power LED nach Reset: LED_POWER, LED_RX aus. Rest an. direkt nach senden von einem String vom PC zum Boart über UART: LED_RETRANS, LED_ERR geht aus. LED_RX glimmt nach dem Senden aller Buchstaben von "test": LED_POWER, LED_RX, LED_RETRANS, LED_ERR aus. bei erneutem Senden eines Strings: LED_RX glimmt und geht nach dem Senden wieder aus. Liegt es vielleicht an der Antenne oder so?
Ach ja, eins noch. Ich werde aus der Konfig der Ports in der main.c wenn
ich parallel den Schaltplan anschaue nicht schlau.
int main(void)
{ PORTB=1;
PORTD=31;
DDRC=63;
DDRD=238;
...
Für was sind diese Einstellungen gut?
An der Stelle werden die Pins für die LEDs auf Ausgang gesetzt (und auch für den RFM12, aber dessen Pins werden in der rf12.c automatisch abhängig von den dortigen Einstellungen nochmal gesetzt. Sind die LEDs also wo anders angeschlossen, muss das hier geändert werden. Wenn die Module nebeneinander liegen, dann sollte es sogar ohne Antenne funktionieren.
ich versuche nun seit 2 Tagen meine (schon mal funktionierende) Funkbrücke wieder zum laufen zu bringen. Ich verwende den Code von Benedigt rfm12_rs232_rxtx_check3.zip Da ich 868MHz-Module habe, habe ich die dafür benötigten Einstellungen durchgeführt (die hie im Thema erwähnt wurden). Ausserdem habe ich die Baudrate auf 9600 geändert. Mehr im Code habe ich nicht geändert. Mein Problem ist nun, dass die Module zwar die Daten hin und her schicken, es aber nur Müll ankommt. Retransmitt und Error-LED's leuchten nicht auf, also kein Fehler bei der Übertragung. Die Module liegen direkt nebeneinander. Im Terminal ist die Baudrate auch auf 9600 eingestellt. Im Anhang habe ich meinen Schaltplan, sowie das AVR-Studio-Projekt, den ich verwende (incl. Makefile), eingefügt. Woran kann es liegen? :-( vielleicht an den nicht richtig gesetzten "Security and Configuration Bits" des Controllers?
Ich vermute dass die Baudrate nicht passt. Sind die Fusebits auf externen Oszillator gesetzt? Stell mal auch im AVR Studio die Frequenz auf 10MHz.
Die Fusebits sind folgendermaßen gesetzt (Screenshot aus PonyProg) http://img135.imageshack.us/img135/8608/bits.jpg Bei AVR habe ich in den Projekt-Einstellungen die Frequenz auf 10MHz gesetzt http://img145.imageshack.us/img145/7972/avr.jpg hat nichts gebracht
Die Fusebits stehen auf Quarz <8MHz wenn ich das richtig interpretiere, also nicht ganz das richtige. Es sollte aber trotzdem funktionieren. Hast du einen DIP Schalter angeschlossen? In der Software ist dieser nämlich aktiviert. Falls du das nicht hast, kommentier mal #define USE_DIPSWITCH aus.
tatsächlich! ich habe angenommen, dass so lange wie hinter #define USE_DIPSWITCH keine 1 steht, wird es nicht ausgeführt :-/ Nun geht es! Ich danke Dir, Benedikt! Wenn ich die DIP-Schalter einsetzen möchte, dann ist es doch richtig, dass am PortC die PIN's 0-2 für die Baudrate, 3-4 für HF-Kanal sind und 5 unbenutzt? In der rfm12_rs232_rxtx_check3.zip ist es wohl nicht richtig beschrieben
Ja, so ist es. Nimm am besten die neueste Version von hier: http://www.mikrocontroller.net/attachment/50533/rfm12_rs232_rxtx_check5.zip Da sind die ganzen Fehler der alten Versionen behoben.
Ich habe mal die Unterstützung für die 868MHz Version eingebaut, aber nicht getestet, da ich keine 868MHz Module betriebsbereit aufgebaut habe. Für die Einhaltung der Sendebeschränkungen im 868MHz Bereich sowie die Verwendung auf nicht erlaubten Frequenzen übernehme ich keine Verantwortung! Die eingestellten Kanälen sind meinem Verständnis der Listen der BNetzA nach für eine derartige Verwendung zugelassen, aber jeder der auf diesen Frequenzen sendet sollte das selbst nochmal kontrollieren.
habe das Programm für 868MHz v5 ausprobiert. Folgende Änderungen habe ich für den Betrieb mit DIP-Schaltern durchgeführt: - in leds.h die define's für DIP-Schalter festgelegt und für Soft-Config auskommentiert - in rf12.c "#define USE_868" aktiviert - in main.c "#define USE_DIPSWITCH", sowie "#define USE_868" aktiviert und "#define USE_SOFTCONFIG" deaktiviert funktioniert alles prima, nur bin ich mit den Einstellungen des DIP-Schalters etwas irritiert. Bei mir ist nun Schalter1 (PinC0) ohne Bedeutung, Schalter2-3 (PinC1+PinC2) HF Kanal und Schalter4-6(Pin3-Pin5) die Baudrate. Verdrahtet nach dem oben eingefügten Schaltplan.
Andreas V. schrieb: > Bei mir ist nun Schalter1 (PinC0) ohne Bedeutung, Schalter2-3 > (PinC1+PinC2) HF Kanal und Schalter4-6(Pin3-Pin5) die Baudrate. Kann nicht sein, denn in der Software werden ganz klar PinC0-2 für die Baudrate verwendet.
blödsinn was ich da oben geschrieben habe... es funktioniert alles super!
Hallo zusammen, ich verwende ebenfalls das RFM12 Modul mit einem leicht geänderten Code von Benedikt (Basis ist die IRQ-Version, jedoch mit den Änderungen von rfm12_rs232_rxtx_check5 integriert). Erweitert habe ich die Funktionalität durch eine eigenen Adressimplementierung. Somit sind nun auch Multipoint-Verbindungen möglich. Broadcast ebenfalls. Sollte Interesse bestehen, so kann ich hier ein Diff zu Benedikts Basiscode posten. Leider treten beim Versenden von großen Mengen der gleichen Chars Fehler auf. Teilweise werden Zeichen verschluckt. Mir ist das erst bei meinem aktuellen Projekt aufgefallen, da ich eine "Trennzeile" aus '-' nicht immer empfange. Daraufhin habe ich eine Testfunktion eingebaut, die mir 256x jeweils eine Zeile "0123456789\r\n" ausgibt und anschließend das gleiche mit "----------\n\r" macht. Die Ziffern kommen prima an, bei den Strichen kommt er aber nach ca 100 Zeilen aus dem Tritt. Erst dachte ich es liegt an der neuen Implementierung, jedoch tritt der Fehler auch mit allen älteren (gepollten) Versionen auf. Hat jemand bei seinem RFM12 ähliche Beobachtungen gemacht? Ich werden gleich mal versuchen einen Workaround (zusätzliche Stuffbytes bei gleichen Chars) versuchen.
Lorenz .. schrieb: > Leider treten beim Versenden von großen Mengen der gleichen Chars Fehler > auf. Teilweise werden Zeichen verschluckt. Sendest du eventuell zu schnell, so dass der Sendepuffer überläuft? > Daraufhin habe ich eine Testfunktion eingebaut, die mir 256x jeweils > eine Zeile "0123456789\r\n" ausgibt und anschließend das gleiche mit > "----------\n\r" macht. Die Ziffern kommen prima an, bei den Strichen > kommt er aber nach ca 100 Zeilen aus dem Tritt. Dass die Striche Probleme machen ist merkwürdig: Diese haben eigentlich nichts spezielles an sich, haben viele 1en und 0en, also ausreichend Flanken, so dass es eigentlich keine Probleme geben dürfte. Den RF12 und auch die Software interessieren die Daten nicht, daher dürfte der Inhalt eigentlich keine Probleme machen.
Hallo Benedikt, Testweise habe ich mal eine Pause von der Länge der "TX-Sammelzeit" zwischen die Ausgabe von jeweils 50 gleichen Chars gesetzt. Und siehe da, es funktioniert. Dies verwundert mich aber etwas. Wenn ich den Code richtig interpretiere, dann wird im Timerinterrupt alle z.B. 50ms ein Paket abgeschickt, egal ob es nur aus einem Char besteht. In der Funktion rf12_putc wird jedoch nach dem Einfügen eines neuen Chars in die Sendequeue die aktuelle Bufferposition geprüft und bei einem (drohenden) Überlauf in der Abzweigung
1 | if (tx_cnt>=MAX_BUF) |
das Paket aus bisher gesammelten Daten incl. des aktuellen Datums SOFORT gesendet. Somit sollte für das nächste Zeichen Platz sein. Da durch das Absenden des Pakets auch ein ACK angefordert wird und vor dem Eintreffen desselben kein weiterer Char (durch
1 | while(flags&WAITFORACK); |
) ankommen kann, bin ich zu dem (eventuellen) Trugschluss gekommen, dass ein Pufferüberlauf nicht möglich ist. Die Funktion rf12_busy() prüft auf diese Weise ja auch die Belegung des Moduls. Bitte kläre mich doch auf, falls ich da falsch liege. Momentan beschäftige ich mich noch mit der Umsetzung von CSMA/CD, was ich bei meiner Multipoint-Lösung für dringend notwendig halte. Hat mir jemand einen Tipp wie ich eine halbwegs zufällige Zahl auf mehreren uCs erzeugen kann? Seriennummer usw scheidet bei den Atmels ja aus. Und da ich auch resets über Broadcast plane, scheidet eine einfache rand() aus. Danke Lorenz
Lorenz .. schrieb: > Dies verwundert mich aber etwas. Wenn ich den Code richtig > interpretiere, dann wird im Timerinterrupt alle z.B. 50ms ein Paket > abgeschickt, egal ob es nur aus einem Char besteht. Nicht im Interrupt sondern in der main Schleife werden die Daten verschickt. Davon abgesehen passts. > In der Funktion rf12_putc wird jedoch nach dem Einfügen eines neuen > Chars in die Sendequeue die aktuelle Bufferposition geprüft und bei > einem (drohenden) Überlauf in der Abzweigung
1 | if (tx_cnt>=MAX_BUF) |
> das Paket aus bisher gesammelten Daten incl. des aktuellen Datums SOFORT > gesendet. Genau. Durch diese 2 Kriterien wird einerseits die Paketgröße maximiert um die Datenrate zu erhöhen, andererseits auch die Latenzzeit klein gehalten wenn nur wenige Daten übertragen werden. > Somit sollte für das nächste Zeichen Platz sein. Da durch das > Absenden des Pakets auch ein ACK angefordert wird und vor dem Eintreffen > desselben kein weiterer Char (durch
1 | while(flags&WAITFORACK); |
) > ankommen kann, bin ich zu dem (eventuellen) Trugschluss gekommen, dass > ein Pufferüberlauf nicht möglich ist. Ein Pufferüberlauf von diesem Puffer ist nicht möglich. Solange aber gesendet, bzw. auf eine Bestätigung gewartet wird, verbleiben alle weiteren empfangenen UART Daten in einem 512 Byte großen FIFO. Das kann aber überlaufen.
@Benedikt: Danke für deine schnelle Aufklärung. Wie gesagt, ich verwende die IRQ-Version, die sendet durch Triggerung im IRQ oder manuell, aber das ist ja irrelevant. Komisch hingegen ist der Umstand, dass meine Funknodes keinen UART verwenden, sondern nur intern (gleicher uC) auf Funksteuerbefehle reagieren (z.B. Tempsensor x auslesen). Daher kann ein Bufferüberlauf durch einen UART nicht entstehen. Und die rf12_putc-Funktion ja wartet, falls der relevante Sendebuffer voll (bzw ein ACK ausstehend) ist. Diese putc-Funktion verwende ich zur Ausgabe von Variablen und Strings aus dem Flash. Weiter würde mich interessieren, ob du mir Erfahrungswerte zu der Definition von ANSWER_TIMEOUT geben kannst. Wie lange dauert z.B. die Übertragung eines einzelnen Chars (ohne den für ein Paket erzeugten Overhead) grob? Ich kann das leider nicht richtig zur RF-BAUDRATE (und dann natürlich auch der Paketgröße) in Relation setzen.
Lorenz .. schrieb: > Und die > rf12_putc-Funktion ja wartet, falls der relevante Sendebuffer voll (bzw > ein ACK ausstehend) ist. Diese putc-Funktion verwende ich zur Ausgabe > von Variablen und Strings aus dem Flash. Was machen die LEDs? Ist die retransmit oder error LED aktiv? Es gibt einen ID Zähler der mit jedem Paket übertragen wird. Wenn ein Paket empfangen wurde, wird dessen ID als neuer Wert übernommen. Alle nachfolgenden Pakete mit gleicher ID werden verworfen. Ich denke eher nicht dass hier noch ein Fehler in der Software ist, aber ich suche nochmal ob ich etwas finde, dass diesen Fehler erklären könnte. > Weiter würde mich interessieren, ob du mir Erfahrungswerte zu der > Definition von ANSWER_TIMEOUT geben kannst. Ich hatte das mal ausprobiert, ist allerdings eine Weile her. Ich glaube 5ms hat zu Problemen geführt bei 20000 Baud. > Wie lange dauert z.B. die > Übertragung eines einzelnen Chars (ohne den für ein Paket erzeugten > Overhead) grob? (8*/20000)s, also 0,4ms. Da durch die Präambel, das Syncword, CRC usw. mindestens 9 Bytes gesendet werden, dauert alleine die Übertragung der Empfangsbestätigung 3,6ms. Dazu kommt noch der Jitter des Timers der als Zeitbasis der Software dient von 1 Periode, also 2ms, was dazu führt dass die eingestellte Zeit um bis zu 2ms kürzer sein kann. So ab 6-7ms aufwärts sollten daher ausreichen. Die 10ms sind ein eher großzügiger Wert.
Benedikt K. schrieb: > Was machen die LEDs? Ist die retransmit oder error LED aktiv? > Es gibt einen ID Zähler der mit jedem Paket übertragen wird. Wenn ein > Paket empfangen wurde, wird dessen ID als neuer Wert übernommen. Alle > nachfolgenden Pakete mit gleicher ID werden verworfen. > Ich denke eher nicht dass hier noch ein Fehler in der Software ist, aber > ich suche nochmal ob ich etwas finde, dass diesen Fehler erklären > könnte. Retransmit oder Error-Led sind beide aus. Naja, mit einer Pause in der Größenordnung des TX-Sammellimits tut es aber korrekt. Erklären kann ich mir den Fehler auch nicht, da deine PutC ja blockierend ist und das durch Warten vermeiden sollte. An der ID liegt es auch nicht, die habe ich mir testweise ausgeben lassen bzw den entsprechenden Codeteil auskommentiert. Wozu nutzt du diese genau? Das war mir beim Studium deines Codes auch nicht klar. Für erneut übertragene Pakete? Danke für deine Arbeit, die ist echt spitze!
Lorenz .. schrieb: > An der ID liegt es auch nicht, die habe ich mir testweise ausgeben > lassen bzw den entsprechenden Codeteil auskommentiert. Wozu nutzt du > diese genau? Das war mir beim Studium deines Codes auch nicht klar. Für > erneut übertragene Pakete? Ja. Das Problem war folgendes: Der Sender sendet ein Paket, der Empfänger empfängt dieses. Er sendet ein ok zurück, was dem Sender sagt dass die Daten angekommen sind. Jetzt können 2 Fehler auftreten: Der Empfänger bekommt das Paket nicht, oder der Sender bekommt das ok nicht. In beiden Fällen wird der Sender das Paket nochmal senden da die Empfangsbestätigung ausbleibt. Der Empfänger muss daher erkennen können ob es sich um ein neues Paket handelt, dazu dient die ID. Diese wird nämlich nur bei neuen Paketen erhöht.
Hallo Benedikt, mal eine Frage zu folgendem Code aus Deiner letzten Version:
1 | void rf12_setbandwidth(unsigned char bandwidth, unsigned char gain, unsigned char drssi) |
2 | {
|
3 | rf12_trans(0x9500|((bandwidth&7)<<5)|((gain&3)<<3)|(drssi&7)); |
4 | }
|
müßte nicht 0x94XX statt 0x95XX übertragen werden? In Deinem alten Code überträgst du auch diesen (0x94) Oppcode. Leider habe ich in den Datenblättern keinen Oppcode 0x95 gefunden. Deshalb erschließt sich mir diese Veränderung auch nicht. Kannst du mir einen Tipp geben?
mikes schrieb: > müßte nicht 0x94XX statt 0x95XX übertragen werden? > In Deinem alten Code überträgst du auch diesen (0x94) Oppcode. Leider > habe ich in den Datenblättern keinen Oppcode 0x95 gefunden. Das ist das "5. Receiver Control Command" aus dem Datenblatt. Der Unterschied von 4->5 ist, dass VDI von fast auf medium gesetzt wurde. Dies macht die Sache etwas unempfindlicher gegenüber Störungen.
Hi Lorenz! Kann man mir deinem Code bei z.B. 3 Schaltungen festlegen, dass man von z.B. Schaltung 1 etwas an Schaltung 2 schickt? Wenn ja, könnt ich mir den Code mal ansehn? lg, Steevie
Hallo Benedikt, >Autor: Benedikt K. (benedikt) (Moderator) >Datum: 14.05.2009 13:12 >Dateianhang: rfm12_rs232_rxtx_check5.zip (215 KB, 229 Downloads) Deinen Code ausgepackt, ins AVR Studio geworfen, kompiliert, auf ein mega8/rfm12 868MHz setup geflasht, läuft auf anhieb! Klasse arbeit, danke schön!
Wie sieht es eigentlich mit der Portierung auf andere Controller aus? Weil der Mega8 ist mir ein bisschen zu gross (auch SMD, bzw. nicht lötbar). Es gibt ja auch z.B. den Tiny84, der ist kleiner, hat weniger I/O-Pins und etwa gleich viel Flash. Kann man da einfach den C-Code darauf brennen, oder erfodert das Pin-änderungen, etc... mfg, cyberlink
cyberlink schrieb: > Wie sieht es eigentlich mit der Portierung auf andere Controller aus? Die Software sollte sich ohne viel Aufwand auf jeden anderen Atmega AVR portieren lassen. Eventuell sind ein paar Registernamen und die Position des SPI Interface anzupassen. > Weil der Mega8 ist mir ein bisschen zu gross (auch SMD, bzw. nicht > lötbar). Es gibt ja auch z.B. den Tiny84, der ist kleiner, hat weniger > I/O-Pins und etwa gleich viel Flash. Dafür weniger RAM und keinen UART. > Kann man da einfach den C-Code darauf brennen, oder erfodert das > Pin-änderungen, etc... Das erfordert erstmal einen Software UART. Ist also prinzipiell machbar, aber erfordert doch einige Anpassungen am Code.
Hallo Benedikt, erstmal Danke für die Mühe die du dir da gemacht hast! Ich habe dein Programm auf 2 Boards aufgespielt, die ich nach deinen Schaltplanvorschlägen gebaut habe. Am einen ATMega8 kommt das Wort "TEST" mit 2400 Baud rein(an RX), alle Baudraten sind auf 2400 gestellt. Es leuchten bei beiden Schaltungen die 3 LEDS, die Error LED ist aus. Leider kommt aus der Empfänger Schaltung nichts raus :/ Hast du einen Tip wo ich nachmessen/schauen könnte wo der Hund begraben liegt? Grüße Martin
Ja die leuchten alle 3... bei beiden Boards und auch wenn ich kein Eingangssignal anlege. Die LEDs gehen von den PORTS die du bei der check5-Version angibst nach GND. In die Menüs beider controller komme ich, da habe ich auch Baudraten und Kanal eingestellt.
Oh ich sehe gerade, in der LED.h steht dass die Belegung an PORTD nur gilt, wenn man DIP Schalter verwendet. Ich habe zwar welche dran, verwende aber SoftConfig... D.h. ich müsste erstmal die LED Belegung umprogrammieren, um korrekte Statusmeldungen zu bekommen. Werde das mal machen und mich dann wieder melden.
Prüf mal die leds.h, ob die der Anschlussbelegung entspricht. Je nach Konfiguration (DIP Schalter oder Config Menü) ist die Belegung nämlich unterschiedlich.
Angehängte Dateien:
-
rfm.png
11 KB
Ok also das hat keinen Unterschied gebracht, leuchten immer noch alle 3. Hab mal den Schaltplan angehängt, DIP Schalter sind zwar auf dem Board, aber alle nicht angeschaltet.
Hast du die Software auf den DIP Modus gestellt, oder verwendest du den Softconfig oder festen Modus? Wenn du den Softconfig oder den festen Modus verwendet hast, dann sind die LEDs normalerweise an PortC angeschlossen. In dem Fall musst du die die Belegung der LEDs in der leds.h und auch die DDRx und PORTx Register in der main.c entsprechend verändern, dass die entsprechenden Pins auf Ausgang sind, und die LEDs beim Einschalten alle aus sind.
Ok, habe das so geändert:
1 | int main(void) |
2 | {
|
3 | #ifdef USE_SOFTCONFIG
|
4 | PORTD=0; |
5 | DDRD=230; |
6 | DDRC=255; |
7 | #else
|
8 | PORTD=15; |
9 | PORTC=255; |
10 | DDRD=242; |
11 | #endif
|
und leds.h
1 | /*
|
2 | // für DIP Schalter
|
3 | #define LED_RX PORTD_7
|
4 | #define LED_TX PORTD_6
|
5 | #define LED_RETRANS PORTD_5
|
6 | #define LED_ERR PORTD_4
|
7 | */
|
8 | |
9 | // für Soft Config
|
10 | #define LED_RX PORTD_7
|
11 | #define LED_TX PORTD_6
|
12 | #define LED_RETRANS PORTD_5
|
13 | #define LED_ERR PORTD_4
|
Es ändert sich leider nichts, die LEDS brenne immer noch alle 3.
So, hab ein bischen mit dem code gespielt und den Eindruck, er bleibt in configmode() irgendwo hängen. Wenn ich danach eine Kontroll-LED anamchen will, geschieht nichts. Ich muss das Menü ja nicht jedesmal im Terminal bedienen oder? Hab das einmal eingestellt und denke das reicht auch.
Ok genug für heute Nacht, so ist der momentane verzweifelte Stand: Der Code ist absolut original bis auf das hier:
1 | int main(void) |
2 | {
|
3 | #ifdef USE_SOFTCONFIG
|
4 | PORTD=255; |
5 | LED_TX = 0; |
6 | LED_RX = 0; |
7 | LED_RETRANS = 0; |
8 | LED_ERR = 0; |
9 | DDRD=230; |
10 | DDRC=255; |
11 | #else
|
12 | PORTD=15; |
13 | PORTC=255; |
14 | DDRD=242; |
15 | #endif
|
16 | |
17 | sei(); |
18 | rf12_init(); // ein paar Register setzen (z.B. CLK auf 10MHz) |
1 | /*
|
2 | // für DIP Schalter
|
3 | #define LED_RX PORTD_7
|
4 | #define LED_TX PORTD_6
|
5 | #define LED_RETRANS PORTD_5
|
6 | #define LED_ERR PORTD_4
|
7 | */
|
8 | |
9 | // für Soft Config
|
10 | #define LED_RX PORTD_7
|
11 | #define LED_TX PORTD_6
|
12 | #define LED_RETRANS PORTD_5
|
13 | #define LED_ERR PORTD_4
|
Es leuchtet nun keine LED, auch nicht wenn ich ein serielles signal anschließe :/ Im Softconfig Menü wurde 2400Baud und Kanal 2 eingestellt. Wenn du noch einen Tip hättest wäre ich dir wirklcih dankbar, entschuldige bitte die Post-Flut hier. Grüße Martin
Und bevor ich nun ins Bett gehe, verlasse ich das Softconfig Menü mit s, sind LED RX und RETRANS an und TX blinkt, wenn das serielle Signal anliegt. Stimmt das soweit? Das hieße ja, ich muss jedesmal erst ins Softconfig Menü und dann rasugehen bevor ich die Schleife configmode() verlassen kann??
Da er anscheinend jedesmal in den Softconfig Modus geht, heißt dass das du den Softconfig Anschluss auf Low geklemmt hast. Lasse den mal offen, dann sollte er diesen überspringen.
Jetzt funktioniert die Übertragung in eine Richtung - In die andere nicht. Wenn ich die 2 µc in den Schaltungen vertausche, geht es ebenfalls nicht - sehr seltsam wie ich meine. Hsat du noch eine Idee? Zur Not würde ich beide Platinen nochmal neu layouten und ätzen, aber ich sehe so vom Leiterbahnenbild zwischen meinen beiden aktuellen auch keinen Unterschied :/ Wenn ich deine Software ohne Änderungen übernehmen will, muss ich die LEDS an PORTC hängen richtig? Grüße Martin
Angehängte Dateien:
-
rfm.png
14 KB
So und hier der neue Schaltplan, passt das dann so, so dass ich nur noch die Software aufspiele und es läuft? Grüße Martin
Die LEDs an PortC0-3 und am besten noch PortD2 über den MAX232 an Pin7 des RS232 Anschluss führen (RTS). Dann sollte es funktionieren.
Ok habe das mit den LEDs geändert, werde nun bei Reichelt bestellen und mich dann wieder melden, bis dahin vielen Dank Benedikt, das ist echt super wie du hier weiterhilfst! Grüße Martin
#define LED_RX PORTD_7 ?!? welchen compiler hast du? bei infineon gab es einen schönen sbit befehl, bei WINAVR muss man das mit Einzelbits und nem kompl. define machen.
Timo P schrieb: > bei WINAVR muss man das > mit Einzelbits und nem kompl. define machen. Richtig, das Makro dazu befindet sich in der portbits.h. Mich hat es nämlich genervt bei WinAVR immer PORTD|=(1<<7); oder etwas ähnliches zu schreiben. PORTD_7=1; ist erstens deutlich besser lesbar und wird auch von den meisten anderen Compilern besser verstanden als PORTD|=(1<<7). Viele setzen das nämlich so um, wie es da steht: Einlesen vom Port, verodern, zurückschreiben. Die andere Lösung wird dagegen sowohl von WinAVR als auch von allen anderen Compilern die ich verwende direkt in einen Bit Setzen Befehl übersetzt.
@Funker läuft deine Platine nun und mit welcher Softwareversion? Würdest du das Layout veröffentlichen?
Kleines Definitionsproblem RS232 --> Recomendet Standard (empfohlener Standard) beschreibt in erster Linie die Physik. hier wird kein wireless serial interface beschrieben. RS232 ist immer Kabelgebunden. Was Du realisiert hast (Hut ab) ist eine Funkstrecke, die serielle Daten überträgt. Oder habe ich das falsch verstanden, handelt es sich um einen RS232 - Funk -Konverter ? Gruß https://www.xing.com/profile/Thomas_Lamparter4
Hallo, kurze Frage zu einer passenden Antenne: Funkmodule gehen soweit gut, allerdings nur auf sehr kurze Distanz, Meter oder so. Meine Antennen sind Koax-Kabel, insgesamt 34cm lang, Isolierung aber bis zur Hälfte abgemacht, d.h.17cm -> lambda/4. Der Innenleiter ist an das Funkmodul angeschlossen, die Isolierung mit GND verbunden, passt das so? Baudrate ist übrigens glaube 20kBaud. Warum ist die Reichweite hier so gering?? Viele Grüße Bart
Angehängte Dateien:
-
SFI-TEST.png
41 KB -
SFI-SMD.png
16 KB
Hallo, habe für dieses tolle Projekt zwei kompakte Eagle-Layouts entworfen. "SFI-Test" ist eins mit DIP-Mega8 Fassung + RFM12 2mm Steckverbindern. Die LEDs sind hier solche mit eingebautem Vorwiderstand. Das in etwa Funkmodul-kleine "SFI-SMD" schließlich mit SMD-Mega8 auf der Top- sowie dem (gespiegelten) RFM12 auf der Bottomseite. Gruss Jan
Bitteschön. Möchte einige davon fertigen lassen, bei Interesse evt. Sammelbestellung möglich.
Hallo, Ist es eigentlich möglich, anstatt des RFM12 auch das RFM12BP anzuschliessen? Weil ich habe 4 Stück von denen Rumliegen und suche einen verwendungszweck dafür (ausser einstauben...) mfg, cyberlink
Prinzipiell ja. Allerdings muss die Software erweitert werden, damit diese die TXEN und RXEN Signale ausgibt. Weiterhin müssen natürlich noch die Vorschriften beachtet werden, da man mit diesen Modulen nicht in allen Bereichen einfach so senden darf.
Funktechnisch ist das kein Problem, ich habe einen komplett Elektromagnetisch abgeschirmten Raum zur Verfügung. Und für die wenigen Sekunden Testbetrieb kommt noch kein Funkmesswagen... Zu TXEN und RXEN: Soweit ich das verstanden habe, müssen diese Pins je nach Datenrichtung (Senden/Empfangen) auf high gezogen werden. Wie das Schaltungstechnisch geht weiss ich noch nicht genau (vielleicht Pullup gegen GND und AVR-Pin auf Input stellen?). Aber die Möglichkeit der Anzeige der Senderichtung ist doch glaube ich schon in der Software eingebaut, müsste man also nur noch über zwei Ports ausgeben, oder? mfg, cyberlink
cyberlink schrieb: > Zu TXEN und RXEN: Soweit ich das verstanden habe, müssen diese Pins je > nach Datenrichtung (Senden/Empfangen) auf high gezogen werden. Ja. > Wie das > Schaltungstechnisch geht weiss ich noch nicht genau (vielleicht Pullup > gegen GND und AVR-Pin auf Input stellen?). Einfach direkt die 3,3V Signale vom AVR auf TXEN/RXEN. > Aber die Möglichkeit der > Anzeige der Senderichtung ist doch glaube ich schon in der Software > eingebaut, müsste man also nur noch über zwei Ports ausgeben, oder? Ja. In der Software gibt es Kommentare wie RX ON, TX ON, RX OFF usw. An diesen Stellen müssen die Pins entsprechend geschaltet werden.
Danke Benedikt! Mit diesen Informationen ist das ja supereinfach zu realisieren (Dank deiner Software). Nochmal zu den 3,3V Signalen: Wie sähe dass dann in C aus, den den Ausgang PB1 auf eben VCC zu bringen und umgekehrt auf GND? Bin in C noch nicht ganz so erfahren wie in Bascom... mfg, cyberlink
Ich verstehe nicht ganz warum der Schaltplan DIP Version und Softconfig so verschieden sind was RTS/CTS betrifft. Kann man das deaktivieren um nur mit RX und TX zu arbeiten? Was ist mit der FFIT Leitung?
Daniel schrieb: > Ich verstehe nicht ganz warum der Schaltplan DIP Version und Softconfig > so verschieden sind was RTS/CTS betrifft. Es gibt keinen Unterschied, RTS ist vorgesehen aber nicht implementiert. > Kann man das deaktivieren um > nur mit RX und TX zu arbeiten? CTS wird immer ausgegeben, man kann das Signal ignorieren, muss dann aber damit rechnen, dass Daten verloren gehen wenn man zu schnell sendet. > Was ist mit der FFIT Leitung? Die ist vorgesehen wird aber auch nicht verwendet.
Vielen Dank Benedikt. Kann man auch einen anderen Pin für CTS konfigurieren oder muss es genau der Pin sein?
Man kann jeden Pin verwenden, man muss diesen nur auf Ausgang setzen und in der uart.h den Pin einstellen.
Hallo, reicht es eigentlich aus in Bascom die Funktion
1 | SPIOUT Kommando(1) , 1 |
bzw.
1 | SPIIN Kommando(1) , 1 |
zu verwenden, um mit dem RFM12 zu kommunizieren? Bastelbär hatte ja in einem anderen Thread einen Code gepostet, der mit einer Software SPI funktioniert. Eine kleiner ablauf der kommunikation wäre nicht schlecht, wenn den jemand beschreiben würde. Gruß Tobi
Hi, ich habe mir jetzt den ganzen Thread durchgelesen (puhh, Gehirnschmelze) und wollte mal nachfragen ob ichs richtig verstanden hab: Kann ich jetzt einfach ne Rs232 Verbindung mit den Boards ersetzen, indem ich statt dem Max232 dieses Board anschließe? Muss ich da nix mehr in den Code extra konfigurieren? Ich programmiere in Bascom (duck und weg) und kann leider dadurch das Programm nicht nachvollziehen. Danke schon mal im Vorraus. Mfg, Florian
Hallo!! Sehr interessante Beiträge. Mittlerweile gibt es ja viele sinnvolle Anmerkungen. Gibt es nun eine aktuelle SW-Version (ggf. auch Hardware), die alle Neuerungen vereint? Wenn ja, wäre eine erneute Veröffentlichung super!
Angenommen, man nimmt sich die neuste Version zur Brust. Welche Maßnahmen sind zur Inbetriebnahme notwendig? Ich habe folgendes gemacht: Softconfig und USE_686 defined. Kann ich nun Daten über die UART einspeisen und versenden? (meine gewünschte Baudrate, sowie der Kanal sind ebenfalls eingestellt(im Code).
Hallo zusammen... Ich möchte mich für diesen super Beitrag zum RFM12 Modul damit bedanken, dass ich den gesamten Text als *.pdf Dokument aufgearbeitet habe. Die im Text vorhandenen Links funktionieren übrigens, so dass man die gewünschten zip Files aus dem Dokument herunterladen kann. Vielleicht habe ich eine "Druckversion" übersehen, dann sei mir verziehen. Ich hoffe, mit diesem Dokument nicht gegen jrgend eine Regel verstossen zu haben. Sonst bitte File wieder entfernen. Danke... Gruss Andy
Hallo Leute, das ist ja mal ein Super Beitrag. Danke an Benedikt für seine tolle Idee und vorallen, dass er soviel Zeit und wissen in dieses Projekt eingesteckt hat und es uns jetzt schenkt. Gibt es eigentlich ein Boardlayout für die Platine zum Download für Eagle oder Target? Habe schon viele diese Lösung erfolgreich nachbauen können. Wäre für ein kurzes Feedback sehr dankbar. Vielen Dank im Voraus. Gruß Eddie
Hallo, ich hätte ma eine kleine Frage zu diese tollen Projekt. Ich benutze die Check4-Version und diese funktioniert auch soweit wunderbar bei mir solange ich beide Atmega8 gleichzeitig einschalte. Sobald ich den Empfänger später einschalte empfängt er garnichts mehr und der Sender sendet solange bis die maximale Wiederholungsanzahl erreicht ist. Wo liegt mein Fehler?
Hallo! Ich habe den Code dieses Threads verwendet, um das Pollin-Funk-AVR-Evaluationsboard (v1.2) in Betrieb zu nehmen. Hat nach wenigen Anpassungen sehr gut funktioniert. Hier meine Änderungen für diejenigen, die auch dieses Board nehmen: verwendete Hardware: * Pollin Funk-Avr-Evulationboard V1.20 * RFM12 mit 17cm-Draht-Antenne * Atmega32 mit 16 MHz-Quarz Änderungen in den Dateien rfm12_rs232_rxtx_check5.zip: main.c ====== CPU-Frequenz - #define F_CPU 10000000UL + #define F_CPU 16000000UL CONFIG-Schalter (Taster gegen 5V statt Jumper gegen GND - bei Reset oder Start drücken und halten) - #define CONFIG PIND_4 + #define CONFIG PINB_1 Abfrage CONFIG-Schalter in main() - if (!CONFIG) + if (CONFIG) rf12.c ====== CPU-Frequenz - #define F_CPU 10000000UL + #define F_CPU 16000000UL SPI-Pins am Atmega - #define SDI 3 - #define SCK 5 - #define CS 2 - #define SDO 4 + #define SDI 5 + #define SCK 7 + #define CS 4 + #define SDO 6 SPI-Geschwindigkeit clk/16 statt clk/4 in rf12_init(void) - SPCR=(1<<SPE)|(1<<MSTR); + SPCR=(1<<SPE)|(1<<MSTR)|(1<<SPR0); // clk/16 leds.h ====== - #define LED_TX PORTC_2 - #define LED_RX PORTC_3 - #define LED_RETRANS PORTC_1 - #define LED_ERR PORTC_0 + #define LED_TX PORTD_5 + #define LED_RX PORTD_5 + #define LED_RETRANS PORTD_6 + #define LED_ERR PORTD_6 Anfang bekam ich nur Müll ausgegeben bis mir auffiel, dass die SPI-Speed auf clk/4 steht. Das ist mit 10Mhz für AVR oberste Geschwindigkeit für RFM12. clk/16 ist für 16 MHz OK (dürfte auch für 10 Mhz nicht zu langsam sein). Das Board hat nur zwei LEDs (ich habe sie 1x gelb und 1x rot bestückt). Daher musste ich TX+RX und ERR+RETRANS zusammenlegen. Einige #defines sind mehrfach in main.c und rf12.c definiert. Das verwirrt und provoziert Fehler. Ich denke, diese sollte man in die (ohnehin vorhandene) config.h auslagern. Die Hardware-nahen #defines wären da auch gut aufgehoben! Grüße Stefan
Besteht eigentlich die Möglichkeit mit der Version in diesem Thread mehrere Funkmodule in einem Netz zu betreiben? Ich lese zur Zeit die Spannung und den Alarmstatus eines Raumelders aus und sende diesen an ein anderes Modul zurück, das den Status auf einem LCD ausgibt. Ich würde jetzt gerne mehrere Rauchmelder abfragen. Das Projekt von Florian Scherp kann dies zwar, benutzt aber einen ATMega16/32. Ich habe jetzt aber schon einige Boards mit einem ATMega88 geätzt. Was für Möglichkeiten gäbe es noch?
Ich hab mal ne Grundsätzliche Frage zu deinem Funkmodul. Kann ich auch einfach nur TXD und RXD ohne Flusskontrolle oder ähnlichen anschließen? Mich interessiert das, da ich dann nämlich gerne zwei Mikrokontoller über dein Funkmodul labbern lassen möchte. Gruß Marius
Hallo zusammen, erstma vielen dank für den Code, der hier zur Verfügung steht. Hätt da aber eine Frage. Habe zwei Funk AVR Boards von Pollin, und wollte den Code zur Datenübertragung nehmen. Habe da einige Änderungen vorgenommen, also die Ports angepasst usw. Leider kriege ich keine Verbindung zwischen den beiden aufgebaut. Hatte vllt. einer den Code für an die oben erwähnte hardware angepasst? Danke und Gruß Dennis
Dennis schrieb: > Hallo zusammen, > > erstma vielen dank für den Code, der hier zur Verfügung steht. > Hätt da aber eine Frage. Habe zwei Funk AVR Boards von Pollin, und > wollte den Code zur Datenübertragung nehmen. Habe da einige Änderungen > vorgenommen, also die Ports angepasst usw. Leider kriege ich keine > Verbindung zwischen den beiden aufgebaut. Hatte vllt. einer den Code für > an die oben erwähnte hardware angepasst? > > Danke und Gruß > > Dennis benutze einen atmega8, Änderungen soweit, externe quelle: F_CPU 3686400UL moduleänderungen: #define SDI 3 // #define SCK 5 #define CS 2 #define SDO 4 LED Änderungen #define LED_TX PORTD_6 //Transmit #define LED_RX PORTD_5 //Resive SPI-Geschwindigkeit clk/16 statt clk/4 in rf12_init(void) SPCR=(1<<SPE)|(1<<MSTR)|(1<<SPR0); // clk/16 Abfrage CONFIG-Schalter in main() #define CONFIG PINB_1 if (CONFIG) möchte mit 868MHz senden, hab also USE_868 aktiviert Übertragung funktioniert trotzdem nicht. Gruß
Hallo zusammen, mein Board läuft jetzt mehr oder weniger. Eine weitere Frage, kennt jemand von euch das Prog RFM12_Scanner. Kann man damit die rssi Werte auf den Monitor ausgeben? Gruß
Hallo, super Lib, funktioniert bei mir den den RFM12 Modulen einwandfrei :) Nun stelle ich mir die Frage, ob man auch ohne großen Aufwand die RFM12BP-868 (500mW) Module verwenden kann? Gruß Dirk
erstmal wollte ich mich auch an Benedikt bedanken für seinen starken sourcecode. nun nachdem ich die ersten teste mit dem rfm12 erfolgreich sind habe ich festgestellt dass manche daten die ich empfange nicht rechtzeitig aus dem fifo ausgelesen werden..gibts es die möglichkeit die Grösse des FIFO buffer zu beinflussen oder ist die schon beim programm von benedikt auf die maximale Grösse eingestellt? vielen dank
Angehängte Dateien:
-
rfm12_softconfig.png
69 KB
Hallo, ich versuche seit Wochen mein RFM-12B Modul zum laufen zu bekommen. Allerdings komme ich keinen Schritt vorwärts. Das Funkmodul antwortet anscheinend nicht auf Anfragen des Mikrocontrollers. Ich habe mit einem Oszilloskop ein Siganl am MOSI erkannt. Allerdings keine am MISO. Ich habe den internen Takt des Atmega mit 8 MHz verwendet. Um vom 2mm auf das 2,54mm Rastermaß zu kommen habe ich etwa 5cm lange Leitungen an das Funkmodul angelötet um es auf meinem Breadboard zu verwenden. Ich kann das Problem nicht genau lokalisieren. Ich verwende die Software : rfm12_rs232_rxtx_check5 Atmega8L-8PU 3,3V RFM12B DIP Rev.4.0 868MHz 3,3V 868MHz aktiviert im Sourcecode 1.Frage: Sollte ich den Takt des Moduls oder den des uC verwenden? Ich kann in meien Fusbits keine 10MHz einstellen. 2.Frage: Sind die Leitungen die ich an das Modul gelötet habe störend? 3.Frage: Müssen Veränderungen am Sourcecode oder der Schaltung vorgenommen werden wenn 3,3V Bauteile verwendet werden? 4.Frage: Fällt jemanden noch ein Fehler auf? ;) Also ich weiß nicht mehr weiter. Wenn ihr keine Lösungen oder Vorschläge habt gebe ich auf.
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" > 1.Frage: Sollte ich den Takt des Moduls oder den des uC verwenden? Ich > kann in meien Fusbits keine 10MHz einstellen. XTal_1 geht auf dem Bild zm Modul: Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" >2.Frage: Sind die Leitungen die ich an das Modul gelötet habe störend? Hauptsache sie sind nicht zu lang. > 3.Frage: Müssen Veränderungen am Sourcecode oder der Schaltung > vorgenommen werden wenn 3,3V Bauteile verwendet werden? Sollte alles okay sein, das Modul läuft ab 2.2V Hast du auch einen UART-RS232 Pegelwandler (Max232 läuft oft nur mit 5V) dran der mit 3.3V läuft? > 4.Frage: Fällt jemanden noch ein Fehler auf? ;) Du könntest mal ain kleines Testprogramm drauf laufen lassen oder deine Fusebits auslesen oder einen Screenshoot der Einstellungen machen. Die "Brown Out detection" hast du auf 2.6V gestellt?
Kann jemand einen Wiki Artikel schreiben, in dem alles erläutert wird? Es ist u.A. sehr umständlich alle >400 Posts zu lesen. MfG. Chris
Hallo, funktioniert das auch mit: http://www.pollin.de/shop/dt/Mzg4OTgxOTk-/Bausaetze_Module/Module/Funkmodul_RFM12BP_868_Sende_Empfangsmodul.html Davon habe ich noch 2 Daheim :-D Würde diese gerne verwenden, da ich auch eine etwas höhere Reichweite benötige! LG
Guten Tag Ich bin ein Neuling und habe nicht so viel Erfahrung mit µC und Funkmodulen. An dieser Stelle möchte ich mich bei Benedikt bedanken für seinen robusten Code. Ein zweiter Dank geht an Stefan für seinen Beitrag vom 16.05.2010 in dem er den Code auf die Pollin-Funk-AVR-Evaluationsboard angepasst hat. Mit diesen Anpassungen ist mir gelungen relativ rasch zwei solche Boards, die mit RFM12 Modulen bestückt sind zum Einsatz zu bringen und die bidirektionale RS232 Funkbrücke aufzubauen. Ich finde es einfach fabelhaft, dass ich mit der bidirektionale RS232 Funkbrücke für meine eigenen, zukünftigen Projekte ein verlässliches Testsystem habe. Gruß an Alle Borislav
Hallo, erst mal ein großes Dankeschön an Benedikt für den Code! Ich möchte in den Code eine Funktion Einbauen, die es mir ermöglicht, nach Eingabe einer bestimmten Zeichenkombination in den Config-Modus zu kommen. Als Zeichenkette wäre für mich irgendetwas denkbar, was man sonst nicht sendet, z.B. eine Kombination aus Sonderzeichen oder ähnliches. Mir ist nun leider nicht ganz klar, wo (und wie) ich diese Funktion einbauen muss. Ich müsste ja die letzten 3 Zeichen abfragen und dann mit der gewünschten Zeichenkette vergleichen. Schonmal Danke im Voraus und Gruß André
Nabend, ich habe mich die Tage recht intensiv mit den RFM12 Modulen beschäftigt und bin dabei auf Benedikts Bibliotheken gestoßen. Was ich dabei nicht ganz verstehe ist die Funktion zum Einstellen der Baudrate. Das CS Bit wird nur unter Baudwerten 5400 gesetzt. Rein rechnerisch komme ich aber auf ~2700 (2693 oder so). Macht in der Praxis nichts aus, ich bin nur drauf gestoßen und möchte mal nachhaken. Ich hoffe ich habe's bisher nur nicht überlesen (so lang wie der Thread schon ist). Grüße, Nils
EDIT: Meine Version der Baudratenfunktion:
1 | void rfmSetBaud( uint16_t baud ) { |
2 | |
3 | uint16_t tmp; |
4 | |
5 | //minimal baudrate with cs=0 is about 2700
|
6 | if( baud < 2700 ) { |
7 | tmp = (344828/(baud*8)-1); //cs=1 BR=344828/(R+1)*(1xcs*7) |
8 | } else { |
9 | tmp = ((344828/baud)-1); //cs=0 BR=344828/(R+1) |
10 | }
|
11 | |
12 | rfmWrtCmd(0xC600|tmp); |
13 | |
14 | }
|
Angehängte Dateien:
-
rfm_simple.gif
13 KB
Hallo Ich wollte gerde die Funkbrücke zum testen aufbauen und dabei ist mir aufgefallen das die Pinbeschriftungen von dem Avr garnicht passen Geschrieben steht Atmega 8 allerdings Reset an pin 29 und auch sonst passen die Nummern garnicht
Sven Möller schrieb: > Ich wollte gerde die Funkbrücke zum testen aufbauen und dabei ist mir > aufgefallen das die Pinbeschriftungen von dem Avr garnicht passen > Geschrieben steht Atmega 8 allerdings Reset an pin 29 und auch sonst > passen die Nummern garnicht Das ist nicht das DIP Gehäuse, sondern das 44 polige TQFP... Bez. Baudrate: Benedikts Formel ist zwar lt. Datenblatt korekt, aber durch das Integer-Runden / Wegschneiden kommen teilweise sehr unglücklicher Werte raus, bei 19200 wird z.B. real auf ~20284 Baud eingestellt. Mit 345600 statt 344828 kommt man meiner Meinung nach besser hin...
Ich habe gestern meinen ersten Versuch gestartet und bin wie zu erwarten gescheitert ... Beide module schalten auf 10mhz, Fuse auf Extern gestellt. Aber beide avr's senden mir über rs232 nur Datenmüll und das in einer tour. Auch wenn einer der beiden aus ist und auch sonst vermutlich nix auf 433 senden dürfte. Rs232 am pc eingestellt auf 19200 auch im config modus nur datenmüll version war die rfm12_rs232_rxtx_check5 hat jemand einen hinweis?
Hallo, hat für mich als reinem Anwender des Codes "rfm12_rs232_rxtx_check5.zip" jemand eine Erklärung für folgendes Phänomen, welches ich in meinem kleinen Netzwerk mit mehreren der Funkmodule habe: Wird eines davon -Nr.1- neu eingeschaltet werden sämtliche davon gesendete Zeichen bei einem weiteren -Nr.2- (ständig eingeschalteten) Modul nicht empfangen- solange nicht von einem dritten -Nr.3- (ebenfalls ständig eingeschalteten) Modul etwas gesendet (und stets auch ordnungsgemäß empfangen) wird. Modul Nr.1 soll aus Energiespargründen nur ab und zu eingeschaltet werden wenn es Daten zum Senden gibt. Nun sehe ich mich außerstande das zu realisieren da ich dabei natürlich nicht auf auf sonstigen Funkverkehr (Modul Nr.3) angewiesen sein möchte. Hoffe das Problem ist einigermaßen klargeworden und jemand kennt eine Lösung ... Gruß Tobi
Hallo, ich verwende den Code aus "rfm12_rs232_rxtx_check5.zip" mit komplett anderer main() und habe das Problem, das ausschließlich beim Empfang die folgende Aufrufkette bei ca. jedem zweiten Telegramm blockiert: rf12_rxdata() -> rf12_rxbyte() -> 1.Aufruf von rf12_ready() konkret in dieser Zeile: while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready Ich will das als Basis für einfache Funk-Spielereien nehmen. Es ist also kein UART etc. beteiligt. Es wird ein Telegramm gesendet wenn eine Taste gedrückt wird. Der Code in main() ist deswegen auch hinreichend simpel und es sind keine Interrupts aktiv.
1 | #define CHANNEL 2 // Sende/Empfangskanal (0-3) (nur gültig wenn kein DIP Schalter verwendet wird) |
2 | #define RF_BAUDRATE 20000 // Baudrate des RFM12 (nur gültig wenn kein DIP Schalter verwendet wird) |
3 | #define MAX_BUF 128 // Paket Größe in Bytes (maximal 250, siehe auch rf12.c) |
4 | : |
5 | : |
6 | rf12_init(); // ein paar Register setzen (z.B. CLK auf 10MHz) |
7 | rf12_config(RF_BAUDRATE, CHANNEL, 0, QUIET); // Baudrate, Kanal (0-3), Leistung (0=max, 7=min), Umgebungsbedingungen (QUIET, NORMAL, NOISY) |
8 | rf12_rxmode(); |
9 | |
10 | |
11 | /* endless main loop */ |
12 | while (1) {
|
13 | /* check for received data */ |
14 | if (rf12_data()) { // Daten im RF12 RX Puffer ?
|
15 | rx_cnt=rf12_rxdata(rxbuf, &status, &rx_id); // komplettes Paket empfangen |
16 | if (rx_cnt<=MAX_BUF) { // Daten gültig (d.h. kein CRC Fehler) ?
|
17 | snprintf(line, sizeof(line), "%03d Received: %d", (int) loop, (int)status); |
18 | WriteString(0, 4, line); |
19 | } else {
|
20 | snprintf(line, sizeof(line), "%03d RX error!", (int)loop); |
21 | WriteString(0, 4, line); |
22 | } |
23 | } |
24 | /* middle key triggers sending */ |
25 | if (!KEY_MIDDLE) {
|
26 | rf12_stoprx(); // auf TX umschalten |
27 | WriteString(0, 7, "Sending ... "); |
28 | rf12_txdata(txbuf, 30, value, 0); |
29 | delay_ms(700); // "debouncing ;-)" |
30 | rf12_rxmode(); // wieder auf RX umschalten |
31 | value++; |
32 | } |
33 | : |
34 | : |
35 | } |
Hardware ist das bekannte OLED Blutzuckermeßgerät: http://www.mikrocontroller.net/articles/Compact_Plus_Blutzuckermessger%C3%A4t-Hardware Es ist also ein 3,3V-System. Das Modul ist RFM12S in der 868 MHz-Version. "USE_868" ist gesetzt und grundsätzlich funktioniert das System auch, da ca. jede zweite Botschaft (durch Tastendruck gesendet) fehlerfrei durchkommt - die Pins sind also korrekt angeschlossen etc. NFFS und NSEL sind je mit einen 12k-Pullup versehen. Das Problem äußert sich so, dass rf12_ready() blockiert. Wenn eine weitere Botschaft vom Sender geschickt wird, dann läuft es weiter - natürlich für dieses Telegram mit fehlerhafter CRC aber die main()-Loop wird wieder ausgeführt. Ich habe zwei gleiche Systeme aufgebaut und die können sich gegenseitig durch das Senden von Botschaften blockieren und auch wieder "entblockieren". Hat jemand eine Idee, woran das liegen könnte? Gruß, Bernd
Noch ein Hinweis: Das Modul ist über ca. 4cm lange Käbelchen verbunden und die Spannung am Modul mit 10µF Tantal / 100 nF keramisch abgeblockt. Sollte also eigentlich alles passen. Ich habe die SPI-Frequenz mal halbiert, hat aber nichts gebracht, da gleiches Verhalten. Hat niemand eine eine Idee? Gruß, Bernd
Hallo! Dieser Thread ist mittlerweile richtig lang.... Ich habe eine Frage: Habt ihr Empfehlungen zu folgenden Einstellungen (868MHz)? rf12_setbandwidth(? , ?, ?); Ziel sollte eine gr. Reichweite sein mit einer Fehlerrate, die noch in Kauf zu nehmen ist. (ich setzte mir ein flag.RX_err wenn der CRC-Check in die Hose geht.) Einstellung derzeit: rf12_setbandwidth(0,3,0); die Reichweite ist nicht zufriedenstellend. Aus dem Gebäude raus, 30m zur Garage. Kein Empfang. Danke für eure Hilfe/Empfehlungen!
Wäre es nicht besser gewesen einen neuen Thread zu erstellen? Es gibt bestimmt genug Leute, die wie ich auch manchmal erst mal oben anfangen und ich nach einer Stunde wundern wie lange der Thread noch geht ;) Zum Thema: würde mich auch interessieren. Hab auch vor ein Paar Tagen im offizielen RFM12-Artikel einen Abschnitt gesehen, in dem stand, wie man möglichst hohe Reichweite bekommt, aber noch nicht rum probiert. http://www.mikrocontroller.net/articles/RFM12#Einstellungen_f.C3.BCr_maximale_Reichweite
Guten Morgen zusammen, ich habe ein Problem und hoffe auf eure Hilfe. Ich habe die Version Check5 auf einem Mega8 und 868Mhz fehlerfrei compiliert(led.h und use868 entsprechend bearbeitet usw.) aber bekomme nur eine Unidirektionale Verbindung obwohl auf beiden der gleiche Code läuft. Ich kann nur von 1 auf 2 Senden aber nicht von 2 auf 1. Die RX-LED blinkt auch nur bei 1 und bei beiden geht die Error-LED an. Die Retrans und TX LEDs bleiben bei beiden aus. Wo kann ich noch nach dem Fehler suchen? Sender sind sowohl TeraTerm auf dem PC und ein Mega168 mit Temperaturwerten. Bei direkter Kabelverbindung klappt alles und emnach scheint von der Seite alles ok zu sein. Habe gestern auch schon das Funkmodul was"scheinbar" nicht sendet ausgetauscht, da ich mehrere habe aber ohne Erfolg. Hat jemand evtl. einen Tip? Gruß Clyde
Hallo zusammen, nach dem Aufbau eines dritten Moduls klappt die Verbindung in beide Richtungen. Weiss zwar noch nicht, was ich versemmelt habe aber werde es später mal suchen. Nun habe ich aber ein anderes Problem... Ich habe keine ausreichene Reichweite, ich komme nicht mal 10-15m durch die Wohnung. Antennen sind Drahtstücke von ca. 8cm(868Mhz-Modul) und eine selbst gewickelte Spule aus einem der wenigen noch Funktionierenden Links. Habe auch mal von QUIET über NORMAL auf NOISY aber es brachte nichts. Als Leistungsabgabe habe ich den Originalcode übernommen, weil ich es so verstehe, das mit maximaler Leistung gefunkt wird. Wer weiß Rat?
Huhu, guckt hier noch jemand?!?! Mittlerweile habe ich eine Aurel-Antenne für 868Mhz, aber vom PC-Zimmer bis ins Wohnzimmer(ca. 15m ums Eck aber offene Türen, Wände Massiv) klappt es immer noch nicht... Habe jetzt auch mal nen anderen Kanal gewählt, aber ohne Erfolg... Mit der Baudrate stehe ich noch auf Kriegsfuß, auf 19200 klappt alles in Sichtweite. bei anderer Baudrate verstehen sie sich nicht mehr, trotz gleicher DIP Stellung, TeraTerm zeigt nur wirre zeichen obwohl ich die Baudrate angepasst habe(2400,4800,9600 ausprobiert). 19200 klappt wie gesagt... Wo könnte der Fehler/das Problem liegen? Gruß Clyde
hallo, ich versuche seit längerem meine beiden Funkmodule RFM12BP-868 mit je einem mega8 zum laufen zu bringen. Nach einigen Fehlschlägen versuche ich jetzt möglichst nahe an Benedikts Code zu bleiben. Ich benutze Softconfig das funktioniert auch, wenn ich den Jumper stecke komme ich in das config-menü. Beim Daten senden (ohne Jumper) blinkt auch die TX-Led, nach einigen versuchen leuchtet die Retrans-Led und später die Error-Led. Beim Empfänger tut sich in dieser Zeit gar nichts. Die Umschaltung von RXEN und TXEN funktioniert auch. Ich weiß nicht mehr weiter, vielleicht sind auch die module hinüber, als sie mal kurz mit 5V liefen. Hat jemand ein kleines Programm für die RFM12BP-868 version um die Funktion zu testen? Grüße
Hallo, ich versuche zwei RFM12 Module mit dem Code von Benedikt zum laufen zu bekommen(check5) - das funktioniert allerdings nur wenn ich beide Module an der selben Spannungsversorgung betreibe - jemand ne Idee woran das liegt? Danke
Moinsen, da ich eine interne UART Funkbrücke brauchte die nicht an den Hardware UART geht habe ich mal diese Funkbrücke als Library gekapselt. Der Aufruf erfolgt genauso wie die UART Lib von Peter Fleury. Im Anhang eine Echo Funkbrücke, ein Modul sendet was es vom UART bekommt und das andere Funkt dies zurück.
Hallo Benedikt, wenn Du hier noch mitliest möchte ich Dich bitten das Prg. hier nochmal für einen Neuling zuverlinken und ein paar Tips zum RFM12 bezüglich Fehler einzustellen. Schon mal danke für Deine Arbeit
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen. Frage an die Moderation? Ich verstehe das nicht, habe weitere Fragen zum Projekt und keine Antwort! Hallo Benedikt, klasse Teil habe es nachgebaut und es tut was es soll. Hast du noch eine Idee wie man das so erweitern kann das DTR und RTS und CTS mitübertragen werden für eine drahtlose FTDI(RS232) Verbindung zum Arduino mini oder clones zum drahtlos programmieren?
Joachim B. schrieb: > Hallo Benedikt, klasse Teil habe es nachgebaut und es tut was es soll. > Hast du noch eine Idee ... Das kann ich bestätigen und habs auch dutzendefach als kleines Funknetzwerk fürs Smart Home im Einsatz! Leider ist der "Support" wohl endgültig ausgelaufen, zum Trost hier im Anhang nochmal eine vereinfachte kleine LP zum Drauflöten eines 433 MHz RFM12 + passende Hex für den Mega8 und einer kurzen Anleitung zum Programmieren mit einem AVRISP-Programmer. Die entsprechende temporär anzulötende 6-pol. Programmierbuchse muß man sich noch dazu basteln (siehe Schaltplan).
Da ich vor Jahren Benedikts Code für eine Funkbrücke zwischen zwei
ATmega8 verwendet habe und auf einem aktuellen Board ebenfalls ein RFM12
bestückt hatte, war es naheliegend das Projekt von damals als
funktionsfähiges Gegenstück zu verwenden.
Zu diesen Zweck habe ich Benedikts Code etwas erweitert und dafür
gesorgt dass er mit einem aktuellen gcc übersetzbar (zumindest für eine
mega8) ist . (Interrupt Namen...)
Features:
-Timeout und Anzahl der Retries lassen sich per Software ändern und
werden im EEprom gespeichert.
-Timeout fürs erneute Senden ist nun variabel (Pseudozufall) um ein
wiederholtes gleichzeitiges Senden von beiden Teilnehmern zu vermeiden.
-Zu Testzwecken kann auf ein Senden der Bestätigung verzichtet werden
und CRC Fehler können angezeigt werden.
Und das Protokoll war glaube ich auch nirgends dokumentiert:
TX POS RX POS
0...4 ------: Sync data: 0xAA + 0xAA + 0xAA + 0x2D + 0xD4
5 0 : Status byte: bit 0 set: received ok
6 1 : Number of data bytes to send (id not counted!)
7...N 2...M : Data bytes: Only if number of bytes is > 0.
If at least one data byte, first byte(7) is an id.
Receiver accepts package when ID is different to the
previous one.
Transmitter increases ID if the reception has been
acknowledged or the the acknowledge is not received
within some timeout.
N+1 M+1 : CRC of bytes 5...N/0...M
N+2 ------: 0 - not received
Speciality in protocol: If one byte is 0x0 or 0xFF, the next byte will
be completely ignored (stuff byte).
The default values will result in a re-sent after 10ms if no ACT has
been received.
Sample reception:
00: Status
AA: Stuff byte because previous byte is 0
01: Number of data bytes to send = 1
05: The 5th packet to send
77: The Data - ascii w
2F: CRC (excluding stuff byte and excluding CRC itself)
E2: Garbage
Vielleicht interessiert es ja jemanden - die RFM12 scheinen ja weiter
aktuell zu sein.
Da ich per PM danach gefragt wurde, hier ein fertiges Binary aus dem Quellcode des vorherigen Posts Hex für: AtMega8 mit 8MHz Quarz. Der Uart läuft standardmäßig mit 9600 Baud. Um in das Konfigurationsmenü zu kommen, muss beim Power Up PinD.2 auf Low gezogen sein.
Gibt es den Benedikt Kullmann eigentlich noch? Seit zig Jahren (ca 2008 glaube ich) nichts mehr von ihm gesehen hier.... hat aber noch MOD Status.
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.