Beispielprogramm für RFM12 433MHz Funk-Module

[Jürgen E. (sid)]

Hallo zusammen,

ich muss mich jetzt auch einmal melden... Gestern hab ich mich 
nachmittags hingesetzt und die Bibliothek etwas erweitert.

Zunächste einmal habe ich die Sende- und Empfangs-Methoden etwas 
modifiziert.

void rf12_txdata(unsigned char *data, unsigned char number);
unsigned char rf12_rxdata(unsigned char *data);

Beim empfangen von Strings muss man jetzt nicht mehr wissen wie lange 
das Paket ist. Es können variable Paketlängen bis zu 240Byte übertragen 
werden. Der Rückgabewert von rf12_rxdata() ist die Länge des Pakets. 
Zusätzlich sind die Pakete noch mit einem CRC16 gesichert und wurden 
bereits überprüft und nur richtige Pakete ausgegeben.

Dann ein großer Punkt ist das blockieren der Funktionen. In einem 
eingebetteten (meist echtzeit) System sind solche Funktionen eigentlich 
unerwünscht. Vorallem wenn einmal ein Paket nicht empfangen wird. 
Deadlocks sind hier ja schon fast vorprogrammiert. (Dieses Urteil mase 
ich mir jetzt einfach mal an.) Asynchrones programmieren (mit 
Interrupts) ist nie verkehrt...

Deshalb hab ich die Bib noch etwas erweitert. Mit den defines:

#define RF12_UseBlockingCalls  //NEVER USE BOTH
#define RF12_UseNoneBlockingCalls  //NEVER USE BOTH

kann man die blockierenden Methoden durch nicht blockierend ersetzten. 
Das Senden/Empfangen wird dann im Hintergrund abgearbeitet. Allerdings 
braucht man dazu einen Interrupt Pin. Der Prozessor blockiert jetzt nur 
noch kurz wenn man Daten an das Modul überträgt, oder anders herum.

// start receiving a package
unsigned char rf12_rxstart(void);

// readout the package, if one arrived
unsigned char rf12_rxfinish(unsigned char *data);

// start transmitting a package of size size
unsigned char rf12_txstart(unsigned char *data, unsigned char size);

// check whether the package is already transmitted
unsigned char rf12_txfinished(void);

// stop all Rx and Tx operations
void rf12_allstop(void);

Zugegeben ich war irgendwie unfähig einen Hardware SPI zu verwenden. Da 
hat das Empfangen der Daten irgendwie nie geklappt. Ka Wieso. Aber wenn 
das wer zum laufen bringt, dann kann man das blockieren noch weiter 
reduzieren G
Vom Prinzip her reicht mir das aber erstmal.

Probiert es einfach mal aus. Ich hab 2 Sample Projekte mit dem 
Kontrollerlab angelegt. Die Bib selber liegt in dem Lbr Verzeichnis und 
sind in die Projekt Verzeichnise gelinkt. Wenn wer Windoof verwendet 
dann muss er sie ggf in die passenden Verzeichnise kopieren.

Auch interessant ist vielleicht meine

unsigned char UART_Tx_Str(unsigned char *str, unsigned char size);

Methode, die ist ähnlich nicht blockierend... Man schickt einen 
beliebigen String über den UART ab und während der String gesendet wird 
kann man schon etwas anderes tun (mit winzigen Unterbrechungen).

Guggs euch an und sag mir was ihr davon haltet, oder wie scheiß ich bin 
G


Sers
Jürgen

[Jürgen E. (sid)]

file vergessen G

[Jürgen E. (sid)]

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

[Andreas P. (andyp17)]

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

[Benedikt K. (benedikt)]

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.

[Andreas P. (andyp17)]

Ich führe einfach folgenden Code in der Interruptroutine aus:

On_int0:
  Print "Bin da"
  Call Rf12_rxdata(maxchar)
  For J = 1 To 6
    Print J ; " " ; Rfdata(j)
  Next
Return

und Rf12_rxdata macht folgendes:

Sub Rf12_rxdata(byval Maxchar As Byte)
  For Count = 1 To Maxchar
    Rf12_ready
    Temp = Rf12_trans(&Hb000)
    Temp_byte = Temp

    'Wenn Temp_byte gleich 89 ist, Werte in Variable speichern
    If Temp_byte = 89 And J = 1 Then
      Set Rec_data
      Timer1 = 0
      Start Timer1
    End If

    'Laufvariable erhöhen, wenn Empfang freigeschaltet ist
    If Rec_data = 1 Then
      Rfdata(j) = Temp_byte
      Incr J
    End If

    'Empfang beenden, wenn Temp_byte gleich 85 ist
    If Temp_byte = 85 And J = 7 Then
      Stop Timer1
      Reset Rec_data
      Set Got_data
    End If
  Next Count
  Auswertung

  Temp = Rf12_trans(&Hca81)
  Temp = Rf12_trans(&Hca83)
End Sub

Ich weiß, du bist kein "Bascom-Mensch", aber könntest du vielleicht doch 
einen Blick drauf werfen?? Besten Dank!!


Andy

[Benedikt K. (benedikt)]

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.

[R. M. (rmax)]

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.

[Andreas P. (andyp17)]

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.

[neuer (Gast)]

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.

[Jörg Becker (Gast)]

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.

[Marvin e. (maavin)]

Mann, bin ich blöd...

ich hab die ganze Zeit am nIRQ ausgang gehangen und hab mich gewundert 
warum das nicht geht ^____^;

mit FFIT gehts natürlich. Und zwar genau so wie Benedikt das schon 
irgendwann mal beschrieben hatte...

also:

FFIT an INT1

...

Config Int1 = Rising
On Int1 Ffit_handler
Enable Int1

...

Ffit_handler:

    ' Byte lesen
    Temp = Rf12_trans(&Hb000)
    Rfdata(count) = Temp
    
    ' Momentan einfach feste länge lesen, STX ETX oder sowas ist aber
    ' hier auch kein problem...
    If Count >= Maxchar Then
      
      ' Wenn 32 Bytes gelesen wurden, Text ausgeben
      For Count = 1 To Maxchar
        Print Chr(rfdata(count));
      Next Count
      
      ' FIFO SYNC Erkennung wieder scharf machen
      Temp = Rf12_trans(&Hca81)
      Temp = Rf12_trans(&Hca83)
 
      ' und von vorne zählen
      Count = 1

    Else
      ' ansonsten nur zähler erhöhen
      Incr Count
    End If


Return

....

Ich programmier mir jetzt mal die STX ETX Erkennung mit einem timeout, 
dann seh ich weiter...

@Wigbert: ich hab jetzt mal gerade beim empfänger die abfrage auf 
spi_sdo=1 geändert... funktioniert auch... wenn er beim sender dann ne 
sekunde aufhört zu senden, dann wird das wohl richtig sein...

[Marvin e. (maavin)]

@wigbert:

wenn ich spi_sdo auf "1" abfrage bleit mein programm stehen...

[Wigbert P. (wigbert)]

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

[Wigbert P. (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

[Andreas P. (andyp17)]

@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

[JBecker (Gast)]

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.

[Marvin e. (maavin)]

also bei mir funktioniert das byteweise lesen über interrupt mit 19.200 
baud mit einiger logik in der interruptroutine (STX/ETX+CRC8)

[Hauke R. (lafkaschar)]

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.

[R. M. (rmax)]

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.

[Andreas P. (andyp17)]

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

[Andreas P. (andyp17)]

Danke, hat sich erledigt! Beim ersten Einschalten habe ich den FIFO 
doppelt initialisiert!

Andy

[Bascom_Jünger (Gast)]

Hi Andy,
würdest du den funktionierenden Code hier veröffentlichen?

[Malte (malthy)]

Ja, der funktionierende BSACOM-Code würde mich auch interessieren!

Danke!
Malte

[Martin (Gast)]

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

[Gast (Gast)]

Schon gesehen?

USB RF Funkmodul mit ATmega8: 
http://www.ulrichradig.de/home/index.php/avr/usb-funk

[Elektrikser (Gast)]

Joo, war in diesem Thread (am 23.05.) schon da und hat seine Platine 
vorgestellt. Einfach nach oben scrollen... ;-)

Gruß Elektrikser

[Martin (Gast)]

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

[Marius S. (lupin)]

das würde mich ja mal interessieren wiedu das mit der TV Karte testest

[Martin (Gast)]

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

[Jürgen E. (sid)]

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?!

[Claude (Gast)]

@ 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?

[Andreas P. (andyp17)]

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

[Jürgen E. (sid)]

@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

[Martin (Gast)]

Wieso meinst du dass ich mit meiner TV Karte gefährlich lebe?

Hat vielleicht jemand eine Lösung für mein Problem?

mfg
Martin

[Jürgen E. (sid)]

Naja weil du wenn du direkt in deine TV karte rein gehst, sehr leicht zu 
Leistung auf den Eingang legen kannst und ihn dadurch kaput machen 
kannst.

[Martin (Gast)]

Is sowieso ein uraltes Ding und wird ohnehin nicht mehr verwendet.
Reicht aber um festzustellen, ob der Sender funktioniert.

Martin

[R. M. (rmax)]

> 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.

[Martin (Gast)]

Wo du recht hast, hast du recht!*g* War mir der Gefahr nicht bewusst.

Martin

[Ulrich Radig (Gast)]

Hallo,

Habe den RFM12 nun auch über den SPI Bus angeschlossen!
Die Senderoutine habe ich schon getestet.

Gruss
Ulrich

[Jürgen E. (sid)]

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

[Marius S. (lupin)]

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.

[Jürgen E. (sid)]

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

[Ulrich R. (radiguli)]

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

[Ulrich R. (radiguli)]

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

[Horst M. (horst)]

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

[MSchmidt (Gast)]

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?

[Ulrich R. (radiguli)]

Hallo@all,

Hier die komplette Zusammenfassung des SourceCodes.

Gruss
Ulrich

[Jürgen E. (sid)]

@ 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

[Wigbert P. (wigbert)]

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

[Avr N. (avrnix)]

Wigbert: nur ein Gedanke sende doch ein Code, damit er umschaltet

[Wigbert P. (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

[Avr N. (avrnix)]

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.

[Olaf :. (opetersen)]

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?

[Olaf :. (opetersen)]

hab ich ganz vergessen;   kann mir jemand erklären was ich da auf dem 
Oszi sehe?

[Claude (Gast)]

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.

[Kalli (Gast)]

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

[Marius S. (lupin)]

Claude: Versuch doch mal Sound abspielen zu lassen, das wär doch mal was 
:)

[Olaf :. (opetersen)]

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**.

[Kalli (Gast)]

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

[Wigbert P. (wigbert)]

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

[Wigbert P. (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

[Karl-heinz L. (kalli)]

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.

[Andreas P. (andyp17)]

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

[Manuel S. (thymythos)]

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.

[Jürgen E. (sid)]

Ulrich hat das Lbr noch etwas erweiter. (Hardware SPI)
Das sollte auch noch mit rein.

Jürgen

[horcheinstorch (Gast)]

verlinkung vielleicht lieber auf den beitrag, als auf das attachment. 
mit datum ist aussagekräftiger..

[Ulrich R. (radiguli)]

Hallo,

Da ich noch einen Fehler hatte hier der aktuelle Source von mir.

Gruss
Ulrich

[Werner B. (Gast)]

@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

[Ulrich R. (radiguli)]

hallo,

Sollte SPSR &=~(1<<SPI2X) sein.
Da aber das SPSR Register sowieso 0x00 nach dem einschalten ist ist die 
Zeile auch überflüssig.

Gruss
Ulrich

[Wolfgang B. (marvin7)]

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

[Wigbert P. (wigbert)]

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

[Ulrich R. (radiguli)]

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

[Wolfgang B. (marvin7)]

@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

[Wigbert P. (wigbert)]

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

[Lorenz (Gast)]

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.

[Lorenz (Gast)]

@Wigbert:
Mach den Pullup doch einfach im Atmel an. Geht schneller...

[Lorenz .. (lorenz)]

so, jetzt aber

[Lorenz .. (lorenz)]

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.

[Wigbert P. (wigbert)]

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

[Wolfgang B. (marvin7)]

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...)

[Wigbert P. (wigbert)]

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

[Wolfgang B. (marvin7)]

@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!

[Wigbert P. (wigbert)]

Hallo Wolfgang,

>Es lebt, es lebt!

na ja so leicht kann man Leute glücklich machen.

Wir hätten zu gern gewusst warum der m32 nicht "lebt"

Wigbert

[Wolfgang B. (marvin7)]

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

[Lorenz .. (lorenz)]

Hallo, also mein Code läuft auf einem MEGA 32. Keine Ahnung was bei euch 
Probleme macht.

Aber das Pollin-Board ist wirklich nicht sehr durchdacht.

[Horst M. (horst)]

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

[Wigbert P. (wigbert)]

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

[Wigbert P. (wigbert)]

Sorry,

der Pegel ist natürlich in dBµV

Wigbert

[Toemi (Gast)]

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

[Benedikt K. (benedikt)]

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.

[Toemi (Gast)]

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

[Benedikt K. (benedikt)]

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

[Toemi (Gast)]

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

[Benedikt K. (benedikt)]

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.

[Toemi (Gast)]

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

[Joachim B. (jar)]

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 :-)))

[Benedikt K. (benedikt)]

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.

[Joachim B. (jar)]

@ 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. (benedikt)]

Die erste Version ist noch die aktuellste:
http://www.mikrocontroller.net/attachment/22522/rfm01.zip
Mit 4MHz aufwärts sollte das ganze funktionieren.

[Joachim B. (jar)]

@ 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 K. (benedikt)]

Dann machs doch so:
if (RF_PIN&(1<<SDO))
 rx_data();

Oder verwende den Interrupt Pin.

[Werner W. (toemi)]

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

[Benedikt K. (benedikt)]

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.

[Joachim B. (jar)]

@ 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

[Benedikt K. (benedikt)]

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.

[Moritz B. (interuper007)]

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

[Werner W. (toemi)]

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

[Werner W. (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

[Moritz B. (interuper007)]

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

[Werner W. (toemi)]

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

[Moritz B. (interuper007)]

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

[Läubi .. (laeubi)]

Ausgang/Eingangs Regsiter richtig gesezt?

[Moritz B. (interuper007)]

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

[Benedikt K. (benedikt)]

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.

[Johannes (Gast)]

Meine Assembler-Routine zum Senden von Befehlen sieht so aus:

RF12_CMD:        ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17
  cbi PORT_SPI,SEL  ;Chip Select
  ldi r18,16    ;Schleifenzähler für die einzelnen Bits
STloop:  
  cbi PORT_SPI,SCK  ;Clock LO
  clc    ;carry löschen
  sbic PIN_SPI,SDI  ;Bit am SPI Eingang =0?
  sec      ;dann carry setzen, an sonsten gelöscht lassen
  rol r16            ;Carry-Bit hinein schieben
  rol r17
  brcc cl      ;herausgeschobenes Bit =0?
  sbi PORT_SPI,SDO  ;ja, dann SDO auf HI
  rjmp cw      ;und weiter
cl:  
  cbi PORT_SPI,SDO  ;SDO LO
  nop
cw:
  sbi PORT_SPI,SCK  ;Clock HI    
  dec r18
  brne STloop    ;weiter mit Schleife
  cbi PORT_SPI,SCK  ;Clock LO
  sbi PORT_SPI,SEL  ;Chip Deselect
  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.

[Benedikt K. (benedikt)]

@ 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.

[jar (Gast)]

@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 ?

[Joachim B. (jar)]

mist, Login vergessen, nach dem while gehts natürlich weiter

while(RF_PIN&(1<<SDO) && __i<12)
{
     rf01_rxdata((char *)&data[__i], 1);    // 32Bytes empfangen
     if(data[__i]>0)
  __i++;
      }

[Benedikt K. (benedikt)]

Schaltest du den FIFO vorher sauber ein ?

[Joachim B. (jar)]

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
}

[Joachim B. (jar)]

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); ?

[Johannes (Gast)]

@Benedikt K.
Mein Code sieht jetzt folgendermaßen aus:

.equ SDI = 3  ;-----> SDO
.equ SDO = 4  ;-----> SDI
.equ SCK = 5  ;-----> SCK
.equ SEL = 2  ;-----> nSEL
.equ nIRQ = 1  ;-----> nIRQ
.equ PORT_SPI = PORTB
.equ DDR_SPI  = DDRB

sbi PORT_SPI,SEL      ; SEL auf HI -> nicht selektieren
cbi PORT_SPI,SCK      ; SPI Clock LO
sbi DDR_SPI,SDO
sbi DDR_SPI,SCK
sbi DDR_SPI,SEL
cbi DDR_SPI,nIRQ
cbi DDR_SPI,SDI

// initialisieren als Master mit Prescaler 16
ldi r16, (1<<SPE)|(1<<MSTR)|(1<<SPR0)
out SPCR,r16

RF12_CMD:        ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17
  cbi PORT_SPI,SEL  ;Chip Select
//***
  out SPDR,r17    ;Erstes Byte senden
t1:  
  sbis SPSR,SPIF    ;warten bis Transfer zu Ende
  rjmp t1
  in  r17,SPDR    ;Angekommenes Byte wieder in r17  
 //***
  out SPDR,r16    ;Zweites Byte senden
t2:  
  sbis SPSR,SPIF    ;warten bis Transfer zu Ende
  rjmp t2
  in  r16,SPDR    ;Angekommenes Byte wieder in r16  
//***
  sbi PORT_SPI,SEL  ;Chip Deselect        
  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.

[Benedikt K. (benedikt)]

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 ?

[Johannes (Gast)]

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.

[Joachim B. (jar)]

ich glaub aus dem RFM01 FiFo kommt bei meinen Sendern nix mehr 
vernünftiges

ich habe mal den DO/nFFS Pin3 mit Pullup an die Soundkarte gehängt

Power Commander FB piept, China Sender macht FSK, ist aber fürchterlich 
verrauscht und es liegen auch immer periodische Signale drauf, also nur 
ON bei empfang ist leider nicht, mal gucken ob ich da noch eine bessere 
Init finde, vermutlich brauch ich doch eher statt dem atmel einen 
HT604/614
http://www.elv-downloads.de/service/manuals/56628-4Kanal-HF-Schaltsignaluebertr/5662756628-4-Kanal-Schal-032004.pdf
 oder sonst was ?? 
http://sprocket.telab.artic.edu/ed/ATS3203/Ancillary_Components/Radio/HT12D_HT12F.pdf 
?? Dekoder

[Kai F. (kai-)]

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

[Steve B. (stevensen)]

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 (Gast)]

@bennet schaue mal bei www.comwebnet.de vorbei

[Steve B. (stevensen)]

@test
in wie fern soll mir das weiterhelfen?

[test (Gast)]

gucke mal RF12 - da gibts auch ein BASCOM Programm und ein Forum, 
vielleicht kannst du das verwenden für deine Sachen.

[Steve B. (stevensen)]

@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.

[Steve B. (stevensen)]

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?

[Benedikt K. (benedikt)]

Wenn data einen Null terminierten String beinhaltet (oder mit anderen 
Worten: Text), dann einfach _writeString (data);
Oder erwartet _writeString() einen String im Flash ?

[Steve B. (stevensen)]

@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?

[Steve B. (stevensen)]

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?

[Benedikt K. (benedikt)]

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.

[Lorenz .. (lorenz)]

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

[Benedikt K. (benedikt)]

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.

[Jürgen E. (sid)]

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:

unsigned char rf12_txfinished(void)
{
  if(RF12_status.Tx)
    return(255);      //not yet finished
  return(0);
}

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

[Lorenz .. (lorenz)]

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).

usart_write("Start...\n");
      
rf12_txstart(test, 29);
      
while(rf12_txfinished());  // HIER BLEIBT ER HÄNGEN

usart_write("Done\r\n");

[Jürgen E. (sid)]

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

[Lorenz .. (lorenz)]

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.

[Jürgen E. (sid)]

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

[Wigbert P. (wigbert)]

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

[Benedikt K. (benedikt)]

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).

[Christian J. (elektroniker1968)]

Hallo,

anbei ein vollständig getester Code in C für das RFM12 für CCS Compiler 
und PIC Prozessoren.

Gruss,
Christian

[Steffen K. (Gast)]

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

[Benedikt K. (benedikt)]

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.

[Steffen K. (Gast)]

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

[Steffen K. (Gast)]

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

[R. M. (rmax)]

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.

[Steffen K. (Gast)]

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

[Steffen K. (Gast)]

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 :-(

[Steffen K. (Gast)]

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

[Benedikt K. (benedikt)]

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

[Steffen K. (Gast)]

DAS IST ALLERDINGS EINE GUTE FRAGE!
Man sollte nicht mit fieber programieren.
Danke für die files, werde sie gleich mal austesten.

Grüßle

[Steffen K. (Gast)]

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

[Benedikt K. (benedikt)]

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.

[heinzi (Gast)]

hallo zusammen!

das hier dürfte interessant für bascom-user sein:
http://www.roboternetz.de/phpBB2/viewtopic.php?t=30824

zusätzlich hat hier jemand nen CRC check und empfangsroutine für UART in
bascom geschrieben:
http://www.roboternetz.de/phpBB2/viewtopic.php?t=5540

[Timo (Gast)]

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

[Benedikt K. (benedikt)]

Ja, das sollte so funktionieren.

[Timo (Gast)]

Hallo Benedikt,

Vielen dank für die Antwort!

na dann bastelle ich es mir und teste demnächst mal mit deinem code.

Gruss,

Timo

[Michael (Gast)]

Hallo,

wie setzt man die fusebits auf extern für ATMEGA8. Ich benutze Winavr 
entwicklungsumgebung und 10MHZ externe quarz.

Danke im Vorraus!

[Timo (Gast)]

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

[Kai F. (kai-)]

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

[Benedikt K. (benedikt)]

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).

[Wigbert P. (wigbert)]

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

[Benedikt K. (benedikt)]

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 ?

[Wigbert P. (wigbert)]

Pullup hat er nur an FSK, ich übrigens auch.
Bei mir klappt es auch ohne Pullup an nSEL.Vielleicht seltsamerweise.
Sollte man wohl nachrüsten.


Wigbert

[Benedikt K. (benedikt)]

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.

[Wigbert P. (wigbert)]

Solche Fehler machen dann richtig spass.

Dank Dir

Wigbert

[Alex (Gast)]

Hallo,

Wie habt hier die Hyperterminal eingestellt für das Bennedickt programm. 
Irgendwie bekomme empfange ich nichts.

Lg

[Wigbert P. (wigbert)]

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

[Wigbert P. (wigbert)]

Ich noch mal,

weitere Einzelheiten und Diskussion zum o.g.Thema siehe auch

http://www.iphpbb.com/board/ftopic-10138836nx63949-87.html

Wigbert

[Avr N. (avrnix)]

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

[Wigbert P. (wigbert)]

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

'##########################
Sub Sendetext                                               'Aufbereitung des Text="Teststring"
 Sendedata = Rufzeichen                                     'welcher String gebraucht wird
 Laenge = Len(sendedata)
 Lean = Laenge + 3                                          '+ 1
 La = Laenge + 52                                           '50 Bei Empfänger subtrahieren
 Ruf = Chr(la) + Sendedata
 C = Checksum(ruf)
 Text = Ruf + Chr(c)
 Text = Text + " "                                           'Folgestring
'Print Text                                                  'Testprint
'Print L ; Sendedata ; C;
End Sub
'##########################

bitte einfügen

Wigbert

[Wigbert P. (wigbert)]

Hallo,

habe in mein Slavecode ein paar Einstellungen geändert

$hwstack = 40                                               ' default use 32 for the hardware stack
$swstack = 40                                               'default use 10 for the SW stack
$framesize = 40

und im Interrupt die Zeile geändert

 If Empfangslen < Count Then

kennt wohl nur kleiner als.... statt grösser als...

nun sollte der Code durchlaufen

Wigbert

[Manni (Gast)]

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

[Andy (Gast)]

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 (Gast)]

@Trigger Schmitt:
Was soll das?

[Ha Jo (Gast)]

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.

[Andy (Gast)]

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

[Andy (Gast)]

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

[megafreak (Gast)]

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?

[Moritz B. (interuper007)]

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

[Avr N. (avrnix)]

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

[Moritz B. (interuper007)]

Hi,

hast du denn etwas anders gemacht als ich? ich sehe das keine 
unterschiede?
Bekommst du wenn du nur Impulse auf sck gibst denn daten?

Moritz

[Moritz B. (interuper007)]

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

[Benedikt K. (benedikt)]

Zu kurze Pause nach dem Einschalten ?

[megafreak (Gast)]

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?

[Benedikt K. (benedikt)]

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.

[Uwe .. (uwegw)]

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.

[Lorenz (Gast)]

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

[Moritz B. (interuper007)]

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

[Karl-heinz L. (kalli)]

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

[Karl-heinz L. (kalli)]

Quellcode

[Benedikt K. (benedikt)]

Wenn ich das richtig sehe, stellst du nirgends die Frequenzabweichung 
an, die für die FSK verwendet wird.

[Karl-heinz L. (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)?

[Benedikt K. (benedikt)]

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.