Important announcement: there is an English version of this forum on
Datum:
Angehängte Dateien:Dieses Programm steuert ein RFM12 Funkmodul an, und sendet/empängt einen Datenblock einstellbarer Länge. Es ist keine Fehlerkorrektur oder ähnliches vorhanden. Die gesamte Hardwareansteuerung wird von der Software in der RF12.c erledigt, ebenso das Ein/Ausschalten von Sender und Empfänger. Man muss also nur das Modul initialisieren, die ganzen Parameter einstellen und kann direkt senden oder empfangen. Der Takt am CLK Pin ist auf 10MHz eingestellt, damit man damit z.B. den AVR damit versorgen kann. Um den Schaltungsaufwand klein zu halten, benutze ich nicht den Interrupt Pin sondern Polle das Interrupt Bit im Status Register. Dadurch kommt man mit nur 4 Pins aus (SPI + Chipselect). Da alles ohne speziellen Hardwarefunktionen läuft, sollte die Software auf jedem AVR (mit SRAM) lauffähig sein. Der FSK/DATA/nFFS Pin muss über einen Pullup (z.B. 1-10k) an VDD gelegt werden, damit alles richtig funktioniert. Alle anderen, in der Software nicht aufgelisteten IO Pins des Moduls, werden auf Ausgang geschaltet und brauchen daher nicht angeschlossen zu werden. Die meisten der Einstellungen habe ich irgendwo in die Mitte gesetzt. Für eine optimale Datenrate und Reichweite muss man mit Sicherheit noch ein paar Details anpassen.
Datum:
Heul, schade nicht in Bascom. Könnte es ein C-Versteher den Code in Bascom übersetzen, oder wenigstens ein Flußdiagramm schreiben. Hätte vielleicht auch ein ASM-Freak was davon. Bitte bitte
Datum:
Hallo, meine Module sind leider noch nicht da :-/ Ich habe mir gerade mal Dein Programm angesehen und frage mich gerade warum Du bei "void rf12_init(void)" :
for (unsigned char i=0; i<10; i++) _delay_ms(10); |
statt z.B.:
_delay_ms(100);
|
genommen hast ? Denke mal Du hast einfach solange probiert, bis die passende Delay-Zeit erreicht war ? Ich habe einige hahnebüchene Fehler in den Code-Beispielen bei Pollin und Hope entdeckt :-? Woher hast Du Deine Infos ? Aus den Hope-Datenblättern, die sind ja auch ziemlich neben der Reihe :-? Ich wollte mit einem RFM01 und RFM02 eine kleine Funkfernsteuerung bauen. Jetzt Frage ich mich, ob Dein Code auch auf einem Tiny13 läuft oder zu groß wird ? In Assembler bin ich nämlich nicht so fit :-P Danke für Deinen Code ;-)
Datum:
Der Grund wiso delay(100ms) nicht funktioniert: Delay ist eine Schleife mit 16bit Zähler. Diese kann je nach CPU Takt nicht länger als einige 10ms werden. Bei 20MHz sind daher nur 13,1ms möglich. Falls die Software nicht richtig laufen sollte: Eventuell muss die Delay Zeit vergrößert werden, denn 100ms braucht das Modul nach dem Einschalten bis es Befehle ausführen kann. Die Datenblätter von den Modulen und die Beispielcodes sind nahezu kompletter Mist. Programmiert habe ich das ganze nach den Datenblättern der einzelnen ICs, die weitaus besser und vor allem fehlerfreier sind: http://www.hoperf.com/pdf/RF01.pdf http://www.hoperf.com/pdf/RF02.pdf http://www.hoperf.com/pdf/RF12.pdf Das RFM12 Programm hat nicht ganz 800Bytes (RFM12 Routinen + main mit Initialisierung auf einem tiny2313). Der Code ist nicht auf Codegröße optimiert, sondern so dass es erstmal funktioniert. Da kann man mit Sicherheit noch einiges verbessern. Die RFM01 und RFM02 Routinen sind etwas kleiner, da bei diesen ja nur Senden oder Empfangen benötigt wird.
Datum:
Danke für die Erklärung und die Datenblätter ;-) Soweit ich das jetzt verstanden habe, müßte ich den RF02-Sender mit zwei Steuerleitungen SCK und MISO betreiben können, da es nur einen Sender gibt kann ich doch nSel direkt auf GND legen, sowie FSK mit Pullup gegen Vcc. Oder übersehe ich da was ? Meine Idee ist im Tiny13 den aktuellen Zustand des zu steuernden Geräts zu speichern und kontinuierlich abzusenden. Ich denke diese Lösung ist am sichersten ;-) Oder gibt's da bessere Varianten ?
Datum:
Bei dem RF02 Sender ist das etwas komplizierter: Im Gegensatz zum RF12 besitzt dieser kein Sende FIFO. Man muss die Bits also im Takt der Baudrate entweder an den FSK oder an den SDI Pin legen (ist per Befehl umschaltbar). Den FSK Pin braucht man also nicht unbedingt, aber der SDO/IRQ Pin ist notwendig, denn an diesem gibt der RF02 den Takt der Baudrate an. Bei jeder fallenden Flanke von diesem wird das Bit an FSK oder SDI eingelesen und gesendet. Momementan polle ich die Leitung noch, später möchte ich das aber per Interrupt oder per USI/SPI im Slave mode machen, denn der IRQ Pin ist nur für 1,6us high. Wenn da ein Interrupt dazwischen kommt, gehen Bits verloren. nSEL kann man nicht auf GND legen, denn damit wird u.a. die Übertragung beendet. Ich habe gerade eine Testplatine mit einem RF02 aufgebaut, im Laufe des Tages werde ich also die Software dafür fertig testen können und diese dann hier rein stellen.
Datum:
Angehängte Dateien:Hier nun dasselbe für den RF02 Sender. Funktioniert ähnlich, ist aber etwas einfacher (da nur Senden), und kleiner (rund 650Bytes inkl main). Ein Nachteil hat das ganze aber: Während die Senderoutine läuft, darf kein Interrupt auftreten, also Interrupts während dem Senden abschalten. Eine bessere Lösung wäre, die Senderoutine selbst teilweise in einen Interrupt zu packen (USI, SPI, INT), aber das würde dann nicht mit allen AVRs funktionieren, daher erst mal die einfache Lösung.
Datum:
Angehängte Dateien:Und hier die Software für den Empfänger RF01.
Datum:
Na, da tut sich auch bei Pollin was. Die C-Programme com Sender/Empfänger sind jetzt vom 16.4.07 8:45.
Datum:
Oder auch nicht: Den einzigen Unterschied den ich sehe ist, dass das Wort "Pinbelegung" hinzukam.
Datum:
verkauf ihnen doch deine Verion xD
Datum:
Hallo Benedikt, sag mal wo kommt bei dir die utils/delay.h her? Ist das aus einer avr clib? Gruss Sven
Datum:
Sorry für die dumme Frage aber was genau hat jetzt rfm01 und rfm02 mit dem rfm12 Modul von Pollin zu tun?
Datum:
@ Thomas Kropf: Alle drei Module gibt es bei Pollin ;-) RFM01 & RFM02 für 4,95 Teuronen RFM12 für 7,95 Teuronen Auf dem RFM01 und RFM12 sind Chips mit FIFO verbaut und (Danke Benedikt) der Sender RFM02 hat leider keinen :-/ Aber alle Chips haben identische Kontrollparameter ;-) Hoffe das meine Bestellung bald mal ankommt, zum Basteln und Testen ;-) Bin schon ganz kribbelig mal zu probieren ob meine Ideen auf 100m Sicht funzen :-P
Datum:
Aaah, danke! Ich bin noch stark am Überlegen. Vor allem wieviele Stück (wenn dann nur rfm12) ich mir zulegen soll. Ich kann leider schwer einschätzen wie "gut" die Dinger wirklich sind. Pollin wird wohl auch nicht ewig diese Module verkaufen. Deswegen würde ich mir gleich einen kleinen Vorrat zulegen wollen. Wenn ich irgendwann mal eine von diesem MCA-25 Kameras wo billig ergattern würde dann wär die Kombination von Funkübertragung und Kamera ein Traum (ich weiß es würde lange dauern aber das wäre egal) :)
Datum:
@ Benedikt das mit der Library hat sich grade aufgeklärt, meine war etwas veraltet. Gruss Sven
Datum:
Angehängte Dateien:Hi, da ich die Teile auch bestellt habe, habe ich mir schon mal den Code von Benedikt auf BASCOM angepasst. Ich weiss allerdings nicht ob er so funktioniert, jedenfalls kompiliert er ohne Fehler. Damit der/die BASCOM-Jünger auch was mit den Funkmodulen machen können poste ich ihn mal. Aber ohne Gewähr, nur als Anregung zu verstehen Viel Spass damit Fossie
Datum:
Hi, vielen Dank an Benedikt für die Bibliotheken! Hier noch ein kleiner Optimierungsvorschlag für die Funktion rf12_trans(): Während das auszugebende Wort am "High-Ende" rausgeschoben wird, kann vom "Low-Ende" her der Rückgabewert in die gleiche Variable geschoben werden. Dadurch wird die Variable werti eingespart, es sind nur halb so viele Schiebeoperationen nötig und der Code wird ein bißchen kleiner. cu Reinhard
Datum:
@Bastelbär Sauber programmiert Respekt werde es nächste Woche testen @alle Muss der AVR zwingend mit 10MHZ takten ?
Datum:
@Bastelbär Respekt auch von mir, wie kommt der AVR denn zum 10 Mhz-Takt? Hat er hier einen eigenen Quarz? Bzw. wie wird das verdrahtet? Vielen herzlichen Dank für den Code !!!
Datum:
Das Modul gibt die 10MHz an CLK aus. Am AVr speist man sie dann an XTAL1 ein, lässt XTAL2 unbelegt und setzt die Fusebits auf externen Takt.
Datum:
Hallo Benedikt, hier nochmal in einem anderen Thread die passende Frage. Bin gerade dabei mal einen Schaltplan zu machen. Ich lese von dem Pull-Up an dem FSK/DATA/nFFS Pin. Der Atmel-Port lässt sich doch so programmieren, das ein interner Pull-Up eingeschaltet wird. Das weisst Du aber sicherlich. Warum hast Du dennoch einen externen Pull-Up empfohlen? Gruss Michael
Datum:
Wiso einen Pin verschwenden, wenn ein Pullup reicht ?
Datum:
Hallo Benedikt, uups, habe ich da was falsch verstanden? Benutzt Du ausschliesslich SDI/SDO/SCLK? Und der FSK/DATA/nFFS Pin ist garnicht mit Deinem Controller verbunden? Gruss Michael
Datum:
Ja, so in etwa. nSEL braucht man aber noch, also das komplette SPI Interface: Daten, Takt, Chipselect. Alle anderen Leitungen wie Interrupt oder nFFS sind optional, wenn man alles auf maximale Geschwindigkeit auslegt, oder es eben mit einem Interrupt betreiben möchte.
Datum:
Hallo Benedikt, ah, mein Fehler. Ja, das mit der Geschwindigkeit war so mein Hintergedanke. Danke für die Infos. Gruss Michael
Datum:
@Bastelbär @Alle
Die Bascom Datei von Bastelbär enthält meiner Meinung nach einen Fehler?
Sub Rf12_setfreq(byval Freq As Single)
Freq = Freq - 430.00
Temp = Freq / 0.0025
If Temp < 96 Then
Temp = 96
Elseif Temp > 3903 Then
Temp = 3903
End If
Temp = Temp + &HA000 !!!! Diese Zeile fehlt oder irre ich mich ???
Temp = Rf12_trans(temp)
End Sub
Kann es leider noch nicht Testen
Datum:
Angehängte Dateien:@Humix
Hast natürlich recht. Die Zeile fehlt. Wird Zeit das meine Module
endlich kommen damit ich das testen kann.
Korrigierte Verison anbei.
mfg.
Joachim
Datum:
Hi Ich hab mir irgendwan bei einer früher AVR GCC version mal einen hass auf das programm anprogrammiert und meide es seitdem. Hat irgendwer eine Idee wieviel Aufwand es sein wird das auf Codevision zu portieren? Tobi
Datum:
Eigentlich kaum Aufwand, da es kaum hardwarenahe Funktionen gibt, die irgendwas spezielles vom Compiler erwarten. Es müssen eigentlich nur die #defines passen, dann sollte das Programm laufen.
Datum:
Hat jemand schon Erfahrungen mit dem Antennenanschluß gemacht. Wie sollte diese Antenne optimal beschaffen sein? gute Zeit wünscht Juppi
Datum:
Welche Entfernung willst du schaffen? Mit 15cm Draht ist schon einges machbar...
Datum:
@ Juppi "Wie sollte diese Antenne optimal beschaffen sein?" Das hängt von der Anwendung ab. Sag uns was Du vorhast und wir können Dir eine Antenne empfehlen.
Datum:
Hallo, Ich habe das Bascom Programm einmal mit einem Mega8 probiert, aber es will nicht so recht. Ich habe nach der RX-Routine in der for-Schleife ein "Print rfdata(count)" eingebaut, um zu sehen, ob der Text auch übertragen wird, aber es kommt immer der Text "96" (ASCII 39 und 36) heraus. Kann es sein, das im Code noch Fehler sind? Ist da was bekannt? Vielen Dank!! Andy
Autor:
Sascha Focus
(sascha_focus)
Datum:
Hi, habe nachdem meine RFM12 endlich gekommen sind, den Code ausprobiert. Keinerlei Datenverlust. Aber eine Frage mal so nebenbei. Warum Software SPI und nicht Hardware SPI? Gruß Sascha
Datum:
Habe versucht den Code von Benedikt zum laufen zu bringen, leider ohne Erfolg. Nutze zwei ATMEGA16 und zwei Module RFM12 gemeinsam auf großem Steckboard. Habe den Pull Up an FSK mit 10kOhm gesteckt, rückmeldung bekomme ich über RS 232. Antenne ist 17cm lang. Dabei fiel auf, daß das Senden scheinbar funktioniert (an SDO kommt mit steigender Flanke rückmeldung). Allerdings scheint der Empfang nicht zu funktionieren. Das Empfangsprogramm bleibt in der Funktion: void rf12_rxdata..... .... for (i=0; i<number; i++) { rf12_ready(); *data++=rf12_trans(0xB000); } rf12_trans(0x8208); ... bei dem rf12_ready hängen, da der RFM12 an SDO das Signal nicht wieder auf HIGH zieht... Hatte das jmd von Euch schon mal???
Autor:
Avr Nix
(avrnix)
Datum:
@bastelbär: Hast du schon dein BASCOM Programm mit den RFM12 Modul ausprobiert?
Datum:
@ Stefan Entweder wurde das Modul nicht richtig initialisiert, oder der Sender sendet nichts. Versuch mal die Pause vor der Initialisierung größer zu machen.
Datum:
@ Benedikt Danke,also, die Pause in der Initialisierung habe ich schon auf 150ms erhöht...muß mir mal nen Funkscanner leihen, um zu sehen, ob er sendet...oder wie macht Ihr das?
Datum:
Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet. Ergibt einen wunderbaren Spectrumanalyer im Bereich 45-880MHz mit etwa 100kHz Auflösung.
Datum:
Benedikt K. wrote: > Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet. Ergibt > einen wunderbaren Spectrumanalyer im Bereich 45-880MHz mit etwa 100kHz > Auflösung. ist zwar etwas OT aber: Wie nutz du den TV-Tuner als Spectrumanalyer?
Datum:
Ich habe am Ausgang des Tuners (ca 34-40MHz) einen SA615 hängen, der als Bandpass + logarithmischer Gleichrichter dient (nebenbei kann man an dem auch noch das FM demodulierte Signal abgreifen, aber das nutze ich nicht). Das RSSI Signal messe ich mit einem AVR, der dem Tuner die Frequenz per I2C vorgibt. So durchlaufe ich den ganzen Frequenzbereich. Leider hat der Tuner nur ein 62,5kHz Abstimmraster, aber das reicht für die meisten Sachen. Die Bandbreite meiner ZF Filter ist sowiso größer.
Datum:
@ Stafan ich habe hier genau das gleich Problem mit zwei ATmega16s. Das senden scheint zu klappen nur beim empfangen hängt der zweite Atmel. Der Code ist nicht angepasst, Original aus dem Zip. Beide können Senden. Sehr Komisch. Hat jemand einen Mega16 als Empfänger am laufen? Gruss Sven
Datum:
Beim mir das gleiche Problem, ich hab Mega32 dran hängen. Senden geht auf jeden Fall, hab ich mit einem Spektrumanalysator überprüft.
Datum:
@ Stefan sorry habe mich vertippt.
Datum:
Ich habe es bei mir gerade nochmal ausprobiert: Die Module an je einen tiny2313 @ 10MHz, und es funktioniert. Probiert mal folgendes: Erst den Empfänger einschalten, dann denn Sender.
Datum:
@ Benedikt Also der Sender sendet eindeutig, das habe ich jetzt mit nem Funkscanner überprüft! Man hört dann beim Senden ein kurzzeitiges Rauschen!... Aber der Empfänger scheint nicht zu funtionieren, auch wenn ich den Empfänger zuvor mit Spannung versorgt habe und anschließend den Sender einschalte! Aber woran soll es dann noch liegen?
Datum:
Leider kann ich da auch nicht viel machen, da man ja nicht in die Module reinschauen kann. Falls du ein Oszilloskop oder einen Frequenzzähler hast: Schau mal ob am CLK Ausgang (vom Empfänger) 10MHz rauskommen. Falls ja, dann ist das Modul zumindest halbwegs richtig initialisiert. Dann sollte es eigentlich funktionieren. Der Sender sollte etwa im 1s Takt Daten senden. Das müsste man deutlich an kurzen Rauschimpulsen hören können.
Datum:
Ich glaube ich habe das Problem: Es liegt am Sender ! Aus irgendeinem Grund funktioniert die Initialisierung nicht immer, sondern erst nach ein paar Versuchen. Zu Beginn höre ich auch nur ein Dauerrauschen, schalte ich den Sender aber mehrmals ein und aus, dann kommen plötzlich die 1s Rauschimpulse. Danach funktioniert es aus irgendeinem Grund jedesmal beim Einschalten.
Datum:
@Benedikt Also: Die Rauschimpulse kommen bei mir immer, das macht mein Scanner hörbar! Die 10MHz kommen sowohl am Sender als auch beim Empfänger an.(Oszi) Habe die Empfängerschaltung jetzt mit einem MEGA8 versucht, aber auch das funktioniert nicht! Der Empfänger bekommt scheinbar kein Signal! Die Signale an SDI und SCK kommen am Modul an, allerdings nichts an SDO!...kann es sein, daß die Initialisierung beim Empfänger nicht stimmt??
Datum:
Die Module gegeben nach dem Einschalten 1MHz aus. Ich schalte den Takt auf 10MHz um. Wenn also die 10MHz rauskommen, versteht also das Modul die Befehle. Ich habe es jetzt noch ein paarmal ausprobiert: Sobald der Sender läuft, empfange ich jedesmal die Daten problemlos.
Datum:
DANKE, Benedikt, aber ich bin noch nicht weiter...:( Ich hoffe wir sprechen von dem gleichen Programm!?...ich habe das rfm12.zip, des ersten Eintrags genommen...und das send auskommentiert und receive rein! oder hab ich da noch was vergessen??? vlt. kannste das aktuelle noch mal posten???
Datum:
Ja, genau dasselbe nutze ich auch. Wenn der Sender läuft, sollte der Empfänger eigentlich auch funktionieren. Hast du auch die Pause in der Schleife beim Empfänger auskommentiert ? Funktionieren müsste es aber trotzdem.
Datum:
ja, habe ich alles gemacht...mir fiel jetzt folgendes auf, wenn ich den Tastkopf an de SDO anschließe, dann scheint es zu funktionieren, aber warum???? Hat da jmd ne Ahnung?
Datum:
Timingproblem ? Oder ist der Pin nicht richtig angeschlossen ? Wie schnell läuft der AVR ? Muss der Tastkopf schon beim Einschalten vorhanden sein, oder reicht es erst später während dem Empfangen ? Probier mal ob es mit einem Pullup oder Pulldown funktioniert.
Datum:
Also um nochmal auf die Antenne zurückzukommen: Zum Einsatz kommen nur RFM12 Module: macht es in der Beschaffenheit der Antenne einen Unterschied, ob ich 10, 20 oder 50m überbrücken möchte? - wahrscheinlich nicht - die Länge und Beschaffenheit hängt doch von der Frequenz ab, oder? Zum Einsatz kommen sowohl RFM01 alsauch RFM02 Module: Verwendet man unterschiedliche Antennen bei Sender und Empfänger ? Um eventuelle Auschweifungen vorzubeugen: nein - keine Richtantenne - ich will nur ein Stück Draht dranhängen.
Datum:
Im einfachsten Fall: etwa 16cm Draht reicht. Die Antennenanpassung macht den Rest. Falls die Entfernung klein ist, kann man die Sendeleistung per Software reduzieren.
Datum:
@Benedikt Also, der SCK Takt liegt bei 3,7kHz und die Daten an den RFM12 Sender scheinen anzukommen. Allerdings kommt am SDO nicht heraus! Hast Du da noch einen Tipp für mich????
Datum:
Es gibt da eigentlich nur 2 Möglichkeiten (vorausgesetzt die Hardware ist OK): a) Die Intialisierung des Empfängers ist nicht korrekt angekommen. Versuch einfach mal die Init Routine mehrmals hintereinander aufzurufen. b) Der Sender sendet nicht die korrekten Daten.
Datum:
Also die initialisierung des Empfängers scheint zu laufen! Danach gibt es, da der SDO auf Low-Bleibt keine weiteren SCK-Impulse mehr....
Datum:
In Dateianhang ist meine code fuer: ATmega8 + RFM02 (TX modul) + hardware SPI PB2 (SS) -> nSEL=CS PB3 (MOSI) -> SDI PB5 (SCK) -> SCK PB0 <- nIRQ PB1 -> FSK
Datum:
Angehängte Dateien:...
Datum:
Angehängte Dateien:Hi Leute, nachdem nun endlich meine Module gekommen sind habe ich mir mal meinen Code wieder vorgenommen und wollte ihn probieren. Dabei habe ich, abgesehen von einem Programmierfehler von mir, einige Ungereimtheiten im Compiler festgestellt. Duch diese Ungereimtheiten war es nicht möglich dass das Programm richtig lief obwohl beim Compilieren kein Fehler auftrat. Als kleine Info: Ohne die Angaben von $hwstack, $swstack und framesize werden beim Aufruf der Funktionen bzw. Subs die Parameter anscheinend nicht richtig übergeben bzw. verarbeitet. Und beim Berechnen der Baudrate wird beim casten der Wert von Temp null anstatt 16 da die 344828 für Word zu gross sind. Also man lernt nie aus was Compiler so alles machen. Ich habe den Code entsprechend geändert und mal duch den Simulator laufen lassen und jetzt klappt es zumindest mit den Aufrufen. Leider kann ich erst morgen das ganze an der Hardware testen. Aber ich schick das File mal mit, die Tage gibts dann einen Erfahrungsbericht von mir. Also bis denne dann....
Datum:
@bastelbär In die Config SPI muß NOSS = 1 eingefügt werden und dann den SS Pin im Programm schalten. ansonsten geht SS (Chip Select) schon nach 8 Bit wieder auf High.
Autor:
Avr Nix
(avrnix)
Datum:
@HUMix - geht es bei in bascom und würdest das zur verfügung stellen?
Datum:
Angehängte Dateien:ES LEBT, ES LEBT!! Die Routinen für den BASCOM laufen. Ein kleiner Fehler, abgesehen von dem den HUMIX gemeldet hat, war noch drin (Highbyte zuerst senden) aber jetzt laufen sie. Ich habe sie gerade an der Hardware mit einem Evalboard getestet. Allerdings hab ich den MEGA32 mit 8Mhz vom Evalboard getaktet, also nicht mit den 10MHz vom Modul. Also aufpassen im Quelltext falls einer die 10Mhz nutzt. Angeschlossen hab ich das Modul folgendermassen: VDD -> VCC GND -> GND SDI -> MOSI (PB5, Pin 6) SDO -> MISO (PB6, Pin 7) SCK -> SCK (PB7, Pin 8) nSel -> SS (PB4, Pin 5) FSK -> R 10k Pullup Jetzt gehts weiter im Programm mit den Feinheiten und IRQ-Steuerung. Auch werde ich mal mit dem SPI-Clock spielen um schneller zu werden. Datei anbei, und nicht die Fuses vergessen. Joachim
Autor:
Avr Nix
(avrnix)
Datum:
@bastelbär kann ich dein Bascom Programm auf http://www.comwebnet.de veröffentlichen? Dort sammele ich von Usern Projekte und die werden veröffentlicht. Gucke mal rein und schreib mir bitte.
Datum:
@Benedikt Kannst Du mir bitte mal die AVR Studio Version nennen, mit der du das Programm compiliert hast..bei mir ist Version 4.13 , Bulid 528.... Bei der Version habe ich bereits rausgefunden, daß man das "#define F_CPU 1000000UL" weder in der Header noch in der c-Datei definieren darf, sondern nur im Makefile von AVR...sonst bekommt man falsche Zeiten bei DELAY.h routinen... Wie gesagt, es funktioniert immer noch nicht und ich sehe im Moment keinen Fehler..!?
Datum:
Hallo liebe gemeinde! ich habe vor, mir auch eine Datenstrecke basierend auf den Modulen RF12 aufzubauen, meine Frage richtitet sich an die Antenne. und zwar nicht für wieweit sie lang sein muss, sondern eher ob ihr erfahrungen mit der max. Länge habt? Der einsatz ort einer Gegenstellt ist dirket neben einem leeren metal roh, gute 30 cm hoch, wenn nicht länger. meine Frage wäre, ob was dagegen spricht dieses zu verwenden. (habe im DB nichts gefunden oder übersehen) lg
Datum:
Hallo, @bastelbär: Ich habe dein Programm nun ausprobiert - nur funktioniert es nicht! Ich verwende ein RFM12-Modul mit einem ATMega8 (mit 4MHz extern) als Sender und ein RFM12-Modul mit einem ATMega48(mit 8MHz extern) als Empfänger. Den Empfängerteil hab ich via RS232 an meinen PC angeschlossen. Schalte ich die beiden Teile ein, so gibt mein Terminal folgendes aus: Init<\r><\n>Set Frequenz<\r><\n>Set Bandwith<\r><\n>Set Baudrate<\r><\n>Set Power<\r><\n>Empfange<\r><\n> Das passt ja alles so weit - nur gibt er sonst nichts mehr aus! Ich habe dann versucht rauszufinden, wo das Programm hängen bleibt. Und das ist im Rf12_rxdata - Teil. Und zwar bleibt das Programm in der for-Schleife hängen. Ich habe dort ein "Print temp" hinein gegeben und mein Terminal hat dauernd 0<\r><\n> ausgegeben. Woran kann das liegen? Normalerweise sollte die for-Schleife doch nur 32mal durchlaufen, oder? Wie sieht das eigentlich mit den Fusebits aus? Vertragen die der Mega8 und der Mega48? Danke für eure Hilfe!! mfg Andy
Datum:
Bei mir kommt, wenn ich eine Ausgabe in der Schleife von rf12_rxdata
mache, gerade einmal diese Ausgabe und dann hängt das Teil halt. Kann es
sein dass das Modul nicht richtig angeschlossen ist? Wenn das Modul
korrekt angeschlossen ist und bei dir die Schleife durchläuft muss die
rf12_ready nicht klappen. Dass der Mega48 eine andere Anschlussbelegung
des SPI hat, ist dir bekannt. Und dass du oben im Programm hinter der
SPI-Definition den SS und den MOSI-Pin extra definieren musst hast du
auch gemacht?
Wenn ja, dann bin ich im Moment am Ende mit meinem Latein. Schau mal
diese Sachen nach und evtl. den SPI-Speed. Aber eher ist es das mit den
extra-Defs des SS und MOSI-Pin.
Was ist denn mit dem Sender? Gibt der im Sekundentakt "Sende" aus?.
mfg.
Joachim
Datum:
Hallo,
Danke für die rasche Antwort. Ich habs jetzt geschafft, dass der
Empfänger im Sekundentakt Daten ausgibt (Hab die hw- und die swstacks am
Anfang vergessen). Nur die Daten sind immer 0. Dh. der Text kommt nicht
an!
Dann hab ich natürlich den Sender unter die Lupe genommen und siehe da:
Der Text "Senden" kommt NICHT! Auch der andere Text ("Init", "Set
Frequenz" ...) kommt nicht, sondern nur irgendwelche verstümmelte Daten.
Muss noch genauer gucken, was da los ist!
Aber trotzdem danke nochmal!
lg
Andy
Datum:
"Verstümmelte" Daten sind ein Hinweis auf falsch gesetzte Quarz-Fuses.
Das bedeutet normalerweise dass der Chip mit der falschen Quarzfrequenz
läuft und dadurch die Baudrate falsch setzt.
Und mach, falls du im Empfängerproggi das "Wait 1" drin hast, das raus.
Nur Nullen deutet immer noch auf einen falschen Anschluss hin, sodass
rf12_ready den falschen PIN einliest. Insbesondere wenn der Sender dabei
aus ist.
mfg.
Joachim
Datum:
@avrnix
Nimm ihn nur den Code. Ist GPL.
mfg.
Joachim
Datum:
Hallo,
Habe jetzt alles gelöst! Der Sender sendet, und der Empfänger empfängt!
Aber der Empfänger empfängt nur:
Empfange<\r><\n><\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<
\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0
>-<\0>-<\0>-<\0>-<\0>-<\0>-<\0>-<\r><\n>
Sonst würde alles klappen! Was kann da noch sein??
THX Andy
Datum:
Guten Morgen! Kann ich irgendwie überprüfen, ob AM Modul etwas empfangen bzw. gesendet wird? THX Andy
Datum:
Andy wrote: > Kann ich irgendwie überprüfen, ob AM Modul etwas empfangen bzw. gesendet Senden: Mit einem Spectrum Analyser Empfangen: Mit dem Oszi am Filter Kondensator des RSSI Pin messen: http://www.mikrocontroller.net/attachment/22519/rfm01.JPG
Datum:
Hallo, Danke für die Antwort, ABER: Einen Spectrum Analyser hab ich nicht und am RSSI Kondensator tut sich nichts - weder am Empfänger, noch am Sender! Ich hab jetzt alles nochmal kontrolliert - richtig angeschlossen ist alles. Kann es sein, dass ein Modul defekt ist? Woran würde ich das merken! Wenn ich den CLK Pin messe, bekomme ich ein Signal - ist das eine Garantie, dass das Modul funktioniert? Ich bin am Verzweifeln!! THX Andy
Datum:
Wenn du meinen Code verwendest, dann kannst du die Frequenz am CLK Pin messen: Da sollten 10MHz rauskommen (standardmäßig sind das 1MHz). Durch die Software wird auf 10MHz umgeschaltet. Wenn das der Fall ist, kann man eigentlich davon ausgehen dass das Modul OK ist, und auch richtig angeschlossen ist.
Datum:
OK, da stimmt was nicht! Beim Sender hab ich 10Mhz - beim Empfänger jedoch nur 1MHz. Da wird der Hund begraben sein. Werd nochmal die Anschlüsse kontrollieren. Wo könnte noch ein Fehler liegen bzw. gibt es noch eine einfache Möglichkeit die Funktionalität des Moduls zu testen?? THX Andy
Datum:
Lade mal die Sender Software rein. Dann kannst du einen Softwarfehler ausschließen, da der Sender ja anscheinend funktioniert.
Datum:
Also, zuerst hat es mit der Sendersoftware funktioniert (nur die 10MHz). Dann ist er auf 1Mhz runtergesprungen und jetzt kommt am CLK gar nix raus! Aber am SDO kommt was raus! Ich glaub, das Modul ist im A...., oder gibt es noch Hoffnung? THX Andy
Datum:
Es könnte sein, dass die Software einfach nur den Takt abschaltet, also falsche Daten am Modul ankommen. Was hast du mit dem Modul gemacht, wenn du denkst das es kaputt ist ?
Datum:
Naja, dann wäre der Takt bei beiden Modulen aus, oder! Es könnte sein, dass ich einmal zuviel Spannung angelegt habe, habe irrtümlich 7V anstatt 5V angelegt - daher befürchte ich, dass es was abgekriegt hat!
Datum:
So, beide Module lassen sich nun auf 10MHz einstellen (Hab ein neues eingebaut), aber es kommen immer noch lauter Nullen?? Was is da los?? Nur so nebenbei: Haben die Einstellungen von SWStack, HWSTack und FrameSize etwas damit zu tun? Wie lauten denn die richtigen Einstellungen für einen Mega8 bzw. Mega48?? Danke Andy
Datum:
Nochwas: Wie muss ich eigentlich den Antennen-Pin beschalten?? Ich weiß, ich bin nervig, aber ich kenn mich da nicht so aus!! THX Andy
Datum:
Ein 16cm langes Stück Draht dran.
Datum:
Hallo Gemeinde! Mir geht es so wie Andy. Ich habe Sender und Empfänger mit ATMega8 aufgebaut. 10 MHz kommen am Taktpin raus. Ich empfange nur Nullen. Hat jemand noch eine Idee? Mir fällt im Moment nicht mehr viel ein. Danke schon mal! JR
Datum:
Bei mir ging es erst, nachdem ich in RF12_RXData RF12_Ready(); durch while (!(RF12_Status() & 0x8000)); ersetzt hatte. Aber eigentlich möchte ich nicht jedes mal das Statusregister abrufen, um zu sehen ob ein neues Byte da ist. Gibt's vll. ne ähnliche Möglichkeit wie beim Senden? Im Datenblatt habe ich dazu nichts gefunden. Stefan
Datum:
Im Prinzip machst du mit dem Status lesen dasselbe wie ich auch, nur das
ich nur das 1.Bit und nicht den ganzen Status lese. Probier mal
folgendes: Ersetze die rxdata Funktion durch diese hier:
void rf12_rxdata(unsigned char *data, unsigned char number)
{ unsigned char i;
rf12_trans(0x82C8); // RX on
rf12_trans(0xCA81); // set FIFO mode
rf12_trans(0xCA83); // enable FIFO
cbi(RF_PORT, SDI);
for (i=0; i<number; i++)
{ rf12_ready();
*data++=rf12_trans(0xB000);
}
rf12_trans(0x8208); // RX off
}
Vielleicht liegt es ja daran, dass SDI high ist.
Datum:
Hallo Benedikt + Helfer, vielen Dank für Eure Arbeit. Meine Test HW mit 2 x Atmega16 + RF01 + RF02 lief mit den Treibern auf Anhieb, d.h. nachdem ich meine Verdrahtungsfehler beseitigt hatte ;-) Beim Empfang hatte ich lediglich das Problem, daß das letzte Byte manchmal falsch empfangen wurde. Ich habe dann ein bisschen experimentiert, hier die Lösung: Beim Sender in der rf02_txdata Funktion eine extra Verzögerung einbauen, vor dem Abschalten des Chip Select und vor dem Ausschalten des Transmitters, erst dann traten bei mir keine Fehler mehr auf. void rf02_txdata(unsigned char *data, unsigned char number) { ... ... ... _delay_us(10); sbi(RF_PORT, CS); while(RF_PIN&(1<<IRQ)); // wait until transfer done _delay_us(10); rf02_trans(0xC464); // TX off after 10us }
Datum:
Das Problem mit dem letzten Byte tritt auch bei den RF12 Modulen auf. Eine Anmerkung zur RF_Ready Zeitweise bleibt das Programm in der RF12_Ready hängen --Endlosschleife-- daher habe ich ihr ein Timeout verpasst. Sub Rf12_ready Reset Ss 'Chip Select = 0 For I = 1 To 30000 If Miso = 1 Then Exit For Next End Sub
Datum:
Ich benutze den Kode von Benedikt und habe einige Zeit gebraucht, um zwei Module zur Zusammenarbeit zu bewegen (man 'sieht' ja leider nicht, ob der Sender wirklich sendet). Ich bekam zuerst am Empfänger auch nur Nullen angezeigt, habe dann mit dem Oszi festgestellt, das die rf12_ready() immer sofort wieder verlassen wird, auch wenn überhaupt kein Zeichen gesendet 8und damit wohl auch nicht empfangen) wurde. Der Grund ist aber eigentlich klar. Wenn man einen gut optimierenden Compiler verwendet, dann wird nach dem Aktivieren des CS sofort im nächsten Takt der Zustand des SDO abgefragt. Der Zustand ändert sich aber beim AVR erst einen Takt später. Also auf jeden Fall ein NOP einfügen.
void rf12_ready(void) { RFM12_CS = 0; // cbi(PORTB, CS); __no_operation(); while(!RFM12_SDO); // wait until FIFO ready RFM12_CS = 1; // sbi(PORTB, CS); } |
(Ja, ich hab's etwas umgeschrieben und ). Läuft bei mir jetzt absolut stabil, vielen Dank an Benedikt für die Mühe. Gruß, Jörg.
Datum:
@JBecker und Luke H. Danke für die Fehler. Ich werde es sofort ändern. @diejenigen bei denen sich das Programm bei rf12_ready() aufhängt: Funktioniert die Software bei euch, wenn ihr den Code wie folgt ändert ? Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"
Datum:
@ Benedikt Das Problem des hängens entsteht in dem Moment wenn RX aufgerufen wird aber aus welchen Gründen auch immer nichts zum Empfangen da ist. Wenn ich es richtig verstehe wird das erste bit vom Status nur high wenn der fifo gefüllt ist. Oder habe ich da etwas falsch verstanden?
Datum:
Ja, das stimmt.
Entweder sendet der Sender also nicht das Startzeichen, oder der
Empfänger empfängt nicht.
Da die Software also prinzipiell lauffähig ist (da sie bei mir und bei
anderen läuft), könnte es ein Timing Problem sein (so ähnlich wie der
Fehler von JBecker, der ist bei mir ja auch nicht aufgetreten.) Daher
die kleine Änderung an der Software. Vielleicht könnte man jemand bei
dem es nicht geht, ausprobieren ob die Änderung was bringt.
Hier nochmal die Änderung in vereinfachter Form. Falls es darann liegt
müsste es funktionieren:
void rf12_ready(void)
{ cbi(RF_PORT, SDI);
cbi(RF_PORT, CS);
asm("nop");
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}
Datum:
@ Humix Man sollte auf jeden Fall, wie schon beschrieben, ein Timeout in der rf12_ready() einfügen. Besser noch: Ich würde gerne den IRQ-Ausgang des Moduls verwenden, habe damit aber bisher gar keinen Erfolg?!? Der Ausgang geht nur gaaaaaanz selten überhaupt mal auf high (und ich habe nicht herausgefunden, wann). Es gibt noch einige Ungereimtheiten. Nach dem Senden sollte man auch warten, bis alle Daten 'raus sind, bevor man den Sender ausschaltet. Eine feste Wartezeit funktioniert zwar, besser wäre es aber wohl, hierfür irgendein Statusbit zu benutzen (wie gesagt, IRQ 'geht' bei mir nicht). Wenn ich zuerst den Empfänger einschalte und dann den Sender, dann empfange ich immer nur das erste gesendete Zeichen, danach hängt der Empfänger. Hmmm, da ist wohl noch etwas Arbeit nötig. Ich möchte die Module zum Fernschalten von Lampen (dimmen) und Geräten einsetzen (Hausautomation). Bevor ich die Platinen anfange, möchte ich nur wissen, das alles funktioniert. Jörg.
Datum:
@ Benedikt Da haben wir uns misverstanden . Die Software funktioniert !! Es geht mir nur darum das wen ein Byte verloren geht das Programm irgendwie aus der Rf__Ready Schleife herauskommen muß.
Datum:
Du meinst, wenn irgendwo in der Mitte ein Byte verloren geht, oder wenn das Sync Word verloren geht ?
Datum:
Richtig. Kann ja auf der Funkstrecke mal passieren.
Datum:
Wenn das Sync Word nicht ankommt, hängt der Empfänger eben. Da muss man halt vor die Empfangsfunktion anpassen (erst einschalten, dann abfragen ob Daten vorhanden sind, und falls ja dann empfangen. Wenn aber während der Übertragung was verloren geht, dann interessiert das nicht: Nach dem Sync Word emfpängt das Modul egal was kommt, bis man das FIFO abschaltet.
Datum:
Hallo, Ich hab jetzt bei rf12_ready das nop und bei rxdata das reset sdi eingebaut! Beides hat nichts gebracht!! Ich empfange immer noch Nullen! Ist vielleicht schon jemand weiter gekommen?? THX Andy
Datum:
Seltsam. Jetzt wäre interessant zu wissen, was du anderst machst als z.B. Humix, JBecker oder ich. Es ist leider sehr schwierig einen Fehler zu finden, der nur bei etwa der Häfte der Schaltungen auftritt. Hast du an der Software irgendwas verändert (außer zwischen Senden/Empfangen umgeschaltet) ?
Datum:
Nein, das einzige, das ich verändert habe, ist, dass ich anstatt 32 Zeichen nur 8 sende, damit ich das im Terminal vernünftig ablesen kann. Sonst hab ich nix verändert. Die Antenne ist 16cm lang! Aber an dem Kondensator bei RSSI messe ich auch kein Signal!! Irgendetwas stimmt da nicht!
Datum:
Hast du mal die unveränderte Software ausprobiert (also nur Senden/Empfangen etsprechend angepasst) ? Welche Optimierungseinstellungen verwendest du ? Ich habe aus -o2 gestellt, da dies meiner Meinung nach das optimalste ist.
Datum:
Was meinst du mit Optimierungseinstellungen? Ich arbeite mit Bascom! Außerdem ist mir aufgefallen, dass beim Sender bei der RS232 folgendes rauskommt: D-i-e-s- -i-s-t-<\r><\n>Sende<\r><\n> Müsste "Sende" nicht zuerst kommen?? Fragen über Fragen....
Datum:
Achso, du verwendest das Bascom Programm. Da kann ich dir leider nicht weiterhelfen, für Bascom Probleme musst du dich an bastelbär wenden.
Datum:
@bastelbär Hallo, kannst du mir vielleicht weiterhelfen?? THX Andy
Datum:
Nochetwas: Welche Fuses muss ich setzen?? Vielleicht liegt hier das Problem!! Ich setze meine Fuses mit AVR Studio 4. Vielleicht kann mir wer einen Screenshot posten!! THX Andy
Datum:
So langsam fange ich wohl an zu verstehen, wie der Empfängerteil im RF12 funktioniert: Nach dem Einschalten des Empfängers und der Initialisierung des FIFO wartet der Empfänger auf die Präambel und das Sync Word. Danach werden kontinuierlich Daten in den FIFO geschoben. Man kann jetzt beliebig viele Bytes auslesen, auch wenn gar keine mehr gesendet (und empfangen) werden. Die Abfrage, ob Daten vorhanden sind, ergibt immer wieder ein positives Resultat. Daher die Nullen, die einige beobachten (und ich teilweise auch). Für eine vernünftige Datenübertragung sollte man also die Daten beim Senden in Paketen blocken, also eventuell ein Protokoll wie STX/ETX oder SLIP verwenden (möglichst mit Checksumme), bei dem man eindeutig (den Anfang und) das Ende des Blocks erkennen kann. Beim Empfang liest man dann solange Daten ein, bis man das Paket-Endezeichen bekommt. Dann kann man den Empfang beenden (oder Abbruch nach einer bestimmten maximalen Anzahl von Zeichen). Um beim Senden nicht eine Wartezeit nach dem letzten Zeichen einfügen zu müssen, kann man auch einfach ein bis zwei Füllbytes senden. Mit Bitte um Kommentare ...... Jörg.
Datum:
Ja, genauso ist es. Die Idee mit dem Ende Zeichen ist gut. Wenn man allerdings nur Steuersignale mit einer festen Länge überträgt, kann man auf das Endzeichen verzichten, und hat damit schonmal eine Fehlerquelle weniger.
Datum:
Guten Morgen, Kann mir vielleicht jemand die Sende- und Empfangsroutinen (in Bascom) erklären, damit ich auch ein bisschen weiß, was da eigentlich passiert! Warum wird zum Beispiel 3x hintereinander &HB8AA gesendet, bevor die Daten übertragen werden, usw. Wäre euch sehr dankbar!! Danke, Andy
Datum:
Nochwas: Wenn ich in der Empfangsroutine anstatt von Temp = Rf12_trans(&Hca83) den Befehl Temp = Rf12_trans(&Hca87) ausführe (Verwenden von Syncword ein), dann lese ich irgendetwas anderes als dauernd 0 aus! Nur sind diese Daten nicht das, was ich mit dem anderen Modul sende. Wenn ich den Sender ausschalte, kommt der gleiche Mist an!! Ich kenn mich nicht mehr aus! Irgendwie komm ich mit diesem sch... Modul nicht weiter. Hab bei Pollin schon 3 weitere bestellt - vielleicht sind meine defekt! Wäre aber trotzdem für Infos über die Sende- und Empfangsroutine dankbar! mfg Andy
Datum:
Ähhmm... Temp = Rf12_trans(&Hca87) bedeutet natürlich: Verwenden von SyncWord aus!!
Datum:
Das deutet darauf hin, dass entweder die Frequenz oder Baudrateneinstellung von Sender und Empfänger nicht übereinstimmen, oder der Sender einfach nicht sendet. Gibt es eigentlich jemanden, bei dem das C Programm noch nicht läuft ?
Datum:
Aber an den Baudraten und Frequenzeinstellungen hab ich nix verändert! Kann es daran liegen, dass der Sender und der Empfänger (nur die Atmels) mit zwei verschiedenen Quarzen laufen?? (Empfänger mit 8Mhz und Sender mit 4Mhz)
Datum:
Daran dürfte es eigentlich nicht liegen, da die Baudrate im Modul erzeugt wird.
Datum:
Ob der Sender sendet, kann ich ohne Spectrum Analyzer nicht feststellen, oder?? Andy
Datum:
Mit einem passenden Funkgerät würde es noch gehen, oder zur Not mit einem TV (das müsste Kanal S38 sein). Keine Ahnung was man auf dem TV erkennen kann, wie und fein man heutige TVs abstimmen kann, aber zumindest bei älteren TVs ohne automatischem Sendersuchlauf sollte man die 1s Sendeimpulse im Ton hören wenn die Frequenz passt.
Datum:
OK, hab ich beides nicht in der Firma. Mal sehen, ob ich die Dinger mit nach Hause nehmen kann. Ansonsten hat keiner eine Idee, was da sein könnte, oder?? Das gibt es ja nicht - bei allen funktioniert es, nur bei mir nicht. Entweder bin ich zu blöd (was ich langsam glaube gg) oder meine Module sind wirklich defekt! Aber dann könnte ich doch überhaupt nichts auslesen, oder. Und auch die Frequenz lässt sich einstellen! Ich steh jetzt echt an!!! mfg Andy
Datum:
Also bei mir läuft Benedikts C Programm ohne Probleme. Den Sender hab ich mit einer TV Karte auf Kanal S37 mit einwenig Finetuning gefunden, man hört den Datenstream im Tonkanal. Werde am Wochenende mal versuchen den Stream mit Gnuradio zu dekodieren. Ich hab mal eine Verständnissfrage: Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann das FFIT Signal? Lt. Datenblatt geht FFIT ja LOW wenn der FIFO Füllstand unter den Programmierten Wert des FIFO IT Levels fällt. Wenn ich nun den FFIT Ausgang des Moduls an einen Interrupt Pin des AVRs hänge, sollte ich doch mitbekommen wenn das Modul den FIFO geleert haben will und wenn der FIFO leer ist?
Datum:
Claude wrote: > Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das > Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann > das FFIT Signal? Das gibt an, ob im FIFO mehr Bits sind, als das eingestellte Level. Bei mir signalisiert FFIT also ob ein komplettes Byte im FIFO ist oder nicht. Ich verwende aber nicht den FFIT Pin, sondern lese das Bit über das Statusregister aus, um einen Pin zu sparen. Bei all denjenigen wo das Programm hängt, müsste also der FFIT Pin auf Low liegen. Denn im Gegensatz zum INT Pin ist der FFIt Pin high aktiv.
Datum:
@Benedikt: Ich habe noch eine Idee. Wäre es möglich, dass du mir 2 Hex-Files mit deinem C-Programm machst. Das wäre super, dann würde ich gleich sehen, ob es am Modul oder am Programm liegt, oder? Der Sender wäre ein Mega48 mit 8Mhz und der Empfänger ein Mega8 mit 4Mhz. SPI-Pins nicht vergessen! Das wäre ganz nett von dir - nur wenn du Zeit hast!! Vielen Dank schon im Voraus!! mfg Andy
Datum:
Angehängte Dateien:@Benedikt Ok, danke für die Erleuchtung :-) Ich hab momentan das Problem das der AVR in der while schleife im rf12_ready hängen bleibt wenn das rfm12 keine Daten empfängt. Werde mal versuchen mit dem FFIT Pin und einer IRQ Routine das ganze ans laufen zu bekommen. @ Andy Warum lädst Du dir nicht einfach WinAVR runter und probierst es selber? Ein Makefile findst Du im Anhang. Für deinen Mega48 musst Du noch im Makefile die Zeile "MCU = atmega8" in "MCU = atmega48" ändern und in rf12.c noch deine Quarzfreuenz einstellen.
Datum:
Ich erstelle jetzt mal 2 Hexdateien, beide für einen mega8 für Sender und Empfänger, teste die mal bei mir an einer Minimalhardware und wenn beide sicher funktionieren, dann lade ich die hier hoch (vermutlich heute Nachmittag bis Abend.) Das sollte dann bei jedem funktionieren. Falls nein -> Hardwarefehler, ansonsten liegt es an der Software.
Datum:
Angehängte Dateien:Hier 2 Programme, die bei mir mit einem Minimalaufbau laufen: RFM12 an einen mega8 gelötet. Der hängt über einen FT232 am PC. Sonst sind keine weiteren Bauteile verbaut (weder Quarz, noch Kondensatoren oder sonstwas). Den mega8 habe ich mit dem internen 8MHz Takt laufen. Die Module sind am SPI Interface angeschlossen, verwenden dieses aber nicht (Software SPI.) Die Hex Dateien kann man direkt den AVR brennen. Jetzt bin ich mal gespannt.
Datum:
JJJUUUUUUUUHHHHHHHHHHHUUUUUUUUUUUUU!!!!! Es kommt die Meldung Empfänger läuft und dann im Sekundentakt "Dies ist ein 433MHz-Test". Und ein bisschen wirres Zeug herum!! Wow, danke!! Hast mir sehr geholfen! Jetzt muss ich nur mehr rausfinden, warum das mit Bascom nicht funzt!! Irgendeine Idee? gg Danke nochmal!! Andy
Datum:
>Claude wrote: >> Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das >> Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann >> das FFIT Signal? Ähm, das muss ich relativieren. Wenn man den Portpin, an dem man FFIT angeschlossen hat, auf Eingang schaltet, dann kommt da schon was an :-) Es liegt übrigens am FFIT exakt das gleiche Signal an, welches Benedikt mit seiner rf12_ready Routine am SDO-Pin abfragt. Man gewinnt also durch den zusätzlichen Pin eigentlich nicht viel. Den IRQ-Pin benutze ich nicht, weil hier ein Gemisch von allen möglichen Statusbits ver-odert anliegt, damit kann ich momentan nicht viel anfangen. In der rf12_ready habe ich ein timeout eingebaut:
U8 rf12_ready(void) { U16 timeout = 1000; RFM12_CS = 0; // cbi(PORTB, CS); __no_operation(); __no_operation(); while((!RFM12_SDO)&&timeout) { timeout--; __delay_cycles(10); // wait until FIFO ready } RFM12_CS = 1; // sbi(PORTB, CS); if(timeout==0) return 0; else return 1; } |
und in rx_data liefere ich als Rückgabewert die Anzahl gelesener Zeichen:
U8 rf12_rxdata(U8 *data, U8 number)
{
U8 i;
FLAG5 = 1;
rf12_trans(0x82C8); // RX on
rf12_trans(0xCA81); // Init FIFO
rf12_trans(0xCA83); // enable FIFO
for (i=0; i<number; i++)
{
FLAG4 = 1;
if(rf12_ready())
*data++ = (U8)rf12_trans(0xB000);
else
break;
FLAG4 = 0;
}
rf12_trans(0xCA81); // disable FIFO
rf12_trans(0x8208); // RX off
FLAG5 = 0;
return i;
}
|
So kann ich im Empfangsprogramm einfach rx_data aufrufen und bekomme entweder die Anzahl der gelesenen Zeichen, oder aber 0, wenn während der timeout-Zeit keine Daten empfangen wurden. Klappt schon ganz gut (also eigentlich perfekt). Das Blocken der Daten in Paketen kommt als nächstes (morgen ist ja Feiertag). Gruß, Jörg.
Datum:
Angehängte Dateien:Hallo Hier Die LIB für EAGLE der Module RFM 01,02 und 12 Gruss Ulrich
Datum:
Hallo Benedikt, ich habe hier Dein Programmierbeispiel gefunden, nachdem ich mit dem Code-Beispiel von Pollin fast verzweifelt hatte, war Dein super strukturierter Code die wahre Wohltat. Ich habe mir von Pollin zwei Funk Eval Boards zugelegt, jeweils mit RFM12 und ATmega32-16 bestückt. Die Verdrahtung ist zwar etwas anders als bei Deiner Hardware, aber mit wenigen Änderungen (Pin defines und Pullup programmieren) lief Deine Software auf Anhieb !!!! Danke für dieses Stück gute Arbeit !!! Georg
Datum:
Hallo zusammen! Mich würde interessieren, ob es jemand mittlerweile geschafft hat, die Module unter Bascom richtig anzusprechen. Ich würde das RF12 nämlich gerne im Zusammenhang eines kleines Roboterprojektes einsetzen, dass ansonsten auf Bascom basiert. Gruß&Dank! Malte
Datum:
Das Basicprogramm von Bastelbär in diesem Thread funktioniert!!!
Datum:
Okay, sorry! Ich hatte die Probleme die Andy hatte, als Probleme des Bascom-Codes interpretiert. Danke für den Hinweis! Gruß, Malte
Datum:
Hallo@all Der Code von Benedikt K. funktioniert, wie in diesen Thrad schon angesprochen bei mir nur mit NOPs in RF_Ready. Im Freien komme ich auf etwa 150m! Interessant wäre für mich noch ein Verstärker um die Reichweite zu erhöhen. Gruss Ulrich
Autor:
Marius S.
(lupin)
Datum:
Kommuniziert bei benedikts letzten beispiel das RFM12 modul mit sich selbst? Meine Idee ist so ein Modul per software usb an den PC zu bringen. Ist es eigentlich wichtig wie die Daten die ich sende aussehen? Bringt es vielleicht die irgendwie zu kodieren (nicht in Bezug auf Sicherheit sondern in Bezug auf Reichweite/Stromverbrauch oder sonstige komischen Effekte)?
Datum:
Marius Schmidt wrote: > Kommuniziert bei benedikts letzten beispiel das RFM12 modul mit sich > selbst? Nein, ein Modul kann nicht gleichzeitig senden und empfangen. > Meine Idee ist so ein Modul per software usb an den PC zu bringen. Ist > es eigentlich wichtig wie die Daten die ich sende aussehen? Bringt es > vielleicht die irgendwie zu kodieren (nicht in Bezug auf Sicherheit > sondern in Bezug auf Reichweite/Stromverbrauch oder sonstige komischen > Effekte)? Manchester Kodierung bringt vermutlich ein kleinwenig, da die Bittakt Wiederherstellung dann einfacher wird. Zwingend notwendig ist das aber nicht, solange es ausreichend Flanken im Datenstrom gibt. Ich teste gerade einen 8-4 Hamming Code, der eigentlich immer ausreichend Flanken in einem Byte erzeugt. So benötigt man zwar auch 16bit für 1Byte Nutzdaten, aber dafür kann man immerhin noch ein falsches Bit wieder korrigieren.
Autor:
Marius S.
(lupin)
Datum:
Vielleicht kann man das ja hiermit kombinieren: http://www.jrobot.net/Projects/AVRcam.html Ist irgendwie logisch, dass das modul nicht beides gleichzeitig kann, schließlich hat es ja nur eine Antenne :-)
Datum:
Angehängte Dateien:Um den Thread etwas zurück zu geben, eine kleine Bastelei von mir. Das RFM12 als Bidirektionaler RS232 Tunnel. Folgendes ist bis jetzt Implementiert: - Basierend auf Benedikts Code - Timeout für RX , wie von JBecker beschrieben. - STX/RTX Stack von der Procyon AVRlib. - Verpacken von UART RX Bytes in STX/ETX Packete . - Entpacken von STX/ETX Packeten und schicken an den UART. - Erkennen von validen STX/RTX Paketen (STX,ETX,CRC). - Bidirektional Half Duplex mit 1200 Baud. Was noch fehlt : - Neuanforderung von STX/ETX Paketen falls diese nicht valid sind. - Nutzung aller Features der STX/ETX Library. - Sauberer Code ... - Schneller Code ... Als Testhardware habe ich 2 ATmega8 mit 14,7456MHZ Quarzen benutzt. Das RFM12 ist ,wie in Benedikts Code, nur mit 4 Leitungen am ATmega. PS: Bitte klopft nicht zu arg auf mich ein, Programmieren ist nicht so mein Ding. Das Werkzeug meiner Wahl ist der Lötkolben,und so Programmiere ich auch :-)
Autor:
Avr Nix
(avrnix)
Datum:
Was ist ein STX/ETX Packet und was warum sollte ich das noch Tunneln? Ich verstehe den Sinn der Anwendung nicht kannst du das mal erläutern?
Datum:
Datum:
Auszug aus der Beschreibung der STX/ETX Lib von Procyon :
STX/ETX is a simple packet protocol for serial data streams and offers packetization, type tagging, and checksum protection for user data. Common uses of STX/ETX might include radio communications were it can improve data reliability over lossy channels. STX/ETX may also be used effectively anywhere multiple access to the communication medium is required. The packets can be made to contain destination addresses or routing information as well as data. |
Ich benötige das STX/ETX für meine Anwendung. Als Test hab ich die RS232 durchgetunnelt. Gruß Claude
Datum:
@Benedikt K Brauchst du die code von hier ?? Beitrag "Re: RMF12 - Funkmodul" Ich habe diser kode testet (ohne einer rf modul) , und die tabelle version ist sehr schnell. Ich kriege hoffentlich 4 modules von Pollin morgens , und auch von die sammelbestellung. mfg Bingo Dänemark
Datum:
Ohmann, Fossie...
da haste mir ma ein Ei gelegt :)
Die Bascom Version läuft wunderbar, man muss nur wissen, dass bei
"Spi_sdo Alias Pinb.6 ' MOSI-PIN"
der "MISO" Pin gemeint ist!
>_<
Das hat mir und möglicherweise noch ein paar anderen die nicht den
Mega32 verwenden und von daher die Pins umdefinieren müssen "das Genick
gebrochen"...
Aber einen Vorteil hatte es, ich hab kurz vorm Seppuku noch eine "Soft
SPI" Routine (angelehnt am C Code) geschrieben:
' werden benötigt für rf12_ready bzw SoftSPI (Definitionen für Mega8)
Spi_sdi Alias Portb.3 ' MOSI-PIN
Config Spi_sdi = Output
Spi_sck Alias Portb.5 ' Clock-Pin
Config Spi_sck = Output
Spi_cs Alias Portb.2 ' SS-Pin
Config Spi_cs = Output
Spi_sdo Alias Pinb.4 ' MISO-PIN
...
...
...
Function Rf12_trans(byval Wert As Word) As Word
Dim I As Integer
Reset Spi_sck
Reset Spi_cs
For I = 0 To 15
If Wert.15 = 1 Then
Set Spi_sdi
Else
Reset Spi_sdi
End If
Shift Wert , Left , 1
If Spi_sdo = 1 Then
Wert = Wert Or 1
End If
' clock
Set Spi_sck
$asm
nop
nop
$end Asm
Reset Spi_sck
Next I
Set Spi_cs
Rf12_trans = Wert
End Function
|
Und die ready methode noch abgeändert:
Sub Rf12_ready
Reset Spi_sdi
Reset Spi_cs
$asm
nop
nop
$end Asm
While Spi_sdo = 0
Wend
End Sub
|
Ich hoffe das war das Problem.
Datum:
Angehängte Dateien:Ich habe gestern endlich meine Module bekommen und gleich eingebaut. Ich benutze sie am Tiny44. Leider funktioniert der Code beim senden nicht. Der Code hängt sich in der rf02_txdata() auf. Die Inits davor werden aber ausgeführt. Da ich nur Pins an 2 Versiedenen Ports zur verfügung habe, habe ich den Code etwas angepasst. Oder hat der Code irgendwo noch ein Bug, weil das die erste Version (Post vom 16.04.2007 15:28) ist. Wie kann ich weiter vorgehen bei der Fehlersuche?
Datum:
Verwendest du irgendwelche Interrupts ?
Datum:
Ja, hab aber erstmal zum testen sei() nicht gesetzt.
Datum:
P.S. ich habe die Leiterplatte mit einem Tropfen Sekundenkleber an der Unterseite mit einem Balsaholz verbunden. Ist Sekundenkleber leitfähig, oder greift es die Leiterbahnen an?
Datum:
So neue Info: Es hängt bei der Funktion:
void rf02_shiftout(unsigned char wert)
{ unsigned char j;
for (j=0; j<8; j++)
{ while(RF_PIN&(1<<IRQ));
while(!(RF_PIN&(1<<IRQ))); <-Diese Schleife läuft ewig!!!!!!!!!!
if (wert&128)
sbi(RF_PORT, SDI);
else
cbi(RF_PORT, SDI);
wert<<=1;
}
}
Datum:
Hast du ein Oszilloskop ? Falls ja, dann sollte and der nIRQ (=SDO) Leitung kurze Impulse im Baudratentakt zu sehen sein. Falls ja, dann überprüfe ob die an dem Pin landen, der abgefragt wird. Liegen am CLK Pin 10MHz oder 1MHz an ?
Datum:
hab leider kein oszi. Nur ein Frequenzmesser bis 200KHz.
Datum:
Matze, könnte es vielleicht sein, daß Du den IRQ-Pin am falschen Port zu lesen versuchst? Weiter oben hattest Du ja geschrieben, daß die Pins über zwei Ports verteilt sind. Poste doch mal Deine Pinbelegung und die entsprechenden #define-Zeilen für RF_PIN, RF_PORT, usw.
Datum:
Die Defines stehen in der C Datei (siehe Post 22.05.2007 08:42 ) B2=Csel A4=SCL A5=SDI A6=IRQ
Datum:
Ah - sorry, das Attachment hatte ich übersehen. Mir ist noch aufgefallen, daß Du util/delay.h inkludierst ohne vorher F_CPU zu definieren. Das ist OK, wenn Du den Tiny44 mit 1MHz taktest oder F_CPU in einem vorher inkudierten Header oder an der gcc-Kommandozeile definierst. Falls der Controller aber schneller getaktet ist und F_CPU nicht entsprechend gesetzt wird, sind Deine Delays zu kurz und das kann dazu führen, daß das Modul das Sendekommando nicht erkennt und Dir deshalb am IRQ-Pin keine Takte liefert.
Datum:
Ich habe den Takt mit 8MHz definiert, derzeit läuft mein Controller aber nur mit 1MHz um zu schnelles schalten zu vermeiden.
Datum:
Hast Du es denn schonmal mit 8MHz versucht, vielleicht ist die CPU ja mit 1MHz zu langsam? Auf jeden Fall sollte F_CPU der tatsächlich eingestellten Taktfrequenz entsprechen, damit die Delays die korrekte Dauer haben. Noch ein Gedanke: Hast Du schonmal untersucht, ob die Schleife gleich beim ersten Aufruf von rf02_shiftout hängen bleibt, oder erst nachdem schon ein paar Bytes zum Modul geschickt wurden?
Datum:
1MHz ist definitiv zu langsam: Die zu erkenenen Impulse haben 1,6µs. Vielleicht solltest du besser die USI oder einen Interrupt nutzen, anstelle der Software Routine.
Datum:
Hallo, Hab noch eine ganz andere Frage. Und zwar: Woran kann es liegen, dass Zeichen "verschwinden" (bei der Übertragung)? Ich will eigentlich nur 3 Byte übertragen. Das erste kommt immer an und die letzten zwei nur selten oder falsch. Was kann da sein? THX Andy
Datum:
Angehängte Dateien:Das liegt am Sendepuffer. Der fasst 2 Byte, die noch nicht übrtragen sind wenn der Sender abgeschaltet wird. Hier mal die neueste Version, wo alle mir bisher bekannten Fehler behoben sind.
Datum:
Und warum funktionierts dann mit der Version, wo 32 Byte übertragen werden??
Datum:
Da funktioniert es nicht so ganz, aber das merkt man nicht, da die letzen paar Zeichen "!\n" sind.
Datum:
Hallo, OK, ich will 3 Bytes übertragen, d.h. ich muss eigentlich 5 Bytes übertragen, weil die letzten beiden irgendwie verschwinden, oder? Das habe ich nun gemacht und es funktioniert jetzt auch besser als vorher. Nur hab ich nochwas komisches festgestellt! Wenn ich z.B. 02 FF 03 übertrage, klappt das wunderbar - immer wieder. Nur wenn ich 02 01 03 sende, dann kommt der Wert 02 immer an und die folgenden nur manchmal. D.h. wenn ich in der Mitte der 3 Bytes eine höhere Zahl sende, klappt es gut, nur bei kleineren funktionierts nicht richtig. Woran kann das nun wieder liegen?? THX Andy
Datum:
Vielleicht sind dem Empfänger zu wenige Pegelwechsel in den Daten. Da müsste eine Manchestercodierung helfen.
Datum:
Der AVR, der das Sendemodul ansteuert läuft jetzt wieder mit 8MHz(interne Clock). Ich habe jetzt einen alten AVR auf externe Clock gestellt und habe den CLK vom Sendemodul genommen so konnte ich die Frequenz des Senders messen. Der Sender läuft nur mit 1 MHz! Bedeutet das dass die InitRoutine schon nicht funktioniert?
Datum:
Matze wrote:
> Bedeutet das dass die InitRoutine schon nicht funktioniert?
Ja.
Datum:
@Andreas: Wenn im Empfangsstream zu wenig Pegelwechsel vorliegen, dann kann der Empfänger den Takt nicht genau genug rekonstruieren. Mögliche Abhilfe: Bit- oder Byte Stuffing. Ich würde erstmal mit Byte Stuffing anfangen, d.h. wenn in einem Byte weniger als z.B. Vier "1"en vorkommen, dann einfach ein Füllbyte "0xAA" hinterher senden. Im Empfänger muß dann das Füllbyte natürlich wieder entfernt werden. Wenn das nicht genügend funktioniert, muß man wohl auf Bit Stuffing umsteigen was aber wesentlich mehr Performance frisst.
Datum:
@Reinhard Max und woran kann das liegen? Bei meinem Versuch ist mir einwas aufgefallen. Ich habe den Test AVR über 2 ca. 10cm lange Kabel (aus einem alten LPT Druckerkabel) mit dem Clocksignal versorgt. Doch der AVR lief nicht an. Erst als ich die Kabel auf ca. 3cm erkürzt habe lief der AVR. Den Sender habe ich mit den gleichen Kabeln am Tiny angeschlossen.Das sieht dann so aus: 3cm Kabel, Steckbuchse, 3cm Kabel (Kabellänge der einzelnen Adern teilweise unterschiedlich lang) Kann das sein dass das eigentlich Problem an den Kabeln liegt? Hab leider mit HF, EMV und co. nicht so viel Erfahrung. Wenn ja wie sollte ich es ändern und auf was muss ich achten?
Datum:
Matze wrote: > Kann das sein dass das eigentlich Problem an den Kabeln liegt? Gut möglich. Ich wollte Dir eh schon vorschlagen die Verbindung zwischen AVR und Funkmodul nochmal zu überprüfen. Wenn die Kabel zu lang sind (und auch noch unterschiedlich lang) kann es durchaus sein, daß am Funkmodul die Signale an der Daten- und Taktleitung so verschliffen sind, daß sie nicht mehr ordentlich erkannt werden. Außerdem fangen die Leitungen sich mit zunehmender Länge (und ohne Abschirmung) leichter Störungen ein.
Datum:
Was für eine Distanz kann man eigentlich ohne Antenne überbrücken mit den Modulen?
Datum:
Mit 15cm Draht am Sender (hab ich fest angelötet, kann ich also nicht einfach abnehmen) komme ich auf 10m Meter störungsfrei bis zum Empfänger ohne Antenne (bzw. eine Kontaktreihe auf dem Steckbrett, macht ca. 1,5cm effektive Länge)
Datum:
Hallo, Wie geht das genau, wenn ich nur etwas empfangen will, wenn der Sender gesendet hat. Kann mir jemand dazu Auskunft geben? THX Andy
Datum:
Angehängte Dateien:Hallo, Hier mal mein USB_Funk Module! Gruß Ulrich
Datum:
Hallo Ulrich, sehr schön gemacht und auch gut dokumentiert (so wie man es von Dir gewohnt ist). Kannst Du mir vielleicht kurz erklären, warum Du MISO mit R4 (welchen Wert hat der eigentlich?) auf 5V ziehst? Hab ich bisher noch nicht gesehen. ciao Michael PS: Der Link auf Deiner Seite auf die Zip-Datei funktioniert nicht.
Datum:
Hallo, Der Widerstand hat den Wert von 10K, ohne diesen gab es bei mir ein Problem mit dem Bus. Der Link auf meiner HP sollte nun auch gehen. Mehr Doku kommt noch! Gruss Ulrich
Datum:
Angehängte Dateien:Hallo Ulrich und Thread, im Anhang mal mein RFM12 USB Stick (Schnellschuss!). Das Ganze passt in ein Hammond Mfg. 1551H Gehäuse 60x35x20mm . Den AVR im Stick kann man per STK500 Protokoll updaten. Auf dem Steckbrett läuft das ganze schon relativ gut. Habe gestern mal einen Reichweiten Test gemacht, konnte damit 4 Stockwerke überbrücken und was mich am meisten beeindruckt hat war die Tatsache das die Kommunikation sogar im Fahrstuhl (faradayscher Käfig) über 3 Stockwerke hinweg funktioniert hat. Sobald ich die Tage Abends mal etwas Zeit finde werde ich mir die Leiterplatten mal Ätzen. Gruß Claude
Datum:
Hallo, So, ich hab jetzt meine Daten Manchester-codiert (wegen des Pegelwechsels). Dann sende ich nach meinen Nutzdaten noch 2 Byte Wirr-Warr hinterher (weil der Empfänger ja 2 Bytes "frisst"), aber es funktioniert immer noch nicht ordentlich. Die Daten kommen an, wie sie wollen. Zweimal kommen sie vollstädnig an, dann wieder 3 mal nicht usw. Was kann da sein? Ich verwende noch die Variante von ganz oben, d.h. ich frage dauernd den Buffer ab, auch wenn nichts gesendet wurde. Liegt darin der Fehler? Bin für jede Hilfe dankbar! THX Andy
Datum:
Verwendest du das Programm von ganz oben, oder diese rf12.c ? http://www.mikrocontroller.net/attachment/23418/rf12.c Die erste Version hatte noch ein paar kleinere Fehler, die bei der neuen Version behoben sein sollten (inklusive dem Verschlucken der 2 Bytes.)
Datum:
Naja, das Problem ist, dass ich Bascom verwende, und ich C nicht so beherrsche! Aber gibt es nicht eine Möglichkeit, dass den Buffer nur auslese, wenn ich auch wirklich etwas gesendet habe??
Datum:
Dazu musst du die Software anpassen: - Empfänger einschalten. - den Status auslesen (FFIT bit) - Nur wenn dieses gesetzt ist, sind Daten im Puffer. Also im Prinzip die Empfangsfunktion zerlegen und die einzelnen Teile in dein Programm einbauen.
Datum:
Das heißt, ich muss trotzdem immer ein Bit auslesen, oder? Oder gibt es vielleicht einen Pin, der den Pegel beim Empfang von Daten ändert??
Datum:
Ja, der FFIT Pin. Aber ob du den einließt, oder den SDO Pin ist eigentlich egal (denn das FFIT Bit wird als erstes am SDO Pin ausgegeben, wenn SDI und nSEL low sind). Daher habe ich mich für die SDO Version entschieden, da man so einen Pin spart.
Datum:
Hallo, danke nun mal für deine Antworten. Ich möchte das ganze gerne mit dem FFIT-Pin lösen. Ich habs nun selbst versucht, aber irgendwie klappt das nicht! Ich komme jetzt nur in die rx-Routine, wenn der FFIT-Pin HIGH wird, aber da sind keine Daten im Buffer. Kannst du mir vielleicht kurz aufzählen, was ich wie aktivieren muss, damit ich meine Daten bekomme? Und was kann ich jetzt von deinem Programm weglassen, weil ich den FFIT-Pin verwende! Wäre echt cool, wenn du mir da weiterhelfen könntest!! Vielen Dank!! mfg Andy
Datum:
Andreas Posch wrote: > Kannst du mir vielleicht kurz aufzählen, was ich wie aktivieren muss, > damit ich meine Daten bekomme? Und was kann ich jetzt von deinem > Programm weglassen, weil ich den FFIT-Pin verwende! - Empfänger einschalten - FIFO Modus Einschalten - FIFO einschalten (Sync Word Erkennung aktivieren) - FFIT Pin abfragen, wenn high Daten empfangen - Wenn Daten empfangen, FIFO ausschalten und Sync Erkennung neu einschalten (das sind diegleichen Befehle wie beim Einschalten des FIFO Modus). Die Befehle dazu finden sich in der rf12.c in der Funktion void rf12_rxdata(unsigned char *data, unsigned char number).
Datum:
Hallo! Ich bin jetzt gerade erst über diesen Thread gestolpert und finde die Thematik höchst interessant. Gibt des noch Bezugsquellen für das RFM12 Modul? Bei pollin gibts nur noch RFM01 und 02. Gruß Björn
Datum:
Hier wird es nächste Woche nochmal eine Sammelbestellung direkt beim Hersteller in China geben: Beitrag "Sammelbestellung RFM12"
Datum:
Hallo Benedikt, Zuerst mal vielen Dank für deine Hilfe!! Ich hab das ganze nun probiert, und es schein auch prinzipiell zu funktionieren. Nur hab ich jetzt das Problem, dass ich nur 2 von 8 Bytes empfange! Der Rest ist 0. Was ist da schon wieder los! Ich weiß, ich bin lässtig, aber ich will das sch... Ding endlich verstehen!! THX... Andy
Datum:
Gibt´s bereits einen Schaltungsvorschlag/Softwarelösung um mit HP03D, FOST02A und RFM12-868-S1 (wenn möglich basierend auf dem Pollin AVR-Board) Wetterdaten aufzunehmen und an eine Master-Station (ebenfalls das Pollin-Board) zu übertragen. Von dort sollen die aufgenommenen Messwerte per Seriell/USB an den PC zur weiteren Auswertung übertragen werden. Am besten Pufferung der Daten in der Master-Station (SRAM?!?), sofern der PC nicht eingeschaltet ist. Gruß, Klaus
Datum:
Sonst noch irgendwelche Wünsche ? Vielleicht fertig aufgebaut frei Haus zugeschickt ?
Datum:
Sicher kannst Du in Deiner Master-Station (Pollin-Board) die Messdaten im SRAM zwischenspeichern... zumindest soviel wie Dein verwendeter Controller RAM (und evtl. noch EEPROM) hat. Da ich davon Ausgehe, dass Du mit dem Pollin-Board das Funk-AVR-Evaluations-Board meinst hat dieses auch keinen Sockel für ein externes EEPROM (im vergleich zum ATMEL Evaluations-Board Version 2.0). Da hier wahrscheinlich noch keiner ein HP03D oder ein FOST02A hat ist diese Anfrage noch was zu früh.
Datum:
BK>Sonst noch irgendwelche Wünsche ? Für den Anfang denke ich sollte das ausreichen, oder fehlt Dir noch etwas? BK>Vielleicht fertig aufgebaut frei Haus zugeschickt ? Nein, das würde ich schon noch gerne selber machen. Wenn´s so etwas noch nicht gibt (hört sich ja danach an), dann werde ich mich mal ans Werk machen und dieses (sofern es von Erfolg gekrönt ist) gerne hier für alle anderen zur Verfügung stellen. Gruß, Klaus
Datum:
Du hast Deine HP03D und FOST02A schon? ;-)
Datum:
Leider hab ich mein Problem immer noch nicht lösen können. Desshalb habe ich mich erstmal um denn Empfänger gekümmert und der lief auf anhieb mit 10MHz. Ganz so blöd kann ich also doch nicht sein. Hat überhaubt schon jemand den rfm02 zum laufen bekommen (mit diesem Code), ich lese hier immer nur vom rfm12 ? Werde jetzt mal einen Mega8 an den Sender hängen, vielleicht klappt es ja mit dem. Dann könnte ich wenigstens von einem Fehlerfreiem Code ausgehen.
Datum:
Ich habs geschafft. Keine Ahnung wo der Fehler war, aber jetzt läuft das System. Den Sender muss ich zwar manchmal 2-3mal anstecken bis er ordentlich anläuft, aber das bekomme ich auch noch hin. Vielleicht sind die Pausen noch zu kurz.
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Marvin, habe Dein Soft-SPI-mega8 in Bascom eingearbeitet. Sollte der rf12 auf senden bleiben,macht er bei mir, oder im Zeitintervall immer wieder auf Senden schalten. wigbert
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Nachtrag
also wenn ich bei ready
> While Spi_sdo = 0 auf 1 ändere sendet er im Sekundentakt
ist das richtig?
Wigbert
Datum:
Hallo zusammen, ich muss mich jetzt auch einmal melden... Gestern hab ich mich nachmittags hingesetzt und die Bibliothek etwas erweitert. Zunächste einmal habe ich die Sende- und Empfangs-Methoden etwas modifiziert.
void rf12_txdata(unsigned char *data, unsigned char number); unsigned char rf12_rxdata(unsigned char *data); |
Beim empfangen von Strings muss man jetzt nicht mehr wissen wie lange das Paket ist. Es können variable Paketlängen bis zu 240Byte übertragen werden. Der Rückgabewert von rf12_rxdata() ist die Länge des Pakets. Zusätzlich sind die Pakete noch mit einem CRC16 gesichert und wurden bereits überprüft und nur richtige Pakete ausgegeben. Dann ein großer Punkt ist das blockieren der Funktionen. In einem eingebetteten (meist echtzeit) System sind solche Funktionen eigentlich unerwünscht. Vorallem wenn einmal ein Paket nicht empfangen wird. Deadlocks sind hier ja schon fast vorprogrammiert. (Dieses Urteil mase ich mir jetzt einfach mal an.) Asynchrones programmieren (mit Interrupts) ist nie verkehrt... Deshalb hab ich die Bib noch etwas erweitert. Mit den defines:
#define RF12_UseBlockingCalls //NEVER USE BOTH #define RF12_UseNoneBlockingCalls //NEVER USE BOTH |
kann man die blockierenden Methoden durch nicht blockierend ersetzten. Das Senden/Empfangen wird dann im Hintergrund abgearbeitet. Allerdings braucht man dazu einen Interrupt Pin. Der Prozessor blockiert jetzt nur noch kurz wenn man Daten an das Modul überträgt, oder anders herum.
// start receiving a package unsigned char rf12_rxstart(void); // readout the package, if one arrived unsigned char rf12_rxfinish(unsigned char *data); // start transmitting a package of size size unsigned char rf12_txstart(unsigned char *data, unsigned char size); // check whether the package is already transmitted unsigned char rf12_txfinished(void); // stop all Rx and Tx operations void rf12_allstop(void); |
Zugegeben ich war irgendwie unfähig einen Hardware SPI zu verwenden. Da hat das Empfangen der Daten irgendwie nie geklappt. Ka Wieso. Aber wenn das wer zum laufen bringt, dann kann man das blockieren noch weiter reduzieren G Vom Prinzip her reicht mir das aber erstmal. Probiert es einfach mal aus. Ich hab 2 Sample Projekte mit dem Kontrollerlab angelegt. Die Bib selber liegt in dem Lbr Verzeichnis und sind in die Projekt Verzeichnise gelinkt. Wenn wer Windoof verwendet dann muss er sie ggf in die passenden Verzeichnise kopieren. Auch interessant ist vielleicht meine
unsigned char UART_Tx_Str(unsigned char *str, unsigned char size); |
Methode, die ist ähnlich nicht blockierend... Man schickt einen beliebigen String über den UART ab und während der String gesendet wird kann man schon etwas anderes tun (mit winzigen Unterbrechungen). Guggs euch an und sag mir was ihr davon haltet, oder wie scheiß ich bin G Sers Jürgen
Datum:
Angehängte Dateien:file vergessen G
Datum:
Angehängte Dateien:Hier noch ein kleines Bugfix. schäm Es gab kleine Probleme beim empfangen wenn die CRC Checksumme nicht gestimmt hat. Ich hab bei der Gelegenheit auch gleich ne Versionsnummer eingeführt, falls andere die Lbr noch weiter entwickeln wollen. 2.0.1 ist der momentane Stand. So far Jürgen
Datum:
Hallo, Ich hatte ja vorhin das Problem, dass ich von 8 gesendeten Bytes nur die ersten 2 empfangen konnte! Ich verwende den FFIT und habe diesen an Int0 meines Mega8 angeschlossen. Immer, wenn ein Interrupt auftritt, führe ich dann die RX-Routine aus! Nun bin ich draufgekommen, dass, wenn ich eine Baudrate unter 2400kbps verwende, am FFIT-Pin mehrere Impulse hintereinander kommen und daher die RX-Routine vom Int0 unterbrochen und nochmals gestartet wird. Und siehe da, die Daten kommen vollständig an! Also stimmt irgenetwas mit meiner Empfangsroutine nicht! Aber was könnte da sein?? Vielen Dank! Andy
Datum:
Andreas Posch wrote: > Ich verwende den FFIT und habe diesen an Int0 meines Mega8 > angeschlossen. Immer, wenn ein Interrupt auftritt, führe ich dann die > RX-Routine aus! Nun bin ich draufgekommen, dass, wenn ich eine Baudrate > unter 2400kbps verwende, am FFIT-Pin mehrere Impulse hintereinander > kommen und daher die RX-Routine vom Int0 unterbrochen und nochmals > gestartet wird. Wie hast du das genau gemacht ? Normalerweise wird ein Interrupt nicht durch einen anderen Interrupt unterbrochen. Das ganze erinnert mich an meine Versuche das ganze Interruptgesteuert zu machen: Es kam nur jedes 2. Byte an.
Datum:
Ich führe einfach folgenden Code in der Interruptroutine aus:
On_int0:
Print "Bin da"
Call Rf12_rxdata(maxchar)
For J = 1 To 6
Print J ; " " ; Rfdata(j)
Next
Return
|
und Rf12_rxdata macht folgendes:
Sub Rf12_rxdata(byval Maxchar As Byte)
For Count = 1 To Maxchar
Rf12_ready
Temp = Rf12_trans(&Hb000)
Temp_byte = Temp
'Wenn Temp_byte gleich 89 ist, Werte in Variable speichern
If Temp_byte = 89 And J = 1 Then
Set Rec_data
Timer1 = 0
Start Timer1
End If
'Laufvariable erhöhen, wenn Empfang freigeschaltet ist
If Rec_data = 1 Then
Rfdata(j) = Temp_byte
Incr J
End If
'Empfang beenden, wenn Temp_byte gleich 85 ist
If Temp_byte = 85 And J = 7 Then
Stop Timer1
Reset Rec_data
Set Got_data
End If
Next Count
Auswertung
Temp = Rf12_trans(&Hca81)
Temp = Rf12_trans(&Hca83)
End Sub
|
Ich weiß, du bist kein "Bascom-Mensch", aber könntest du vielleicht doch einen Blick drauf werfen?? Besten Dank!! Andy
Datum:
Auch wenn ich diese Art der Programmierung als schrecklich betrachte (soviel Code in der Interruptroutine), müsste es aber trotzdem funktionieren. Ich kenne mich mit Bascom überhaupt nicht aus, daher weiß ich nicht, ob während einer Interruptroutine die Interrupts auch aus bleiben, oder ob bascom die Interrupts wieder aktiviert. Letzeres würde den Fehler erklären. Eine bessere Lösung wäre: Einen Empfangspuffer einrichten, in den im Interrupt nur die empfangenen Daten geschrieben werden und ein Bytezähler erhöht wird. Dann noch eine Variable, die anzeigt ob der Empfang vollständig ist.
Datum:
Ich würde vorschlagen, pro Interrupt jeweils nur ein Byte zu empfangen und für das nächste empfangene Byte wieder einen neuen Interrupt generieren zu lassen, ansonsten wird zwar der Start des Empfangs per Interrupt angestoßen aber der eigentliche Empfang des Pakets läuft dann wieder pollend.
Datum:
Danke einaml für deine Antwort, ich werd es mal so probieren. Aber in meiner Empfangsroutine hab ich ja schon so eine Art Buffer. Ich speichere zunächst alles in der Variable Rfdata und wenn der Empfang abgeschlossen ist, werte ich die Daten aus. Nur ist ja das Problem, dass nur die ersten 2 Bytes ankommen. Nur wenn ich während des Empfangs nocheinmal sende, kommen weitere Daten an! Irgendwelche Ideen?? Ich weiß nicht mehr weiter.
Datum:
Int2_int: Disable Int2 Enable Interrupts ....... ...... enable int2 return int musst du ausschalten und enablen die internen int(wurden ausgeschaltet), dann kannste die daten weiter empfangen.
Datum:
Andreas, wie die anderen schon zum Teil bemerkt haben, ist Deine Interrupt-Routine nicht so ganz nach den Regeln der Kunst :-))) Du führst nach dem Einsprung in die Int0-Routine Print "....." aus. Das kann eventuell (wenn das Senden nicht interruptgesteuert ist) viel zu lange dauern. In dieser Zeit läuft Dir eventuell der Empfangs-FIFO des Transceivers über und Du verlierst Zeichen. Im Übrigen wird eigentlich der Empfang jedes einzelnen Bytes durch einen Interrupt signalisiert. Du solltest also nicht nach dem ersten Interrupt versuchen, mehrere Zeichen zu lesen, sondern nur jeweils eins (wie Benedikt schon schrieb). Gruß, Jörg.
Datum:
Mann, bin ich blöd... ich hab die ganze Zeit am nIRQ ausgang gehangen und hab mich gewundert warum das nicht geht ^____^; mit FFIT gehts natürlich. Und zwar genau so wie Benedikt das schon irgendwann mal beschrieben hatte... also: FFIT an INT1
...
Config Int1 = Rising
On Int1 Ffit_handler
Enable Int1
...
Ffit_handler:
' Byte lesen
Temp = Rf12_trans(&Hb000)
Rfdata(count) = Temp
' Momentan einfach feste länge lesen, STX ETX oder sowas ist aber
' hier auch kein problem...
If Count >= Maxchar Then
' Wenn 32 Bytes gelesen wurden, Text ausgeben
For Count = 1 To Maxchar
Print Chr(rfdata(count));
Next Count
' FIFO SYNC Erkennung wieder scharf machen
Temp = Rf12_trans(&Hca81)
Temp = Rf12_trans(&Hca83)
' und von vorne zählen
Count = 1
Else
' ansonsten nur zähler erhöhen
Incr Count
End If
Return
....
|
Ich programmier mir jetzt mal die STX ETX Erkennung mit einem timeout, dann seh ich weiter... @Wigbert: ich hab jetzt mal gerade beim empfänger die abfrage auf spi_sdo=1 geändert... funktioniert auch... wenn er beim sender dann ne sekunde aufhört zu senden, dann wird das wohl richtig sein...
Datum:
@wigbert: wenn ich spi_sdo auf "1" abfrage bleit mein programm stehen...
Hallo Marvin,
ich habe Deinen Soft SPI Code
und deine ready Methode in den Code von Fossy eingebaut.
wenn ich spi_sdo auf 0 lasse.
pendelt das programm nach dem Durchlauf zwischen
>While Spi_sdo = 0
>Wend
wenn es klappt habe ich mein Code beigelegt.
Irgendetwas stimmt bei mir dann nicht
Wigbert
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Nachtrag:
Pinb.4 ist ja wohl als Eingang declariert.
Kann mir mal jemand erklären wann der Spi_sdo Port des RFM12 ein H
Pegel hat.Wenn bei Empfang Daten empfangen werden, oder wann noch?
>Spi_sdo Alias Pinb.4 ' MISO-PIN
Dank Euch
Wigbert
Datum:
@Jörg: Ich habe nun meine Interrupt-Routine so abgeändert, dass ich dort nur eine Bit-Variable setze und dann den Code im Hauptprogramm ausführe. Aber es geht trotzdem nicht! Was mir aufgefallen ist: Wenn ich die Baud-Rate auf 1200 stelle, kommt für jedes Byte ein extra Interrupt; und dann funktioniert die Übertragung auch! Aber wenn ich die Baud-Rate auf 19200 stelle, kommt nur mehr ein Interrupt für alle Bytes! Wahrscheinlich kommen die einzelnen Interrupts dann schon zu schnell, dass nur mehr einer erkannt wird. Und bei 19200 funktionierts nicht! Ich würde gern wissen, was da falsch läuft! THX Andy
Datum:
Andreas, Du solltest in der Interrupt-Routine sofort das Byte aus dem FIFO lesen. Bei 19200 Baud sollte nur ca. alle 500us ein Zeichen ankommen, das sollte eigentlich immer reichen, um das Zeichen schnell genug abzuholen. Hängt aber alles stark von Deiner Programmstruktur ab. Schreib doch mal einfach eine Senderoutine, in der Du jede Sekunde ein Paket mit z.B. 10 Zeichen sendest, vielleicht die Zahlen 1,2,...,10. Im Empfangsprogramm liest Du in der Interrupt-Routine die empfangenen Zeichen in einen Puffer, wie beschrieben jedes einzeln. Wenn Du eine 10 empfangen hast (oder zehn Zeichen), dann setzt Du ein Flag. Im Hauptprogramm wartest Du auf das Flag und schreibst dann den Inhalt des Puffers auf die RS232. So kommen sich die beiden Dinge nicht ins Gehege, da ja das Senden auf der RS232 in die Sendepause des Senders fällt. In der Interruptroutine aber nur die wirklich notwendigen Dinge machen. War doch Bascom, oder? Sollte aber auf jeden Fall schnell genug sein. Gruß, Jörg.
Datum:
also bei mir funktioniert das byteweise lesen über interrupt mit 19.200 baud mit einiger logik in der interruptroutine (STX/ETX+CRC8)
Autor:
Hauke Radtki
(lafkaschar)
Datum:
Ich hab mich noch nicht komplett mit den Modulen beschäftingt, da meine noch nicht da sind aber so wie ich das verstanden habe haben die Module einen Fifo. Und für Jedes ankommende Byte wird ein Interrupt erzeugt. Dann würde ich, solange die Main nicht so lang ist, dass der Fifo überlaufen kann in der maximalen zeit bis zur Bearbeitung, in jedem Interrupt eine Variable hochzählen, die anzeigt, wieviele Bytes noch gelesen werden müssen. Wenn du dann ein Byte ausliest, ziehst du wieder eins von dieser Variable ab. Wenn sie 0 ist brauchst du natürlich auch nichts zu lesen.
Datum:
Hauke Radtki wrote: > aber so wie ich das verstanden habe haben die Module einen Fifo. Ja, der ist aber nur 16 Bit (also 2 Byte) lang. Man muß also jedes empfangene Byte aus dem FIFO holen, bevor das nächste komplett ist, sost läuft der FIFO über. > Und für Jedes ankommende Byte wird ein Interrupt erzeugt. Nein, ein Interrupt wird immer dann erzeugt, wenn der FIFO den bei der Initialisierung eingestellten Füllstand erreicht hat. Wird er dann nicht geleert, gibt es den nächsten Interrupt erst wieder wenn er übergelaufen ist, was dann bedeutet, daß man Daten verloren hat.
Datum:
Hallo, Ich lese nun jedes Byte einzeln ein und siehe da: Es funktioniert bei jeder Baud-Rate! An dieser Stelle mal danke an alle, die mir geholfen haben! Einen Fehler hab ich aber noch! Beim ersten Senden nach dem Einschalten funktionerts nicht. Es wird nur bei ersten Byte ein Interrupt ausgelöst. Bei den folgenden nicht! Sende ich dann nocheinmal haut es hin! Was könnte da noch sein? Hab schon einiges durchprobiert - komm aber nicht dahinter! THX Andy
Datum:
Danke, hat sich erledigt! Beim ersten Einschalten habe ich den FIFO doppelt initialisiert! Andy
Datum:
Hi Andy, würdest du den funktionierenden Code hier veröffentlichen?
Datum:
Ja, der funktionierende BSACOM-Code würde mich auch interessieren! Danke! Malte
Datum:
Schon gesehen? USB RF Funkmodul mit ATmega8: http://www.ulrichradig.de/home/index.php/avr/usb-funk
Datum:
Joo, war in diesem Thread (am 23.05.) schon da und hat seine Platine vorgestellt. Einfach nach oben scrollen... ;-) Gruß Elektrikser
Datum:
Hallo! Habe mittlerweile eine Funkstrecke zwischen zwei RFM12, die jeweils an einem PIC16F876 hängen, aufgebaut. Habe den Code von Benedikt auf den PIC umgelegt. Beide Module können senden! (Mittels TV Karte getestet) Leider kann keines der beiden empfangen. Die Module bleiben in RX_Data in rfm12_ready hängen. Habe mittlerweile anstatt nur auf SDO zu warten, den ganzen Status ausgelesen. Habe dann auch noch den Sender aus und eingeschalten. Folgendes Ergebnis: Der einzige Unterschied zwischen eingeschaltenem und ausgeschaltenem Sender ist, dass sich das 8 Bit (RSSI) von high auf low ändert. Das ffit und das ffem (Fifo Empty) änder sich nicht. Bitte um Hilfe. Danke schon im Voraus! mfg Martin
Autor:
Marius S.
(lupin)
Datum:
das würde mich ja mal interessieren wiedu das mit der TV Karte testest
Datum:
Stelle bei meiner TV-Karte die Frequenz ein und hänge die Antenne an den Antenneingang. Wenn der Sender dann Daten sendet, kann man dies anhand der Rauschimpulse im Ton genau hören. mfg Martin
Datum:
Junge Junge, lebst mit deiner TV Karte aber ganz schön gefährlich Jürgen PS: Keiner was zu sagen zu meiner Erweiterung der Lib (siehe oben)? Hat die überhaupt schon mal wer getestet?!
Datum:
@ Jürgen Sobald ich meine Hardware neu aufgebaut habe werde ich deine Lib mal testen. Der erste Versuch mit meiner Hardware ist gescheitert , der von mir eingesetzte FTDI FT232R ist für meine Anwendung zu "langsam" (Latenz). Wie weit bist Du denn mit der Hardware SPI gekommen?
Datum:
Hallo, Mein Bascom-Code funktioniert doch noch nicht so einwandfrei, wie ich mir das gedacht hatte. Beide, der Empfänger und der Sender, stürzen in regelmäßigen Abständen ab. Der Empfänger empfängt dann einfach nichts mehr. Zumindest kommen keine Impulse mehr aus dem FFIT-Pin. Ich habe aber auch schon mal beobachtet, dass dann dauernd Impulse am Pin anliegen und der Empfänger ebenfalls nicht mehr reagiert. Ist aber erst 1-2mal vorgekommen. Und der Sender resetet sich einfach. Beide Abstürze kommen ziemlich gleichzeitig, d.h. in gleichen Abständen vor. Hat irgendwer eine Idee, was da sein könnte? Vielleicht falsche Einstellungen bei hw- und swstack? Hab mich damit schon gespielt - kommt aber nix brauchbares raus! Vielleicht kann mir irgendwer weiterhelfen! THX Andy
Datum:
@Claude naja also das Senden ging einwandfrei. (Getriggert über nIRQ) aber empfangen habe ich immer nur mist bzw: 0xFF. Ka wieso. Momentan geht aber die Uni wieder vor und ich habe momentan keinen wirklichen Verwendungszweck für die Teile, deshalb lass ich es etwas schleifen... Eigentlich wollte ich einen ultra leicht empfänger für Flugmodelle damit bauen, aaaaber die Reichweite (die im Datenblatt mit 150m angegeben wurde) ist mir dann doch eteas zu gering... Auch wenn ich schon eine Platine anfertigen hab lassen, die mit ATmega48 und Pinout (also Prog Anschluss + 4 Servos) nur 19x19mm hat.... Jürgen
Datum:
Wieso meinst du dass ich mit meiner TV Karte gefährlich lebe? Hat vielleicht jemand eine Lösung für mein Problem? mfg Martin
Datum:
Naja weil du wenn du direkt in deine TV karte rein gehst, sehr leicht zu Leistung auf den Eingang legen kannst und ihn dadurch kaput machen kannst.
Datum:
Is sowieso ein uraltes Ding und wird ohnehin nicht mehr verwendet. Reicht aber um festzustellen, ob der Sender funktioniert. Martin
Datum:
> Is sowieso ein uraltes Ding und wird ohnehin nicht mehr verwendet. > Reicht aber um festzustellen, ob der Sender funktioniert. ... dazu reicht auch ein 16..17cm langes Stück Draht am Sender und eine Zimmerantenne oder ein weiteres Drahtstück an der TV-Karte. Damit kannst Du den Sender testen, ohne gleich die Karte aufs Spiel zu setzen.
Datum:
Wo du recht hast, hast du recht!*g* War mir der Gefahr nicht bewusst. Martin
Datum:
Angehängte Dateien:Hallo, Habe den RFM12 nun auch über den SPI Bus angeschlossen! Die Senderoutine habe ich schon getestet. Gruss Ulrich
Datum:
Ja gut so weit war ich auch schon. Nur das ich eben den SPI mit voller Geschwindigkeit laufen hab lassen. Nur ging dann das Empfangen nicht mehr. Und ich hatte das warten dann über den nIRQ bin gelöst. Wieso hast du eigentlich meine Async routinen weg gemacht?! Ist doch wesentlich besser wenn der CPU nicht blockiert oder?! Ahm als CRC Start Polynom hab ich jetzt einfach die 0x0000 genommen. Ich denke wenn man da ein anderes nimmt kann man Fehler besser dedektieren, das muss ich mal nachlesen... Jürgen
Autor:
Marius S.
(lupin)
Datum:
Jürgen: Eine Funkfernsteuerung für Modellflieger würde ich lieber auf 27 MHz machen (das ist die "Spielzeugfrequenz"...) Aber dafür gibt es glaube ich keine Fertigmodule. Gibt es überhaupt TX/RX Module für Modellfunk? Also nur rein zur Signalübertragung, keine Aufbereitung etc.
Datum:
Naja also die Flugfrequenzen sind 35 bzw 40Mhz. Aber gut da is die Reichweite halt mal >500m. Deswegen hab ichs auch sein lassen. Mich hat halt nur das Gewicht und die Größe interessiert und das ich dann am Modell alles selber gemacht hätte.... Aber gut ich hab eh ned so viel Zeit G
Autor:
Ulrich Radig
(radiguli)
Datum:
Hallo, Also habe nun das Senden und Empfangen von Daten getestet, funktionieren mit einen Mega8, Mega88 und Mega32. Mal sehen was passiert wenn man den SPI-Bus höher taktet. Ich werde auch bald eine Interruptroutine benutzen, ist besser als Polling, habe auch noch irgendwo schon einen fertigen Ringbuffer für Senden und Empfangen herumliegen. Gruss Ulrich
Autor:
Ulrich Radig
(radiguli)
Datum:
Hallo@Marius Schmidt Natürlich gibt es nur Sendemodule für 27 und 35MHZ Band z.B. hatte ich mal eins von Graupner habe dann mit einen Mega88 das RC SummenSignal erzeugt und auf den Sender gegeben. Den SourceCode dafür habe ich sogar auf meiner HP. Für den Empfang baue ich mir immer die Module um. Gruss Ulrich
Datum:
Moins, bin auch gerade am Spielen mit den RFM12. Eigentlich wollte ich damit eine RS232-Verbindung verlängern, muß nun aber in diesem Thread betroffen zur Kenntnis nehmen, daß die Module nicht gleichzeitig senden und empfangen können. Gibt es noch Hoffnung (hab ich vielleicht was falsch verstanden)? Die Funkverbindung soll transparent für die jeweilige Applikation sein, d.h. wenn die Anwendung eine full-duplex-Verbindung erwartet, muß die Funkstrecke das realisieren. Hat hier jemand eine gute Idee, ob sowas mit den RFM12 prinzipiell überhaupt zu realisieren wäre? Wie schnell kann so ein RFM12 zwischen den Betriebsarten Senden und Empfangen umschalten? Würden sich zwei Funkstrecken mit RFM01 und RFM02 gegenseitig ins Gehege kommen? Fragen über Fragen... Gruß Horst
Datum:
Ulrich: Ich hab's mir noch nicht angeschaut, aber warum überträgt man mit diesen RC Summensignal? Kann man nicht rein digital bitweise übertragen und das dann wieder beim Empfänger umsetzen?
Hallo@all, Hier die komplette Zusammenfassung des SourceCodes. Gruss Ulrich
Datum:
@ Horst Meier Du hast 2 Möglichkeiten: 1) Du sagst das das eine 38k4 oder 56k6 Verbindung ist und läßt die Funkstrecke selbst mit 115k2 laufen (also mindestens doppelt so schnell wie die Kabel Verbindung). Oder 2) Du nimmer 2 Einheite pro Seite und gibt ihnen nicht gegenseitig stöhrende Sende/Empfangs Freq. Also z.B. das eine Paar 500kHz mehr als dem anderen. Hmm oder 3) Du arbeitest mit Handschaking und/oder mit einem Buffer der groß genug ist. Jürgen
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Leute, Ich lese mit meinen Bascomcode über ein Interrupt meine RXD-Strings ein.Soweit so gut.Kann also mit ein Terminalprogramm mein Text von rf12 zu rf12 senden. Jetzt soll jeder rf12 mit Empfang starten,nach übertragen der Strings zum Controller (m8) auf Senden umschalten. Benötigt der rf12 zum umschalten Empfang-Senden ein Reset,oder wie macht Ihr das generell. Wigbert
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Avr Nix, das Problem ist ,glaub ich das bei Empfang die Schleife nicht beendet wird.Er wartet das ein Pin H wird.Wollte mal wissen ob das warten zeitlich begrenzt wird, oder Reset oder ? Wigbert
Autor:
Avr Nix
(avrnix)
Datum:
Wenn ein Reset geben soll - vielleicht den Watchdog einschalten wird der nicht immerhalb von max 2sek zurückgesetzt wird ein REset gemacht. Oder die lässt einen Zähler hochlaufen bis er einen Wert hat und springst dann raus. Ich hoffe ich habe dich richtig verstanden.
hi bin auch gerade an den RFM12 Modulen. Habe das gleiche Problem wie schon andere beschrieben haben. Senden scheint zu funktionieren, nur empfangen nicht. Auch bei mir bleibt die Empfängerseite in der Funktion rf12_ready() hängen. Den Sender konnte ich heute ein wenig in der Uni testen (OSZI). Der Sender schaltet den CLK auf 10Mhz um und wenn ich die Messspitze an die Antenne halte sieht es wie im Bild zu sehen aus. Wie geht ihr bei testen vor?
Datum:
hab ich ganz vergessen; kann mir jemand erklären was ich da auf dem Oszi sehe?
Datum:
Ich benutze eine TV Karte mit 17cm Draht als Antenne. Das Signal kann man wunderbar auf Kanal S37 (+/- Finetuning) Empfangen und die Daten hört man im Tonkanal. Was Du da mit dem Oszi beobachtest ist wahrscheinlich ein einschwingen der HF Sendestufe des Moduls, schaut bei mir genauso aus. Mit einem normalen Oszi ( alles kleiner 5GSPs ;-) ) wirst du nichts am Antennenausgang des Moduls sehen können. Das die Empfängerseite im rf_ready() hängen bleibt ist normal solange keine Daten eintreffen. Gibt hier im Thread schon ein paar Lösungen dafür.
Datum:
Hallo Benedikt, hallo alle ich bin erst kurz mit den RFM01 und RFM02 beschäftigt und weiß nicht, wo der Fehler in meiner Konfiguration ist. Wie ich hier gelesen habe, ist in den Dokumentationen und Beispielprogrammen von Pollin diverse Fehler. Da ich C nicht kann und in Assembler einen PIC programmiere, ist es mir noch nicht gelungen eine Verbindung zwischen den Modulen aufzubauen. Deshalb wäre es toll, wenn jemand die Minimalst-Konfiguration eines laufenden "Duos" aus RFM01 und RFM02 posten würde, nicht als C-Code, sondern nur die Adressen und Hexwerte für Sender und Empfänger. Vielen Dank Kalli
Autor:
Marius S.
(lupin)
Datum:
Claude: Versuch doch mal Sound abspielen zu lassen, das wär doch mal was :)
Datum:
Angehängte Dateien:so klingt es wenn ich meine TV-karte auf 433,93MHz stelle. Viel rauschen und im Sekundentakt ein klicken oder piepen. Mein Sender sendet also. Mit dem empfang bin ich auch noch nicht weiter. Ich wollte es eigentlich vermeiden noch extra die Interruptleitung zu verwenden. Habt ihr noch andere änderungen vorgenommen? Also ich habe jetzt - rf12.c aus dem erten beitrag - in der rf12_ready() nop's eingefügt und den timeout von JBecker - in der main() die Warteschleife verkürzt; Bringt es was, wenn ich die Baudrate verkleiner? Hat der Kontroller eingentlich ein Register das ich nur auslesen kann, Revisionsnummer oder so? Vieleicht ist ja mein SDO im A**.
Datum:
Hallo alle hier noch einmal meine Bitte, die Minimalst-Konfiguration eines laufenden "Duos" aus RFM01 und RFM02 zu posten, nicht als C-Code, sondern nur die Adressen der benötigten Register und Hexwerte für Sender und Empfänger. Ich habe es jetzt geschafft, das Statusregister auszulesen. Es wechselt zwischen 0x0F30 und 0x0FC0, Daten im FIFO alles 0. Hilft das bei der Fehlersuche? Danke und ein schönes Wochenende Kalli
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Leute, habe Marvin seine Interrupt-Empfangscode (Ffit an Int1) eingebaut. Emfange aber nur das 1.Zeichen und noch irgendeins. Hardwaremässig sollte dann alles ok sein. Versaut mir das Print das Zeitfenster? und wo bleibt rf12_ready Wigbert
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Leute, selbstverständlich funktioniert Marvin sein Interrupt-Code Man muss ihn nur richtig einbauen. schäm. Enable Interrupts 'Interrupts global zulassen sollte nicht fehlen. Wigbert
Datum:
Hallo alle Ich kriege die Verbindung der Module einfach nicht hin. Deshalb stelle stelle hier mal meine Sende und Empangsroutine ein, mit der Bitte mal rüber zu sehen, was an der Konfiguration nicht passt. Original-Listings im Anhang Empfänger: nSEL=1 ; Grundzustand der Selekt-Leitung SCK=0 ; Grundzustand der Clock -Leitung nSEL=0 ; Modul selektieren Initialisieren: C2E0 CLK: 10MHz C42B Data Filter: internal CE88 FIFO mode C6F7 AFC settings: autotuning: -10kHz...+7,5kHz E000 disable wakeuptimer CC00 disable low duty cycle A640 set freqenz C823 baudrate 898A Bandbreite C0C1 RX on CE89 FIFO CE8B enable FIFO Statusregister und FIFO auslesen: SEL=1 ; Grundzustand der Selekt-Leitung SDI=0 ; Datenleitung auf Lo nSEL=0 ; Modul selektieren 16 mal SCK auf High und wieder auf Lo setzen für Statusregister aus SDO lesen 8 mal SCK auf High und wieder auf Lo setzen für FIFO aus SDO lesen Sender: nSEL=1 ; Grundzustand der Selekt-Leitung SCK=0 ; Grundzustand der Clock -Leitung nSEL=0 ; Modul selektieren Initialisieren an SDI: CC00 ? was macht das? 8B61 Config. Setting commands (CLK - Pin - Frequenz, ...) A640 Semdefrequenz D040 ???? C823 Baudrate C220 enable TX, ... C038 Power - Amp., Disable CLK-Pin, ... 4 mal 0xAA (preamble) an FSK Frame 0x2DD4 an FSK Daten zum Senden an FSK schicken Beim übertragen der Daten an SDI habe ich eine Warteschleife eingebaut, beim übertragen an FSK frage ich den IRQ - Pin ab.
Datum:
Hallo, Ich hab da wieder mal eine Frage! Und zwar will ich das RFM12 als Sender und Empfänger nutzen. Und zwar soll das Modul etwas senden und dann in den Empfangsmodus wechseln. Aber wann und wie schalte ich auf Empfänger um? Ich habe einmal probiert, gleich nach dem Senden mit: Temp = Rf12_trans(&H82c8) Temp = Rf12_trans(&Hca81) Temp = Rf12_trans(&Hca83) auf Empfang zu schalten, aber das hat nicht so recht funktioniert! Wie stelle ich das richtig an?? THX... Andy
Autor:
Manuel Stahl
(thymythos)
Datum:
Hab jetzt auch zwei RFM12 + ATmega8 am laufen. Software ist die von Jürgen Eckert. Könnten alle, die an der Firmware weiterentwickeln bitte jeweils die aktuellste Version hier verlinken: http://www.mikrocontroller.net/articles/AVR_RMF12#Software Dann muss man nicht immer den ganzen Thread durchsuchen.
Datum:
Ulrich hat das Lbr noch etwas erweiter. (Hardware SPI) Das sollte auch noch mit rein. Jürgen
Datum:
verlinkung vielleicht lieber auf den beitrag, als auf das attachment. mit datum ist aussagekräftiger..
Hallo, Da ich noch einen Fehler hatte hier der aktuelle Source von mir. Gruss Ulrich
Datum:
@Ulrich Radig, in rf12_init() verstehe ich was nicht. Was bringt SPSR &= ~(0<<SPI2X); ??? Denn ~(0<<SPI2X) == ~(0) == 0xFF, und var & 0xFF ändert nichts. Gruß Werner
Autor:
Ulrich Radig
(radiguli)
Datum:
hallo, Sollte SPSR &=~(1<<SPI2X) sein. Da aber das SPSR Register sowieso 0x00 nach dem einschalten ist ist die Zeile auch überflüssig. Gruss Ulrich
Datum:
Hallo zusammen, Also ich hab ja jetzt alles zusammen. Das Pollin Evaluations-Board und den RFM12. Die hier herunterladbaren Bascom-Beispiele laufen nicht darauf. (So wird nirgends PortD.4 eingeschaltet (und das RFM12 bekommt so auch keinen "Saft") Bevor ich jetzt das Rad komplett neu erfinde: Hat jemand einen laufenden Code für das Evaluations-Board? (Mir reicht ja schon ein einfaches Beispiel, das nur sendet.) Pollin hat da ja leider gar nix parat... Wolfgang
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Wolfgang, der Code von Bastelbär(blätter mal hoch)funktioniert. Wobei bei dem Pollinboard gibt es mit den Optokoppler probleme. Ich hab Ihn durch eine Brücke ersetzt.Würde mal Deine Erfahrung dazu gerne lesen. http://www.roboternetz.de/phpBB2/viewtopic.php?t=30824 Wigbert
Autor:
Ulrich Radig
(radiguli)
Datum:
Hallo, Mit dem Optokoppler hatte ich die gleichen Probleme. Spannung am RM12 Module brach zusammen. Habe dann den Optokoppler durch einen Jumperbrücke ausgetauscht. Gruss Ulrich
Datum:
@wigbert, @radiguli Vielen Dank, da werde ich mir wohl heute Abend auch nen Jumper einbasteln. Mal schauen ob ich heute noch dazu komme. Melde mich auf jeden Fall mit dem Ergebnis! Schöne Woche Wolfgang
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Angehängte Dateien:-
PICT0158.JPG
123,4 KB, 2594 Downloads
Hallo Wolfgang, bitte bei den o.g.Code den 10KOhm Pullup-Widerstand nicht vergessen. Sonst bleibt die Schleife stehen. Ich hab den einfach auf die richtigen Pins eines freien Controller- sockels gesteckt. Wigbert
Datum:
Hi, also meine Abänderungen betreffen das Pollin-Board. In den Routinen sind die notwendigen Pullups und Optokoppleranschaltungen bereits drin. (c) by Benedikt! (danke dafür) An den Bitsetzungen fürs SPI habe ich auch etwas verändert. Schaut einfach mal rein, senden tut das Teil prima. Led 1 dient der Anzeige ob das Device bereit ist. Led 2 blinkt beim senden DAmit das Teil auch was sendet müsst ihr den Taster gedrückt halten. Ein anderer wichtiger Punkt. Ich habe den Optokoppler nun entfernt, da ich den AVR mit dem Takt des RM12 takte. Und das Ding kann keinen Optokoppler anschalten wenn noch kein Takt anliegt. Deshalb eine Brücke einlöten wenn ihr den externen Takt verwenden wollt.
Datum:
@Wigbert: Mach den Pullup doch einfach im Atmel an. Geht schneller...
Datum:
Angehängte Dateien:so, jetzt aber
Datum:
Noch ein wichtiger Nachtrag: Die Spannungsversorgung für das RFM12 muss wirklich sehr sauber sein. Ich hatte auf meinem Empfangsboard (Breedboard mit Mega8) riesige Probleme damit. Mit angeschlossenem Programmer (mit 5V-Versorgung per USB) lief der Empfang problemlos. Mit meinem "üblichen" Netzteil ging zwar der Mega8 und alles andere, jedoch kam nichts an: Der RFM12 war einfach tot! Kaum hatte ich das Netzteil gewechselt ging alles prima.
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Lorenz,
>Mach den Pullup doch einfach im Atmel an. Geht schneller...
vielleicht wird der Pin irgendwann gebraucht, und dann musst Du doch
externen Pullup-Widerstand nehmen.Vielleicht war mir auch 10K
lieber als ein Port.
Hauptsache der Pullup wird bedacht.
Wigbert
Datum:
Hallo Wigbert, Ich verwende den ATMEGA32. Der Optokoppler scheint sogar damit zu funktionieren. Egal, jetzt ist er raus und noch immer geht nix. Ich nun aber das Problem, dass der Pullupwiderstand nicht nur den RFM12 nach Plus ziehen will auch der PIN B.3 vom ATMega32 liegt da. Bevor ich jetzt den Mega32 zerschieße: Ich hab auch nen ATMega8 hier. Ich denke, ich sollte es erst einmal mit dem probieren. Du hast das ja damit zum Laufen gebracht. Kann ich dein Programm bekommen? (Ein brauchbares Übertragungsprotokoll hab ich dann schon fast fertig. Ist noch von nem früheren Projekt... Auch mit Funk... aber mehr amateurfunklastig :-) Mir schwebt da so eine Routinglösung vor, wie beim THENET-Protokoll in Packet Radio. Kurz: Wenn viele solche RFM12-Knoten da sind, und einer hört nicht, sollen die anderen Router spielen. Sollte grad noch so in nen ATMega8 passen...)
Hallo Wolfgang, mach ich doch glatt. Der Code ist so frisch, das Du die Druckerschwärze noch riechen müsstest. -für m8 -10K auf m32 Sockel Pin4(PB3) ,Pin10(VCC) -wurde gerade auf mein Pollinboard nochmals getestet -Dein Quarz reinschreiben !!!!!! (9216000 steht drin) -linke LED muss im Sekundentakt blinken -Sendet im Sekundentakt. - wenn Du den Code auf Empfang umstellst, wait 1 raus. !!!!! Wigbert
Datum:
@wigbert Es lebt, es lebt! Im Sekundentakt kommen herrliche Bursts über den Empfänger. Selbst OHNE Antenne kann ich eine Signalstärke von über 60dB messen. Jetzt wird es Zeit, die zweite Patine aufzubauen! Leider ist unter der Woche nicht soo viel Zeit. Wolfgang P.S.: Es ist schon irre, was auf der Frequenz 433.920Mhz in unserer Kleinstadt so alles sendet. Da ist keine Sekunde Ruhe!
Autor:
Wigbert Picht-dl1atw
(wigbert)
Datum:
Hallo Wolfgang,
>Es lebt, es lebt!
na ja so leicht kann man Leute glücklich machen.
Wir hätten zu gern gewusst warum der m32 nicht "lebt"
Wigbert
Datum:
Warum der ATMega32 Schwierigkeiten macht? Ich hab jetzt nicht intensiv nachgeschaut, aber der PinB.3 scheint da die Schlüsselrolle zu spielen...evtl. müsste der FSK/DATA/nFFS abgetrennt und via 10 kOhm an Plus gelegt werden... Oder anders herum gesagt: Das Board ist ja ganz nett... aber nicht so gut durchdacht... Naja zum Testen geht der ATMega8 auch sehr gut und wenn da alles ausprobiert ist folgt eh eine eigene (und viel kleinere) Platine ;-) Gruß Wolfgang
Datum:
Hallo, also mein Code läuft auf einem MEGA 32. Keine Ahnung was bei euch Probleme macht. Aber das Pollin-Board ist wirklich nicht sehr durchdacht.
Datum:
Angehängte Dateien:Moin Leutz, es ist vollbracht! Wie ich weiter oben bereits angedeutet habe, wollte ich mit den RFM12 eine drahtlose Duplex-RS232-Verbindung realisieren und hatte dazu einige Fragen. Mittlerweile habe ich eine - erstaunlich gut - funktionierende Lösung. Die Hardware ist recht übersichtlich konstruiert (im Wesentlichen RFM12, ATtiny2313 und MAX3232 sowie einige Status-LEDs) und läuft bereits ab deutlich unter 3V Betriebsspannung (angepeilt ist eine Versorgung durch eine Lithiumzelle CR123A). Der Mikrocontroller wird vom RFM12 mit 10 MHz getaktet (Fusebits auf externe Taktquelle setzen). Die Firmware realisiert eine anwendungstransparente "not-that-full-duplex transmission", d.h. wenn die eine Übertragungsrichtung vollkommen ausgelastet wird, kann in der entgegengesetzten Richtung u.U. nicht die gesamte Bandbreite der seriellen Schnittstelle genutzt werden (für Bursts stehen sende- und empfangsseitig je 57 Byte Pufferspeicher zur Verfügung). Für den typischen Anwendungsfall einer Dateiübertragung via X/Y/Z-Modem oder Kermit ist dies jedoch völlig ausreichend. Die Bitrate der seriellen Schnittstelle kann bis hinauf zu 115,2 kbit/s konfiguriert werden, auf der Funkseite sind ebenfalls max. 115 kbit/s möglich. Mit einem Trick (Aktivierung des Paritätsbits auf der seriellen Schnittstelle, um eine Bitzeit mehr "Luft" zu gewinnen) konnte ich dabei mit Kermit oder ZModem Übertragungsraten von bis zu 9,5 KByte/s erzielen. Allerdings wird die Übertragung über mehr als einige Meter bei dieser Geschwindigkeit bereits recht unzuverlässig. Eine ein oder zwei Stufen geringere Funkdatenrate und dementsprechende serielle Bitrate von 57,6 kbits/s konnte ich aber problemlos in meiner gesamten Wohnung ausnutzen. Die Firmware stellt im Bedarfsfall auch eine fehlertolerante Übertragung via (8,4)-Hamming-Code (mit entsprechender Reduzierung des Durchsatzes) zur Verfügung. Eine Verschlüsselung der übertragenen Daten oder eine Adressierung mehrerer Adapter ist nicht realisiert, auch eine gesicherte Übertragung (mit CRC, Sendewiederholung etc.) ist nicht implementiert. Die Konfiguration der Parameter erfolgt über ein einfaches Terminalinterface, das mit nahezu jedem Terminalprogramm bedient werden kann. Wird beim Einschalten des Adapters der Pin 9 (Port D.5) des ATtiny über eine Taste auf L gezogen, wird der Konfigurationsmodus gestartet. Nach dem Senden eines Leerzeichens (0x20) zur Messung der Bitrate der seriellen Schnittstelle erscheint dann das Hauptmenü: Serial Bridge V0.1 1-Serial Bitrate 2-Serial Interface Settings 3-Radio Data Rate 4-Base Frequency 5-FSK Range 6-Receiver Bandwidth 7-Output Power Setting 8-DQD Threshold 9-Protection Navigiert wird mit den Ziffern 0...9, wobei man mit 0 immer wieder zurück in das Hauptmenü gelangt. In den Untermenüs kann mit den Ziffern 1 bis max. 9 der gewünschte Parameter gesetzt werden. Im "Protection"-Untermenü wird die oben angesprochene fehlertolerante Hamming-Übertragung aktiviert. Alle Einstellungen werden natürlich im EEPROM des ATtiny gespeichert. Die Beschaltung des ATtiny2313: Pin 2: RxD - vom MAX 3232 Pin 3: TxD / Pin 5: CLK vom RFM12 Pin 6: LED1 (grün) Pin 7: LED2 (gelb) Pin 8: LED3 (rot) Pin 9: Taste Pin 10: Vss Pin 11: nRES - Pin 12: SDI \ \ Pin 13: SDO vom RFM12 Pin 14: SCk Pin 15: nSEL - Pin 20: Vdd Am RFM12 ist der Anschluß FSK/DATA/nFFS über einige kOhm auf H-Pegel zu legen. Als Antenne wird ein Stück Draht (idealerweise ca. 17 cm lang) verwendet. Der MAX3232 ist nach Datenblatt beschaltet. Es hat sich gezeigt, daß durch die Spannungsverdoppler- und -inverterschaltung des MAX3232 relativ starke Störungen (Oberwellen) auf den Betriebsspannungsanschluß eingekoppelt werden, die den Empfang des RFM12 deutlich beeinträchtigen (beim MAX232 ist mir das nicht aufgefallen). Eine 150uH-Drossel zwischen Pin 16 des MAX3232 und der restlichen Betriebsspannungsversorgung schafft Abhilfe. Die Betriebsspannung ist mit 100nF Keramik und einigen 100uF Elektrolyt gepuffert. Die gesamte Schaltung habe ich auf 4x4cm Lochraster untergebracht. Die Funktionen der LEDs: Beim Einschalten leuchtet zunächst kurz LED1, danach gemeinsam kurz LED2 und LED3. Wurde die Taste gedrückt, verlöschen alle LEDs und der Konfigurationsmodus wird aktiviert, anderenfalls versucht der Adapter den Kontakt zu seinem Partner aufzunehmen. Kann keine Verbindung hergestellt werden, blinkt LED1 deutlich wahrnehmbar. Wurde die Verbindung aktiviert, blinkt LED1 ebenfalls, allerdings so schnell (im Rhythmus der Kommunikation der beiden Adapter miteinander), daß sich ein kontinuierliches Leuchten der LED1 ergibt (etwas dunkler als Dauerlicht). Leuchtet LED1 gar nicht oder mit voller Helligkeit, dann hat sich irgend etwas aufgehängt und der Adapter sollte zurückgesetzt werden. Die LED2 signalisiert, daß beim Empfang ein korrigierbarer Hammingfehler (Einbitfehler) festgestellt wurde. Die LED3 signalisiert, daß beim Empfang ein nicht korrigierbarer Hammingfehler (Zwei- oder Mehrbitfehler) festgestellt wurde. LED2 und LED3 leuchten im Fehlerfall ca. 1,5 Sekunden und können zur Beurteilung der Verbindungsqualität verwendet werden. Als Übertragungsverfahren habe ich mir folgendes einfallen lassen: 0x2D---0xD4---LI---[Nutzdaten]---0xAA---0xAA Nach dem Synchronwort 0x2DD4 wird ein Längenindikator (8 Bit) übertragen. Dieser Längenindikator ist immer (8,4)-hammingcodiert. Sind keine Nutzdaten zu übertragen, der Längenindikator also 0, werden direkt zwei Füllbytes 0xAA angehängt (ansonsten folgt nun die Payload - je nach Konfiguration "nackt" oder hammingcodiert - und am Ende wieder die zwei Füllbytes) und danach in den Empfangsmodus gewechselt. Der empfangende Adapter wechselt dann seinerseits in den Sendemodus und so fort. Es findet also ein fortwährendes Handshaking beider Adapter statt. Dies erlaubt es, die über die serielle Schnittstelle eintreffenden Nutzdaten nahezu verzögerungsfrei zum Gegenüber zu übertragen. Empfängt der Adapter innerhalb einer gewissen Zeit nichts, wechselt er wieder in den Sendemodus; dadurch ergibt sich dann das Blinken der LED1. Ich habe während der Tests etliche MBytes übertragen und kann nur immer wieder mein Erstaunen über die Zuverlässigkeit auch bei höheren Bitraten zum Ausdruck bringen. Vielleicht kann der Eine oder Andere auch etwas mit meiner Lösung anfangen oder eventuell diese oder jene Routine gebrauchen. Gruß Horst
Hallo, habe mal für alle "Erstanwender" des RFM12 mein TV-Messempfänger in 1m Entfernung mit ca 17cm Drahtantenne positioniert. Bei Verwendung meines o.g. Codes sollte folgendes passieren. (wer die Frequenz micht einstellen kann, Kanal 37 ) Beim Senden wird das Bild dunkel bzw der Schnee sollte weg sein und das Rauschen ist nicht mehr zu hören (kurzzeitig da nur kurz auf Senden) und das im Sekundentakt. Gemessen hab ich ein Pegel von knapp 81 bBµV.(obige Ant.+ Entfernung) Wobei ich der Meinung bin, das der Pegel zu 433,6 Mhz etwas ansteigt. Wigbert
Datum:
Hallo ins Forum, wie ich sehe sind hier ja schon einige mit dem RFM12 beschäftigt. Leider läuft's bei mir nicht so richtig... Den Frenquenz Devider kann ich per setting einstellen, sodass ich die 10MHz (oder andere Werte) am CLK pin messen kann. Die SPI Verbindung scheint also zu gehen. (d.h. bei einem von 3 Modulen geht auch das nicht) Beim Senden bekomme ich auf einem 70cm Empfänger auch einen Träger angezeigt, bei 433.92 (der eingestellten Sendefrequenz) aber ohne Modulation. Beim Empfang bekomme ich grundsätzlich eine 0 im MSB, d.h. ich bekomme gar kein Ready zurück :-( Hat jemand von euch schon mal den Status ausgelesen? Bzw. würde mich interessieren, welche Werte bekommt ihr eingelesen, wenn Ihr die Controllregister beschreibt? Also bei mir sind das während der initialisierung und dem Senden immer 0xFFFF und beim umschalten auf Empang sieht das wie folgt aus: Schreibe 0x82C8 (Lese: 0xFFFF) Schreibe 0xCA81 (Lese: 0x0000) Schreibe 0xCA83 (Lese: 0x0000) Warten auf Ready ... aber MSB bleibt auf 0 Kann mir mal jemand seine Werte schicken, die er beim Schreiben auf das RFM12 im Gegenzug erhält? Viele Grüße an alle Bastler Toemi
Datum:
Ich habe die Werte jetzt nicht ausgelesen, aber ich wette der Fehler liegt in der Softwareroutine die die 16bit ausgeben/einlesen. Poste mal den Code, dann kann ich mal drüberschauen. 0x0000 und 0xFFFF sehen sehr danach aus, dass irgenwas, nur nicht der Status gelesen wird.
Hallo Benedikt,
danke für die schnelle Antwort.
Denke nicht, dass es an der SPI Routine liegt,
weil auch auf dem Oszi (siehe Anhang) sieht man, dass nichts
zurück-gesendet wird,
sondern erst nach dem Kommando 0x82C8 das RFM12 von High->Low wechselt.
Habe auch schon mit dem Timing gespielt, alles ohne Erfolg...
Bzgl. code muss ich mich als NICHT-AVRler outen ;-(
aber der C-Code sieht wie folgt aus:
unsigned int rf12_trans(unsigned int data)
{
unsigned char i;
RFM_nSEL = 0;
delay_1us(10);
for (i=0; i<16; i++)
{
if (data & 0x8000)
RFM_SDI = 1;
else
RFM_SDI = 0;
data<<=1;
if (RFM_SDO == 1)
data|=1;
delay_1us(5);
RFM_SCK = 1;
delay_1us(10);
RFM_SCK = 0;
delay_1us(5);
}
RFM_nSEL = 1;
return data;
}
Also mich würde echt mal interessieren,
was bei dir so zurückkommt, wenn Du ein Kommando sendest,
bzw. ob Du den Status auslesen kannst?
Will aber natürlich auch keine zusätzliche Arbeit bei dir generieren ...
Viele Grüße,
Toemi
Datum:
Deine Routinen sehen gut aus, das Timing ist auch langsam, daran sollte es eigentlich nicht liegen. Wenn ich nur 0xC0E0 sende, kommt u.a. das zurück: 0100000010000000 und danach 0000000010000000 Deutlich zu erkennen: Das POR Flag, das nur beim ersten Lesen gesetzt ist. Mit der kompletten Initialisierung kommt das zurück: 0000001000000011 Die hintersten Bits wechseln aber andauernd, je nachdem welchen Müll das Modul empfängt. Wenn das Modul ein Signal empfängt, dann das hier: 0000001110100011 Und wenn die Daten gültig sind, (Sync Pattern empfangen), dann das hier: 1010000111111110
Datum:
Hi Benedikt, danke für die Messung, nur damit ich dich richtig verstehe: Bei jeder SPI-Ausgabe wird ja auch ein Wert eingelesen, das sind die Werte, die Du angegeben hast, richtig? Was bekommst Du denn, wenn Du direkt nach dem Einschalten explizit nach dem Status fragst, also 0x0000 sendest? Also irgendwie scheinen meine Teilchen anders zu laufen ... Welche Revision habt ihr denn? Bei mir auf der Unterseite steht: RFM12S Rev:3.0 Gekauft bei Pollin... Also langsam vergeht mir der Spass ... Viele Grüße, Toemi
Datum:
Direkt nach dem Einschalten der Spannung, wenn das erste mal der Status gelesen wird, müsste das 2. Bit gesetzt sein (Power on Reset). Sollte das nicht der Fall sein passt etwas nicht mit der Verdrahtung. All diese Bits lese ich, während ich 0x0000 sende. Wartest du mit dem Lesen auch 0,1s bis das Modul bereit ist ? Laut Datenblatt sollten die Pegel bei der fallenden Flanke wechseln. Bei dir wechselt der Ausgang des RFM12 mit der steigenden Flanke. Seltsam. Meine Module sind auch Rev 3 von Pollin.
Datum:
Hi, also langsam versteh ich's ... und ich mach fortschritte: Man muss wohl explizit den Status abfragen (0x0000 senden, und Status einlesen) Das, was bei den sonstigen Kommandos ausgegeben wird hat wohl keine Bedeutung ?! also jetzt habe ich mal direkt nach dem Einschalten den Status abgefragt: Gesendet: 0x0000 Empfangen: 0x4000 ==> POR gesetzt Nach einem Reset; Gesendet: 0x0000 Empfangen: 0x0000 ==> Flag gelöscht Wenn dann irgendwann mal der Receiver enabled war, dann flattern auch die unteren Bits. Nur Empfangen tue ich noch nichts ... Muss jetzt nochmal die Register überprüfen: Init für Send und Empfangsmodul identisch: 0xC000 ==> 1MHz am CLK output okay ! 0x80D7 0xC2AB 0xCA81 0xE000 0xC800 0xC4F7 0xA620 0x948C 0xC610 0x9860 Sender: 0x8238 0xB8AA 0xB8AA 0xB8AA 0xB82D 0xB8D4 some data 0xB8xx 0x8208 Dann nach dem Status gefragt: gesendet 0x0000 und hier 0xA000 als Antwort, nochmal 0x0000 und hier 0x8000 als Antwort, könnte auch passen: TX Register ready, warum beim ersten Status RGUR (TX register underrun, register overwrite gesetzt ist, keine Ahnung ??? Empfänger: 0x82C8 0xCA81 0xCA83 warten auf Status.MSB <<<=== tja, und hier bekomme ich nie das MSB gesetzt Status zeigt mir 0x02?? an, also FIFO empty (FFEM) Vielleicht liegt das Problem doch am RGUR flag beim Sender ??? Benedikt, kannst Du bitte mal den Status auslesen, nachdem Du was gesendet hast? Danke und Gute Nacht, Toemi
hab ich das bis hier überlesen ? ich weiss immer noch nicht wie ich das RFM 01 an den Atmel anschliesse, hat mal jemand ein Bild ? ich hab mein Modul auf einen gekürzten Eprom Sockel 24-pol gelötet, als Zwischenlage etwas Lochraster um Abstand Platine Kontakte und Sockel zu bekommen bis jetzt weiss ich nur das Miso Mosi benutzt wird ? ist das zwingend ? wirft wieder meine Planung über den Haufen , da hängen meine Taster dran , na egal wenn die Ports ausgehen muss ich eh auf Key via I²C Port PCH8574 oder war das PCF ? beides jedenfalls Röhren :-)))
Datum:
Wenn du meine Softwareroutinen verwendest, dann kannst du jeden beliebigen Pin verwenden. Die Belegung steht in der rf01.c und kann dort auch verändert werden.
Datum:
@ Benedikt K. gerne, welchen Takt braucht der Atmel mind ? sind die downloadlinks up2date ? äh welchem Link soll ich folgen, dem ersten im Thread oder muss ich nach updates suchen ?
Datum:
Die erste Version ist noch die aktuellste: http://www.mikrocontroller.net/attachment/22522/rfm01.zip Mit 4MHz aufwärts sollte das ganze funktionieren.
Datum:
@ Benedikt K. also brauch ich von den 14 Pins nur Vcc hier VDD GND Antenne SDI 5 // SDI, -> RF02 SCK 6 // SCK, -> RF02 nSEL 7 // nSEL, -> RF02 SDO 0 // FFIT/SDO, <- RF02 das http://www.mikrocontroller.net/attachment/22522/rfm01.zip #define CS in nSEL wäre eleganter ? ich hab mir einen Wolf gesucht was du mit CS meinst, klaro chip select, aber wenn die den nSEL nennen, na egal while (!(RF_PIN&(1<<SDO))); // wait until data in FIFO macht mir noch Kopfschmerzen, nicht wirklich kooperativ, ich halte doch meinen atmel nicht solange an ! hat jemand eine bessere Idee ? lg jar
Datum:
Dann machs doch so: if (RF_PIN&(1<<SDO)) rx_data(); Oder verwende den Interrupt Pin.
Datum:
Benedikt, kannst Du bitte mal den Status auslesen, nachdem Du was gesendet hast? Bei mir kommt zunächst einaml 0xA000 als Antwort, und dann bei den nächsten Status 0x8000 als Antwort. Weisst DU was das RGUR flag beim bedeutet? Gruss, Holger
Datum:
1010000111111110 kommt an, wenn ich das Sync Word sende. RGUR bedeutet, dass der Sender am Senden ist, aber du zu spät Daten nachgeladen hast, der konstante Bitstrom beim Senden also abgerissen ist. Das ist im Prinzip das gleiche wie der Pufferüberlauf beim Empfangen, daher teilen sich beide auch das selbe Bit. Eigentlich solltest du erst 0x8000 bekommen (=Daten im Puffer) und kurze Zeit später 0xA000 (= Puffer übergelaufen), wenn du keine Daten liest.
Datum:
@ Benedikt Dann machs doch so: if (RF_PIN&(1<<SDO)) rx_data(); ??? reden wir von verschiedenen Programmen ? rx_data(); gibt es nicht ! wenn du rf01_rxdata(data, 32); meinst dann sind die inkompatibel weil rf01_rxdata(data, 32); != rx_data(void); ist sorry das ich frage aber so schnell blicke ich nicht durch lg jar
Datum:
Ja, diese Funktion mein ich. Die heist bei jeder Version ein wenig anderst, aber es geht ja nur ums Prinzip: Schauen ob Daten da sind, falls ja, dann die Funktion aufrufen.
Datum:
Hallo Leutz, Ich versuche seit 2 Tagen vergeblich eine Kommunikation mit dem RFM12 aufzubauen, jedoch hapert es schon bei der SPI Kommunikation. Ich versuche das ganze mit Hardware SPI und Assembler. Der µC ist ein PIC 18F2550. Da ich über Assembler und RFM12, noch fast nichts gefunden habe, melde ich mich mal zu meinen Problemen und eventuell kann mir ja jemand helfen. Meine Fragen: - Der µC befindet sich AUSSCHLIEßLICH im Master Mode!? - Die Verwaltung des nSel Pins muss ich per hand machen? Also keine Verwaltung durch das Hardware SPI interface? - Welche Zustände muss der nSel haben und zu welchen Momenten? - Muss ich auf SLAVE Commnunication umstellen wenn ich Daten Empfangen möchte? - Auf meinem SDO pin des Funkmoduls bekomme ich rein garnichts!? - Die Initialiesierung hab ich gemacht wie in Benedikt's code! Hab auch schon ein zweites Modul ausprobiert aber ich kann weder auslesen noch senden, noch sonst irgentwas ich messe die Daten am Oszi und sehe wie der Controller sie sendet! Doch zurück kommt nix!? Ich wäre über eure Hilfe echt dankbar! P.S. Also momentan kommt I²C echt einfacher vor! Liebe Grüße Moritz
Datum:
Hallo Moritz, ich bin hier auch am Testen und habe so meine Probleme ... Schau dir doch mal mein Timing Diagramm hier an: Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module" nSEL ist im Ruhezustand HIGH, und geht vor der Starten der seriellen Kommunikation auf LOW. Dann kommen die Daten, das MSB zuerst. Am Ende der Übertargung, also nach dem LSB geht nSEL wieder auf HIGH. Dass Du auf dem SDO nichts siehst, hat mich auch verunsichert. Aber der Status wird nur ausgegeben wenn Du als Kommando 0x0000 schickst, dann siehst Du parallel zu deinem 0x0000 Wort auch auf SDO Signale vom RFM12. Am Einfachsten Du schickst einfach mal das Kommando 0xC000: Also wie folgt: Power ON nSEL = High eine Zeit lang warten nSEL = LOW uC => SDI : 1100 0000 0000 0000 (jedes Bit mit SCK low-high-low übertragen) nSEL = HIGH Nun mess mal am CLK, da muessten nun 1MHz anliegen. So kannst Du erst mal deine serielle Kommunikation testen (vom uc => RFM12) Um die andere Richtung zu testen einfach mal den Status senden 0x0000: Power ON nSEL = High eine Zeit lang warten nSEL = LOW uC => SDI : 0000 0000 0000 0000 (jedes Bit mit SCK low-high-low übertragen) und gleichzeitig SDO abfragen und die Bits einlesen. nSEL = HIGH Du muesstest beim ersten mal 0xA000 einlesen (damit wird der Power On gekennzeichnet) und beim nächsten mal Status abfragen bekommst Du 0x8000 als Antwort. Somit ist auch der serielle Empfang getestet. Die Funkstrecke klappt bei mir aber noch nicht. Habe aber gerade die Idee, dass ich vielleicht schneller auf dem seriellen Bus sein muss. Hatte zu Testzwecken mal delays eingebaut ... Viel Erfolg, Toemi
Datum:
Hallo Benedikt, manchmal ist es gut seine Gedanken einfach mal so auszutauschen ... Mit Deiner Aussage "...Deine Routinen sehen gut aus, das Timing ist auch langsam, daran sollte es eigentlich nicht liegen." hattest Du natürlich recht bezügliche dem SPI an sich, aber dem Sender gefällt das nicht (wie Du ja auch meintest), wenn er die Daten nicht schnell genug nachgeschoben bekommt "...aber du zu spät Daten nachgeladen hast, der konstante Bitstrom beim Senden also abgerissen ist. ..." Nachdem ich meine Delays entfernt habe, das SPI nun also schneller läuft, funzt die Sache hier nun einwandfrei. DANKE für die Unterstützung! Moritz, wie sieht's bei dir aus ? Viele Grüße, Toemi
Datum:
Guten Abend, Freut mich das es bei dir läuft!!! Ich bin ein ganzes Stück weiter. Also meine SendeSPI scheint zu funktionieren. Ich kann den Teiler vom CLKOut beliebig einstellen. Hatte schon 2 Mhz und 10 Mhz am CLK liegen, jenachdem wie ich es geschrieben hatte! Also von daher denk ich, alles okay. Nur das Empfangen macht mir noch Schwierigkeiten. Die Timings hab ich auch schon in verdacht gehabt bin aber jetzt auf Max Speed gegangen was bei 4,6µS impulse für den RFM12 ja echt langsam ist, wie ich Datenblatt lesen konnte. Nunja, ich denke für den heutigen Tag/Nacht reicht es! Und etwas weiter bin ich ja auch schon. ;-) Aber nun zu meinem Empfangsproblem ich empfange entweder nur 1en oder nur 0en. In deinem (Toemi) Beitrag weiter oben, hab ich gelesen das es bei dir auch mal so war? Eventuell weißt du die Lösung? Aber!!!!, Vielen Dank du hast mir schon viel weitergeholfen! Liebe Grüße Moritz
Datum:
Hi Moritz, mit den 0-en und 1-en war ein Fehler von mir, das war immer der Wert, den ich mit den Kommandos zurückerhalten habe, aber nie in der eigentliche Empgfangsroutine. Nun werte ich nur noch den Rückgabewert von der Statusabfrage aus (Sende 0x0000 und lese Status parallel dazu ein). Das bringt dann auch mal ein paar andere Bits. Der eigentliche Empfang ging bei mir ja zunächst gar nicht, da ich schon im rf12_ready() hängen blieb, weil das MSB nicht gesetzt war, weil der Sender gar nicht richtig gesendet hat, weil ich zu langasam die Daten in den Sender geschoben habe. Hmmm, so spontan habe ich da keine Idee für Dich, höchsten nochmal die Frage, was Du auf eine Statusanfrage (Sende 0x0000 und lese parallel dazu die Antwort ein erhälst) Teste mal gleich nach dem Einschalten, bevor du das erst kommando schickst. Damit siehst Du on auch das SPI Empfangen funktioniert. Du muesstest beim ersten mal 0xA000 einlesen (damit wird der Power On gekennzeichnet) und beim nächsten mal Status abfragen bekommst Du 0x8000 als Antwort. Gruss, Toemi
Moin, Also ich komm hier nicht weiter, ich habe mal mein CLK und den SDO pin am Oszi dargestellt und abfotographiert. Eventuell siehst du ja was falsch läuft. Ich habe das komische Gefühl das es mit dem Hardware SPI nie was wird und wenn ich es von Hand geschrieben hätte schon fertig wäre!? Die Flanken im SDO bekomme ich auch nur so wie dargestellt wenn ich den PIN Up-Pulle. Hast du auch Pull-Ups dran? An allen? Könnte die Pause zwischen den 8 Clocks das Problem sein?! Wenn ich einschalte und einmal 0x0000 sende kommt 0xFFFF zurück! und wenn ich das dauer sende bleibt es dabei! aber ist das was ich auf dem Oszi sehe wirklich 0xFFFF es sieht mir so nach 0x0000 aus? Naja auf jeden Fall bekomme ich nix zurück ohne Pull-up tut sich an dem Pin garnichts. Mmmh so langsam wird es nervig...! Vielen Dank, Hoffnungsvolle Grüße Moritz