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.
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
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)" :
1
for(unsignedchari=0;i<10;i++)
2
_delay_ms(10);
statt z.B.:
1
_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 ;-)
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.pdfhttp://www.hoperf.com/pdf/RF02.pdfhttp://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.
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 ?
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.
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.
@ 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
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) :)
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
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
Nein, der AVR kann beliebig getaktet werden. 10MHz bietet sich nur an,
das dieser Takt von dem Modul zur Verfügung gestellt wird. So spart man
sich den Quarz. Ein weiterer Vorteil ist auch: Man kann den AVR
dynamisch takten, indem man den Takt bis auf 1MHz reduziert.
@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 !!!
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
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
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.
@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
@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
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
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.
@ 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.
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
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
Ganz einfach: Weil nicht jeder AVR SPI hat.
Damit die Software wirklich auf jedem AVR läuft, und nicht jeder erst
die Software an seinen Wunsch AVR anpassen muss.
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???
@ Stefan
Entweder wurde das Modul nicht richtig initialisiert, oder der Sender
sendet nichts.
Versuch mal die Pause vor der Initialisierung größer zu machen.
@ 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?
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?
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.
@ 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
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.
@ 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?
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.
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.
@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??
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.
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???
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.
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?
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.
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.
Im einfachsten Fall: etwa 16cm Draht reicht. Die Antennenanpassung macht
den Rest. Falls die Entfernung klein ist, kann man die Sendeleistung per
Software reduzieren.
@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????
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.
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....
@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.
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
@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.
@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..!?
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
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
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
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
"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
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
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
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
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.
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
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
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 ?
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!
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
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
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
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.
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
}
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
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.
1
voidrf12_ready(void)
2
{
3
RFM12_CS=0;// cbi(PORTB, CS);
4
__no_operation();
5
while(!RFM12_SDO);// wait until FIFO ready
6
RFM12_CS=1;// sbi(PORTB, CS);
7
}
(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.
@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"
@ 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?
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
}
@ 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.
@ 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ß.
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.
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
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) ?
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!
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.
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....
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
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.
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.
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
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
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 ?
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)
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.
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
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?
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.
@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
@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.
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.
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.
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
>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:
1
U8rf12_ready(void)
2
{U16timeout=1000;
3
4
RFM12_CS=0;// cbi(PORTB, CS);
5
__no_operation();
6
__no_operation();
7
while((!RFM12_SDO)&&timeout)
8
{
9
timeout--;
10
__delay_cycles(10);// wait until FIFO ready
11
}
12
RFM12_CS=1;// sbi(PORTB, CS);
13
if(timeout==0)
14
return0;
15
else
16
return1;
17
}
und in rx_data liefere ich als Rückgabewert die Anzahl gelesener
Zeichen:
1
U8rf12_rxdata(U8*data,U8number)
2
{
3
U8i;
4
5
FLAG5=1;
6
rf12_trans(0x82C8);// RX on
7
rf12_trans(0xCA81);// Init FIFO
8
rf12_trans(0xCA83);// enable FIFO
9
for(i=0;i<number;i++)
10
{
11
FLAG4=1;
12
if(rf12_ready())
13
*data++=(U8)rf12_trans(0xB000);
14
else
15
break;
16
FLAG4=0;
17
}
18
rf12_trans(0xCA81);// disable FIFO
19
rf12_trans(0x8208);// RX off
20
FLAG5=0;
21
22
returni;
23
}
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.
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
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
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
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)?
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.
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 :-)
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 :-)
@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
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:
1
' werden benötigt für rf12_ready bzw SoftSPI (Definitionen für Mega8)
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?
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?
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 ?
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.
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.
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?
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.
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
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.
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
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?
@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.
@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?
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.
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)
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.
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
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
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
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.)
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??
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.
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.
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
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).
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
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
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
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.
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
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.
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.
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
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.
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:
1
#define RF12_UseBlockingCalls //NEVER USE BOTH
2
#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.
// check whether the package is already transmitted
11
unsignedcharrf12_txfinished(void);
12
13
// stop all Rx and Tx operations
14
voidrf12_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
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
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
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
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.
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.
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.
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.
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.
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.
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
1
...
2
3
Config Int1 = Rising
4
On Int1 Ffit_handler
5
Enable Int1
6
7
...
8
9
Ffit_handler:
10
11
' Byte lesen
12
Temp = Rf12_trans(&Hb000)
13
Rfdata(count) = Temp
14
15
' Momentan einfach feste länge lesen, STX ETX oder sowas ist aber
16
' hier auch kein problem...
17
If Count >= Maxchar Then
18
19
' Wenn 32 Bytes gelesen wurden, Text ausgeben
20
For Count = 1 To Maxchar
21
Print Chr(rfdata(count));
22
Next Count
23
24
' FIFO SYNC Erkennung wieder scharf machen
25
Temp = Rf12_trans(&Hca81)
26
Temp = Rf12_trans(&Hca83)
27
28
' und von vorne zählen
29
Count = 1
30
31
Else
32
' ansonsten nur zähler erhöhen
33
Incr Count
34
End If
35
36
37
Return
38
39
....
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...
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
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
@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
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.
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.
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.
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
Hallo!
Möchte das RFM12 an einem PIC 16F876 betreiben. Auf was muss ich achten?
Hat das schon jemand mit einem PIC versucht?
Danke für eure Hilfe.
mfg
Martin
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
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
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?!
@ 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?
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
@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
> 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.
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
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.
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
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
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
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
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?
@ 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
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
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
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?
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.
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
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**.
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
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
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
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.
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
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.
@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
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
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
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
@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
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
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.
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.
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
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
@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!
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
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
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
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
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
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
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.
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 :-)))
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.
@ 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 ?
@ 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
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
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.
@ 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
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.
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
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
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
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
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
Hey!
Ja so wie im Datenblatt verlangt, alles Ausgänge und der SDI wird
automatisch verwaltet, hab aber beides ausprobiert. Ich habe eben
probiert, dass was ich sende gleichzeitig zu empfangen. Kein Erfolg es
kommt auch nur 0xFFFF und 0x0000 an also sehe ich Probleme bei dem
Hardware SPI. Ich werde heut Abend die Routinen selber schreiben, das
ist glaub ich das sinnvollste, oder? denn ich denke das ist hier
verschenkte Zeit und ne SPI Übertragung ist ja nun nicht soooo schwierig
;-).
Ich meld mich! Danke euch allen! Super Support hier!
Grüße Moritz
Die Software bei den Programmen hier verwendet Software SPI, die sollte
mit jedem Controller funktionieren. Bei der RS232 Funkbrücke wird der
Hardware SPI auf einem mega8 verwendet. Beide Routinen funktionieren,
probier diese also mal aus. Damit kannst du einen Softwarefehler
ausschließen.
Meine Assembler-Routine zum Senden von Befehlen sieht so aus:
1
RF12_CMD: ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17
2
cbi PORT_SPI,SEL ;Chip Select
3
ldi r18,16 ;Schleifenzähler für die einzelnen Bits
4
STloop:
5
cbi PORT_SPI,SCK ;Clock LO
6
clc ;carry löschen
7
sbic PIN_SPI,SDI ;Bit am SPI Eingang =0?
8
sec ;dann carry setzen, an sonsten gelöscht lassen
9
rol r16 ;Carry-Bit hinein schieben
10
rol r17
11
brcc cl ;herausgeschobenes Bit =0?
12
sbi PORT_SPI,SDO ;ja, dann SDO auf HI
13
rjmp cw ;und weiter
14
cl:
15
cbi PORT_SPI,SDO ;SDO LO
16
nop
17
cw:
18
sbi PORT_SPI,SCK ;Clock HI
19
dec r18
20
brne STloop ;weiter mit Schleife
21
cbi PORT_SPI,SCK ;Clock LO
22
sbi PORT_SPI,SEL ;Chip Deselect
23
ret
Diese liefert , nachdem ich die Initialisierungs-Befehle aus dem
Beispielprogramm des Herstellers ($80d7,$8239...) gesendet habe und dann
den "Staus Read"-Befehl gesendet habe den Wert $4080 bei erneutem Senden
$0080. Das heißt, diese Routine müsste funktionieren, da das POR-Bit
nach dem ersten Lesen gelöscht wird.
Allerdings bekomme ich das ganze nicht mit dem Hardware-SPI hin. Ich
habe schon sämtliche kombinationen bezüglich der Bits CPOL und CPHA im
SPI-Control-Register versucht, aber nichts hat funktioniert, ich bekomme
immer nur $ffff zurück. Wenn ich das Datenblatt des ATMega8 richtig
verstanden habe, muss man sich um das setzen und löschen des SS-Pin im
"Master-Modus" selbst kümmern oder wird es doch automatisch gesteuert?
In den Beispiel-Programmen taucht es jedenfalls nicht auf.
@ Johannes
Welche Geschwindigkeit verwendest du ?
Bei mir funktioniert es nur bis max 3MHz SPI Takt (obwohl laut
Datenblatt mehr möglich sein sollten.) Das Modul läuft mit dem SPI Modus
0.
@Benedikt K.
nachdem ich das erste RFM01 zerlötet hatte klappts nun mit dem 2ten,
zumindest sieht es gut aus, aber
warum ist der FiFo nach power on nicht leer ?
ich lese und lese -> while(RF_PIN&(1<<SDO)
und kommt immer 0 raus
ist der FiFo voll mit Nullen auch wenn keiner sendet ?
Benedikt K. wrote:
> Schaltest du den FIFO vorher sauber ein ?
sieht so aus , denke ich jedenfalls aus deine Code Schnipsel
BTW, was erwarte ich denn bei diesen China Sendern ?
reguläre Rx Daten sicher nicht, der Power Commander (IR Verlängerung)
sagt 433 MHz Empfang im China Sender vorhanden
http://www.linkdelight.com/photo/remoteCordControl/R7C.jpg
#ifdef RF_PORT
rf01_init(); // ein paar Register setzen (z.B. CLK auf 10MHz)
void rf01_init(void)
{ unsigned char i;
RF_PORT=(1<<CS);
for (i=0; i<11; i++)
_delay_ms(10); // wait until POR done
rf01_trans(0xC2E0); // AVR CLK: 10MHz
rf01_trans(0xC42B); // Data Filter: internal
rf01_trans(0xCE88); // FIFO mode
rf01_trans(0xC6F7); // AFC settings: autotuning: -10kHz...+7,5kHz
rf01_trans(0xE000); // disable wakeuptimer
rf01_trans(0xCC00); // disable low duty cycle
}
Benedikt K. wrote:
> Schaltest du den FIFO vorher sauber ein ?
ja
aber RF_PORT=(1<<CS);
ist eine böse Falle, 3 Tage Fehlersuche warum nicht RF_PORT|=(1<<CS); ?
@Benedikt K.
Mein Code sieht jetzt folgendermaßen aus:
1
.equ SDI = 3 ;-----> SDO
2
.equ SDO = 4 ;-----> SDI
3
.equ SCK = 5 ;-----> SCK
4
.equ SEL = 2 ;-----> nSEL
5
.equ nIRQ = 1 ;-----> nIRQ
6
.equ PORT_SPI = PORTB
7
.equ DDR_SPI = DDRB
8
9
sbi PORT_SPI,SEL ; SEL auf HI -> nicht selektieren
10
cbi PORT_SPI,SCK ; SPI Clock LO
11
sbi DDR_SPI,SDO
12
sbi DDR_SPI,SCK
13
sbi DDR_SPI,SEL
14
cbi DDR_SPI,nIRQ
15
cbi DDR_SPI,SDI
16
17
// initialisieren als Master mit Prescaler 16
18
ldi r16, (1<<SPE)|(1<<MSTR)|(1<<SPR0)
19
out SPCR,r16
20
21
RF12_CMD: ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17
22
cbi PORT_SPI,SEL ;Chip Select
23
//***
24
out SPDR,r17 ;Erstes Byte senden
25
t1:
26
sbis SPSR,SPIF ;warten bis Transfer zu Ende
27
rjmp t1
28
in r17,SPDR ;Angekommenes Byte wieder in r17
29
//***
30
out SPDR,r16 ;Zweites Byte senden
31
t2:
32
sbis SPSR,SPIF ;warten bis Transfer zu Ende
33
rjmp t2
34
in r16,SPDR ;Angekommenes Byte wieder in r16
35
//***
36
sbi PORT_SPI,SEL ;Chip Deselect
37
ret
Ich habs auch schon mit einem Vorteiler von 128 versucht und an den mit
//*** Markierten stellen eine warteschleife eingefügt, hat alles nichts
genutzt. eigentlich sollte das Timing ja nicht so kritisch sein, weil
laut Datenblatt höchstens mal 25ns gewartet werden muss (Timing
specification), was aber bei 16Mhz Takt niemals unterschritten wird.
Dem Datenblatt darf man nicht so ganz vertrauen: Bei mir funktioniert
das ganze mit 5MHz SPI Takt nicht, nur mit 2,5MHz, obwohl eigentlich
laut Datenblatt alles schneller sein dürfte.
Kann es sein, dass du SDO und SDI vertauscht hast ?
Na toll! hätte ich mir mal die Mühe gemacht und mir im Datenblatt die
Bedeutung von "MOSI" und "MISO" angeschaut, dann hätte ich mir viel
Ärger gespart! Vielen Dank, Benedikt!
Bei mir funktiert es jetzt sogar mit einer Clock-Frequenz von 8Mhz, also
mit dem kleinsten Vorteiler von 2.
Habe den ganzen Post jetzt mehr überflogen als gelesen, weil er sich
doch schon zu einem Monster entwickelt hat...
Wenn ich eine Funksteurung der einfachsten Art brauche, kann ich doch
den Code im ersten Post mit der NOP Ergänzung nehmen oder gibts es eine
aktuellere Version, die genauso einfach ist?
MfG
Kai
Hallo erstmal,
ich bin am verzweifeln. Ich habe das rfm01 und rfm02 und möchte sie mit
2 mega8 und Bascom laufen lassen. Die Clk-Einstellung kann ich auf
verschieden Takte ändern, drum denke ich, die Spi-Schnittstellen laufen.
Beim Empfänger kommen verschiede Werte an, allerdings ignoriere ich
momentan das sdo-Signal, wenn ich nun den Sender einschalte ändern sich
die Werte es kommt dann konstant z.b ein H3708 und beim nächsten
Senderstart konstant ein H3138. irgendwie Sendet der Sender nicht
richtig. Damit ich überprüfen kann ob die Hardware richtig ist bräuchte
ich ne Software die garantiert läuft. Könnte mir jemand mal eine Sender-
und Empfängersoftware (die halt ein paar Wörter sendet) für die RFM01
und RFM02 als hex zuschicken. Am besten mit den Pinbelegung für einen
atmel mega 8 mit 8 Mhz. Ich weiss das ist viel verlangt,aber vielleicht
hat ja jemand genau diese Konfiguration.
@test
die Programme für den rfm12 habe ich natürlich schon durch geschaut, man
findet sie auch hier im Thread ebenso im anderen grossen Thread in
diesem Forum und in andere foren. Leider sind die Befehlssätze des RFM12
nicht identisch mit denen von RFM01/RFM02 und da hängst vielleicht.
Jetzt versuche ich die C-Beispiele selber zu compilieren, bin
diesbezügl. nicht firm und bekomme immer Warnings wegen delay.h und
Errors wegen 99 C-mode usw.
Jetzt wäre es halt für mich einfacher gewesen wenn ich einen fertig
compilierten Code bekommen hätte. Naja soll wohl nicht sein, da muß ich
halt weiter kämpfen.
hi,
mal ne andere Frage. Es gibt weiter oben von Benedikt unteranderem die
beiden Progs RFM01/RFM02. Im Empfänger gibts die Zeilen:
unsigned char data[32];
for (;;)
{
rf01_rxdata(data, 32); // 32Bytes empfangen
}
Ich habe keine Ahnung von C. Wie kann ich den data auf die rs232
ausgeben? Also ich habe die Funktion
_writeString ("Hallo, Welt!\n"); die z.b funktiniert so.
Wie muss ich data da einsetzen damit ich was senden kann?
Wenn data einen Null terminierten String beinhaltet (oder mit anderen
Worten: Text), dann einfach _writeString (data);
Oder erwartet _writeString() einen String im Flash ?
@bennedikt
Habs noch mal nur mit data probiert,jetzt kommt was allerdings nur wirre
Zeichen aber im Takt und die Anzahl ist auch gleich (glaub ich). In
irgendeinem Thread hatte ich was von timingprobs dies bezgl. gelesen.
Ich habe deinen C-Code angepasst, aber wahrscheinlich nicht richtig.
Habe 2 Mega8 mit 8 Mhz
F_CPU 8000000UL //10000000UL
Hier von 10 Mhz auf 8 Mhz geändert
#define SDI 3 // SDI, -> RF02
#define SCK 5 // SCK, -> RF02
#define CS 2 // nSEL, -> RF02
#define SDO 4 // SDO, <- RF02
Muss ich irgenwas anderes noch ändern?
hi
danke für die vielen und detailierten Antworten. Jetzt habe ich noch
zwei Fragen. Ich kenne mich nur bedingt mit C aus und hieraus werde ich
nicht schlau:
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))); <---------
if (wert&128)
sbi(RF_PORT, SDI);
else
cbi(RF_PORT, SDI);
wert<<=1;
}
}
Was prüfen die beide While-Abfragen? Das erste while prüft ob ein Bit im
Port gesetzt ist und das zweite ob nicht ?!?
Ich habs irgendwann geschafft nach langer Recherche und den
unmöglichsten Einstellungen die C-Programme auf den RFm01 und RFM02 zum
Laufen zu bringen.
Sie funken auch allerdings stimmen nur die ersten beiden Zeichen das
kommen wirre. Woran kann das liegen?
Das RFM02 ist ein wenig dumm anzusteuern, da es kein FIFO hat. Es gibt
aber eine kleine Hilfe: Das Modul erzeugt 1,6µs lange Impulse, sobald
das nächste Bit geladen werden soll. Diese muss man irgendwie erkennen,
und das wird mit diesem Code gemacht: Warten solange der Pin High ist,
dann warten solange der Pin Low ist. Danach wird das nächste Bit
ausgegeben. Damit das ganze fehlerfrei funktioniert, muss der AVR mit
mindestens 4MHz getaktet werden.
Hallo,
Nachdem mein Testaufbau mit den blockierenden Funktionen funktioniert
hat, bin ich auf den Interrupt-gesteuerten C-Code von Jürgen
umgestiegen.
Dabei habe ich jedoch riesige Probleme. Hardwarebasis ist ein
Pollin-Board (mit RFM12, ATMEGA32) sowie ein Breedboard (ATMEGA8) mit
dem selben Modul. Bei mir bleibt beim Sendeboard der Programmablauf in
der txfinished() und beim Empfangsboard in der rxfinish() hängen.
Wer betreibt sein RFM12 mit IRQ-Steuerung? Hat jemand den Code von
Jürgen verwendet?
Danke
Lorenz
Hier zumindest ein zur Hälfte interruptgesteuertes Programm (nur beim
Empfang). Das ganze ist recht universell und leicht im eigenen Programm
verwendbar, da wirklich alles in einer Datei ist.
Die Daten werden Byteweise der Funktion übergeben, die daraus von selbst
die Pakete bildet, diese überträgt, prüft und wieder als einzelne Bytes
zur Verfügung stellt.
Morgen,
5:18 man man man, zu was für einer Gottes unwürdigen Zeit schreibst du
Forenbeiträge? :)
Kein wunder das dein Code auch an der Stelle hängen bleibt:
1
unsignedcharrf12_txfinished(void)
2
{
3
if(RF12_status.Tx)
4
return(255);//not yet finished
5
return(0);
6
}
Nein jetzt mal im Ernst: Er kann da nicht hängen bleiben. Das ist völlig
unmöglich. Es sei den dein Speicher (Stack) ist voll, was aber relativ
unwahrscheinlich ist, sag ich mal.
Beim empfangen kann ich mir das evtl noch einigermassen vorstellen. Wenn
z.B. die Längenangebe länger ist als die eigentlich Pufferlänge. Aber
sonst, KA was du treibst.
Tus mal etwas mehr debugen, oder evtl fehlt auch dieser Hardware
Interrupt Pin bei dir, oder die Pinbelegung ist allg ander?!
Jürgen
Ach, manchmal dauerts halt etwas länger im Bastelkeller, da merkt man
erst, dass man schlafen sollte, wenns hell wird...wer kennt das nicht?!?
Also die Funktion kann schon hängen. Wenn der Status.Tx nicht mehr auf 0
gestellt wird (hab ich nirgens in deinem code gefunden ?!?) dann bleibt
der immer in der Warteschleife. Und irgendwie wechselt bei mir der
Status nicht.
Hardwaremäßig habe ich den FFIT-Pin an Int1 hängen (beim TXer). Der RXer
ist auch mit dem IRQ (Int0) verbunden.
Mein Projekt habe ich mal angehängt. Evtl ist ja jemand so nett und
wirft einen kurzen Blick drauf. Manchmal sieht man ja den Wald vor
lauter Bäumen nicht...
@Benedikt: Deine neuen Routinen habe ich mir gestern auch angeschaut.
Von der IRQ-gesteuerten Programmroutine konnte ich jedoch nichts
abstrahieren, was mich auf mein Problem gebracht hätte.
Aber ansonsten nettes Package. Sobald die IRQ-Steuerung bei mir
funktioniert will ich das mal ausprobieren. Im Endeffekt ist das die
Applikation die ich wollte (Funkbrücke, mit Hardware-Handshaking).
Tja,
ISR()
kenne ich jetzt nicht. Ist das das gleiche wie
SIGNAL()
?
Eigentlich hängt er ja nicht im Methoden aufruf, sondern in der while()
Schleife. Ich würde einfach mal Tippen das der die Async'tät einfach
nicht ausführt. Schon mal geschaut ob der da rein springt, oder ob
überhaupt das HW Signal da ankommt?
Jürgen
Hallo Jürgen,
Ja, ISR ist die neue Variante. Dafür wird dann auch der INT1_vect statt
dem INTERRUPT1 verwendet.
Nach etwas Schlaf habe ich auch den letzten Teil deines Codes
verstanden. Ich bin immer davon ausgegangen, dass das Senden ohne IRQ
von statten geht. Aber ist wohl nicht so!
Mit dem HW-Signal ist so eine Sache. Habe leider kein Oszi hier,
triggerbar schon gar nicht... Und mit dem Multimeter wirds schnell
eng... Werds wohl in Software prüfen müssen.
Andere Frage. Wie steht es denn mit den Signalpegeln bei dem Modul?
Soweit ich weiß ist das Ding active-high. Die Interrupt-Kontrollregister
hast du ja nicht verändert. Von dem her sollte das ja OK sein (default
ist ja steigender Pegel).
Benedikt hat in einen Post (anderer Thread, Funkbrücke...) mal geäußert
dass er einen Inverter davor hat???
Naja, werde die Nacht heute mal wieder mit Debuggen verbringen. Dauert
ohne vernünftiges Equipment etwas länger :-)
Ach ja, was ich noch loswerden wollte:
DANKE AN ALLE, OHNE DEN THREAD WÜRDE HEUTE NICHT MAL DIE EINFACHE
ÜBERTRAGUNG BEI MIR FUNKTIONIEREN.
Ich hab keinen inverter drinnen. Und es geht.
Aber der Proz muss >1Mhz laufen. Hab es eben mit einer Low Power
variante getestet (1Mhz) und da lief es ned. :)
Ich werde heute noch den Treiber etwas erweitern um das Energier
Management anzusteuern.
Jürgen
Hallo Benedikt
>Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet
hab mir von Pollin auch ein paar solcher Dinger besorgt.
Hast Du da mal was veröffentlicht?
Wigbert
Zu dem Tuner habe ich bisher noch nichts geschrieben, da die Lösung
bisher wirklich nur eine Bastellösung ist: Es funktioniert halt so
einigermaßen, damit ich was messen kann.
Einen Schaltplan usw. habe ich bisher nicht gezeichnet, da sich die
Schaltung eigentlich kontinuierlich in einer Weiterentwicklung befindet.
Wenn du am Code zur Ansteuerung für den Tuner interessiert bist, dann
schick mir mal eine Nachricht. Allerdings macht der Code nicht viel mehr
als eine Frequenz an den Tuner senden (mehr kann der Tuner ja auch
nicht, als eine Frequenz zu empfangen).
Hi folks!
Ich bin seit tagen dabei, diesen Beitrag zu lesen und das vorhandene
KnowHow anzuwenden auf meinen ATmega8 (12MHz Quarz).
Ich hab das Modul (RFM12S) wie folgt verbunden
Mega8 rfm12s sonstiges
MISO (PB4) SDO
MOSI (PB3) SDI
SS (PB2) nSEL
SCK (PB5) SCK
FSK über 5k an bat+
nINT/VDI offen
nIRQ offen
DCLK offen
CLK offen
nRES offen
PD5 LED gn
PD6 LED gb
Hier nun die Frage:
was muss ich minimal in meinem Code haben, um ein 434Mhz Signal zu
empfangen und wenn ein signal kam, die gelbe les leuchten zu lassen?
Ich komm mit den komplexen codes hier einfach nicht zu recht.
Zum beispiel bringt mir mein compiler bei der fnktion
unsigned short rf12_trans(unsigned short wert)
fehler aus. Irgendwas mit cbi und sdi. aber an den Ports ist doch
garkein Int???? Oder seh ich das falsch?
Wär cool, wenn mir jemand weiter helfen könnte.
f.y.i.: Das Signal, das ich empfangen will, ist von einer
fernsteuerbaren Steckdose, die auf 434MHz sendet. (von REV, Mod.
008341).
Grüßle
Steffen
Du hast vermutlich die global.h nicht eingebunden.
Das was du vorhast wird vermutlich nicht, bzw. nur mit etwas Umweg
funktionieren: Die Funksteckdose ist ein AM Sender, der RFM12 dagegen
ein FM Empfänger.
ok, dann war des halt nix mit der fernbedienung, aber das ist nict so
schlim, weil das nicht der entgültige zweck ist. wollte blos damit
überprüfen, ob der empfänger überhaupt was bekommt.
das mit der Lib werde ich gleich testen.
Nun zu meinem eigentlichen problem: Wozu die interrupt geschichte beim
initialisieren des moduls???
Ich brauch nen code, wer einfach nur (ambesten 8) bits sendet. diese
bits sind immer die gleichen (bit0 -> zustand von pin_x, bit1 -> Zustand
von pin_y u.s.w.). somit brauch ich blos einen sehr rudimentären code,
den sogar ich als spi-newbe verstehe.
Ich habe 2 rfm12 module, wobei ich eines nur zum senden und eines nur
zum empfangen verwenden will. früher oder später wird vielleicht
erweitert auf bidirektional, aber im moment nicht von nöten.
desshalb bin ich auf der suche nach jemandem, der mir sagen kann, was
ich alles aus den bibliotheken wirklich brauche. im prinzip ein zwischen
schritt von den projekten, die ihr alle gecoded habt.
Grüßle
Steffen
noch ne frage:
gibt es irgendeinen zwingenden grund, die 10MHz vom modul anzubinden?
Oder kann ich den ATmega auch einfach mit den internen 8MHz oder einem
externen quarz mit 12 MHz betreiben?
Grüßle
Steffen K. wrote:
> gibt es irgendeinen zwingenden grund, die 10MHz vom modul anzubinden?
Nein, der µC kann im Prinzip beliebig getaktet werden, solange er die
Daten nur schnell genug an das Modul liefern bzw. vom Modul abholen
kann.
hattest recht, die comile-fehler sind mit der global.h weg.
hätte man(n) drauf kommen können douhg
aber verstanden habe ich den code trotzdem nicht ganz:
void rf01_trans(unsigned short wert) // was ist ein short?
{ unsigned char i;
cbi(RF_PORT, CS); // was macht (_SFR_BYTE(sfr) &= ~_BV(bit))
for (i=0; i<16; i++)
{ if (wert&32768) // wenn wert und 8000h??? wo kommen
die 8000h her?
sbi(RF_PORT, SDI); // was macht (_SFR_BYTE(sfr) |= _BV(bit))
else
cbi(RF_PORT, SDI);
sbi(RF_PORT, SCK);
wert<<=1; //???
_delay_us(0.2);
cbi(RF_PORT, SCK);
}
sbi(RF_PORT, CS);
}
Ja, ok, das sind viele fragen, aber unsere lehrer sind nicht die
hellsten, denen muss ich sogar was zeigen im unterricht, wie will man(n)
denn da zum uC-crack werden..... :-/
Grüßle
ok,
wer lesen kann ist eindeutig im vorteil.
16 bit -> uint16
>typedef unsigned short uint16_t;
d.h.
>uint16_t steht für einen 16-Bit Integer ohne Vorzeichen (unsigned int) mit einem
Wertebereich von 0 bis 65536.
aber die clear bit und set bit geschichte hab ich noch ned raus :-(
moment mal, ist cbi und sbi 100% das gleiche wie |=(1<<x) und
&=~(1<<y)????
falls ja, bleibt blos noch die frage nach dem (wert&32768) konstrukt?!
Grüßle
Gegenfrage: Wenn du das RFM12 hast, wiso verwendest du dann die Routinen
für das RFM01 ?
Welche Software verwendest du ?
Nimm am besten diese hier, und betrachte diese zunächst als fertiges
Modul.
Mit rf12_putc() kannst du einzelne Bytes verschicken, die werden mit
Fehlerkorrektur usw. übertragen und der Empfänger kann diese mit
rf12_getchar() abrufen.
http://www.mikrocontroller.net/attachment/24996/rfm12_rs232_rxtx_check_int.zip
moin jungs (und mädels???)
hat mir gestern keine ruhe gelassen, dass das modul nicht funktioniert.
Bin deßhalb noch kurz in gschäft und hab mir mein oszi geholt.
zur SW: ich mach keine init vom RF-Modul sondern sende dauernd im
while(1)
rf01_trans(0x893B); // |low_bat_det, |wk_up, crystal_mode, 10pf
crystal_c, base_bw134kHz, clk_out
wenn das modul dies bekommt, müsste doch am clk-pin 10Mhz anstatt 1MHz
auskommen, oder ned???
signale kommen auch alle am jeweiligen pin an (SCK, SDI, nSEL), aber es
tut sich nichts am CLK-Ausgang.
Hab auch mal ti/tp-Verhältnis vom SCK verändert (bis auf 50/50), hat
aber auch nichts geholfen.
Hat jemand ne ahnung, woran das liegen kann?
Verdrahtet sind SDO (MISO), SDI (MOSI), nSEL (SS), SCK (SCK). VDD
schalte ich per uC über einen Port (bringt ja 40mA, %V bleiben stabil,
also null problem), FSK liegt per 5k an 5V. alles andere liegt offen.
Grüßle
Steffen K. wrote:
> wenn das modul dies bekommt, müsste doch am clk-pin 10Mhz anstatt 1MHz> auskommen, oder ned???
Nein, mit dem Befehl kann man den Takt nur abschalten. 0xC0E0 schaltet
auf 10MHz.
Hallo Leute,
ich hab mir eine schaltung aufgebaut mit rfm12. Nun meine frage zu der
Eagle schaltung: Kann ich die CLK pin mit dem XTAL pin des µC so
einbinden? Es sollte dann für die Externe Quarz gelten oder habe ich da
was falsch gemacht
Lg,
Timo
Hallo Leute,
da ich jetzt alles aufgebaut habe und die Fusebits auf extern
eingestellt habe und seitdem ich kein programm in den µC
reinprogrammieren kann, bleibt mir nur eins euch zu fragen. Ich schicke
im Anhang einen für ATMEGA8 und ATTiny2313 µC fusebits einstellungen für
externe quarz. Was mache ich falsch. Ich benutze ATTiny2313 für sender
und ATMEGA8 für empfanger mit RFM12. Programmieren tue ich mit isp
schnittstelle. Bitte um einen Feedback.
lg
Timo
Ich habe jetzt mal zwei Funkmodule mit dem ATmega8 aufgebaut und es hat
von Anfang an funktioniert!
Schade finde ich nur, dass alle Ports belegt sind und man dadurch
beispielsweise kein LCD mehr anschließen kann. Ich werde jetzt wohl
zusätzlich noch einen mega8 brauchen um ein LCD anzuschließen und
beispielsweise ein Tastenfeld für die Sachen, die ich senden will.
Aber auf jeden Fall ein großes Lob an Benedikt! Sogar ich habs
hinbekommen :D
Alle Ports belegt ? Lass die Status LEDs weg, dann hast du PortC und
PortD komplett frei und an PortB ist auch noch ein wenig frei (je
nachdem welche Version du verwendest, kann es ein wenig anderst sein).
Hallo Benedikt,
>Ja, das sollte so funktionieren.
Timo hat eine Resetverbindung vom RFM12 zum m8.
Haben wir nicht .Könnte das zu Problemen führen?
Die Fusebits sind meiner Meinung nur teilweise richtig.
Wurde aber richtiggestellt.
Wigbert
Resetpin vom RFM12 ist mit Reset vom meg8 verbunden ?
Der Pin ist an sich Open Collector, er dürfte also nicht stören. Wobei
man nie weiß, was das das RFM12 genau mit Reset macht: Es kann sein,
dass ein Reset Impuls künstlich verlängert wird.
Ist an nSEL vom Modul ein Pullup ?
Bei mir klappte es meistens, aber nicht immer:
Wenn die Isolation gut ist, reicht die parasitäre Kapazität aus, um nSEL
während des Programmierens auf high zu halten. Wenn nicht, geht SDO auf
Low -> Programmieren geht schief.
Ähnliches passiert, wenn nSEL Low war, während der Programmiervorgang
anfing.
Hallo,
Für meine zukünftige Master-Slave Kommunikation wurden für die
Erstellung und Übertragung von Datenpaketen 2 Testcode in Bascom
entworfen.
Ziel wird es sein eine Master gesteuerte Kommunikation aufzubauen.
Prinzip:
Master ruft Slave
Slave sendet Daten an Master
Master sendet Befehle an Slave
Master:
eingegebenen String (Adresse oder Datenpaket) mit Stringlänge und Check
vervollständigen. So das folgendes Paket gesendet wird:
Längenbyte- Stringbyte-Stringbyte-…………-Checkbyte
Das Längenbyte bestimmt die Sendedatenlänge.
Slave:
interruptgesteuertes Auslesen des Datenpaketes und zwischenspeichern.
Dabei wird wiederum aus dem ersten Byte die Empfangsdatenlänge
errechnet.
In einer Sub wird der Check durchgeführt und der gewonnene Textstring
ausgegeben
Eine weitere Sub dient zur Erkennung der hinterlegten Adresse.
Der Textstring wird ordnungsgemäss verarbeitet. Kommt immer richtig an.
Seltsamerweise werden aber verschiedene Werte der Checksumme empfangen.
Nicht falsche sondern unterschiedliche (letzte Ziffer).
Kann es sein, das irgendein Müll mit übertragen wird?
Ein "sinnloses"Byte einfach anzuhängen wär auch kein Problem
Die Software wurde auf Pollinboard getestet(10 Mhz von RFM12)
Wigbert
Es gibt auch ein Testboard für den RFM12 Modul für ATMEGA 8
--> http://www.comwebnet.de/seite48.html
Die Zuleitungen sind über Jumper Konfigurierbar
Das Testboard ist "Schaltung Pollinboard kompertibel"
Vielleicht hilft es den einen oder anderen beim Experimentieren.
Freie PINs vom M8 sind rausgeführt.
http://www.comwebnet.de
Hallo Leute,
habe das Problem mit dem Checksum-Fehler gefunden.
Einfach im Master ein String zuviel senden.
Also
Lean = Laenge + 3 'Länge um 1 erhöhen
Text = Text + " " 'wird im Slave nicht ausgewertet
1
'##########################
2
Sub Sendetext 'Aufbereitung des Text="Teststring"
3
Sendedata = Rufzeichen 'welcher String gebraucht wird
Also das nenne ich "Perfekten Code" von Benedikt !!!!
Ich habe mit Begeisterung diesen thread gelesen. 4x RFM12 gekauft und 2
Stück davon in 15 Minuten an meine existierenden ATmega32 angeschlossen.
Den C-Code von Benedikt vom 22. Mai in die ATmega's geworfen und läuft
!!
Also hier nochmals vielen Dank an Benedikt für diese tolle Arbeit !!!
Denn diese Datenübertragung fehlte mir noch in meiner Sammlung, da ich
mit den schrulligen Dingern von Con.. nix anfangen konnte (nach der
ersten Wand war Funkstille und das mit 1 Kbit).
Gruß
Manni
Hallo allerseits,
Na da tut sich ja einiges in diesem Thread!
Hab da noch eine andere Frage/Problem:
Und zwar verwende ich das RFM12 als Leuchtensteuerung. Das Modul
empfängt Daten, die dann im µC ausgewertet werden - dieser erzeugt dann
PWM-Signale für das Leuchtmittel.
Das funktioniert alles wunderbar, bis auf eine Kleinigkeit. Und zwar,
wenn ich das ganze eine Zeit lang laufen lasse, reagiert das RFM12 nicht
mehr auf meine Befehle, die ich von einem anderen RFM sende. Erst wenn
ich das Board in der Leuchte resete, dann spricht es wieder an.
Was kann da sein? Der µC ist es glaub ich nicht, weil die PWM-Signale
weiter erzeugt werden. Nur der Empfang wird "stumm". Auch den Sender
kann ich ausschließen.
Es könnte irgendwo im Code liegen, weil diese Problem bei all meinen
Leuchten vorkommt. Ich glaube vielleicht, dass das RFM irgendwelche
Störsignale empfängt und sich dann "aufhängt".
Ich weiß, dass das ganze ohne Code von mir nur ein Raten ist, aber
vielleicht kennt jemand das Problem. (Ich darf den Code nicht
bekanntgeben).
Vielen Dank für eure Unterstützung!
mfg
Andy
Andy wrote:
> @Trigger Schmitt:> Was soll das?
Das ist schon der 3. Eintrag dieser Art von dem Spammer.
Hat er in anderen Threads auch schon veranstaltet.
Meldung an webmaster habe ich schon geschickt.
Hallo nochmal!
Bin meinen Code nochmal durchgegangen! Ich schalte direkt nach dem
Empfang von Daten wieder in den "Bereitschaftsmodus". Das mach ich mit
folgenden Befehlen:
rf12_trans(0xCA81); // set FIFO mode
rf12_trans(0xCA83); // enable FIFO
Stimmt das? Oder muss ich da sonst noch was berücksichtigen?
Außerdem habe ich einen TimeOut programmiert. Falls das Stop-Byte nicht
empfangen wird, setzt der Timer alle Empfangsvariablen zurück und
schaltet das RFM12 mit den obigen Befehlen wieder in den
Bereitschaftsmodus?
Habe ich da irgendwo einen Denkfehler, oder könnte das so funktionieren?
Vielen Dank für eure Hilfe!!
mfg
Andy
Nachdem hier einige "Zwischenfälle" vorgekommen sind, wollte ich nur mal
nachfragen, ob vielleicht wer eine Lösung für mein Problem hätte. :-)
Vielen Dank
mfg
Andy
hallo,
weiß jemand, wie genau man die Signalstärke abfragen kann?
Kann ich zum Beispiel eine Funkfernbedienung mit dem RFM12 Modul bauen
und danach den Empfänger software seitig so zu konfigurieren, dass ich
nur Signale aus einem Meter Entfernung empfange?
Weiß das jemand?
Hallo Leute,
Ich bins wieder, habe in der Mitte schon mal gepostet, und bin immernoch
nicht weiter, ich habe inzwischen auch schon andere RFM12's ausprobiert.
NIX.
Ich vermute das ich irgentwas Hardware mäßig falsch mache. Wenn ich am
SLK takte und den SDI am modul auf "0" lasse muss ich doch an dem SD0 am
Scope irgentwas sehen?? Den Takt hab ich auch schon verändert. Ich sehe
da nix, garnichts. Wie soll ich anfangen zu suchen? Habe die Belegung
wie folgt gemacht. Habe auch schon mit pull ups und pull downs rum
gespielt aber kein ergebnis.
nSel --> SS (µC) (auch mit pullup)
SCK --> SCK (µC)
SDI --> SDO (µC)
SDO --> SDI (µC)
FSK --> Pullup (10k) an 5V
beide GND an Masse
VDD an 5 V
Ich wäre euch zu tiefst Dankbar wenn ihr mir sagen würdet was ich falsch
mache!!!
Moritz
Also habe es so gemacht:
MISO ->SDO
MOSI ->SDI
SS -> nSEL
SCK -> SCK
FSK/DATA -> 10k ->VCC
INT1 -> DCLK/FFIT ( nur wenn Interrupt Betrieb )
http://www.comwebnet.de
Ich habe noch etwas beobachtet. Wenn ich 3 mal hintereinander 0xC0E0
sende schaltet er den Clock ausgang auf 10 Mhz um. Sonst nicht NUR WENN
ICH 3 MAL sende!!!!???? Da muss doch was grundlegendes Falsch sein? Oh
man ich dreh noch durch hier, sorry.
Hoffnungsvolle grüße Moritz
Hallo,
weiß niemand ob das mit der Signalqualität so genau möglich ist?
Noch eine Frage: wie sollte ich die Antenne gestallten, wenn ich nur
eine Reichweite von 2m brauche?
megafreak wrote:
> weiß niemand ob das mit der Signalqualität so genau möglich ist?
Such mal, das habe ich schon ein paarmal erklärt, wo man das Signal
abgreifen kann.
> Noch eine Frage: wie sollte ich die Antenne gestallten, wenn ich nur> eine Reichweite von 2m brauche?
Garkeine. Bzw. Wenn du eine Antenne dranmachst, dann nimm einen 17cm
langen Kupferdraht mit etwa 0,5-1mm² und wickel den zu einer etwa 5cm
langen, etwa 5mm dicken Spule auf. Dann kannst du noch die Sendeleistung
am Modul selbst reduzieren.
Auf 2m Entfernung hat bei mir schon Sender mit 15cm Draht und Empfänger
ganz ohne Antenne, nur Steckbrett-Kontaktreihe, ausgereicht. Den Sender
hab ich dabei nie ohne Antenne getestet, weil die fest eingelötet ist.
Wieso willst du denn die Reichweite so stark begrenzen? Mehrere Sender
in der Nähe? Dann lieber die Frequenz wechseln.
Der Pin für die analoge Empfangsanzeige ist leider nicht auf die
Anschlussleisten gelegt. Irgendwo hat mal jemand gepostet, an welchem
der SMD-Teile auf dem Modul man das Signal anzapfen könnte. Ansonsten
gibt es noch die digitale RSSI-Abfrage. Da muss man anscheinend einen
Grenzwert vorgeben und bekommt dann die Rückmeldung ob der Wert drüber
oder drunter liegt.
Hi,
kann jemand der das Modul mit IRQs benutzt bitte kurz eine Pinbelegung
vom Atmel zum RFM12 posten? Ich verzweifle hier noch bei der Umsetzung
des IRQ-Betriebs mit dem Code von Jürgen.
Interessant wäre auch noch der genutzte Compiler, da ich mit GCC einige
Anpassungen am bestehenden Code vornehmen musste. Nicht dass der
Originalcode von Jürgen auf seinem Compiler ein volatile einfügt und
GCC nicht...
Danke vielmals
Lorenz
Hey,
@benedikt das wars danke!!! Jetzt funktioniert wenigstens die
Umschaltung auf 10MHz bei jedem mal senden! Vielen dank. Jetzt bleibt
nur noch das problem wenn ich 0x00 sende das nix zurück kommt! Haste
dazu noch ne idee?
Grüße
Moritz
Hallo Moritz,
ich habe auch das Problem, dass ich zwei RFM12 nicht zum laufen kriege
und ich baue das auch mit PIC's auf(16F876) .
Bei mir läuft der Empfänger schon (getestet mit einem RFM02 als Sender),
leider geht mein RFM12 als Sender nicht. Wie weit hast Du Deine Teile
schon am Laufen? Hier mein Quellcode:
Mit freundlichen Grüßen
Kalli
Ja...ääää ..richtig das ist Register 0x98xx, kannst Du mich eventuell
aufklären, was da eingestellt wird. Aus dem Datenblatt werde ich nicht
schlau :-(
Welches ist auf der Empfängerseite das dazugehörige Register (was dann
ja auch eingestellt werden muss, oder)?
Damit stellst du ein, welche Frequenzen bei einer 0 bzw 1 erzeugt werden
soll. Je größer die Frequenz, desto mehr Bandbreite benötigt man.
Allerdings ist dann natürlich auch der Abstand größer, so dass sich das
ganze leichter unterscheiden lässt. Ich stelle meist etwa 100kHz ein.
Beim Empfänger muss die Bandbreite entsprechend eingestellt werden. Dort
stelle ich meist 200kHz ein (etwa das doppelte wie beim Sender.) Ob das
die ideale Einstellung ist, weiß ich nicht, aber die Reichweite ist auf
jedenfall größer, als bei der im Datenblatt empfohlenen.
Hey,
Ich versuche gerade eine den Code von Benedikt für den ADUC831 zu
schrieben, aber irgendwie wird das nichts.
Ich will die Hardware SPI verwenden, brauch ich da den ganzen Code?
Ich muss nur die Register ändern dann müsste es doch gehen oder?
hallo Benedikt
Ich habe jetzt im Empfänger den Code 98D0(H) (FSK=210KHz)und im Sender
9860(H) (FSK=105KHz) eingestellt. Der Empfänger scheint aber den Sender
nicht zu "verstehen", denn senden tut das Teil: Wenn ich einen RFM02 als
Sender zum RFM12 nutze, funktioniert die Verbindung. Schalte ich dann
zusätzlich einen zweiten RFM12 als Sender ein, stört dieser die 1.
Verbindung. Wenn ich dann beim diesem RFM12-Sender die Antenne abziehe,
klappt die 1. Verbindung wieder (die zum RFM02). Da beide Programme die
selben Initialisierung haben gehe ich davon aus, dass irgend etwas in
dieser "Preambel" geschichte nicht stimmt
Ich habe jetzt testweise in den Empfänger die Patternerkennung
ausgeschaltet CA87(H) statt CA83(H) -> Jetzt empfängt das Teil. es ist
zwar nur Datenschrott, aber es bestärkt mich in der Annahme, das der
Fehler beim Sender in dieser Sektion steckt
Noch etwas auffälliges:
Am Ende der Senderoutine schalte ich TX aus mit 0x8208, der Sender
scheint aber weiter zu senden, da der Empfänger das Signal vom RF02
immer noch nicht empfängt. Erst wenn ich die Antenne abziehe und damit
die Sendeleistung reduziere (denke ich), wird der Empfang vom RFM02
wieder hergestellt.
Hi alle,
Warum der Sender nicht abschaltet, habe ich herausgefunden (glaube ich):
Ich schalte den Sender mit 0x8200 aus, vorher setze ich aber dien
SEL-Leitung kurz auf High und die CLK -Leitung und auf LOW
bsf SEL ;setze Bit für Selekt-Leitung
bcf SCK ;lösche Bit für Clock -Leitung
call warten2 ; warte
bcf SEL ; lösche Bit für Selekt-Leitung
danach nimmt das Modul wieder Steuerbefehle entgegen
Kann das jemand bestätigen, dass das daran liegt?, Muss das auch noch wo
anders z.B. vor dem Senden der Daten Preambel Syncwort geschehen?
Alle ratlos ???
ich vermute ein Timing-Problem bei meinem Sender, habe auch schon an
meinen Zeitschleifen rumgeschraubt.... nix
Gibt es noch was spezielles, worauf ich beim Übermitteln der zu
sendenden Daten achten muss?
Hilfeeeee...
Hast du schonmal geschaut ob die empfangenen Daten (bei ausgeschalteter
Syncword Erkennung) irgendwas mit den gesendeten zu tun haben, oder ob
was komplett anderes empfangen wird ?
Ansonsten ist noch zu beachten, dass die SPI Frequenz nicht mehr als
2,5MHz betragen darf.
Seid 3 Tagen bin ich jetzt dabei und irgendwie will das Moped nicht:
habe den RFM01 und 02 an jeweils einen ATMega16 angeschlossen. Der
Sender scheint unentwegt zu senden (hängt sich nicht auf, keine
Fehlermeldung beim Kompilieren, Signal anm SCK)
Der Empfänger hingegen hängt sich im "rf01_rxdata" in der Zeile "while
(!(RF_PIN&(1<<SDO))); // wait until data in FIFO" auf.
Interessant dabei ist: wenn ich den SDO abklemme und auf eine LED lege,
so blinkt diese als ob sie Daten empfangen würden und der Controller
hängt sich nicht mehr auf (zeigt dafür immer den selben Datenmüll an).
Lege ich den Pin MIT LED auf den Eingang, so kommt weder Datenmüll noch
blinkt die LED.
Habe leider kein Oszi, kann also wenig zu dem Signal sagen.
Meine Frage: Ist das Verhalten normal? Sollte ich lieber beim Sender
oder beim Empfänger nach dem Fehler suchen?
Danke im Voraus
ReinHerR
@ ReinHerR
leider kenne ich mich in der Programmierung in C nicht aus, aber um die
Teile zum Laufen zu bringen, solltest Du eventuell mal die hier
veröffentlichten Programme nehmen, dann hast Du wenigstens eine
Grundlage für dein Programm. Ich habe den nFFS-Pin am RFM01 mit 10k auf
H gezogen, vielleicht da mal nach sehen?
@ benedikt
die 8 angeschlossenen LED's am Ausgang des PIC's flackern unmotiviert
vor sich hin, mal mehr mal weniger. Da ist nichts gleichmäßiges zu
erkennen.
SPI: die Programmierung über die SPI-Schnittstelle klappt (denke ich)
weil ich ja am Anfang der Initialisierung auf 10MHz Clock Out umschalte
und später dann über die selbe Routine den Sender einschalte und die
Daten zum Modul schicke. Einziger Unterschied bei den Daten: Ich warte
am Ende immer auf ein H am SDO, bevor ich die nächsten Daten
übermittele.
...das ist ja das schlimme, ich habe den Code von hier, ausschließlich
erweitert durch die LCD-Routine, genauso angeschlossen wie beschrieben
und den 10k-Widerstand habe ich auch eingelötet. Blöde ist natürlich
dass ich keine Messgeräte habe um zu testen ob überhaupt der Sender
funzt. 433 Mhz ist a auch nicht gerade mit dem Ohrhörer zu detektieren
;-) Muss ich wohl mal jemanden mit ´nem Fernseher aufsuchen.
Inzwischen überlege ich ob evtl. die Platine selbst kaputt ist. Pollin
ist ja nicht unbedingt für gute Qualität berühmt und es sind ja
schließlich auch Restposten. Aber so recht glauben will ich das auch
nicht.
Gruß
ReinHerR
Also, was ich bis jetzt von Pollin bezogen habe, war alles OK, keine
def. Ware. Dieser Thread hier ist so lang und da glaube ich nicht, dass
das Programm für die RFM01/02 noch Fehler hat. Ich würde einfach mal was
einfaches an einen Port deines Prozessors ranhängen (kein LCD..)
vielleicht nur mal ne LED ein und ausschalten. Um so mehr Code, desto
größer die Fehlerwarscheinlichkeit.
KH
@Benedikt K.:
ich benutze bisher recht deine einfachen Routinen für die RFM12. Klappt
top.
Nur dass die Rx-Funktion blockiert bis sie Daten empfängt passt nicht zu
dem Programm in das sie jetzt integriert werden soll.
Also dachte ich mir: leg den FFIT auf nen PCInt, aktivier den RX mit
1
rf12_trans(0x82C8);// RX on
2
rf12_trans(0xCA81);// set FIFO mode
3
rf12_trans(0xCA83);// enable FIFO
und warte auf den PCInt. Sobald der kommt les ich dann wie gehabt mit
1
for(i=0;i<number;i++)// number is natürlich definiert
2
{rf12_ready();
3
*data++=rf12_trans(0xB000);
4
}
die Daten aus. Danach wird der Fifo und die Patternerkennung neu
gestartet und ich warte auf die nächsten Daten.
Leider klappt das nur genau ein mal und danach kommen immer nur noch die
ersten zwei Byte korrekt, die restlichen 4 zappeln wild.
Aktivier ich den RX aber wie oben beschrieben und starte dann deine
Rx-Funktion sobald der PCInt kommt sind die Daten immer einwandfrei.
Ich muss also immer die "RX-On Präambel" (die drei Befehle oben)
schicken direkt bevor ich Daten auslese.
Kann sich das jemand erklären?
Ich meine, es ist nicht schlimm, hat aber ne weile gedauert zum drauf
kommen und ich verstehs nich. ;-)
Danke und Gruß
Fabian
Wenn ich das richtig verstehe, startest du die Sync Word Erkennung nach
jeder Übertragung neu, aber es funktioniert trotzdem nur das 1. mal
richtig ?
Und sobald der FFIT Pin aktiv ist, liest du das ganze Paket auf einmal
ein ?
Das klingt so, als wenn rf12_ready(); nicht richtig funktioniert, warum
auch immer.
Ich habe FFIT invertiert an INT0 gelegt, das funktioniert wunderbar:
Solange der Pegelgesteuerte Interrupt aktiv ist, sind Daten im
Empfangspuffer.
Exakt.
Das mit der Syncword Erkennung geht ja auch gar nicht anders oder?
Der Sender sendet aktuell sein Datenpaket im Loop immer wieder.
Ich kann auch nochmal ein abgespecktes Codestück anhängen wenn Bedarf
besteht.
Gruß
Fabian
Die "echten" Interrupts waren nimmer frei. darum hängts an nem PCInt und
der feuert ja bei jedem Pegelwechsel. Darum deaktivert sich der
Interrupt auch selbst und wird erst wieder nach dem Auslesen aktiviert.
Aber wie ichs drehe und Wende ich komme nicht ohne diese "Präambel aus".
Kannste mir vieleicht mal nen Schnipsel schicken wie du die Daten dann
im Int ausliest?
Gruß
Fabian
Aso, ja... hatte ich mal reingeschaut, aber nicht genauer, weil mir das
mit crc usw doch etwas overkill war.
seh aber grad, so schlimm isses ja nich.
Diesen Effekt erklärt es aber nicht wirklich.
Die einzige Idee die mir grad noch kommt: Das Modul ist ein RFM12 V1.0
von Pollin. Die Anderen (z.b. Aus der Sammelbestellung) sind alle V3.0.
Vieleicht war das ja auch ein Bug.
Hauptsache es funktioniert jetzt.
Gruß
Fabian
Hallo,
ich arbeite mich gerade in das thema ein, und bin etwas überwältigt von
der vielfalt an informationen die in mehr oder weniger 3 threads hier
verteilt sind. ich bin jetzt seit 2 tagen dabei mir einen überblick zu
verschaffen und naja, es ist viel.
mein ziel ist es das rmf12 an einen at90can128 anzuschließen.
als grundlage habe ich den code von benedikt (weiter oben
rfm12_rs232_rxtx_check_int.zip ) angenommen.
jetzt gibt es knapp 10 weitere ausführungen dieses oder eines ähnlichen
codes in diesem thread:
Beitrag "bidirektionale RS232 Funkbrücke mit RFM12"
mein ziel ist eine bidirektionale verbindung zwischen 2 modulen mit
einer ü rate von 19200baud. und später mal eine 1 zu n übertragung.
@benedikt:
ich habe die sourcen des (rfm12_rs232_rxtx_check_int.zip (hier)) soweit
an meinen controller angepasst.
wenn ich richtig sehe, verwendest du in programm:
1) die sourcen von Peter Fleury
2) einen softwareuart
ich habe die sourcen an den at90can128 soweit angepasst, dennoch sind
fragen offen.
-zum schaltplan, warum verwendest du den fet bs170 in deiner schaltung,
hat der atmega8 keine flankeneinstellungen oder was war der grund?
-ist die grundlage gut für mein vorhaben, oder gibt es hier einen
passenderen code?
ich frage mich natürlich immer noch, ob der code zum kennenlernen gut
geiegnet ist, oder ob ich doch den ersten hier geposteten code nehmen
sollte:
doch dabei ist mir aufgefallen das die c datei dort rf12 heißt, der code
ist doch aber für das modul rfm12, oder!?
-gilt der schaltplan in: rfm12_rs232_rxtx_check_int.zip auch für
rfm12.zip (2,3 KB, 1976 Downloads)
@All:
ihr steckt hier schon länger drin, und ich erst seit 2 tagen und ich
muss jetzt einfach einp aar fragen stellen, bevor ich hier völlig den
verstand verliere, bei der menge datenblätter, codeschnipsel, hinweise
und schaltpläne.
es wurde ja schon mit einer übersicht begonnen:
https://www.mikrocontroller.net/attachment/24947/RFM12.txthttp://www.mikrocontroller.net/articles/RFM12
was auch wirklich schon etwas hilft.
ich habe das transceiver modul von pollin RFM12, zumindest hoffe ich das
pollin nicht auch da noch unterschiedliche verkauft hat, es scheint ja
noch weitere zu geben:
RF12 (sieht aber anders aus als meins)
RFM12BP (ebenfalls)
RFM12B (ähnlich)
allerdings war bei dem pollin modul das datenblatt zum RFM12 dabei,
deswegen gehe ich mal davon aus, das es das dann auch ist.
zu dem von pollin beigefügten code gab es damals die aussage das er
fehler enthält.
ich hoffe ich bin auf dem richtigen weg.
dank an euch,
m.
maddin wrote:
> wenn ich richtig sehe, verwendest du in programm:>> 1) die sourcen von Peter Fleury
Ja
> 2) einen softwareuart
Nein.
> -zum schaltplan, warum verwendest du den fet bs170 in deiner schaltung,> hat der atmega8 keine flankeneinstellungen oder was war der grund?
Der pegelgetriggerte Interrupt ist nur Low aktiv, der RF12 gibt aber
einen Highpegel aus, solange Daten im Puffer sind.
> -ist die grundlage gut für mein vorhaben, oder gibt es hier einen> passenderen code?
Der Unterschied zwischen den Versionen ist, dass die oberste alles per
Software macht, während die neueren die SPI Schnittstelle und Interrupts
verwenden.
> doch dabei ist mir aufgefallen das die c datei dort rf12 heißt, der code> ist doch aber für das modul rfm12, oder!?
Das IC heißt RF12, das Modul RFM12.
> -gilt der schaltplan in: rfm12_rs232_rxtx_check_int.zip auch für> rfm12.zip (2,3 KB, 1976 Downloads)
Nein
> RF12 (sieht aber anders aus als meins)
Das ist nur das IC, das hast du ganz sicher nicht.
> RFM12BP (ebenfalls)
Das ist in Deutschland nicht zulässig
> RFM12B (ähnlich)
Das müsste einen anderen Anschluss haben (Stiftleisten statt SMD). Das
von Pollin verkaufte heißt korrekt glaube ich RFM12-433S1 oder so
ähnlich.
Von der Software her sind aber alle gleich.
@benedikt,
vielen dank für die schnelle antwort.
zählt rfm12_rs232_rxtx_check_int.zip auch zu den neuen, wie auch die im
beitrag funkbrücke!?
in dem angehängten code aus dem beitrag:
bidirektionale RS232 Funkbrücke mit RFM12
sind ebenfalls schaltpläne, dort ohne bs170, dennoch mit atmega8. liegt
dies daran das dort noch gepollt wird?
der code stammt aus einem thread bereich indem du ebenfalls eine
funkstrecke mit 19200 baud aufbaust.
ich will in erster linie die module kennen lernen ist der link
https://www.mikrocontroller.net/attachment/24947/RFM12.txt
eine gute zusammenfassung.
welche software würdest du mir als grundlage empfehlen, oder ist
rfm12_rs232_rxtx_check_int.zip gut!? er lässt sich jedenfalls schon sehr
gut portieren.
ich frage nur, da ich mich sonst noch durch atmega8 datenblätter, durch
das gesamte vorgehen von dir im beitrag funkbrücke kämmen müsste.
welcher schaltplan passt zu rfm12.zip hier?
vielen dank, bis hier hin,
m.
hallo benedikt,
ich welchem thread liegt dieser code?
gibts dazu einen schaltplan, leider muss ich den code portieren und
dazu auch einen passenden verdrahtungsansatz wählen.´
wird dort gepollt, oder ist es interruptgesteuert?
wird spi genutzt?
wie gesagt, der code aus rfm12_rs232_rxtx_check_int.zip ist ja schon
fast gänzlich portiert.
gruß,
m.
maddin wrote:
> ich welchem thread liegt dieser code?
Hier:
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"> gibts dazu einen schaltplan, leider muss ich den code portieren und> dazu auch einen passenden verdrahtungsansatz wählen.´
Nein, denn die Pins lassen sich in der rf12.c beliebig umbelegen.
> wird dort gepollt, oder ist es interruptgesteuert?
Nur gepollt, der Code ist daher weitestgehend µC unabhängig.
> wird spi genutzt?
Nein.
> wie gesagt, der code aus rfm12_rs232_rxtx_check_int.zip ist ja schon> fast gänzlich portiert.
Den kannst du auch nehmen, aber eigentlich gibt es da ja nicht viel zum
Portieren. Die Ports anpassen, und fertig.
@benedikt,
>>Den kannst du auch nehmen, aber eigentlich gibt es da ja nicht viel zum
Portieren. Die Ports anpassen, und fertig.<<
so war es auch, nur im global int reg, und hier und da ein wenig (uart)
usw..
dann bleiben eigentlich nur noch 3 fragen, bevor ich starten kann.
1) wird hier
http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip
der FFIT PIN auch invertiert genutzt?
2) wird das CTS Handschaking signal bei deinem programm genutzt, muss es
also "mitgeroutet" werden!?
3) in den meisten aplikationen wird der mikrocontroller vom RFM12
gesteuert, bei den boards die ich einsetze, ist bereits ein 16Mhz quarz
vorhanden, kann das zu problemen führen, muss ich das 10mhz sig. des
rfm12 nutzen (synchronisation, timings) oder KANN ich es nutzen, und
reicht es F_CPU anzupassen?
bis dahin, vielen dank für die Schnelle reaktion an dich.
gruß,
m.
maddin wrote:
> 1) wird hier> http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip>> der FFIT PIN auch invertiert genutzt?
Nein, hier der Pin garnicht verwendet.
> 2) wird das CTS Handschaking signal bei deinem programm genutzt, muss es> also "mitgeroutet" werden!?
Es wird nicht verwendet.
> 3) in den meisten aplikationen wird der mikrocontroller vom RFM12> gesteuert, bei den boards die ich einsetze, ist bereits ein 16Mhz quarz> vorhanden, kann das zu problemen führen, muss ich das 10mhz sig. des> rfm12 nutzen (synchronisation, timings) oder KANN ich es nutzen, und> reicht es F_CPU anzupassen?
Es reicht die Frequenz anzupassen. Bei der SPI Version muss die SPI
Frequenz eventuell langsamer gestellt werden, da diese nicht schneller
als 2,5MHz sein darf.
Hallo Benedikt,
>>Nein, hier der Pin garnicht verwendet<<
ählich wie hier?
Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module"
rfm12schaltplan.tif
im gegensatz zu deinem schaltplan (mit FFIT) wird hier dann NIRQ für die
Rückmeldung genutzt!?
in dem sw paket rfm12_rs232_rxtx_check3__6.zip ist keiner der beiden
pins genutzt?
m.
maddin wrote:
> im gegensatz zu deinem schaltplan (mit FFIT) wird hier dann NIRQ für die> Rückmeldung genutzt!?
Das geht auch, man spart sich den Inverter, allerdings geht NIRQ bei
allen möglichen Sachen auf Low. Dann muss man erst suchen, was die
Ursache dafür war.
> in dem sw paket rfm12_rs232_rxtx_check3__6.zip ist keiner der beiden> pins genutzt?
Da wird gepollt.
Hallo Benedikt,
ich habe den aubau der funkmodule samt antenne, die "einarbeitung" ins
studio sowie das aufstellen einer "teststrecke" für eine bidirektionale
datenü. am samstag soweit durch bekommen.
heute sitze ich noch an der "portierung deines codes"
die pins sind angepasst,
die interrupt register.
der kram lässt sich fehlerfrei kompilieren und flashen.
der 500hz trigger kommt.
cs kommt.
dennoch musste ich eh auch im datenblatt des atmega8 kramen.
hier bin ich noch über:
MCUCR gestolpert.
ISC11 ISC10 Description
0 0 The low level of INT1 generates an interrupt request.
0 1 Any logical change on INT1 generates an interrupt request.
1 0 The falling edge of INT1 generates an interrupt request.
1 1 The rising edge of INT1 generates an interrupt request.
mich wundert nach wie vor deine invertierung, oder habe ich da noch ein
falsches datenblatt erwischt, kenne die atmels sonst noch nicht.
spi clock muss noch überprüft werden (<2,5Mhz) irgentwas stimmt da noch
nicht ganz.
bis hier hin, erstmal vielen dank für die Unterstützung,
m.
maddin wrote:
> ISC11 ISC10 Description> 0 0 The low level of INT1 generates an interrupt request.> 0 1 Any logical change on INT1 generates an interrupt request.> 1 0 The falling edge of INT1 generates an interrupt request.> 1 1 The rising edge of INT1 generates an interrupt request.>> mich wundert nach wie vor deine invertierung, oder habe ich da noch ein> falsches datenblatt erwischt, kenne die atmels sonst noch nicht.
FFIT ist solange high, wie Daten im Puffer sind. Ich benötige also einen
Intterupt, der solange gestartet wird, wie ein Pin high ist.
Warum? In der ISR liest du 1 Byte Daten aus und dann überprüfst du FFIT
ob er noch High ist, wenn ja liest du das nächste Byte in der gleichen
ISR. Defakto also eine Schleife in der ISR die solange Bytes liest bis
FFIT auf LOW geht.
Gruß Hagen
...ich verstehe den grund immer noch nicht, aber ich werde es erstmal
selbst versuchen, ich bin ja froh für die unterstützung.
Interrupt = Unterbrechungsanforderung
ausgelöst durch ein ereignis (flanke).
...oder habe ich etwas übersehen?
werde die tage abends an meinem code weiterarbeiten, und mal sehen das
ich die funkmodule angesteuert bekomme, viel kann es nicht mehr sein -
hoffe ich ._)
m.
Ein Interrupt kann halt auch duch einen Level ausgelöst werden... das
ist z.B. nötig, wenn der uC im DeepSleep ist, wo der Takt abgeschaltet
ist. Flanken kann man nur mit Takt erkennen!
Ich mach das mit dem FFIT übrigens genauso wie HagenRe. Funktioniert
wunderbar.
Gruß
Fabian
...hier noch ein Bild und Hinweis für Lochraster Testaufbauten...
das modul hat ja bekanntlich ein 2mm Raster.
es besteht trotzdem die möglichkeit es auf lochraster zu setzen,
wenn man die Pins wie folgt abwinkelt:
O O | | O |
O O | | O |
O= Pin
|= abgewinkelt und mit Kupferlackdraht durchgeführt
man benötigt natürlich Pinleiste und Federleiste.
gruß,
m.
Sicher?
Ich gehe jetzt mal nicht davon aus, dass die Zeichnung maßstaßsgetreu
ist, aber 2 sieht doppelt so lang aus wie 1.
Oder sieht das nur so aus?
Aber danke trotzdem :-)
Hab grad nochmal mit dem Meßschieber nachgemessen: die angaben von
Thomas kommen auf ca 0.1mm hin.
Ich hatte für 1) ca 0.9mm, für 2) ca 1,05mm
Gruß
Fabian
Hallo,
ich versuche gerade ein RFM02-Modul zum Laufen bekommen, bin allerdings
schon daran gescheitert, wie ich es anschließen soll.
Klar hab ich mir die Pinbelegung (auch das Datenblatt des ICs und alle
Befehle, etc.) angeschaut, aber da die Anwendung, die ich realisieren
möchte, etwas zeitkritisch ist, hatte ich gehofft, das RFM02 mit der SPI
eines ATmega8515 ansteuern zu können, anstatt die Schnittstelle selber
zu implementieren, wie das hier bei den Beispielprogrammen war.
Aber es sind einfach zu viele Sachen unklar, als dass ich gescheit was
planen könnte.
Verstehe ich das richtig, dass über den nIRQ-Pin beim Senden der Daten
ein Takt (Baudrate) kommt, außerdem noch die Interrupts und man kann
auch noch das Statusregister auslesen?
Bloß ist das Statusregister nirgendwo dokumentiert, was bringt mir das
dann? Außerdem steht im Datenblatt des RF02 was von asynchroner
Übertragung am FSK-Pin.
Und bei dem "Data Transmit"-Befehl wird in dem Beispieldiagramm für ein
Senden via FSK eben nicht der "Data Transmit"-Befehl gesendet, sondern
"Power Management". So nach dem Motto: Hier kommt noch irgendein Befehl
und wenn du was auf dem FSK-Pin sendest, merkt der Chip das von selber.
Aber das kann doch nicht sein, schließlich gibt es kein Start-Bit oder
so. Außerdem, wenn das mit dem Takt über nIRQ stimmt, woher weiß der
RF02 dann, dass er mit dem Takt starten soll.
Ich hatte mir das jetzt so gedacht: Ich verbinde MOSI mit SDI und MISO
mit FSK, dann könnte ich die Befehle im Master-Mode senden und das
Clock-Signal erzeugen, für die Daten auf Slave umschalten und dann den
nIRQ an den Clock-Pin hängen. Geht das, oder reicht das Signal am nIRQ
nicht aus für ne saubere Clock? Könnte man das vielleicht
nachbearbeiten, mit nem Monoflop z.B.?
Dann hab ich immer noch keinen blassen Schimmer, was ich mit den
Interrupts machen soll, aber ich wäre schonmal glücklich, wenn überhaupt
was funktionieren würde.
Oder gibt es noch ne bessere Möglichkeit mit der SPI? Ich werde hier
langsam verrückt, ich suche schon seit Stunden und NIRGENDWO gibt es die
Infos, die ich suche.
Wäre sehr dankbar für Hilfe!
Julian Krick wrote:
> Verstehe ich das richtig, dass über den nIRQ-Pin beim Senden der Daten> ein Takt (Baudrate) kommt, außerdem noch die Interrupts und man kann> auch noch das Statusregister auslesen?
Ja, so in etwa. Der Takt kommt aber nur, wenn dieser aktiviert wird.
> Bloß ist das Statusregister nirgendwo dokumentiert, was bringt mir das> dann? Außerdem steht im Datenblatt des RF02 was von asynchroner> Übertragung am FSK-Pin.
Es gibt mehrere Möglichkeiten:
- Das Modul kann als dummes FSK Modul arbeiten, d.h. die Daten am FSK
Pin werden direkt gesendet.
- Man kann die Daten über den SDI Pin senden, das sollte dann synchron
zur Baudrate ablaufen.
> Und bei dem "Data Transmit"-Befehl wird in dem Beispieldiagramm für ein> Senden via FSK eben nicht der "Data Transmit"-Befehl gesendet, sondern> "Power Management". So nach dem Motto: Hier kommt noch irgendein Befehl> und wenn du was auf dem FSK-Pin sendest, merkt der Chip das von selber.
Bei diesem Modus muss man den Sender einschalten, danach sendet er dumm
was am FSK Pin anliegt.
Im anderen schaltet sich der Sender selbst ein.
> Ich hatte mir das jetzt so gedacht: Ich verbinde MOSI mit SDI und MISO> mit FSK, dann könnte ich die Befehle im Master-Mode senden und das> Clock-Signal erzeugen, für die Daten auf Slave umschalten und dann den> nIRQ an den Clock-Pin hängen.
Sollte eigentlich funktionieren (auch wenn ich es noch nicht ausprobiert
habe.)
Hallo Benedikt, danke erstmal für die Antwort.
Verstehe ich das richtig, dass der Sender, wenn ich ihn per
Power-Management-Befehl aktiviert habe, dann die ganze Zeit sendet, was
an FSK anliegt? Also auch, wenn ich gar nichts dort hin sende?
Also selbstverständlich nur, wenn ich ihn in dem entsprechenden Modus
betreibe.
Wenn ich den nIRQ-Pin als Clock für die SPI nehme, dann muss ich doch
verhindern, dass auch wirklich Interrupts darüber kommen. Wie kann ich
das denn abstellen? Ich hab im Datenblatt keinen Befehl gefunden, um zu
kontrollieren, ob Interrupts gesendet werden oder nicht. Geht das
überhaupt?
Ich bin mir noch nicht sicher, was ich machen möchte, also ob Daten über
FSK oder über SDI. SDI erscheint mir praktischer, allerdings habe ich
keinen Schimmer, wie ich das SPI-Interface auf die Baudrate takten soll.
Es stimmt doch, dass ich, wenn ich die Daten über SDI sende, sie
ebenfalls mit der eingestellten Baudrate senden muss, schließlich fällt
das Clocksignal weg.
Ich verstehe nicht, warum die diese Dinger bauen und dann nicht gescheit
dokumentieren. grrrr
Hallo benedikt, hallo fabs
ich habe gas gleiche Problem wie weiter oben schon von fabs erwähnt,
dass nach dem 2. Datenbyte nur noch Datenmüll am Empfänger ankommt. Ich
habe festgestellt, dass die Bits beim 3. Byte versetzt ankommen (1.Bit
an Position3 ...). Ich meine, ich lese den FIFO zu früh / zu schnell
aus. Wie habt ihr das gelöst? Der nIRQ-Pin ist bei mir immer L . Muss
ich den erst aktivieren (und wie)?
nimm nicht den nIRQ, der Signalisiert viele Dinge. nimm den FFIT, der
signalisiert sobald der FIFO mehr als die eingestellten Bits enthält.
Bei mir hat sich das inzwischen erledigt...
ich mach das so (etwas abgespeckt):
go wird hierbei in einem PinChange interrupt gesetzt sobald sich am FFIT
was tut.
Es is übrigens wichtig, dass sich der PC-INT direkt erstmal selbst
deaktiviert und sein Flag vor dem reaktivieren auch nochmal gelöscht
wird!!
Gruß
Fabian
vielen Dank für die schnelle Antwort.
Der Tipp mit dem FFIT war schon mal genial. Trotzdem kommt der Empfänger
aus dem Tritt. Wenn ich mir die Signale oszilloskopiere sehe ich, dass
nach dem 4. H-Signal am FFIT (ich sende insgesamt nur 4 Bytes) kein
stehendes Signal am SDO anliegt. ABER: Der Fehler ist weg, wenn ich
zusätzlich zu meinen 4 Nutz-Bytes noch 2 "Dummy"-Bytes sende, die ich im
Empfänger aber nicht auslese.
Leide verstehe ich kein C, ich mach das in Assembler auf einem PIC.
Deshalb noch mal eine Frage zum Empfänger: Nach jedem Byte das ich
0xB0xx auslese muss ich die SEL-Leitung einmal kurz auf H legen, sonst
klappt die Verbindung auch nicht. ist das in euren C- Programmen auch
so?
Karl-heinz Lachmund wrote:
> ABER: Der Fehler ist weg, wenn ich> zusätzlich zu meinen 4 Nutz-Bytes noch 2 "Dummy"-Bytes sende, die ich im> Empfänger aber nicht auslese.
Du denkst beim Sender daran, dass dieser ein 16bit Sende FIFO hat ?
> Leide verstehe ich kein C, ich mach das in Assembler auf einem PIC.> Deshalb noch mal eine Frage zum Empfänger: Nach jedem Byte das ich> 0xB0xx auslese muss ich die SEL-Leitung einmal kurz auf H legen, sonst> klappt die Verbindung auch nicht. ist das in euren C- Programmen auch> so?
Ja, steht ja auch so im Datenblatt, dass man nur 8bit lesen kann.
> Du denkst beim Sender daran, dass dieser ein 16bit Sende FIFO hat ?
Nach 3*Preambel und 2 Sync-Bytes schicke ich meine 6 Datenbyts zum Modul
(0xB8xx). Nach jedem dieser 11 Bytes warte ich auf ein H am DSO. Ist das
falsch?
Karl-heinz Lachmund wrote:
> Nach jedem dieser 11 Bytes warte ich auf ein H am DSO. Ist das> falsch?
Ja, wenn du danach keine Dummybytes mehr sendest.
Danach ist mindestens noch 1 ungesendetes Byte im FIFO, das verloren
geht wenn du sofort abschaltest.
OK, wieder ein Stückchen schlauer :-)
Mich störts, wenn man nach langem rumprobieren was zum laufen bekommt,
aber nicht genau weiß, warum das jetzt so muss.
Vielen Dank
Hi.
Da ich jetzt eine Batteriebetriebene Anwendung (Fernbedienung) mit dem
RFM12 habe muß ich natürlich am Strom etwas knapsen.
Im DB des RF12 steht ja was von StandbyCurrent 0.1uA. Leider finde ich
nirgends eine Angabe, wie ich das Modul in diesen Standby Modus setze.
Reicht es den TX abzuschalten (RX ist eh aus)? Oder muß ich zusätzlich
noch den WakeupTimer nutzen? Spart es dann noch Strom wenn ich nicht den
CLK-Output vom Modul nutze und ihn deaktiviere?
Richtig abschalten (über Transistor) ist nicht wirklich praktikabel, da
das Modul ja min 100ms zum starten braucht und der Benutzer wohl kaum
100ms Delay auf einen Tastendruck toleriert.
Wie kann man das Teil noch am Strom fressen hindern? Wie gesagt, ich
will nur ab und zu was senden wenn auf der Fernbedienung eine Taste
gedrückt wird.
Gruß
Fabian
Schalte alles aus, was du nicht brauchst, auch den Crystal Oscillator.
Dann sollte die Stromaufnahme in der Nähe des Datenblattwertes sein. Die
Zeit bis das Modul danach wieder bereit ist, beträgt etwa 10ms.
Fabian B. wrote:
> und danach is Power Management Register 0x8201 schreiben... also alles> aus.>> Den WakeupTimer braucht man dafür also nicht?>> Gruß> Fabian
Hallo Fabian,
richtig, dafür brauchst du den WakeupTimer nicht, du kannst das Modul
einfach über die SPI Schnittstelle wieder einschalten. Allerdings
verbraucht dein Mikrocontroller dann immer noch relativ viel Strom. Du
könntest ihn natürlich auch schlafen legen. Um ihn dann wieder
aufzuwecken würde sich theoretisch der WakeupTimer eignen, da nach
Ablauf der eingestellten Zeit das Modul einen Interrupt wirft. Leider
bin ich dabei auf große Probleme mit dem Modul bezüglich
Langzeitstabilität gestoßen. Hier habe ich das Ganze beschrieben und
auch eine andere Möglichkeit zum Stromsparen aufgezeigt.
Beitrag "Re: RFM12: Erfahrungen"
Das funktioniert jetzt seit einigen Wochen richtig gut.
Gruß
Björn
Den uC will ich übern Interrupt wecken... der kommt aber nicht vom
RFM12, ist als nicht das Problem.
Aber danke, den Thread werd ich mal lesen.
Gruß
Fabian
Hallo,
habe mir auch 4 RFM12-Module gekauft. Gibt es irgendwo einen Finalen
Code und Schema? Der Thread ist groß um ihm ganz durch zu lesen.
Und wie oder mit was kann ich die Antenne machen? Das Modul soll in eine
Art Fernbedingung rein. Darf also nicht eine Lange antenne oder Kabel
sein.
Danke
Hi!
Als Antenne eignet sich im einfachsten Falle eine Drahtantenne. Je nach
Frequenz sollte sie 15cm (433 Mhz) oder 8,7cm (868 MHz) sein. Mehr dazu
findest du im Thread, oder an anderer Stelle hier im Forum. Einfach mal
nach "Antenne".
gruß bobkins
Ich nehm immer 16cm Draht und wickel den um nen Bleistift... ist
Leistungstechnisch sicher nicht optimal aber reicht für indoor dicke.
Und es ist nicht so groß. Du kannst, wenns dir nicht um maximale
Reichweite geht aber die ca 16cm Draht auch einfach "irgendwie" in die
FB "reinstopfen".
Es gibt ja verschiedene Codes je nach Anwendung. Ich benutze Code auf
der Basis von Benedikts RFM12_RX_TX_beispiel.zip.
Gruß
Fabian
Ich hätt da nochmal ne Frage an die Profis:
ich hab jetzt meine Fernbedienung ohne das RFM12 bis auf <10uA
Stromverbrauch runter gebracht... aber das RFM12 braucht selbst wenn ich
alles (Osz., Clock out, Baseband) abschalte immernoch rund 300-350uA.
Das ist ja schon etwas weit weg von den 0.3uA die im Datenblatt
angegeben sind.
Ich hab auch schon den PullUp an FSK so groß wie ging gemacht (ca 100K),
der frisst zwar auch noch was aber das Gro macht das Board selbst.
Mehr abschalten kann ich ja wohl kaum?!
Ich will ungern dem Modul vollständig den Saft abdrehen...hat jemand
noch ne Idee?
Gruß
Fabian
Alle Eingänge des Moduls sind auf einem definierten Pegel:
nRes wird vom uC auf High gehalten (über Pullup) (ist Strommäßig aber
egal)
FSK liegt direkt über 100k an VCC (mehr geht nicht sonst wird die
Funktion des Moduls zufällig)
SDI, nSel und SCK werden durch den uC aktiv getrieben.
ins Power Management Register schreibe ich 0x8201, also im Prinzip
"alles aus".
Hast du mal bei dir gemessen, wie weit du mit dem Stromverbrauch des
Moduls "runter kommst"? Ich bin ja immerhin noch 3 Größenordnungen vom
angegebenen entfernt...andererseits sind die 0.3uA auch direkt aus dem
Chip-DB übernommen...auf dem Modul is ja noch ein bissi was drauf,
vieleicht gehts einfach nicht besser...
Gruß
Fabian
@ Richard B.: Nimm irgendeinen Draht. Ich nehm hier Schaltdraht 0,2qmm.
Mal noch ne Frage zum Stromverbrauch:
Ich hab langsam den Verdacht, daß nicht das RFM12 der "Verbraucher"
meiner gesuchten 300uA ist sondern die Verkabelung selbst. Es ist mein
erstes so verbrauchssensibles Projekt von daher fehlt mir da etwas das
Gefühl, aber ich hätte eigentlich nicht gedacht, daß ich scheinbar auf
einer gefädelten Lochrasterplatine so hohe Leckströme haben kann. Ist
das möglich?
Die <10uA ohne RFM12, von denen ich oben schrieb, waren wohl ne
Fehlmessung :(.
Muß ich wohl doch mal wieder ne Platine backen und mal dann probieren.
Ärgerlich finde ich aber, daß das JTAG-ICE2 knapp 700uA aus der
Schaltung zieht...das macht das Messen etwas umständlich.
Gruß
Fabian
Fabian B. wrote:
> Ärgerlich finde ich aber, daß das JTAG-ICE2 knapp 700uA aus der> Schaltung zieht...das macht das Messen etwas umständlich.
Der interne Pegelwandler will auch versorgt werden...
Richard B. wrote:
> Kann man das Modul von Pollin auch mit einem AVR benutzen?> Hat das einer Versucht?>> Sensor-Funkübertragung> http://www.pollin.de/shop/detail.php?pg=NQ==&a=MjE0OTQ0OTk=
Klar kann man das auch an einen AVR hängen, aber es übermittelt halt
keinen Datenstrom, sondern nur den Zustand eines einzigen Schalters.
Das ist ein völlig anderes Modul als die, um die es in diesem Thread
geht. Mach dafür bitte einen neuen Thread auf, falls es weitere Fragen
dazu gibt.
Hallo
habe paar RFM12-868 Module gekauft, code von Benedikt genommen
(Software-SPI), und etwas angepasst (lediglich Sendefrequenz).
Habe aber ein Problem: der Sender wird zwar richtig initialisiert (10MHz
am CLK, rauschtöne beim senden), beim senden hängt er in der
rf12_ready() in dieser Schleife:
while (!(RF_PIN&(1<<SDO)));
Habe schon lange drum gefummelt, kriege es leider nicht geregelt. Wenn
ich z.B. in diese Schleife lösche, dann schein es mindestens irgendwas
zu senden (habe mit TV-Tuner bei 855,75 deutliche Tone im
Sekundeninterval).
Habe schon mit timeout versucht: die Warteschleife wird nur dann
verlassen, wenn der counter==0 ist. Es kommt also nichts am SDO.
Vor paar Tagen habe ich rfm12-434 als Empfänger und rf01-434 als Sender
zum laufen bekommen, es funktioniert einwandfrei.
woran kann das liegen, dass SDO nicht auf High gezogen wird, und das
beim !Senden!? Habe gelesen, dass manche solches Problem beim Empfänger
hatten, komme aber nicht weiter.
PS: Hardware - ATTiny2313, 4 MHz extern getaktet, RFM12-868-D
Belegung:
RF12 Tiny
SDO 0
SDI 3
nSEL 2
SCK 1
, alle anderen nicht angeschlossen
Danke im Voraus
Hallo
nach langem Lesen (das muss man ja auch können :)) habe ich mein Fehler
entdeckt: und zwar habe ich den PollUp vergessen. Der Sender sendet
also.
Dann hatte ich folgenden Problem (wie hier schon einige berichtet
haben):
rf12_ready() Schleife beim Empfänger hing ewig. Habe einen Timeout
eingebaut, es hat funktioniert, die Schleife wurde jedesmal nur nach
diesem Timeout verlassen. Dadurch wurden nur 3 erste Bytes aus dem FIFO
abgeholt (für meine Zwecke würde das reichen), und mehr nichts, außerdem
dauerte das FIFO-Lesen viel zu lange(was nicht akzeptabel war).
Habe lange mit Status-Register gespielt, Timeout verändert und noch
ganze Weile herumprobiert, hat auch nichts gebracht.
Dann habe ich die o.g. Methode geändert, und zwar so:
1
voidrf12_ready(void)
2
3
{
4
unsignedlongtimeout=0;
5
RF_PORT&=~(1<<CS);
6
#asm
7
nop
8
#endasm
9
//wait until FIFO ready or timeout
10
while(!(RF_PIN&(1<<SDO)))
11
{
12
RF_PORT|=(1<<CS);
13
RF_PORT&=~(1<<CS);
14
if(((timeout++)>100000)){break;};
15
};
16
RF_PORT|=(1<<CS);
17
}
ich habe also in der while-schleife, in der auf High am SDO gewartet
wird, nSEL auf High und wieder auf Low gesetz, und jetzt geht es besser,
es funktioniert zu mindestens so, wie ich das gerne hätte.
Jetzt ist die Frage: woran könnte das liegen?
Hallo
Arbeitet hier auch jemand mit dem RFM02?
Ich arbeite mit einem Mega8 und AVR-Studio. Das Modul schaltet nicht auf
10MHz um und tut auch sonst nichts. Gibt es irgend was grundlegendes zu
beachten?
Hat sich erledigt.
Ursache war das Pollin-Funkboard. Der Optokoppler schaltet die Spannung
etwas verzögert ein. Abhilfe ist entweder den Optokoppler überbrücken,
dann ist auch ein programmieren möglich ohne das man die SCK-Leitung vom
Funk-Modul trennt, oder man wartet 100msec bis man mit den init beginnt.
Hallo,
hab ich das richtig vestanden, das FSK,DATA und nFFS keinen Pullup
Widerstand brauchen? Was mache ich mit den Ausgängen?
Hat einer ein simplen Schaltplan? Habe hier nichts gefunden.
Danke
Hallo,
ich verweise dich mal auf einen anderen Thread.
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"
In der Zip-Datei findest du auch einen Schaltplan und ein Programm, mit
dem du eine Funkbrücke machen kannst.
Gruß Gerd
Wie stark beeinflusst die Form einer Drahtantenne die Sendeleistung,
bzw. Reichweite?
Ich möchte den Sender für eine Fernbedienung nutzen und habe in der
Länge nur ca. 10cm Platz.
Soll ich einen 17cm langen Draht zu einer langen Spule aufwickeln oder
den Draht auf 10cm kürzen?
Beim Empfänger hab ich genug Platz, so dass die 17cm Drahtantenne kein
Problem machen wird.
Ich möchte knapp 10m Entfernung überbrücken (direkte Sichtverbindung).
Noch was:
Haben die Sendemodule bei jemand schon größere EMV Schwierigkeiten bzw.
Störungen am PIC/AVR verursacht?
Igor Metwet wrote:
> Soll ich einen 17cm langen Draht zu einer langen Spule aufwickeln oder> den Draht auf 10cm kürzen?
Aufwickeln
> Haben die Sendemodule bei jemand schon größere EMV Schwierigkeiten bzw.> Störungen am PIC/AVR verursacht?
Direkt an die Pins der Betriebsspannung 1nF + 100nF und es sollte keine
Probleme geben.
Wobei ich mit 16,4cm aufgewickeltem draht (d =ca 0,8cm) auf 1,5m mit der
schwächsten Sendereinstellung (-21dB) schon mal Aussetzer hatte. Jetzt
hab ich auf -12dB gestellt und komm bei mir quer durch die Wohnung noch
durch 4 Wände durch.
Gruß
Fabian
Moin allerseits!
Habe meine zwei RFM12 an je einem Atmega32 auf Anhieb zum laufen bringen
können :)
Für die C-Routinen möchte ich mich auch bei Benedikt bedanken!!!
Anfangs ist das letzte Byte verloren gegangen, aber mit der neuesten
Version der rf12_txdata lief auch das.
Meine Module sind übrings 868-MHz-Exemplare, die mit ca. 8,6 cm
Drahtantennen ausgestattet sind. Bisher habe ich nur Datenraten von
19200 Baud verwendet.
Als nächstes werd ich mich mal an Hardware-SPI ranwagen. Werde dann
berichten, ob ich Erfolg hatte.
gruß
bobkins
PS: Super Forum, super Leute!!! :D
Hallo!
Ich wundere mich gerade, warum am Interrupt-Pin nIRQ nur ein positiver
Impuls beim Einschalten sichtbar ist?!?
Müsste nIRQ nicht im Idel-Zustand auf High sein?
bobkins
Hallo,
ich bin neu hier und will der RFM12 Modul benutzen. Komme aber hier im
Thread nicht ganz durch und weiss nicht welchen Sourcecode ich benutzen
soll.
Vielleicht könnt ihr mir helfen.
Ich sende zahlen von 0 bis 999 an ein Emfänger.
Beispiel: Es wird die Zahl 345 vom Sender an den Empfänger geschickt.
Der Emfänger schick dann die 345 zurück und bestädigt damit das er es
richtig empfangen hat.
Mit welchem Code mache ich das am besten?
Vielen Dank
Hallo,
hat jemand schon ein ideales Setup (Deviation, Bandwith, Afc....) für
maximale Reichweite gefunden?
Ich nutze eine Baudrate von 19200 mit folgenden einstellungen:
Deviation 30Khz
Bandwith 67Khz
Afc +3/-4 Fres, Auto, Fine Mode
Vielleicht geht da noch mehr :-)
Grüße
Wolfgang
Meine Erfahrung: Mehr Bandbreite und mehr Deviation bringen deutlich
mehr Reichweite (vorausgesetzt es ist kein anderer Sender in der Nähe
der dann stört).
Ich nutze 200kHz Bandbreite und ich glaube 90kHz Deviation.
Hallo Benedikt,
bei Analog modulierten Signalen würde ich dir widersprechen und sagen
ein hoher Frequenzhub verringert die Reichweite.
Wir sprechen hier aber von einer digitalen Modulation!?!?
Da wäre ein Statement von einem HF Spezialisten hilfreich.
Grüße
Wolfgang
Das waren zumindest meine Erfahtungen. Mit den im Datenblatt angegebenen
"optimalen Einstellungen" war die Reichweite ziemlich bescheiden. Warum
es so ist, kann ich dir auch nicht sagen, aber probiere es einfach mal
aus: Man spürt deutlich einen Unterschied.
Ich erkläre mir das so: Mehr Deviation -> es ist einfacher zu
Unterscheiden welche Frequenz gesendet wird, da die beiden weiter
auseinander liegen.
maddin wrote:
> ...hier noch ein Bild und Hinweis für Lochraster Testaufbauten...>> das modul hat ja bekanntlich ein 2mm Raster.>> es besteht trotzdem die möglichkeit es auf lochraster zu setzen,>> wenn man die Pins wie folgt abwinkelt:>> O O | | O |> O O | | O |>>> O= Pin> |= abgewinkelt und mit Kupferlackdraht durchgeführt>> man benötigt natürlich Pinleiste und Federleiste.>> gruß,> m.
Ich verstehe nicht ganz wie du das gemacht hast?
Benutzt du ein Sockel und Stiftleisten?
Hallo hab mir auch die rf 12 module besorgt und auch gleich angefangen
zu testen, hab nur ein problem. mein empfänger empfängt nix.
verwendete pins sind SCK, SDO, SDI, NSEL..
Anbei mein code evtl. könnt ihr ja en fehler entdecken..
MfG Florian
nö, das RFM12 liefert ja einen Clock als Output und kann damit einen µC
versorgen. Habe hier auch einen Mega32 mit ext. 12Mhz dran. Kommt den
nach der Initialisierung an Clock ein 10Mhz Takt raus (Oszi nötig) ?
und 'Receiver' ist bei dir falsch geschrieben ;-)
Ok, das sollte nicht stören. Aber ich würde vor den Calls im Programm
erstmal den Stackpointer initialisieren.
Hallo,
muss ich den RFM12 am AVR SCK, MOSI und MISO per Jumper anschliessen
damit ich, wenn ich den AVR Programmieren will mit ISP, das FRM12
abschliesen kann? Oder kann ich direkt per ISP programmieren auch wenn
der RFM12 dran hängt?
Richard B. wrote:
> Oder kann ich direkt per ISP programmieren auch wenn> der RFM12 dran hängt?
Ja. Da SPI ein Bus ist, kannst Du beide Funktionen gleichzeitig
verdrahtet lassen. Solange am RFM12 nSEL nicht auf Low gezogen wird,
sind seine übrigen SPI-Pins hochohmig und stehen damit der
Programmierung des Controllers nicht im Wege.
Hallo zusammen,
ich habe meine Testschaltung mit zwei RFM12 Modulen aufgebaut.
Mit dem Programm RFM12_RX_TX habe ich den Empfänger und Sender bespielt.
Wenn ich jetzt beide starte ... sehe ich im Terminal vom Empfänger nur
Empfänger "Empfaenger laeuft !<\n>" und dann kommt nix mehr ... also
empfängt der Empfänger nichts :-(
Wie gehe ich jetzt am besten vor um das Problem zu finden? Wo muss ich
messen?
Beide haben keine Antenne dran ... sind aber 40 cm von einander
entfernt.
Vielen Dank im voraus!
Viele Digitalmultimeter haben einene Hz-Messmöglichkeit.
oder du baust dir irgendwie (z.B. aus TTL Zähler-Bausteinen) einen
20-Bit-Counter auf und schließt ans CarryBit ein D-Flipflop mit einer
Led an... die sollte dann ca mit 9Hz blinken. Wobei das ziemlich von
Hinten durch die Brust ins Auge wäre.
Was hast du denn für Meßgeräte zur Verfügung?
Gruß
Fabian
@ bobkins
Könntest du mir vielleicht deinen C-Code für die 868 Module geben? Ich
sitze hier an dran, es läuft nicht und finde den Fehler nicht. Aufbau
ist wie auf dem Bild von Benedikt aber es will einfach nicht. Ich denke
mal, dass ich noch falsche Einstellungen habe.
Thx im vorraus,
Christian
hallo,
würde mich ebenfalls für die konfiguration eines 868MHz funkmoduls
interessieren, bzw was man alles umschreiben muss um den code von
benedikt für sein 433MHz modul verwenden zu können.
Danke,
MAX
Benedikt K. wrote:
> Versuche irgendwie herauszufinden, ob die Frequenz am CLK Ausgang der> Module bei 10MHz. Wenn nicht, dann ist irgendwas falsch angeschlossen.
Danke dir Benedikt. Jetzt funktioniert es ;-)
Am Sender waren es nicht 10Mhz.
Meine Module werden vom Mega8 mit internen Clock 8 Mhz gesteuert.
Ist das ein Problem das die Module mit internen Clock laufen? Hab die
mit 19200Baud laufen.
Ist es wie bei UART das man 0.2% Fehler hat? oder ist es da egal? Soll
ich lieber 11.05 ... mhz benutzen?
Achja, ich benutze isolierten Kupferdraht für die Antenne, ist das ok?
oder ist nicht isoliert besser?
Danke dir Benedikt.
So ... die Module versenden fleisig Chars.
Ich will aber nun das der Sender ein int von 0 bis 999 versendet und der
Empfänger die auch als int bekommt. Wie mach ich das? Kann mir einer
einen codeschnippsel posten?
Ich habe das mit atoi versucht ... klappt aber irgendwie nicht.
Danke
Richard B. wrote:
> Hier der C Code für den Empfänger:> tmp = atoi(test[0]);
atoi nimmt char* als Argument, Du gibt ihm hier aber nur ein char.
So wäre es richtig:
tmp = atoi(test);
Dann mußt Du allerdings auch sicherstellen, daß der String mit einem
'\0' abgeschlossen ist, entweder indem Du es mitschickst oder indem Du
test[1]='\0' setzt. In beiden Fällen mußt Du test noch entsprechend
größer deklarieren.
> ../main.c:106: warning: implicit declaration of function 'atoi'> [/c]> Wie kriege ich die Warnung weg?
1
#include<stdlib.h>
> Hier der Code vom Sender:>>
1
>voidsend(void)
2
>{unsignedchartest[]="2";
3
>rf12_txdata(test,1);
4
>
Um die \0 mitzuschicken, die den String abschließt, mußt Du hier zwei
Zeichen übertragen.
Ein ganz anderer Ansatz wäre noch, den Integer-Wert Byte für Byte binär
zu übertragen, dann würdest Du Dir das Konvertieren nach ASCII und
zurück sparen und ein Wert hätte bei der Übertragung immer die gleiche
Anzahl von Bytes.
Richard B. wrote:
> Wie mache ich es mit dem Interger?
Das wollte ich dem geneigten Leser eigentlich als Übungsaufgabe
überlassen ;)
> Wie verschicke ich binär?
Für die Module gibt es da keinen Unterschied, die verschicken einfach
nur Bytes. Ob es sich dabei um (ASCII-)Strings oder Binärdaten handelt
ist eine Frage der Interpretation in der sich Sender und Empfänger halt
einig sein müssen, damit sie Daten austauschen können.
Von daher sollte man das das, was rf12_txdata übergeben bekommt, besser
nicht als String betrachten (obwohl es im Einzelfall ein solcher sein
kann), sondern als Puffer, der eine beliebige Bytefolge enthalten kann.
Die einfachste Möglichkeit, einen int-Wert binär zu schicken, würde z.B.
so aussehen:
1
intfoo=42;
2
rf12_txdata((char*)&foo,sizeof(int));
Die Adresse der int-Variablen wird in einen char-Pointer umgedeutet und
rf12_txdata soll ab dieser Adresse so viele Bytes senden, wie in einer
Integer-Variablen enthalten sind.
An der Empfänger-Seite darfst Du jezt aber wirklich mal selber üben...
;)
Richard B. wrote:
> Geht es in die richtige Richtung?
Ja, der Aufruf von rf12_rxdata müßte so passen, den if-Block kannst Du
Dir aber sparen, denn nach dem Empfang steht in test ja schon der
komplette int-Wert drin.
Ok, mach gleich Feierabend und teste es.
Wie mache ich es eigentlich mit einer Überprüfung ob auch das richtige
angekommen ist?
Sender(sendet int 144) -> Empfänger(sendet int 144 zurück) ->
Sender(Überprüf 144 = 144 ) -> Empfänger(stimmt)
Ja, so kann man das machen, aber effizienter ist es, wenn der Sender
gleich redundante Informationen mitschickt, anhand derer der Empfánger
die Korrektheit selbst überprüfen kann.
Beispielsweise kann der Sender die Daten doppelt schicken, einmal
normal, einmal invertiert, um Fehler durch systematische Bitkipper
auszuschließen, was sich aber wegen der Verdopplung der Daten nur bei
kleinem Datenvolumen (Fernbediungunskommandos, sporadische Meßwerte,
etc.) anbietet.
Bei größeren Datenblöcken wird meistens mit Prüfsummen (Stichwort: CRC)
gearbeitet.
Das bedeutet nur, dass rf12_txdata() einen unsigned char* erwartet, du
aber einen char* übergibst. Es hat in diesem Fall aber keine
Auswirkungen auf die Funktion.
ok stimmt. Muss ich jede funktion nochmal in die main.c reinschreiben
die ich benutze?
Wie z.B. itoa, bekomme nählich die Warnung:
../main.c:131: warning: implicit declaration of function 'itoa'
Das heißt doch ich muss die oben nochmal hinschreiben ... also den
function kopf ... oder?
Finde leider hier nichts welche Register ich einstellen kann um die
Sendeleistung zu verbessern. Was kann ich einstellen? Müssen die
Einstellungen beim Sender und Empfänger gleich sein um die optimale
Einstellugen zu bekommen? Wie tastet man sich da heran?
Muss ich vielleicht die Baud runterdrehen?
Was kann ich mit rf12_setpower machen?
Achja meine Module sind nur 50cm von einander entfernt ... und liefern
so ein schlechtes Ergebnis. Das kann doch nicht sein.
Richard B. wrote:
> Das heißt doch ich muss die oben nochmal hinschreiben ... also den> function kopf ... oder?
Nein, nur den passenden Header einbinden, in dem die Funktion deklariert
ist, so wie ich es Dir für atoi schonmal hingeschrieben hatte.
> Was kann ich für ein besseren Empfang machen?
Richtig senden? ;)
Deine Sende-Schleife läßt zwischen den einzelnen Sendungen eine längere
Pause. In dem Fall darfst Du meines Wissens anschließend nicht einfach
weiter Daten senden, sondern mußt die Übertragung mit Präambel und allem
Trallala neu aufsetzen, damit der Empfänger sich wieder neu auf den
Sender synchronisieren kann.
Übrigens ist das letzte Byte Deiner Müll-Werte in den meisten Zeilen
korrekt, was meines Erachtens auch auf ein Synchronisations-Problem
hindeutet.
Endlich antwortet einer ;-)
Das mit dem Header geht jetzt danke.
Das verstehe ich nicht. Das heißt wenn ich eine Sekunde warte muss ich
das Modul wieder von einem Initialisieren?
Das Problem ist ja auch das die ersten Zeichen auch nicht immer richtig
ankommen. Habe an den rf12_setbankwidth werten einbisschen gespielt und
es hat verbesserungen gegeben.
Aber leider weiss ich nicht wie hoch ich gehen darf und was z.B.
rf12_setbankwidth(4,1,4) ist // 200kHz Bandbreite, -6dB Verstärkung,
DRSSI threshold: -79dBm
was ist aber rf12_setbankwidth(4,2,4) ? doppelt so viel? also -12db?
Das synchronisieren macht die Software schon selbst, darum musst du dich
nicht kümmern.
Für maximale Reichweite sollte diese Einstellung gut sein:
rf12_setpower(0, 5);
rf12_setbankwidth(4,0,0);
Damit sollten einige 10m selbst unter ungünstigen Bedingungen möglich
sein.
Welche Software verwendest du eigentlich ?
Hallo Benedikt,
ich benutze den von dir empfohlenen Code: RFM12_RX_TX.zip
Ich werde die Einstellungen gleich testen. Und das Ergebniss hier
Posten.
Die Einstellugen müssen beim Sender und Empfänger gleich sein oder?
Maximale Reichweite ... heißt das, das bei 50 cm ich damit ein Problem
haben könnte aber nicht in 5m ?
Ich habe es mit den Einstellungen probiert ... es ist sogar noch
schlechter.
Ich habe mal die funktion wieder zurückgebaut und verschicke wieder
einen Text und hier sieht es irgendwie besser aus.
Ergebnis:
1
S e n d e r l a e u f t ! \n
2
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
3
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
4
\x D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
5
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
6
? D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
7
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
8
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
9
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
10
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
11
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
12
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
13
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
14
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
15
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
16
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
17
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
18
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
19
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
20
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
21
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
22
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
23
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
24
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
25
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
26
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
27
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
28
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
29
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
30
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
31
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
32
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
33
ÿ D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
34
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
35
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
36
D i e s i s t e i n 4 3 3 M H z T e s t ! ! ! \n
37
Am Anfang habe ich ein ÿ was ich nicht mitschicke ... kann es sein wenn
ich nur eine Zahl schicke es immer wegem dem ÿ zu einem Problem kommt?
Soll ich dann lieber sowas machen "######-123+######"
Heißt das ich davor einbisschen blödsind schicke und dann nach - und +
suche um die Zahl zu finden?
Hast du eine Idee?
Vielen DANK im voraus.
Wenn ich das richtig sehe, ist das erste Byte jeweils zuviel.
Probier mal folgendes aus:
Ersetze diese Funktion durch das hier (bzw. wichtig ist eigentlich nur
das 2. nop. Eventuell reicht die Pause vor dem Einlesen nicht ganz aus:
void rf12_ready(void)
{
cbi(RF_PORT, CS);
asm("nop");
asm("nop");
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
sbi(RF_PORT, CS);
}
Irgendwie funktioniert das alles nicht bei mir. Hab den RFM12, der sagt
garnix, der RFM01 macht auch keine Anstalten was zu empfangen, der RFM02
sendet zumindest das original Pollin Programm.
Bei den hier geposteten Progs regt sich garnix. Der Optokoppler wurde
fachmännisch gebrückt. Die Programme laufen auf einem ATMega8 mit
internen 8 MHz, eine 17 cm Antenne schmückt die Boards, ein 1k
Widerstand legt beim RFM12 FSK auf VCC.
Muss ich bei den RFM01 und RFM02 auch noch irgendwelche Modifikationen
am pollin Board vornehmen um die zum funktionieren zu bewegen? Wie
siehts beim RFM12 aus?
Ich hau die Dinger gleich inne Egge!
MfG BC
@ Browncoat:
Welchen COde verwendest du? Mit IRQs oder gepollt? Bei den IRQ-Methode
hatte ich mal was zum Pollin-Board gepostet. Gepollt sollte auch so
funktionieren.
Ansonsten habe ich bei meinem Board nur noch den Takt aus dem RFM12 auf
den Quartzsteckplatz gelegt, um die 10Mhz Takt zu nutzen. Widerstand
habe ich wie du 1k auf Vcc.
Schreib mal welchen Code du nutzt, dann kann ich dir evtl ein "working
sample" schicken.
Hi, also ich benutze die Codes aus diesem Thread,
Für das RFM01
http://www.mikrocontroller.net/attachment/22522/rfm01.zip
Das original Pollin Programm macht hier nichts ausser nach dem Reset
drei mal die LED blinken zu lassen. Die Software hier funktioniert
bisher nicht.
RFM02
http://www.mikrocontroller.net/attachment/22516/rfm02.zip
Das Senden mit dem RFM02 und original Pollin Code klappt, getestet am
TV, Kanal S37. Mit dem Code hier sagt erleider garnichts.
fürs RFM12
http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip
Der original Pollin Code macht auch hier keine Anstalten, getestet
gestern am Spektrumanalysator.
Mit dem Code von hier erhalte ich schonmal eine Meldung via RS232.
Hab leider von jedem Funkmodul nur eins zur Verfügung, und die
befürchtung, daß RFM01 und RFM12 einen weg haben könnten, da sich da
schon ein paar andere Leute dran versucht haben. RFM02 hab ich selbst
aufgelötet und getestet.
MfG BC
Kann eventuell jemand hier seine exakten Einstellungen sprich der
register posten wäre echt nett.
Komm nämlich auch nich weiter vielleicht funktionierts ja mit anderen
Einstellungen...
MfG Flo
Kannst du mir eine bessere Version nennen? Ohne das ich die Verkabelung
neu machen muss?
Hab die Verkabelung so wie es in der gif von der RFM12_RX_TX.zip steht.
ASO verstanden. Das heißt wenn der FFIT eine Flanke setzt dann reagiert
der INT von AVR und bearbeitet das empfangene. Richtig?
Welche Version nehme ich dafür? Hier ist es schon langsam
unübersichtlich.
Nachdem man Empfänger nichts empfangt habe, habe ich mal am Filter
Kondensator des RSSI Pin gemessen und immer wenn der Sender sendet,
hatte ich einen kurzen Spannungsanstieg messen, heißt das der Sender
funktioniert?
Ja. Das heißt auch, dass der Empfänger in etwa auf die selbe Frequenz
eingestellt ist, und läuft.
Ich würde entweder auf ein fehlendes Sync Word vom Sender tippen, auf
ein nicht aktives FIFO oder sonst eine falsche Modulationseinstellung.
Danke für die schnelle Antwort!
Ist einmal gut zu wissen das irgendwas geht.
Das Sync Word ist doch nach der Preamble B82D und B8D4 oder hab ich das
was übersehen?
Wie muss ich das machen wenn ich beim empfangen nicht pollen will
sondern den Interrupt verwenden?
Hab gelesen FFIT mit nINT verbinden und dann nIRQ zum µC stimmt das?
Jedenfalls ohne irgendwas tut der nIRQ Pin nur selten was.
Nein, du verbindest FFIT mit dem uC. Wenn der FFIT feuert, dann sind so
viele Bits im FIFO wie du als Benachrichtigungsschwelle eingestellt
hast...(Benedikts default ist 8 Bit).
Mehr brauchts nicht.
Gruß
Fabian
Exakt.
Du kannst also im Prinzip im Interrupt ein Byte ausm Fifo abholen. Wenn
noch mehr da sind feuert der Int ja eh wieder. Vorausgesetzt du hast nen
Levelinterrupt! FFIT bleibt High(?) solange der Fifo über der Schwelle
ist.
Gruß
Fabian
Das Funk Modul das funktioniert hat 2.08V zwischen CLK und GND und das
Modul das nicht funktioniert hat 1.81V. Kann man daraus schließen, dass
das Modul das nicht funktioniert mit weniger MHZ am CLK läuft?
Nachdem ich jetzt daran glaub das mein Hardware SPI ein Problem hat
wollte ich mal Fragen ob mir jemand die Software-Routine für SPI von
Benedikt bitte erklären könnte:
Ganz einfach:
Als erstes wird das höchstwertige Bit ausgegeben, danach der Wert um
eine Stelle nach links geschoben, so dass das gerade eben an den Port
gelegte Bits rausfällt. An die nun freie Stelle rechts wird der
Eingangspin eingelesen.
Es wird also gleichzeitig gesendet und empfangen, so wie es bei SPI
üblich ist. Die SCK Leitung wird dann noch getoggelt, und das ganze 16x
(für die 16bit) wiederholt.
Am ende wurde der Wert der anfangs in Wert war gesendet, und ein 16bit
Wert von SPI in Wert empfangen.
Hab eine Frage zur Antenne. Ist es besser die Antenne mit voller länge
(17cm) in das Gehäuse zu legen oder es zur einer Spirale aufwickeln?
Sind 433Mhz Module.
Das liegt vermutlich daran, dass man die Frage so nicht beantworten
kann.
17cm Antenne ist mit Sicherheit die einfachere Lösung, da eine gut
optimierte Spirale als Antenne nicht einfach zu berechnen ist.
Ich würde also die 17cm verwenden, da man da weniger falsch machen kann.
@Benedikt:
hast du ein paar Links oder Infos wie man sowas berechnet?
Ich hab in meiner Fernbedienung die Antenne zu einer Spirale mit ca 8mm
Durchmesser gewickelt (Platzgründe) und musste eine deutlich verminderte
Reichweite feststellen.
Gruß
Fabian
Ich habe nun noch immer das gleiche Problem: Wenn der Sender sendet
ändert sich beim Empfänger am RSSI Pin was.
Beide Module sind gleich initialisert, Sender/Empfänger Register
gesetzt.
Module liegen 10cm entfernt, Software oder Hardware SPI bringen das
gleiche Resultat.
Weiß vielleicht jemand was da sein könnte?
Eine Frage noch zum AVR-Sleep Mode.
Ich benutzen den RFM12 per polling. Der Empfänger ist also in der Main
die ganze Zeit in der while schleife vom RFM12 bis er Daten zugesendet
bekommt.
Wie kann ich den AVR in den Sleep Modus setzen?
Heißt wenn 5 Minuten keine Daten angekommen sind dann schlafen gehen.
Das könnte man einfach in einem Timer lösen ... aber ich habe gehört das
man keinen Sleep befehl im Timer machen sollte da es zu Problemen führt.
Hat einer eine Idee wie man das machen könnte?
Ich weiß eine Lösung wäre, wenn man das ansteuern des RFM12 per
Interrupt machen würde ... aber die Hardware ist schon gelötet.
@Richard B.
Die 17 cm Draht-Antenne solltest du nicht als Spirale wickeln, da sich
damit die Eigenschaften der Antenne verändern. Ideal ist gerade!
Die ideale Länge der Draht-Antenne hängt von der Frequenz ab und
berechnet sich laut Literatur so:
l = c0 / (f * 4)
l=Länge der Draht-Antenne
c0=Lichtgeschwindigkeit in Luft in m/s
f=Frequenz in Hz
c0/f stellt die Wellenlänge der Funkwelle dar. Als Antenne wird 1/4 der
Wellenlänge verwendet (Stichwort "Viertelwellendipol").
Beispiel:
f=433Mhz
l = 300e6 m/s / (433e6 Hz * 4) = 17,3cm
Wenn du deine Antenne als Spirale wickeln willst, oder sonst irgendwie
vom langen Draht abweichen willst, müsstest du dir ein spannendes Buch
über Hochfrequenztechnik anschauen, auf Erfahrungswerte ausweichen, oder
deine Antennenkonstruktion mit einem Messempfänger ausmessen. Letzteres
gibt dir einen praktischen Wert.
Der Vollständigkeit halber erwähne ich noch den Verkürzungsfaktor. Der
berücksichtigt den Unterschied der Wellenausbreitungsgeschwindigkeit in
Vakuum gegenüber der Geschwindigkeit im (Kupfer-)Draht. Den könnte man
einfach als 0,96 annehmen. Also würde die Antenne kürzer als 17,3 cm
werden.
So genau kann man das allerdings nicht sagen, weil selbst das kleine
Stückchen Leiterbahn auf dem RFM-Modul seine Finger im Spiel hat, uvm.
Daher sagen wir einfach mal 17cm, passt schon!
@Christian M.
Sorry, hab dich ganz vergessen! Mein Code ist derselbe, wie auch für die
433 MHz-Module. Nur die Konfiguration habe ich etwas angepasst, so wie
ich es laut Datenblätter für richtig hielt. Wenn du die haben möchtest,
müsste ich mal bei Gelegenheit nachschauen.
mfg bobkins
Hallo bobkins (Gast),
es wäre toll wenn du die Konfiguration für die 868 Module einmal
heraussuchen kannst. Auch ich habe hier, ähnlich wie Christian ein 868
Modul das leider nicht läuft.
Gruß Michael
@bobkins
Freut mich, dass du mich nicht vergessen hast. Ich bin aber durch langes
studieren des Codes und des Datenblattes selbst auf die Loesung
gekommen. Sind im Grunde nur zwei oder drei Aenderungen. Werde die heute
abend hier auch mal angeben.
Zurzeit bin ich mit einem Kommunikations-Protocoll fuer die Module
beschaeftigt. Halt mit Frames variabeler Groesse, CRC usw.
Mal schauen was dabei rauskommt.
Bye, Christian.
PS.: Ich habe hier leider keine deutschen Umlaute. Arbeite in den NL.
Also nicht ueber die Schreibweise wundern ;-)
hi!
super, dann werd ich ja nicht mehr gebraucht ;-)
Soweit ich mich erinnern kann (hab mal wieder meinen krempel nicht hier)
habe ich die Einstellungen genauso gemacht. wie gesagt, siehe
Datenblatt.
mfg bobkins
Leider wird vielerorts nur mehr der RFM12B angeboten. Der soll im
Prinzip gleich sein, verträgt allerdings nur max 3,8V. Laut Datenblatt
liegt der High-Output bei min Vdd-0,4 = dann 3,4V.
Mein AtMega Board hat nur 5V. Laut Datenblatt Mega16 liegt die Input
High Voltage bei min. 0,6*V=3V. Hat schon jemand ausprobiert, ob da die
Kommunikation reibungsfrei läuft? Bzw. kann ich einfach 2 Dioden nehmen
für die Absenkung der 5V? Hab keinen Platz für noch nen Spannungsregler
bzw. Pegelwandler und will es möglichst einfach lösen. Vorschläge?
Pegelwandler
3V high an den AVR wäre knapp. Aber du kannst davon ausgehen, dass ein
unbelasteter Ausgang eines CMOS ICs annähernd Vdd liefert, nur dauert
low=>high dann länger als im Datasheet vom RFM steht. Wenn du den
SPI-Takt also nicht voll ausreizt und dem RFM seine 3,5V gibst, dann
dürfte das gut funktionieren.
Wenn Dioden, dann ausreichend belastet damit es mindestens 0,6V pro
Diode sind (1mA min bei 1N4148). Bei den 0,3µA eines RFM12 im Standby
kommen dort sonst weit über 4V an. Also Lastwiderstand 3K3 hinter die
Dioden, und auch einen kleinen Elko, sonst entscheidet der RFM em Ende
noch auf Brownout sobald er aufwacht.
...ich habe ein paar kleine fragen zu diesen beiden routinen:
void rf12_txdata(unsigned char *data, unsigned char number)
{ unsigned char i;
rf12_trans(0x8238); // TX on
rf12_ready();
rf12_trans(0xB8AA);
rf12_ready();
rf12_trans(0xB8AA);
rf12_ready();
rf12_trans(0xB8AA);
rf12_ready();
rf12_trans(0xB82D);
rf12_ready();
rf12_trans(0xB8D4);
for (i=0; i<number; i++)
{ rf12_ready();
rf12_trans(0xB800|(*data++));
}
rf12_ready();
_delay_us(10);
rf12_trans(0x8208); // TX off
}
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
for (i=0; i<number; i++)
{ rf12_ready();
*data++=rf12_trans(0xB000);
}
rf12_trans(0x8208); // RX off
}
1) in benedikts code ist zwischen:
rf12_trans(0xCA81); // set FIFO mode
und :
rf12_trans(0xCA83); // enable FIFO
ein delay, ist es notwendig - warum?
2)beim einschalten von rx oder tx werden immer beide optionen nach der
jeweiligen aktion wieder abgeschaltet, warum? kann ich auch direkt
umschalten..
3)es müsste doch auch moglich sein, mit einem flankeninterrupt zu
empfangen, indem man ffit nach jedem byte das man ausliest abfragt.
4)das modul bietet auch die möglichkeit statusmeldungen zurückzulesen
(datenblatt befehl 16 (0xxx xxxx xxxx xxxx), leider ist er nicht
dokumentiert, also welches bis welchen status rückmeldet, oder gibts da
noch ein extra datenblatt?
5)zu der präambel von B8AA, wurde weiter oben schon angesprochen:
wo wird diese wieder entfernt?
6)was bewirkt:
rf12_trans(0xB82D);
rf12_ready();
rf12_trans(0xB8D4);
sind das noch befehle?
gruß und vielen dank im vorraus,
m.
auf die Gefahr hin dass ich mich beim total Blamiere: Ich hab bei diesem
Prog. von Benedikt echt Probleme.
Ich habe das Programm eingebaut und es lässt sich mit nur einer Warnunge
Compilieren (../main.c:55: warning: pointer targets in passing argument
1 of 'lcd_puts' differ in signedness
). Der ATMega16 hängt sich nicht auf. Aber auf dem Display entsteht nur
Datenmüll:
Wenn ich die empfangenen Daten wie folgt verarbeite:
rf12_rxdata(test,15);
// daten verarbeiten
lcd_gotoxy(0,0);
lcd_puts(test);
dann bekomme ich einen 15 Zeichen breiten schwarzen Balken.
Ersteze ich "lcd_puts(test);" durch lcd_puts(test[3]); dann bekomme ich
den ganzen Bildschirm voller wirrer zeichen (bei jedem Durchlauf die
gleichen).
Der ATMega hängt sich aber nicht auf. Habe auf zwei Boards (gleiche
Verdrahtung) die gleichen Probleme. Es ist egal ob das eine Board sendet
oder nicht, im Sekundentakt wird das Display beschrieben.
Hab´ ich jetzt das CHAR-Handling nicht verstanden oder hab´ich ein ganz
anderes Problem?
Danke für die Hilfe
Gruß
Kuddel
Kleine Frage - ist die Empfangssteuerung von RFM01 und RFM12 und die
Sendesteuerung von RFM02 und RFM12 jeweils identisch, also die Module
austuaschbar? Ich googel da schon ganze Zeit und finde keine Antwort.
LG
Vajk
Hallo alle,
ich suchte eine Sende-/Empfang Modul SET für die Übertragung von Daten
mit einer entfernung von mindesten 30m. und bin auf diese Beitrag
gestoßen. Als controller benutze ich der Mega16 der auf den AVR STK500
angeschlossen ist. jetz wollte ich gern der RF12 als Sende-/Empfang
Modul SET benutzen und habe einige Fragen an euch.
1-kann ich der RF12 direkt an meiner AVR STK500 anschliessen und
benutzen ohne weiter änderungen oder erweiterungen?
2- wenn änderungen nötig sind: welche sind die?
3- welche Type von Antenne um mein Ziel zu erreichen kann ich benutzen?
Danke im voraus
Steven
Hi,
Warum hat eigendlich keiner den Betrag von Horst beachtet? Meiner
Meinung nach, stellt er eine sehr durchdachte effektive Lösung dar. Bei
mir entstand der Eindruck, das alles was von Benedikts Mainstream-Lösung
abweicht, einfach ignoriert wird, auch - oder besonders - wenn es eine
gute Idee ist.
helge wrote:
> Warum hat eigendlich keiner den Betrag von Horst beachtet?
Keine Ahnung. Anscheinend reden alle mit, aber wirklich nutzen tut
niemand die Software.
Bei meiner RS232 Funkbrücke wollten alle eine Menü über das sich die
Parameter einstellen lassen. Also habe ich diese eingebaut. Irgendwann
habe ich festgestellt, dass diese einen größeren Bug hat, der eigentlich
relativ schnell auffällt, wenn man die Software verwendet (die
Einstellungen werden nicht gespeichert). Da sich aber bisher niemand
beschwert hat, muss ich davon ausgehen, dass niemand die Software
verwendet. Daher investiere ich dafür auch keine Zeit mehr.
Hallo Benedikt,
Ich habe mir vor kurzem ein RFM12 bei Pollin gekauft, und will mal
versuchen es für 9600 Baud Packet-Radio zu benutzen. Ein Digipeater auf
438,425MHz steht in Sichtweite, sodaß zu geringe Empfindlichkeit kein
Problem sein dürfte. Die minimale Bandbreite von 64 kHz ist allerdings
etwas breit. Auch der FSK-Frequenzhub ist etwas groß, läßt der sich
einstellen?
Ist der analoge RSSI-Ausgang am RFM12 zugänglich? Die digitale RSSI gibt
ja leider nur eine Schwellenüberschreitung aus, die man höchstens auf
verschiedene Schwellen umschalten könnte. Laut Datenblatt müßte ein 1nF
C am RSSI-Analoganschluß liegen.
Gibt es auch einen Händler für die 500mW-Version hierzulande, oder muß
man die in Tschechien bestellen?
Anscheinend hat das Modul auch eine untere Grenzfrequnez für die
Modulation, ich bin aus dem Datenblatt noch nicht recht schlau geworden.
Christoph Kessler wrote:
> Auch der FSK-Frequenzhub ist etwas groß, läßt der sich einstellen?
In 15kHz Schritten aufwärts.
> Ist der analoge RSSI-Ausgang am RFM12 zugänglich?
Ja, siehe Zeichnung.
> Anscheinend hat das Modul auch eine untere Grenzfrequnez für die> Modulation, ich bin aus dem Datenblatt noch nicht recht schlau geworden.
Ja, scheint so zu sein. Ich hatte mit den analogen RSSI Ausgang mal
versucht ein RFM12 als Spektrumanalyser für das 433MHz Band zu
missbrauchen, dabei fiel mir auf, dass es etwas Ober und Unterhalb der
eigentlichen Frequenz ein Signal am RSSI Pin erzeugt, nicht aber wenn
man genau auf die Frequenz geht.
Ja genau die Idee hatte ich auch, einen einfachen Panaoramaempfänger. Es
gibt wohl verschiedene Genarationen dieses Moduls, mal sehen ob meines
auch an der Stelle einen C hat.
Das 500mW-Modul hatte ich über den Thread entdeckt:
Beitrag "Sammelbestellung bei tme.eu : RFM12 , 100nF 0805, Atmega88"
Sammelbestellung bei tme.eu : RFM12 , 100nF 0805, Atmega88
Da steht was von 7 kHz Hochpass, ob das ein Schreibfehler ist?
Wieso haben die im Datenblatt das Ausschnitt-Drucken verhindert? Zum
Glück gibts Ghostscript das sich um solche Feinheinten nicht kümmert.
Hallo,
ich habe jetzt versucht meine beiden Module RFM12 mit dem Code aus
diesem Thread in Betrieb zu setzen. Auf den ersten Blick hat auch alles
ganz toll ausgesehen. Jetzt habe ich aber festgestellt, daß mein
rf12_ready nicht blockierend ist, so wie es eigentlich sein sollte. Wenn
der Sender gar nicht engeschaltet ist, wird einfach von der
Empfangsroutine 0xff in den Puffer eingetragen.
Ich habe schon die kleinen Verbesserungen am rf12_ready nachgetragen.
Jetzt fällt mir nichts mehr ein.
Hat jemand einen Tip?
Dirk
Dirk Schlage wrote:
> Jetzt habe ich aber festgestellt, daß mein> rf12_ready nicht blockierend ist, so wie es eigentlich sein sollte. Wenn> der Sender gar nicht engeschaltet ist, wird einfach von der> Empfangsroutine 0xff in den Puffer eingetragen.
Hast du rf12_ready so angepasst ?
void rf12_ready(void)
{
cbi(RF_PORT, CS);
asm("nop");
asm("nop");
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
sbi(RF_PORT, CS);
}
Das sollte funktionieren.
Hallo,
ich habe noch eine kleine frage zur sendebereitschaft des moduls, im
code von benedikt wird das modul immer im rx gehalten, will eines
senden, wird es in den sendezusatnd gebracht, und die daten werden
übertragen (den protokoll overhead/ sicherungsschicht mit
richtungswechsel und bestätigung mal weggelassen).
ich hatte bei meiner funkstrecke das problem, das ich zu scheinbar zu
schnell nach dem senden wieder in den rx zustand geschaltet habe, das
modul sendete nicht richtig.
im code ist diese funktion dafür zuständig:
/*void rf12_rxmode(void)
{
rf12_trans(0x82C8); // RX on
rf12_trans(0xCA81); // set FIFO mode
_delay_ms(.6);
rf12_trans(0xCA83); // enable FIFO: sync word search
rf12_trans(0); // Status lesen um Bits zu löschen
}*/
im datenblatt ist gott sei dank das das modul diese zeit benötigt.
jetzt meine frage:
es gibt eine funktion:
static inline void rf12_ready(void)
{
cbi(RF_PORT, CS);
asm("nop");
asm("nop");
while (!(RF_PIN&(1<<SDO))); sbi(RF_PORT, CS);
}
um die bereitschaft des moduls abzufragen, die scheint dies anhand des
zustandes der sdo leitung zu machen, warum nicht anhand der statusbits,
oder geht das nicht?
gruß,
whitenoise
White Noise wrote:
> es gibt eine funktion:>> static inline void rf12_ready(void)> {> cbi(RF_PORT, CS);> asm("nop");> asm("nop");> while (!(RF_PIN&(1<<SDO))); sbi(RF_PORT, CS);> }>> um die bereitschaft des moduls abzufragen,
Die Fragt nicht ab, ob das Modul bereit ist zu senden/empfangen, sondern
nur ob Platz im Sendepuffer ist bzw. ob Daten im Empfangspuffer sind.
> die scheint dies anhand des> zustandes der sdo leitung zu machen, warum nicht anhand der statusbits,> oder geht das nicht?
Das Statusbit wird über die SDO Leitung übertragen. Zufällig ist es
genau das erste Bit, daher muss nicht das komplette Statusregister
gelesen werden.
@Benedikt
Ich möchte noch was wegen Deinem Post vom 14.05.2008 15:25 sagen.
Es tut mir leid, das Du da wenig Rückkoppelung bekommst.
Ich muss sagen, das ich mich für das Thema, auch die RS232 Brücke sehr
interessiere. Leider trifft es in den Spezifikationen (Fehlerkorrektur
usw.) nicht meine Vorstellungen.
Habe auch leider meine eigenen Bemühungen wegen anderer Projekte immer
weiter verschieben müssen. Aber irgendwann wird Dich mal der Hammer
treffen und einer wird sich wegen der Bugs beschweren. ;-)
Trotzdem lese ich immer wieder mit und bin oft erfreut wie geduldig und
kompetent Du, nach so langer Zeit antwortest. Es ist wirklich immer
wieder eine Freude von Dir zu lesen.
Bitte mach weiter so. Echt Klasse.
Falls du, (oder mal jemand anderst) eine ordentliche Fehlerkorrektur in
die Funkübertragung einbaut, dann wäre es schön wenn er den Code mal
veröffentlichen würde. Denn genau zu diesem Punkt findet man eigentlich
rein garnichts im Internet. Ich hatte damals Tagelang nach verschiedenen
Verfahren gesucht. Die waren alle entweder zu schlecht (Verhältnis
Overhead zu erreichter Sicherheit zu schlecht) oder zu Rechenaufwendig
(viel SRAM notwendig, und oft auch sehr rechenaufwendig).
>Die waren alle entweder zu schlecht (Verhältnis>Overhead zu erreichter Sicherheit zu schlecht) oder zu Rechenaufwendig>(viel SRAM notwendig, und oft auch sehr rechenaufwendig).
Ich kann das dann hier posten wenn es soweit ist.
Allerdings muss ich Dir rechtgeben, das es nicht einfach ist einen
Kompromiss zwischen Nutzdatenrate, Sicherheit und Aufwand zu finden.
Dazu kommt noch das die Entfernung und die Funkemgebung starken Enfluss
haben. Möglicherweise wird Dir meine Lösung auch nicht gefallen,
aber das werden wir ja dann sehen.
while(!(RF_PIN&(1<<SDO)));// wait until FIFO ready
6
}
Ich habe jetzt den von vorgestern auch noch mal ausprobiert. Leider
wartet da nix.
Ich frage mich warum ich am Anfang den Eindruck hatte, daß etwas über
die Funkstrecke kam. Ich stelle zwischen Sender und empfänger per
bedingter Compilierung um. Die Sende routine wird beim Empfänger gar
nicht aufgerufen.
Ich gebe das Ganze dann auf einem Nokia3310-LCD aus.
Ich denke ich muss noch mal ganz zurück, und das Umschalten der Frequenz
am Ausgang per Oszilloskop messen. Leider bin ich am Oszilloskop etwas
schusselig. Mit etwas Glück finde ich auch an einem rostigen Nagel die
10MHz, wenn ich wild an den kleinen Knubbeln rumschraube.
Gibt es die Möglichkeit per SPI ohne Interrupt, oder sonstige Leitungen
zu prüfen, ob ein Byte empfangen wurde?
Gruß
Dirk
tach tach,
hab auch nen kleine´s prob. mit meinen RFM02 und einem ATMega8.
habe vom RFM02 den TaktPin CLK auf xTal 1 vom At8 geschaltet doch wie es
scheint geht da nix.
Der Externe Ausgang XTal am At8 ist ON doch war´s das auch schon.
Habe das Fusebit über MyAvr QuikProg angeschaltet und auf der Evo. Bord
von Avr geht das ganze auch.
Auf der TestPlatine hingegen nicht.
Benutze ein leicht abgewandeltest C Prog. von Pollin. auch die
Schaltung ist übernommen.
was läuft falsch.
mfg. CUpa
Hallo,
ich habe mich 2 Funk-AVR-Eva-board von Pollin bestellt und dazu auch die
RFM12
Funk modul.Zur Verfügung habe ich die ATMEGA16 chip.
ich habe eine Frage: kann die Software RFM12_RX_TX von Benedik mit dem
MEGA16 laufen?
wenn nein welche änderungen soll man hier machen damit die software mit
einem Mega16 läuft?
Ic danke Ihnen in voraus
Hi alle,
ich bin eine neue mikrocontroller benutzerin und will daten per funk
übertragen.
dem zu folge bin ich auf diese Beitrag gestoßen und es hat mich sehr
viele geholfen. ich habe noch einigen schwierigkeiten und hoffe, dass
jemand hier mir helfen könnte.
am 18.05.2007 Georges E Wrote:
>> 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 !!!!
ich wollte gern wissen wie er pin defines für eine ATmega 16 geändert
hat.
@ Roland:
wenn du dein Problem gelöst hat, kannst mir sagen wie.
MFG
Chryst
Hallo Benedikt,
erstmal ein großes Dankeschön für das Einstellen des Beispielcodes!
ich teste grade die beiden C- Beispielprogramme für die Module RFM01 und
RFM02. Ich habe folgendes Problem:
Meistens werden nur das erste oder auch die ersten beiden Bytes korrekt
übertragen. Ab dann kommt nur Müll an. Beide Module arbeiten mit 10MHz,
dass habe ich kontrolliert. Offenbar sendet der Sender auch was, sonst
würde der Empfänger nicht reagieren. Nur leider kommt eben nichts
Gescheites beim Empfänger an. Ich habe auch schon versucht die
Init-Funktion am Anfang mehrmals aufzurufen. - Ohne Erfolg.
Hast du da ev. eine Idee?
Grüße
Jonny
Setze mal die SPI Frequenz hoch und lese mal den Status beim Interruppt
aus. Ich hatte das Prob auch. Bei mir war es so das ich nicht schnell
genug die empfangengen Daten aus dem Modul gehollt habe und er in der
Zeit diese schon wieder überschrieben hat.
Hallo Gast,
vielen Dank für den Hinweis. Könntest du ev. zeigen, an welcher Stelle
im Code was geändert werden muss - oder deinen geänderten Codeausschnitt
zeigen?
Das wäre sehr freundlich von Dir :)
Viele Grüße
Jonny
Hallo Marco,
ah - Danke für den Hinweis. Ich habe nun im Main-Programm zu Testzwecken
diese Zeilen eingetippt:
SPCR &= ~(1<<SPR1);
SPCR &= ~(1<<SPR0);
SPSR |= (1 << SPI2X);
Das Problem bleibt weiter bestehen. Die ersten beiden Bytes sind noch
ok, dann kommt irgendwas an.
Werden in Benedikts Beispiel überhaupt die SPI-Register des Chips
genutzt?
Viele Grüße
Jonny
Hi,
ich hab ein paar Module bei Pollin bestellt. Ich wollte die zwei
Atmega32 mit dem Takt des Funkmodules versorgen. Soll heißen, ich
schließe CLK an XTAL1 an. Nun meine Frage, wie muss ich die Fusebits,
die für den Takt zuständlich sind, einstellen. Auf Ext. Clock, auf Ext.
RC Osc, auf Ext. Low Freq, oder auf Ext. Crystal/Resonator (auf HIGH,
MEDIUM oder LOW)?
mfg liggi
Ext. Clock.
Du solltest aber einen Quarzoszillator verfügbar haben, falls Du mal
wieder auf einen Quarz umsteigen möchtest und das RFM12 nicht
funktioniert.
Moin,
ich hab mal eine Frage zu den Quellcodes für das RFM02 Module, die in
diesem Thread zu finden sind.
Bin beim anpassen des Codes darauf gestoßen, dass 0xD2.. an das Modul
gesendet wird. In den Datenblättern von Pollin und Hope RF gibt es
jedoch kein Register, was mit D beginnt.
Wozu ist das genau gut?
Philipp wrote:
> Bin beim anpassen des Codes darauf gestoßen, dass 0xD2.. an das Modul> gesendet wird. In den Datenblättern von Pollin und Hope RF gibt es> jedoch kein Register, was mit D beginnt.
Doch, auf Seite 16 des Hope RF Datenblatts unter Punkt 11.
> Wozu ist das genau gut?
Damit wird der Strom für die interne PLL eingestellt.
Hallo, ich hätte da mal eine Frage.
Kann ich die hier vorgestellte Bibliothek auch für das RFM12BP Modul
verwenden, oder muss ich dazu etwas anpassen?
Welchen Wert muss ich bei diesem Modul für die unterschiedlichen
Sendeleistungen zum Modul schicken (also z.B. für 10 mW, 25 mW oder die
max. 500 mW)?
Und noch eine Frage. Ich glaub ich habs nur einfach nicht gesehen, aber
wie schalte ich das Modul in den Standy, also den Sende- und
Empfangsteil ab, sodass nur noch der interne Oszillator des Moduls läuft
und wie schalte ich dann den Sende- bzw. den Empfangsteil wieder an?
Danke im Voraus
Chris
Hallo,
ich arbeite in der Schule mit einem Atmel mega8 und den RFM01/02
Modulen, leider kriegen wir keine Verbindung zu stande. Ich habe die
verschiedensten Beispiele benutzt und kamen dennoch zu keinem
vernünftigem Ergebnis.
Ich habe leider keinen Frequenzscanner, aber laut Ozi sollte eigentlich
gesendet und empfangen werden. Das was empfangen wird sollte eigentlch
über UART an einen PC gesendet werden und alles kommt an nur die Sachen
die via UKW gesendet wurden nicht.
Auf Wunsch kann ich das Programm Listing Online stellen.
Danke schon mal im voraus
Hallo,
ich fange jetzt auch an mit den Rfm12 und Bascom zu tüffteln,
ich verstehe nur nicht, wieso man die Daten wie Frequenz, Baudrate usw.
nicht einfach ins Modul spi-t und gut, da werden Consts geschrieben und
Subs usw. warum ?
Gruss
A. Arndt
Weil sich das für ein guten Programmierstil so gehört!
So ist es einfacher an neue Umgebungsbedingungen anzupassen!
Wer halbwegs vernünftig programmiert verwendet consts etc. Alles andere
ist nur Bastelmüll!
Hallo,
gut, das ist ansichtssache, ich programmiere mit vielen Kommentaren,
würde aber nie z.B. um auf einem LCD die Zahl 48 darzustellen
programmieren
A = 48
lcd a
sondern lcd "48"
und gut.
Ich möchte zum Beispiel nur den Wert, also die 9 Bits eines DS1820 zu
einem 2. AVR schicken und da via LCD darstellen lassen, nichts mit uart
usw. also könnte ich doch die Daten wie Frequenz usw, einmal
rüberschieben zum Modul und mich dann auf das Datensenden konzentrieren
(Sender) und mir den Wert zurückschicken, wenn identisch i.O. ansonsten
nochmal schicken bis i.O.
Oder bin ich mit dieser Idee völlig auf dem Holzweg...?
Gruss
A. Arndt
Eine Antwort schicken erfordert zumindest schon mal das Umschalten vom
Empfangs- in den Sendemodus. Rein auf Datensenden reicht also nicht.
Außerdem muss der Empfänger noch das Ende eines Pakets erkennen und
falls dieses nicht erkannt wird nach einer gewissen Anzahl Bytes
aufhören zu empfangen.
Solche Dinge wollen beachtet werden.
Hallo,
das ist klar, ich dachte mir das wie folgt :
Sende Frequenz 'z.B. 433,92 MHz
sende Baudrate '19200
sende Frequ-Shift ' 120kHz
und schalte auf Empfang und warte
das gilt für Sender und Empfänger
Dann erfolgt am Sender die Messung mit Ds1820 und schaltet um auf Senden
und schickt die Daten und schaltet wieder auf Empfang.
Der Empfänger lauert auf Daten, empfängt diese, wartet kurz und schickt
diese Daten genau so zurück und schaltet wieder Empfang.
Der Sender empfängt die Daten, prüft ob i.O und schickt ggf. Daten
nochmal und schaltet wieder auf Empfang.
Empfängt der Empfänger innerhalb von 5 Sek nichts mehr wertet er die
Daten des DS1820 aus und zeigt sie auf dem LCD (dieses könnte natürlich
noch mit Sendung von z.B. code für ok verfeinert werden).
Man könnte natürlich auch die Auswertung gleich am Sender machen.
So das "Grobgerüst"....
Gruss
A. Arndt
Hi,
gibts keine Rubrik RFM12 für Dummies ohne Sprüche "Steht doch im
Datenblatt"...
Es gibt halt Hobbybastler und Ingenieure, daher ist auch das Verständnis
für diese Infos zu verschieden...
Gruss
A. Arndt
Hallo zusammen. Ich wollte mich jetzt auch mal mit den Funkmodulen
beschäftigen und hab auch 2 rfm12 hier liegen. Allerdings seh ich bei
dem Quellcode, speziell bei der Funktion rf12_trans, noch nicht so ganz
durch. Vielleicht könnte sich ja jemand bereit erklären mir zu
verdeutlichen was da vor sich geht.
Hier noch mal die Funktion:
Hi,
welche Werte müssen denn mindestens ans Modul gesendet werden...?
Frequenz, Baudrate und Bandbreite ????
Was hat es mit dem sog. FIFO auf sich, welchen Befehl muss ich schreiben
um die empfangenen Daten auszulesen zu können ?
Sind die Daten nach dem Auslesen im Modul weg ?
Wie bekomme ich mit, wenn Daten im Modul angekommen sind ?
Gruss
A. Arndt
Hallo,
bei mir bleibt das Programm, wenn ich senden möchte, hier hängen:
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
in der rf12_ready(). Habe auch ein asm("nop"); eingefügt.
Hat jemand ein Tipp für mich, woran das liegen könnte?
Ich habe MISO, MOSI, SCK und nSel und FSK über 10k auf 5V an meinem
ATMega2560 angeschlossen.
Vielen Dank!
Gruß Jonas
Hallo,
ich habe nun manches in diesem Thread gelesen, bin Modellfan in und
möchte einen 1:32 LKW mit einer Fernsteuerung ausstatten.
Habe auch schon manches mit dem ATTiny2313 umgesetzt.
Allerdings stört mich hier etwas die Unzuverlässigkeit der produzierten
Geräte, wenn ich etwas steuere, dann sollte das meiste auch den
Empfänger erreichen.
Ich hab mir das so vorgestellt:
Der Sender sendet laufend 3 Bytes, das erste und zweite muß im Empfänger
in
einen Output je Pin durch Timer in 1ms bis 2ms Rechteck umgesetzt werden
mit gesamt 20ms Distanz. (Für Servo, Motor). Das dritte Byte dient
Sonderfunktionen (Licht etc.)
Diese 3 Bytes sollten zyklisch immer wieder gesendet werden, man könnte
ja noch ein viertes Byte hinzunehmen als Prüfbyte (mit den anderen über
XOR ermittelt)
Ich hoffe, das man das mit 2 ATTiniy2313 hinbekommt, habe noch jede
Menge herumliegen, bräuchte nur 2 RFM12
Hallo ,
habe heute von Pollin Päckchen bekommen,
was war darin:
Bausatz Funk AVR Evaluations Board = war in Ordnung, aber
2 * Rainbow - Mouse
in einem Beutel, auf dem 2 Stk. Funkmodul RFM 12 drauf stand.
Auch auf der Rechnung stand 2 * Funkmodul RFM 12
Ist die Firma Pollin bei euch auch so unzuverlässig, wenn ihr was
bestellt ??
Manja wrote:
> Ist die Firma Pollin bei euch auch so unzuverlässig, wenn ihr was> bestellt ??
Nein nur extra bei dir haben sie ne Ausnahme gemacht um dich speziell zu
ärgen, weil du ein Leerzeichen vor einem doppeltem Satzendezeichen setzt
:P
Mir isses noch nicht passiert, wurde aber schon öfter berichtet. Einfach
anrufen dann kriegt mans meist nachgeliefert und darf das falsch
gelieferte behalten.
Unzuverlässig? Reichelt hat das letzte Mal bei mir statt 5 Atmega32
(TQFP) 5 Atmega128 (TQFP) geliefert. Waren mit Atmega32 auf der Tüte
beschriftet.
Passiert anscheinend in jedem Laden.
@Georg E.
Du hast weiter oben geschrieben, dass du 2 DemoBoards von Pollin im
Einsatz hast und dafür den Code von Benedikt angepasst hättest. Kannst
du mir den Code evtl. zur Verfügung stellen? Ich hab mir auch gerade 2
DemoBoards bei Pollin bestellt...
@all
oder kann mir sonst jemand vielleicht 'nen fertigen SimpelCode zur
Verfügung stellen?
Danke
Werner
Hallo,
weiss jemand, ob die RFM 01 / 02 auch ohne AVR betrieben werden können ?
Ich würde sie nämlich mit Encoder-Decoder ICs betreiben wollen:
RFM02
Spannung anschliessen
Ausgang von Encoder-IC in FSK-input
nSEL auf Low
RFM01
Spannung anschliessen
nSEL auf Low
Irgendwo müsste das Signal wieder rauskommen....?
oder geht es nicht ?
Danke für Eure Antworten
Susi
Huhu Susi,
das geht nicht ohne uC .. ein I2C-Speicherchip kann eigentlich auch
nicht ohne uC leben ... bei den Funkmodulen st das auch so ... (ohke PC
direkt dran geht auch).
LG
Vajk
A. Arndt wrote:
> Hi,>> gibts keine Rubrik RFM12 für Dummies ohne Sprüche "Steht doch im> Datenblatt"...
Da die Datenblätter eben sehr technisch sind, versucht z.B. dieser
Wiki-Artikel die Thematik auch auf einfachere Weise zu erklären:
http://www.mikrocontroller.net/articles/RFM12> Es gibt halt Hobbybastler und Ingenieure, daher ist auch das Verständnis> für diese Infos zu verschieden...
Es geht nicht ums Verständnis, sondern darum, dass nicht alles dreifach
gefragt wird. Es ist völlig klar, dass nicht jeder einen so langen
Thread wie diesen komplett durchlesen will, dafür gibt es das Wiki!
Erhält man eine passende Antwort und die Frage steht noch nicht im Wiki
ist jeder eingeladen dies nachzutragen.
Hallo zusammen,
ich habe ein Problem mit meinem RFM12 das Senden soll.
Das komische ist, wenn ich den Sender an +5V Netzteil anschließe
funktioniert es immer gut. Wenn ich es aber mit Batterien betreibe,
funktioniert das fast nie ... nur ab und zu. Hat eine eine Idee woran
das liegt?
Wenn ich im Batterie Mode den ISP Stecker anstecke dann funktioniert das
wieder immer.
Das RFM12 schaltet immer auf 10Mhz hängt aber in der sende Funktion wenn
mit Batterie betrieben wird.
Hat einer eine Idee was ich messen soll oder was das Problem sein
könnte?
Danke
Hallo.
Habe ein Problem mit dem Empfangsmodul RFM01.
Die Konfiguration des Moduls habe ich vom Beipsielcode von hopeRF
übernommen (http://www.hoperf.com/pdf/RF01_code.pdf --> 24 Byte an Modul
senden).
Das Modul wird über eine HW-SPI angesprochen, die auf 78kHz eingestellt
ist. Nach der Initialisierung des Moduls wird auf einen NIRQ-Interrupt
gewartet, der nach 8bits im Buffer auslöst.
Ist das der Fall, werden zuerst die 16bit vom Status Register und danach
8bit FIFO ausgelesen.
Das Ganze wird 8mal durchgeführt und anschließend das
FIFO-Löschen-Kommando ans Modul gesendet.
Nun passiert folgendes: Wenn der NIRQ-Interrupt auslöst, werden statt
des Status-Registers sofort die 8bit-Daten empfangen.
Nachdem dann wieder FIFO-Löschen geschickt wurde, funktioniert das ganze
wieder bis zum nächsten Löschen-Kommando. Danach werden wieder statt des
Status Registers die 8bit-Daten empfangen.
Hat jemand eine Idee, was daran schuld sein könnte???
mfg Alfred
Hallo,
es war die rede davon das der ffit pin auf high geht wenn der fifo voll
ist beim rfm01. welcher der beiden ist jetzt gemeint, da sind ja 2...
MfG Flo
Hi,
ich habe mir zwei Module mit dem IA 4221 und IA4320 für Modellbau
aufgebaut. Der Empfänger wiegt nur ca. 0.3g. Allerdings gibt es noch
Probleme bei der Programmierung. Ich habe eine zuverlässige Verbindung
auf 433MHz (Mit geringer Reichweite). Wenn ich allerdings auf beiden
Seiten 868MHz einstelle tut sich nichts mehr. Muss zusätzlich noch eine
andere Einstellung vorgenommen werden damit die 868MHz funktionieren?
Die ANtennenschaltung ist bereits für 868MHz ausgelegt. Ich schiebe die
Daten direkt (ohne FIFO) raus. Kann bei Gelegenheit den Code posten.
Chris
Gerd wrote:
> Unzuverlässig? Reichelt hat das letzte Mal bei mir statt 5 Atmega32> (TQFP) 5 Atmega128 (TQFP) geliefert. Waren mit Atmega32 auf der Tüte> beschriftet.
Schon das Geld für die besseren Megas zurück gezahlt?
Irgend wie, treiben sich hier immer mehr Krumme Typen rum.
Ich hatte bloß einen sehr kurzen Liefertermin mit der zu bauenden
Schaltung. Der ist wegen der Falschlieferung in die Hose gegangen.
Ansonsten hätte ich mich darüber gefreut, ist klar. Beim zweiten Mal
waren es dann FT245 statt Atmega32. Hat mich dann bewogen, woanders zu
bestellen.
Ich glaube allerdings nicht, dass man wieder so viel Pech mit Reichelt
haben kann.
Gruß Gerd
Hallo Leute,
ich sitze hier jetzt schon ein paar Tage an meiner Funkschaltung (RFM12)
und versuche die Hardware SPI Schnittstelle zum laufen zu bringen. Ich
sehe mit einem Oszi auch, dass Daten übertragen werden. Ich versuche die
Clock des Modules zu ändern. Leider ohne Erfolg.
Ich verwende einen ATMega32.
Vielleicht kann mir einer ja meinen Fehler zeigen.
Thx,
Christian
Hallo RFM-Gemeinde,
ich glaube das ist jetzt ein wenig OT aber ich denke das passt hier
schon.
Mittlerweile habe ich eine Menge Projekte unter FAST-AVR geschrieben und
sie haben immer beeindruckend gut funktioniert. Zuletzt jetzt das
Projekt mit 2 RFM 12ern. Es funktionierte natürlich nicht sie mit
Hard-SPI zum laufen zu zwingen. Also drangemacht an AVR-GCC und zum
testen Benedikts Code (danke Benedikt für deine Pionierleistung ;-) )
geladen, geändert und auf meinem Tiny2313 getoastet und......... siehe
da es funzt.
Jetzt aber mal meine Frage: Mein Code in FAST-AVR entspricht vom Umfang
der Funktionen derer in Benidikts Code in C. Nach dem Compilieren habe
ich aber bei FAST-AVR nur ca 56% RAM beschrieben während mir AVR-GCC
161% sagt.
Trotz allem habe ich ihn in meinen Chip bekommen. Senden-Empfangen funzt
aber die anschließende bearbeitung der Daten funzt nur ab und an.
Ausserdem habe ich auch festgestellt das manchmal nach dem Einschalten
der Chip langsamer läuft, Da ich am Anfang 2 LEDs blinken
lasse.(interner 4 MHz-Takt ist eingefused)
Wäre prima wenn mir jemand sagen könnte warum mir AVR-GCC eine
Speicherauslastung von rd160% angibt. Achja -os ist eingestellt. Bei
anderen einstellungen verändert sich allerdings nicht viel.
Vielen Dank schonmal vorab
hallo leutz, hab frage zur dieser Funktionsaufruf.
setpower(0, 6) // 1mW Ausgangangsleistung, 120kHz Frequenzshift
kann sein das die Frequenz auf 105kHz eingestellt wird und nicht auf
120?
Hier noch mal die Funktion:
void rf12_setpower(unsigned char power, unsigned char mod)
{
rf12_trans(0x9800 | (power&7) | ((mod&15)<<4));
}
falls ich falsch liege kurze Erklärung wäre sehr nett:)
thx
fantomas wrote:
> hallo leutz, hab frage zur dieser Funktionsaufruf.>> setpower(0, 6) // 1mW Ausgangangsleistung, 120kHz Frequenzshift> kann sein das die Frequenz auf 105kHz eingestellt wird und nicht auf> 120?
Ja, hast recht. 7 wäre 120kHz.
Hallo Rf12 - Programmierer,
Pionierarbeit auf dem Gebiet der RF 12-Module. Jetzt scheinen auch die
bekannten "Verdächtigen" auf den Zug aufzuspringen. Im Januar-Heft der
Zeitschrift Elektor sind gleich zwei Artikel dazu zu finden. Einmal ein
Artikel über die Module selbst und einmal die Programmierung einer
Übertragungsstrecke zwischen zwei RF12-Modulen. Wobei die Synchronierung
trickreich gelöst worden zu sein scheint. Auf der Elektorseite kann man
sich die Beispielprogramme kostenlos herunterladen: www.
elektor.de/071125.
Hat schon jemand damit experimentiert?
Gruß
Altprog
Hallo,
Ist der Code bei denen nicht in Bascom programmiert ? Bäähh.
Ja genau, aber das ist doch kein Problem. Man kann den Code doch auch in
andere Sprachen übertragen, soforn man die Fuktion verstanden hat.
Altprog
>Ja genau, aber das ist doch kein Problem.
Bascom ? Geht gar nicht ...
>Man kann den Code doch auch in andere Sprachen übertragen
Wenn ich mich in den Bascom-Code einarbeiten muss, dann kann ich auch
gleich weiter in Basic porgrammieren, aber wer will das schon.
naja, eine Programmiersprache ist doch nur ein Handwerkszeug ...
und wenn Du bascom nicht verstehst und von "einarbyten" sprichst,
aber C oder asm kannste? ... dat paßt irgendwie nicht ....
>nicht verstehst
Davon hat keiner gesprochen, programmiere ab und an noch was in
VisualBasic am Rechner, so isset nicht.
Jedoch hat Bascom mir nie gefallen, hatte mir auch mal das Buch von
Rowalt geholt, aber es direkt wieder verkauft.
>aber C oder asm kannste?
Früher (in den 90er - Oh gott bin ich alt ..) hab ich µC nur in ASM
programmiert (Damals nur PICs brrr).
Heutzutage programmiere ich nur noch C, da mann verschiedene Controller
nutzen will/muss.
>"einarbyten"
;-)
Hallo Rudger
> Davon hat keiner gesprochen, programmiere ab und> an noch was in VisualBasic am Rechner, so isset nicht.
oh dann solltest Du Dich hier registrieren, damit ich Dich mal
direkt per email kontaktieren kann ...
>> aber C oder asm kannste?> Früher (in den 90er - Oh gott bin ich alt ..) hab ich µC> nur in ASM programmiert (Damals nur PICs brrr).
handshake, alldings haß ich PICs, 8051er .. das waren mir lieber
> Heutzutage programmiere ich nur noch C, da mann> verschiedene Controller nutzen will/muss.
ack,dto.
... ergo kannst Du sehrwohl den Quälcode in bas(tel)com lesen!
Hallo,
eigentlich wollte ich ja keine Diskussion über Programmiersprachen
anstoßen. Deswegen wiederhole ich meine Frage: Hat jemand sich die
Beispielprogramme schon mal genauer angesehen oder gar damit
experimentiert?
Gruß
Altprog
Hallo
Also ich habe einige Fragen zu Bendikts Code:
Dazu schreibe ich die Funktionen hin und meine Frage in den Kommentaren,
bzw die Frage Allgemein.
Ihr würdet mir sehr helfen wenn ihr mir einige Dinge erklären könntet.
Also:
1.) Die Pins SDI und SDO und CS, müssten diese in der rf12.c nicht also
Eingang oder Ausgang definiert werden?
2.) Funktion: rf12_trans()
1
if(wert&32768)/
2
sbi(RF_PORT,SDI);
3
else
4
cbi(RF_PORT,SDI);
5
werti<<=1;
Also ist SDI nicht der Input? Ich denke mir Folgendes Bei dieser
Funktion, alle bits bis auf das 15 ausblenden und dann SDI je nach dem
auf High oder Low setzen, dannach das vorletzte Bit der Variable der
Stelle 14 an die Stelle 15 Schieben und im nächsten durchgang senden.
Wieso wird hier SDI und nicht SDO verwendet?
3.) Funktion: rf_trans() [Siehe Kommentare]
1
if(RF_PIN&(1<<SDO))
2
werti|=1;
3
sbi(RF_PORT,SCK);
4
wert<<=1;//warum erste jetzt shiften?
5
_delay_us(0.3);//Warum 0.3 us?
6
cbi(RF_PORT,SCK);
Die Frage warum man SDO bzw den Output für den Input verwendet bleibt,
bzw wo definiert wurde ob Ausgang oder Eingang (DDRB =...)
4.)
Funktion: rf12_txdata
Warum Schicke ich in dieser Funktion zuerst:
rf12_trans(0xB8AA);
rf12_trans(0xB8AA);
rf12_trans(0xB8AA);
rf12_trans(0xB82D);
rf12_trans(0xB8D4);
Wechle beteutung hat 3xAA, 2D und D4 habe dazu nirgenst etwas gefunden.
5.) Funktion: rf12_rxdata
rf12_trans(0xCA81); // set FIFO mode
rf12_trans(0xCA83); // enable FIFO
Muss ich den FIFO am Ende der Funktion nicht wieder disablen, bzw würden
ein 0xCA83 nicht reichen? wozu das 0xCA81 davor?
6.) Was ist dieser FIFO? (JaJa First IN First Out aber was ersetzt der
mir?) :D
Ich bin für jede Hilfe/Antwort dankbar.
Liebe Grüße,
Michael
Michael Graßl wrote:
> 1.) Die Pins SDI und SDO und CS, müssten diese in der rf12.c nicht also> Eingang oder Ausgang definiert werden?
Ja, werden sie auch:
RF_DDR=(1<<SDI)|(1<<SCK)|(1<<CS);
RF_PORT=(1<<CS);
> 2.) Funktion: rf12_trans()> Also ist SDI nicht der Input?
Jain. SDI ist der Ausgang vom AVR und der Eingang vom RF12. Je nachdem
von welcher Seite man es aus betrachtet ist es also entweder Ausgang
oder Eingang.
> 3.) Funktion: rf_trans() [Siehe Kommentare]>>
1
>if(RF_PIN&(1<<SDO))
2
>werti|=1;
3
>sbi(RF_PORT,SCK);
4
>wert<<=1;//warum erste jetzt shiften?
5
>_delay_us(0.3);//Warum 0.3 us?
6
>cbi(RF_PORT,SCK);
7
>
Wenn du vorher shiften würdest, dann würde das MSB verloren gehen.
0,3µs, weil das Datenblatt maximal 2,5MHz Taktfrequenz erlaubt. Dazu
noch etwas Reserve, damit es zu keinen Timingproblemen kommt.
> Wechle beteutung hat 3xAA, 2D und D4 habe dazu nirgenst etwas gefunden.
2DDA ist das Syncword, das der Empfänger erkennt. AA sind Binär
10101010, also möglichst viele Flanken, damit der Empfänger sich auf die
Baudrate einstellen kann.
> 5.) Funktion: rf12_rxdata> rf12_trans(0xCA81); // set FIFO mode> rf12_trans(0xCA83); // enable FIFO> Muss ich den FIFO am Ende der Funktion nicht wieder disablen, bzw würden> ein 0xCA83 nicht reichen? wozu das 0xCA81 davor?
Die Antwort hast du dir selbst gegeben: 0xCA81 schaltet den FIFO Mode
ein, deaktiviert aber das FIFO. Mit der Sequenz 0xCA81 -> 0xCA83 wird
die Syncword Erkennung gestartet.
Das Abschalten geschieht bei mir durch das Abschalten des Empfängers.
Benedikt K. wrote:
>> 2.) Funktion: rf12_trans()>>> Also ist SDI nicht der Input?>> Jain. SDI ist der Ausgang vom AVR und der Eingang vom RF12. Je nachdem> von welcher Seite man es aus betrachtet ist es also entweder Ausgang> oder Eingang.
Aso, so siehst du das, da ich immer von meinem AVR den ich Programmiere
Ausgegangen bin ist mir das nicht in den sin gekommen.
>> Wenn du vorher shiften würdest, dann würde das MSB verloren gehen.
Meine erste Idee war es auch dort zu shiften wo derweil werti <<=1;
steht, weil es dann in einem Logischen zusammenhang stehen würde.(Zu dem
Zeitpunkt an dem ist das MSB eh schon egal oder?)
> 2DDA ist das Syncword, das der Empfänger erkennt. AA sind Binär> 10101010, also möglichst viele Flanken, damit der Empfänger sich auf die> Baudrate einstellen kann.
Ahm, ich geh mal davon aus beim 2DDA hast du dich beim A vertippt, Frage
wo steht das mit dem 2DD4 und fängt er dann erst zu senden an oder der
empfänger erst zum "empfangen" bzw das empfangen als Daten anzusehen?
> Die Antwort hast du dir selbst gegeben: 0xCA81 schaltet den FIFO Mode> ein, deaktiviert aber das FIFO. Mit der Sequenz 0xCA81 -> 0xCA83 wird> die Syncword Erkennung gestartet.> Das Abschalten geschieht bei mir durch das Abschalten des Empfängers.
Naja ich meinte das die Zwei Schritte auch nur mit 0xCA83 gemacht werden
könnten da ja beim 1 --> 001, 3--> 011, immer das erste Bit gesetzt
wird.
ASO mit RX off wird der FIFO auch bedeutungslos
Danke für die schnelle Hilfe.
lg Michael
Michael Graßl wrote:
> Meine erste Idee war es auch dort zu shiften wo derweil werti <<=1;> steht, weil es dann in einem Logischen zusammenhang stehen würde.(Zu dem> Zeitpunkt an dem ist das MSB eh schon egal oder?)
Ja, das sollte auch gehen.
Ich schiebe halt gerne mehr am Ende. Der Hintergedanke war, diesen Shift
als Wartezeit sinnvoll einzusetzen, aber der Compiler stellt die
Reihenfolge vermutlich um, daher funktioniert das nicht ganz.
> Ahm, ich geh mal davon aus beim 2DDA hast du dich beim A vertippt,
Ja. 4 und A sehen sich irgendwie so ähnlich.
> Frage wo steht das mit dem 2DD4
RF12 Datenblatt, Seite 18 unter 7. FIFO and Reset Mode Command.
> und fängt er dann erst zu senden an oder der> empfänger erst zum "empfangen" bzw das empfangen als Daten anzusehen?
Er beginnt erst nach dem Empfang von 2DD4 mit dem Füllen des FIFOs.
> Naja ich meinte das die Zwei Schritte auch nur mit 0xCA83 gemacht werden> könnten da ja beim 1 --> 001, 3--> 011, immer das erste Bit gesetzt> wird.
Es geht darum, dass ff bit (Bit 1) zurücksetzen, damit die Syncword
Erkennung neu gestartet wird. Man muss also beide Befehle ausführen,
damit es funktioniert.
Gut Danke die Fragen habe ich jetzt verstanden.
Nun bleibt nur mehr die Frage zum FIFO.
Frage Benedikt, wie müsste der Ablauf aussehen wenn ich das Ganze ohne
Polling realisieren würde.
Würde das dann so aussehen das vom nIRQ die Anfrage nach dem Nächsten
Bit zum senden kommt und vom nInt die Meldung das ein neues Bit anliegt?
Bzw was müsste ich spezielle einstellen?
lg Michael
Hallo
Thx, also der FITT geht auf High wenn Daten zum auslesen da sind, aber
wie bekomme ich mit ob ich mehr Daten in den FiFo zum schreiben Platz
haben?
Oder ist das abhängig davon ob RX oder TX aktiv ist?
LG, Michael
Hallo Forum,
ich versuche nun auch seit einiger Zeit die RFM12 zum laufen zu bringen
und zwar mit zwei Pollin-Boards.
Ich habe Benedikts Code ein klein wenig geändert. Es sollte bei
Betätigen des Tasters auf dem Senderboard eine 1 gesendet werden. Wenn
diese empfangen wird sollte auf dem Empfängerboard eine LED kurz
aufleuchten. Danach sollte die LED noch einmal, zur Bestätigung des
Programmdurchlaufes, aufleuchten.
Die LED leuchtet aber nur einmal auf. Der Empfänger empfängt also etwas
aber nur nicht die gewollte 1.
Ich habe nun keinen blassen Schimmer wo der Fehler liegt. Ich hoffe ihr
könnt mir helfen.
Den Code habe ich mal in den Anhang getan, damit das hier nicht zu lang
wird.
MfG
Robert
Das geht dann mit dem nIRQ Pin: Dieser geht auf Low, sobald sich
irgendwas im RFM12 tut. Wenn man mehrere Interruptquellen hat, dann muss
man erst den Status auslesen um festzustellen was den Interrupt
ausgelöst hat.
Ok, aber wofür ist dann der nINT?
Damit sich der nIRQ Rührt muss ich also nix tun/einstellen.
Also ich geh dann mal Testen.
Danke für die Hilfe.
Michael
Kann man den Frequenzhub verringern, indem man den Quarz wechselt?
Ich habe mal ausgerechnet, dass ein Quarz von etwa 4,75MHz bei
Einstellung auf das 915 MHz-Band Sendefrequnezen zwischen 427 und 441
MHz erlauben würde. Allerdings steht im Datenblatt was von min. 8 MHz.
Damit würde sich der große Frequenzhub von mind. 30 kHz auf weniger als
die Hälfte verringern, was eher amateurfunküblichen Bandbreiten
entspricht. Mit einem 5 MHz Quarz ginge immerhin 430,24 - 439,76 also
fats das ganze Amateurband, bei 15 kHz Hub
Hallo
Ich habe ein Problem bei der Initialisierung meiner Module. Und zwar
habe habe ich 2 rfm12 module aufgebaut eines auf einem Pollinboard und
eines auf einer eigen Kontstruktion.
Nun je nach Gemütszustand der Module initialisieren sie oder nicht.
Wenn ich mir das ganze am Oszi anschaue Sehe ich je nachdem eine
Frequenz mit einer länge vom 1000ns bzw 10mhz (das sollte wohl so sein)
oder eben nur irgend ne Schwingung mit 100ns länge. (Siehe Bild)
Frage ist das normal wenn die Module nicht initialisieren bzw ist diese
Frequenz normal?
Achja übertragen habe ich bis jetzt auch noch nichts erfolgreich. Dazu
hätte ich jedoch eine Frage wenn ich 15 mal ein 'T' übertrage und zum
schluß ein \n aber nur ein T einlese bleibt der Rest im rfm12 bzw wie
groß ist der Buffer im rfm12?
lg Michael
> Nun je nach Gemütszustand der Module initialisieren sie oder nicht.
zu meinem Frust, habe ich das auch so erlebt ... bis ich in einer
der letzten elrads gelesen habe, daß die keinen langsamen Stromanstieg
a la Netzteil mögen .. sprich man sollte sie mit einem Transistor als
Schalter via uC "an" machen ... sprich der Powerup-Reset braucht eine
steile Flanke.
Viel Erfolg
Vajk
Vajk .v.i. wrote:
> bis ich in einer der letzten elrads gelesen habe,http://de.wikipedia.org/wiki/Elrad
Solange gibts die RFM12 doch noch garnicht.
> daß die keinen langsamen Stromanstieg> a la Netzteil mögen .. sprich man sollte sie mit einem Transistor als> Schalter via uC "an" machen ... sprich der Powerup-Reset braucht eine> steile Flanke.
Habe ich bisher noch nie drauf geachtet und hatte noch nie Probleme
damit.
Wartest du vielleicht nach dem Einschalten vielleicht nicht ausreichend
lange bis das Modul bereit ist?
Hallo
Ich habe gerade festgestellt das die module auch dann einen 10mhz takt
ausgeben wenn ich Sie mitten im Programm per nRes auf low ziehe, dann
ist für die Dauer von low keine Frequenz mehr da aber dann kommt Sie
wieder.
Frage ist eine Frequenz von 10mhz kein Anzeichen für eine geglückte
Initialisierung?
PS: Meine erste überlegung war nicht das Schalten per Transistor sondern
das Reseten per µC. Einfach als Ausgang definieren und dann bei Zeiten
von High auf low switchen....
lg michael
edit: Gut Beitrag bearbeiten geht anscheinend nach X min nicht mehr.
So, ich habe Folgendes heraus gefunden das rfm12 modul gibt
standardmäßig 10mhz aus, nur nach meiner Initialisierung wird es so ein
müll....ich geh mal alle Pins nachmessen...
lg Michael
Hallo
Ich komme einfach nicht weiter, frage könnte mal jemand von euch einen
Foto machen was bei euch am CLK rauskommt bei erfolgreicher
Initialisierung?
edit: Ich weiß es hört sich Blöd an, Foto -> Screenshot vom Oszi.*nicht
das mir einer den Pin Fotografiert.... ;-)
Lg, Michael
Mike K. wrote:
> könnte mal jemand von euch einen> Foto machen was bei euch am CLK rauskommt bei erfolgreicher> Initialisierung?
Für was brauchst du ein Foto? Selbst ohne Bild solltest du doch 10MHz
von 1MHz auf dem Oszi unterscheiden können...
Dein Bild sieht gut aus:
http://www.mikrocontroller.net/attachment/46526/init.jpg
Das 1MHz Signal ist ein recht sauberes Rechteck, das 10MHz Signal ist
mehr oder weniger (je nach kapazitiver Last) verrundet. Ähnlich sieht es
bei mir auch aus.
Nach dem Einschalten:
1MHz -> gut
Nach dem Senden des Befehls der auf 10MHz umschaltet (also nach der
rf12_init():
10MHz -> gut
1MHz -> schlecht
Wenn die 10MHz rauskommen, dann ist zumindest die SPI Verbindung zum
RFM12 in Ordnung.
Hallo,
ich werde jetzt auch mal ein paar Experimente mit den Modulen starten
und natürlich würde ich gern auf den hier geposteten Code zurückgreifen.
Mit welchen AVRs verträgt sich der den reibungslos oder zumindest mit
wenig Anpassungen? Ich fürchte ich brauch etwas mehr Speicher als die 2k
des ATTiny2313. Es soll aber ein Tiny werden, das es um eine
betteriebetreibene Fernsteuerung geht. Ein paar ATTyiny45 hätte ich da,
aber der hat zu wenig IOs.
Ich frag nur, weil ich mir nämlich neulich selber mal ein Bein gestellt
haben, mit dem Beschluss ein Projekt von einem ATMega32 auf ATMega644
portiert, was überraschend viel Arbeit war.
Grüße
Flo
Florian Rist wrote:
> Mit welchen AVRs verträgt sich der den reibungslos oder zumindest mit> wenig Anpassungen?
Der Code mit Software SPI ist auf einem tiny2313 und die Versionen mit
Hardware SPI auf einem mega8 entwickelt.
Von der Größe her sollte ein tiny2313 aber für alles reichen, auch von
der Geschwindigkeit her.
Nur wenn man die Sendedaten (z.B. aus einem UART Datenstrom) puffern
muss, dann sind die 128Byte SRAM schnell verbraucht.
Hallo Benedikt
> Der Code mit Software SPI ist auf einem tiny2313 und die Versionen mit> Hardware SPI auf einem mega8 entwickelt.
OK. Danke.
> Von der Größe her sollte ein tiny2313 aber für alles reichen, auch von> der Geschwindigkeit her.
Braucht das Funkmodul eigentlich auf der Sendeseite eine bestimmte
mindest Geschwindigkeit, oder könnte ich da mit der Taktfrequenz quasi
beliebig weit nach unten gehen?
> Nur wenn man die Sendedaten (z.B. aus einem UART Datenstrom) puffern> muss, dann sind die 128Byte SRAM schnell verbraucht.
Das muss ich nicht, also sind die 128 Byte wohl auch kein Problem
Grüße
Flo
Florian Rist wrote:
> Braucht das Funkmodul eigentlich auf der Sendeseite eine bestimmte> mindest Geschwindigkeit, oder könnte ich da mit der Taktfrequenz quasi> beliebig weit nach unten gehen?
Was meinst du mit Taktfrequenz? Der 10MHz Takt wird von dem Modul
selbst. Die Baudrate kann man an sich beliebig wählen, wenn man das FIFO
verwendet gibt es ein paar Grenzen aufgrund des begrenzten Teilerfaktor.
Wenn man das FIFO nicht verwendet, kann man die Baudrate an sich
beliebig lang machen (auch wenn dies wenig Sinn hat).
Hallo
> Ich denke, er meint den SPI-Takt.
Genau. Und damit indirekt auch den Takt des µCs. Ich dachte mir ich
versuche es mit weniger als den üblichen 10 MHz, um Strom zu sparen.
Allerdings ist es wohl auch kein Problem mit 10 MHz zu leben der µC wird
je eh die meiste Zeit in Tiefschlaf verbringen und so praktisch keinen
Strom verbrauchen.
Grüße
Flo
Der einzig limitierende Faktor ist die Geschwindigkeit mit der du Daten
rein fütterst. Das muss schnell genug gehen damit der Sendefifo nicht
leer läuft.
AHM....japadabadu....es lebt/sendet/empfängt.
Danke für die Hilfe und für den Code Benedikt.
edit: ahm wie ich den Fehler gefunden habe?
Nun ich habe alle Kabel nochmal nachgesteckt, dann haben beide Module
initialisiert, dann habe ich beide Module etwas senden lassen, eines der
beiden Module ist beim senden in ne Endlosschleife gekommen (aktiviertes
led ging nicht aus), das war für mich defekt, nach einem Wechsel gings
dann fast auf Anhieb da es noch Probleme mit der Stromversorgung
gab....
lg mike
Hallo
ich habe eine Frage wie wirkt es sich aus wenn ich CS dauerhaft auf
Masse ziehe, da es ja eigentlich mein eingziger spi slave ist?
Bzw würde das Probleme beim Programmieren des AVR uCs per SPI bringen?
lg Mike
Mike K. wrote:
> ich habe eine Frage wie wirkt es sich aus wenn ich CS dauerhaft auf> Masse ziehe, da es ja eigentlich mein eingziger spi slave ist?
Ich habe es noch nicht ausprobiert, aber vermutlich ja, da der RF12
daran das Ende/den Anfang eines Befehls erkennt.
> Bzw würde das Probleme beim Programmieren des AVR uCs per SPI bringen?
Definitiv ja, denn dann ist SDO dauerhaft aktiv. Selbst mit am µC
angeschlossenem CS gibt es oft Probleme wenn kein Pullup an CS ist.
Ansonsten floated der beim Programmieren und ist dann eventuell auf Low.
Hy
ich konnte bis jetzt im Forum leider kein Hilfe dazu finden.
Ich kommuniziere zur Zeit zwischen zwei/drei RFM12.
Ich habe eine Basisstation, die mehrere Außenstationen abfragt. Dazu
wird jeweils eine ID versendet und wenn die Außenstation die hat
antwortet sie. So wollte ich doppeltes senden verhindern.
loop
[
send( ID0)
recieve()
send( ID1)
recieve()
send( ID2)
recieve()
]
Das ganze funktionert perfekt aber ich wollte mal testen was passiert,
wenn der z.B. ID1
z.B. durch Störungen nicht antwortet. habe ihn daher für 10 Sekunden
ausgeschaltet.... das Programm sollte die dann überspringen und noch die
anderen Stationen abfragen können.
Leider sendet meine Basisstation nicht mehr raus, nachdem er einmal
keine Antwort vom einer Außenstation bekommen hat! Die Außenstation
funktioniert wunderbar aber die Basisstation erst wieder nach einem
Reset(komplett Strom an/aus).
Damit er nicht in der Recieve Schleife hängen bleibt ( falls nur ein
Slave nicht geht) und ewig wartet habe ich den Timer zugeschaltet.
Dieser wird vor jeder Empfangsfunktion immer Timer =0 gesetzt. Der Timer
zählt
per ISR hoch und nach 5 Sekunden, wenn nichts kommt, bricht er mit break
ab siehe Code....
Mit dem Timer läuft es auch wunderbar weiter in einer Schleife aber er
sendet einfach
nicht mehr, sobald einmal keine Antwort kam. Das ist dann leider das
Ende der Kommunikation da ohne Befehl keine Antwort mehr vom allen
Außenstationen kommt :D
das habe ich hinzugefügt:
void rf12_ready(void)
{
cbi(RF_PORT, CS);
while (!(RF_PIN&(1<<SDO))) // wait until FIFO ready
{
if (Timer > 10)
{
error=1;
break;
}
}
}
auch der Versuch vor jedem senden eine neue INIT durchzuführen hat nicht
geholfen. bleibt der RFM12 irgendwie hängen?
Hallo
Ich habe jetzt das DB des rf12 3 mal durchkämmt aber finde die max SPI
frequenz nicht...
Könntet ihr mir da kurz helfen, ich vermute derzeit 10mhz/4 gehe ich da
richtig?
lg mike
Hallo
ähm 10/4 = 2,5mhz....
Der rf12 läuft ja mit 10mhz und bei 4mhz wäre der Teilungsfaktor ja 2.5
wovon ich aber noch nichts gehört habe oder ist das beim rf12 anders als
bei atmel pic und co?
lg mike
Es gibt 2 Grenzwerte:
Einmal die normalen Register, für die nur die man nur das Timing aus dem
Datenblatt einhalten muss, und dann noch das Auslesen/Beschreiben des
FIFOs das auf 10MHz/4 begrenzt ist. Das ist eine gemeine Falle.
Hallo
Danke für die Hilfe, frage weißt du zufällig wo ich die Timing zeiten
der Register finde. Bzw kannst du mir sagen ob es viele Probleme gibt
wenn ich an die grenze von 2.5mhz gehe weil du hast da sicher schon mehr
Erfahrung.
Edit: noch etwas im DB meines Atm168 habe ich das CPHA bit entdeckt für
SPI, nun bei folgendem Absatz steige ich aus, frage was macht der sp12
schickt er die Daten schon bei der steigenden oder erst bei der
fallenden Flanke?
Bit 2 – CPHA: Clock Phase
The settings of the Clock Phase bit (CPHA) determine if data is sampled
on the leading (first) or
trailing (last) edge of SCK. Refer to Figure 18-3 and Figure 18-4 for an
example. The CPOL
functionality is summarized below:
lg tester
Mike K. wrote:
> Danke für die Hilfe, frage weißt du zufällig wo ich die Timing zeiten> der Register finde.
RF12 Datenblatt Seite 13.
> Bzw kannst du mir sagen ob es viele Probleme gibt> wenn ich an die grenze von 2.5mhz gehe weil du hast da sicher schon mehr> Erfahrung.
Wenn die 2,5MHz wirklich kleiner/gleich als die 10MHz/4 sind, gibt es
keine Probleme (das ist zum Beispiel der Fall, wenn man den RFM12 Takt
als AVR Takt verwendet). 8MHz/4 (interner 8MHz Oszillator) habe ich auch
schon probiert, das geht auch ohne Probleme.
> Edit: noch etwas im DB meines Atm168 habe ich das CPHA bit entdeckt für> SPI, nun bei folgendem Absatz steige ich aus, frage was macht der sp12> schickt er die Daten schon bei der steigenden oder erst bei der> fallenden Flanke?
Der RF12 schickt die Daten bei der fallenden Flanke raus, und liest bei
der steigenden Flanke ein. Somit kommen nur die SPI Modi 0 und 2 in
Frage.
Da laut dem Timingdiagramm auf Seite 13 CLK zu Beginn und am Ende Low
ist, muss CPOL 0 sein. Somit bleibt nur SPI Mode 0 übrig.
Hallo
Danke für die Hilfe, eine Frage hätte ich noch, der rf12 idelt bei SCK
High oder?
PS: die Skizze auf seite 13 verstehe ich zwar nicht ganz aber der clock
da ist mit 2mhz eingezeichnet.... deshalb und auf grund deines Beitrags
nehme ich das mal als Grenzwert....
lg tester
Guten Morgen
ich hatte das Problem zusammen mit der schnellen Hilfe von Benedikt
lösen können.
Ich nutze einen Timer um ein ewiges warten ohne Antwort zu vermeiden.
Funktioniert mitlerweile auch wunderbar aber hatte leider Timer = 0 an
der falschen Stelle im Code in der TX Funktion... dadurch hat er nach
einmal Abbruch in der RX nicht mehr gesendet...
in der
void rf12_txdata(unsigned char *data, unsigned char number)
hallo,
ich habe mir letzte woche auch die beiden Funkmoduloe von pollin gekauft
RFM01 und RFM02 und jetzt möchte ich das so haben, dass ich an den
atmega8 vom sendemodul einfach 8 taster an die pins pd0 bis pd7 hänge
und dann damit 8 ausgänge auch pd0 bis pd7 am anderen atmega8 des
empfangmoduls steuern kann.
ist das mit deinem programm ( von benedikt ) so ohne weiters möglich?
schon mal danke für eure hilfe
Stefan
du kannst die zustände der Ports in einem Char speichern und den dann
sende. Der andere Atmega setzt die Port dann entsprchend des Chars. Man
müsste sich nur noch eine Fehlerüberprüfung überlegen.
mfg Gerrit
soweit wie ich weiß, ist in dem Programm keine Fehlerüberprüfung, wie
zum
Beispiel eine Hash. Bei so wenigen Daten, könnte man sie auch einfach
mehrmals senden. Desweitern könnte man auch noch ein Byte dranhängen,
das dafür sorgt, dass die Summe der gesetzten Bits z.B. gerade ist.
Hier sind noch ein paar andere Beispiel und Anregungen:
http://de.wikipedia.org/wiki/Pr%C3%BCfsumme
Wenn es auch RFM12 sein dürfen, dann hätte ich hier noch etwas:
Diese Software überträgt beliebige Datenpakete in beide Richtungen,
inkl. Fehlerprüfung und Empfangsbestätigung. Es wird auch automatisch
eine bestimmte Anzahl an erneuten Sendeversuchen unternommen, falls es
das erste mal nicht klappt. Der Erfolg der Übertragung wird von der
Funktion zurückgeliefert.
Das ganze ist eine Verallgemeinerung der RS232 Funkbrücke. Da ich das
ganze allgemein halten wollte, verwende ich außer einem Timer Interrupt
für die Timeouts keine weiteren Interrupts. Daher muss man regelmäßig
die Empfangsroutine aufrufen.
also wenn ich mir quasi 2 rfm12 funkmodule besorge und dann dein
beispiel c-code auf die atmega8 aufspiele, kann ich so die ports pd0 bis
pd7 auf den jeweils anderen atmega 8 ausgeben???
mfg
Ja, so in etwa.
Du musst dann halt anstelle der uart_getchar() Funktion den Port
einlesen und anstelle der uart_putc() den Port beschreiben.
Um so wenig wie möglich zu senden wäre es z.B. gut wenn man nur nach
Änderungen an den Eingängen einen neuen Wert sendet, also so in etwa:
und wenn ich das dann auf beiden atmegas aufspiele müsste das
funktionieren???
sorry wenn ich nerve aber ich hab da nicht so wirklich die ahnung von
;-)
mfg schönen abend noch
Nein, nicht ganz.
Die Initialisierung brauchst du schon noch.
Weiterhin müssen beim Empfänger die Daten auch noch wieder an die Pins
ausgegeben werden.
Salú!
Kann mir mal eben einer sagen, ob die reine Datenübertragung bei im mit
dem Code vom Benedikt funktioniert? Ich meine damit alle Daten, >= 0x80.
Bei mir funktioniert die Sache nämlich nur, solange ich mich auf die
Übertragung vom kleinen ASCII-Zeichnsatz beschränke (also bis Dezimal
126) beschränke. Das sehr zuverlässig. Alles drüber, bringt Mist.
Danke und Gruß
Es sollte eigentlich funktionieren.
Verwendest du zufällig die Software von ganz oben? Die hat nämlich ein
paar kleinere Bugs die u.a. sowas bewirken können.
Die neueren Versionen funktionieren aber definitiv mit allen Werten. Man
muss nämlich u.a. bei den Werten 0x00 und 0xFF dafür sorgen, dass nie 2
oder mehr solcher Werte aufeinander folgen.
Wieso soll man dafür sorgen müssen?. Die Übertragung von zweimal 0x00
hintereinander funktioniert bei mir ganz wunderbar. Ist auch laut
Datenblatt kein Problem.
Welche Software soll ich stattdessen verwenden?
Hallo Benedikt,
ich habs gerade nochmal getestet - zweimal 0x00 hintereinander gibt
keine Probleme. Erste wenn ich 0x80 oder etwas darüber sende gibts Zoff.
Ich verwendet Deinen Code, hab ich aber auf HW-SPI umgebaut, weil ich
kein Freund von wechselndem Timing im Clock bin. Fahr auch gut so.
Bis auf die "Kleinigkeit" eben...
Gruß
Schorsch
Schorsch wrote:
> Wieso soll man dafür sorgen müssen?.
Ganz einfach:
Der RF12 synchronisiert anhand der Flanken vom Signal seine Baudrate.
Wenn lange Zeit keine Flanken vorhanden sind (also bei 0 und bei 255),
kann es sein, dass die Baudrate wegdriftet und ein Bit übersprungen oder
doppelt eingelesen wird.
Da 0 ein Wert ist, der bei der Messwertübertragung durchaus häufiger
vorkommt als andere Werte, ist dies schnell passiert.
Das das Problem exakt ab 0x80 auftritt klingt stark nach einem Fehler im
Code. Zeig mal die komplette Software.
Hallo zusammen,
ich teste gerade mit einem Evaluations-Board V1.2 von Pollin die
Funkmodule RFM12. Das System läuft aber nur sporadisch.
Es kommt häufig vor, dass das RGIT-Bit nach einem transmitter register
write command nicht gesetzt ist.
Es wird die Funktion rf12_ready benutzt, das Programm hängt dann in dem
while.
Mit dem Command status read kann man sehen, dass nach dem power on nur
das POR-Bit gesetzt ist und kein anderes Bit im Status-Word.
Die sonstige Kommunikation zu dem RFM12 scheint ok, ich habe das mit dem
Befehl „low battery and microcontroller clock divider command“ getestet.
Es ist immer möglich den clock output einzustellen und dies mit einem
Scope zu prüfen.
Vielleicht kann mir jemand helfen wo ich das Problem suchen kann.
Hallo
leider bin erst dieser Tage dazu gekommen mich mit Hardware SPI zu
beschäftigen.
Nun habe ich Prompt das erste Problem ich bin zu schnell aber nochmal
von vorne:
Der hardware SPI Takt is 1MHZ (8mhz clock und SPI2X und SPR0 sind
gesetzt)
Nun wenn ich einen Befehl einzeln Absetze zb den für 10mhz clock
funktioniert alles nur wenn ich mehrere Parameter hintereinander Abgebe
scheint es als würde er diese nicht erkennen.
zum versenden der einzelnen Daten habe ich die Funktion
unsigned char spi_transresive(unsigned char data) {
unsigned char resive=0;
SPCR &= ~(1<<SPIE);
SPDR = data;
while(!(SPSR & (1<<SPIF)))
;
resive = SPDR;
SPCR |= (1<<SPIE);
return resive;
}
Diese Funktion rufe ich 2mal auf beginnent mit dem High teil...
Nun habe ich die funktion um einen teil erweitert und zwar wurde die
while bedingung erweitert um: && !(SPI_PIN&(1<<SPI_MISO))
Nun hat es aber anstandslos Funktioniert.
Mein Problem ist nun das diese Arbeit später von einem Interrupt
übernommen werden soll weshalb ich diese erweiterung nicht brauchen kann
irgend und nur SPIF reichen sollte.
Hat irgenjemand eine Idee was bei mir flash ist. (wie gesagt prinzipiell
funktionierts)
PS: Ich habe auch schon 1ms warten zwischen den Paramtern Probiert geht
auch wunderbar....
lg mike
Hallo,
ich habe Benedikts Schaltung und Code übernommen, aber bekomme keine
fehlerfreie Komunikation zwischen meinem RFM12 (als Sender) und RFM01
hin. Sender und empfänger bekommen die richtige Initalisierung. Sobald
der Sender angeschlossen ist, kommen Daten beim Empfänger an, aber diese
sind leider nicht die gesendeten, sonder zufällig auftretende Bits.
Vielleicht ist es ein Timingproblem oder einer der Chips ist einfach
kaputt. Ich habe leider nicht soviel Erfahrung und weiß nicht, wo ich
weiter nach einem Fehler suchen kann?
Danke und frohe Ostern
Sebastian
@Benedikt...
Erstmal herzlichen Dank für dein tolles Programm..
es läuft sehr zuverlässig.
Ich meine dieses : rfm12_just_rxtx.zip
Ich benutze allerdings die RFM12B-Dip Module mit 868 Mhz und 3,3Volt.
Die Module habe ich erstmal zur Probe mit Widerständen (1,8 und 3,3KOhm)
auf 5Volt angepasst.Klappt auch sehr gut.
Als IDE benutze ich AvrStudio und habe dein Programm hier entsprechend
angepasst.Dabei ist mir folgendes aufgefallen :
extern void rx_packet(void);
...hast du wohl im Eifer des Gefechts vergessen im rf12-header
einzutragen- AvrStudio hat gemeckert.
rf12_trans(0x80D7);// Enable FIFO
müsste aber heissen :
rf12_trans(0x80D7);//433 MHz EL,EF,11.5pF
Ist mir aber nur aufgefallen, weil ich die 868-Module habe und Diese
zu Anfang nur in unmittelbarer Nähe funktioniert hatten.
Habe ich übersehen, weil da " Enable FIFO " stand. :)
Man überliest es leicht.
für 868Mhz : rf12_trans(0x80E7);//868 MHz EL,EF,11.5pF
soweit - sogut - es klappt ja alles...
was ich aber nicht verstehe und im mom noch nicht nachvollziehen
kann - ist :
Warum brauchen die Module ca.30 sec. um sich zu synchronisieren ???
danach läuft die Übertragung perfekt - sogar aus meinem Garten.
Vorher habe ich mit dem Pollin-programm gespielt und es auch
zum Laufen bekommen. Hier finden sich die Module sofort.
Aber es arbeitet halt mit INT0.
Sag' jetzt bitte nicht - dann nimm das doch. :)
Da du wesentlich mehr Erfahrung mit den Dingern hast- als ich, würde ich
gerne wissen, warum das so ist ???
Mein Ziel ist eine Fernbedienung für eine selbstgebaute 5zu1-Anlage.
Deswegen muss der avr im Sender auch schlafen gelegt werden können,
um Batteriegerecht zu werden.
lg
kalliheinzi
> Nun wenn ich einen Befehl einzeln Absetze zb den für 10mhz clock> funktioniert alles nur wenn ich mehrere Parameter hintereinander Abgebe> scheint es als würde er diese nicht erkennen.
Zwischen den Einzelbefehlen muss das Chip-Enable deaktiviert und wieder
aktiviert werden. Wenn du länger wartest, tritt halt ein Timeout auf und
deswegen geht's auch.
Von mir gibt es eigentlich nur recht wenige Versionen. Hier die beiden
die ich empfehlen kann:
Eine einfache Testversion mit Software SPI, ideal für die ersten
Versuche mit dem RFM12:
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"
Bidirektionale Übertragung inkl. Empfangsbestätigung (nicht unbedingt
gut zum Verstehen geeignet, eher zum Anwenden):
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"
RFM01 und RFM02 verwende ich nicht mehr, daher gibt es davon nur je eine
Version die nicht perfekt ist, aber funktionieren sollte.
Hallo
Frage kann ich dem RFM12 nachdem ich meine Daten erhalten habe sagen
Danke das wars jetzt such wieder nach start Bytes?
Weil bis jetzt habe ich immer das Senden aktiviert und dann wieder auf
empfangen umgeschalten...
Lg mike
Mike K. schrieb:
> Frage kann ich dem RFM12 nachdem ich meine Daten erhalten habe sagen> Danke das wars jetzt such wieder nach start Bytes?
Ja. Anders gehts auch garnicht, denn der RF12 weiß nicht wann die Daten
zuende sind, er empfängt einfach immer weiter.
Zum Neustarten des Empfangs reicht es das FIFO abzuschalten und wieder
anzuschalten (0xCA81 + 0xCA83).
Eine Frage habe ich noch wie groß ist der FiFo maximal?
Ist es der Fifo IT Level Max von 15Bits also fast 2 Byte? Was passiert
wenn ich nicht schnell genug bin die Daten Abzuholen?
lg Inf
Ich habe ein Problem mit Hardware SPI,
Also das Original Programm von Benedikt funktioniert ohne Probleme mit
meinem uC board. Nun habe ich das ganze mal auf hardware SPI umgebaut.
F= F_CPU/16 => 20mhz/16
So das initalisieren des Modules funktioniert, das schließe ich aus den
10mhz clock output.
Beim senden polle ich SPIF...danach ist für mich die Übertragung
erledigt
Nun sende ich folgende Bytes an das Modul:
0x8238
0xB8AA
0xB8AA
0xB82D
0xB8D4
10 mal 0xB8AA
0x8208
Dann beginnt Das spiel wieder von vorne mit 0x8238 aber spätestens nach
dem 3mal bleibt es bei selbigem 0x8238 stehen weil das SPIF flag nicht
fällt. Nun scheint es so als würde das Modul hängen.
Nur selbst in den erfolgreichen Durchläuf werden keine Daten gesendet.
Hat dazu irgenjemand eine Idee?
Und was macht eigentlich rf12_ready den das habe ich irgendwie nirgendst
verbaut...
edit: Achja ob ich 0xB8AA nun 10mal oder 1000mal als Daten verschicke
ändert an der Situation nur wenig...
lg mike
Mike K. schrieb:
> Und was macht eigentlich rf12_ready den das habe ich irgendwie nirgendst> verbaut...
Es prüft ob Platz im Sendefifo ist. Ohne die Abfrage gehen alle Daten
außer den ersten beiden verloren, da das FIFO überläuft.
Gut jetzt habe ich ein rf12 ready verbaut:
Vielen dank für die ständige Hilfe vorallem am Sonntag.
SPI_PORT &= ~(1<<SPI_SS);
while (!(SPI_PIN&(1<<SPI_MISO))); // wait until FIFO ready
Nun werden zumindest Daten versand leider bleibt er nochimmer nach dem
3ten mal hängen.
Ganz so als sei das rfm12 modul abgeschmiert...
Des weitern habe ich herausgefunden das das RFM12 modul weiter Blockt
den ich den uC kurz resete. Nur wenn ich etwas länger auf dem Reset
bleibe funktioniert das Ganze wieder. Das RFM12 modul wird aber nicht
zurück gesetzt...
Lg mike
Ich glaube ich habe das Problem gefunden ich habe nach dem pollen des
SPI Interrupt frag vergessen dieses zu löschen und schließend das zuvor
gelöschte SPI ISR enable wieder gesetzt was zur Ausführung der SPI ISR
führte in der ich zuvor nur schwachsinn hatte... oder wird das SPIF flag
nach dem auslesen von SPDR selbst ständig gelöscht?
Leider kommte ich es noch nicht testen.
Lg, mike
Hallo
ist es normal das der RFM12 beim empfangen bei rf12_ready in einer
endlos schleife bleibt? Also wen nix von einem anderen gesendet
wird?warte er dort so lange bis jemand etwas sendet? Die Verbindung
dürfte gehen, da ich 10 Mhz am Clock Ausgang habe.
ich bekomm einfach kein verbindung zwischen dem rfm12 und rfm01 hin ich
hab die codes von Benedikt genommen und die Verbidnungen stimmen auch.
Ich bekomme bei beiden die 10Mhz Ausgang also müssten doch eigentlich
alles richtig sein!?
Ich bin über jede Hilfe dankbar.
mfg Christian
Hallo,
Ich habe heute viele Stunden damit verbracht den ganzen Thread zu lesen,
leider stehe ich nun vor einem noch größeren Problem.
Bei dem Projekt was ich gerade realisiere, handelt es sich um Folgendes:
Mit einer in ca. 2,5m Höhe angebrachten Kamera wird ein Roboter erkannt
und dessen Position bestimmt. Anschließend soll der Roboter zu einem
bestimmten Punkt fahren (später einem Ball nachfahren). Also der Roboter
selbst empfängt nur Daten zur Motorsteuerung, hat also keine Sensoren
oder ähnliches.
Nun, das Alles funktioniert soweit ganz gut, auch der Roboter ist schon
gebaut; leider fehlt mir noch ein wichtiges Element...
...eine Kommunikation zwischen dem PC und dem Roboter, per Funk (433Mhz
oder 868Mhz). Habe mir dazu das "AVR Evaluation Board" zum Senden der
Befehle gekauft. Zum Empfangen der Daten am Roboter hab ich ein eigenes
Board entwickelt. (beide mit einem RFM12 bestückt)
Nun mein Problem:
Ich habe schon relativ viel Erfahrung mit C++, Java und ähnlichen
Programmiersprachen. Leider bin ich im Bereich von µC nicht so gut
drauf.
Finde die Programme von Benedikt richtig gut (danke vielmals ;) ), doch
leider blick ich nicht so wirklich durch.
Ich möchte mein AVR Board mit einer RS 232 Schnittstelle mit dem PC
verbinden, dieser übergibt dann laufend neue Befehle, die an den Roboter
gesendet werden sollen.
Doch mit welcher Funktion (UART?!) kann ich mit dem Programm von
Benedikt diese neuen Befehle vom PC einlesen und anschließend immer
wieder senden!?
Habe das Programm "RFM12_RX_TX.zip", helfen mir da Funktionen aus dem
"uart.c" !?
Also schon mal danke, dass ihr meinen Beitrag durchgelesen habt und
vielleicht will mir ja jemand mit einem kleinen Programm oder Funktionen
welche ich dazu brauche, helfen ;-)
DANKE!!
Viele Grüße
Jan
Hallo zusammen,
mit Hilfe des "rfm12_just_rxtx"-Codes von Benedikt (danke hierfür ;-)
versuche ich eine Funk-Lichtschranke zu realisieren. Leider habe ich das
Problem, dass sich der Empfänger aufhängt, sobald der Sender nicht
erreichbar ist. Jörn Ahrens hat am 13.03.2009 das gleiche Problem,
allerdings mit anderem Quellcode, lösen können. Leider stelle ich mich
hier etwas blöde an und komme zu keiner Lösung.
Könnt ihr mir sagen, wie ich software-mäßig (z.B. wie Jörn mit einem
Timer), einen nichtantwortenden Empfänger ignorieren kann? Ich kann mir
den Fehler auch leider nicht wirklich erklären. Kommt es zu einem
Buffer-Überlauf des FIFOs? Über eine kleine Hilfestellung wäre ich
wirklich sehr dankbar!
Vielen Danke und ein schönes Pfingstwochenende!
Gruß,
Jens
PS: Am Quellcode von Benedikt habe ich nichts grundlegendes geändert -
muecke schrieb:
> Leider habe ich das> Problem, dass sich der Empfänger aufhängt, sobald der Sender nicht> erreichbar ist. Jörn Ahrens hat am 13.03.2009 das gleiche Problem,> allerdings mit anderem Quellcode, lösen können. Leider stelle ich mich> hier etwas blöde an und komme zu keiner Lösung.
Mit der Version sollte sich das ganze eigentlich nicht aufhängen.
Hast du das
if rx_data_in_buffer())
im Code drin gelassen?
Damit sollte eigentlich nur dann die Empfangsfunktion aufgerufen werden,
wenn auch wirklich Daten empfangen wurden.
Hallo Benedikt,
schön, dass gerade du dich meldest. Die Funktion habe ich, ähnlich wie
in deinem Beispiel, in einer for-Schleife untergebracht. Allerdings
möchte ich mit dem Modul, bei dem der Fehler auftritt, nur senden.
Konkret wird ein "S" gesendet und somit die Zeitmessung gestartet,
sobald eine Lichtschranke unterbrochen wird. Normales Senden ist kein
Problem, nur wenn ich den Empfänger ausschalte und in der Zwischenzeit
wieder was gesendet wird, hängt sich der Sender auf und eine weitere
Kommunikation mit wieder eingeschaltetem Empfänger, ist nicht mehr
möglich. Die if rx_data_in_buffer()-Funktion wird bei mir zwar
aufgerufen um mögliche Daten zu empfangen, allerings verwerfe ich die
Daten. Trotzdem findet ja im Hintergrund eine Fehlererkennung statt, wo
sich vermutlich bei mir der Fehler eingeschlichen hat. Du hast doch an
dieser Stelle schon Jörn weitergeholfen - meinst du nicht, dass ich an
der gleichen Stelle hänge?
Danke -
muecke schrieb:
> Normales Senden ist kein> Problem, nur wenn ich den Empfänger ausschalte und in der Zwischenzeit> wieder was gesendet wird, hängt sich der Sender auf und eine weitere> Kommunikation mit wieder eingeschaltetem Empfänger, ist nicht mehr> möglich.
Was hängt sich nun auf? Der Sender (wie hier) oder der Empfänger (wie du
im vorigen Post geschrieben hast)?
> Du hast doch an> dieser Stelle schon Jörn weitergeholfen - meinst du nicht, dass ich an> der gleichen Stelle hänge?
Nein, das war ein anderes Problem. Jörg hatte das Problem, dass er immer
auf Daten gewartet hat, auch wenn garkeine ankahmen. Bei dieser Version
wird durch das if rx_data_in_buffer() umgangen, denn nur wenn Daten da
sind, werden auch welche abgeholt.
OK - Ich versuche es mal ausführlicher zu beschreiben, meine Beiträge
scheinen doch verwirrend zu sein - sorry. Vorab: Es ist der Sender, der
hängen bleibt. Folgende Situation:
Der Sender sendet fortlaufend ein "S" an einen Empfänger. Dieser
Empfänger gerät jetzt aus dem Empfangsbereich (oder wird ausgeschaltet).
Der Sender merkt das nicht und sendet fleißig weiter. Kommt jetzt der
Empfänger wieder in den Empfangsbereich (oder wird wieder angeschaltet),
so kommt es zu keiner weiteren Kommunikation. Ich nehme an, dass der
Sender auf eine Antwort wartet, die das korrekt empfangene "S"
bestätigt?!? Ich muss zugeben, dass ich nicht alle Funktionen komplett
verstanden habe.
Ein Versuch per Watchdog zu resetten klappt leider nicht. Der Watchdog
wird zwar ausgelöst, doch leider lässt sich das RFM12-Modul nicht
resetten bzw. erneut initialisieren. Ich habe deshalb angenommen, dass
noch alte Daten im FIFO verweilen und nicht verarbeitet werden können.
Eine Quick-and-Dirty Lösung wäre vielleicht das resetten per Watchdog
mit anschließender neu-Initialisierung des RFM12. Nur fehlt es mir
leider an Hintergrundinfos, was ich zusätzlich zu der normalen
Initialisierung hinzufügen muss.
Hast du mal die Software unverändert ausprobiert und geschaut ob der
Sender dann immer noch abstürzt? Die sollte 1x pro Sekunde einen Wert
senden.
Dass das RFM12 sich irgendwo aufhängt und selbst ein Reset des AVRs
nichts bringt klingt sehr merkwürdig, denn eigentlich macht die Software
eine Init des RFM12 und beschreibt eigentlich alle Register nach dem
Einschalten.
Hallo Benedikt,
danke, dass du so schnell geantwortet hast. Bin leider gerade erst
wieder zum Basteln gekommen. Ich habe deine Original-Software
draufgespielt und siehe da, es funktioniert wie gewünscht ;-) Noch weiß
ich nicht wo mein Fehler liegt, aber ich werde nochmal Stück für Stück
meine Änderungen einpflegen und dann sehen wo es hakt. Vielen Dank
nochmal für deine schnellen Antworten.
Ich verfolge dieses Funk-Projekt hier schon seit langer Zeit und ich
muss einfach mal einen Lob an die Entwickler aussprechen, wie toll ihr
(aber insbesonderem du, Benedikt) hier Stück für Stück eine super
Software auf die Beine gestellt habt. Hat immer wieder Spaß gemacht, die
Entwicklung zu verfolgen!
Grüße, Jens
Da der Empfang der Daten in der check_rx_packet(); Funktion erfolgt,
muss diese mindestens mit 1kHz aufgerufen werden, ansonsten kann es zu
Problemen kommen.
Irgendwann muss ich den Empfang mal in den Interrupt verlagern.
Hallo zum vorerst Letzten ;-)
Ich habe meinen Fehler gefunden und möchte ihn kurz beschreiben.
Vielleicht hängt ein anderer Anfänger an einer ähnlichen Stelle.
Das Senden hatte ich durch einen Interrupt ausgelöst. Funktioniert auch
alles wunderbar, nur wenn der Empfänger nicht mehr erreichbar ist, wird
das Zeitinterrupt benötigt (fürs Timeout, meine ich). Dieser ist
allerdings durch den Sendeinterrupt blockiert. Echt ein blöder
Anfängerfehler, aber ich habe aus der Fehlersuche mal wieder gelernt.
Jetzt setze ich im Sendeinterrupt nur noch ein globales Char, welches
dann in der fotlaufenden for-Schleife ausgewertet wird und das Zeichen
entsprechend gesendet wird.
Nochmals danke -
hallo, habe mal ne kurze frage und zwar habe ich zwei rfm12 module in
betrieb genommen und möchte ganz einfach mit einem taster an PD1 auch
dementsprechend einen ausgang in meinem Fall eig PB0 steuern. Ich habe
folgenden code und er funktioniert auch soweit. Nur tut es nur, wenn ich
den taster an PD0 habe und drücke, kann ich am anderen Atmega an PD1 die
Led zum leuchten bringen jedoch blionkt sie immer nur kurz auf, wenn ich
den taster betätige. Woran liegt das???
Oh ich habe grade selber gesehen, das PD0 ja RXD ist, dann habe ich die
ganze zeit gesehen, das daten gesendet werden und dan TXD wieder
ankeokmmen.
jedenfalkls funktioniert die Übertragung schon.
ja ich hab das auf beiden atmegas drauf.
Reicht das nich wenn ich schreibe:
if (PIND & (1<<PD1)) {
PORTB = 0b00000011;
}
für die Verarbeitung??
Wie kann ich denn jetzt alle Ports PD0 bis PD7 einlesen und dann auch
wieder an PB oder glaube PC ist besser, da alle frei sind, ausgeben.
welche Funktion muss ich ändern?
Also mit einem Eingang alle Ausgänge ansteuern ist ja kein Problem,
aber ich möchte gerne jeden einzeln ansteuern.
mfg
So hab noch mal ne Frage und zwar wie kann ich wenn ich die daten wieder
ausgebe auch die Eingänge entprellen, sodass ich mit einem tastendruck
An bzw. und dann wieder Ausschalten kann?
Hier mein code, der aber "leider" nicht funktioniert:
Ich würde fast darauf tippen, dass es an debounce liegt, denn damit das
funktioniert, muss man drücken und innerhalb von 100ms wieder los
lassen. Dieser Zeitpunkt ist denke ich nur schwer zu treffen.
mh also ich hab da jetzt verschiedene zeiten ausprobiert aber daran
liegt es nicht.
kann man denn beim auslesen der daten was ändern oder kann es sein das
man so etwas überhaupt nicht auslesen kann, das der taster entprellt
ist???
so hier noch mal der code. hab noch mal bissl was geändert unter anderem
die if schleife nach hinten aus der ersten if schleife gezogen und die
zeit vergrößert.
also weenn ich direkt am sende avr ne led an PC0 hänge funzt das auch
mit an und aus aber eben nich am empfänger, dort bleibt sie so lange an,
wie man auch drückt.
habt ihr noch ne idee???
Hallo zusammen.
Ich hab gerade den 2-Jahres Thread hinter mir gebracht ;) Der längste
den ich an einem stück gelesen habe^^
Da ich mich auch bald mit den Modulen beschäftigen werde, wollte ich
einfach nur mal meinen Dank an euch aussprechen, an allen die daran
mitgewirkt haben. Ich Fang jetzt gerade erst mit C Programmierung an,
aber mit den ganzen Werken hier sollte es keine Probleme geben ;)
Meine RFM-Module sollen ADC-Werte (3x Temp. mit LM35 (Displayausgabe
funktioniert schon) + 6 versch. Spng. (6 Cellen LiPo) + Strommessung
(Wie am besten bis 150Amp messen?) Übertragen.
Echt saubere Arbeit von euch, weiter so.
MFG Timo S.
Hallo Leute,
am 18.05.2007 hat Georg folgendes geschrieben:
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
Jetzt habe ich genau die gleiche Konfiguration wie Georg, also die
beiden Boards, jeweils mit RFM12 von Pollin sowie beide mit Atmega32
bestückt. Er schreibt, dass er Pin-defines und Pullup ändern musste,
damit das Programm läuft. Kann mir mal bitte jemand sagen, wie die
Änderungen im Programm aussehen müssen?
Ähhhh, achja, bitte bei den Antworten (hoffentlich :-) berücksichtigen,
dass ich gerade erst anfange, mit AVR´s rumzuspielen.
Vielen Dank für die Hilfe im voraus
Ralf
Ralf schrieb:
> Jetzt habe ich genau die gleiche Konfiguration wie Georg, also die> beiden Boards, jeweils mit RFM12 von Pollin sowie beide mit Atmega32> bestückt. Er schreibt, dass er Pin-defines und Pullup ändern musste,> damit das Programm läuft. Kann mir mal bitte jemand sagen, wie die> Änderungen im Programm aussehen müssen?
In der rf12.c finden sich diese Zeilen:
#define RF_PORT PORTB
#define RF_DDR DDRB
#define RF_PIN PINB
#define SDI 3
#define SCK 5
#define CS 2
#define SDO 4
Dort müssen der Port und die Pinnummern eingetragen werden, wo das Modul
angeschlossen ist.
Erstmal möchte ich Benedikt K. dafür danken, dass er dieses gute
Beispiel veröffentlicht hat.
Ich möchte die rfm12 dazu nutzen Temperaturdaten(uint8_t und uint16_t)
zu "verschicken", mit dem Beispiel "Dies ist ein 433MHz Test !!!\n "
klappt dies auch tadellos, allerdings schaffe ich es nicht einzelne
unsigned char oder unsigned int zu übermitteln. Ein kleiner Denkanstoss
würde mir hoffentlich weiterhelfen.
Der Funktion musst du Daten übergeben (in Form eines unsigned char
Arrays) und die Anzahl an Bytes. Diese werden übertragen.
Du musst deine Werte halt irgendwie in das Array bekommen, z.B. über ein
struct oder per Hand den uint16 Wert in 2 Bytes zerlegen.
Hallo,
ich möchte nun auch eine Funkverbindung an meinen schon sehr weit
fortgeschrittenen Webserver bauen.
Leider schaffe ich es nicht, eine Verbindung herzustellen.
Wenn ich das Status-Register auslesen, nach dem ersten Start, bekomme
ich 0x4000. Das sieht ja noch ganz gut aus.
Nach dem Initialisieren ist das Statusregister aber immer auf 0x0000,
auch wenn ich das FIFO eingeschaltet habe. Es müsste aber doch
eigentlich das FFEM-Bit gesetzt sein, oder?
Ich habe die Version Benedikt verwendet, aber für einen DS89C450
"abgeändert". Sehr viel gab es da nicht, eigentlich nur die rf12_trans
Funktion ein bisschen abändern.
Ich habe die Funktion auch schon testweise in Assembler geschrieben,
genau die gleichen Probleme.
Desweiteren habe ich das Setzen der Frequenz, der Baudrate usw., was
eig. in in main passiert, in die init Funktion verschoben.
Setzen der 10Mhz funktioniert auch.
Ich weiß nicht, woran das noch liegen könnte...
Würde mich über Hilfe freuen!
RaphaelS
Hallo,
ich habe eine Schaltung mit Benedikts Software aufgebaut und mich dabei
auch an seinen Schaltplan gehalten. Gibt es jetzt eine Möglichkeit zu
sehen/testen ob soweit alles in Ordnung ist? Irgendeine LED die leuchten
sollte, ein Pin der high ist etc? Oder sollte ?
Viele Grüße Franz
Bei neueren Versionen gibt es eine leds.h. In der kann man Pins
festlegen an denen Status LED angeschlossen werden.
Bei den alten, einfachen Versionen gabs das noch nicht. Da könnte man
die Leitungen zum RFM12 anschauen: Wenn sich auf denen periodisch etwas
tut, dann sendet das Modul.
Hallo zusammen,
ich hatte die Funkmodule RFM12 (433MHz) von Pollin schon einige Zeit
(ca. 2Jahre) unbenutzt zuhause liegen. Jetzt habe ich die Zeit gefunden
diese an zwei Pollin Demo Boards anzuschließen. Verdrahtet ist alles
entsprechend dem Pollin Adapter Modul. Ich habe zunächt mal das
RFM12_RX_TX.zip Paket von Benedikt ausgepackt und auf meine
Konfiguration angepasst. Dabei ist der Prozessor Takt (Atmega8, 16MHz)
und der FSK Pin auf PB1 auf high zu legen wie schon früher besprochen.
Die Module geben beide einen 10MHz Takt aus (gemessen), den meine
Atmegas aber nicht verwenden.
Die Module liegen nebeneinander auf dem Schreibtisch (ca. 10cm Abstand).
Ich habe Beim Sender "sende...\n" und Empfänger die Meldung "Empfaenger
laeuft !\n" in MS/Hyperterm.
Läuft der Sender, Empfange ich Datenmüll mit einem Haufen Smileys und
Sonderzeichen, aber kein einziges Schnipselchen vom gesendeten Testtext
Den Code habe ich nicht verändert.
Habe schon mit und ohne Antenne versucht -> kein Einfluss.
Empfang mit 5x gesendeter Message ist:
Empfaenger laeuft !
DBIsartHBY !%&qAErh
aefQeaeQY!&%IqBea DBf BrheBY0%%Iz @Brt BBeQr`BBY!%%xABea
BBeaea BB\!%2qAea
Habe auch mal 0xAA gesendet anstelle des Test Textes, erhalte da aber
genauso Datenmüll. Das Bitmuster ist in den empfangenen Daten nicht
wiederzufinden.
Wenn ich nicht sende empfange ich auch nichts => ich denke ich habe
keine externen Störungen aus der Umgebung.
Module sollten nicht defekt sein. Wurden meines erachtens sehr pfleglich
und sorgfältig behandelt. (Jedenfalls bisher)
Habe keine Erfahrung mit HF Funk-Technik, kann aber ein Osziloskop
bedienen. Scanner habe ich nicht. Fernseher noch nicht probiert, weil
örtlich getrennt und der Nutzen hat sich mir für mein aktuelles Problem
noch nicht erschlossen.
Ich könnte ein paar Tipps gebrauchen:
Wo sollte ich als nächtes den Fehler suchen? Was kann ich noch prüfen?
Muss man mit Verstärkung und Frequenzeinstellungen eine Abstimmung
suchen? - Wenn ja, wie geht man geschickt vor?
Was kann ich jetzt noch an Fehlern ausschließen? (Stimmt die
Sendefrequenz, Rastet der Empfänger auf die Frequenz ein, komme ich in
die Präamble, ...)
Grüsse, Oliver
Hab das gleiche prob nur mit dem Basic Programm von bastelbär.
PLZ Help???
könnte sein, dass bei mir was mit der SPI Kommunikation nicht
stimmt...bin mir aber nicht so sicher.
Versuch mal den Prozessortakt runterzusetzen bzw. die Verzögerungen in
den SPI Routinen zu vergrößern. Das FIFO Register darf nicht so schnell
angesprochen werden wie der Rest. Daher kann es sein, dass alles andere
funktioniert, nur die Übertragung nicht.
Hallo,
erstmal muss ich sagen, dass der Code von Benedikt super ist (hat mir
viel Arbeit erspart).
ich habe heute endlich (nach langer langer Fehlersuche) eine
Funkübertragung zwischen einem RFM12 und einem RFM02 zustande gebracht.
Das Ganze funktioniert schon soweit, dass das RFM12 erkennt, wann Daten
angekommen sind und das RFM02 Daten sendet. Die empfangenen Daten werden
dann über USART an den Computer gesendet. Nur leider empfange ich nie
das was ich gesendet habe, also mir kommt es so vor, als ob alle Bits
eines Bytes wild durcheinander gewürfelt werden würden. Aber wenn ich
mehrmals das gleiche Sende, kommt jedesmal der gleiche "Müll" an (auch
wenn ich zwischendrin etwas anderes gesendet habe), also sind die
empfangenen Daten doch nicht ganz zufällig.
Beispiel: Ich sende "test" und empfange jedesmal 00111110, 00001111,
00000100, 00001010, 01111111, dann sende ich "...." und empfange
jedesmal 00111110, 01000011, 00100000, 01010000, 01111000
Komisch ist dabei noch, dass aus 4 gesendeten Bytes 5 Empfangene werden.
Hat jemand vielleicht eine Idee, woran das liegen könnte? Ich denke,
dass die beiden Module nicht genau aufeinander abgestimmt sind, obwohl
ich 2 AtMega8 mit jeweils einem externen Quarz von 3,6864MHz benutze.
(An dem Code habe ich nichts verändert.)
Schon mal im voraus Danke für eure Antworten
Grüße Julian
Da das RFM02 etwas bescheuert anzusteuern ist und nur kurze Peaks im
Takt der Baudrate ausgibt, könnte es sein dass einzelne Impulse
übersehen werden und daher manche Bits mehrmals gesendet werden. Lass
den Sender mal schneller laufen.
Hast du ein zweites RFM12 das du als Sender verwenden könntest, um zu
prüfen ob es damit geht? So könntest du zumindest sicherstellen, dass
der Empfänger funktioniert. Ich tippe nämlich immer noch auf ein Problem
beim RFM02.
Der Sender sendet auf jeden Fall (das habe ich mit einem Fernseher
geprüft). Aber ich werde es morgen nochmal mit einem anderen RFM12
probieren. Obwohl ich mir irgendein Problem mit dem Timing auch gut
vorstellen könnte.
Hallo liebe Funkgemeinde,
wir alle haben schon sehr viele Stunden mit diesen RFM12-Modulen
verbracht und einige haben vielleicht auch schon aufgegeben. Aber last
den Kopf nicht hängen. Die Dinger funktionieren wirklich, jetzt auch bei
mir. Ich gehe jetzt nicht mehr auf die Hardware ein. Ein bisschen
Konzentration beim Löten muss eben jeder mitbringen. Software habe ich
von Benedikt verwendet.
Die funktioniert eigentlich auf Anhieb, wenn da nicht das Problem mit
den Quarzen auf den Modulen wäre. Die sind eben nicht genau gleich und
wenn man jetzt eine Verbindung aufbauen möchte, muss einer von beiden
ggf. abgeglichen werden. Hier ein Beispiel:
Ich habe bei meinem Sender die Frequenz 868.92 MHz eingestellt.
( Achtung :Ich verwende die 868MHZ Module ! )
Für die Variable freq ergibt das einen Wert von :
(868.92-860) / 0.005 = 1784
#define RF12FREQ(freq) ((freq-860.0)/0.005) // macro for calculating
frequency value
rf12_setfreq(RF12FREQ(868.3)); // Sende/Empfangsfrequenz auf 868,92MHz
einstellen
Wenn ich jetzt im Empfänger nach dieser Formel auch den Wert für freq
berechnen lasse ich das zwar richtig, meine Module können aber nie
miteinander kommunizieren. Warum: weil die Quarze so ungenau sind. In
meinem Fall musste ich für freq den Wert 1747 beim Empfänger einstellen.
Theoretisch ist das die Frequenz von 868.735,hier treffen sich Sender
und Empfänger am Besten. Um jetzt bei euren Modulen die beiden Werte zu
ermitteln könnt ihr meinen Sourcecode verwenden.
Und das geht's:
1) Software im Sender wie von Benedikt
2) Software im Empfänger mit folgenden Änderungen:
rf12.c
void rf12_ready(void)
{
unsigned long timeout = 0;
cbi(RF_PORT, SDI);
cbi(RF_PORT, CS);
asm("nop")
while (!(RF_PIN & (1<<SDO))) //wait until FIFO ready or timeout
if (((timeout++)>70000)){break;};
}
main.c
.
.
sei();
uart_puts_P("Empfaenger laeuft !\n\r");
uint16_t freq=1745; // Startwert für Frequenzlauf
rf12_trans(0xA000|freq);
char sst[] = " ";
for (;;)
{
rf12_trans(0xA000|freq);
ltoa(freq, sst, 10);
uart_puts(sst);
uart_puts_P("\n\r");
freq++;
if (freq> 1751) // Endwert für Frequenzlauf
freq=1745;
receive();
}
.
.
.
Im Terminalprogramm sollte dann folgendes erscheinen:
Dies ist ein 868MHz Test 1745
Dies ist ein 868MHz Test 1746
Dies ist ein 868MHz Test 1747
( Habe meinen Text im Sender natürlich auch angepasst )
3) Den besten Wert ermitteln und später im Empfänger eintragen.
868 Module
z.B. 1747 => ( 1747*.005)+ 860= 868.735
rf12_setfreq(RF12FREQ(868.735)); // Sende/Empfangsfrequenz auf
868,92MHz einstellen
433MHz Module
z.B. 1755 => ( 1755*.0025)+430= 434.3875
rf12_setfreq(RF12FREQ(434.3875)); // Sende/Empfangsfrequenz auf
434.3875MHz einstellen
Eigentlich ganz einfach. Vielen Dank noch mal allen für die gute
Vorarbeit.
Viel Spaß beim Probieren!
Thomas
Ok hab auch den ganzen thread durchforstet und muss sagen respekt.
so nun zu meinem problem:
verwende das programm von benedikt "RFM12_RX_TX.zip" und blicke bei der
usart ausgabe nicht durch oder zumindest gehe ich mal stark davon aus
das ich die rs232 schnittstelle nicht richtig konfiguriere.
kann mir da mal einer weiterhelfen? das ein zigste was ich raus bekomme
und nicht schwer ist ist die baudrate von 19200, nur der rest keine
ahnung.
und dann mal frage ob das funktioniert
2 * Funk-AVR-Evaluations-Board v1.2
2 * Atmel ATmega 32 mit 16MHz Clock vom Board
2 * RFM12S
Newbie Daniel schrieb:
> kann mir da mal einer weiterhelfen? das ein zigste was ich raus bekomme> und nicht schwer ist ist die baudrate von 19200, nur der rest keine> ahnung.
Abgesehen von der Baudrate gibts beim UART auch nicht viel zu
konfigurieren für die übliche Anwendung.
Welche Einstellung suchst du denn?
hm...meinte für das hyperterminal. sorry wenn ich mich missverständlich
ausgedrückt habe. oder sollte man da ein anderes prog nutzen um diese
ausgabe auszugeben?
Die Baudrate ist klar, ansonsten 8bits, kein Parity, 1 Stopbit.
Ich verwende immer dieses Programm, das ist für sowas besser geeignet:
Beitrag "Neues Terminal-Programm für Windows"
ok also hatte ich doch alles richtig eingestrahlt. und bei mir kommt
irgendwie nur müll an.
zumindest kann es nicht an dem Seriel->USB Adapter liegen da er beim
test einbandfrei funktioniert hat.
als Antenne benutze ich eine 1mm² draht aufgewickelt zur spule.
habt ihr vielleicht eine ahnung woran es liegen könnte. zudem es ist
nicht immer der gleiche müll varriert etwas.
Sender
20 EB DD 87 E7 EE BF 08 80 F3
20 EB DD 87 E7 EE BF 08 80 F3
20 EB DD 87 E7 EE BF 08 80 F3
20 73 75 08 0A C8
20 73 75 08 0A C8
Empfänger
14 58 1A 79 71 41 F8
14 58 1A 5E 71 43 F8
14 58 1A 5E 71 43 F8
14 61 1A 59 1C 41 F8
14 94 75 1A 59 12 00 CD
also ein gewisses muster ist zu sehen aber net dat was kommen sollte und
empfangen tut er auch net. das sind die strings die beim start
ausgegeben werden sollen.
Die Daten haben Bitweise betrachtet nicht wirklich viel Ähnlichkeit.
Hast du schonmal ausprobiert, ob bekannte Daten die in der Software
gesendet werden (also z.B. uart_putc(0x23)) richtig ankommen?
ehm ok glaub wir missverstehen uns wieder aber mal wieder meine schuld
sorry die dinger kommen nur nach einem reset. muss mir angewöhnen das
ich ausführlicher werde.
sprich jede zeile kam nach einmal reset drücken.
und dann geht es ja ehr um die zeile:
1
uart_puts_P("Sender laeuft !\n");
oder sehe ich das falsch kann es sein das diese uart.c und uart.h net so
funzt wie sie soll für das funk-evu-board obwohl ich schon gescheckt
habe ob es wie beim normalen evu-board angeschlossen ist (was es auch
ist). oder muss ich da noch irgendwo was definieren um es auf das board
anzupassen? <- könnte ich mir ehr vorstellen aber wenn ja wo?
die prozessoren laufen beide von board aus auf 16MHz also vom quarz und
fuse bits passen. das prog selber hab ich auf die 8MHz stehen lassen.
muss man das auf die board frequenz anpassen oder was? <- mal dumm
gefragt
jo hab es mal nach dem schreiben gleich praktiziert und oh wunder der
sender gibt nun den richtigen string raus nur der empfänger net. hab
nochmal die fuse bits kontrolliert die sind bei beiden identisch und
durch ein einfaches blicken weiß ich das der quarz zumindest schon mal
dran ist aber raus kommen tut nur folgendes:
E0 E0 00 E0 E0 E0 E0 E0 00 E0 00 00 E0 E0 00 E0 E0 E0 00 E0 00 E0 E0 E0
00 E0 E0 E0 00 E0 00 00 E0 00 00 00 E0 E0 E0 00 E0 E0 E0 00 E0 E0 E0 E0
E0 00 00 E0 00 E0 E0 00 00 E0 00 00 00 E0 00
das kommt bei einmal reset.
aber so wie es ausschaut kommt der sender auch nicht viel weiter da der
string "sende..." nicht ausgegeben wird.
wie kann ich nun rausfinden wo er sich genau aufhängt? kann zumindest
noch sagen das er bis "rf12_txdata(test,32);" noch hinkommt.
ok anscheinend brauchten beide eine bedenkzeit und ein programm wechseln
was getsern sender war ist heut empfänger und umgekehrt und siehe da es
klapt nur das ich vor dem "Dies...." noch immer ein zeichen empfangen
wird keine ahnung von wo da es auch variiert.
Benedikt, danke für die tolle Arbeit!
Hat schon mal jemand daran gedacht, hierfür einen Wiki einzurichten?
Ich hab zwar nicht den ganzen Thread gelesen, aber mir scheint dass den
Usern immer wieder die gleichen Fehler passieren (z.B. fehlender
Bypass-C am RFMxx). Außerdem verliert man bei den verschiedenen über den
ganzen Thread verteilten Versionen und Unterversionen schnell den
Überblick.
lG Patrick
Ich benötige beim RFM12 den PIN nIRQ für den Wake-Up Timer
(Batteriebetrieb).
Leider wird nIRQ auf LOW gesetzt und blockiert, nachdem ein Byte
erfolgreich gesendet wurde (d.h. Statusbit RGIT => 1 und nIRQ => 0).
Wird jetzt der Wake-Up Timer gestartet, bleibt nIRQ die ganze Zeit auf
LOW. Das Wake-Up Event wird korrekt im Statusregisterbit WKUP angezeigt,
nur der nIRQ ist leider blockiert.
Ich habe keine Befehlsequenz gefunden, die den nIRQ sauber wieder
freigibt.
Ich habe getestet:
- Lesen der Statusregister (0x0000)
- das Bit et im Power-Managemant gelöscht und gesetzt, wie im Handbuch
unter "12. wake-up timer" beschrieben
- Alle Varianten den Chip schlafen zu legen (0x8201) und wieder
aufzuschalten.
Als einzigen dirty Workaround habe ich gefunden, ein zusätzliches dummy
Byte zu senden und den Sender sofort stromlos zu schalten (0x8201) bevor
das Statusbit RGIT/FFIT Erfolg meldet und nIRQ wieder auf LOW geht.
Hardware: Pollin RFM12s Rev:3.0
Hallo zusammen,
zunächst vielen Dank an Benedikt für das tolle Stück Software.
Ich habe jetzt etwas Probleme, das ganze auf meine Fragestellung zu
portieren:
Ich möchte Daten zunächst über 2 RFM12 zwischen 2 Controllern
austauschen (halbduplex reicht). Die Daten gehen dann aber nicht sofort
an den jeweiligen UART, sondern erst mal in einen Buffer. Erst im Zuge
des weiteren Programmablaufs entscheidet sich, ob die Daten über den
UART gesendet werden oder direkt intern verarbeitet werden.
Hat jemand schon mal so etwas gemacht und ich habe es hier nicht
gefunden? Oder ist das so "exotisch", dass ich es selbst implementieren
muss ;) ?
Viele Grüße
Hermann
Hermann Gebhard schrieb:
> Die Daten gehen dann aber nicht sofort> an den jeweiligen UART, sondern erst mal in einen Buffer.
Das machen eigentlich alle Programme: Die empfangenen Daten werden
zunächst in einen internen Speicher eingelesen. Dann kann man die Daten
Byteweise abholen. Allerdings muss die Software dafür sorgen, dass der
Puffer leer ist bevor das nächste Paket ankommt, sonst gibts Probleme.
Die UART Ausgabe baue ich immer nur als Beispiele ein, da man so die
Software leicht ausprobieren und testen kann.
Hallo Allerseits,
das Problem vom Oliver Schneider ist gelöst.
Vorweg eine wichtige Hardware-Sache: Die Verbindung zwischen dem µC und
dem Funkmodul muss ziemlich kurz sein. Bei einem Pollin-Board und dem
Funkmodul auf einem externen Board, das mit einem Flachbandkabel
verbunden ist, funktioniert es mit einem ca. 20cm Kabel nicht mehr, mit
ca. 6cm dagegen wunderbar. Scheinbar ist das Clock-Signal zu schwach
oder die Sampling-Zeitpunkte für die Datenübernahme extrem dicht
zusammen, oder sonst irgendwas.
Ansonsten gibt es noch ein paar Verbesserungsmöglichkeiten und Bugs in
Benedikts Code (dem unidirektionalen für RF12).
- GAAANZ Wichtig: Das letzte gesendete Byte wird nicht ordentlich
übertragen, man muss also noch ein Dummybyte hinterherschicken. Das hat
wohl mit dem Empfang und verschiedenen Buffern zu tun, der
Taktrückgewinnung und irgend welchen anderen seltsamen Dingen.
Jedenfalls, wenn man noch ein weiteres Byte sendet, das beim Empfang
aber ignoriert, klappts.
- In der Empfangsroutine kann leicht über die Feldgrenze geschrieben
werden: Es wird immer ein unsigned short (sind offenbar 16 Bit, sonst
passt das mit den restlichen Routinen nicht) an eine Feldposition mit 8
Bit Platz geschrieben. Das funktioniert auch, bis man zum letzten
Element kommt. Da kann man dann nur hoffen, dass hinter dem Feld nichts
wichtiges steht. Besser, man schreibt einen expliziten Typecast in die
Zuweisung.
- Die Synchronisierungsphase vor der Präambel könnte man noch etwas
verlängern. Ich hatte das Gefühl, dass dann die Übertragung sicherer
startet.
Hallo Ihr,
ich versuche das beispielprogramm von Benedikt auf einem AT90USB128 zum
laufen zu bringen. aber leider bleibt es immer in der rf12_ready() in
der schleife hängen. Die funktion habe ich, nachdem ich gelesen habe das
schon mehrere hier ein problem damit haben, entsprechend geändert zu:
1
void rf12_ready(void)
2
{
3
cbi(RF_PORT, SDI);
4
cbi(RF_PORT, CS);
5
_NOP(); //einen Takt warten. Funktion aus ina90.h
6
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready; hier bleibts hängen
7
set_7seg(4);
8
}
die Dateien im anhang ist nur die erste version mit geänderten PINS für
MISO, MOSI, SCK und SS. Die Spannungsversorgung erreiche ich indem ich
das entsprechend an PORTD an einen PIN hänge (sind nicht alle
rausgeführt bei PORTB) der dauerhaft die Spannung gewährleistet.
Konfiguration:
1
#define RF_PORT PORTB
2
#define RF_DDR DDRB
3
#define RF_PIN PINB
4
5
#define SDI 2
6
#define SCK 1
7
#define CS 0
8
#define SDO 3
ich hoffe einer von euch kann mir bei meinem problem helfen und ich
befürchte das es ein dumme fehler ist den ich nur dauernd übersehe :(
Gruß und Danke
AVRnoob
- Wo bleibt er hängen: Beim Senden oder beim Empfangen?
- Funktioniert die Kommunikation prinzipiell, also wird der Takt vom
RFM12 auf 10MHz umgeschaltet?
Du könntest einen 2. AVR als Teiler durch 1 Million programmieren und
diesen damit Takten. Ob die LED mit 1Hz oder 10Hz blinkt sollte man
erkennen können.
Ich tippe nämlich auf ein generelles Kommunikationsproblem, denn
zumindest beim Senden sollte die Software nicht hängen bleiben.
also ich habs nun einfach an ein oszi von einem freund abgemessen (CLK
port am rfm12) und der schaltet aufjedenfall auf 10Mhz.
kann ich eigentlich den takt vom rfm12 irgendwie variabel ändern? beim
pollin beispiel steht drinnen das der mit 8Mhz taktet statt mit den 10
(einfach ein fehler?).
Nach langes Basteln funktioniert das Testprogramm mit dem Propeller
wunderbar !
Wer für Propeller Hilfe braucht kann sich bei mir gerne melden ...
Ciao
Hallo allerseits,
Horst Meier stellte in seinem Beitrag vom 23.06.2007 eine RFM12 (433
MHz) Assembler-Lösung für einen ATtiny 2313 vor.
Ich versuche gerade die Schaltung und den Code auf eine 868 MHz Lösung
mit einem ATMega88A mit RFM12B abzuändern.
Die Lösungen von Benedikt "rfm12_r2323_rxtx_check5" und "RF12_just_rxtx"
habe ich bereits mit 2 x STK500 und ATMega8L ( 868 Mhz )aufgebaut.
Die Datenübetragung funktioniert einwandfrei. Da ich zwar etwas
Erfahrung mit C habe aber kein C-Experte bin und einige Projekte bereits
in Assembler realisiert habe, scheint mir Horst's Lösung passender zu
sein.
Ich möchte ähnlich wie joern ( 11.03.2009 )von einer Basistation bis zu
3 Außenstationen ansteuern mit entsprechender Rückantwort.
Die Stationen sollen spätzestens nach 3 Minuten antworten, ansonsten
werden die Relais der Stationen per separater Watchdogschaltung
abgeschaltet.
etwa mit nur 3 Bytes : von Basis -> Station1
1.Byte Zieladresse
2.Byte Absenderadresse
2.Byte Command ( z.B. Aus- oder Einschalten und Watchdog retriggern)
danach 3 Bytes Station1 ->Basis
1.Byte Zieladresse ( hier die Adresse der Basis )
2.Byte Absenderadresse ( damit ich die Stationen unterscheiden kann )
2.Byte Statusinfo ( z.B aus- oder eingeschaltet etc.)
Die Funkübertragung ist nur ein Teil meines Projekts
Es werden noch diverse Sensoren ( Temperatur/Druck) ausgewertet (per
TWI) und Relais geschaltet.Eine kabelgebundene Lösung in Assembler
existiert bereits.
Ich hoffe es kann jemand helfen.
Gruß
Willy
Und was war jetzt die Frage?
Die Lösung hast du schon genannte: Du überträgst die Daten (z.B. hiermit
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module") so wie du sie
genannt hast, der Empfänger prüft ob die empfangene Nachricht für ihn
ist, falls ja wird sie abgearbeitet, falls nein verworfen.
Hallo Benedikt,
Vielen Dank für Deine schnelle Antwort.
Deine Software "just_rxtx" sendet die Bytes optimal nacheinander und
gibt pro Byte eine Rückmeldung an den Absender 0=ok 1=Fehler. Da es sich
in meinem Projekt um eine Basis und drei Außenstationen handelt ist
diese Kommunikation nicht ausreichend. Wenn von der Basis eine bestimmte
Außenstation angesprochen wird (über das Adressbyte),dann soll auch nur
diese entsprechend antworten und nicht alle.
Lässt sich das so realisieren wie ich das beschrieben habe ?
Wo genau in der Software sind die Änderungen notwendig ?
Gruß
Willy
Die rf12 Routinen kannst du eigentlich unverändert übernehmen.
Das eine Byte pro Übertragung ist nur ein Beispiel. Wenn du z.B.
tx_data(data,16); schreibst, werden 16 Bytes aus dem data Array auf
einmal übertragen. Maximal sind 128 Bytes möglich.
Ebenso beim Empfangen: Dort kommen auch die Daten als 128Byte Packete
an.
Hallo Benedikt,
for (;;)
{ check_rx_packet();
if (rx_data_in_buffer())
{ unsigned char count, i;
count=rx_data(data);
for (i=0; i<count; i++) // Empfang
{
uart_putc(data[i]);
}
}
if (uart_data()) // sende Beispiel
{
data[0]=uart_getchar(); // ???
uart_putc(tx_data(data,1)); // ???
}
}
wenn ich das richtig verstehe, dann wird durch die Funktion
check_rx_packet,
ob Daten vorhanden sind, wenn rx_data_in_buffer "true liefert dann wird
die Anzahl der empfangenen Bytes gezählt
count=rx_data(data) und anschließend alle Daten an die UART ausgegeben.
Den anschließenden Sendeteil vertehe ich nicht richtig.
uart_data() kommt aus uart.c und gibt 1 zurück wenn 1<<RXC ( receive
complete). Aber wie funktioniert das mit den beiden folgenden Zeilen ?
Gruß
Willy
Willy K. schrieb:
> wenn ich das richtig verstehe, dann wird durch die Funktion> check_rx_packet,> ob Daten vorhanden sind,
Ja. Allerdings läuft über diese Funktion der komplette Empfang der Daten
usw. ab. Daher muss diese ausreichend oft aufgerufen werden, damit der
Empfangspuffer des RF12 nich überläuft.
> wenn rx_data_in_buffer "true liefert dann wird> die Anzahl der empfangenen Bytes gezählt> count=rx_data(data) und anschließend alle Daten an die UART ausgegeben.
Jaein. Das ganze ist Paket basiert. Sollte eine nachricht empfangen
werden, wird diese von der check_rx_packet Funktion empfangen und in den
internen Puffer gespeichert. Das gesamte Paket wird über rx_data()
abgeholt und in das neue Array kopiert. Das muss ausreichend schnell
geschehen, denn wenn das nächste Paket empfangen wird, ehe das alte
abgeholt wurde, geht das alte Paket verloren.
> Den anschließenden Sendeteil vertehe ich nicht richtig.> uart_data() kommt aus uart.c und gibt 1 zurück wenn 1<<RXC ( receive> complete). Aber wie funktioniert das mit den beiden folgenden Zeilen ?
uart_data() zeigt an, dass sich Daten im Empfangspuffer befinden. Falls
ja, wird ein Byte mittels uart_getchar() aus dem Puffer gelesen, in
data[0] kopiert und dieses über tx_data() versendet. Zusätzlich wird der
Sendestatus über den UART zurückgesendet.
Das ganze ist nur zur Demonstration vorhanden, damit die Software direkt
ohne Anpassungen lauffähig ist, und man so die Module testen kann.
Hallo Benedikt,
ich verstehe ,dass die Software nur zum Testen der Module gedacht ist.
Die entprechenden Anpassungen muss ich wohl selbst durchführen.
Vielen Dank vorerst
Gruß
Willy
So, ich habe mein RFM12 nun auch zumindest als Sender mit eigenem Code
in Betrieb genommen. Ich hatte einige Probleme, beim Senden den die
Ready-Signale mittels IRQ bzw. SDO zu bekommen. Hier scheinen so
ähnliche Fehler auch recht häufig aufzutreten, daher mal meine
Erkenntnisse dazu:
Im Gegensatz zu den (falschen) Angaben im Datenblatt ist es nicht
möglich, Steuerbefehle im Sende-Datenstrom unterzubringen. Die
Beschreibung im Datenblatt (TX Register Buffered Data Transmission),
erst zwei Bytes in den TX-Buffer zu schreiben und dann per Power
Management-Befehl den Transmitter einzuschalten, funktioniert genau wie
das Ausschalten des Transmitters im selben Beispiel nicht!
Das heißt, Kommandos müssen immer am Anfang nach dem Ziehen der Chip
Select-Leitung abgesetzt werden, nach dem Schreiben irgendwelcher Bytes
in den TX-Buffer erkennt das RFM12 diese Befehle nicht mehr, solange die
Chip Select-Leitung noch gehalten wird.
Die ganzen Code-Beispiele halten sich interessanterweise nicht an die im
Datenblatt empfohlene Vorgehensweise und funktionieren daher.
Mit der folgenden Reihenfolge läuft mein Sender nun anscheinend
erfolgreich:
CS auf Low setzen
Config Command (EL=1)
Power Management Command (ER=0, ET=1)
Warten auf SDO==1 oder nIRQ==0
Schreiben in TX-Buffer
Warten auf SDO==1 oder nIRQ==0
.
.
.
Schreiben in TX-Buffer
Warten auf SDO==1 oder nIRQ==0
CS auf High setzen
CS auf Low setzen
Power Management Command (ER=1, ET=0)
CS auf High setzen
Die Kommunikation per SPI hätten die Designer des Chips wirklich etwas
durchdachter machen können. Die Rückmeldung zu gesetzten Register-Werten
ist gleich Null. Dabei wäre es schon nicht schlecht, ohne Hilfsmittel
oder zusätzlichen Schaltungsaufwand herausfinden zu können, ob der
Sender nun an oder aus ist. Glücklicherweise gibt es noch den
CLK-Ausgang, an dem man mit dem Multimeter(!) "debuggen" kann (indem man
CLK ein und ausschaltet).
Gastino,
ich habe mehr oder wenig genau dieselbe Erfahrung mit dem rfm12 gemacht.
Es geht noch zuverlässiger wenn du immer die ganze Reihenfolge schickst:
CS_Low
SPI_Befehl
CS_High
Die Sendegeschwindigkeit hängt praktisch von der SPI Geschwindigkeit
ab...
Ich habe ca. 86.000 kbs erreicht.
kann man mit den dingern so eine art funksteckdose bauen, aber mit
rueckantwort. ich bekomme naemlich immer die kriese wenn ich per funk
steckdose was an und ausmachen will aber nich erkennen kann obs geklappt
hat da das ja aus dem baumarkt immer nur one way ist ..
die naechste frage waere kann man mit dem rfm12 auch die baumarkt
steckdosen steuern?
wuerde dso nen ding auch gerne an den net-io haengen .. sollte gehen
oder?
wie zufrieden seit ihr mitlerweile mit dem ding?
viele gruesse mentox
Hiiiiiilfe!
Nach tagelangem rumprobieren mit den Modulen bin ich jetzt wirklich kurz
vorm Aufgeben...
Wie es aussieht wird was gesendet und der Empfänger sieht auch, daß da
ein Sender ist, aber der FIFO bleibt leer!!!
Ich hab fast den ganzen Thread hier gelesen und dieses Problem bisher
nicht nochmal gefunden. Hat jemand eine Idee?
Defekte Module kann ich weitestgehend ausschließen, da ich es schon mit
2 433MHz und 2 868MHz Modulen versucht habe.
Die Kommunikation mit den Modulen läuft anscheinend auch einwandfrei,
denn das CLK-Signal läßt sich ohne Probleme auf 10MHz oder "Aus"
schalten.
Benedikts Programm habe ich natürlich auch schon ausprobiert, aber da
tut sich leider gar nichts.
Und da Benedikts Progamm zwar gut strukturiert ist, es dadurch aber auch
etwas unübersichtlicher wird, habe ich mal etwas kompakteren Code
zusammengeschrieben, der empfängerseitig den Modul-Status pollt und auf
RS232 ausgibt. Und falls im Status ein voller FIFO angezeigt wird, wird
auch der FIFO ausgelesen und auf RS232 ausgegeben. Habe ich aber bisher
noch nicht erleben dürfen...
Die RF-Konfiguartion habe ich dabei von Benedikt übernommen.
Meine große Bitte wäre, daß jemand, bei dem die Module laufen, den Code
mal bei sich draufspielt und schaut ob er im Status was mit 0x8000 oder
größer bekommt.
Wenn irgendwas mit dem Bit 0x0100 kommt, wird zumindest ein RF-Signal
empfangen, wie es bei mir (meistens) der Fall ist. Das Status Read
Command ist ja im Datenblatt auch ausführlich beschrieben.
Für Leute die Sender und Empfänger genau abgleichen wollen, ist der Code
ebenfalls interessant, weil im Status ja der Frequenzoffset mitangegeben
wird...
Ansonsten ist der Code für einen ATmega8 mit Auslieferungskonfiguartion.
Also internem Oszillator und 1Mhz Takt. Und ich benutze das Hardware
SPI, weil es sehr einfach zu handhaben ist. Nur der nSEL-Pin muß
wahrscheinlich angepasst werden, da ich ihn auf PortD habe. Läßt sich in
den #defines leicht machen. Pull-up an FSK ist natürlich auch dran...
Oh, und der Sender benutzt nIRQ. Für den Fall, daß jemand auch den
Sendecode testen will.
Falls also jemand vor lauter Schnee etwas Zeit dafür übrig hat, wäre ich
sehr dankbar. Andernfalls wandert das alles bald in den Müll...
Viele Grüße
aXeL
Hallo!
Erstmals will ich mich bei allen die Code für die Funkmodule geschrieben
haben, bedanken... ich weiß echt nichtmehr woher ich alles hab, aber ich
glaub hauptsächlich eh von benedikt... Also Danke!
Auch wenn meine Source Codes noch nicht vollständig sind, und ich mir
noch nichts passendes für den empfang überlegt hab, will ich mal meine
vorläufigen Codes hier reinstellen. Bin demnächst drauf und drann das
ganze nochmal mit interrupts + fehlerkorrektur etc. zu schreiben, aber
zum testen ist das so mal ganz toll.
(Wollte zuerst alles mit #defines auswählbar machen, aber ich glaub das
wird sehr unübersichtlich. Aber so wies jetzt ist gehts glaub ich noch.
einfach in config.h alles richtig eintragen. Falls man den Reset
verwendet würd ich einen zusätzlichen Wiederstand empfehlen, weil ich
nicht weiß, was bitte ein DIO sein soll... hab mal was gelesen dass man
das für den Controller als Reset verwenden kann, die meisten lassen ihn
unbeschaltet, hat bei mir aber irgendwie nicht geklappt siehe unten...)
Weil ichs noch nirgendst gelesen hab und es aber aus unerklärlichen
gründen bei mir fehler gemacht hat: nRes lege ich über einen Wiederstand
(kiloohm unkritisch) auf die Versorgungsspannung. Erst seitdem ich das
mach funktioniert bei mir senden und empfang. lustigerweise hat das
umschalten der Ausgangsfrequenz (CLK) auch schon vorher funktioniert.
Bin mir aber nicht ganz sicher ob da nicht noch irgendein problem war...
Inzwischen find ich die hope datenblätter schon viel besser... es gibt
aber auch irgendwie verschiedene, bei manchen steht nur sehr wenig, bei
anderen viel... wenn man mal drinnen ist dann kann man glaub ich echt
viel mit den Modulen machen.
Sobald ich wieder Zeit hab gibts auch einen RF_FREQUENCY_868 switch.
Ich weiß dass es schon vieles gibt zu dem Thema, wollte nur mal einen
Laagebericht abgeben, da ich einige Probleme mit dem Pollin Funkboard
usw. hatte.. und es doch recht viel arbeit war bis alles funktioniert
hat.
Ich hoffe es hilft wem und ist nicht nur Wiederholung der letzten
Beiträge :P
hallo leute
ich möchte jetzt auch mal per funkt daten übertragen. Habe mir überlegt,
dass ich leicht anfangen sollte. Möchte also mal nur über funk eine LED
an und aus-schalten. Ich habe nicht ganz verstanden, wie ich die
hardware aufbauen soll. Einfach atmega8 an RFM12 oder mus noch etwas
dazwichen?
Hier sind ziemlich viele versionen würde sich die im anhang dafür
eignen?
danke für eure hilfe
Marcelo
Nicht alle auf einmal antworten bitte... ;o)
Was ist denn los? Seit 11 Tagen kein einziger Beitrag, trotz 20
Downloads...
Einer von Euch muß doch das Programm inzwischen mal getestet haben...
Auch wenn gar nichts funktioniert hat, würde ich mich über eine kurze
Rückmeldung freuen, damit ich vielleicht doch noch einen Anhaltspunkt
finden kann, warum es bei mir nicht richtig funzt...
Viele Grüße,
aXeL
hallo
habe nur mal ne kurze frage gibt es irgendeinen unterschied zwichen
rfm12 oder rf12? Das programm rf12 läuft das auch auf einem rfm12 funk
Modul?
Mfg
Tobias
Hallo aXel, hallo an alle RFM12-Benutzer,
ich muss mich jetzt auch in die Gruppe der Erfolglosen einreihen.
Nach dem bei mir ein Funkstrecke RFM02 -> RFM01 seit 4 Wochen
erfolgreich Daten überträgt, versuche ich es jetzt mit den
RFM12-Modulen.
Aber was das RFM12 sendet kommt nirgends an. Weder an einem RFM12 noch
an einem RFM01.
Empfangsseitig ist alles ok, das RFM12 empfängt die gesendeten Daten des
RFM02 korrekt.
Ich versuche jetzt schon seit 1 Woche den Fehler in der Senderoutine zu
finden, habe die Beispielcodes angepasst, verändert, zigmal das
Datenblatt gelesen, aber alles ohne Erfolg.
Das Trägersignal ist da, das habe ich mit einem Fernseher kontrolliert.
Ich habe schon unzähliges versucht, daher bin jetzt der Meinung, dass
die RFM12 (hab's mit 2 von 4 probiert) defekt sein müssen.
Vielleicht eine fehlerhafte Serie?
Ich habe meine Mitte Dezember bei Pollin gekauft.
Gibt es noch Andere, die auch das Sendeprobleme haben?
Danke schon jetzt für Eure Mithilfe.
Freundliche Grüße
Andreas
Hallo,
das Senden funktioniert jetzt doch.
Leider habe ich keine Erklärung, woran es lag. Am Code habe ich nichts
geändert. Möglicherweise hat's schon gestern funktioniert und ich hab's
einfach durch das viele ausprobieren übersehen.
Tut mir Leid, dass mein Beitrag von heute morgen unnötig war.
Gruß
Andreas
@ Andreas Montnacher
Hallo,
habe gelesen, dass deine Funkstrecke RFM02 --> RFM01 funktioniert.
Bei mir läuft es leider noch nicht.
Könntest Du mir mal bitte sagen, wie Du die Module an den Controller
angeschlossen hast, und evtl. deine Programme hochladen?
BRauche mal was zum vergleichen.
Danke
Gruß Tom
Einen schönen guten Tag auch, bin neu hier und hab mich mal n bischen
mit dem pic und dem RFM auseinandergesetzt, bei der Programmierung hab
ich mich sehr an eure Vorschläge gehalten, aber irgenwie ist da noch der
wurm drine, ich selber benutz das RFM12 von Pollin. Ich wollte damit ein
kleines spiel programmieren, um die Funkübertragung erstmal
auszuprobieren. Wäre cool wenn mir jemand nen tipp geben kann wo ich
scheisse gebaut hab.
Außerdem nimmt er den PORTA als eingang nicht an, und ich weiß nicht
wieso, aber ihr bestimmt:-)
Mfg Karl
Hallo Tom,
meine Programme sind in Assembler geschrieben und durchgehend
kommentiert.
Falls Du einen Assembler brauchst, am Anfang der Programme findest du
den Link dazu.
Die Verbindungen zw. AVR und RFM sind gleich denen vom Pollinboard.
Die Led's und Schalterpins nicht. Das 2. Funkmodul hatte ich immer auf
einem Steckbrett aufgebaut.
Die Settings der RFM-Register sind nicht unbedingt ein Muss, aber es
funktioniert mit diesen Einstellungen. Habe die Settings noch nicht
optimiert.
Zur Funktion: der RFM02 sendet alle 5 Sek, 5x das gleiche Byte, wobei
immer nur der Zustand eines Schalters gesendet wird.
Der RFM01 gibt den Zustand der Schalter an den Leds, als Flash, für ca
100ms aus.
Du kannst mich jederzeit fragen, wenn's klemmt.
Gruß
Andreas
Hallo zusammen,
ich habe im Datenblatt von dem RFM12 gelesen, dass man diesen auch ohne
TX Buffer/Register benutzen kann. Für eine spezielle Anwendung würde ich
gerne mit dem RFM12 Modul gerne einzelne Bits vertschicken können. Kann
mann, wenn man das Bit 7 "el" im Configuration Control Command Register
auf low lässt, einzelne Bits wie beim RF02 Modul versenden? d.h. wird
die Bit Rate vom RFM12 Modul dann als Taktgeber an irgendeinem Pin
herausgegeben und kann ich dann am FSK Input meine zu versendenen Bits
anlegen? Ich hoffe, dass mir da jemand weiterhelfen kann- danke für eure
Hilfe!
Gruß
Tim
Vielleicht ist es im Thread schon erwaehnt, ist etwas zu lange zum
gruendlichen Durchlesen:
Im Code von Benedikt K. (rfm02.zip vom 16.04.2007 15:28) fuer das
RFM02-Modul ist in der Funktion zum Setzen der Sendeleistung ein Bug.
1
voidrf02_setpower(unsignedcharpower)
2
{
3
rf02_trans(0xB000|((power&7)<<8));
4
}
Die Sendeleistung bleibt immer auf 0dB (also auf Maximum, weshalb es
wohl auch nicht direkt auffaellt), da die Bits fuer die Wahl der
Leistung nicht hoch genug geschoben werden. Sie muessten eigentlich
direkt ins hohe Byte, also direkt nach dem B stehen, laut Datenblatt zum
RF02.
Korrekt muesste der Code so lauten, wenn ich mich nicht irre:
Tim schrieb:
> Kann> mann, wenn man das Bit 7 "el" im Configuration Control Command Register> auf low lässt, einzelne Bits wie beim RF02 Modul versenden? d.h. wird> die Bit Rate vom RFM12 Modul dann als Taktgeber an irgendeinem Pin> herausgegeben und kann ich dann am FSK Input meine zu versendenen Bits> anlegen?
Ja, funktioniert. Es gibt allerdings keinen IRQ vom RFM12 als Takt für
die Bitrate. Das musst du im AVR mit einem Timer machen.
Abend, ich habe mir überlegt wie ich mit den rfms bisschen Energie
sparen könnte. Habe paar Infos zur Filter gefunden und mir überlegt ob
es eine gute idee wäre ein aktiven rc bandpass filter zu bauen mit den
man erst den nc weckt und dann den rfm Modul anschmeißt. Momentan wecke
ich meine ncs in bestimmten Abständen und lausche ob was los ist.
Wollte euch fragen ob Ihr in die Richtung schon was gemacht habt oder
bessere Ideen gibt wie man die Batterien schont.
Grüße fantomas
PS
bei lynx-dev gabs Preissenkung für Module. Die btm Module sind auch
billiger geworden.
Wenn der Empfänger immer erreichbar sein soll dann muss der Modul
ständig im Empfangsmodus sein und das kostet Strom(20mA). Und ich möchte
eben so wenig wie möglich Strom verbrauchen. Deswegen dachte ich warten
bis etwas auf der Frequenz spuckt und erst dann den Modul an schmeißen.
Hallo,
habe mir Platinen geätzt für das RFM01 und RFM02 und grade erst diesen
Text gesehen in den Sourcen:
> // nFFS: 1-10k Pullup an Vcc !!!
Da ich kein Bock habe die Platinen nun noch mal zu ätzen, warum muss das
und kann ich das nicht mit dem internen Pull-Up machen?
Fabian S. schrieb:
> Da ich kein Bock habe die Platinen nun noch mal zu ätzen, warum muss das> und kann ich das nicht mit dem internen Pull-Up machen?
Sicher, wenn du den Pin sowieso mit dem µC verbunden hast geht das auch.
Nur ist für den nFFS-Pullup nicht unbedingt ein µC-Pin notwendig, wenn
du nur dien FIFO nutzen möchtest.
Jo hab ich auch vorhin raus bekommen, danke ;)
Habe jetzt noch ein Problem, dass ich Datenmüll empfange. Das letzte der
32 Zeichen (letzte Leerzeichen in dem String) ist immer ein Zufallswert.
Also habe den Test verwendet aus dem Code hier, wobei ich jetzt doch
zwei RF12 Module drin habe.
Also du zu sendenen Daten kommen korrekt an, danach gibt es jedoch
Datenmüll beim ausgeben übern uart.
Vielleicht liegt es daran, dass mir nicht ganz klar ist wie das
Empfangen funktioniert. Ich sage der Funktion ja, dass sie 32 Bytes
empfangen soll. Wartet er dann wirklich bis 32 Bytes da sind? Macht er
eine Null-Terminierung?
Fabian S. schrieb:
> Habe jetzt noch ein Problem, dass ich Datenmüll empfange. Das letzte der> 32 Zeichen (letzte Leerzeichen in dem String) ist immer ein Zufallswert.
Nach dem letzten (32.) Byte mit Nutzdaten musst du noch 2 Byte
zusätzlich senden. Die letzten 2 Byte müssen nämlich noch aus dem
TX-Register zum Sender geschoben werden. Sonst bleiben die drin stecken
und der empfangende RFM bekommt nur noch Rauschen.
Fabian S. schrieb:
> Wartet er dann wirklich bis 32 Bytes da sind? Macht er> eine Null-Terminierung?
Wenn einmal das Sync erkannt wurde, liefert der FIFO so lange Daten bis
zum Abschalten des Empfangs oder FIFO Reset. Wenn das Programm 32 Byte
erwartet, wird es diese auch bekommen falls du nur die Hälfte sendest.
Der Rest ist einfach digitalisiertes Rauschen.
Verstehe ich das richtig? Ich soll statt 32 einfach 34 Bytes senden,
wobei die letzten beiden nur irgendwas ist, was irgendwo in der Tonne
landet?
Kommt mir seltsam vor :-/
Richtig, die 2 zusätzlichen Bytes sind nur "Dummys". Der RFM hat ein 2
Byte großes TX-Register. Das ist ein FIFO in Senderichtung. Wenn du nach
dem 32. Byte sofort den Sender ausschaltest, werden die nicht mehr
komplett gesendet. Daher schiebst du noch 2 Byte zusätzlich in den FIFO.
Damit werden die 32 Byte dann wirklich gesendet, vom vorletzten (33.)
Byte übrigens auch ein Teil. Ich habe das mit einem Logikanalysator
nachvollziehen können.
Naja ausschalten wollte ich ihn dann noch nicht.
Er soll ein paar Pakete im Abstand einiger Sekunden senden. Wenn ich
dann immer die 2 Bytes rein schiebe, damit er das aktuelle Paket sendet
kommen doch die beiden Dummy Bytes an, sobald ich das 2. Paket sende
oder?
Dieser Ablauf ist aber nicht gut. Damit ist der Sender auch dann aktiv,
wenn du gar nichts zu übertragen hast. So etwas soll nicht vorkommen.
Richtig wäre folgender Ablauf:
Sender: Tx an - sende Präambel (2D, D4) - sende 32 Byte Daten - sende 2
Dummybytes - Tx aus ...warten ... TX an ...
Empfänger: RX an - FIFO Init/Reset - 32 Byte empfangen - FIFO Reset - 32
Byte empfangen - FIFO Reset .....
Beim Einschalten des TX wird der TX-FIFO initialisiert. Die 2 Byte am
Ende stören so überhaupt nicht. Damit gibt es einen klaren Ablauf. Nach
dem Senden braucht der Empfänger natürlich etwas Zeit, um die Daten zu
verarbeiten bzw. zur RS232 zu schicken. Das muss mit dem Sender
abgestimmt sein. Sonst kann es zu Überschneidungen kommen und Daten
gehen verloren.
Ich muss zugeben, dass ich von den Modulen sogut wie keine Ahnung habe
und verwende die Lib vom Benedikt. (Vielen Dank übrigens!)
Habe da nun keine Funktion gefunden wie tx_on oder tx_off :P
Und auch um den Fifo zu resetten finde ich nichts. Wie stellt man das
an?
Hallo,
also ich hab hier ein paar allgemeine Fragen zu diesem Empfangsmodul.
Ich arbeite hier nämlich an einer Diplomarbeit und unsere Hauptschaltung
muss bis nächsten Freitag fix sein, es geht soweit alles, es fehlt aber
eben noch, dass RFM02 zum empfangen. Verwendet wird ein ATMEGA8, dieser
wird von einem externen Takt gespeist (1,8..MHz), ca. 5V
Versorgungsspannung, dann wird ein LCD im 4-Bit Modus betrieben, 2 ADC
Eingänge sind belegt, ein weiterer Pin von PORT C. Somit bleiben
eigentlich nur mehr PortC und PortB über für genügend Pins. Was ich mit
dem RFM02 machen will ist simpel, ich will ein Signal senden, welches
den µC aus einem Schlaf-Modi aufweckt, am liebsten wäre mir der
Power-Down Modus. Nun hab ich mich bereits ein WENIG in die Materie von
RFM eingelesen. Soweit ich weiß geht ein Pin High sobald der Buffer des
Modules voll ist. Nun hab ich mir gedacht, dass ich, das als externen
Interrupt verwenden kann zum wieder aufwecken. Nun, der Pin des externen
Interrupts ist ja bereits durch, das LCD belegt. Was nun? Den Pin vom
LCD anders Belegen? Gibts andere Möglichkeiten den µC aufzuwecken?
Weiters wollte ich auch nach der Beschaltung von dem Modul fragen. Ist
wirklich nur die Versorgungsspannung, Ground und ein 10k Widerstand
zwischen Data und Vdd nötig (Anhang)?
Und soweit ich, das verstanden habe müssen die Pins SDI, nSEL, SCK und
SD0 nun nur mehr mit dem µC verbunden werden. Der Rest bleibt in der
Luft?
Ich bitte um eine kurze Rückmeldung ob meine Gedankengänge richtig sind.
MFG Julian
Was das Anschließen des Moduls angeht kann ich nun nicht weiter helfen,
aber wenn du dein Pin des LCDs nicht umlegen willst kannst du ja den
16Bit Timer nehmen, um den Atmega regelmäßig aufzuwecken und schaust
dann kurz nach, ob was neues da ist. Bei 1,8Mhz und 16 Bit kommst auf
ca. 37Hz runter, der Stromverbrauch sollte also nur unwesentlich
steigen.
Hallo, habe die Kombination RFM01 und RFM02. Verwende den Code von
Benedikt (danke für die gute Arbeit) und habe es nun endlich nach 2
Tagen zum laufen bekommen. Es lag einzig und allein an der
Optimierungseinstellung. Hatte -O0 eingestellt und nun auf -O2
umgestellt und es klappt. Könnte mir bitte einer erklären, wieso es
daran lag oder wo man etwas zu diesen Einstellungen nach lesen kann.
Schau dir mal in Zukunft die Warnings deines Compilers genauer an. Der
AVR-GCC z.B. gibt ein sehr diskriptives Warning aus, wenn eine _delay
Funktion mit -O0 verwendet wird.
Gruß
Fabian
mal ne kleine Frage am Rande;-)
Die meisten werden wohl müde lächeln;-)
versuche RFM01-RFM02 zum laufen zu bringen mit Software von Benedikt.
Kann ich am Atmega auch den Internen Takt nehmen und auf 8Mhz stellen
und nur noch in der Software die anpassung von F_CPU vornehmen?
Wird das funktionieren?
Vielen Dank
Hallo Leute!
Ich habe mir nun auch die RFM12 Module von Pollin bestellt. Leider habe
ich, wie viele andere hier auch ein kleines Problem:
Ich bin Besitzer des Pollin AVR Funk Evaluationsboard, und habe dort ein
RFM12 Modul draufgelötet. Das Modul sendet am CLK die Frequenz 10Mhz
aus, und scheint auch zu senden und zu empfangen. Soweit wunderbar!
Das 2. Modul habe ich über einen Adapter auf mein Steckbrett gebracht.
Dort gibt es aber nur Probleme: Die Initialisierung scheint nicht
anzukommen. Es werden 1Mhz am CLK ausgesendet, und dadurch kann man auch
nicht senden oder empfangen, logisch. Ich habe bereits den AtMega32 und
den AtMega8 ausprobiert. Ich habe auch schon versucht, erst den
Empfänger einzuschalten, oder die Init-Routine mehrmals zu senden. Alles
vergeblich! Übrigens programmiere ich in Bascom :D
Die SPI Pins habe ich auch schon etliche Male überprüft, sogar mit denen
vom Pollinboard verglichen.
Ich bin nun wirklich am Ende meines Wissens! Ist das Modul kaputt? Kann
ich eine Erstattung fordern?!
DTMRacer
Also ich hatte es, dass sich das Modul nicht initialisiert hat einmal
dadurch, dass die Sleeps zu klein waren und dann auch, dass die Clock
nicht groß genug war. Also mit nem Clock von 1Mht habe ich es noch nicht
hinbekommen.
welche genauen Sleeps meinst du? Während der Initialisierungsphase? Also
zwischen den ganzen Routinen?
Und übrigens läuft mein M8 mit 8MHz.
Ich bin echt ratlos..
So ich hab dann auch nochmal ne Fragen, wenn hier noch jemand aktiv ist
;)
Ich versuche grade den Wake-Up Modus zum laufen zu bringen, es
funktioniert jedoch kein Stück.
Einfache Frage: Was zur Hölle muss ich machen???
Momentan sieht meine Initialisierung so aus:
rf12_init();
sleep_10ms(100);
rf12_setfreq(RF12FREQ(433.92));
rf12_setbandwidth(4, 1, 4);
rf12_setbaud(19200);
rf12_setpower(0, 6);
sleep_10ms(100);
rf12_trans(0xE000 | 512 | (1<<8)); // wake up timer value => 1024ms
rf12_trans(0x8200 | (1<<5) | (1<<1) | (1<<0) | (1<<7)); // WA aktivieren
Warum passiert da nichts am Interrupt Pin?
hmm.. :/ Ich weiß nicht genau welche Sleeps du meinst. Den Einzigen den
ich hier sehe, ist 150 ms vor dem Beginn der Initialisierung.
Kann es nicht vielleicht wirklich sein, dass das Modul kaputt ist?!
okay. Du hast ja oben schon erwähnt, dass du kein Bascom kannst, aber
danke für die Namen der Routinen!
Leider funktioniert auch das nicht. Übrigens wäre es auch unlogisch, da
ich aus Testzwecken exakt die gleiche Software auf beiden Controllern
habe. Und auf dem einem Controller funktioniert es ja. Erstmal geht es
bei mir darum, die 10Mhz am CLK zu erreichen.
Ich werde mich mal mit Pollin in Kontakt setzen...
Hi DTMRacer, ich hatte mit 3 RFM Chips das gleiche Problem, die init
wurde nur halb abgeschlossen und ich bin auch nicht auf 10 Mhz gekommen.
Hab die Timings während der Ansteuerung auch mal verzögert... Kein
Plan... Hab auch keine Lösung
Karl K. schrieb:> Hi DTMRacer, ich hatte mit 3 RFM Chips das gleiche Problem, die init> wurde nur halb abgeschlossen und ich bin auch nicht auf 10 Mhz gekommen.> Hab die Timings während der Ansteuerung auch mal verzögert... Kein> Plan... Hab auch keine Lösung
jaa.. ich hab jetzt eine:
Ich habe die SPI Pins von dem Pollin Experimentier Funk Board direkt an
dem funktionierendem Modul, mit Kabel ausgestattet. Den Vcc Jumper
gezogen, also bekommt das eig. funktionierende Modul keinen Strom mehr,
und die SPI Pins an das Modul auf dem Steckbrett geklemmt. Das Modul
springt nicht auf 10 Mhz. Also ist es wohl kaputt, ich wende mich jezt
einfach mal an Pollin, mal sehen was die dazu sagen..
Würde ich dir auch einfach mal empfehlen!
Hallo,
Wir haben uns vor einigen Tagen das Funkmodul RFM12 gekauft und haben
diese nun hier. In Bascom kennen wir uns zwar einigermaßen gut aus (so
grundlegende Funktionen) und wollten nun eine Datenübertragung mit Hilfe
dieser Funkmodule einrichten. Jetzt ist halt unser Problem, dass wir
ersteinmal von Funkmodulen keine Ahnung haben ;-)!
Nach Lesen von gefühlten 200 Posts in diesem Thread und nachdem wir uns
ca 5 Stunden mit dem Thema beschäftigt haben, kriegen wirs immernoch
nicht hin :-D
Ich wollte jetzt malhier euch fragen, ob jemand von euch uns den
Programmcode (Sende, sowie Empfangsmodul) in Bascom zur verfügung
stellen könnte.
Besonders hamma wäre natürlich, wenn jemand lust hat uns das zu erklären
bzw wir, nachdem wir das Programm haben, einige doofe Fragen dazu
stellen dürfen, wenn wir was nicht verstehen.
Hallo zusammen
Man das ist ja nen echt Krass langer Fred geworden in den letzten Jahren
XD
Ich habe einen Traum den ich gerne umsetzen würde.
Und zwar möchte ich in meiner Wohnung eine Art EIB Bus Haben der auf
Funk Basiert (Mietwohnung) um zB. per Fernbedienung Lampen oder anderes
Zeugs zu schalten.
Jetzt habe ich einige fragen:
- Hat jemand von euch so etwas schon mal gebaut und gibt es dazu
vielleicht schon eine fertige Dokumetation ?
-Funktionieren die RFM12 Module auch einwandfrei wenn man mehrere Sender
und Empfänger hat oder kommt es da zu Störungen untereinander ?
-Hab ich das richtig gelesen das man mit den Programmen die ihr
entwickelt habt 4byte übertragen kann ?
Was ich mir überlegt habe:
-da ich glaube ich nie mehr als 255 Geräte in meiner Wohnung haben würde
täte es eine 8bit Identifizierung der Geräte anhand zugeteilter IDs
-In den meisten fällen werde ich nur 1/0 als Daten wert brauchen
(Schalten)
-zum messen zB Temperatur dann 0-255 oder für Dimmer
-Fehleranalyse/Korektur der Daten mittels Parity oä. muss mich da
nochmal ind INF1 Skript einlesen :D
-Auswertung von Daten an einem Empfänger von mehreren Sendern
Was ich besitze:
-CNC-Fräse -> Platinen Fräsen mittels Target 3001!
-Tektronix TDS 1002b Digi ossi mit 1GS/s 2CH 60MHz
-Mögliche Kanalerweiterung von 10kanälen(1,0) Elektor Schaltung für Ossi
-C und mProzessor Kentnissen aus Studium (wenig Praxis mit AVR)
-AVR Programmer (mySmartUSB+Software)
-Steckboard, Lötkolben, und was man so braucht zum basteln :D
Ist das Reliesierbar Ja/Nein ? mit begründung bitte ^^
Viele Grüße Alex
Hallo,
ich habe ein kleines Problem mit meinem Empfänger:
Der Empfang der Daten funktioniert nur wenn ich am SCK-Pin ein ca 30 cm
langes Drahtstück anlöte... Ansonsten kommt nur Müll am Empfänger an.
Weiter oben gibt es schon so einen Eintrag mit einem Tastkopf am
sck-pin.... wurde eine Lösung gefunden?
Danke
Grüße Fabian
Alexander P. schrieb:> - Hat jemand von euch so etwas schon mal gebaut und gibt es dazu> vielleicht schon eine fertige Dokumetation ?
Gebaut ja, Doku nein.
>> -Funktionieren die RFM12 Module auch einwandfrei wenn man mehrere Sender> und Empfänger hat oder kommt es da zu Störungen untereinander ?
Bei Funk kommt es immer zu Störungen und jedes Modul ist Sender und
Empfänger.
>> -Hab ich das richtig gelesen das man mit den Programmen die ihr> entwickelt habt 4byte übertragen kann ?
Oder mehr, was der RAM so hergibt.
Hallo Benedikt,
habe Deinen (uralten) Code (vom 22.05.2007) entpackt, in Avr-Studio
importiert, die Konfiguration an die Pollin Funk-Board angepasst und
alles hat auf Anhieb funktioniert!!!!
Vielen Dank,
Grüße,
Micha
Hallo Micha,
ich arbeite auch mit dem Pollin Board und versuche es vergebens ans
laufen zu bekommen. Mir fehlt ein bisschen die Übersicht und bin so zu
sagen einsteiger in der AVR Programmierung mit c.
Vielleicht könntest du oder auch andere helfen. Möchte mein rf12 im
868MHz Band betreiben und einfach einen String übertragen. Ich würde
mich sehr über eure Hilfe freuen.
Vielen Dank
Hallo,
ich beschaeftige mich auch erst seit kurzem mit dem Modul und kenn mich
daher auch nicht so gut aus, bei mir funktioniert das Senden beim
empfangen habe ich auch noch meine Probleme, er haengt sich jedesmal in
der rf12_ready funktion auf. Satusregister ausgelesen und bekomme da
immer was anderes raus... vielleicht kann auch mir wer helfen.
-ATmega32
-Pollin Board
Aber vielleicht kann dir ein anderer aus diesem super Forum noch Helfen
ich druecke dir die Daumen.
Moin moin,
ich habe soeben meine beiden RFM12 868-MHz-Band FSK Module zum Laufen
gebracht. Allerdings nicht mit einem AVR, sondern der Sender laeuft mit
einem pic16f88 und der Receiver mit einem pic16f628a.
Der Sender schickt einen String samt checksum in die Welt und der
Receiver empfaengt den String und wertet die checksum aus. Das laeft
jetzt schon seit 1 Stunde ohne checksum-Error ueber 4 Stockwerke!
Wichtig ist die Initialisierung der Funkmodule! Ein gern gemachter
Fehler ist auch Port-Konfiguration des Controllers, heisst welcher Port
ist input, welcher output (SDI auf SDO usw.).
Wenn es gewuenscht ist, kann ich den Schaltplan samt Software posten!
der Kaila
Interessant wäre vor allem (eben auch für AVR-ler) die Initialisierung
bzw. Configurationsparameter für's RFM.
Also welches Register initialisiert du wie...
Gruß
Fabian
Moin,
oki, hier der Sourcecode samt Schaltplan, der fuer Sender und Empfaenger
gleichermassen gilt.
Die Software ist mit PikLab, sdcc, gputils und gpsim entwickelt worden.
Bitte gebt Bescheid, wenn ihr Ungereimtheiten findet. Ich bin gerne fuer
Diskussionen zugegen!
der Kaila
Vielen Dank fuer deine Bemuehungen. Weisst du zufaellig auch warum man
einen String empfaengt dieser im Terminal richtig angezeigt wird aber im
outputfile unterscheiden sich die Zeiten.
hier mal ein Beispiel:
13:54:34.322:
H
13:54:34.430:
i
13:54:34.430:
er wird auf 868.3MHz gesendet
empfangen
wuerde mich ueber jegliche Antworten freuen.
mfg
Hey,
das ging aber schnell :-). Also das ist ein Auszug aus dem Outputfile
von HTerminal mit dem ich meinen ganzen Sende Empfangsvorgang
ueberwache. Sprich ob eine uebertragung zu stande kommt oder nicht. Und
hierbei wundere ich mich ein bissschen ueber die "unterschiedlichen"
Zeiten.
Wuerde das gerne in ein Log file schreiben weiss aber nicht wie das
geht.
mfg
Vielleicht koenntest du mir deine Mail addresse geben dann koennten wir
vielleicht darueber etwas schneller uns austauschen vielen Dank.
oder wenn du moechtest schreib mich einfach mal an huibui@gmx.de
Hallo zusammen,
ich habe hier zwei RFM12 auf zwei Pollin Boards laufen.
Am Empfänger hängt ein Display, auf dem ich den empfangenen Text
ausgebe.
Kann mir jemand sagen, warum das letzte Zeichen immer Müll ist?
Kann das einfach nicht nachvollziehen.
Benutze den Code von Benedikt auf einem Mega32 mit 16MHz und das Display
hat nen T6963C.
MfG
Robert
Robert Knipp schrieb:> Hallo zusammen,>> ich habe hier zwei RFM12 auf zwei Pollin Boards laufen.> Am Empfänger hängt ein Display, auf dem ich den empfangenen Text> ausgebe.> Kann mir jemand sagen, warum das letzte Zeichen immer Müll ist?> Kann das einfach nicht nachvollziehen.> Benutze den Code von Benedikt auf einem Mega32 mit 16MHz und das Display> hat nen T6963C.>> MfG> Robert
Der Fehler ist in Zeile 42
Werner B. schrieb:> Der Fehler ist in Zeile 42
Na das ist ja mal eine konstruktive Antwort.
Zu viel Per Anhalter durch die Galaxis gelesen, oder?
Ich weiß ja dass meine Frage nicht gerade präzise ist. Ich habe aber
keinen balssen Schimmer woran es liegen könnte und dachte dass
vielleicht jemand hier einen konstruktiven Tip hat, wo ich bei der
Fehlersuche ansetzen kann.
Moin moin und Prost,
bin gerade in Zwischenstation vom Mera-Luna-Festival. Hab noch 'ne
dicke Birne aber, hier die kompletten Files meines Senders und
Empfaengers!
der Kaila
Ps: Arbeite unter Linux und kann nur zip. Sollte aber von WinZip de-
komprimiert werden koennen!
Pps: Der Sender rotzt jetzt testweise alle 10ms einen String nebst
checksum raus. Ueber 4 Stockwerke taucht dann doch ab und zu ein
chksum-Error auf, aber ganz selten! Ist schon ziemlich sicher die
ganze Uebertragung :-D
Hey,
wollte mal nachfragen ob es eine einfach Möglichkeit gibt eine CRC
einzufuegen? Da ich neu auf deisem Gebiet bin komme ich mit Kaila's code
nicht zurecht.
Theoretisch ist mir eine crc bekannt nur beim implementieren hapert es
noch.
mfg
Hi Niko,
der String "Kaila" wird in rfm12_snd_msg in der for-Schleife ins
tx-Fifo geschrieben, also in msg[0..4] steht der String. In msg[5]
ist dann die berechnete check-Summe. Das ist keine zyklische Redundanz-
pruefung, sollte aber fuers erste reichen.
msg[0]='K',
msg[1]='a',
...
msg[4]='a'
msg[5]=chksum
Der Empfaenger bekommt aus den rx-Fifo den String wie folgt:
msg[0]='K',
msg[1]='a',
...
msg[4]='a'
msg[5]=chksum
Die chksum in msg[5] vom Sender muss mit der berechneten im
Empfaenger verglichen werden.
Das sollte erst einmal den evtl. Datenverlust registrieren!
der Kaila
Hallo allerseits,
erst einmal vielen Dank Kailer fuer deine rasche Antwort. Nun habe ich
es geschafft eine CRC zu implementieren, aber bin auch schon wieder auf
ein neues Problem Aufmerksam geworden :-(.
Versuche ein syn. Byte zu senden damit der Emppfaenger bescheid weiss
das er empfangen kann. Es funktioniert nur habe ich ein
Verstaendnisproblem und zwar schicke ich s. Quelltext:
1
Sender:
2
uint16_tsyn,syn_Byte=0xAA;
3
...
4
rf12_ready();
5
syn=rf12_trans(0xB800|syn_Byte);
6
...
// und versuche das nun im Sender auszulesen was letztendlich in syn
drinsteht!
1
USART_Transmit(syn);
2
USART_Transmit(syn&0x00FF);
3
USART_Transmit(syn>>8);
4
USART_Transmit_String("\n",1);
// aber es sind nur Nullen, im Empfaenger jedoch sehe ich das AA
gesendet worden ist wie kann das sein?
hey,
nein das mache ich nicht, es wird der naechste Schritt sein eine Art
chat aufzubauen dazu benoetige ich spaeter vielleicht noch ein paar
Tipps.
mfg
Hallo Leute,
ich besitze auch die RFM12 Funkmodule. Alles funktioniert wunderbar, nur
mein Controller hat keine Zeit mehr die ganze Zeit auf das SDO Signal zu
warten. Mit anderen Worten: Ich möchte ein nIRQ Interrupt nutzen, wenn
das RFM12 Modul Daten empfangen hat. Meine Unterroutinen sehen
folgendermaßen in Bascom aus:
1
'--------------------------------------
2
'---Funkmodul---
3
'--------------------------------------
4
5
Sub Rf12_init:
6
Waitms 150
7
Temp = Rf12_trans(&Hc0e0)
8
Temp = Rf12_trans(&H80d7)
9
Temp = Rf12_trans(&Hc2ab)
10
Temp = Rf12_trans(&Hca81)
11
Temp = Rf12_trans(&He000)
12
Temp = Rf12_trans(&Hc800)
13
Temp = Rf12_trans(&Hc4f7)
14
Waitms 150
15
End Sub
16
17
18
Sub Rf12_setfreq(byval Freq As Single)
19
20
Freq = Freq - 430.00
21
Temp = Freq / 0.0025
22
If Temp < 96 Then
23
Temp = 96
24
Elseif Temp > 3903 Then
25
Temp = 3903
26
End If
27
Temp = Temp + &HA000
28
Temp = Rf12_trans(temp)
29
End Sub
30
31
32
Sub Rf12_setbandwith(byval Bandwith As Byte , Byval Gain As Byte , Byval Drssi As Byte)
33
Drssi = Drssi And 7
34
Gain = Gain And 3
35
Temp = Bandwith And 7
36
Shift Temp , Left , 2
37
Temp = Temp + Gain
38
Shift Temp , Left , 3
39
Temp = Temp + Drssi
40
Temp = Temp + &H9400
41
Temp = Rf12_trans(temp)
42
End Sub
43
44
45
Sub Rf12_setbaud(byval Rfbaud As Long )
46
Local Ltemp As Long
47
48
If Rfbaud < 663 Then Exit Sub
49
50
If Rfbaud < 5400 Then
51
Temp = 43104 / Rfbaud
52
Temp = Temp + &HC680
53
Else
54
Ltemp = 344828 / Rfbaud
55
Temp = Ltemp
56
Temp = Temp + &HC600
57
End If
58
Decr Temp
59
Temp = Rf12_trans(temp)
60
End Sub
61
62
63
Sub Rf12_setpower(byval Outpower As Byte , Byval Fskmod As Byte)
64
Outpower = Outpower And 7
65
Temp = Fskmod And 15
66
Shift Temp , Left , 4
67
Temp = Temp + Outpower
68
Temp = Temp + &H9800
69
Temp = Rf12_trans(temp)
70
End Sub
71
72
73
Sub Rf12_txdata(byval Maxchar As Byte)
74
Temp = Rf12_trans(&H8238)
75
Rf12_ready
76
Temp = Rf12_trans(&Hb8aa)
77
Rf12_ready
78
Temp = Rf12_trans(&Hb8aa)
79
Rf12_ready
80
Temp = Rf12_trans(&Hb8aa)
81
Rf12_ready
82
Temp = Rf12_trans(&Hb82d)
83
Rf12_ready
84
Temp = Rf12_trans(&Hb8d4)
85
Rf12_ready
86
For Count = 1 To Maxchar
87
Rf12_ready
88
Temp = &HB800 + Rfdata(count)
89
Temp = Rf12_trans(temp)
90
Next Count
91
Rf12_ready
92
Temp = Rf12_trans(&H8208)
93
End Sub
94
95
96
Sub Rf12_rxdata(byval Maxchar As Byte)
97
Temp = Rf12_trans(&H82c8)
98
Temp = Rf12_trans(&Hca81)
99
Temp = Rf12_trans(&Hca83)
100
For Count = 1 To Maxchar
101
Rf12_ready
102
Temp = Rf12_trans(&Hb000)
103
Rfdata(count) = Temp
104
Next Count
105
Temp = Rf12_trans(&H8208)
106
End Sub
107
108
109
110
Function Rf12_trans(byval Wert As Word) As Word
111
Local Lowbyte As Byte
112
Local Highbyte As Byte
113
114
Lowbyte = Wert And 255
115
Shift Wert , Right , 8
116
Reset Spi_cs
117
118
Highbyte = Spimove(wert)
119
Lowbyte = Spimove(lowbyte)
120
Set Spi_cs
121
122
Temp = Highbyte * 256
123
Temp = Temp + Lowbyte
124
Rf12_trans = Temp
125
126
End Function
127
128
Sub Rf12_ready
129
Reset Spi_cs 'Chip Select = 0
130
For I = 1 To 30000
131
If Spi_sdo = 1 Then Exit For
132
Next
133
End Sub
Ich habe nun den nIRQ Pin an INT1 am AtMega32 angeschlossen und den
Interrupt auf fallende Flanke konfiguriert. Leider wird beim Empfangen
kein Signal am nIRQ Pin geliefert. Muss ich diese Funktion im RFM12
konfigurieren? Und wenn, was muss ich an das Modul senden, damit ein
Interrupt ausgelöst wird, wenn Bytes im FIFO sind?
Viele Grüße,
Wolfang
Hi Wolfgang,
uha, ist das so ein Mix zwischen Basic und Fortran, was Du da
programmierst?
Oki, zum Thema. Deiner Initialisierung nach sollte der nIRQ-Pin vom
RFM12 im default-Zustand auf +5V sein. Das wuerde ich erstmal testen.
Bei mir war das anfaenglich nicht so (einige mV). Wenn dem so ist - also
nicht +5V -, dann wuerde ich ein 22uF Elko direkt am VDD und GND vom
RFM12 loeten und checken, was dann passiert. Die Dinger sind
betriebsspannungsmaessig ziemlich empfindlich. Bei mir liefen die erst
dann zuverlaessig....
der Kaila
Guckst du hier:
http://bascom-forum.de/index.php/topic,3421.0.html
Da gibt es Beispiele für alle möglichen Ansteuerversionen.
Der nIRQ bleibt übrigens so lange auf low, bis das Statusregister
gelesen wurde und entsprechend reagiert wurde. Beim FIFO IRQ muss der
FIFO geschrieben oder gelesen werden, die anderen IRQ's werden beim
Lesen gelöscht.
Moin,
hmmm, aber bei mir macht es keinen Unterschied, ob ich das Status-Reg in
der Initialisierungs-Routine vorsichtshalber lese oder Peng!
Erst mit dem Elko liess sich der nIRQ ueberreden, ueberhaupt auf High zu
gehen?!
der Kaila
Ich habe die RFM auf dem Pollin Funk AVR Board, da ist auch kein Elko in
der Nähe. Es funktioniert trotzdem. Hast du diesen "high sensitivity
reset" deaktiviert? Wenn man den Status ausliest, kann man ja sehen
welcher IRQ der Auslöser war.
Hallo,
ich mag diesen nIRQ-Pin nicht mehr.. Ich habe eure Vorschläge mal
ausprobiert, leider funktionierte es irgendwie nicht.
Naja.. und so habe ich halt weiter gesucht und gesucht und gefunden:
Ohne weitere(!) Konfiguration (siehe meinen Code oben) konnte ich den
FFIT Pin benutzen. Dieser schaltet auf High sobald der voreingestellte
Wert an Bits (Bytes?) im FIFO Speicher gelandet ist. Bei mir ist dies
glaub ich 8 Bits. Einfach den INT0 auf steigende Flanke konfigurieren
und mit dem Byte auslesen beginnen.
Trotzdem danke für eure Hilfe!!
Wolfgang
Ich hatte am Anfang die selben Probleme. Nur mit einem Logikanalysator
kommt man da wirklich weiter. Sonst tappst du da immer im Dunkeln.
Mit FFIT funktioniert es natürlich auch so. Aber Funktionen wie Wake-up,
welche einen IRQ benötigen kannst du nicht nutzen.
Hallo liebe RFM12 Nutzer,
erstmal danke an Benedikt fuer die Bereitstellung des Sourcecodes. Ich
habe 2 AVR Funkboards von Pollin und nutze den internen 8Mhz Takt des
ATmega32.
Leider bekomme ich das ganze nicht so recht zum laufen, meine AVRs
haengen im rf12_ready() beim warten auf den FIFO. Lustigerweise hatte
ich nach laengerem hin-und-her schon einmal eine funktionierende
Verbindung zwischen den 2 Boards hinbekommen. Nach kurzer Stromtrennung
hat das ganze aber nicht mehr funktioniert (1 mal tat der Sender spaeter
nochmal auf einem Board...). Seither haengen beide wie gesagt im
rf12_ready...
Kann mir bitte jemand weiterhelfen wie ich da auf Fehlersuche gehen
kann? Bin ein Anfaenger was Mikrocontroller betrifft, werde mich aber
bemuehen :)
Viele Gruesse,
Manuel
erstmal wollte ich mich auch an Benedikt bedanken für seinen starken
sourcecode.
nun nachdem ich die ersten teste mit dem rfm12 erfolgreich sind habe ich
festgestellt dass manche daten die ich empfange nicht rechtzeitig aus
dem fifo ausgelesen werden..gibts es die möglichkeit die Grösse des FIFO
buffer zu beinflussen oder ist die schon beim programm von benedikt auf
die maximale Grösse eingestellt?
vielen dank
Hi,
wollte mich auch für den code rfm01 und rfm02 bedanken.
Dann hätte ich noch ne Frage, beim rfm02 is ja keine fsk-modulation auf
dabei, über nimmt dein code die funktion dann?
MfG
Up4
Hallo Benedikt,
ich bin durch deinen Code aus folgendem Beitrag schon sehr viel weiter
gekommen:
Beitrag vom "Datum: 15.03.2009 19:17"
Da ich normalerweise nicht mit makefiles arbeite habe ich noch eine
kurze Frage zur Verwendung anderer µCs.
Ist es richtig, dass ich wenn ich anstelle eines ATmega8 einen
ATtiny2313 verwenden möchte nur im Makefile die Zeile MCU ändere?
Oder muss ich im Quelltext noch weitere Änderungen vornehmen?
Vielen Dank!
Das hat mir nicht sonderlich weiter geholfen. Ich nutze momentan den
Code rfm12_just_rxtx.
Auf zwei ATmega8 läuft alles wunderbar. Ich möchte das genze jetzt gerne
mit zwei ATtiny2313 zum laufen bekommen. Ich hab einige Probleme beim
Anpassen des Codes, da die ATtiny 2313 ja kein richtiges SPI haben.
Außerdem hab ich große Probleme mit dem compilieren, da ich sonst nicht
mit makefiles arbeite und normalerweiße nur eine .C Datei habe.
Alle Versuche, die ich in den letzten Tagen unternommen habe um das
ganze nach einigen Änderungen im Code zu kompilieren, sind gescheitert.
Ich nutze Code::Blocks. Wenn ich das Ganze zu compilieren versuche,
bekomme ich einige Fehlermeldungen, die alle wie folgt beginnen:
undefined reference to '...'
Ich konnte leider keine Lösung dafür finden.
Ich wäre über Hilfe sehr dankbar.
Grüße ext.
Hallo
Ich nutze das Funk-Avr-Evaluationboard und die Module RF01 bzw. RF02 von
Pollin. Das Senden funktioniert einwandfrei jedoch das Empfangen leider
nicht. Beide Module takten auf 10Mhz und ich weiß einfach nicht mehr
weiter. Im Anhang befindet sich der Code fürs empfangen. Kann mir
vielleicht einer weiterhelfen?
mfg Jonny
Hallo,
soweit ich das gesehen habe fehlt das "Receiver FIFO Read Command"
(0xB000) damit die Daten aus dem FIFO geladen werden. Aktuell sendest du
nur ein 8 Bit Kommando anstelle eines 16 Bit Kommandos ... (zumindest
wäre es beim RFM12 so).
1
for(j=0;j<16;j++)// read and discard status register
2
{sbi(RF_PORT,SCK);
3
asm("nop");
4
cbi(RF_PORT,SCK);
5
}
6
7
// hier 0xB0 senden => "Receiver FIFO Read Command"
Hallöle,
ich habe 2 Pollin-Boards v1.2 mit Atmega8 sowie jeweils RFM12-433.
Nach einigen Stunden Foren-Lektüre wage ich nun doch mal 'ne kleine
Frage:
Welcher der vielen Beispielcodes läuft auf meinen (unmodifizierten)
Boards? Dabei möchte ich den Atmega8 am 12MHz Quarz betreiben/belassen
und optimalerweise SPI benutzen (muß aber nicht unbedingt sein).
Kleiner Tipp wäre nett.
Viele Grüße
Igel1
Danke an Benedikt ich habe die Module mit zwei Anpassungen zum laufen
bekommen. Ich habe ein tamega32 in Verbindung mit avr bord von
robotikhartware gennutzt.
1. es muste nur die pins vom port änder
#define SDI 5 //5
#define SCK 7 //6
#define CS 4 //7
#define SDO 6 //0
2. die angepaste ready funktion nutzen weil dich der sender immer
aufgehangen hat.
void rf12_ready(void)
{
cbi(RF_PORT, SDI);
cbi(RF_PORT, CS);
asm("nop");
while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}
danke an alle.
Danke für den Beitrag auch wenn er schon ein paar Tage alt ist.
Hat mir doch Anregungen gegeben
Also ich beschäftige mich geraume Zeit mit RFM Module
und bin wie viele Wutausbrüche bekommen, weil das tweaken
nicht so stimme in den Hope Beschreibung ist.
Schaut euch die Microchip Doku zum MRF49XA ist identisch mit den Silab
Chip IA oder SI 4420 nur eben Microchip genau.
http://ww1.microchip.com/downloads/en/DeviceDoc/70590C.pdf
Was mich zur Verzweiflung gebracht hatte das der FIFO des Receivers
Das erste Paket richtig empfangen hatte und dann meist nur Müll.
Alles geändert was so geht auf TX RX Seit aber über eine richtige Daten
rate von über 10% Quersummencheck kam ich nicht darüber.
Also noch mal
http://www.mikrocontroller.net/articles/RFM12
studiert was man tun kann bei FIFO Overflow.
Meine MCU's liefen beide mit 10MHZ
Geschwindigkeit ändern, also internen.
Die Geschwindigkeit auf 16MHZ geändert und nun habe ich bei 4800 baud
525 gute zu 2 Drops.
Warum ich das geschrieben habe, weil ich selbst nicht glauben konnte das
bei einer so niedrigen Bitrate von Bedeutung sein könnte. CU :)
Hallo,
Ich beschäftige mich jetzt seit 2 Wochen mit den 868MHz Modulen und bin
langsam am verzweifeln.
Ich benutze die RFM12b Module mit 2 Atmega8, habe alle Änderungen für
die 868MHz übernommen und benutze den RFM12_RX_TX.zip Code von Benedikt
vom 16.05.07 mit der optimierten Senderoutine.
Ich musste lediglich die neue uart Library runterladen und alles ging
problemlos kompilieren.
Die While-Schleife läuft er problemlos durch, das "senden...." kann ich
sekündlich im Terminal auslesen.
Nur gibt er mir weder ein 10MHz Signal an SCK aus, noch kann ich sonst
irgendwelche Signale an MISO oder MOSI feststellen.
Also wird das RFM12 Modul wohl nicht richtig initialisiert, obwohl ich
beim Debuggen keine Fehler feststellen kann.
Neben anderen möglichen Fehlerquellen wollte ich mal Fragen, ob es an
meinem Atmel Studio 6 liegen kann, da der Code ja mittlerweile 8 Jahre
alt ist und ja auch die uart-Library schon veraltet war.
Vielleicht hat sich ja etwas an sonstigen Libraries geändert, sodass es
irgendwo zu Problemen kommt.
Alle anderen Fehlerquellen wie falsche Verdrahtung etc kann ich
ausschließen, da ich alles schon sehr oft kontrolliert habe.
Ich würde mich freuen, wenn mir jemand helfen könnte.
Gruß