Hat jemand Erfahrung mit dem 2,4GHz-Transceiver RFM70?

Bei mir funktioniert es jetzt. Der Fehler war, ich hatte beim Init das 
Register 0x1d nicht frei geschaltet. Ohne die Freischaltung ist das 
Register schreibgeschützt. Jetzt läuft die Übertragung mit und ohne 
"autoack".

Hallo holger,

das habe ich gemacht.

Hier sind meine Registereinstellungen für TX und RX:
Kannst du das bitte mit deinen Einstellungen vergleichen?

TX:

1

const unsigned int Bank1_Reg0_13[40]=    

2

{       

3

//    address      data

4

    (0x20|0x00),  0x40,  0x4B,  0x01,  0xE2,    //0xE2014B40  Address 0

5

    (0x20|0x01),  0xC0,  0x4B,  0x00,  0x00,    //0x00004BC0  Address 1

6

    (0x20|0x02),  0xD0,  0xFC,  0x8C,  0x02,    //0x028CFCD0  Address 2

7

    (0x20|0x03),  0x99,  0x00,  0x39,  0x41,    //0x41390099  Address 3  

8

    (0x20|0x04),  0xF9,  0x9E,  0x86,  0x0B,    //0x0B869ED9  Address 4

9

    (0x20|0x05),  0x24,  0x06,  0x7F,  0xA6,    //0xA67F0624  Address 5

10

    (0x20|0x0C),  0x00,  0x12,  0x73,  0x00,    //0x00127300  Address C

11

    (0x20|0x0D),  0x36,  0xB4,  0x80,  0x00    //0x36B48000  Address D  

12

};

13

14

//************  Bank1 register 14 initialization value

15

const unsigned int Bank1_Reg14[12]=

16

{

17

//    address      Data...

18

    (0x20|0x0E),   0x41,0x20,0x08,0x04,0x81,0x20,0xCF,0xF7,0xFE,0xFF,0xFF

19

//    0x20 = Write Command

20

};

21

22

//************  Bank0 register initialization value

23

const unsigned int Bank0_Reg0_29[18]=

24

{

25

//    address      data

26

    (0x20|0x00),  0x7A,  //Enable CRC ,CRC=1byte, POWER UP, TX

27

    (0x20|0x01),  0x01,  //Enable Autoacknownledge datapipe 0

28

    (0x20|0x02),  0x01,  //Enable RX Addresses datapipe 0

29

    (0x20|0x03),  0x03,  //RX/TX address field width 5byte

30

    (0x20|0x04),  0x00,  //auto retransmission disabled

31

    (0x20|0x05),  0x02,  //channel = 2

32

    (0x20|0x06),  0x35,  //air data rate-1M,out power +5dbm,setup LNA gain-high

33

    (0x20|0x1C),  0x01,  //Enable dynamic payload length datapipe 0

34

    (0x20|0x1D),  0x07  //Enable EN_DPL, EN_ACK_PAY, EN_DYN_ACK

35

};

RX:

1

const unsigned int Bank1_Reg0_13[40]=    

2

{       

3

//    address      data

4

    (0x20|0x00),  0x40,  0x4B,  0x01,  0xE2,    //0xE2014B40  Address 0

5

    (0x20|0x01),  0xC0,  0x4B,  0x00,  0x00,    //0x00004BC0  Address 1

6

    (0x20|0x02),  0xD0,  0xFC,  0x8C,  0x02,    //0x028CFCD0  Address 2

7

    (0x20|0x03),  0x99,  0x00,  0x39,  0x41,    //0x41390099  Address 3  

8

    (0x20|0x04),  0xF9,  0x9E,  0x86,  0x0B,    //0x0B869ED9  Address 4

9

    (0x20|0x05),  0x24,  0x06,  0x7F,  0xA6,    //0xA67F0624  Address 5

10

    (0x20|0x0C),  0x00,  0x12,  0x73,  0x00,    //0x00127300  Address C

11

    (0x20|0x0D),  0x36,  0xB4,  0x80,  0x00,    //0x36B48000  Address D  

12

};

13

14

//************  Bank1 register 14 initialization value

15

const unsigned int Bank1_Reg14[12]=

16

{

17

//  address         Data...

18

  (0x20|0x0E),   0x41,0x20,0x08,0x04,0x81,0x20,0xCF,0xF7,0xFE,0xFF,0xFF,

19

//  0x20 = Write Command

20

};

21

22

//************  Bank0 register initialization value

23

const unsigned int Bank0_Reg0_29[20]=

24

{

25

//    address      data

26

    (0x20|0x00),  0x7B,  //Enable CRC, POWER UP, RX

27

    (0x20|0x01),  0x00,  //Disable Autoacknowledge datapipe 0-5

28

    (0x20|0x02),  0x01,  //Enable RX Addresses datapipe0

29

    (0x20|0x03),  0x03,  //RX/TX address field width = 5byte

30

    (0x20|0x04),  0x00,  //auto retransmission disabled

31

    (0x20|0x05),  0x02,  //channel = 2

32

    (0x20|0x06),  0x35,  //air data rate-1M,out power 0dbm,setup LNA gain-high

33

    (0x20|0x11),  0x01,  //Datapipe0: Number of Bytes in RX payload = 1

34

    (0x20|0x1C),  0x00,  //Enable dynamic payload legth datapipe0

35

    (0x20|0x1D),  0x00,  //Enable EN_DPL, EN_ACK_PAY, EN_DYN_ACK

36

};

Im Moment benutze ich die gleichen Einstellungen wie in den Beispielen 
von Hope. Allerdings setzt du Bank 0 Register 0 auf 0x7a. Damit 
maskierst du alle IRQ's aus, somit wird der IRQ Pin nie auf low gehen. 
Probiere mal 0x0f für RX und 0x0e für TX. Damit sind alle IRQ aktiviert. 
Aktive IRQ werden durch schreiben einer 1 im Register 7 gelöscht. Danach 
geht der IRQ Pin auf high.

Und "autoacknowledge" auf beiden Seiten einschalten (Register1).
Ich habe beim Init für TX und RX die gleichen Einstellungen. Erst danach 
aktiviere ich "PTX" oder "PRX".

Holger Sch. schrieb:
> Und "autoacknowledge" auf beiden Seiten einschalten (Register1).

habe ich gemacht! 0x01 = 0x3F

> Ich habe beim Init für TX und RX die gleichen Einstellungen. Erst danach
> aktiviere ich "PTX" oder "PRX".

Wie meinst du das?
Sobald ich bei TX im Reg. 0x00 = 0x0E und bei RX 0x0F hinein schreibe, 
habe ich ja in diesem Moment PTX und PRX aktiviert. Oder?

Hallo Holger,

anbei meine Vorgehensweise (auf der RX-Seite) step by step als Grafik.

LG

Heimo

Mein Init:
- Bank 0 Register 0-22
- Bank umschalten
- Bank 1 Register 0-5, 12-14
- Bank umschalten
- Activate + 0x73 (Register 29 freischalten)
- Register 29 + 28 schreiben

dann bei RX:
- Flush RX
- PRX + PWR_UP aktivieren
- auf IRQ warten
- wenn IRQ low, FIFO lesen (R-RX_payload)
- IRQ löschen

bei TX:
- Flush TX
- PTX + PWR_UP aktivieren
- wenn FIFO_Status bit 5 = 0 (TX FIFO nicht voll)
- FIFO schreiben (W_TX_Payload)
-> RFM sollte jetzt senden
- auf IRQ warten (Paket gesendet)
- IRQ löschen
- etwas warten, dann neues Paket in den FIFO schreiben

CE kann die ganze Zeit auf 1 bleiben.

Ich sehe nicht, das du Activate + 0x73 zum Freischalten von Register 29 
sendest.
Gesendet wird, wenn PWR_UP = 1, PTX, CE = 1 und FIFO beschrieben. Ich 
lasse CE auf 1. Nach W_TX_Payload startet die Übertragung sofort.

Hallo Holger!

Ich habe den Code nun geändert. Irgendwo habe ich aber noch einen 
Fehler.

Für TX und RX habe ich CE jetzt immer auf 1.

TX-Seite:
Ich sende ein Datenbyte (0xAF)
Das FIFO-Status_Register lese ich permanent aus (Ausgabe am PORTC) und 
erhalte 0010 0001 also TX FIFO full und RX FIFO empty.
IRQ = immer 0.


RX-Seite:
Ich lese das FIFO (ist immer 0) und das FIFO-Status_Register permanent 
aus (Ausgabe am PORTC) und erhalte 0001 0001 also TX FIFO empty und RX 
FIFO empty.
IRQ = immer 1.


TX-Seite:

1

void main(void)

2

{   

3

  SPI_Master_Init();        // Init SPI & MCU Settings

4

  Init_RF_Settings();        // Init RF Settings

5

  Flush_TX();            // Clear FIFO

6

  Power_Up();            // Set RFM70 in Power Up TX-Modus

7

  CE_high();            // CE = 1

8

9

    while(1)

10

    {

11

        Payload_TX(0xA0, 0xAF);    // Payload TX: command write & send 0xAF data

12

13

        Payload_TX(0x17, 0x00);    // Payload TX: command read FIFO status register & send 0x00 dummy byte

14

        PORTC = SPDR;

15

        _delay_ms(1000);

16

    }

17

}

RX-Seite:

1

void main(void)

2

{   

3

  SPI_Master_Init();        // Init SPI & MCU Settings

4

  Init_RF_Settings();        // Init RF Settings

5

  Flush_RX();            // Clear FIFO

6

  Power_Up();            // Set RFM70 in Power Up RX-Modus

7

  CE_high();            // CE = 1

8

9

    while(1)

10

    {

11

        Payload_RX(0x61, 0x00);    // Read FIFO Payload

12

        PORTC = SPDR;

13

        _delay_ms(2000);

14

15

        Payload_RX(0x17, 0x00);    // Payload RX: command read FIFO status register & send 0x00 dummy byte

16

        PORTC = SPDR;

17

        _delay_ms(1000);

18

    }

19

}

Hallo Holger,

hab´s hin bekommen :-)

Danke für deine Hilfe!!!

Heimo G. schrieb:
> TX-Seite:
> Ich sende ein Datenbyte (0xAF)
> Das FIFO-Status_Register lese ich permanent aus (Ausgabe am PORTC) und
> erhalte 0010 0001 also TX FIFO full und RX FIFO empty.
> IRQ = immer 0.

Wenn der IRQ auf low geht, könnte es auch bedeuten das kein ACK von der 
RX-Seite zurück kommt. Der Grund steht im Status Register 7. Benutze 
doch erst mal W_TX_Payload_NOACK zum Senden. Ca. 500 µs nach dem 
Beschreiben des FIFO sollte der IRQ auf low gehen. Dann musst das 
Statusregister 7 lesen. Bit 5 sollte high sein (Data send). Bit 4 wird 
high, wenn vom RX kein ACK zurück kommt. Wenn du das gelesene Byte 
wieder in das Register 7 schreibst, wird der IRQ gelöscht und der 
IRQ-Pin wieder high.
Bei mir ging am Anfang der IRQ nicht auf low, da ich eine falsche 
Bedingung zur Ausführung von Activate + 0x73 hatte. Der FIFO war dann 
auch immer voll.

Auf der RX-Seite wartest du, bis IRQ-Pin low wird. Dann kannst du den 
FIFO lesen.

Ich habe inzwischen noch einen Fehler bei mir gefunden. Ich habe in die 
RX- und TX_ADDR Register (10,11,16) nur 4 Byte geschrieben. Damit 
bleiben die Werte in den Registern auf den Defaults, werden nicht 
überschrieben. Erst mit 5 Byte ändern die sich.

Heimo G. schrieb:
> hab´s hin bekommen

OK, ich war gerade am Schreiben.

Hallo,

da ich mir auch RFM70 Module bestellt habe, hätte ich interresse an 
einem kleinen Demoprojekt. Könnte einer von euch eventuell seinen 
kompletten Sourcecode hier veröffentlichen ?

Gruß
Garag

Vieles in der Beschreibung des RFM70 erinnert an die Dokumentation 
zumindest eines nRF24L*-ICs von Nordic Semiconductor. Möglicherweise ist 
ein solcher auf dem RFM70 montiert und wenn dem so ist, findet man bei 
Nordic einiges an brauchbaren Informationen und Beispielcodes.

Martin Thomas schrieb:
> Möglicherweise ist ein solcher auf dem RFM70 montiert

Das sollte ein RF70 (ohne "M") sein:
http://www.hoperf.com/rf_fsk/RF70.htm

Hallo

Ich würde mich gern hier anhängen und hätte auch noch ein paar Fragen 
zur Kommunikation zweier RFM70.
Wenn ich von einem Sender (PTX device) zum Empfänger (PRX device) ein 
Datum schicke, bekomme ich, wenn eingeschaltet doch ein AutoACK zurück. 
Im PRX kann ich dazu, laut Datenblatt ja sogar frei wählen, was da per 
AutoACK zurück geschickt wird.
Meine Fragen dazu wären:
- wann muß ich per W_ACK_PAYLOAD die Daten, die per AutoACK geschickt 
werden schreiben ? Also reicht das einmal, und die werden dann immer als 
ACK zurück geschickt, oder müßte ich das in die Int-Routine des 
Empfängers mit einbauen.
- wo finde ich denn im PTX device, was da als ACK zurück geschickt wurde 
?

Dann hätte ich noch ein Anliegen. Wenn ich mehrere PRX devices 
gleichzeitig mit eine Datum beschicken möchte geht das ja nur mit 
W_TX_PAYLOAD_NOACK. Wie macht man das möglicht zuverlässig. Im Moment 
behelfe ich mir damit, daß mehrfach zu senden. Da wäre ich für weitere 
Tips auch sehr dankbar.

Die Register Setting habe ich von den Hope-Beispielen übernommen. 
Lediglich von den Adressbytes werden nur 3 bei mir ausgewertet. Das 
gesendete Datum sind bei mir immer nur 3 Bytes lang.

Danke schon mal und Gruß

Ulf

Ulf Lanz schrieb:
> Im PRX kann ich dazu, laut Datenblatt ja sogar frei wählen, was da per
> AutoACK zurück geschickt wird.

Nein, mit "W_ACK_PAYLOAD" werden zusätzlich zum ACK auch noch Daten mit 
übertragen. Das aber ist optional.

> - wann muß ich per W_ACK_PAYLOAD die Daten, die per AutoACK geschickt
> werden schreiben ? Also reicht das einmal, und die werden dann immer als
> ACK zurück geschickt, oder müßte ich das in die Int-Routine des
> Empfängers mit einbauen.
> - wo finde ich denn im PTX device, was da als ACK zurück geschickt wurde

Die Daten müssten vor dem Beginn der Übertragung des Ack im RFM sein. 
Nach dem Ack sind die weg. Im PTX sind die im dann RX FIFO. Diese Daten 
haben mit dem Ack selbst nichts zu tun. Dafür ist das PID im Packet 
Control Byte zuständig. Ack mit Payload habe ich aber noch nicht 
getestet.

> Dann hätte ich noch ein Anliegen. Wenn ich mehrere PRX devices
> gleichzeitig mit eine Datum beschicken möchte geht das ja nur mit
> W_TX_PAYLOAD_NOACK. Wie macht man das möglicht zuverlässig.

Am einfachsten wäre wohl wenn jedes Modul eine eigene Adresse bekommt 
und du sendest mit Auto-Ack.

Hallo Holger

Danke für die Antwort

Es ist aber schon so, daß man sich beim AutoACK nicht um die 
Senderichtungs-Umschaltung kümmern muß, oder ? Ich sende mein Datum von 
PTX zum PRX. Dann warte ich bis beim PTX der Int. kommt und kann dann 
das RX-FIFO des PTX auslesen, das ja dann die ACK-Payload enthalten 
sollte.

>Am einfachsten wäre wohl wenn jedes Modul eine eigene Adresse bekommt
>und du sendest mit Auto-Ack.

Das geht leider nicht, weil dazu nicht genug Zeit ist.
Geplant hatte ich das so, daß alle Empfänger auf RX_ADDR_P0 die gleiche 
Adresse haben und auf RX_ADDR_P1 jeder eine unterschiedliche. Die 
Epfänger werden dann auf RX_ADDR_P1 konfiguriert wobei hier die Daten 
mit ACK übertragen werden. Auf RX_ADDR_P0 würde ich dann ohne ACK das 
Auslöse-Signal schicken.

Gruß Ulf

Ulf Lanz schrieb:
> Es ist aber schon so, daß man sich beim AutoACK nicht um die
> Senderichtungs-Umschaltung kümmern muß, oder ? Ich sende mein Datum von
> PTX zum PRX. Dann warte ich bis beim PTX der Int. kommt und kann dann
> das RX-FIFO des PTX auslesen, das ja dann die ACK-Payload enthalten
> sollte.

Hallo Holger

Ich hab's gerade mal ausprobiert, das klappt Super :-).
Danke nochmal für's "auf die Schiene setzen".

Gruß Ulf

Ulf Lanz schrieb:
> Es ist aber schon so, daß man sich beim AutoACK nicht um die
> Senderichtungs-Umschaltung kümmern muß, oder ?
Ja, der macht das von allein.

> Ich sende mein Datum von
> PTX zum PRX. Dann warte ich bis beim PTX der Int. kommt und kann dann
> das RX-FIFO des PTX auslesen, das ja dann die ACK-Payload enthalten
> sollte.
Es sollten die IRQ's TX_DS und RX_DR kommen, ohne empfangenes Ack MAX_RT

> Geplant hatte ich das so, daß alle Empfänger auf RX_ADDR_P0 die gleiche
> Adresse haben und auf RX_ADDR_P1 jeder eine unterschiedliche. Die
> Epfänger werden dann auf RX_ADDR_P1 konfiguriert wobei hier die Daten
> mit ACK übertragen werden. Auf RX_ADDR_P0 würde ich dann ohne ACK das
> Auslöse-Signal schicken.

Sollte funktionieren, die RFM's haben ja 6 RX-Pipes mit Ack und können 
auf 6 verschiedene Adressen reagieren. Damit beim PTX das Ack 
funktioniert, muss die RX-Adresse der Pipe 0 gleich der TX-Adresse sein. 
Also aufpassen.

Holger

Ulf Lanz schrieb:
> Ich hab's gerade mal ausprobiert, das klappt Super :-).
> Danke nochmal für's "auf die Schiene setzen".

Ah, super. War gerade noch am Schreiben.

Hallo!

Ich benötige Hilfe, um mehrere RGB-Led-Lampen zu synchronisieren.

Ich steuere mehrere RGB-Led-Lampen per Funk (RFM70 Funkmodul) an und 
möchte
diese nun untereinander synchronisieren, da bei einem Farbablauf nach
ca. 1min eine zeitlich merkbare Verschiebung der Farben beginnt.
Jede LED-Lampe ist mit einem Funkmodul ausgestattet.

Da die Hardware bereits fertig ist, muss ich das ganze per Software 
lösen.
Mein Gedanke:
Über die Fernbdienung muss ich eine LED-Lampe als Master definieren.
Der Master sagt den anderen LED-Lampen welche Farbsequenz gestartet wird 
und synchronisiert die "Slaves" am Anfang jedes Farbdurchlaufes.

Hat jemand eine Idee (Flussdiagramm), wie ich das am einfachsten lösen 
kann?

Hallo Ulf!

Das hört sich gut an.
Wie kann ich aber auf Pipe2 senden?
In Adresse 10 stelle ich die TX_ADDR ein. Gilt diese nicht für alle 5 
Pipes oder wie funktioniert das. Kannst du mir da bitte ein Beispiel 
geben?

ulf_l schrieb:
> Wenn man eine Übertragung mit AutoACK macht und kein Empfänger da ist,
> der das quittiert, wird diese Übertragung immer wieder durchgeführt.
> Auch das löschen des MAX_RT Bits im Status-Register bricht das nicht ab.
> Es ist zwingend notwendig, daß zusätzlich zum löschen des MAX_RT Bits
> auch per FLUSH_TX das TX-FIFO geleert wird.

Kann ich bestätigen, genau so habe ich es auch gemacht.

Hallo Ulf!

Weißt du wie ich die Register einstellen muss (TX und RX) damit ich auf 
Auto_ACK abfragen kann?

Hallo Heimo

Lade Dir doch mal hier http://www.hoperf.com/rf_fsk/rfm70.htm den 
Beispiel-code für transmittter und receiver code herunter. Dort ist eine 
Verbiundung mit AutoACK konfiguriert und eine Datenübertragung die per 
Command ohne AutoACK auskommt realisiert.

Wenn Du mit AutoACK vom PTX sendest, dann geht der INT erst auf Low, 
wenn das ACK zurück gekommen ist, oder der max. Retry erreicht wurde. 
Was von beiden passiert ist, kann man im Status-Register auslesen. Wenn 
MaxRetry eingetreten ist, FLUSH_TX nicht vergessen.

Gruß Ulf

Hallo Ulf!

Der Beispielcode ist für mich zu verwirrend.

Die Datenübertragung ohne ACK funktioniert.

Für die Datenübertragung mit ACK habe ich folgendes geändert:

TX-Seite:
Enable Auto ACK (Pipe 0 bis 5)
0x01 = 3F

Enable dynamic payload length und enable payload with ACK
0x1D = 06

Nach dem Senden frage ich das Statusregister (Bit 5) ab, ob das Bit 
gesetzt ist und lösche es durch Schreiben einer 1.


RX-Seite:
Enable Auto ACK (Pipe 0 bis 5)
0x01 = 3F

Enable dynamic payload length und enable payload with ACK
0x1D = 06


Ist diese Vorgehensweise so ok?

Hallo Heimo

Im Prinzip schaut das erst mal OK aus. Du solltest aber beim PTX device 
auch Bit 4 im Statusregister prüfen und entsprechend reagieren. Im 
RX-Device muß auf RX- und TX-Adresse für die Pipe, auf der das AutoACK 
ablaufen soll, gleich sein.

So verwirrend ist der Hope-Code aber auch nicht. Du müßtest das auf 
deinen uController anpassen und man hätte dann immer gleiche 
Voraussetzungen. Da sind lediglich die SPI-Schnittstelle und die 
diversen Steuersignale anzupassen.

Gruß Ulf

Hallo Ulf!

Ich schick dir mal meine registersettings vom PTX. Vielleicht fällt dir 
was auf!
Ich habe derzeit keine Idee mehr, was nicht passen könnte.

Vielleicht kannst du mir in Punkten auflisten, was für die 
AutoACK-Übertragung zu tun ist.

1

//************  Bank0 register initialization value

2

const char Bank0_Reg0_29[46]=

3

{

4

//    address      data

5

    (0x20|0x00),  0x08,  //reflect RX_DR\TX_DS\MAX_RT,Enable CRC 1byte,POWER down,PTX

6

    (0x20|0x01),  0x3F,  //Enable auto acknowledgement data pipe5\4\3\2\1\0

7

    (0x20|0x02),  0x3F,  //Enable RX Addresses pipe5\4\3\2\1\0

8

    (0x20|0x03),  0x03,  //RX/TX address field width 5byte

9

    (0x20|0x04),  0xff,  //auto retransmission dalay (4000us),auto retransmission count(15)

10

    (0x20|0x05),  0x17,  //23 channel

11

    (0x20|0x06),  0x17,  //air data rate-1M,out power 0dbm,setup LNA gain

12

    (0x20|0x07),  0x07,  

13

    (0x20|0x08),  0x00,  

14

    (0x20|0x09),  0x00,

15

    (0x20|0x0C),  0xc3,  //only LSB Receive address data pipe 2, MSB bytes is equal to RX_ADDR_P1[39:8]

16

    (0x20|0x0D),  0xc4,  //only LSB Receive address data pipe 3, MSB bytes is equal to RX_ADDR_P1[39:8]

17

    (0x20|0x0E),  0xc5,  //only LSB Receive address data pipe 4, MSB bytes is equal to RX_ADDR_P1[39:8]

18

    (0x20|0x0F),  0xc6,  //only LSB Receive address data pipe 5, MSB bytes is equal to RX_ADDR_P1[39:8]

19

    (0x20|0x11),  0x20,  //Number of bytes in RX payload in data pipe0(32 byte) 

20

    (0x20|0x12),  0x20,  //Number of bytes in RX payload in data pipe1(32 byte)

21

    (0x20|0x13),  0x20,  //Number of bytes in RX payload in data pipe2(32 byte)

22

    (0x20|0x14),  0x20,  //Number of bytes in RX payload in data pipe3(32 byte)

23

    (0x20|0x15),  0x20,  //Number of bytes in RX payload in data pipe4(32 byte)

24

    (0x20|0x16),  0x20,  //Number of bytes in RX payload in data pipe5(32 byte)

25

    (0x20|0x17),  0x00,  //fifo status

26

    (0x20|0x1C),  0x3F,  //Enable dynamic payload length data pipe5\4\3\2\1\0

27

    (0x20|0x1D),  0x06  //Enables Dynamic Payload Length,Enables Payload with ACK

28

};

29

30

31

//************  Bank0 register 28 + 29 initialization value

32

const char Bank0_Reg28_29[4]=

33

{

34

    (0x20|0x1C),  0x3F,  //Enable dynamic payload length data pipe5\4\3\2\1\0

35

    (0x20|0x1D),  0x07  //Enables Dynamic Payload Length,Enables Payload with ACK,Enables the W_TX_PAYLOAD_NOACK command 

36

};

37

38

39

//************  Receive address datapipe 0

40

const char RX0_Address[6]=

41

{

42

//    address      data

43

    (0x20|0x0A),  0x34,  0x43,  0x10,   0x10,  0x01

44

};

45

46

//************  Transmitt address 

47

const char TX_Address[6]=

48

{

49

//    address      data

50

    (0x20|0x10),  0x34,  0x43,  0x10,   0x10,  0x01

51

};

Hallo Heimo

Eine der Pipes des PTX device muß aber auch die gleiche RX-Adresse 
haben, wie die TX Adresse, da ja auf dieser die Kommunikation statt 
findet.

PTX sendet auf Adresse x
-> PRX empfängt auf Adresse x
-> PRX sendet automatische auf Adresse x das ACK zurück
-> wenn jetzt keine der Pipes im PTX die Adresse x hat, dann wird da 
auch kein ACK empfangen.

Gruß Ulf

Hallo Ulf!

folgende Einstellungen habe ich:

PTX:

//Receive address datapipe 0
0x34,  0x43,  0x10,   0x10,  0x01

//Transmitt Address
0x34,  0x43,  0x10,   0x10,  0x01


PRX:

//Receive address datapipe 0
0x34,  0x43,  0x10,   0x10,  0x01

//Transmitt Address
0x34,  0x43,  0x10,   0x10,  0x01

Hallo Heimo

In Register 0X00 muß auch das PoweUp-Bit gesetzt sein, sonst macht der 
Sender schon mal gar nix. Das Register 0X1D kommt bei Dir zwei mal vor. 
Da sollte der Wert 0X07 drin stehen.
Sonst fällt mir da jetzt erst mal nichts fehlerhaftes auf.

Gruß Ulf

Hallo Ulf!

Das Problem liegt denke ich bei meiner Initialisierung der Registerbank0 
und 1 bzw. setze ich ACTIVATE an falscher Stelle?

Hier die Routinen der Reihe nach:

1.) Init Registerbank 0 (inkl. Reg. 1C und 1D)
2.) Toggle Registerbank (0x50 = 0x53)
3.) Init Registerbank 1 + Register E
4.) Toggle Registerbank (0x50 = 0x53)
5.) ACTIVATE (0x50 = 0x73)

Kannst du das bitte mit deiner Init vergleichen?

Vielen Dank!

Hallo Heimo

Nochmal die Bitte: Schau Dir die Beispieldateien von Hope an. Die 
Funktion

1

void RFM70_Initialize()

ist reiner c-Code, ohne irgendwelche Controller-spezifischen 
Anweisungen. Da siehst Du ganz schnell, was da mit welcher Reihenfolge 
gemacht werden muß.

Das bringt mehr, als wenn ich ständig irgendwelche Code-Ausschnitte von 
Dir mit meinem vergliche, und dabei aber immer den Rest nicht kenne.

Die erste Aktivierung wird dort so gemacht:

1

i=SPI_Read_Reg(29);//read Feature Register Payload With ACK¸ ACTIVATE 0x73),Payload With ACK (REG28,REG29).

2

if(i==0) // i!=0 showed that chip has been actived.so do not active again.

3

    SPI_Write_Reg(ACTIVATE_CMD,0x73);// Active

Gruß Ulf

Hallo Ulf!

Ok, jetzt hab ich´s. Kommunikation läuft.

Ich habe jetzt 2 Empfänger und sende mit TX =
0x58,  0x41,  0x4C,   0x00,  0x10

Empfänger 1:
0x58,  0x41,  0x4C,   0x00,  0x10

Empfänger 2:
0x58,  0x41,  0x4C,   0x00,  0x11


Beide Empfänger sind auf datapipe 0 eingestellt.

Ich empfange aber auf beiden, obwohl die Adressen unterschiedlich sind.

Alle anderen pipes sind disabled.


Hast du eine Idee, warum ich auf beiden Empfängern empfange?

Hallo Heimo

Was war's denn jetzt, daß es nicht ging ?

Wenn im Register 3 noch 0X03 steht, dürfte das theoretisch allerdings 
nicht sein, daß beide Empfangen. Ich hab das aber mit dem untersten Bit 
noch nicht probiert. Bist Du sicher, daß die anderen Pipes disabled sind 
?

So wie ich das Datenblatt verstanden habe werden die untersten Bits aber 
sowieso nicht ausgewertet, weil die für die Pipes reserviert sind. Änder 
doch mal das unterste Bit von Adressbyte 4, in deinem Fall 0X00, ob dann 
immernoch der nicht addressierte Empfänger empfängt.

Wertest Du eigentlich die Bits RX_P_NO im Statusregister beim Empfangen 
aus ? Wäre mal interssant, was da drin steht wenn "fehlerhaft" empfangen 
wird.

Gruß Ulf

Hallo Heimo

Hast Du jetzt mal versucht das niederwertigste Bit im Adresbyte 4 zu 
ändern, ob dann auch der "nicht addresierte" Empfänger was empfängt ?

Gruß Ulf

Hallo Ulf

Ich habe auf der Rx-Seite das Bit (Pipe 0 und 1) geändert. Ergebnis: 
Kein Empfang. Der Transmitter reagiert also darauf.

Noch eine Frage an dich!

Ich möchte von Rx nach Tx auf der Pipe1 eine 2Byte Adresse (0xA101) 
zurück senden. (Dyn. Payload ist eingestellt).

Nach dem Senden lese ich auf der Tx-Seite das FIFO 2x hintereinander aus 
und speichere die Bytewerte in Variablen.

Payload(0x61, 0x00);  // Read FIFO payload (Cube address high byte)
x = USIDR;
Payload(0x61, 0x00);  // Read FIFO payload (Cube address high byte)
y = USIDR;

Wenn ich x und y auslese, erhalte ich nur den Wert für x. y bleibt 0.

Wenn ich z.B. einen 2Byte Wert mit einem payload sende, muss ich das 
payload auf der Rx-Seite doch 2x hintereinander auslesen - oder?

Heimo G. schrieb:
> Wenn ich z.B. einen 2Byte Wert mit einem payload sende, muss ich das
> payload auf der Rx-Seite doch 2x hintereinander auslesen - oder?

Dafür gibt es das Register 0x4B, received packet lenght. Das ist ja der 
Sinn von dynamic payload. Mit dem Datenpaket wird auch die Größe 
übertragen.

Ja, aber ich weiß ja die gesendete Größe = 2Byte.

Mir geht es um das Auslesen.

ich habe die folgende Routine:

CS = low
SPI_transfer(0x61);  // Read FIFO payload
SPI_transfer(0x00);  // 1. dummybyte
x = USIDR;
SPI_transfer(0x00);  // 2. dummybyte
y = USIDR;
CS = high

und hier ist irgendwo der Wurm drinnen.

Hallo Heimo

ich muß mich leider wiederholen: Die Hope-Beispiele nutze da

1

/**************************************************         

2

Function: SPI_Read_Buf();                                   

3

4

Description:                                                

5

  Reads 'length' #of length from register 'reg'         

6

/**************************************************/        

7

void SPI_Read_Buf(UINT8 reg, UINT8 *pBuf, UINT8 length)     

8

{                                                           

9

  UINT8 status,byte_ctr;                              

10

11

  CSN = 0;                        // Set CSN l

12

  status = SPI_RW(reg);           // Select register to write, and read status UINT8

13

14

  for(byte_ctr=0;byte_ctr<length;byte_ctr++)           

15

    pBuf[byte_ctr] = SPI_RW(0);    // Perform SPI_RW to read UINT8 from RFM70 

16

17

  CSN = 1;                           // Set CSN high again

18

19

}

Und das funktioniert einfach. Warum machst Du dir das leben so schwer ? 
Bei der Kommunikation über SPI wird immer beim Schreiben auch 
gleichzeitig gelesen. Das finde ich bei deiner Funktion nicht.
Wie schaut den deine Funktion

1

SPI_transfer(0x00);

aus ? Hier müßte doch eigentlich gleich das empfangene Datum zurück 
kommen. Ich sehe leider auch in den vergangenen Beiträgen von Dir nicht, 
was z.B. USIDR ist.

Gruß Ulf

Holger Sch. schrieb:
> Register 0x4B

Ups, das war vom RFM23. Beim RFM 70 ist es Kommando 0x60 (R_RX_PL_WID). 
Lies doch vor dem FIFO mal R_RX_PL_WID. Da müsste ja eine 2 drin stehen. 
Bei mir hat es jedenfalls funktioniert.

Hallo

Wenn Du Dir das im Beitrag 
Beitrag "Re: Hat jemand Erfahrung mit dem 2,4GHz-Transceiver RFM70?" anschaust, dann 
siehst Du, daß nur im ersten SPI-Kommando das Register ausgewählt wird 
und dann die Bytes durch schreiben einer Null gelesen werden.
Versuch es doch mal so.

Gruß Ulf

... und weil jetzt alle unsere RFM70 Module wunderbar funken hier die 
(Um)frage nach eurer RFM70 Reichweite. Beispiel: bei mir funkt's keine 
5m. Mensch oder Tür sind funkdicht. Gibt es hier jemanden, der mit RFM70 
über Stockwerke funkt opder im Freien über 100 m? Habe ich was falsch 
verstanden? Immerhin sagt Hoperf, dass "Home automation" eine typische 
Anwendung ist. Was ich mit den Händen erreiche, muss ich doch aber nicht 
fernbedienen....? Die beiden RF_PWR bits sind mir bereits bekannt 
(RF_PWR = 11).

So gut 100m im Freifeld und 25m diagonal über ein Stockwerk sind 
durchaus realistisch.
Kontrolliere mal deine Bytes in der Registerbank 1.

1

address      data...

2

    (0x20|0x00),  0x40,  0x4B,  0x01,  0xE2,    //0xE2014B40  Address 0

3

    (0x20|0x01),  0xC0,  0x4B,  0x00,  0x00,    //0x00004BC0  Address 1

4

    (0x20|0x02),  0xD0,  0xFC,  0x8C,  0x02,    //0x028CFCD0  Address 2

5

    (0x20|0x03),  0x99,  0x00,  0x39,  0x41,    //0x41390099  Address 3  

6

    (0x20|0x04),  0xF9,  0x9E,  0x86,  0x0B,    //0x0B869ED9  Address 4

7

    (0x20|0x05),  0x24,  0x06,  0x7F,  0xA6,    //0xA67F0624  Address 5

8

    (0x20|0x0C),  0x00,  0x12,  0x73,  0x00,    //0x00127300  Address C

9

    (0x20|0x0D),  0x36,  0xB4,  0x80,  0x00,    //0x36B48000  Address D

Wieviel dBm hast du in Adresse 0x06 in Reg.Bank 0 eingestellt?

0x06 = 0x37  //air data rate-1M,out power +5dbm,setup LNA gain

Deine beschriebene Reichweite erscheint mir schon sehr gut. Gratuliere! 
Zwischenzeitlich habe ich mit ein Paar Verbesserungen zumindest mal 
meine Anforderung erfüllt - 10m Luftlinie, eine Person ist kein 
Hindernis mehr.
Bei mir ist Bank 0 0x06 = 0x3F, also 2 mbps, sonst kein Unterschied. 
Setting von 0x37 probiere ich noch.

Der Techniker von Hoperf schreibt mir
"In the open air,We have tested ,the range of our RFM70 module will 
reach 80~70 using our demo board." und weiter "I think there is maybe 
something wrong with your hardware design and software,for example,PCB 
layout\the placement of the module ... Because the frequency of RFM70 
module is high(2.4G), so the wavelength will short,and then the signal 
will been absorbed easily and penetration is not very good." ...

(so sehe ich das im Großen und Ganzen auch.)

Meine Maßnahmen waren:
- Modul weg von allen anderen Leitungen, insbes GND muss weit weg
- Stabilisierung der Versorgungsspannung (3,3V) mit entspr. 
Kondensatoren
- Spiel mit verschiedenen Kanälen (es gibt in meiner Umgebung gute und 
schlechte, WLAN etc.)
- RFM70 IRQ low startet Empfang. Kein Polling.

Ich komme aber noch lange nicht auf 100m oder Funk durch eine 
Zielgelwand. Wie sieht denn das Layout bzw. die Beschaltung aus? 
Interessiert mich wirklich ...

Ich habe das Funkmodul stehend auf einer Platine (am 
Platinenrand)angelötet.

Hallo Gerhard

Ich will ebenfalls eine einfache Kommunikation zwischen zwei RFM70 
aufbauen. Ich hatte vor den Master und den Slave von hoperf 1:1 ins 
BASCOM zu übersetzen. Dein Eintrag ist der erste den ich fand der 
Fortschritte in Sachen RFM70/BASCOM erahnen lässt. Kannst du den Code, 
zumindest den Teil der Kommunikation/Initialisierung, eventuell 
uploaden?

Gruss Yvo

Hi Gerhard.

Bei mir ist es mit C ja auch nicht weit her...
Aber ich versteh das so: das if len kontrolliert ob etwas fertig 
verarbeitet und bereit zum Lesen im RX liegt. Falls ja liest er das.
Das While interresiert sich nicht für die Daten, nur für Veränderungen 
und steuert quasi Carrier detect an. oder sehe ich das komplett falsch? 
Gruss Yvo

Hallo Yvo

Tschuldigung für den Namensverschreiber ... Was ich noch vergessen habe, 
die Daten, die mit dem ACK zurück geschickt werden liegen in 
W_ACK_PAYLOAD und nicht im W_TX_PAYLOAD.

Gruß Ulf

Ja, genau so!

Tx und Rx0 kannst du jederzeit ändern.

Hi Gerhard,
laut Datenblatt halten sie das nicht aus. Lediglich die Eingangspins 
halten eine Spannung von bis zu 5V aus. Ich habe es aber selber noch 
nicht ausprobiert, würde es auch nur im Notfall tun, wenn du keine 
andere Wahl hast.

Gruß
Harald

> die Module sind bis 3,6 Volt spezifiziert.
> Ich möchte sie aber mit einer Lipo-Zelle betreiben, sprich es stehen bis
> 4,2 Volt an.
> Für nen Spannungsregler hab ich leider keinen Platz mehr. Das ganze soll
> in einem Modell-PKW im Maßstab 1:87 reinpassen.
zwei Dioden ams SMD passen sicher iwohin .... und dann hast Du 3.6 V ;-)

Hallo!,
Danke für die rasche Antwort. Meine Register Einstellungen sind genauso 
wie in den Hope Dateien! Ich habe die INCLUDE dateien von pic.h auf 
htc.h geändert da ich den high tech c Compiler verwende. Und da ich 
einen 18er Pic verwende habe ich die ANSEL Einstellungen durch ADCON1 = 
0x0F ersetzt. Ebenso den OSCCON habe ich auf 0x70 gelassen, damit der 
PIC mit 8Mhz arbeitet. Auf PORTC gebe ich den FIFO Status aus. Nach wie 
vor bekomme ich TX und RX FIFO Empty flags ausgegeben. Auf beiden 
Seiten. RX und TX.
Das kann doch eigentlich nicht sein?

Sind noch irgendwelche Änderungen am Hope Code notwendig die ich 
vergessen habe? Kann das nicht so recht verstehen.. Den Thread und auch 
alle anderen habe ich schon studiert... Irgendwo muss doch eine 
Kleinigkeit noch fehlen!?

Vielen Dank schon mal

M.Bente

Anbei das Registerdump:
Die Werte in Bank0 habe ich gerade mit dem Debugger ausgelesen. Stehen 
genauso im Chip.


//Bank1 register initialization value

//In the array RegArrFSKAnalog,all the register value is the byte 
reversed!!!!!!!!!!!!!!!!!!!!!
const unsigned long Bank1_Reg0_13[]={       //latest config txt
0xE2014B40,
0x00004BC0,
0x028CFCD0,
0x41390099,
0x0B869ED9,
0xA67F0624,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00000000,
0x00127300,
0x36B48000,
};

const UINT8 Bank1_Reg14[]=
{
  0x41,0x20,0x08,0x04,0x81,0x20,0xCF,0xF7,0xFE,0xFF,0xFF
};




//Bank0 register initialization value
const UINT8 Bank0_Reg[][2]={
{0,0x0F},//reflect RX_DR\TX_DS\MAX_RT,Enable CRC ,2byte,POWER UP,PRX
{1,0x3F},//Enable auto acknowledgement data pipe5\4\3\2\1\0
{2,0x3F},//Enable RX Addresses pipe5\4\3\2\1\0
{3,0x03},//RX/TX address field width 5byte
{4,0xff},//auto retransmission dalay (4000us),auto retransmission 
count(15)
{5,0x00},//23 channel
{6,0x17},//air data rate-1M,out power 0dbm,setup LNA gain
{7,0x07},//
{8,0x00},//
{9,0x00},
{12,0xc3},//only LSB Receive address data pipe 2, MSB bytes is equal to 
RX_ADDR_P1[39:8]
{13,0xc4},//only LSB Receive address data pipe 3, MSB bytes is equal to 
RX_ADDR_P1[39:8]
{14,0xc5},//only LSB Receive address data pipe 4, MSB bytes is equal to 
RX_ADDR_P1[39:8]
{15,0xc6},//only LSB Receive address data pipe 5, MSB bytes is equal to 
RX_ADDR_P1[39:8]
{17,0x20},//Number of bytes in RX payload in data pipe0(32 byte)
{18,0x20},//Number of bytes in RX payload in data pipe1(32 byte)
{19,0x20},//Number of bytes in RX payload in data pipe2(32 byte)
{20,0x20},//Number of bytes in RX payload in data pipe3(32 byte)
{21,0x20},//Number of bytes in RX payload in data pipe4(32 byte)
{22,0x20},//Number of bytes in RX payload in data pipe5(32 byte)
{23,0x00},//fifo status
{28,0x3F},//Enable dynamic payload length data pipe5\4\3\2\1\0
{29,0x07}//Enables Dynamic Payload Length,Enables Payload with 
ACK,Enables the W_TX_PAYLOAD_NOACK command
};


const UINT8 RX0_Address[]={0x34,0x43,0x10,0x10,0x01};//Receive address 
data pipe 0
const UINT8 RX1_Address[]={0x39,0x38,0x37,0x36,0xc2};////Receive address 
data pipe 1


Danke für die Mühe!

PS der CH ist geändert von mir aber bei beiden... Nur zum Test!

Hallo!
Also meine neuesten Versuche haben ergeben das der Sender wohl nicht 
ordentlich sendet. Ich habe das Programm so geändert das er die ganze 
Zeit senden soll, der Stromverbrauch steigt jedoch nicht an. Der 
Empfänger verbraucht den im Datenblatt angegeben Strom. Nur der Sender 
bleibt bei ca 2 mA. Muss ich fürs senden noch irgendwas machen? 
Normalerweise sollte der Sender ja wenn ich sende auch so auf 20 mA 
kommen!? Alles etwas komisch.

Grüße
M.Bente

Hei!
i=SPI_Read_Reg(29);//read Feature Register
if(i==0) // i!=0 showed that chip has been actived.so do not active 
again.
SPI_Write_Reg(ACTIVATE_CMD,0x73);// Active

Meinst du das mit dem ACTIVATE und Entsperren? Habe da am Hope Code 
nichts geändert. Ebenso an der Beschreibung der Bank1 Register habe ich 
nichts geändert. Um die Bank1 auszulesen muss ich erstmal entsprechende 
Routinen schreiben da die ja 32 bit lang sind.

@Andreas die SPI Konfiguration habe ich von 1:1 vom HOPE Code also auch 
das Software SPI. Ich kann auch jedes Register erfolgreich schreiben und 
lesen. Jedoch senden und/oder empfangen kann ich nicht.

Weiß auch noch nicht wie ich überprüfen kann ob nun der Sender nicht 
sendet oder der Empfänger nicht empfängt -> ein Teufelskreis.

Hoffnungsvolle Grüße

Moritz

Danke! Gute idee. Also Nachdem ich den TX-FIFO Beschrieben habe wird das 
TX-Empty Flag gelöscht.

Also voher: FIFO_STATUS: 0x11 (TX-Empty, RX-Empty)
Nachdem beschreiben: 0x01 (RX-Empty)

Aber das TX-Full Flag kommt nicht. Muss das gesetzt werden?

Dank dir für deine Hilfe!

Moritz

Ich verstehe es nicht. Genauso mach ich es auch. Habe das Config 
Register ausgelesen vor und nach der Senderoutine alles okay und 
plausibel.
Die Funktion des "R_RX_PL_WID" habe ich noch nicht ganz verstanden? Was 
soll ich da auslesen können? Versuche jetzt mal das Register im 
Empfänger die ganze Zeit auszulesen und gucke ob sich was im Takt des 
senden ändert. Aber so langsam glaube ich das es nichts wird mit den 
RFM70. Habe 4 RFM70's hier die alle das selbe Verhalten zeigen...
Habe das auf dem Steckbrett gesteckt und tausche regelmäßig hin und her.
Bringt jedoch keine Änderung. Grüße

Okay danke für die Erklärung, das Register ist dauerhaft leer, wird ja 
auch noch nichts empfangen. Habe gerade mal den PORT gewechselt auf 
andere PINS am Controller aber, das Ergebnis ist das selbe. Hat schon 
mal jemand auf einmal 4 defekte Module geliefert bekommen? Kann ich mir 
gar nicht vorstellen...
Grüße!

Also der CE PORT wechselt beim umschalten von RX auf TX einmal, wie 
erwartet. Bin mit meinem Latein auch langsam am Ende. Nach dem 
Einschalten warte ich 200ms (in der Hope Routine POWERUP Delay)

Wärst du bereit(oder vlt auch jemand anders) das ich mal 2 Module zu dir 
schicke und die mal testest?, meine Module habe ich mit einer 
Buchsenleiste bestückt. Siehe Photo, Rückporto würde ich dann dazu 
legen.(Komme aus dem Raum Hannover) Kann im Moment nur von einem 
Hardware defekt ausgehen... Und jetzt nochmal welche bestellen, weiß 
nicht ob mich das so sehr nach vorne bringt.

Habe das Packet senden jetzt so eingebaut:
CE=0
Delay1ms
FIFO schreiben
CE=1
delay1ms
CE=0

-> keine Änderung zu vorher.

Also ich an dem Sender kann ich am IRQ was messen aber am Empfänger 
nicht. Habe da noch nen Delay Eingebaut und das stört ihn alles nicht 
... Hat evtl jemand für eine 18er PIC einfache RX und TX Projekte die 
ich schnell nachstecken kann um ein Hardware Problem auszuschließen?
Grüße !

Könnte einen ATMEGA besorgen. Muss jetzt erstmal aufhören. Ich melde 
mich morgen zu dem Thema wieder! Erstmal vielen Dank für die großartige 
Unterstützung!

Grüße Moritz

Hallo !

Ich habe mir inzwischen 2 neue Module bestellt und die zeigen das selbe 
Verhalten also kann ich von einem Hardware defekt wohl nicht mehr 
ausgehen. "Schade"... Das mit dem activate Komando mache ich genau wie 
in dem HOPE beispiel:

Register 29 auslesen,
 -> wenn Register = "0" ist, dann Activate CMD und 0x73 schreiben.
Wenn es nicht "0" ist wird nicht nochmal aktiviert.

Im Code:
i=SPI_Read_Reg(29);
if(i==0) SPI_Write_Reg(ACTIVATE_CMD,0x73);

Danach wird noch Register 22 und 21 beschrieben und danach wird Bank1 
initialisiert.


Hat jemand noch ne Idee was ich bei der Portierung des Hope Codes 
vergessen habe.
Ich verwende einen PIC18f2525 habe geändert:
MCU Init:
alt      neu
ANSEL -> ADCON1 = 0x0F; -> alles digitale I/Os
WPUB  -> --

Habe es mit dem High tech c Compiler kompiliert. Musste also noch die 
include <pic.h> auf include <htc.h> ändern danach wird kompiliert ohne 
Fehler. Timer von 1hz für das senden läuft und Statusregister wird alles 
korrekt ausgelesen -> 0x0E bei beiden, Sender und Empfänger.
Alle Register habe ich nach der INIT ausgelesen mit dem Debugger und es 
steht in jedem Register das drin was drin stehen soll. Alle 
Delay_routinen habe ich überprüft und sind okay.

Wenn jemand noch eine Idee hat was ich falsch übernommen habe wäre ich 
sehr dankbar.

Grüße Moritz

Hallo Gerhard,

habe mir das mal durchgelesen, und sehe erstmal keine großen 
Unterschiede. Die Module scheinen mich nicht zu mögen. Schade eigentlich 
von der Größe her wären sie für meine Fernbedienung ideal! Gibt es was 
vergleichbares auf dem Markt? Obwohl aufgeben eigentlich nicht meine Art 
ist, bin ich hier kurz davor. Hatte schon sehr lange nicht mehr so arge 
Probleme wie mit diesen Modulen, das letzte mal mit dem RFM12. ;-) Das 
war/ist ein ähnliches Theater. Durch die Packethandling-Geschichte hatte 
ich die Hoffnung das es bei diesen Modulen einfacher mit der Umsetzung 
wird aber es will nicht.

Habe nochmal alle Module ausprobiert und auch nochmal alles ausgelesen 
vor dem Reset und nach der Init. Alles super. Nach dem Senden kommt auch 
der TX_DS interupt. Und der IRQ geht auch auf low. Nur der Empfänger 
gibt keine Reaktion von sich. Ich sträube mich auch noch eine Platine 
herzustellen aber vlt. liegt es ja an meinem Steckbrett aufbau. Naja mal 
schauen wie und was ich jetzt mache, habe so langsam keine Ideen mehr.

Vielen Dank trotzdem für die Hilfe!!!

Grüße

Moritz

Nein sende ohne AutoAck, wenn ich mit AutoAck sende kommt das TX_DS 
nicht. Und im Register TX_Observe (0x08) ändern sich die Bits wie man es 
erwartet wenn keine Antwort zurück kommt.

Hallo Gerhard,
tausche regelmäßig alles hin und her. Habe auch bei beiden schon den 
selben Code laufen lassen, da der Beispielcode (wenn ich alles richtig 
verstanden habe) nach dem senden in den Empfangsmodus wechselt, sollten 
2 Master mit der selben Adresse sich ja auch verstehen. Channel und 
TX-RX Adresse waren immer unverändert. TX = RX adresse. Das habe ich 
nicht verändert. Mit den Kanälen habe ich zwischendurch zum Testen mal 
rumgespielt aber keine Veränderung.
Der FIFO Status bewegt sich überhaupt nicht. Die ganze Zeit 0x11, RX 
empty,TX empty. Das letzte bit in Register 0x00 müsste sich meines 
Erachtens aber auch ändern während der Laufzeit, wenn man zwischen PTX 
und PRX umschaltet. Also hängt es davon ab ob sich das Modul im RX oder 
im TX mode befindet.

Grüße Moritz