RFM12 - Reale Sendefrequenz

[Tobias F. (colonel2601)]

Hallo,
hat hier schon mal jemand bei den beliebten RFM12-Modulen die reale 
Sendefrequenz ermittelt?
Ich habe mehrere Module der 868-MHz-Variante, die sich alle gleich 
verhalten.

Wenn ich das Freq-Kommando 0xA320 zum RFM12 sende, sollte doch die 
Frequenz 864.000 MHz eingestellt werden (nach der Formel aus dem 
RF12-Datenblatt f = 10*C1*(C2+F/4000), F= 320h = 800dez). Mit meinem 
Spectrum Analyzer messe ich aber eine Frequenz bei 860.000 MHz (siehe 
Screenshot im Anhang, Center-Freq des Analyzers auf 860MHz, Span auf 
10MHz, im Zero-Span-Modus finde ich die gleiche Signalhöhe bei 860MHz, 
und deutlich weniger bei 864MHz).

Der Spectrum Analyzer HM5014-2 ist nicht kalibriert, die 
(Un-)Genauigkeit inkl. Alterungsdrift sollte bei ein paar ppm liegen, 
also nicht im MHz-Bereich. EinsLive wird übrigens korrekt bei 105.5MHz 
angezeigt, aber das ist ja leider keine Aussage für den höheren 
Frequenzbereich des Analyzers ;-)

Einer macht hier also Murks, entweder die RFM-Module oder der Analyzer, 
ich kann nur nicht herausfinden, wer das ist.

Daher meine Frage: Wie sind eure Erfahrungen mit den RFM12-Modulen? Das 
sie untereinander funktionieren, steht ja außer Frage. Aber wie sieht's 
in Kombination mit anderer HW aus? Habt ihr schon mal Messungen der 
Center-Freq. durchgeführt?

Gruß,
colonel2601

[Holger S. (holli_1)]

Schon mal an die FSK-Modulation gedacht?

[Jupp (Gast)]

Also ich lese da 864MHz ab, Wie kommst Du auf 860MHz Sendefrequenz?

[Tobias F. (colonel2601)]

Jo, danke erstmal für die schnellen Antworten.

@Holger: Ja, habe ich, aber die FSK-Modulation ist auf +/-45kHz 
eingestellt, die wird man auf dem Bild vermutlich nur mit Phantasie 
erkennen können, da der "Frequenzbuckel" genau in der Mitte eine 
Absenkung aufweist, die Maxima liegen leicht rechts und links der 
Center-Freq.

@Jupp: Mache ich was falsch? Die Center-Freq. des Spectrum-Analysers ist 
auf 860 MHz eingestellt, der Span auf 10MHz, ergo wird auf dem 
Bildschirm doch der Bereich von 855 .. 865 MHz dargestellt, und das 
Signalmaximum liegt doch ziemlich exakt in der Mitte, geschätzt 0.2MHz 
daneben, also ganz genau gemessen bei 860.2 MHz, oder? Das würde ich ja 
noch als Abweichung durchgehen lassen, aber nicht die 4 MHz zu den 
eingestellten 864MHz...

Grüße, und weiter ratlos,
Tobias

[Tobias F. (colonel2601)]

Desweiteren:
- Das Signal kommt wirklich von meinem Sender. Schalte ich diesen aus, 
so zeigt der Spectrum Analyzer nur noch Grundrauschen an. Ich habe den 
Test gemacht, um sicherzugehen, dass ich nicht irgendeinem Fremdsender 
hinterherjage...
- Die Kommunikation mit dem RFM12-Modul läuft über Hardware-SPI eines 
Atmel ATXMEGA32, z.B. das Kommando zum Setzen unterschiedlicher 
Taktteilerfaktoren (1.0MHz, 2.0MHz, 2.5MHz) funktioniert problemlos.
- Setze ich die Frequenz auf 864 MHz (Kommando A320), messe ich ca. 860 
MHz. Setze ich die Frequenz auf 868 MHz (Kommando A640), so messe ich 
ca. 865 MHz. Der Frequenzoffset zwischen gesetzter und gemessener Freq. 
ist also nicht konstant.
- Die Änderung der Lastkapazität für den 10 MHz Quarz von Minimum 
(8.5pF) auf Maximum (16.0pF) erzeugte keine(!) Änderung in der 
Sendefrequenz. Sollte sich die TX-Frequenz nicht ändern, wenn ich die 
Lastkapazität des Quarzoszillators ändere, da die TX-Frequenz über eine 
PLL aus dem Quarztakt generiert wird? Oder ist der Oszillator so stabil?

Noch ratloser,
Tobias (und nun gute Nacht ;-)

[Holger S. (holli_1)]

Ich habe letztens mal einen RFM12 gemessen, allerdings statisch d.h. 
Sender eingeschaltet und dann am FSK-Pin gewackelt. Da konnte man schön 
die Änderung der Frequenz durch die FSK-Modulation sehen. Die 
Mittenfrequenz war genau wo sie sein sollte. Schon mal ein anderes Modul 
getestet oder die Quarzfrequenz gemessen? Oder ist eine andere Referenz 
für den Spektrumanalysator zum Vergleichen verfügbar?

[Adi (Gast)]

Ein einfacher Test um rauszufinden ob dein Speci die Frequenz richtig 
anzeigt wäre folgender:
Nimm die Funkfernbedienung deines Autos - die arbeitet ziemlich 
wahrscheinlich auf 433,92MHz (zumindest war das bislang bei allen 
Funkschlüsseln so, die ich vermessen habe - die Frequenz lässt sich 
ansonsten aber bestimmt googlen). Stell den Speci auf diese Frequenz und 
drücke den Knopf (sicherheitshalber den für Versperren, nicht dass du 
den Wagen unbemerkt aufsperrst und dir die Jungs in Schwarz das Navi 
klauen ;-)). Und dann siehst du ja, ob dein Speci dir die Wahrheit sagt 
:-)


Die etwas aufwändigere Variante - bzw die Grundidee von Holger:
Laut RFM12 Datasheet kann das TRX Modul auch einen Clock ausgeben (ich 
nehme an dass du da auch 10MHz rausbekommst). Ich würde mal versuchen 
diese 10MHz dem Spectrum Analyzer als externe Referenz anzubieten 
(eventuell musst du das Signal dazu etwas aufbereiten).

Viel Erfolg
Adi

[Holger S. (holli_1)]

Ich habe aus Spaß mal mit einem HMO1024 Oszi am RFM12 gemessen. Und es 
zeigt sogar etwas an. Eingestellt auf 435 MHz und 240 kHz FSK, mit 
FSK-Pin einmal auf low und high. Wie man sieht ist alles da wo es sein 
soll.

[Franzl F. (Firma: Elektroniker) (franzl-f)]

Tobias Franke schrieb:
> Die Kommunikation mit dem RFM12-Modul läuft über Hardware-SPI eines
> Atmel ATXMEGA32

Können die ATXmega jetzt 16Bit SPI? SPI Takt zu hoch? Funktioniert das 
Empfangen mit einem RFM12 Einwandfrei?

[Tobias F. (colonel2601)]

Hi, und danke für die Tipps.

@Adi:
Ich habe das ganze Haus nach einem passenden Sender durchsucht, irgendwo 
im höheren 100er-MHz-Band, aber keinen mit genau bekannter Frequenz 
gefunden. Einfach zu kompliziert gedacht.
Mein Opel-Schlüssel sendet auf 433.92MHz, was auch der Spectrum Analyzer 
genau anzeigt. Demnach ist der Analyzer in Ordnung, und meine Module 
senden auf der falschen Frequenz Mist

@Holger:
Danke für die Screenshots, die Aufnahmen sind wirklich sehr deutlich, 
das Modul macht zumindest, was es soll.

@Franzl:
Nein, auch die ATXMega machen nur 8-Bit-SPI. Ich sende erst das 
High-Byte, dann das Low-Byte. Da ich den Chip-Select manuell vorher und 
nachher schalte, sollte das gehen. Weil ich die Ausgangsfrequenz des 
CLK-Pins umschalten kann (getestet: 1MHz, 2MHz, 2.5MHz), bin ich davon 
ausgegangen, dass sowohl das Kommando als auch die Parameter korrekt 
übertragen werden. Aber ich werd's mir gleich nochmal auf dem Oszi 
ansehen.
Den Empfang habe ich noch nicht getestet, da habe ich das 
Henne-Ei-Problem. Ich wollte erstmal sichergehen, dass der Sender das 
macht, was er soll...

Da zwischen den Freq.-Einstellungen (864 & 868 MHz) und den Messungen 
(860 & 865MHz) kein linear steigender Zusammenhang besteht, gehe ich 
weder von einem Berechnungsfehler noch einem Quarz- oder PLL-Problem 
aus, evtl. ist wirklich die SPI-Übertragung nicht ganz korrekt...

Ich geh' jetzt mal messen...

[Simon K. (simon)]

Wie sieht denn deine Berechnung in Software aus? Möglicherweise ein 
Rundungsfehler oder sogar Ungenauigkeit durch Verwendung von 
Gleitkomma-Datentypen.

[Tobias F. (colonel2601)]

Hi Simon,
ich berechne nicht in SW, ich gebe Konstanten über SPI an das 
RFM12-Modul. Die Formel lautet vereinfacht (mit C1=2 und C2=43 schon 
eingesetzt): f=860+F/200. F ist die Konstante, die ich per Kommando 
vorgeben, entweder 800 oder 1600, das ergibt f (in MHz) von 864 MHz bzw. 
868 MHz (bzw. sollte es ergeben ;-)

Hardware-SPI war im ATXMega auf 1MHz Taktfrequenz eingestellt, die Daten 
wurden bei der fallenden Flanke ausgegeben, weil der RF12 diese bei der 
steigenden einsychronisiert. Zig µs vorher wurde nCS auf low gezogen, 
später wieder auf high. Aufgrund der 2 8-Bit-SPI-Transfers (und meinem 
aktuellen bescheidenen Takt von 1MHz) gab es ein langes Gap zwischen dem 
MSB und dem LSB des 16-Bit-Transfers. Außerdem war der Clock am Anfang 
und am Ende high, das ergab sich aus dem HW-SPI, da ja bei der fallenden 
Flanke die Daten generiert werden sollen, deshalb fängt er mit der 
fallenden Flanke an und hört mit der steigenden Flanke auf. Da Setup- 
und Hold-Zeiten im Datenblatt nur auf die steigende Flanke bezogen 
waren, habe ich mir nichts dabei gedacht.

Naja, ich hab's jetzt mal auf SW-SPI umgestrickt, Freq. jetzt nur noch 
30kHz, das sollte wohl zu schaffen sein, mit CLK am Anfang und Ende low. 
Wenn morgen der Spectrum Analyzer noch nicht zur Reparatur ist (nur 
mechanisch ;-), werde ich's in der Firma nochmal nachmessen. Die 
Ausgangsfrequenz von CLK lässt sich zumindest wie gewohnt einstellen.

[Jörg W. (dl8dtl) (Moderator)]

Tobias Franke schrieb:
> Da ich den Chip-Select manuell vorher und
> nachher schalte, sollte das gehen.

Das ist bei SPI immer so.  Insofern gibt's auch nie ein Problem
mit 16-bit-SPI.

[Tobias F. (colonel2601)]

Hallo,
erstmal D A N K E !!!

Die Umstellung auf Software-SPI hat's gebracht, die Frequenzen liegen 
nun genau da, wo sie sein sollen (siehe Screenshots).
Woran es nun genau liegt, kann ich noch nicht sagen, ich werde noch ein 
bißchen testen, um es herauszufinden, aber es funktioniert schon mal 
**freu**
Dann muß ich doch nicht alle Module von meinen Boards herunterreißen...

Grüße,
Tobias

[Tobias F. (colonel2601)]

Na, und schon gefunden.

Wenn ich bei meinem Software-SPI nach dem 16ten Bit den CLK auf high 
stehen lasse, dann wird die falsche Frequenz eingestellt.
Setze ich dagegen CLK am Ende auf low, bevor nSEL wieder auf high 
gesetzt wird, so wird die korrekte Frequenz erzeugt.

Seltsam ist nur, dass der Kommando-Code (also die MSBits) in beiden 
Fällen richtig erkannt wird, die Frequenz wird ja in beiden Fällen 
geändert. Und das ich mit beiden Varianten den Ausgangstakt auf 1MHz, 
2MHz usw. korrekt setzen kann.

Evtl. hat die interne PLL ein Schieberegister, welches noch die fallende 
CLK-Flanke braucht, um die Daten zu übernehmen, während die anderen 
Konfigurationsregister diese nicht benötigen.

Also, nochmal besten Dank an alle, die mir nützliche Anregungen gegeben 
haben. Das Problem sehe ich hiermit als gelöst an ;-)

[Simon K. (simon)]

Ich würde einfach mal darauf tippen, dass du den falschen SPI Mode 
benutzt (hast).

[Malte _. (malte)]

Tobias F. schrieb:
> Wenn ich bei meinem Software-SPI nach dem 16ten Bit den CLK auf high
> stehen lasse, dann wird die falsche Frequenz eingestellt.
> Setze ich dagegen CLK am Ende auf low, bevor nSEL wieder auf high
> gesetzt wird, so wird die korrekte Frequenz erzeugt.

Danke! Der Hinweis auf die Verwendung von Software statt Hardware und 
die extra Wartezeit am Ende hat auch bei mir den RFM12 endlich zum 
funktionieren gebracht.

Falls noch jemand beim Suchen nach einer Lösung über diesen Thread 
stolpern sollte:

//on PORTC:
#define RFM12_NINT 3
#define RFM12_SELECT 4
#define RFM12_MOSI 5
#define RFM12_MISO 6
#define RFM12_CLK 7
#define RFM12_RESET 5
//on PORTB:
#define RFM12_NIRQ 1

#if 0
//user hardware (not working)
uint16_t rfm12_command(uint16_t data) {
  uint16_t indata;
  PR_PRPC &= ~PR_SPI_bm;
  PORTC.OUTCLR = (1<<RFM12_SELECT);
  PORTC.PIN6CTRL = PORT_OPC_TOTEM_gc; //now the RFM12 drives the pin
  SPIC.CTRL = SPI_ENABLE_bm | SPI_MASTER_bm | SPI_MODE_0_gc | SPI_PRESCALER_DIV4_gc;
  SPIC.INTCTRL = SPI_INTLVL_OFF_gc;
  //Reading status + reading data = clear status bits
  SPIC.STATUS;
  SPIC.DATA;
  //shift out data
  SPIC.DATA = data >> 8;
  while (!SPIC.STATUS); //wait for shift of first byte
  indata = SPIC.DATA << 8;
  SPIC.DATA = data && 0xFF;
  while (!SPIC.STATUS); //wait for shift of second byte
  indata |= SPIC.DATA;
  PORTC.OUTSET = (1<<RFM12_SELECT);
  PORTC.PIN6CTRL = PORT_OPC_PULLUP_gc; //RFM12 is high impedance again
  //PR_PRPC |= PR_SPI_bm;
  return indata;
}
#else
//use software (working)
uint16_t rfm12_command(uint16_t outdata) {
  uint16_t indata = 0;
  PORTC.OUTCLR = (1<<RFM12_CLK);
  PORTC.OUTCLR = (1<<RFM12_SELECT);
  PORTC.PIN6CTRL = PORT_OPC_TOTEM_gc; //now the RFM12 drives the pin
  //shift out and get data
  uint8_t i;
  /* The RFM12 samples the pin on the rising clock edge and changes the
     Pin on the falling clock edge. The first bit is there before any clock.
  */
  for (i = 0; i < 16; i++) {
    indata <<= 1;
    //write data
    if (outdata & 0x8000) {
      PORTC.OUTSET = (1<<RFM12_MOSI);
    } else {
      PORTC.OUTCLR = (1<<RFM12_MOSI);
    }
    _delay_us(2.0);
    //rise clock
    PORTC.OUTSET = (1<<RFM12_CLK);
    //read data
    if (PORTC.IN & (1<<RFM12_MISO)) {
      indata |= 1;
    }
    _delay_us(2.0);
    //clock to low
    PORTC.OUTCLR = (1<<RFM12_CLK);
    outdata <<= 1;
  }
  _delay_us(2.0); //give some time to the RFM12 for sampling
  PORTC.OUTSET = (1<<RFM12_SELECT);
  PORTC.PIN6CTRL = PORT_OPC_PULLUP_gc; //RFM12 pin is high impedance again
  return indata;
}
#endif

[Michael U. (amiga)]

Hallo,

ich kann mich erinnern, daß meine RFM-Module alle mit Software-SPI 
laufen, weil es damals (2009) irgendwelche Probleme mit dem Timings des 
Hardware-SPI und den RFM-Modulen gab.

Weil Software-SPI lief habe ich es bis heute so weiter verwendet...

Gruß aus Berlin
Michael

[Tobias F. (colonel2601)]

Hey, freut mich, dass der 5 Jahre alte Thread noch gefunden wurde und 
geholfen hat.

Grüße,
Tobias