Kompatibelität CC1100 und RFM12

[oldies (Gast)]

Hallo,
kennt sich irgendjemand von euch mit dem CC1100 von TI aus?
Versuche schon seit tagen ihn zu überreden mit dem Pollin-Funkmodul 
RFM12 zu reden.
Ist das überhaupt möglich??

Das Funkmodul RFM12 ist wie folgt initialisiert (bis auf die Frequenz 
aus den Beispielen übernommen):

  rf12_setfreq(RF12FREQ(433.25));      // Sende/Empfangsfrequenz auf 433,25MHz einstellen
  rf12_setbandwidth(RxBW200, LNA_6, RSSI_79);  // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf12_setbaud(19200);        // 19200 baud
  rf12_setpower(PWRdB_0, TxBW120);    // 1mW Ausgangangsleistung, 120kHz Frequenzshift

Es empfängt auch brav Daten von einem anderen RFM12.

Die Konfiguration des CC1100 sieht wie folgt aus:

  0x29,  // IOCFG2
  0x2E,  // IOCFG1
  0x06,  // IOCFG0
  0x47,  // FIFOTHR
  0x2D,  // SYNC1
  0xD4,  // SYNC0
  0x3E,  // PKTLEN
  0x1A,  // PKTCTRL1
  0x45,  // PKTCTRL0
  0x01,  // ADDR
  0x00,  // CHANNR
  0x06,  // FSCTRL1
  0x00,  // FSCTRL0
  0x10,  // FREQ2    #
  0x0B,  // FREQ1    #
  0xDA,  // FREQ0    # -> 433,249969 MHz
  0x49,  // MDMCFG4 
  0x75,  // MDMCFG3 
  0x02,  // MDMCFG2 
  0x32,  // MDMCFG1
  0xC1,  // MDMCFG0  CHANSPC_M
  0x35,  // DEVIATN
  0x04,  // MCSM2
  0x0C,  // MCSM1 0c
  0x38,  // MCSM0
  0x16,  // FOCCFG
  0x6C,  // BSCFG
  0x43,  // AGCCTRL2
  0x40,  // AGCCTRL1
  0x91,  // AGCCTRL0
  0x46,  // WOREVT1
  0x50,  // WOREVT0
  0x78,  // WORCTRL
  0x56,  // FREND1
  0x10,  // FREND0
  0xA9,  // FSCAL3
  0x0A,  // FSCAL2
  0x00,  // FSCAL1
  0x11,  // FSCAL0
  0x41,  // RCCTRL1
  0x00,  // RCCTRL0
  0x57,  // FSTEST
  0x7F,  // PTEST
  0x3F,  // AGCTEST
  0x98,  // TEST2
  0x31,  // TEST1
  0x0B  // TEST0

Das Sync-Word ist auf das vom RFM12 eingestellt; Modulation 2-FSK; Baud 
19200 [lt. RFStudio]. Das RFM12 erkennt es auch, nur die anschließend 
kommt nur Datenmüll an, nichts verwertbares.

Kann mir evtl. jemand von euch bei diesem Problem helfen??

MfG

[oldies (Gast)]

Nachtrag:
zum Senden verwende ich folgenden Code (teils aus boop-firmware):

void switch_to_idle() {
  cc1100_strobe(SIDLE);
  while (cc1100_read1(MARCSTATE) != 01);
}

// write length bytes of data to addr in CC1100
unsigned char cc1100_write(unsigned char addr,unsigned char* data, unsigned char length) {

  unsigned short i;
  unsigned char status;
  unsigned char x;
  
  FIOCLR0 = CS1;
  while (FIOPIN0 & MISO1);
  SSPDR = (addr | WRITE);
  while ((SSPSR & (1<<4)));
  status = SSPDR;
  for (i=0; i < length; i++) {
    SSPDR = data[i];
    while ((SSPSR & (1<<4)));
    x=SSPDR;
  }
  FIOSET0 = CS1;
  
  return(status);
}
// write on byte of data to addr in CC1100
// a few instructions faster than cc1100_write(addr, data, 1)
unsigned char cc1100_write1(unsigned char addr,unsigned char data) {

  unsigned char status;
  unsigned char x;
  
  FIOCLR0 = CS1;
  while (FIOPIN0 & MISO1);
  SSPDR = (addr | WRITE);
  while ((SSPSR & (1<<4)));
  status = SSPDR;
  
  SSPDR = data;
  while ((SSPSR & (1<<4)));
  x=SSPDR;
  
  FIOSET0 = CS1;
  
  return(status);
}
unsigned char cc1100_strobe(unsigned char cmd) {

  unsigned short status;
  
  FIOCLR0 = CS1;
  while (FIOPIN0 & MISO1);
  SSPDR = cmd;
  while ((SSPSR & (1<<4)));
  status = SSPDR;
  FIOSET0 = CS1;
  
  return(status);
}

/* Send the contents of buffer b over radio 
  b must be less than 62 characters
  Blocks until radio is idle.
  A EOT (0x04) is appended to the packet.
*/
void RF_send(unsigned char* b, int payload_cnt) {
  
  switch_to_idle();
  cc1100_strobe(SFTX);
  cc1100_strobe(SCAL);
  cc1100_write1(TX_fifo, payload_cnt+2);
  cc1100_write1(TX_fifo, 1);
  cc1100_write(TX_fifo | BURST, b, payload_cnt);
  cc1100_write1(TX_fifo, 0x04);
  
  cc1100_strobe(STX);
}

gesendet wird folgendes:

 unsigned char* buf = "Dies ist ein Test!!!"; 
RF_send(buf, 20) ;

leider sieht der Empfang (Sync wird wohl erkannt, da die Daten in den 
Fifo geladen werden) alles andere als schön aus - und leider auch nicht 
immer gleich; Hier mal die Aufzeichnung von dem, was der RFM12 über SPI 
beim senden des CC1100 (s.o.) von sich gibt:

1.

E0167CE21FE134D8C877C8B839F8BBAE8C61CA9F8A30B27C906820860DC0100C8014874001C00080041040098E00400700030100C066904006004000840140030002678021804E07038A6001869020460411C0280C84110840004C0A802500800048000DC0A0208020008003900000C01E2A4C80100F00024353060A05CC3309882208C0000606CC86CC6C0008000088300080420001404E1C0C08004C05020440C00204C0008E864000469802001500480403C8708810827F06400EC040010082F40C00C00403C4090000000101C00088800015807F8EC640518C18823239080058000E05C0812896

2.

E0167CF08F611A6CC83BC8B839F8BBAE8C43CA90F134C265F221A0700002F060401A8800424FC2C8000780024B400044038C5F8008841FEC100FD80D0006080188010001038C4502C00C0184C0028000C833438209C08780800B06000792FA02D0080F604201000400004080400000C8704040028828420100018002018646000041C4224105010500800601C011C810C000004303C00E8C010E807000C80C03018000844100000CC44A0C84230002408C1080000088044000807FC40788004800490400CA050584C80008C000000380E0000A8C7F8280D010C006060F800800424A42020804084480

3.

E0367CE08F6134D8C877927073F2775E310F2CFC530B2F920D83A2E64C4000000E04C01A4DC47018C81CD0E26204CC489003C60CC40040C860E84280220FC0904A0084CE80DD61CC0700C0C545CC1304000C600C0EC0530C800008804454008030000204000780510609041F0400E02388204846030F8600C4114284300801843161005DC4400040840C40410E030000C4000805848021C422C06921A2A0380600404640000DC010C029146FC0514005C4FAC0878400C0C0010B0E9CFB8410807848802601010F400301A20C4408414418640002C8E66FC0858403A00C000240000219C08846164D01

4.

E02CFC711EE090A06CC83BE45C1CFC5DD6C610E4CFE530B27C9068364300018055C02D0A8C184000C002900108901C020000C01A004301001C018020540F10C00E0E0000018052C7100D01C0000C808048C8080646400244040E08444008044A49824F90008807061300110280040000410E02450600800C0D0209C01241807400C4304380040000040044400088780401C000008240080080600C0001806061000808008028058042C000802100C040C00084222001468460E4E027C000018A08540E900008A2E00009C4208C400400004410C0410041800847D0040016D998A6A2C400C080002031

Mir gehen langsam die Ideen aus, was hier schief läuft. Würde mich 
wirklich über Hilfe freuen :)

MfG

[oldies (Gast)]

Hallo,
habe festgestellt, dass der CC1100 von Haus aus "Data whitening" macht, 
dieses kann im Register PKTCTRL0 (z.B. wert 0x05) abgestellt werden.
nun bekomme ich vom RFM12 valide Datenpakete (CRC OK), diese sehen eben 
allerdings noch so aus:

Dies ist 2�[�^MFW7B^R^R^P
Dies 4��^H^L���^CQ���!!!
Dies 4��^H^Ym-�^D����BBB
Dies t��^H^L���^CQ���!!!
Dies l��^H^L���^B����BBB
Dies d��^H^L���^CQ���!^P�
Dies ist 2�[�^MFW7B^R^Y^H
Dies t��^H^L���^B����BBB
Dies t�ބ^FV�q^AQ��� ��

Wobei noch zu klären wäre, ob es wirklich nur an der Sendefunktion 
liegt.

MfG

[oldies (Gast)]

Sry, editieren geht leider nicht.
Korrektur:
Habe in meinem Empfänger den crc-check wohl versehentlich abgeschaltet 
gehabt. Die ankommenden Datenpakete sind NICHT valide, somit scheint es 
wohl doch noch Probleme bei der Kommunikation zu geben.
Kennt jemand einen Zaubertrick?!

MfG

[oldies (Gast)]

Problem gelöst,
das RFM12 arbeitet nicht mit der eingestellten Baudrate von 19200, 
sondern mit 20284, daher ist es nötig beim cc1100 die Baudrate auf 
diesen Wert zu setzen um die Funktion zu gewährleisten.

MfG

[R. W. (quakeman)]

oldies schrieb:
> Problem gelöst,
> das RFM12 arbeitet nicht mit der eingestellten Baudrate von 19200,
> sondern mit 20284, daher ist es nötig beim cc1100 die Baudrate auf
> diesen Wert zu setzen um die Funktion zu gewährleisten.

Bist du sicher, dass du die Baudrate im RFM12 auch korrekt eingestellt 
hast?
Denn mir wäre das neu, dass die eingestellte Baudrate nicht eingehalten 
wird. Leider hast du für den RFM12 keine Registerwerte für die 
Initialisierung angegeben, weshalb ich dazu eben nicht viel sagen kann.

Wenn man im "Data Rate Command" Register cs=1 benutzt kommt man 
rechnerisch auf schlechte 21552Bps bei 0xC681 als Init Wert. Wenn man 
dagegen cs=0 setzt kommt man auf gute 19157Bps bei 0xC611 als Init Wert. 
Ich würde mal dadrauf Tippen, dass du cs=1 benutzt, womit man keine gute 
Näherung an 19200Bps bekommt.

Ciao,
     Rainer

[thinkJD (Gast)]

Hi,
wie es scheint funktioniert die Kommunikation jetzt, habe ich das 
richtig verstanden?
Falls ja, hast du noch ein paar Tipps für mich? Ich möchte nämlich 
ebenfalls die Betty und das RFM12 zum Kommunizieren überreden.

Gruß JD

[B. G. (smarti)]

Hi,

ich hab mal gegoogelt und das hier gefunden:

Linksammlung zur Betty sowohl cc1100 also auch rfm12:

http://bettyhacks.com/forum/index.php?topic=121.0

@ oldies
läuft deine kommunikation inzwischen?

Grüßle

Smarti

[Bernhard M. (boregard)]

Fox Mulder schrieb:
> oldies schrieb:
>> Problem gelöst,
>> das RFM12 arbeitet nicht mit der eingestellten Baudrate von 19200,
>> sondern mit 20284, daher ist es nötig beim cc1100 die Baudrate auf
>> diesen Wert zu setzen um die Funktion zu gewährleisten.
>
> Bist du sicher, dass du die Baudrate im RFM12 auch korrekt eingestellt
> hast?

Ich vermute mal, er hat den code von Benedikt für die RFM benutzt
 (z.B. aud dem Thread hier 
Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module" ). Dort wird 
die Berechnung für die Baudrate folgendermassen gemacht:

rf12_trans(0xC600|((344828UL/baud)-1));

was aber genau bei 19200 zu dem Wert 16 führt, der aber lt. Datenblatt 
21552 Baud ergibt, richtig wäre 17, also 0xC611...

[avr (Gast)]

Hi oldies,

wollte fragen ob die Kommunikation funktioniert? Wenn ja, kannst du 
deine Konfiguration hier posten? Ich wollte auch Betty mit RFM12 
kommunizieren lassen.

Gruß
AVR

[antonia (Gast)]

Mich würde auch interessieren ob die Kommunikation geht. Ich möchte den 
mpd-deamon damit steuern (siehe mcbetty). Es gibt aber dass 
scartinterface nirgends zu kaufen. Ich hatte schon überlegt, ob man 
nicht einfach eine zweite Betty als Gegenstelle verwenden kann

Gruß
antonia

[thinkJD (Gast)]

Jap, funktioniert :-)
http://www.thinkjd.de/2011/05/moodpxl-v1-0-das-vorlaufige-projektende/

Die grundlegende Kommunikation funktioniert wie oben beschrieben.
Wenn man noch ein paar Features mehr haben will, ist das auch kein 
Thema. Der CC1100 Chip lässt sich sehr komfortabel parametrieren.
Einziges Problem, nahezu alles was der CC1100 hardwareseitig kann, muss 
für den RFM12 nachprogrammiert werden.