Forum: Mikrocontroller und Digitale Elektronik Mehrer RFM12 nutzen


von Christoph H. (webturtle)


Lesenswert?

Dank euren guten Tips hier im Forum habe ich ja nun meine Fernbedienung 
mit RFM12 fertig.
Weil das prima geht wollte ich es noch für ein zweites Projekt nutzen.
Das meiste vom Quelltext habe ich natürlich übernommen. Nun aber 
empfängt natürlich das RFM12 aus dem ersten Projekt auch alle Befehle 
aus dem zweiten Projekt.
Das ist nun erstmal nicht schlimm, aber auch nicht toll.

Da viel mir ein, dass ich ja immer über die Synchronpatterns gelesen 
habe bei den ursprünglichen Nachforschungen.
Das ist ja eigentlich genau was ich brauche. Also nochmal Datenblatt 
hergenommen.
Ich verstehe das so:

Mit 0xCA81 sage ich ja dem RFM dass es ein 2Bit Synchronpattern nutzen 
soll, den Puffer erst füllt wenn es dies empfangen hat und schalte 
diesen High Sensivity Reset ab.

Dannn lege ich mit 0xCED4 das Synchronpattern fest. Das ist ja auch die 
Standardeinstellung so.

Daher muss ich beim senden nach der Präambel erst 0x2D und dann 0xD4 
senden.

Das ist der Status quo.

Nun will ich z.B. als Synchronpattern 0xCE42 nutzen. Ich verstehe es so, 
dass die 2D fürs High Byte fest ist und das Low dann 0x42 ist.
Ich sende also Präambel, 0x2D und 0x42 und dann mein Paket.

Leider reagiert es dann nicht. Es reagiert noch immer wie am Anfang.

Daher muss wohl auf Empfängerseite was nicht richtig sein.

Hier mal mein Code, der Empängerinitialisierung
1
rf12_trans(0xC0E0);      // 10MHz
2
rf12_trans(0x80D7);      // FIFO verwenden
3
rf12_trans(0xC2AB);      // Data Filter: intern
4
rf12_trans(0xCE42);      // LSB im Sync Pattern: Standard D4, hier 42 ohne Erfolg
5
rf12_trans(0xCA81);      // FIFO modus: 2BitSync, NutzeSync, kein High Sens
6
rf12_trans(0xE000);      // Wakeuptimer aus
7
rf12_trans(0xC800);      // Low duty cycle aus
8
rf12_trans(0xC4F7);      // AFC settings: autotuning: -10kHz...+7,5kHz
9
10
rf12_trans(0x82C8);      // RX ein
11
rf12_trans(0xCA81);      // FIFO modus
12
rf12_trans(0xCA83);      // FIFO ein

Wird jemand schlau aus den Sync Pattern?

von Sebastian (Gast)


Lesenswert?

Kann man nicht einfach einen anderen Kanal nutzen?

von Christoph H. (webturtle)


Lesenswert?

Wäre ne alternative.
Aber dennoch, was wenn man nicht das Standardsync Pattern nutzen will, 
weil dies ja wahrscheinlich die meisten nutzen...

Es muss doch irgendwie mit dem Sync Pattern gehen.

von Christoph H. (webturtle)


Lesenswert?

Also ich hab jetzt den ganzen Tag nebenher gelesen und ich finde einfach 
nichts, was mir in meinem Ansatz einen Fehler aufzeigt.

Irgendwie müsste es einfach genau so funktionieren, wie ich es mache.

Niemand mehr ne Idee? Nutzt wirklich jeder die Standardeinstellung?

Chris

von Huch (Gast)


Lesenswert?

Es ist schon eine Weile her, dass ich das Datenblatt gelesen habe, aber:

Aus meiner Erinnerung und der allgemeinen Verwendung von Synchronmustern 
leite ich folgendes ab:

Das Synchronmuster dient dazu im Empfänger den Datentakt abzuleiten. 
Genau dazu und nicht mehr. Eine Adressierung von Empfängern soll das 
nicht leisten. Das empfangene Synchronwort wird nicht mit dem im 
Empfänger gespeicherten verglichen. Das wird wiederrum nur beim Senden 
verwendet.

Würde man dem Gedanken dennoch nähertreten, so würde dies im Empfänger 
erfordern die Flankenabstände zu speichern und nachträglich auszuwerten 
welche Daten tatsächlich gesendet wurden um die dann zu vergleichen.

Eine Möglichkeit ist, in Deinem Protokoll eine Adresse einzufügen. Dann 
empfangen immer noch alle Empfänger die Daten. Der angeschlossene uC 
muss dann entscheiden, ob die Nachricht für ihn bestimmt ist oder nicht.

von Christoph H. (webturtle)


Lesenswert?

Dann hab ich das mit dem Synchronmuster komplett falsch verstanden.
Ich hab das so interpretiert, dass der Fifo gefüllt wird, wenn das 2DD4 
(Standard) kommt.

Und damit dann der Empfang "richtig beginnt". Daher ist ja die Präambel 
und das High und Low Sync Byte nie in meinem Empfangspaket mit drin.
Auch der Empfanginterrupt wird dann ja erst getriggert, ich empfange 16 
Byte und sage dann dem Fifi er soll erneut auf das Synchron Byte warten.

Daher dachte ich darüber könnte ich adressieren.

Eine Frage bleibt allerdings: Warum empfängt er korrekt obwohl ich das 
Synchronbyte geändert habe....

Ich denke ich muss vorher einen Fehler haben und das wurmt mich 
irgendwie. Auch wenn ich es letztlich nicht dazu nutzen kann wie ich 
wollte.

Chris

von Huch (Gast)


Lesenswert?

>Ich hab das so interpretiert, dass der Fifo gefüllt wird, wenn das 2DD4
>(Standard) kommt.

Das schon, aber der Empfang des Musters bewirkt nur das der Abtasttakt 
für die nachfolgenden Daten bestimmt wird. Die genaue Form des 
Synchronmusters ist letztlich garnicht entscheidend. Es muss halt nur 
einige Bits im maximalen Takt enthalten.

Es gibt natürlich andererseits gewisse Zusammenhänge zwischen der 
genauen Form des Musters, seiner Länge und der Grenzen in denen der Takt 
im RFM12 variiert werden kann. Insofern ist meine Erklärung nicht ganz 
vollständig. Ich nehme z.B. an, das der Takt nicht verdoppelt oder 
halbiert werden kann. Um das zu testen könnte man ein Synchronmuster 
probieren, das keine einzelnen 0 oder 1 Bits enthält, sondern nur 
Vielfache von 2 oder 3 gleichen Bits enthält etc.
Das könntest Du mal ausprobieren, aber ich glaube nicht das es 
funktioniert. Es hätte jedenfalls zu Folge, das Du die Unterscheidung 
über die Datenrate machen müsstest. Die Sender müssten dann jeweils auch 
im halben oder drittel Takt die Bits im Sendepaket duplizieren 
(stopfen).

>Eine Frage bleibt allerdings: Warum empfängt er korrekt obwohl ich das
>Synchronbyte geändert habe....
Weil eben auch mit diesem Muster eine Synchronisation möglich ist. Es 
enthält einzelne Bits die Du im Nenntakt sendest. Damit ist im Empfänger 
eine Synchronisation auch auf dieses Muster möglich.

Du musst halt im Auge behalten das es hier nur um die 
Taktsynchronisation geht. Nicht um den Inhalt des Synchronmusters. Wie 
schon beschrieben, würde das ja erforderlich machen, die Zeitabstände zu 
speichern und sie nachträglich zu bewerten um auch den Dateninhalt zu 
ermitteln wobei dann auch noch die Relation zwischen Anfangstakt und 
Ergebnistakt berücksichtigt werden müsste. Das wäre aber ein ziemlicher 
Aufwand.

Über ein zusätzliches Adressbyte ist das Problem ohnehin ganz einfach zu 
lösen.

von Holger S. (holli_1)


Lesenswert?

Christoph Hoell schrieb:
> Mit 0xCA81 sage ich ja dem RFM dass es ein 2Bit Synchronpattern nutzen
> soll, den Puffer erst füllt wenn es dies empfangen hat und schalte
> diesen High Sensivity Reset ab.

Nein, 0xca81 bedeutet 8 bit FIFO, FIFO deaktiviert, high sens. Reset 
deaktiviert. 0xCA83 aktiviert den FIFO. Danach erst ist die Erkennung 
des Sync-Wortes wieder aktiv. Nach dem Empfang eines Datenpaketes muss 
die Sync-Erkennung wieder neu aktiviert werden, mit 0xCA81 und danach 
0xCA83.

Die Änderung des Sync-Wortes sollte funktionieren, allerdings nur mit 
einem RFM12B !! Der RFM12 hat diese Möglichkeit nicht, da geht nur 0x2D 
0xD4.

Das von Huch geschriebene stimmt nicht. Das Sync-Wort dient zur 
Freischaltung des FIFO, zur Synchronisation gibt es die Präambel 0xAA.

von Huch (Gast)


Lesenswert?

>Das von Huch geschriebene stimmt nicht. Das Sync-Wort dient zur
>Freischaltung des FIFO, zur Synchronisation gibt es die Präambel 0xAA.

Es ging hier im Thread um die Taktsynchronisation von Sender um 
Empfänger mit dem Mittel des Synchronwortes. Die Freischaltung ist nicht 
unmittelbar Folge des Empfanges des Synchronwortes und kann es auch 
nicht sein, denn der korrekte Empfang des Synchronwortes würde ja schon 
die Synchronizität des Taktes voraussetzen, sondern eben der 
erfolgreichen Synchronisation.

Das zusätzlich zu den Synchronworten noch eine Präamble zur 
Synchronisation eines Datenpaketes dient ist sicher richtig.
Aber das war garnicht das Thema und würde überdies meiner Aussage nicht 
widersprechen.

von Christoph H. (webturtle)


Lesenswert?

Ich denke ich habe es verstanden. Sicher bin ich mir nicht, aber 
zumindest soweit, dass ich das Synchronpattern wohl nicht als Adresse 
benutzen kann.

Also mach ichs wie oben empfohlen mit einem Adressbyte.

Danke für die Erläuterungen.

Chris

von Huch (Gast)


Lesenswert?

Anders ausgedrückt:

Es macht nur dann Sinn den Fifo zu aktivieren, wenn Sender und Empfänger 
synchron sind. Das Synchronmuster dient zur synchronisierung und nicht 
zur Freischaltung des Fifo.

Die Vorbedingung zur Freischaltung ist eben genau die Synchronizität. 
Insofern ist das Senden des Synchronmuster nicht unmittelbar die 
Vorbedingung für das Freischalten des Fifo. Das ist eine mittelbare 
Konsequenz.

von Holger S. (holli_1)


Lesenswert?

Huch schrieb:
> Es macht nur dann Sinn den Fifo zu aktivieren, wenn Sender und Empfänger
> synchron sind. Das Synchronmuster dient zur synchronisierung und nicht
> zur Freischaltung des Fifo.
>
> Die Vorbedingung zur Freischaltung ist eben genau die Synchronizität.
> Insofern ist das Senden des Synchronmuster nicht unmittelbar die
> Vorbedingung für das Freischalten des Fifo. Das ist eine mittelbare
> Konsequenz.

Nur leider kompletter Unsinn. Du solltest dir die Datenblätter mal genau 
durchlesen. Wie du selbst schreibst ist das schon eine Weile her. Das 
sieht man hier.

von Huch (Gast)


Lesenswert?

>Nur leider kompletter Unsinn. Du solltest dir die Datenblätter mal genau
>durchlesen. Wie du selbst schreibst ist das schon eine Weile her. Das
>sieht man hier.

Möglicherweise irre ich mich wirklich. Ich wünschte aber Du würdest Dich 
etwas feinfühliger ausdrücken. Jedenfalls werde ich mal nachschauen.

von Michael U. (amiga)


Lesenswert?

Hallo,

Huch schrieb:
>>Das von Huch geschriebene stimmt nicht. Das Sync-Wort dient zur
>>Freischaltung des FIFO, zur Synchronisation gibt es die Präambel 0xAA.
>
> Es ging hier im Thread um die Taktsynchronisation von Sender um
> Empfänger mit dem Mittel des Synchronwortes. Die Freischaltung ist nicht
> unmittelbar Folge des Empfanges des Synchronwortes und kann es auch
> nicht sein, denn der korrekte Empfang des Synchronwortes würde ja schon
> die Synchronizität des Taktes voraussetzen, sondern eben der
> erfolgreichen Synchronisation.
>
> Das zusätzlich zu den Synchronworten noch eine Präamble zur
> Synchronisation eines Datenpaketes dient ist sicher richtig.
> Aber das war garnicht das Thema und würde überdies meiner Aussage nicht
> widersprechen.

Du liegst komplett falsch...
Die 0xAA (0x55 würde auch gehen, es ist eben nur eine 0101... Folge 
beliebiger Länge) geben dem Empfänger erstmal zeit, damit ADC/AFc 
einschwingen können.zusätzlich wird die Bittakt-PLL syncronisiert.
Die empfangenen Bits werden zum Syncword-Comparator durchgereicht. Das 
ist letztlich nur ein 16Bit-Schieberegister, wo die ankommenden Bits 
durchgeschoben werden. Ein Byteanfang ist ja zu dieser Zeit noch nicht 
bekannt.
Wenn an den Ausgängen des Schieberegisters die Sycpattern anliegen, ist 
der Byteanfang erkannt und die folgenden Bits werden in den FIFO 
geschoben.

Ab diesem Zeitpunkt können beliebige Daten folgen, auch 0xAAoder das 
Syncpattern. Die Patternlogik wird erst wieder aktiv, wenn der FIFO aus- 
und wieder eingeschaltet wird.

Beim RFM12 ist meines Wissens das Syncpattern nicht änderbar.

PA: ich würde einfach in den Daten am Anfang eine Systemnummer schicken 
und in der Empfangsroutine nur die Daten wieter verwenden, die für mich 
sind...

Gruß aus Berlin
Michael

von Huch (Gast)


Lesenswert?

>Du liegst komplett falsch...

Hm. Das scheint tatsächlich im Datenblatt missverständlich ausgedrückt 
zu sein. Mit dem Synchronmuster scheint hier keines zum Zwecke der 
Taktsynchronisation sondern zur Protokollsynchronisation gemeint zu 
sein.

Im Datenblatt von Hope steht bei der Beschreibung des Kommandos CA80, 
das das Synchronmuster 2DD4 ist. Dann wird aber gesagt, das der Fifo 
nach Empfang dieses Musters freigeschaltet wird. Das auf dieses Muster 
synchronisiert wird ist nirgendwo beschrieben. Dafür aber unter dem 
Kommando B8xx das das Senderegister mit AA gefüllt ist.

>Beim RFM12 ist meines Wissens das Syncpattern nicht änderbar.
Das oben genannte CED4 Kommando kann ich auch nicht finden.

Hmm. Ich habe leider nur die Datenblätter von Hope und von Integration.
Gibt es noch andere?

von Huch (Gast)


Lesenswert?

Jedenfalls wird der Takt nicht, wie ich ursprünglich meinte auf das 2DD4 
synchronisiert sondern wohl auf das anfängliche AA. Insofern habe ich 
was Falsches erzählt.

Danke für den Hinweis Holger.

Der eigentliche Grund warum das vom TO angedachte nicht geht, ist dann 
wohl, dass das Muster nicht zu ändern ist. Oder kannst Du mal schreiben, 
Christoph, wo Du das Kommando CED4 gelesen hast?

von Matthias S. (mat-sche)


Lesenswert?

Hi,

soviel zum Fachgesimpelllll.

Ich würde Dir vorschlagen ein Übertragungsprotokoll zu nehmen, in dem 
auf verschiedenster Weise Anweisungen/Informationen übertragen werden. 
So kannst Du zum Bsp. Adressen vergeben. Weiterhin kannst Du zu jeder 
Zeit den Kanal wechseln. Schau Dir mal das SNAP-Protokoll an.

MAT

von Holger S. (holli_1)


Lesenswert?

So, ich habe es gerade mal getestet. Mit einem RFM12B als Empfänger 
funktioniert es, wenn ich das 2. Sync-Byte mit 0xCE4E ändere. Ich sende 
mit einem RFM12, empfange mit einem RFM12B. Das komplette Sync-Wort ist 
jetzt 0x2d4e, mit 0x2dd4 bleibt der Empfänger still.

Wie gesagt, es funktioniert NUR mit einem RFM12B als Empfänger!

von Huch (Gast)


Lesenswert?

Super.
Falls der TO ein RFM12B und nicht das RFM12 hat, sollte es also gehen.

von Christoph H. (webturtle)


Lesenswert?

Ich habe den Befehl aus dem Artikel hier auf mikrocontroller.net
Ich Glaube im pollin Datenblatt steht er auch. Es stimmt aber dass er in 
manchen der original datenblätter nicht auftaucht.

Ich hab es jetzt mit der Adresse implementiert und es geht auch. Der 
Grund warum ich es über das syncpattern wollte war eigentlich nur um dem 
Prozessor Arbeit zu sparen. Denn wenn ja "sein" rfm gar nicht anschlägt, 
braucht er auch nix auszuwerten.

Vielleicht nehme ich in Zukunft die b Version. Oder für die vielen 
Schalter gar die reinen Sender. Aber preislich nimmt es sich nicht viel.

von Huch (Gast)


Lesenswert?

Schön das es funktioniert. Tut mir leid, das ich am Anfang was falsches 
erzählt habe.

Verzeih bitte aber bist Du ganz sicher, dass Du einen RFM12 und nicht 
einen RFM12B hast?

>Es stimmt aber dass er in manchen der original datenblätter nicht auftaucht.
Könntest Du bitte mal einen Link auf das Datenblatt posten. Ich habe nur 
solche vom B gefunden, in denen der Befehl dokumentiert ist.
Das wäre nett.

von Christoph H. (webturtle)


Lesenswert?

Ich habe nicht den B was wohl der Grund ist warum es nicht geht.
Den Befehl fand ich hier auf der Seite. Bei Artikeln nach rfm12 suchen.
Bei den datenblättern muss ich erst wieder genau schauen, weil ich 
wahrscheinlich alle Jan die es je gab. Ich hab die Teile ja nicht ins 
laufen bekommen un ewig gesucht und gelesen bis mir hier geholfen wurde.

Ich finde diesen Theras trotzdem ganz nützlich für die Nachwelt.

von Christoph H. (webturtle)


Lesenswert?

Ich hab jetzt nochmal nachgesehen.
Es ist also definitiv so, dass der Befehl nur auf in den Datenblättern 
des B Modell auftaucht.
Ich hab mich da wohl von der Webseite verleiten lassen.

Die Frage ist allerdings ob ich nicht in Zukunft das B nehme. Ist auch 
billiger.
Die Sender sind nachher sowieso Batteriebetrieben. Allerdings frage ich 
mich grad wie ich das beim Programmieren mit der niedrigen 
Versorgungsspannung mache.

Chris

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.