Beispielprogramm für RFM12 433MHz Funk-Module

[hans-michael (Gast)]

Hey,
Ich versuche gerade eine den Code von Benedikt für den ADUC831 zu 
schrieben, aber irgendwie wird das nichts.
Ich will die Hardware SPI verwenden, brauch ich da den ganzen Code?

Ich muss nur die Register ändern dann müsste es doch gehen oder?

[Karl-heinz L. (kalli)]

hallo Benedikt
Ich habe jetzt im Empfänger den Code 98D0(H) (FSK=210KHz)und im Sender 
9860(H) (FSK=105KHz) eingestellt. Der Empfänger scheint aber den Sender 
nicht zu "verstehen", denn senden tut das Teil: Wenn ich einen RFM02 als 
Sender zum RFM12 nutze, funktioniert die Verbindung. Schalte ich dann 
zusätzlich einen zweiten RFM12 als Sender ein, stört dieser die 1. 
Verbindung. Wenn ich dann beim diesem RFM12-Sender die Antenne abziehe, 
klappt die 1. Verbindung wieder (die zum RFM02). Da beide Programme die 
selben Initialisierung haben gehe ich davon aus, dass irgend etwas in 
dieser "Preambel" geschichte nicht stimmt

[Karl-heinz L. (kalli)]

Ich habe jetzt testweise in den Empfänger die Patternerkennung 
ausgeschaltet  CA87(H) statt CA83(H) -> Jetzt empfängt das Teil. es ist 
zwar nur Datenschrott, aber es bestärkt mich in der Annahme, das der 
Fehler beim Sender in dieser Sektion steckt

[Karl-heinz L. (kalli)]

Oder ist das für den Enpfänger 9080(H) -> habe ich eingestellt, geht 
auch nicht

[Karl-heinz L. (kalli)]

Noch etwas auffälliges:
Am Ende der Senderoutine schalte ich TX aus mit 0x8208, der Sender 
scheint aber weiter zu senden, da der Empfänger das Signal vom RF02 
immer noch nicht empfängt. Erst wenn ich die Antenne abziehe und damit 
die Sendeleistung reduziere (denke ich), wird der Empfang vom RFM02 
wieder hergestellt.

[Karl-heinz L. (kalli)]

Hi alle,
Warum der Sender nicht abschaltet, habe ich herausgefunden (glaube ich): 
Ich schalte den Sender mit 0x8200 aus, vorher setze ich aber dien 
SEL-Leitung kurz auf High und die CLK -Leitung und auf LOW
  bsf  SEL  ;setze Bit für Selekt-Leitung
  bcf  SCK  ;lösche Bit für Clock -Leitung
  call  warten2 ; warte
  bcf  SEL  ; lösche Bit für Selekt-Leitung
danach nimmt das Modul wieder Steuerbefehle entgegen
Kann das jemand bestätigen, dass das daran liegt?, Muss das auch noch wo 
anders z.B. vor dem Senden der Daten Preambel  Syncwort geschehen?

[Karl-heinz L. (kalli)]

Alle ratlos ???
ich vermute ein Timing-Problem bei meinem Sender, habe auch schon an 
meinen Zeitschleifen rumgeschraubt.... nix
Gibt es noch was spezielles, worauf ich beim Übermitteln der zu 
sendenden Daten achten muss?
Hilfeeeee...

[Benedikt K. (benedikt)]

Hast du schonmal geschaut ob die empfangenen Daten (bei ausgeschalteter 
Syncword Erkennung) irgendwas mit den gesendeten zu tun haben, oder ob 
was komplett anderes empfangen wird ?
Ansonsten ist noch zu beachten, dass die SPI Frequenz nicht mehr als 
2,5MHz betragen darf.

[ReinHerR (Gast)]

Seid 3 Tagen bin ich jetzt dabei und irgendwie will das Moped nicht: 
habe den RFM01 und 02 an jeweils einen ATMega16 angeschlossen. Der 
Sender scheint unentwegt zu senden (hängt sich nicht auf, keine 
Fehlermeldung beim Kompilieren, Signal anm SCK)
Der Empfänger hingegen hängt sich im "rf01_rxdata" in der Zeile "while 
(!(RF_PIN&(1<<SDO))); // wait until data in FIFO" auf.
Interessant dabei ist: wenn ich den SDO abklemme und auf eine LED lege, 
so blinkt diese als ob sie Daten empfangen würden und der Controller 
hängt sich nicht mehr auf (zeigt dafür immer den selben Datenmüll an). 
Lege ich den Pin MIT LED auf den Eingang, so kommt weder Datenmüll noch 
blinkt die LED.
Habe leider kein Oszi, kann also wenig zu dem Signal sagen.
Meine Frage: Ist das Verhalten normal? Sollte ich lieber beim Sender 
oder beim Empfänger nach dem Fehler suchen?

Danke im Voraus
ReinHerR

[Karl-heinz L. (kalli)]

@  ReinHerR
leider kenne ich mich in der Programmierung in C nicht aus, aber um die 
Teile zum Laufen zu bringen, solltest Du eventuell mal die hier 
veröffentlichten Programme nehmen, dann hast Du wenigstens eine 
Grundlage für dein Programm. Ich habe den nFFS-Pin am RFM01 mit 10k auf 
H gezogen, vielleicht da mal nach sehen?

@ benedikt
die 8 angeschlossenen LED's am Ausgang des PIC's flackern unmotiviert 
vor sich hin, mal mehr mal weniger. Da ist nichts gleichmäßiges zu 
erkennen.
SPI: die Programmierung über die SPI-Schnittstelle klappt (denke ich) 
weil ich ja am Anfang der Initialisierung auf 10MHz Clock Out umschalte 
und später dann über die selbe Routine den Sender einschalte und die 
Daten zum Modul schicke. Einziger Unterschied bei den Daten: Ich warte 
am Ende immer auf ein H am SDO, bevor ich die nächsten Daten 
übermittele.

[ReinHerR (Gast)]

...das ist ja das schlimme, ich habe den Code von hier, ausschließlich 
erweitert durch die LCD-Routine, genauso angeschlossen wie beschrieben 
und den 10k-Widerstand habe ich auch eingelötet. Blöde ist natürlich 
dass ich keine Messgeräte habe um zu testen ob überhaupt der Sender 
funzt. 433 Mhz ist a auch nicht gerade mit dem Ohrhörer zu detektieren 
;-) Muss ich wohl mal jemanden mit ´nem Fernseher aufsuchen.

Inzwischen überlege ich ob evtl. die Platine selbst kaputt ist. Pollin 
ist ja nicht unbedingt für gute Qualität berühmt und es sind ja 
schließlich auch Restposten. Aber so recht glauben will ich das auch 
nicht.

Gruß
ReinHerR

[Karl-heinz L. (kalli)]

Also, was ich bis jetzt von Pollin bezogen habe, war alles OK, keine 
def. Ware. Dieser Thread hier ist so lang und da glaube ich nicht, dass 
das Programm für die RFM01/02 noch Fehler hat. Ich würde einfach mal was 
einfaches an einen Port deines Prozessors ranhängen (kein LCD..) 
vielleicht nur mal ne LED ein und ausschalten. Um so mehr Code, desto 
größer die Fehlerwarscheinlichkeit.
KH

[Fabian B. (fabs)]

@Benedikt K.:
ich benutze bisher recht deine einfachen Routinen für die RFM12. Klappt 
top.
Nur dass die Rx-Funktion blockiert bis sie Daten empfängt passt nicht zu 
dem Programm in das sie jetzt integriert werden soll.
Also dachte ich mir: leg den FFIT auf nen PCInt, aktivier den RX mit

  rf12_trans(0x82C8);      // RX on
  rf12_trans(0xCA81);      // set FIFO mode
  rf12_trans(0xCA83);      // enable FIFO

 und warte auf den PCInt. Sobald der kommt les ich dann wie gehabt mit

  for (i=0; i<number; i++)      // number is natürlich definiert 
  {  rf12_ready();
    *data++=rf12_trans(0xB000);
  }

 die Daten aus. Danach wird der Fifo und die Patternerkennung neu 
gestartet und ich warte auf die nächsten Daten.
Leider klappt das nur genau ein mal und danach kommen immer nur noch die 
ersten zwei Byte korrekt, die restlichen 4 zappeln wild.
Aktivier ich den RX aber wie oben beschrieben und starte dann deine 
Rx-Funktion sobald der PCInt kommt sind die Daten immer einwandfrei.
Ich muss also immer die "RX-On Präambel" (die drei Befehle oben) 
schicken direkt bevor ich Daten auslese.
Kann sich das jemand erklären?
Ich meine, es ist nicht schlimm, hat aber ne weile gedauert zum drauf 
kommen und ich verstehs nich. ;-)

Danke und Gruß
Fabian

[Benedikt K. (benedikt)]

Wenn ich das richtig verstehe, startest du die Sync Word Erkennung nach 
jeder Übertragung neu, aber es funktioniert trotzdem nur das 1. mal 
richtig ?
Und sobald der FFIT Pin aktiv ist, liest du das ganze Paket auf einmal 
ein ?

Das klingt so, als wenn rf12_ready(); nicht richtig funktioniert, warum 
auch immer.
Ich habe FFIT invertiert an INT0 gelegt, das funktioniert wunderbar: 
Solange der Pegelgesteuerte Interrupt aktiv ist, sind Daten im 
Empfangspuffer.

[Fabian B. (fabs)]

Exakt.
Das mit der Syncword Erkennung geht ja auch gar nicht anders oder?
Der Sender sendet aktuell sein Datenpaket im Loop immer wieder.

Ich kann auch nochmal ein abgespecktes Codestück anhängen wenn Bedarf 
besteht.

Gruß
Fabian

[Fabian B. (fabs)]

Die "echten" Interrupts waren nimmer frei. darum hängts an nem PCInt und 
der feuert ja bei jedem Pegelwechsel. Darum deaktivert sich der 
Interrupt auch selbst und wird erst wieder nach dem Auslesen aktiviert.

Aber wie ichs drehe und Wende ich komme nicht ohne diese "Präambel aus".

Kannste mir vieleicht mal nen Schnipsel schicken wie du die Daten dann 
im Int ausliest?

Gruß
Fabian

[Benedikt K. (benedikt)]

Schau mal hier:
http://www.mikrocontroller.net/attachment/24996/rfm12_rs232_rxtx_check_int.zip

[Fabian B. (fabs)]

Aso, ja... hatte ich mal reingeschaut, aber nicht genauer, weil mir das 
mit crc usw doch etwas overkill war.
seh aber grad, so schlimm isses ja nich.
Diesen Effekt erklärt es aber nicht wirklich.
Die einzige Idee die mir grad noch kommt: Das Modul ist ein RFM12 V1.0 
von Pollin. Die Anderen (z.b. Aus der Sammelbestellung) sind alle V3.0. 
Vieleicht war das ja auch ein Bug.

Hauptsache es funktioniert jetzt.

Gruß
Fabian

[Thomas (Gast)]

Hallo! Als Ich gut verstanden habe RFM12 gibt's bei euch um ca. 8 Euro 
(Teuronen? :)). Schaut mal an:
http://www.seguro.pl/sklep/?wyszukaj=tak&_szukaj=rfm12#admin/zdjecia/0ccdcc5d8810489d186c959bdada70d6.jpg.
Bei uns sieht das ein bisschen biliger aus. Wenn man eine groessere 
Menge braucht dann koennen sich die Transportkosten lohnen.
Danke fuer die Sourcecode. Gruesse!

[Jürgen A. (jaja)]

Guggst du hier:
Beitrag "Dritte Sammelbestellung RFM12 Funkmodule + Sensoren"

Unter 3 Euro ;-)

Da kann selbst Polen nicht mithalten...

Grüße,
Jürgen

[maddin (Gast)]

Hallo,

ich arbeite mich gerade in das thema ein, und bin etwas überwältigt von 
der vielfalt an informationen die in mehr oder weniger 3 threads hier 
verteilt sind. ich bin jetzt seit 2 tagen dabei mir einen überblick zu 
verschaffen und naja, es ist viel.

mein ziel ist es das rmf12 an einen at90can128 anzuschließen.

als grundlage habe ich den code von benedikt (weiter oben 
rfm12_rs232_rxtx_check_int.zip ) angenommen.

jetzt gibt es knapp 10 weitere ausführungen dieses oder eines ähnlichen 
codes in diesem thread:
Beitrag "bidirektionale RS232 Funkbrücke mit RFM12"

mein ziel ist eine bidirektionale verbindung zwischen 2 modulen mit 
einer ü rate von 19200baud. und später mal eine 1 zu n übertragung.

@benedikt:

ich habe die sourcen des (rfm12_rs232_rxtx_check_int.zip (hier)) soweit 
an meinen controller angepasst.

wenn ich richtig sehe, verwendest du in programm:

1) die sourcen von Peter Fleury
2) einen softwareuart

ich habe die sourcen an den at90can128 soweit angepasst, dennoch sind 
fragen offen.

-zum schaltplan, warum verwendest du den fet bs170 in deiner schaltung, 
hat der atmega8 keine flankeneinstellungen oder was war der grund?
-ist die grundlage gut für mein vorhaben, oder gibt es hier einen 
passenderen code?

ich frage mich natürlich immer noch, ob der code zum kennenlernen gut 
geiegnet ist, oder ob ich doch den ersten hier geposteten code nehmen 
sollte:
doch dabei ist mir aufgefallen das die c datei dort rf12 heißt, der code 
ist doch aber für das modul rfm12, oder!?

-gilt der schaltplan in: rfm12_rs232_rxtx_check_int.zip  auch für 
rfm12.zip (2,3 KB, 1976 Downloads)

@All:

ihr steckt hier schon länger drin, und ich erst seit 2 tagen und ich 
muss jetzt einfach einp aar fragen stellen, bevor ich hier völlig den 
verstand verliere, bei der menge datenblätter, codeschnipsel, hinweise 
und schaltpläne.

es wurde ja schon mit einer übersicht begonnen:
https://www.mikrocontroller.net/attachment/24947/RFM12.txt
http://www.mikrocontroller.net/articles/RFM12

was auch wirklich schon etwas hilft.

ich habe das transceiver modul von pollin RFM12, zumindest hoffe ich das 
pollin nicht auch da noch unterschiedliche verkauft hat, es scheint ja 
noch weitere zu geben:
RF12 (sieht aber anders aus als meins)
RFM12BP (ebenfalls)

RFM12B  (ähnlich)

allerdings war bei dem pollin modul das datenblatt zum RFM12 dabei, 
deswegen gehe ich mal davon aus, das es das dann auch ist.

zu dem von pollin beigefügten code gab es damals die aussage das er 
fehler enthält.

ich hoffe ich bin auf dem richtigen weg.

dank an euch,

m.

[Benedikt K. (benedikt)]

maddin wrote:

> wenn ich richtig sehe, verwendest du in programm:
>
> 1) die sourcen von Peter Fleury

Ja

> 2) einen softwareuart

Nein.

> -zum schaltplan, warum verwendest du den fet bs170 in deiner schaltung,
> hat der atmega8 keine flankeneinstellungen oder was war der grund?

Der pegelgetriggerte Interrupt ist nur Low aktiv, der RF12 gibt aber 
einen Highpegel aus, solange Daten im Puffer sind.

> -ist die grundlage gut für mein vorhaben, oder gibt es hier einen
> passenderen code?

Der Unterschied zwischen den Versionen ist, dass die oberste alles per 
Software macht, während die neueren die SPI Schnittstelle und Interrupts 
verwenden.

> doch dabei ist mir aufgefallen das die c datei dort rf12 heißt, der code
> ist doch aber für das modul rfm12, oder!?

Das IC heißt RF12, das Modul RFM12.

> -gilt der schaltplan in: rfm12_rs232_rxtx_check_int.zip  auch für
> rfm12.zip (2,3 KB, 1976 Downloads)

Nein

> RF12 (sieht aber anders aus als meins)

Das ist nur das IC, das hast du ganz sicher nicht.

> RFM12BP (ebenfalls)

Das ist in Deutschland nicht zulässig

> RFM12B  (ähnlich)

Das müsste einen anderen Anschluss haben (Stiftleisten statt SMD). Das 
von Pollin verkaufte heißt korrekt glaube ich RFM12-433S1 oder so 
ähnlich.
Von der Software her sind aber alle gleich.

[maddin (Gast)]

@benedikt,


vielen dank für die schnelle antwort.

zählt rfm12_rs232_rxtx_check_int.zip auch zu den neuen, wie auch die im 
beitrag funkbrücke!?

in dem angehängten code aus dem beitrag:

bidirektionale RS232 Funkbrücke mit RFM12

sind ebenfalls schaltpläne, dort ohne bs170, dennoch mit atmega8. liegt 
dies daran das dort noch gepollt wird?

der code stammt aus einem thread bereich indem du ebenfalls eine 
funkstrecke mit 19200 baud aufbaust.

ich will in erster linie die module kennen lernen ist der link

https://www.mikrocontroller.net/attachment/24947/RFM12.txt


eine gute zusammenfassung.

welche software würdest du mir als grundlage empfehlen, oder ist 
rfm12_rs232_rxtx_check_int.zip gut!? er lässt sich jedenfalls schon sehr 
gut portieren.

ich frage nur, da ich mich sonst noch durch atmega8 datenblätter, durch 
das gesamte vorgehen von dir im beitrag funkbrücke kämmen müsste.

welcher schaltplan passt zu rfm12.zip hier?

vielen dank, bis hier hin,

m.

[maddin (Gast)]

übrigens, das ist die ansammlung an infos aus diesem forum hier.

wenn man nicht aufpasst dann rutscht man ganz schnell ins chaos ab :-)

m.

[Benedikt K. (benedikt)]

Ich würde mit dem hier anfangen:
Das sind Sender + Empfänger die beide ganz sicher funktionieren.
http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip

[maddin (Gast)]

hallo benedikt,

ich welchem thread liegt dieser code?

gibts dazu einen schaltplan, leider muss ich den code portieren und 
dazu auch einen passenden verdrahtungsansatz wählen.´

wird dort gepollt, oder ist es interruptgesteuert?

wird spi genutzt?

wie gesagt, der code aus rfm12_rs232_rxtx_check_int.zip ist ja schon 
fast gänzlich portiert.

gruß,
m.

[Benedikt K. (benedikt)]

maddin wrote:

> ich welchem thread liegt dieser code?

Hier:
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"

> gibts dazu einen schaltplan, leider muss ich den code portieren und
> dazu auch einen passenden verdrahtungsansatz wählen.´

Nein, denn die Pins lassen sich in der rf12.c beliebig umbelegen.

> wird dort gepollt, oder ist es interruptgesteuert?

Nur gepollt, der Code ist daher weitestgehend µC unabhängig.

> wird spi genutzt?

Nein.

> wie gesagt, der code aus rfm12_rs232_rxtx_check_int.zip ist ja schon
> fast gänzlich portiert.

Den kannst du auch nehmen, aber eigentlich gibt es da ja nicht viel zum 
Portieren. Die Ports anpassen, und fertig.

[maddin (Gast)]

@benedikt,

>>Den kannst du auch nehmen, aber eigentlich gibt es da ja nicht viel zum
Portieren. Die Ports anpassen, und fertig.<<

so war es auch, nur im global int reg, und hier und da ein wenig (uart) 
usw..

dann bleiben eigentlich nur noch 3 fragen, bevor ich starten kann.

1) wird hier 
http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip

der FFIT PIN auch invertiert genutzt?

2) wird das CTS Handschaking signal bei deinem programm genutzt, muss es 
also "mitgeroutet" werden!?

3) in den meisten aplikationen wird der mikrocontroller vom RFM12 
gesteuert, bei den boards die ich einsetze, ist bereits ein 16Mhz quarz 
vorhanden, kann das zu problemen führen, muss ich das 10mhz sig. des 
rfm12 nutzen (synchronisation, timings) oder KANN ich es nutzen, und 
reicht es F_CPU anzupassen?

bis dahin, vielen dank für die Schnelle reaktion an dich.

gruß,
m.

[Benedikt K. (benedikt)]

maddin wrote:

> 1) wird hier
> http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip
>
> der FFIT PIN auch invertiert genutzt?

Nein, hier der Pin garnicht verwendet.

> 2) wird das CTS Handschaking signal bei deinem programm genutzt, muss es
> also "mitgeroutet" werden!?

Es wird nicht verwendet.

> 3) in den meisten aplikationen wird der mikrocontroller vom RFM12
> gesteuert, bei den boards die ich einsetze, ist bereits ein 16Mhz quarz
> vorhanden, kann das zu problemen führen, muss ich das 10mhz sig. des
> rfm12 nutzen (synchronisation, timings) oder KANN ich es nutzen, und
> reicht es F_CPU anzupassen?

Es reicht die Frequenz anzupassen. Bei der SPI Version muss die SPI 
Frequenz eventuell langsamer gestellt werden, da diese nicht schneller 
als 2,5MHz sein darf.

[maddin (Gast)]

Hallo Benedikt,

>>Nein, hier der Pin garnicht verwendet<<

ählich wie hier?

Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module"

rfm12schaltplan.tif

im gegensatz zu deinem schaltplan (mit FFIT) wird hier dann NIRQ für die 
Rückmeldung genutzt!?

in dem sw paket rfm12_rs232_rxtx_check3__6.zip ist keiner der beiden 
pins genutzt?

m.

[Benedikt K. (benedikt)]

maddin wrote:
> im gegensatz zu deinem schaltplan (mit FFIT) wird hier dann NIRQ für die
> Rückmeldung genutzt!?

Das geht auch, man spart sich den Inverter, allerdings geht NIRQ bei 
allen möglichen Sachen auf Low. Dann muss man erst suchen, was die 
Ursache dafür war.

> in dem sw paket rfm12_rs232_rxtx_check3__6.zip ist keiner der beiden
> pins genutzt?

Da wird gepollt.

[maddin (Gast)]

alles klar.

wie ich gerade noch sehe, in den datenblättern des pollin moduls sind 
erhebliche unterschiede:

im anhang

m.

[maddin (Gast)]

einmal werden die timings beschrieben udn einmal die einzelnen 
regeister.

ich hoffe ich kann es uploaden...das ist nur das ende, ab seite 6.

m.

[maddin (Gast)]

Hallo Benedikt,

ich habe den aubau der funkmodule samt antenne, die "einarbeitung" ins 
studio sowie das aufstellen einer "teststrecke" für eine bidirektionale 
datenü. am samstag soweit durch bekommen.

heute sitze ich noch an der "portierung deines codes"

die pins sind angepasst,
die interrupt register.
der kram lässt sich fehlerfrei kompilieren und flashen.

der 500hz trigger kommt.
cs kommt.

dennoch musste ich eh auch im datenblatt des atmega8 kramen.
hier bin ich noch über:

MCUCR gestolpert.

ISC11 ISC10 Description
0 0 The low level of INT1 generates an interrupt request.
0 1 Any logical change on INT1 generates an interrupt request.
1 0 The falling edge of INT1 generates an interrupt request.
1 1 The rising edge of INT1 generates an interrupt request.

mich wundert nach wie vor deine invertierung, oder habe ich da noch ein 
falsches datenblatt erwischt, kenne die atmels sonst noch nicht.

spi clock muss noch überprüft werden (<2,5Mhz) irgentwas stimmt da noch 
nicht ganz.

bis hier hin, erstmal vielen dank für die Unterstützung,

m.

[Benedikt K. (benedikt)]

maddin wrote:
> ISC11 ISC10 Description
> 0 0 The low level of INT1 generates an interrupt request.
> 0 1 Any logical change on INT1 generates an interrupt request.
> 1 0 The falling edge of INT1 generates an interrupt request.
> 1 1 The rising edge of INT1 generates an interrupt request.
>
> mich wundert nach wie vor deine invertierung, oder habe ich da noch ein
> falsches datenblatt erwischt, kenne die atmels sonst noch nicht.

FFIT ist solange high, wie Daten im Puffer sind. Ich benötige also einen 
Intterupt, der solange gestartet wird, wie ein Pin high ist.

[Hagen R. (hagen)]

Warum? In der ISR liest du 1 Byte Daten aus und dann überprüfst du FFIT 
ob er noch High ist, wenn ja liest du das nächste Byte in der gleichen 
ISR. Defakto also eine Schleife in der ISR die solange Bytes liest bis 
FFIT auf LOW geht.

Gruß Hagen

[Benedikt K. (benedikt)]

Anfangs hatte ich das so. Aber es wurde nur jedes 2.Byte gelesen. Keine 
Ahnung warum.

[maddin (Gast)]

...ich verstehe den grund immer noch nicht, aber ich werde es erstmal 
selbst versuchen, ich bin ja froh für die unterstützung.

Interrupt = Unterbrechungsanforderung

ausgelöst durch ein ereignis (flanke).

...oder habe ich etwas übersehen?

werde die tage abends an meinem code weiterarbeiten, und mal sehen das 
ich die funkmodule angesteuert bekomme, viel kann es nicht mehr sein - 
hoffe ich ._)

m.

[Fabs (Gast)]

Ein Interrupt kann halt auch duch einen Level ausgelöst werden... das 
ist z.B. nötig, wenn der uC im DeepSleep ist, wo der Takt abgeschaltet 
ist. Flanken kann man nur mit Takt erkennen!

Ich mach das mit dem FFIT übrigens genauso wie HagenRe. Funktioniert 
wunderbar.

Gruß
Fabian

[maddin (Gast)]

Hallo,

hier ein Bild meiner Teststrecke.

m.

[maddin (Gast)]

...hier noch ein Bild und Hinweis für Lochraster Testaufbauten...

das modul hat ja bekanntlich ein 2mm Raster.

es besteht trotzdem die möglichkeit es auf lochraster zu setzen,

wenn man die Pins wie folgt abwinkelt:

O O | | O |
O O | | O |


O= Pin
|= abgewinkelt und mit Kupferlackdraht durchgeführt

man benötigt natürlich Pinleiste und Federleiste.

gruß,
m.

[Simon K. (simon)]

Hallo,

Kann mir jemand die rot markierten Angaben einmal abmessen und 
mitteilen? Dankesehr!

[Thomas F. (thomas-hn)]

1 ~ 1.0mm
2 ~ 1.1mm

Ich habe das gerade nur mit einem Geodreieck ausgemessen, da ich nichts 
genaueres zur Hand hatte.

[Simon K. (simon)]

Sicher?

Ich gehe jetzt mal nicht davon aus, dass die Zeichnung maßstaßsgetreu 
ist, aber 2 sieht doppelt so lang aus wie 1.

Oder sieht das nur so aus?

Aber danke trotzdem :-)

[Fabian B. (fabs)]

Hab grad nochmal mit dem Meßschieber nachgemessen: die angaben von 
Thomas kommen auf ca 0.1mm hin.
Ich hatte für 1) ca 0.9mm, für 2) ca 1,05mm

Gruß
Fabian

[Simon K. (simon)]

Ich danke euch beiden! :-)

[Julian Krick (Gast)]

Hallo,
ich versuche gerade ein RFM02-Modul zum Laufen bekommen, bin allerdings 
schon daran gescheitert, wie ich es anschließen soll.
Klar hab ich mir die Pinbelegung (auch das Datenblatt des ICs und alle 
Befehle, etc.) angeschaut, aber da die Anwendung, die ich realisieren 
möchte, etwas zeitkritisch ist, hatte ich gehofft, das RFM02 mit der SPI 
eines ATmega8515 ansteuern zu können, anstatt die Schnittstelle selber 
zu implementieren, wie das hier bei den Beispielprogrammen war.

Aber es sind einfach zu viele Sachen unklar, als dass ich gescheit was 
planen könnte.
Verstehe ich das richtig, dass über den nIRQ-Pin beim Senden der Daten 
ein Takt (Baudrate) kommt, außerdem noch die Interrupts und man kann 
auch noch das Statusregister auslesen?
Bloß ist das Statusregister nirgendwo dokumentiert, was bringt mir das 
dann? Außerdem steht im Datenblatt des RF02 was von asynchroner 
Übertragung am FSK-Pin.
Und bei dem "Data Transmit"-Befehl wird in dem Beispieldiagramm für ein 
Senden via FSK eben nicht der "Data Transmit"-Befehl gesendet, sondern 
"Power Management". So nach dem Motto: Hier kommt noch irgendein Befehl 
und wenn du was auf dem FSK-Pin sendest, merkt der Chip das von selber. 
Aber das kann doch nicht sein, schließlich gibt es kein Start-Bit oder 
so. Außerdem, wenn das mit dem Takt über nIRQ stimmt, woher weiß der 
RF02 dann, dass er mit dem Takt starten soll.

Ich hatte mir das jetzt so gedacht: Ich verbinde MOSI mit SDI und MISO 
mit FSK, dann könnte ich die Befehle im Master-Mode senden und das 
Clock-Signal erzeugen, für die Daten auf Slave umschalten und dann den 
nIRQ an den Clock-Pin hängen. Geht das, oder reicht das Signal am nIRQ 
nicht aus für ne saubere Clock? Könnte man das vielleicht 
nachbearbeiten, mit nem Monoflop z.B.?

Dann hab ich immer noch keinen blassen Schimmer, was ich mit den 
Interrupts machen soll, aber ich wäre schonmal glücklich, wenn überhaupt 
was funktionieren würde.

Oder gibt es noch ne bessere Möglichkeit mit der SPI? Ich werde hier 
langsam verrückt, ich suche schon seit Stunden und NIRGENDWO gibt es die 
Infos, die ich suche.
Wäre sehr dankbar für Hilfe!

[Benedikt K. (benedikt)]

Julian Krick wrote:
> Verstehe ich das richtig, dass über den nIRQ-Pin beim Senden der Daten
> ein Takt (Baudrate) kommt, außerdem noch die Interrupts und man kann
> auch noch das Statusregister auslesen?

Ja, so in etwa. Der Takt kommt aber nur, wenn dieser aktiviert wird.

> Bloß ist das Statusregister nirgendwo dokumentiert, was bringt mir das
> dann? Außerdem steht im Datenblatt des RF02 was von asynchroner
> Übertragung am FSK-Pin.

Es gibt mehrere Möglichkeiten:
- Das Modul kann als dummes FSK Modul arbeiten, d.h. die Daten am FSK 
Pin werden direkt gesendet.
- Man kann die Daten über den SDI Pin senden, das sollte dann synchron 
zur Baudrate ablaufen.

> Und bei dem "Data Transmit"-Befehl wird in dem Beispieldiagramm für ein
> Senden via FSK eben nicht der "Data Transmit"-Befehl gesendet, sondern
> "Power Management". So nach dem Motto: Hier kommt noch irgendein Befehl
> und wenn du was auf dem FSK-Pin sendest, merkt der Chip das von selber.

Bei diesem Modus muss man den Sender einschalten, danach sendet er dumm 
was am FSK Pin anliegt.
Im anderen schaltet sich der Sender selbst ein.

> Ich hatte mir das jetzt so gedacht: Ich verbinde MOSI mit SDI und MISO
> mit FSK, dann könnte ich die Befehle im Master-Mode senden und das
> Clock-Signal erzeugen, für die Daten auf Slave umschalten und dann den
> nIRQ an den Clock-Pin hängen.

Sollte eigentlich funktionieren (auch wenn ich es noch nicht ausprobiert 
habe.)

[Julian Krick (Gast)]

Hallo Benedikt, danke erstmal für die Antwort.

Verstehe ich das richtig, dass der Sender, wenn ich ihn per 
Power-Management-Befehl aktiviert habe, dann die ganze Zeit sendet, was 
an FSK anliegt? Also auch, wenn ich gar nichts dort hin sende?
Also selbstverständlich nur, wenn ich ihn in dem entsprechenden Modus 
betreibe.

Wenn ich den nIRQ-Pin als Clock für die SPI nehme, dann muss ich doch 
verhindern, dass auch wirklich Interrupts darüber kommen. Wie kann ich 
das denn abstellen? Ich hab im Datenblatt keinen Befehl gefunden, um zu 
kontrollieren, ob Interrupts gesendet werden oder nicht. Geht das 
überhaupt?

Ich bin mir noch nicht sicher, was ich machen möchte, also ob Daten über 
FSK oder über SDI. SDI erscheint mir praktischer, allerdings habe ich 
keinen Schimmer, wie ich das SPI-Interface auf die Baudrate takten soll.
Es stimmt doch, dass ich, wenn ich die Daten über SDI sende, sie 
ebenfalls mit der eingestellten Baudrate senden muss, schließlich fällt 
das Clocksignal weg.


Ich verstehe nicht, warum die diese Dinger bauen und dann nicht gescheit 
dokumentieren. grrrr

[Karl-heinz L. (kalli)]

Hallo benedikt, hallo fabs
ich habe gas gleiche Problem wie weiter oben schon von fabs erwähnt, 
dass nach dem 2. Datenbyte nur noch Datenmüll am Empfänger ankommt. Ich 
habe festgestellt, dass die Bits beim 3. Byte versetzt ankommen (1.Bit 
an Position3 ...). Ich meine, ich lese den FIFO zu früh / zu schnell 
aus. Wie habt ihr das gelöst? Der nIRQ-Pin ist bei mir immer L . Muss 
ich den erst aktivieren (und wie)?

[Fabian B. (fabs)]

nimm nicht den nIRQ, der Signalisiert viele Dinge. nimm den FFIT, der 
signalisiert sobald der FIFO mehr als die eingestellten Bits enthält.

Bei mir hat sich das inzwischen erledigt...

ich mach das so (etwas abgespeckt):

ISR( PCINT0_vect ) {
  go = 1;
  PCMSK0 &= ~(1 << PCINT0);
  PCIFR = 0xFF;
}


void rf12_rxdata2(unsigned char *data, unsigned char number)
{  unsigned char i;
  for (i=0, y=0; i<number; i++, y++)
  {  rf12_ready();
    *data++=rf12_trans(0xB000);
  }
  rf12_trans(0x8208);      // RX off
}

void main() {
// Empfänger anschalten
rf12_trans(0x82C8);      // RX on
  rf12_trans(0xCA81);      // set FIFO mode
  rf12_trans(0xCA83);      // enable FIFO

while( 1 ) {

  if(go) {          // Daten zum Empfangen vorhanden!
    rf12_rxdata2((unsigned char*)rxbuffer,6);  // Daten abholen
    rf12_trans(0x82C8);      // RX on
    rf12_trans(0xCA81);      // set FIFO mode
    rf12_trans(0xCA83);  
    go = 0;
    PCIFR = 0xFF;            // PC-INT Flag löschen
    PCMSK0 = (1 << PCINT0);  // PC-INT reaktivieren

        }
}}

go wird hierbei in einem PinChange interrupt gesetzt sobald sich am FFIT 
was tut.
Es is übrigens wichtig, dass sich der PC-INT direkt erstmal selbst 
deaktiviert und sein Flag vor dem reaktivieren auch nochmal gelöscht 
wird!!

Gruß
Fabian

[Karl-heinz L. (kalli)]

vielen Dank für die schnelle Antwort.
Der Tipp mit dem FFIT war schon mal genial. Trotzdem kommt der Empfänger 
aus dem Tritt. Wenn ich mir die Signale oszilloskopiere sehe ich, dass 
nach dem 4. H-Signal am FFIT (ich sende insgesamt nur 4 Bytes) kein 
stehendes Signal am SDO anliegt. ABER: Der Fehler ist weg, wenn ich 
zusätzlich zu meinen 4 Nutz-Bytes noch 2 "Dummy"-Bytes sende, die ich im 
Empfänger aber nicht auslese.
Leide verstehe ich kein C, ich mach das in Assembler auf einem PIC. 
Deshalb noch mal eine Frage zum Empfänger: Nach jedem Byte das ich 
0xB0xx auslese muss ich die SEL-Leitung einmal kurz auf H legen, sonst 
klappt die Verbindung auch nicht. ist das in euren C- Programmen auch 
so?

[Benedikt K. (benedikt)]

Karl-heinz Lachmund wrote:

> ABER: Der Fehler ist weg, wenn ich
> zusätzlich zu meinen 4 Nutz-Bytes noch 2 "Dummy"-Bytes sende, die ich im
> Empfänger aber nicht auslese.

Du denkst beim Sender daran, dass dieser ein 16bit Sende FIFO hat ?

> Leide verstehe ich kein C, ich mach das in Assembler auf einem PIC.
> Deshalb noch mal eine Frage zum Empfänger: Nach jedem Byte das ich
> 0xB0xx auslese muss ich die SEL-Leitung einmal kurz auf H legen, sonst
> klappt die Verbindung auch nicht. ist das in euren C- Programmen auch
> so?

Ja, steht ja auch so im Datenblatt, dass man nur 8bit lesen kann.

[Karl-heinz L. (kalli)]

> Du denkst beim Sender daran, dass dieser ein 16bit Sende FIFO hat ?

Nach 3*Preambel und 2 Sync-Bytes schicke ich meine 6 Datenbyts zum Modul 
(0xB8xx). Nach jedem dieser 11 Bytes warte ich auf ein H am DSO. Ist das 
falsch?

[Benedikt K. (benedikt)]

Karl-heinz Lachmund wrote:
> Nach jedem dieser 11 Bytes warte ich auf ein H am DSO. Ist das
> falsch?

Ja, wenn du danach keine Dummybytes mehr sendest.
Danach ist mindestens noch 1 ungesendetes Byte im FIFO, das verloren 
geht wenn du sofort abschaltest.

[Karl-heinz L. (kalli)]

OK, wieder ein Stückchen schlauer :-)
Mich störts, wenn man nach langem rumprobieren was zum laufen bekommt, 
aber nicht genau weiß, warum das jetzt so muss.
Vielen Dank

[Fabian B. (fabs)]

Hi.
Da ich jetzt eine Batteriebetriebene Anwendung (Fernbedienung) mit dem 
RFM12 habe muß ich natürlich am Strom etwas knapsen.
Im DB des RF12 steht ja was von StandbyCurrent 0.1uA. Leider finde ich 
nirgends eine Angabe, wie ich das Modul in diesen Standby Modus setze. 
Reicht es den TX abzuschalten (RX ist eh aus)? Oder muß ich zusätzlich 
noch den WakeupTimer nutzen? Spart es dann noch Strom wenn ich nicht den 
CLK-Output vom Modul nutze und ihn deaktiviere?
Richtig abschalten (über Transistor) ist nicht wirklich praktikabel, da 
das Modul ja min 100ms zum starten braucht und der Benutzer wohl kaum 
100ms Delay auf einen Tastendruck toleriert.
Wie kann man das Teil noch am Strom fressen hindern? Wie gesagt, ich 
will nur ab und zu was senden wenn auf der Fernbedienung eine Taste 
gedrückt wird.

Gruß
Fabian

[Benedikt K. (benedikt)]

Schalte alles aus, was du nicht brauchst, auch den Crystal Oscillator. 
Dann sollte die Stromaufnahme in der Nähe des Datenblattwertes sein. Die 
Zeit bis das Modul danach wieder bereit ist, beträgt etwa 10ms.

[Fabian B. (fabs)]

also beim "booten" ganz normal

  rf12_init();          // ein paar Register setzen
  rf12_setfreq(RF12FREQ(433.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
  rf12_setbandwidth(4, 1, 4);    // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf12_setbaud(19200);      // 19200 baud
  rf12_setpower(7, 6);      // 1mW Ausgangangsleistung, 120kHz Frequenzshift

und danach is Power Management Register 0x8201 schreiben... also alles 
aus.

Den WakeupTimer braucht man dafür also nicht?

Gruß
Fabian

[Björn B. (elmo)]

Fabian B. wrote:
> und danach is Power Management Register 0x8201 schreiben... also alles
> aus.
>
> Den WakeupTimer braucht man dafür also nicht?
>
> Gruß
> Fabian

Hallo Fabian,

richtig, dafür brauchst du den WakeupTimer nicht, du kannst das Modul 
einfach über die SPI Schnittstelle wieder einschalten. Allerdings 
verbraucht dein Mikrocontroller dann immer noch relativ viel Strom. Du 
könntest ihn natürlich auch schlafen legen. Um ihn dann wieder 
aufzuwecken würde sich theoretisch der WakeupTimer eignen, da nach 
Ablauf der eingestellten Zeit das Modul einen Interrupt wirft. Leider 
bin ich dabei auf große Probleme mit dem Modul bezüglich 
Langzeitstabilität gestoßen. Hier habe ich das Ganze beschrieben und 
auch eine andere Möglichkeit zum Stromsparen aufgezeigt. 
Beitrag "Re: RFM12: Erfahrungen"
Das funktioniert jetzt seit einigen Wochen richtig gut.

Gruß
Björn

[Fabian B. (fabs)]

Den uC will ich übern Interrupt wecken... der kommt aber nicht vom 
RFM12, ist als nicht das Problem.
Aber danke, den Thread werd ich mal lesen.

Gruß
Fabian

[Richard B. (Gast)]

Hallo,

habe mir auch 4 RFM12-Module gekauft. Gibt es irgendwo einen Finalen 
Code und Schema? Der Thread ist groß um ihm ganz durch zu lesen.

Und wie oder mit was kann ich die Antenne machen? Das Modul soll in eine 
Art Fernbedingung rein. Darf also nicht eine Lange antenne oder Kabel 
sein.


Danke

[bobkins (Gast)]

Hi!
Als Antenne eignet sich im einfachsten Falle eine Drahtantenne. Je nach 
Frequenz sollte sie 15cm (433 Mhz) oder 8,7cm (868 MHz) sein. Mehr dazu 
findest du im Thread, oder an anderer Stelle hier im Forum. Einfach mal 
nach "Antenne".

gruß bobkins

[Fabian B. (fabs)]

Ich nehm immer 16cm Draht und wickel den um nen Bleistift... ist 
Leistungstechnisch sicher nicht optimal aber reicht für indoor dicke. 
Und es ist nicht so groß. Du kannst, wenns dir nicht um maximale 
Reichweite geht aber die ca 16cm Draht auch einfach "irgendwie" in die 
FB "reinstopfen".

Es gibt ja verschiedene Codes je nach Anwendung. Ich benutze Code auf 
der Basis von Benedikts RFM12_RX_TX_beispiel.zip.

Gruß
Fabian

[Fabian B. (fabs)]

Ich hätt da nochmal ne Frage an die Profis:
ich hab jetzt meine Fernbedienung ohne das RFM12 bis auf <10uA 
Stromverbrauch runter gebracht... aber das RFM12 braucht selbst wenn ich 
alles (Osz., Clock out, Baseband) abschalte immernoch rund 300-350uA. 
Das ist ja schon etwas weit weg von den 0.3uA die im Datenblatt 
angegeben sind.
Ich hab auch schon den PullUp an FSK so groß wie ging gemacht (ca 100K), 
der frisst zwar auch noch was aber das Gro macht das Board selbst.

Mehr abschalten kann ich ja wohl kaum?!

Ich will ungern dem Modul vollständig den Saft abdrehen...hat jemand 
noch ne Idee?

Gruß
Fabian

[Benedikt K. (benedikt)]

Sind alle Eingänge auf einem definierten Pegel ? Battery Low detector 
aus ?

[Fabian B. (fabs)]

Alle Eingänge des Moduls sind auf einem definierten Pegel:
nRes wird vom uC auf High gehalten (über Pullup) (ist Strommäßig aber 
egal)
FSK liegt direkt über 100k an VCC (mehr geht nicht sonst wird die 
Funktion des Moduls zufällig)

SDI, nSel und SCK werden durch den uC aktiv getrieben.

ins Power Management Register schreibe ich 0x8201, also im Prinzip 
"alles aus".

Hast du mal bei dir gemessen, wie weit du mit dem Stromverbrauch des 
Moduls "runter kommst"? Ich bin ja immerhin noch 3 Größenordnungen vom 
angegebenen entfernt...andererseits sind die 0.3uA auch direkt aus dem 
Chip-DB übernommen...auf dem Modul is ja noch ein bissi was drauf, 
vieleicht gehts einfach nicht besser...

Gruß
Fabian

[Richard B. (Gast)]

Gibt es Antennen Draht auch bei Reichelt?

[Fabian B. (fabs)]

@ Richard B.: Nimm irgendeinen Draht. Ich nehm hier Schaltdraht 0,2qmm.

Mal noch ne Frage zum Stromverbrauch:
Ich hab langsam den Verdacht, daß nicht das RFM12 der "Verbraucher" 
meiner gesuchten 300uA ist sondern die Verkabelung selbst. Es ist mein 
erstes so verbrauchssensibles Projekt von daher fehlt mir da etwas das 
Gefühl, aber ich hätte eigentlich nicht gedacht, daß ich scheinbar auf 
einer gefädelten Lochrasterplatine so hohe Leckströme haben kann. Ist 
das möglich?
Die <10uA ohne RFM12, von denen ich oben schrieb, waren wohl ne 
Fehlmessung :(.
Muß ich wohl doch mal wieder ne Platine backen und mal dann probieren.

Ärgerlich finde ich aber, daß das JTAG-ICE2 knapp 700uA aus der 
Schaltung zieht...das macht das Messen etwas umständlich.

Gruß
Fabian

[Simon K. (simon)]

Fabian B. wrote:
> Ärgerlich finde ich aber, daß das JTAG-ICE2 knapp 700uA aus der
> Schaltung zieht...das macht das Messen etwas umständlich.

Der interne Pegelwandler will auch versorgt werden...

[Richard B. (Gast)]

Kann man das Modul von Pollin auch mit einem AVR benutzen? Hat das einer 
Versucht?

Sensor-Funkübertragung
http://www.pollin.de/shop/detail.php?pg=NQ==&a=MjE0OTQ0OTk=

[R. M. (rmax)]

Richard B. wrote:
> Kann man das Modul von Pollin auch mit einem AVR benutzen?
> Hat das einer Versucht?
>
> Sensor-Funkübertragung
> http://www.pollin.de/shop/detail.php?pg=NQ==&a=MjE0OTQ0OTk=

Klar kann man das auch an einen AVR hängen, aber es übermittelt halt 
keinen Datenstrom, sondern nur den Zustand eines einzigen Schalters.

Das ist ein völlig anderes Modul als die, um die es in diesem Thread 
geht. Mach dafür bitte einen neuen Thread auf, falls es weitere Fragen 
dazu gibt.

[motormons (Gast)]

Hallo

habe paar RFM12-868 Module gekauft, code von Benedikt genommen 
(Software-SPI), und etwas angepasst (lediglich Sendefrequenz).
Habe aber ein Problem: der Sender wird zwar richtig initialisiert (10MHz 
am CLK, rauschtöne beim senden), beim senden hängt er in der 
rf12_ready() in dieser Schleife:

while (!(RF_PIN&(1<<SDO)));

Habe schon lange drum gefummelt, kriege es leider nicht geregelt. Wenn 
ich z.B. in diese Schleife lösche, dann schein es mindestens irgendwas 
zu senden (habe mit TV-Tuner bei 855,75 deutliche Tone im 
Sekundeninterval).

Habe schon mit timeout versucht: die Warteschleife wird nur dann 
verlassen, wenn der counter==0 ist. Es kommt also nichts am SDO.

Vor paar Tagen habe ich rfm12-434 als Empfänger und rf01-434 als Sender 
zum laufen bekommen, es funktioniert einwandfrei.

woran kann das liegen, dass SDO nicht auf High gezogen wird, und das 
beim !Senden!? Habe gelesen, dass manche solches Problem beim Empfänger 
hatten, komme aber nicht weiter.

PS: Hardware - ATTiny2313, 4 MHz extern getaktet, RFM12-868-D
Belegung:
RF12         Tiny

SDO          0
SDI          3
nSEL         2
SCK          1
, alle anderen nicht angeschlossen

Danke im Voraus

[motormons (Gast)]

Hallo

nach langem Lesen (das muss man ja auch können :)) habe ich mein Fehler 
entdeckt: und zwar habe ich den PollUp vergessen. Der Sender sendet 
also.

Dann hatte ich folgenden Problem (wie hier schon einige berichtet 
haben):
rf12_ready() Schleife beim Empfänger hing ewig. Habe einen Timeout 
eingebaut, es hat funktioniert, die Schleife wurde jedesmal nur nach 
diesem Timeout verlassen. Dadurch wurden nur 3 erste Bytes aus dem FIFO 
abgeholt (für meine Zwecke würde das reichen), und mehr nichts, außerdem 
dauerte das FIFO-Lesen viel zu lange(was nicht akzeptabel war).
Habe lange mit Status-Register gespielt, Timeout verändert und noch 
ganze Weile herumprobiert, hat auch nichts gebracht.

Dann habe ich die o.g. Methode geändert, und zwar so:

void rf12_ready(void)

{
  unsigned long timeout = 0;
  RF_PORT &=~(1<<CS);
  #asm 
  nop
        #endasm
  //wait until FIFO ready or timeout
  while (!(RF_PIN & (1<<SDO)))
  {
    RF_PORT |=(1<<CS);
    RF_PORT &=~(1<<CS);
    if (((timeout++)>100000)){break;};
  };
  RF_PORT |=(1<<CS);
}

ich habe also in der while-schleife, in der auf High am SDO gewartet 
wird, nSEL auf High und wieder auf Low gesetz, und jetzt geht es besser, 
es funktioniert zu mindestens so, wie ich das gerne hätte.

Jetzt ist die Frage: woran könnte das liegen?

[Hubert G. (hubertg)]

Hallo
Arbeitet hier auch jemand mit dem RFM02?
Ich arbeite mit einem Mega8 und AVR-Studio. Das Modul schaltet nicht auf 
10MHz um und tut auch sonst nichts. Gibt es irgend was grundlegendes zu 
beachten?

[Hubert G. (hubertg)]

Hat sich erledigt.
Ursache war das Pollin-Funkboard. Der Optokoppler schaltet die Spannung 
etwas verzögert ein. Abhilfe ist entweder den Optokoppler überbrücken, 
dann ist auch ein programmieren möglich ohne das man die SCK-Leitung vom 
Funk-Modul trennt, oder man wartet 100msec bis man mit den init beginnt.

[Hans Jürgen (Gast)]

Hallo,

hab ich das richtig vestanden, das FSK,DATA und nFFS keinen Pullup 
Widerstand brauchen? Was mache ich mit den Ausgängen?

Hat einer ein simplen Schaltplan? Habe hier nichts gefunden.

Danke

[Gerd G. (elektrikser)]

Hallo,

ich verweise dich mal auf einen anderen Thread. 
Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"
In der Zip-Datei findest du auch einen Schaltplan und ein Programm, mit 
dem du eine Funkbrücke machen kannst.

Gruß Gerd

[Igor M. (bastel-wastel)]

Wie stark beeinflusst die Form einer Drahtantenne die Sendeleistung, 
bzw. Reichweite?

Ich möchte den Sender für eine Fernbedienung nutzen und habe in der 
Länge nur ca. 10cm Platz.
Soll ich einen 17cm langen Draht zu einer langen Spule aufwickeln oder 
den Draht auf 10cm kürzen?

Beim Empfänger hab ich genug Platz, so dass die 17cm Drahtantenne kein 
Problem machen wird.
Ich möchte knapp 10m Entfernung überbrücken (direkte Sichtverbindung).


Noch was:
Haben die Sendemodule bei jemand schon größere EMV Schwierigkeiten bzw. 
Störungen am PIC/AVR verursacht?

[Benedikt K. (benedikt)]

Igor Metwet wrote:
> Soll ich einen 17cm langen Draht zu einer langen Spule aufwickeln oder
> den Draht auf 10cm kürzen?

Aufwickeln

> Haben die Sendemodule bei jemand schon größere EMV Schwierigkeiten bzw.
> Störungen am PIC/AVR verursacht?

Direkt an die Pins der Betriebsspannung 1nF + 100nF und es sollte keine 
Probleme geben.

[Fabian B. (fabs)]

Wobei ich mit 16,4cm aufgewickeltem draht (d =ca 0,8cm) auf 1,5m mit der 
schwächsten Sendereinstellung (-21dB) schon mal Aussetzer hatte. Jetzt 
hab ich auf -12dB gestellt und komm bei mir quer durch die Wohnung noch 
durch 4 Wände durch.

Gruß
Fabian

[Igor M. (bastel-wastel)]

Dank dir, werde ich so machen mit der Hardware.

Die Software kann ich dann ja noch anpassen.

[bobkins (Gast)]

Moin allerseits!

Habe meine zwei RFM12 an je einem Atmega32 auf Anhieb zum laufen bringen 
können :)
Für die C-Routinen möchte ich mich auch bei Benedikt bedanken!!!

Anfangs ist das letzte Byte verloren gegangen, aber mit der neuesten 
Version der rf12_txdata lief auch das.

Meine Module sind übrings 868-MHz-Exemplare, die mit ca. 8,6 cm 
Drahtantennen ausgestattet sind. Bisher habe ich nur Datenraten von 
19200 Baud verwendet.

Als nächstes werd ich mich mal an Hardware-SPI ranwagen. Werde dann 
berichten, ob ich Erfolg hatte.

gruß
bobkins

PS: Super Forum, super Leute!!! :D

[Pete (Gast)]

@Benedikt:
Kann man den BS170 auch durchen einen invertierenden Buffer ersetzen ?

[Benedikt K. (benedikt)]

Ja

[bobkins (Gast)]

Hallo!

Ich wundere mich gerade, warum am Interrupt-Pin nIRQ nur ein positiver 
Impuls beim Einschalten sichtbar ist?!?

Müsste nIRQ nicht im Idel-Zustand auf High sein?

bobkins

[Benedikt K. (benedikt)]

Ja. Les mal das Status Register aus, da sollte mindestens ein Bit 
gesetzt sein.

[Peter (Gast)]

Hallo,

ich bin neu hier und will der RFM12 Modul benutzen. Komme aber hier im 
Thread nicht ganz durch und weiss nicht welchen Sourcecode ich benutzen 
soll.

Vielleicht könnt ihr mir helfen.

Ich sende zahlen von 0 bis 999 an ein Emfänger.
Beispiel: Es wird die Zahl 345 vom Sender an den Empfänger geschickt. 
Der Emfänger schick dann die 345 zurück und bestädigt damit das er es 
richtig empfangen hat.

Mit welchem Code mache ich das am besten?


Vielen Dank

[Benedikt K. (benedikt)]

Prinzipiell sind die neuesten Versionen am besten. Für die ersten 
Versuche würde ich aber das hier empfehlen:
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"

[Wolfgang G. (Gast)]

Hallo,

hat jemand schon ein ideales Setup (Deviation, Bandwith, Afc....) für 
maximale Reichweite gefunden?
Ich nutze eine Baudrate von 19200 mit folgenden einstellungen:
Deviation 30Khz
Bandwith 67Khz
Afc +3/-4 Fres, Auto, Fine Mode
Vielleicht geht da noch mehr :-)

Grüße
Wolfgang

[Benedikt K. (benedikt)]

Meine Erfahrung: Mehr Bandbreite und mehr Deviation bringen deutlich 
mehr Reichweite (vorausgesetzt es ist kein anderer Sender in der Nähe 
der dann stört).
Ich nutze 200kHz Bandbreite und ich glaube 90kHz Deviation.

[Wolfgang G. (Gast)]

Hallo Benedikt,
bei Analog modulierten Signalen würde ich dir widersprechen und sagen 
ein hoher Frequenzhub verringert die Reichweite.
Wir sprechen hier aber von einer digitalen Modulation!?!?
Da wäre ein Statement von einem HF Spezialisten hilfreich.

Grüße
Wolfgang

[Benedikt K. (benedikt)]

Das waren zumindest meine Erfahtungen. Mit den im Datenblatt angegebenen 
"optimalen Einstellungen" war die Reichweite ziemlich bescheiden. Warum 
es so ist, kann ich dir auch nicht sagen, aber probiere es einfach mal 
aus: Man spürt deutlich einen Unterschied.
Ich erkläre mir das so: Mehr Deviation -> es ist einfacher zu 
Unterscheiden welche Frequenz gesendet wird, da die beiden weiter 
auseinander liegen.

[Richard B. (rbrose)]

maddin wrote:
> ...hier noch ein Bild und Hinweis für Lochraster Testaufbauten...
>
> das modul hat ja bekanntlich ein 2mm Raster.
>
> es besteht trotzdem die möglichkeit es auf lochraster zu setzen,
>
> wenn man die Pins wie folgt abwinkelt:
>
> O O | | O |
> O O | | O |
>
>
> O= Pin
> |= abgewinkelt und mit Kupferlackdraht durchgeführt
>
> man benötigt natürlich Pinleiste und Federleiste.
>
> gruß,
> m.


Ich verstehe nicht ganz wie du das gemacht hast?
Benutzt du ein Sockel und Stiftleisten?

[florian (Gast)]

Hallo hab mir auch die rf 12 module besorgt und auch gleich angefangen 
zu testen, hab nur ein problem. mein empfänger empfängt nix.
verwendete pins sind SCK, SDO, SDI, NSEL..
Anbei mein code evtl. könnt ihr ja en fehler entdecken..

MfG Florian

[florian (Gast)]

hier noch die 2.

[Fabian B. (fabs)]

Pullup an FSK?

Gruß
Fabian

[florian (Gast)]

kann es eventuell was dami zu tun haben das mein µC mit 12 Mhz läuft und 
das rf12 modul bekanntlich mit 10Mhz?

[florian (Gast)]

jap 10k

[Jojo S. (Gast)]

nö, das RFM12 liefert ja einen Clock als Output und kann damit einen µC 
versorgen. Habe hier auch einen Mega32 mit ext. 12Mhz dran. Kommt den 
nach der Initialisierung an Clock ein 10Mhz Takt raus (Oszi nötig) ?

[Jojo S. (Gast)]

und 'Receiver' ist bei dir falsch geschrieben ;-)
Ok, das sollte nicht stören. Aber ich würde vor den Calls im Programm 
erstmal den Stackpointer initialisieren.

[florian (Gast)]

der stackpointer wird initialisiert bzw. wird ihm in der zeile mov 
sp,#022h der startplatz im speicher zugewiesen...

[Jojo S. (Gast)]

stimmt, obwohl ich schon 4 Augen habe habe ich nur auf die Zeile nach 
dem Label geguckt.

[Richard B. (rbrose)]

Hallo,

muss ich den RFM12 am AVR SCK, MOSI und MISO per Jumper anschliessen 
damit ich, wenn ich den AVR Programmieren will mit ISP, das FRM12 
abschliesen kann? Oder kann ich direkt per ISP programmieren auch wenn 
der RFM12 dran hängt?

[R. M. (rmax)]

Richard B. wrote:

> Oder kann ich direkt per ISP programmieren auch wenn
> der RFM12 dran hängt?

Ja. Da SPI ein Bus ist, kannst Du beide Funktionen gleichzeitig 
verdrahtet lassen. Solange am RFM12 nSEL nicht auf Low gezogen wird, 
sind seine übrigen SPI-Pins hochohmig und stehen damit der 
Programmierung des Controllers nicht im Wege.

[florian (Gast)]

kann es eventuell auch daran liegen das ich keinen enstörkondensator von 
100nF für die Betriebsspannung zwischen 5V und GND hab?

[Richard B. (rbrose)]

Hallo zusammen,

ich habe meine Testschaltung mit zwei RFM12 Modulen aufgebaut.
Mit dem Programm RFM12_RX_TX habe ich den Empfänger und Sender bespielt.
Wenn ich jetzt beide starte ... sehe ich im Terminal vom Empfänger nur 
Empfänger "Empfaenger laeuft !<\n>" und dann kommt nix mehr ... also 
empfängt der Empfänger nichts :-(

Wie gehe ich jetzt am besten vor um das Problem zu finden? Wo muss ich 
messen?
Beide haben keine Antenne dran ... sind aber 40 cm von einander 
entfernt.


Vielen Dank im voraus!

[Benedikt K. (benedikt)]

Versuche irgendwie herauszufinden, ob die Frequenz am CLK Ausgang der 
Module bei 10MHz. Wenn nicht, dann ist irgendwas falsch angeschlossen.

[Richard B. (rbrose)]

Wie kann ich es am besten rausfinden wenn ich kein Ozi habe? Kann ich 
irgendwie einen Zähler mit einem AVR bauen`?

[Fabian B. (fabs)]

Viele Digitalmultimeter haben einene Hz-Messmöglichkeit.
oder du baust dir irgendwie (z.B. aus TTL Zähler-Bausteinen) einen 
20-Bit-Counter auf und schließt ans CarryBit ein D-Flipflop mit einer 
Led an... die sollte dann ca mit 9Hz blinken. Wobei das ziemlich von 
Hinten durch die Brust ins Auge wäre.
Was hast du denn für Meßgeräte zur Verfügung?

Gruß
Fabian

[Christian M. (Gast)]

@ bobkins

Könntest du mir vielleicht deinen C-Code für die 868 Module geben? Ich 
sitze hier an dran, es läuft nicht und finde den Fehler nicht. Aufbau 
ist wie auf dem Bild von Benedikt aber es will einfach nicht. Ich denke 
mal, dass ich noch falsche Einstellungen habe.

Thx im vorraus,

Christian

[MAX (Gast)]

hallo,

würde mich ebenfalls für die konfiguration eines 868MHz funkmoduls 
interessieren, bzw was man alles umschreiben muss um den code von 
benedikt für sein 433MHz modul verwenden zu können.

Danke,
MAX

[Richard B. (rbrose)]

Benedikt K. wrote:
> Versuche irgendwie herauszufinden, ob die Frequenz am CLK Ausgang der
> Module bei 10MHz. Wenn nicht, dann ist irgendwas falsch angeschlossen.

Danke dir Benedikt. Jetzt funktioniert es ;-)
Am Sender waren es nicht 10Mhz.

[Richard B. (rbrose)]

Meine Module werden vom Mega8 mit internen Clock 8 Mhz gesteuert.
Ist das ein Problem das die Module mit internen Clock laufen? Hab die 
mit 19200Baud laufen.

Ist es wie bei UART das man 0.2% Fehler hat? oder ist es da egal? Soll 
ich lieber 11.05 ... mhz benutzen?

Achja, ich benutze isolierten Kupferdraht für die Antenne, ist das ok? 
oder ist nicht isoliert besser?

[Benedikt K. (benedikt)]

Bei den Modulen ist das egal, da diese ihren eigenen Quarz haben.

[Richard B. (rbrose)]

Achja, ich benutze isolierten Kupferdraht für die Antenne, ist das ok?
oder ist nicht isoliert besser?

[Richard B. (rbrose)]

Keiner eine Antwort?

[Benedikt K. (benedikt)]

Die Isolierung des Drahtes ist egal, der Draht sollte nur nicht zu dünn 
sein (so ab 0,5mm Durchmesser aufwärts)

[Richard B. (Gast)]

Danke dir Benedikt.

So ... die Module versenden fleisig Chars.
Ich will aber nun das der Sender ein int von 0 bis 999 versendet und der 
Empfänger die auch als int bekommt. Wie mach ich das? Kann mir einer 
einen codeschnippsel posten?
Ich habe das mit atoi versucht ... klappt aber irgendwie nicht.

Danke

[Fabian B. (fabs)]

Was heisst denn versucht? code?
Du verschickst nur chars... wenn du dann wieder Ints haben willst musst 
du sie wandeln...eben mit atoi

Gruß
Fabian

[Richard B. (rbrose)]

Hier der C Code für den Empfänger:

void receive(void)
{  
  unsigned char test[1];  
  uint8_t tmp;
  rf12_rxdata(test,1);
  tmp = atoi(test[0]);  
  if(tmp > 0 && tmp < 10) 
  {
    einer = tmp;
  }
}

Beim Build bekomme ich diese Warnung:

../main.c:106: warning: implicit declaration of function 'atoi'

Wie kriege ich die Warnung weg?

Hier der Code vom Sender:

void send(void)
{  unsigned char test[]="2";  
  rf12_txdata(test,1);
}

Aber irgendwie ist einer und tmp immer 0.

Einer eine Idee?

[R. M. (rmax)]

Richard B. wrote:
> Hier der C Code für den Empfänger:

>   tmp = atoi(test[0]);

atoi nimmt char* als Argument, Du gibt ihm hier aber nur ein char.
So wäre es richtig:

    tmp = atoi(test);

Dann mußt Du allerdings auch sicherstellen, daß der String mit einem 
'\0' abgeschlossen ist, entweder indem Du es mitschickst oder indem Du 
test[1]='\0' setzt. In beiden Fällen mußt Du test noch entsprechend 
größer deklarieren.

> ../main.c:106: warning: implicit declaration of function 'atoi'
> [/c]
> Wie kriege ich die Warnung weg?

#include <stdlib.h>

> Hier der Code vom Sender:
>
>

> void send(void)
> {  unsigned char test[]="2";
>   rf12_txdata(test,1);
>

Um die \0 mitzuschicken, die den String abschließt, mußt Du hier zwei 
Zeichen übertragen.


Ein ganz anderer Ansatz wäre noch, den Integer-Wert Byte für Byte binär 
zu übertragen, dann würdest Du Dir das Konvertieren nach ASCII und 
zurück sparen und ein Wert hätte bei der Übertragung immer die gleiche 
Anzahl von Bytes.

[Richard B. (rbrose)]

@Reinhard Max
Danke für die ersten Anmerkungen.

Wie mache ich es mit dem Interger? Wie verschicke ich binär?

[R. M. (rmax)]

Richard B. wrote:
> Wie mache ich es mit dem Interger?

Das wollte ich dem geneigten Leser eigentlich als Übungsaufgabe 
überlassen ;)

> Wie verschicke ich binär?

Für die Module gibt es da keinen Unterschied, die verschicken einfach 
nur Bytes. Ob es sich dabei um (ASCII-)Strings oder Binärdaten handelt 
ist eine Frage der Interpretation in der sich Sender und Empfänger halt 
einig sein müssen, damit sie Daten austauschen können.

Von daher sollte man das das, was rf12_txdata übergeben bekommt, besser 
nicht als String betrachten (obwohl es im Einzelfall ein solcher sein 
kann), sondern als Puffer, der eine beliebige Bytefolge enthalten kann.

Die einfachste Möglichkeit, einen int-Wert binär zu schicken, würde z.B. 
so aussehen:

int foo = 42;
rf12_txdata((char*)&foo, sizeof(int));

Die Adresse der int-Variablen wird in einen char-Pointer umgedeutet und 
rf12_txdata soll ab dieser Adresse so viele Bytes senden, wie in einer 
Integer-Variablen enthalten sind.

An der Empfänger-Seite darfst Du jezt aber wirklich mal selber üben... 
;)

[Richard B. (rbrose)]

Danke dir.

Probiere das zuhause aus ... muss leider noch einbisschen hier auf der
Arbeit arbeiten :-)

Hier meine Überlegung schon mal:

void receive(void)
{  
  int test;  
  rf12_rxdata((char*)&test,sizeof(int));  
  if(test > 0 && test < 10) 
  {
    einer = test;
  }
}

Geht es in die richtige Richtung?

[R. M. (rmax)]

Richard B. wrote:

> Geht es in die richtige Richtung?

Ja, der Aufruf von rf12_rxdata müßte so passen, den if-Block kannst Du 
Dir aber sparen, denn nach dem Empfang steht in test ja schon der 
komplette int-Wert drin.

[Richard B. (rbrose)]

Ok, mach gleich Feierabend und teste es.

Wie mache ich es eigentlich mit einer Überprüfung ob auch das richtige 
angekommen ist?

Sender(sendet int 144) -> Empfänger(sendet int 144 zurück) -> 
Sender(Überprüf 144 = 144 ) -> Empfänger(stimmt)

[R. M. (rmax)]

Ja, so kann man das machen, aber effizienter ist es, wenn der Sender 
gleich redundante Informationen mitschickt, anhand derer der Empfánger 
die Korrektheit selbst überprüfen kann.

Beispielsweise kann der Sender die Daten doppelt schicken, einmal 
normal, einmal invertiert, um Fehler durch systematische Bitkipper 
auszuschließen, was sich aber wegen der Verdopplung der Daten nur bei 
kleinem Datenvolumen (Fernbediungunskommandos, sporadische Meßwerte, 
etc.) anbietet.

Bei größeren Datenblöcken wird meistens mit Prüfsummen (Stichwort: CRC) 
gearbeitet.

[Richard B. (rbrose)]

So beim Builden der funktion:

void send_int(uint16_t zahl)
{      
  rf12_txdata((char*)&zahl,sizeof(uint16_t));
}

Kriege ich den Fehler:

../main.c:125: warning: pointer targets in passing argument 1 of 'rf12_txdata' differ in signedness

Was heißt das? Finde vieles bei google aber keine Erklärung.

[Benedikt K. (benedikt)]

Das bedeutet nur, dass rf12_txdata() einen unsigned char* erwartet, du 
aber einen char* übergibst. Es hat in diesem Fall aber keine 
Auswirkungen auf die Funktion.

[Richard B. (rbrose)]

ok stimmt. Muss ich jede funktion nochmal in die main.c reinschreiben 
die ich benutze?

Wie z.B. itoa, bekomme nählich die Warnung:

../main.c:131: warning: implicit declaration of function 'itoa'

Das heißt doch ich muss die oben nochmal hinschreiben ... also den 
function kopf ... oder?

[Richard B. (rbrose)]

Mhhh irgendwas mache ich falsch. Hier mein Code

Sennder:

In der main schleife:
  send_int(354);
  for (unsigned char i=0; i<250; i++)
       _delay_ms(10);


Die Funktion:


void send_int(uint16_t zahl)
{      
  rf12_txdata((char*)&zahl,sizeof(uint16_t));
}

Empfänger:

  while(1) 
   {            
     receive_int();                                    
   }


void receive_int(void)
{  
  uint16_t test;  
  char buffer[7];

    rf12_rxdata((char*)&test,sizeof(uint16_t));    
    
  itoa( test, buffer, 10);
  uart_puts(buffer);  
  uart_putc('\n');
}

Und das ist das Ergebniss auf dem Terminal:

- 9 1 1 8 \n
1 6 2 2 6 \n
3 2 6 1 0 \n
1 6 2 2 6 \n
1 6 2 2 6 \n
1 6 2 2 6 \n
1 3 7 8 \n
3 2 6 1 0 \n
3 2 6 1 0 \n
1 5 2 0 2 \n
1 6 2 2 6 \n
1 6 2 2 6 \n
8 0 3 4 \n
- 1 5 8 \n
1 6 2 2 6 \n


Wieso das? Wieso hab ich so ein Ergebniss?

[Richard B. (rbrose)]

Hilfe ... das Liegt an den Modulen ... die Übertragen mit Fehlern ... Oh 
man.

Hab die Empfänger funktion so geändert:

void receive_int(void)
{  
  int test;    
    rf12_rxdata((char*)&test,sizeof(int)); 
  
  if(test == 123)
  {
    uart_puts("Richtig!");  
  } else 
  {
    uart_puts("Falsch!");  
  }       
}

Das Ergebniss ist:

S e n d e r   l a e u f t   ! \n F a l s c h ! F a l s c h ! F a l s c h ! 
F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! 
F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! 
F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! 
F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! F a l s c h ! 
F a l s c h ! F a l s c h ! R i c h t i g ! F a l s c h ! R i c h t i g ! F a l s c h !
 R i c h t i g ! 
F a l s c h ! R i c h t i g ! R i c h t i g ! R i c h t i g ! R i c h t i g ! F a l s c h !
 F a l s c h ! R i c h t i g ! F a l s c h ! R i c h t i g ! R i c h t i g !

Was kann ich für ein besseren Empfang machen?
rf12_setbandwidth(4, 1, 4); Kann ich hier was machen?

[Richard B. (rbrose)]

Finde leider hier nichts welche Register ich einstellen kann um die 
Sendeleistung zu verbessern. Was kann ich einstellen? Müssen die 
Einstellungen beim Sender und Empfänger gleich sein um die optimale 
Einstellugen zu bekommen? Wie tastet man sich da heran?

Muss ich vielleicht die Baud runterdrehen?
Was kann ich mit rf12_setpower machen?

Achja meine Module sind nur 50cm von einander entfernt ... und liefern 
so ein schlechtes Ergebnis. Das kann doch nicht sein.

[R. M. (rmax)]

Richard B. wrote:

> Das heißt doch ich muss die oben nochmal hinschreiben ... also den
> function kopf ... oder?

Nein, nur den passenden Header einbinden, in dem die Funktion deklariert 
ist, so wie ich es Dir für atoi schonmal hingeschrieben hatte.

> Was kann ich für ein besseren Empfang machen?

Richtig senden? ;)

Deine Sende-Schleife läßt zwischen den einzelnen Sendungen eine längere 
Pause. In dem Fall darfst Du meines Wissens anschließend nicht einfach 
weiter Daten senden, sondern mußt die Übertragung mit Präambel und allem 
Trallala neu aufsetzen, damit der Empfänger sich wieder neu auf den 
Sender synchronisieren kann.

Übrigens ist das letzte Byte Deiner Müll-Werte in den meisten Zeilen 
korrekt, was meines Erachtens auch auf ein Synchronisations-Problem 
hindeutet.

[Richard B. (rbrose)]

Endlich antwortet einer ;-)

Das mit dem Header geht jetzt danke.

Das verstehe ich nicht. Das heißt wenn ich eine Sekunde warte muss ich 
das Modul wieder von einem Initialisieren?

Das Problem ist ja auch das die ersten Zeichen auch nicht immer richtig 
ankommen. Habe an den rf12_setbankwidth werten einbisschen gespielt und 
es hat verbesserungen gegeben.
Aber leider weiss ich nicht wie hoch ich gehen darf und was z.B.
rf12_setbankwidth(4,1,4) ist  // 200kHz Bandbreite, -6dB Verstärkung, 
DRSSI threshold: -79dBm

was ist aber rf12_setbankwidth(4,2,4) ? doppelt so viel? also -12db?

[Richard B. (rbrose)]

@ Reinhard Max

Wie Synchronisiere ich die Module? Finde hier nirgends informationen.
Vielen Dank für deine Mühe.

[Benedikt K. (benedikt)]

Das synchronisieren macht die Software schon selbst, darum musst du dich 
nicht kümmern.

Für maximale Reichweite sollte diese Einstellung gut sein:
rf12_setpower(0, 5);
rf12_setbankwidth(4,0,0);

Damit sollten einige 10m selbst unter ungünstigen Bedingungen möglich 
sein.

Welche Software verwendest du eigentlich ?

[Richard B. (Gast)]

Hallo Benedikt,

ich benutze den von dir empfohlenen Code: RFM12_RX_TX.zip
Ich werde die Einstellungen gleich testen. Und das Ergebniss hier 
Posten.
Die Einstellugen müssen beim Sender und Empfänger gleich sein oder?

Maximale Reichweite ... heißt das, das bei 50 cm ich damit ein Problem 
haben könnte aber nicht in 5m ?

[Richard B. (rbrose)]

Ich habe es mit den Einstellungen probiert ... es ist sogar noch 
schlechter.

Ich habe mal die funktion wieder zurückgebaut und verschicke wieder 
einen Text und hier sieht es irgendwie besser aus.

Ergebnis:

S e n d e r   l a e u f t   ! \n
D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    \x D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ? D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
    ÿ D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
     D i e s   i s t   e i n   4 3 3 M H z   T e s t   ! ! ! \n
        

Am Anfang habe ich ein ÿ was ich nicht mitschicke ... kann es sein wenn 
ich nur eine Zahl schicke es immer wegem dem ÿ zu einem Problem kommt?
Soll ich dann lieber sowas machen "######-123+######"
Heißt das ich davor einbisschen blödsind schicke und dann nach - und + 
suche um die Zahl zu finden?

Hast du eine Idee?


Vielen DANK im voraus.

[Benedikt K. (benedikt)]

Wenn ich das richtig sehe, ist das erste Byte jeweils zuviel.
Probier mal folgendes aus:
Ersetze diese Funktion durch das hier (bzw. wichtig ist eigentlich nur 
das 2. nop. Eventuell reicht die Pause vor dem Einlesen nicht ganz aus:

void rf12_ready(void)
{
  cbi(RF_PORT, CS);
  asm("nop");
  asm("nop");
  while (!(RF_PIN&(1<<SDO)));      // wait until FIFO ready
  sbi(RF_PORT, CS);
}

[Richard B. (rbrose)]

Hallo Benedikt,

meine rf12_ready funktion sieht so aus:

void rf12_ready(void)
{  cbi(RF_PORT, SDI);
  cbi(RF_PORT, CS);
  asm("nop");
  while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}

Soll ich die so abändern wie bei dir?

[Richard B. (rbrose)]

Hab die Methode so geändert wie du die hast ... hat aber leider nicht 
geholfen ich kriege am anfang immer irgend ein Müll.

[Browncoat (Gast)]

Irgendwie funktioniert das alles nicht bei mir. Hab den RFM12, der sagt 
garnix, der RFM01 macht auch keine Anstalten was zu empfangen, der RFM02 
sendet zumindest das original Pollin Programm.

Bei den hier geposteten Progs regt sich garnix. Der Optokoppler wurde 
fachmännisch gebrückt. Die Programme laufen auf einem ATMega8 mit 
internen 8 MHz, eine 17 cm Antenne schmückt die Boards, ein 1k 
Widerstand legt beim RFM12 FSK auf VCC.

Muss ich bei den RFM01 und RFM02 auch noch irgendwelche Modifikationen 
am pollin Board vornehmen um die zum funktionieren zu bewegen? Wie 
siehts beim RFM12 aus?

Ich hau die Dinger gleich inne Egge!

MfG BC

[Lorenz .. (lorenz)]

@ Browncoat:
Welchen COde verwendest du? Mit IRQs oder gepollt? Bei den IRQ-Methode 
hatte ich mal was zum Pollin-Board gepostet. Gepollt sollte auch so 
funktionieren.
Ansonsten habe ich bei meinem Board nur noch den Takt aus dem RFM12 auf 
den Quartzsteckplatz gelegt, um die 10Mhz Takt zu nutzen. Widerstand 
habe ich wie du 1k auf Vcc.
Schreib mal welchen Code du nutzt, dann kann ich dir evtl ein "working 
sample" schicken.

[Browncoat (Gast)]

Hi, also ich benutze die Codes aus diesem Thread,

Für das RFM01
http://www.mikrocontroller.net/attachment/22522/rfm01.zip
Das original Pollin Programm macht hier nichts ausser nach dem Reset 
drei mal die LED blinken zu lassen. Die Software hier funktioniert 
bisher nicht.


RFM02
http://www.mikrocontroller.net/attachment/22516/rfm02.zip

Das Senden mit dem RFM02 und original Pollin Code klappt, getestet am 
TV, Kanal S37. Mit dem Code hier sagt erleider garnichts.



fürs RFM12
http://www.mikrocontroller.net/attachment/23263/RFM12_RX_TX.zip

Der original Pollin Code macht auch hier keine Anstalten, getestet 
gestern am Spektrumanalysator.
Mit dem Code von hier erhalte ich schonmal eine Meldung via RS232.

Hab leider von jedem Funkmodul nur eins zur Verfügung, und die 
befürchtung, daß RFM01 und RFM12 einen weg haben könnten, da sich da 
schon ein paar andere Leute dran versucht haben. RFM02 hab ich selbst 
aufgelötet und getestet.

MfG BC

[Florian (Gast)]

Kann eventuell jemand hier seine exakten Einstellungen sprich der 
register posten wäre echt nett.
Komm nämlich auch nich weiter vielleicht funktionierts ja mit anderen 
Einstellungen...

MfG Flo

[Richard B. (rbrose)]

Sehe ich das richtig, dass der Empfänger ständig in einer Schleife hängt 
bis er etwas empfängt?

[Benedikt K. (benedikt)]

Ja, bei den einfachen Versionen schon. Die besseren nutzen einen 
Interrupt.

[Richard B. (rbrose)]

Kannst du mir eine bessere Version nennen? Ohne das ich die Verkabelung 
neu machen muss?

Hab die Verkabelung so wie es in der gif von der RFM12_RX_TX.zip steht.

[Benedikt K. (benedikt)]

Das geht nicht. Man braucht zumindest noch eine Verbindung von FFIT zu 
einem INT Anschluss-

[Richard B. (rbrose)]

ASO verstanden. Das heißt wenn der FFIT eine Flanke setzt dann reagiert 
der INT von AVR und bearbeitet das empfangene. Richtig?

Welche Version nehme ich dafür? Hier ist es schon langsam 
unübersichtlich.

[Maximilian (Gast)]

Nachdem man Empfänger nichts empfangt habe, habe ich mal am Filter 
Kondensator des RSSI Pin gemessen und immer wenn der Sender sendet, 
hatte ich einen kurzen Spannungsanstieg messen, heißt das der Sender 
funktioniert?

[Benedikt K. (benedikt)]

Ja. Das heißt auch, dass der Empfänger in etwa auf die selbe Frequenz 
eingestellt ist, und läuft.
Ich würde entweder auf ein fehlendes Sync Word vom Sender tippen, auf 
ein nicht aktives FIFO oder sonst eine falsche Modulationseinstellung.

[Maximilian (Gast)]

Danke für die schnelle Antwort!

Ist einmal gut zu wissen das irgendwas geht.

Das Sync Word ist doch nach der Preamble B82D und B8D4 oder hab ich das 
was übersehen?

[Benedikt K. (benedikt)]

2DD4 ist das Sync Word. Davor kommen noch ein paar AA (10101010 usw.) um 
den Empfänger auf die Bitrate einzusynchronisieren.

[Maximilian (Gast)]

Wie muss ich das machen wenn ich beim empfangen nicht pollen will 
sondern den Interrupt verwenden?

Hab gelesen FFIT mit nINT verbinden und dann nIRQ zum µC stimmt das?

Jedenfalls ohne irgendwas tut der nIRQ Pin nur selten was.

[Fabian B. (fabs)]

Nein, du verbindest FFIT mit dem uC. Wenn der FFIT feuert, dann sind so 
viele Bits im FIFO wie du als Benachrichtigungsschwelle eingestellt 
hast...(Benedikts default ist 8 Bit).

Mehr brauchts nicht.

Gruß
Fabian

[Maximilian (Gast)]

Aha, habe ich das jetzt richtig verstanden:

Wenn Daten im FIFO dann geht FFIT auf high, sobald Daten aus sind geht 
er auf low.

[Fabian B. (fabs)]

Exakt.
Du kannst also im Prinzip im Interrupt ein Byte ausm Fifo abholen. Wenn 
noch mehr da sind feuert der Int ja eh wieder. Vorausgesetzt du hast nen 
Levelinterrupt! FFIT bleibt High(?) solange der Fifo über der Schwelle 
ist.

Gruß
Fabian

[Richard B. (rbrose)]

Wenn der AVR bei "wait until FIFO ready" stecken bleibt ...

void rf12_ready(void)
{
  cbi(RF_PORT, CS);
  asm("nop");
  asm("nop");
  while (!(RF_PIN&(1<<SDO)));      // wait until FIFO ready
  sbi(RF_PORT, CS);
}

was könnte das Problem sein?

Und wie kann ich prüfen ohne Ozi ob mein Modul mit 10Mhz läuft?

[Richard B. (rbrose)]

Das Funk Modul das funktioniert hat 2.08V zwischen CLK und GND und das 
Modul das nicht funktioniert hat 1.81V. Kann man daraus schließen, dass 
das Modul das nicht funktioniert mit weniger MHZ am CLK läuft?

[Benedikt K. (benedikt)]

Das kann man eigentlich nicht sagen, es könnte noch andere Gründe geben.

[Richard B. (rbrose)]

Hab den Fehler gefunden. Es lag an DDRB = 0xFF; :-(

[Maximilian (Gast)]

Nachdem ich jetzt daran glaub das mein Hardware SPI ein Problem hat 
wollte ich mal Fragen ob mir jemand die Software-Routine für SPI von 
Benedikt bitte erklären könnte:

#else      //Routine für Software SPI
  for (unsigned char i=0; i<16; i++)
  {  
    if (wert&32768)
      RF_PORT |=(1<<SDI);
    else
      RF_PORT &=~(1<<SDI);
    werti<<=1;
    if (RF_PIN&(1<<SDO))
      werti|=1;
    RF_PORT |=(1<<SCK);
    wert<<=1;
    asm("nop");
    RF_PORT &=~(1<<SCK);
  }
#endif
  RF_PORT |=(1<<CS);
  return werti;

[Benedikt K. (benedikt)]

Ganz einfach:
Als erstes wird das höchstwertige Bit ausgegeben, danach der Wert um 
eine Stelle nach links geschoben, so dass das gerade eben an den Port 
gelegte Bits rausfällt. An die nun freie Stelle rechts wird der 
Eingangspin eingelesen.
Es wird also gleichzeitig gesendet und empfangen, so wie es bei SPI 
üblich ist. Die SCK Leitung wird dann noch getoggelt, und das ganze 16x 
(für die 16bit) wiederholt.
Am ende wurde der Wert der anfangs in Wert war gesendet, und ein 16bit 
Wert von SPI in Wert empfangen.

[Richard B. (rbrose)]

Hab eine Frage zur Antenne. Ist es besser die Antenne mit voller länge 
(17cm) in das Gehäuse zu legen oder es zur einer Spirale aufwickeln?

Sind 433Mhz Module.

[Richard B. (rbrose)]

Keiner will mir das beantworten? :-(

[Benedikt K. (benedikt)]

Das liegt vermutlich daran, dass man die Frage so nicht beantworten 
kann.
17cm Antenne ist mit Sicherheit die einfachere Lösung, da eine gut 
optimierte Spirale als Antenne nicht einfach zu berechnen ist.
Ich würde also die 17cm verwenden, da man da weniger falsch machen kann.

[Fabian B. (fabs)]

@Benedikt:
hast du ein paar Links oder Infos wie man sowas berechnet?
Ich hab in meiner Fernbedienung die Antenne zu einer Spirale mit ca 8mm 
Durchmesser gewickelt (Platzgründe) und musste eine deutlich verminderte 
Reichweite feststellen.

Gruß
Fabian

[Maximilian (Gast)]

Ich habe nun noch immer das gleiche Problem: Wenn der Sender sendet 
ändert sich beim Empfänger am RSSI Pin was.

Beide Module sind gleich initialisert, Sender/Empfänger Register 
gesetzt.

Module liegen 10cm entfernt, Software oder Hardware SPI bringen das 
gleiche Resultat.

Weiß vielleicht jemand was da sein könnte?

[Richard B. (rbrose)]

Eine Frage noch zum AVR-Sleep Mode.
Ich benutzen den RFM12 per polling. Der Empfänger ist also in der Main 
die ganze Zeit in der while schleife vom RFM12 bis er Daten zugesendet 
bekommt.
Wie kann ich den AVR in den Sleep Modus setzen?
Heißt wenn 5 Minuten keine Daten angekommen sind dann schlafen gehen.

Das könnte man einfach in einem Timer lösen ... aber ich habe gehört das 
man keinen Sleep befehl im Timer machen sollte da es zu Problemen führt.
Hat einer eine Idee wie man das machen könnte?

Ich weiß eine Lösung wäre, wenn man das ansteuern des RFM12 per 
Interrupt machen würde ... aber die Hardware ist schon gelötet.

[bobkins (Gast)]

@Richard B.
Die 17 cm Draht-Antenne solltest du nicht als Spirale wickeln, da sich 
damit die Eigenschaften der Antenne verändern. Ideal ist gerade!

Die ideale Länge der Draht-Antenne hängt von der Frequenz ab und 
berechnet sich laut Literatur so:

l = c0 / (f * 4)

l=Länge der Draht-Antenne
c0=Lichtgeschwindigkeit in Luft in m/s
f=Frequenz in Hz

c0/f stellt die Wellenlänge der Funkwelle dar. Als Antenne wird 1/4 der 
Wellenlänge verwendet (Stichwort "Viertelwellendipol").

Beispiel:
f=433Mhz
l = 300e6 m/s / (433e6 Hz * 4) = 17,3cm

Wenn du deine Antenne als Spirale wickeln willst, oder sonst irgendwie 
vom langen Draht abweichen willst, müsstest du dir ein spannendes Buch 
über Hochfrequenztechnik anschauen, auf Erfahrungswerte ausweichen, oder 
deine Antennenkonstruktion mit einem Messempfänger ausmessen. Letzteres 
gibt dir einen praktischen Wert.

Der Vollständigkeit halber erwähne ich noch den Verkürzungsfaktor. Der 
berücksichtigt den Unterschied der Wellenausbreitungsgeschwindigkeit in 
Vakuum gegenüber der Geschwindigkeit im (Kupfer-)Draht. Den könnte man 
einfach als 0,96 annehmen. Also würde die Antenne kürzer als 17,3 cm 
werden.

So genau kann man das allerdings nicht sagen, weil selbst das kleine 
Stückchen Leiterbahn auf dem RFM-Modul seine Finger im Spiel hat, uvm. 
Daher sagen wir einfach mal 17cm, passt schon!


@Christian M.
Sorry, hab dich ganz vergessen! Mein Code ist derselbe, wie auch für die 
433 MHz-Module. Nur die Konfiguration habe ich etwas angepasst, so wie 
ich es laut Datenblätter für richtig hielt. Wenn du die haben möchtest, 
müsste ich mal bei Gelegenheit nachschauen.

mfg bobkins

[Michel (Gast)]

Hallo bobkins (Gast),

es wäre toll wenn du die Konfiguration für die 868 Module einmal 
heraussuchen kannst. Auch ich habe hier, ähnlich wie Christian ein 868 
Modul das leider nicht läuft.

Gruß Michael

[Christian M. (inscene)]

@bobkins

Freut mich, dass du mich nicht vergessen hast. Ich bin aber durch langes 
studieren des Codes und des Datenblattes selbst auf die Loesung 
gekommen. Sind im Grunde nur zwei oder drei Aenderungen. Werde die heute 
abend hier auch mal angeben.
Zurzeit bin ich mit einem Kommunikations-Protocoll fuer die Module 
beschaeftigt. Halt mit Frames variabeler Groesse, CRC usw.
Mal schauen was dabei rauskommt.

Bye, Christian.

PS.: Ich habe hier leider keine deutschen Umlaute. Arbeite in den NL. 
Also nicht ueber die Schreibweise wundern ;-)

[Christian M. (inscene)]

So, hier die Einstellungen für die 868 MHz Module.

Die Frequenz umstellen (in der Main):

rf12_setfreq(RF12FREQ(868.92));  // Sende/Empfangsfrequenz auf 868,92MHz einstellen

In der Funktion void rf12_init(void) folgendes ändern (in der rf12.c):

//rf12_trans(0x80D7);      // Enable FIFO 433 MHz
rf12_trans(0x80E7);      // Enable FIFO 868 MHz

In der rf12.h volgendes ändern:

//#define RF12FREQ(freq)  ((freq-430.0)/0.0025)              // macro for calculating frequency value out of frequency in MHz
#define RF12FREQ(freq)  ((freq-860.0)/0.005)              // macro for calculating frequency value out of frequency in MHz

Das war auch schon alles. Ich habe diese Änderungen in der Version 
rfm12_rs232_rxtx.zip gemacht.

Ich hoffe das hilft euch weiter.

Gruß, Christian

[bobkins (Gast)]

hi!

super, dann werd ich ja nicht mehr gebraucht ;-)

Soweit ich mich erinnern kann (hab mal wieder meinen krempel nicht hier) 
habe ich die Einstellungen genauso gemacht. wie gesagt, siehe 
Datenblatt.

mfg bobkins

[Anna W. (Gast)]

Leider wird vielerorts nur mehr der RFM12B angeboten. Der soll im 
Prinzip gleich sein, verträgt allerdings nur max 3,8V. Laut Datenblatt 
liegt der High-Output bei min Vdd-0,4 = dann 3,4V.

Mein AtMega Board hat nur 5V. Laut Datenblatt Mega16 liegt die Input 
High Voltage bei min. 0,6*V=3V. Hat schon jemand ausprobiert, ob da die 
Kommunikation reibungsfrei läuft? Bzw. kann ich einfach 2 Dioden nehmen 
für die Absenkung der 5V? Hab keinen Platz für noch nen Spannungsregler 
bzw. Pegelwandler und will es möglichst einfach lösen. Vorschläge?

[Andreas K. (a-k)]

Pegelwandler

3V high an den AVR wäre knapp. Aber du kannst davon ausgehen, dass ein 
unbelasteter Ausgang eines CMOS ICs annähernd Vdd liefert, nur dauert 
low=>high dann länger als im Datasheet vom RFM steht. Wenn du den 
SPI-Takt also nicht voll ausreizt und dem RFM seine 3,5V gibst, dann 
dürfte das gut funktionieren.

Wenn Dioden, dann ausreichend belastet damit es mindestens 0,6V pro 
Diode sind (1mA min bei 1N4148). Bei den 0,3µA eines RFM12 im Standby 
kommen dort sonst weit über 4V an. Also Lastwiderstand 3K3 hinter die 
Dioden, und auch einen kleinen Elko, sonst entscheidet der RFM em Ende 
noch auf Brownout sobald er aufwacht.

[maddin (Gast)]

...ich habe ein paar kleine fragen zu diesen beiden routinen:

void rf12_txdata(unsigned char *data, unsigned char number)
{  unsigned char i;
  rf12_trans(0x8238);      // TX on
  rf12_ready();
  rf12_trans(0xB8AA);
  rf12_ready();
  rf12_trans(0xB8AA);
  rf12_ready();
  rf12_trans(0xB8AA);
  rf12_ready();
  rf12_trans(0xB82D);
  rf12_ready();
  rf12_trans(0xB8D4);
  for (i=0; i<number; i++)
  {    rf12_ready();
    rf12_trans(0xB800|(*data++));
  }
  rf12_ready();
  _delay_us(10);
  rf12_trans(0x8208);      // TX off
}

void rf12_rxdata(unsigned char *data, unsigned char number)
{  unsigned char i;
  rf12_trans(0x82C8);      // RX on
  rf12_trans(0xCA81);      // set FIFO mode
  rf12_trans(0xCA83);      // enable FIFO
  for (i=0; i<number; i++)
  {  rf12_ready();
    *data++=rf12_trans(0xB000);
  }
  rf12_trans(0x8208);      // RX off
}

1) in benedikts code ist zwischen:
  rf12_trans(0xCA81);      // set FIFO mode

und :
  rf12_trans(0xCA83);      // enable FIFO
ein delay, ist es notwendig - warum?

2)beim einschalten von rx oder tx werden immer beide optionen nach der 
jeweiligen aktion wieder abgeschaltet, warum? kann ich auch direkt 
umschalten..

3)es müsste doch auch moglich sein, mit einem flankeninterrupt zu 
empfangen, indem man ffit nach jedem byte das man ausliest abfragt.

4)das modul bietet auch die möglichkeit statusmeldungen zurückzulesen 
(datenblatt befehl 16 (0xxx xxxx xxxx xxxx), leider ist er nicht 
dokumentiert, also welches bis welchen status rückmeldet, oder gibts da 
noch ein extra datenblatt?

5)zu der präambel von B8AA, wurde weiter oben schon angesprochen:
wo wird diese wieder entfernt?

6)was bewirkt:
         rf12_trans(0xB82D);
  rf12_ready();
  rf12_trans(0xB8D4);

sind das noch befehle?


gruß und vielen dank im vorraus,

m.

[Andreas K. (a-k)]

Die Statusbits stehen sehr wohl im Datasheet vom RF12.

Die Präambel schmeisst der Emfänger weg, weil er überhaupt erst bei 2DD4 
wirklich aufwacht.

[ReinHerR (Gast)]

auf die Gefahr hin dass ich mich beim total Blamiere: Ich hab bei diesem 
Prog. von Benedikt echt Probleme.

Ich habe das Programm eingebaut und es lässt sich mit nur einer Warnunge 
Compilieren  (../main.c:55: warning: pointer targets in passing argument 
1 of 'lcd_puts' differ in signedness
). Der ATMega16 hängt sich nicht auf. Aber auf dem Display entsteht nur 
Datenmüll:
Wenn ich die empfangenen Daten wie folgt verarbeite:

rf12_rxdata(test,15);
// daten verarbeiten
lcd_gotoxy(0,0);
lcd_puts(test);

dann bekomme ich einen 15 Zeichen breiten schwarzen Balken.

Ersteze ich "lcd_puts(test);" durch lcd_puts(test[3]); dann bekomme ich 
den ganzen Bildschirm voller wirrer zeichen (bei jedem Durchlauf die 
gleichen).
Der ATMega hängt sich aber nicht auf. Habe auf zwei Boards (gleiche 
Verdrahtung) die gleichen Probleme. Es ist egal ob das eine Board sendet 
oder nicht, im Sekundentakt wird das Display beschrieben.

Hab´ ich jetzt das CHAR-Handling nicht verstanden oder hab´ich ein ganz 
anderes Problem?
Danke für die Hilfe
Gruß
Kuddel

[Vajk .. (vajk)]

Kleine Frage - ist die Empfangssteuerung von RFM01 und RFM12 und die 
Sendesteuerung von RFM02 und RFM12 jeweils identisch, also die Module 
austuaschbar? Ich googel da schon ganze Zeit und finde keine Antwort.
LG
Vajk

[Christian J. (Gast)]

Nein, ist sie nicht. Befehlsbits sind jeweils andere.

[Steven (Gast)]

Hallo alle,
ich suchte eine Sende-/Empfang Modul SET für die Übertragung von Daten 
mit einer entfernung von mindesten 30m. und bin auf diese Beitrag 
gestoßen. Als controller benutze ich der Mega16 der auf den AVR STK500 
angeschlossen ist. jetz wollte ich gern der RF12 als Sende-/Empfang 
Modul SET benutzen und habe einige Fragen an euch.

1-kann ich der RF12 direkt an meiner AVR STK500 anschliessen und 
benutzen ohne weiter änderungen oder erweiterungen?

2- wenn änderungen nötig sind: welche sind die?

3- welche Type von Antenne um mein Ziel zu erreichen kann ich benutzen?

Danke im voraus
Steven

[helge (Gast)]

Hi,

Warum hat eigendlich keiner den Betrag von Horst beachtet? Meiner 
Meinung nach, stellt er eine sehr durchdachte effektive Lösung dar. Bei 
mir entstand der Eindruck, das alles was von Benedikts Mainstream-Lösung 
abweicht, einfach ignoriert wird, auch - oder besonders - wenn es eine 
gute Idee ist.

[Benedikt K. (benedikt)]

helge wrote:
> Warum hat eigendlich keiner den Betrag von Horst beachtet?

Keine Ahnung. Anscheinend reden alle mit, aber wirklich nutzen tut 
niemand die Software.
Bei meiner RS232 Funkbrücke wollten alle eine Menü über das sich die 
Parameter einstellen lassen. Also habe ich diese eingebaut. Irgendwann 
habe ich festgestellt, dass diese einen größeren Bug hat, der eigentlich 
relativ schnell auffällt, wenn man die Software verwendet (die 
Einstellungen werden nicht gespeichert). Da sich aber bisher niemand 
beschwert hat, muss ich davon ausgehen, dass niemand die Software 
verwendet. Daher investiere ich dafür auch keine Zeit mehr.

[Christoph db1uq K. (christoph_kessler)]

Hallo Benedikt,

Ich habe mir vor kurzem ein RFM12 bei Pollin gekauft, und will mal 
versuchen es für 9600 Baud Packet-Radio zu benutzen. Ein Digipeater auf 
438,425MHz steht in Sichtweite, sodaß zu geringe Empfindlichkeit kein 
Problem sein dürfte. Die minimale Bandbreite von 64 kHz ist allerdings 
etwas breit. Auch der FSK-Frequenzhub ist etwas groß, läßt der sich 
einstellen?

Ist der analoge RSSI-Ausgang am RFM12 zugänglich? Die digitale RSSI gibt 
ja leider nur eine Schwellenüberschreitung aus, die man höchstens auf 
verschiedene Schwellen umschalten könnte. Laut Datenblatt müßte ein 1nF 
C am RSSI-Analoganschluß liegen.

Gibt es auch einen Händler für die 500mW-Version hierzulande, oder muß 
man die in Tschechien bestellen?

Anscheinend hat das Modul auch eine untere Grenzfrequnez für die 
Modulation, ich bin aus dem Datenblatt noch nicht recht schlau geworden.

[Benedikt K. (benedikt)]

Christoph Kessler wrote:
> Auch der FSK-Frequenzhub ist etwas groß, läßt der sich einstellen?

In 15kHz Schritten aufwärts.

> Ist der analoge RSSI-Ausgang am RFM12 zugänglich?

Ja, siehe Zeichnung.

> Anscheinend hat das Modul auch eine untere Grenzfrequnez für die
> Modulation, ich bin aus dem Datenblatt noch nicht recht schlau geworden.

Ja, scheint so zu sein. Ich hatte mit den analogen RSSI Ausgang mal 
versucht ein RFM12 als Spektrumanalyser für das 433MHz Band zu 
missbrauchen, dabei fiel mir auf, dass es etwas Ober und Unterhalb der 
eigentlichen Frequenz ein Signal am RSSI Pin erzeugt, nicht aber wenn 
man genau auf die Frequenz geht.

[Christoph db1uq K. (christoph_kessler)]

Ja genau die Idee hatte ich auch, einen einfachen Panaoramaempfänger. Es 
gibt wohl verschiedene Genarationen dieses Moduls, mal sehen ob meines 
auch an der Stelle einen C hat.

Das 500mW-Modul hatte ich über den Thread entdeckt:
Beitrag "Sammelbestellung bei tme.eu : RFM12 , 100nF 0805, Atmega88"
 Sammelbestellung bei tme.eu : RFM12 , 100nF 0805, Atmega88

[Christoph db1uq K. (christoph_kessler)]

Da steht was von 7 kHz Hochpass, ob das ein Schreibfehler ist?

Wieso haben die im Datenblatt das Ausschnitt-Drucken verhindert? Zum 
Glück gibts Ghostscript das sich um solche Feinheinten nicht kümmert.

[Dirk Schlage (Gast)]

Hallo,
ich habe jetzt versucht meine beiden Module RFM12 mit dem Code aus 
diesem Thread in Betrieb zu setzen. Auf den ersten Blick hat auch alles 
ganz toll ausgesehen. Jetzt habe ich aber festgestellt, daß mein 
rf12_ready nicht blockierend ist, so wie es eigentlich sein sollte. Wenn 
der Sender gar nicht engeschaltet ist, wird einfach von der 
Empfangsroutine 0xff in den Puffer eingetragen.
Ich habe schon die kleinen Verbesserungen am rf12_ready nachgetragen. 
Jetzt fällt mir nichts mehr ein.
Hat jemand einen Tip?

Dirk

[Vajk .. (vajk)]

Hat sich von euch schon jemand das Beispiel von Ulrich Radig
(http://ulrichradig.de/ -> arv -> usbfunk) angesehen ?

[Benedikt K. (benedikt)]

Dirk Schlage wrote:
> Jetzt habe ich aber festgestellt, daß mein
> rf12_ready nicht blockierend ist, so wie es eigentlich sein sollte. Wenn
> der Sender gar nicht engeschaltet ist, wird einfach von der
> Empfangsroutine 0xff in den Puffer eingetragen.

Hast du rf12_ready so angepasst ?

void rf12_ready(void)
{
  cbi(RF_PORT, CS);
  asm("nop");
  asm("nop");
  while (!(RF_PIN&(1<<SDO)));      // wait until FIFO ready
  sbi(RF_PORT, CS);
}

Das sollte funktionieren.

[Thorsten S. (whitenoise)]

Hallo,

ich habe noch eine kleine frage zur sendebereitschaft des moduls, im 
code von benedikt wird das modul immer im rx gehalten, will eines 
senden, wird es in den sendezusatnd gebracht, und die daten werden 
übertragen (den protokoll overhead/ sicherungsschicht mit 
richtungswechsel und bestätigung mal weggelassen).

ich hatte bei meiner funkstrecke das problem, das ich zu scheinbar zu 
schnell nach dem senden wieder in den rx zustand geschaltet habe, das 
modul sendete nicht richtig.

im code ist diese funktion dafür zuständig:
/*void rf12_rxmode(void)
{
  rf12_trans(0x82C8);                // RX on
  rf12_trans(0xCA81);                // set FIFO mode
  _delay_ms(.6);
  rf12_trans(0xCA83);                // enable FIFO: sync word search
  rf12_trans(0);                  // Status lesen um Bits zu löschen

}*/

im datenblatt ist gott sei dank das das modul diese zeit benötigt.

jetzt meine frage:

es gibt eine funktion:

static inline void rf12_ready(void)
{
  cbi(RF_PORT, CS);
  asm("nop");
  asm("nop");
  while (!(RF_PIN&(1<<SDO)));              sbi(RF_PORT, CS);
}

um die bereitschaft des moduls abzufragen, die scheint dies anhand des 
zustandes der sdo leitung zu machen, warum nicht anhand der statusbits, 
oder geht das nicht?

gruß,
whitenoise

[Benedikt K. (benedikt)]

White Noise wrote:
> es gibt eine funktion:
>
> static inline void rf12_ready(void)
> {
>   cbi(RF_PORT, CS);
>   asm("nop");
>   asm("nop");
>   while (!(RF_PIN&(1<<SDO)));              sbi(RF_PORT, CS);
> }
>
> um die bereitschaft des moduls abzufragen,

Die Fragt nicht ab, ob das Modul bereit ist zu senden/empfangen, sondern 
nur ob Platz im Sendepuffer ist bzw. ob Daten im Empfangspuffer sind.

> die scheint dies anhand des
> zustandes der sdo leitung zu machen, warum nicht anhand der statusbits,
> oder geht das nicht?

Das Statusbit wird über die SDO Leitung übertragen. Zufällig ist es 
genau das erste Bit, daher muss nicht das komplette Statusregister 
gelesen werden.

[Thorsten S. (whitenoise)]

danke - klar

[Wasweissich (Gast)]

@Benedikt
Ich möchte noch was wegen Deinem Post vom 14.05.2008 15:25 sagen.
Es tut mir leid, das Du da wenig Rückkoppelung bekommst.

Ich muss sagen, das ich mich für das Thema, auch die RS232 Brücke sehr 
interessiere. Leider trifft es in den Spezifikationen (Fehlerkorrektur 
usw.) nicht meine Vorstellungen.
Habe auch leider meine eigenen Bemühungen wegen anderer Projekte immer 
weiter verschieben müssen. Aber irgendwann wird Dich mal der Hammer 
treffen und einer wird sich wegen der Bugs beschweren. ;-)

Trotzdem lese ich immer wieder mit und bin oft erfreut wie geduldig und 
kompetent Du, nach so langer Zeit antwortest. Es ist wirklich immer 
wieder eine Freude von Dir zu lesen.

Bitte mach weiter so. Echt Klasse.

[Benedikt K. (benedikt)]

Falls du, (oder mal jemand anderst) eine ordentliche Fehlerkorrektur in 
die Funkübertragung einbaut, dann wäre es schön wenn er den Code mal 
veröffentlichen würde. Denn genau zu diesem Punkt findet man eigentlich 
rein garnichts im Internet. Ich hatte damals Tagelang nach verschiedenen 
Verfahren gesucht. Die waren alle entweder zu schlecht (Verhältnis 
Overhead zu erreichter Sicherheit zu schlecht) oder zu Rechenaufwendig 
(viel SRAM notwendig, und oft auch sehr rechenaufwendig).

[Wasweissich (Gast)]

>Die waren alle entweder zu schlecht (Verhältnis
>Overhead zu erreichter Sicherheit zu schlecht) oder zu Rechenaufwendig
>(viel SRAM notwendig, und oft auch sehr rechenaufwendig).

Ich kann das dann hier posten wenn es soweit ist.
Allerdings muss ich Dir rechtgeben, das es nicht einfach ist einen 
Kompromiss zwischen Nutzdatenrate, Sicherheit und Aufwand zu finden.
Dazu kommt noch das die Entfernung und die Funkemgebung starken Enfluss 
haben. Möglicherweise wird Dir meine Lösung auch nicht gefallen,
aber das werden wir ja dann sehen.