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

[H. G. (ledi)]

Ich möchte mit dem Transceiver RGB-Leds im Wohnraum ansteuern. Auf der 
einen Seite habe ich die Fernbedienung (ATMEL 90PMW316 als UC mit RFM70) 
und auf der Empfängerseite ebenfalls den 90PWM316 mit dem RFM70.

Per SPI-Schnittstelle gelingt die Kommunikation(Chip-ID konnte ich 
auslesen).
Leider konnte ich bis dato noch keinen Datensatz per Funk übertragen. Da 
ich hier schon über eine Woche herumbastle und jetzt einfach nicht mehr 
weiter weiß, bitte ich um eine Hilfestellung.

Daher meine Frage: Hat jemand Erfahrung mit dem 2,4GHz-Transceiver 
RFM70?

[Holger S. (holli_1)]

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".

[H. G. (ledi)]

Hallo holger,

das habe ich gemacht.

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

TX:

const unsigned int Bank1_Reg0_13[40]=    
{       
//    address      data
    (0x20|0x00),  0x40,  0x4B,  0x01,  0xE2,    //0xE2014B40  Address 0
    (0x20|0x01),  0xC0,  0x4B,  0x00,  0x00,    //0x00004BC0  Address 1
    (0x20|0x02),  0xD0,  0xFC,  0x8C,  0x02,    //0x028CFCD0  Address 2
    (0x20|0x03),  0x99,  0x00,  0x39,  0x41,    //0x41390099  Address 3  
    (0x20|0x04),  0xF9,  0x9E,  0x86,  0x0B,    //0x0B869ED9  Address 4
    (0x20|0x05),  0x24,  0x06,  0x7F,  0xA6,    //0xA67F0624  Address 5
    (0x20|0x0C),  0x00,  0x12,  0x73,  0x00,    //0x00127300  Address C
    (0x20|0x0D),  0x36,  0xB4,  0x80,  0x00    //0x36B48000  Address D  
};

//************  Bank1 register 14 initialization value
const unsigned int Bank1_Reg14[12]=
{
//    address      Data...
    (0x20|0x0E),   0x41,0x20,0x08,0x04,0x81,0x20,0xCF,0xF7,0xFE,0xFF,0xFF
//    0x20 = Write Command
};

//************  Bank0 register initialization value
const unsigned int Bank0_Reg0_29[18]=
{
//    address      data
    (0x20|0x00),  0x7A,  //Enable CRC ,CRC=1byte, POWER UP, TX
    (0x20|0x01),  0x01,  //Enable Autoacknownledge datapipe 0
    (0x20|0x02),  0x01,  //Enable RX Addresses datapipe 0
    (0x20|0x03),  0x03,  //RX/TX address field width 5byte
    (0x20|0x04),  0x00,  //auto retransmission disabled
    (0x20|0x05),  0x02,  //channel = 2
    (0x20|0x06),  0x35,  //air data rate-1M,out power +5dbm,setup LNA gain-high
    (0x20|0x1C),  0x01,  //Enable dynamic payload length datapipe 0
    (0x20|0x1D),  0x07  //Enable EN_DPL, EN_ACK_PAY, EN_DYN_ACK
};

RX:

const unsigned int Bank1_Reg0_13[40]=    
{       
//    address      data
    (0x20|0x00),  0x40,  0x4B,  0x01,  0xE2,    //0xE2014B40  Address 0
    (0x20|0x01),  0xC0,  0x4B,  0x00,  0x00,    //0x00004BC0  Address 1
    (0x20|0x02),  0xD0,  0xFC,  0x8C,  0x02,    //0x028CFCD0  Address 2
    (0x20|0x03),  0x99,  0x00,  0x39,  0x41,    //0x41390099  Address 3  
    (0x20|0x04),  0xF9,  0x9E,  0x86,  0x0B,    //0x0B869ED9  Address 4
    (0x20|0x05),  0x24,  0x06,  0x7F,  0xA6,    //0xA67F0624  Address 5
    (0x20|0x0C),  0x00,  0x12,  0x73,  0x00,    //0x00127300  Address C
    (0x20|0x0D),  0x36,  0xB4,  0x80,  0x00,    //0x36B48000  Address D  
};

//************  Bank1 register 14 initialization value
const unsigned int Bank1_Reg14[12]=
{
//  address         Data...
  (0x20|0x0E),   0x41,0x20,0x08,0x04,0x81,0x20,0xCF,0xF7,0xFE,0xFF,0xFF,
//  0x20 = Write Command
};

//************  Bank0 register initialization value
const unsigned int Bank0_Reg0_29[20]=
{
//    address      data
    (0x20|0x00),  0x7B,  //Enable CRC, POWER UP, RX
    (0x20|0x01),  0x00,  //Disable Autoacknowledge datapipe 0-5
    (0x20|0x02),  0x01,  //Enable RX Addresses datapipe0
    (0x20|0x03),  0x03,  //RX/TX address field width = 5byte
    (0x20|0x04),  0x00,  //auto retransmission disabled
    (0x20|0x05),  0x02,  //channel = 2
    (0x20|0x06),  0x35,  //air data rate-1M,out power 0dbm,setup LNA gain-high
    (0x20|0x11),  0x01,  //Datapipe0: Number of Bytes in RX payload = 1
    (0x20|0x1C),  0x00,  //Enable dynamic payload legth datapipe0
    (0x20|0x1D),  0x00,  //Enable EN_DPL, EN_ACK_PAY, EN_DYN_ACK
};

[Holger S. (holli_1)]

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.

[Holger S. (holli_1)]

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".

[H. G. (ledi)]

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?

[H. G. (ledi)]

Hallo Holger,

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

LG

Heimo

[Holger S. (holli_1)]

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.

[H. G. (ledi)]

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:

void main(void)
{   
  SPI_Master_Init();        // Init SPI & MCU Settings
  Init_RF_Settings();        // Init RF Settings
  Flush_TX();            // Clear FIFO
  Power_Up();            // Set RFM70 in Power Up TX-Modus
  CE_high();            // CE = 1

    while(1)
    {
        Payload_TX(0xA0, 0xAF);    // Payload TX: command write & send 0xAF data
    
        Payload_TX(0x17, 0x00);    // Payload TX: command read FIFO status register & send 0x00 dummy byte
        PORTC = SPDR;
        _delay_ms(1000);
    }
}

RX-Seite:

void main(void)
{   
  SPI_Master_Init();        // Init SPI & MCU Settings
  Init_RF_Settings();        // Init RF Settings
  Flush_RX();            // Clear FIFO
  Power_Up();            // Set RFM70 in Power Up RX-Modus
  CE_high();            // CE = 1

    while(1)
    {
        Payload_RX(0x61, 0x00);    // Read FIFO Payload
        PORTC = SPDR;
        _delay_ms(2000);

        Payload_RX(0x17, 0x00);    // Payload RX: command read FIFO status register & send 0x00 dummy byte
        PORTC = SPDR;
        _delay_ms(1000);
    }
}

[H. G. (ledi)]

Hallo Holger,

hab´s hin bekommen :-)

Danke für deine Hilfe!!!

[Holger S. (holli_1)]

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.

[Holger S. (holli_1)]

Heimo G. schrieb:
> hab´s hin bekommen

OK, ich war gerade am Schreiben.

[Dirk B. (garag)]

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

[Martin T. (mthomas) (Moderator)]

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.

[Jack (Gast)]

Hallo Holger und Heimo,
wäre auch an einem kleinen, einfachen Beispiel interresiert.
Das Rad muss ja nicht neu erfunden werden oder??

   Gruss
   jack

[Rufus Τ. F. (rufus)]

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

[Ulf L. (ulf_l)]

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

[Holger S. (holli_1)]

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.

[Ulf L. (ulf_l)]

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 L. (ulf_l)]

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

[Holger S. (holli_1)]

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

[Holger S. (holli_1)]

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.

[H. G. (ledi)]

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?

[ulf_l (Gast)]

Hallo Heimo

Die einfachste Möglichkeit ist, daß ein RFM70 auf einer zweiten Pipe 
eine Befehlssequenz ohne ACK an alle Empfänger sendet . Das könnte man 
so jede Sekunde einmal machen.
Dazu müssen alle Empfänger in der entsprechenden Pipe die gleiche 
Adresswe haben.
- im "Master" auf diese Adresse umschalten
- Sync-Signal an alle Empfänger schicken
- im "Master" auf ursprüngliche Adresse umschalten
fertig.

Gruß Ulf

[ulf_l (Gast)]

Hallo

Noch ein Tip, der mich gestern etwas Zeit gekostet hat:
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.

Gruß Ulf

[H. G. (ledi)]

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 (Gast)]

Hallo Heimo

Nein, Du sendest immer nur an eine Adresse, die, die eben als TX Adresse 
im PTX eingestellt ist. Wenn Du auf eine andere Pipe senden willst, dann 
muß vorher die entsprechende Adresse beim Sender auch eingestellt 
werden.

Angenommen Pipe 1 hat die Adresse 1 und Pipe 2 die Adresse 2 und deine 
Normale Kommunikation läuft auf Pipe 1 ab. Dann wechselst Du für das 
Sync-Paket im Sender auf Adresse 2, sendest dein Sync-Paket ohne AutoACK 
an alle Empfänger, die auch alle die gleiche Adresse 2 haben müssen, und 
wechselst dann im Sender wieder zurück auf Adresse 1.

Gruß Ulf

[Holger S. (holli_1)]

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.

[gunnar (Gast)]

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

Ja davon ist auszugehen.

[H. G. (ledi)]

Hallo Ulf!

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

[Ulf L. (ulf_l)]

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

[H. G. (ledi)]

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?

[Ulf L. (ulf_l)]

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

[H. G. (ledi)]

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.

//************  Bank0 register initialization value
const char Bank0_Reg0_29[46]=
{
//    address      data
    (0x20|0x00),  0x08,  //reflect RX_DR\TX_DS\MAX_RT,Enable CRC 1byte,POWER down,PTX
    (0x20|0x01),  0x3F,  //Enable auto acknowledgement data pipe5\4\3\2\1\0
    (0x20|0x02),  0x3F,  //Enable RX Addresses pipe5\4\3\2\1\0
    (0x20|0x03),  0x03,  //RX/TX address field width 5byte
    (0x20|0x04),  0xff,  //auto retransmission dalay (4000us),auto retransmission count(15)
    (0x20|0x05),  0x17,  //23 channel
    (0x20|0x06),  0x17,  //air data rate-1M,out power 0dbm,setup LNA gain
    (0x20|0x07),  0x07,  
    (0x20|0x08),  0x00,  
    (0x20|0x09),  0x00,
    (0x20|0x0C),  0xc3,  //only LSB Receive address data pipe 2, MSB bytes is equal to RX_ADDR_P1[39:8]
    (0x20|0x0D),  0xc4,  //only LSB Receive address data pipe 3, MSB bytes is equal to RX_ADDR_P1[39:8]
    (0x20|0x0E),  0xc5,  //only LSB Receive address data pipe 4, MSB bytes is equal to RX_ADDR_P1[39:8]
    (0x20|0x0F),  0xc6,  //only LSB Receive address data pipe 5, MSB bytes is equal to RX_ADDR_P1[39:8]
    (0x20|0x11),  0x20,  //Number of bytes in RX payload in data pipe0(32 byte) 
    (0x20|0x12),  0x20,  //Number of bytes in RX payload in data pipe1(32 byte)
    (0x20|0x13),  0x20,  //Number of bytes in RX payload in data pipe2(32 byte)
    (0x20|0x14),  0x20,  //Number of bytes in RX payload in data pipe3(32 byte)
    (0x20|0x15),  0x20,  //Number of bytes in RX payload in data pipe4(32 byte)
    (0x20|0x16),  0x20,  //Number of bytes in RX payload in data pipe5(32 byte)
    (0x20|0x17),  0x00,  //fifo status
    (0x20|0x1C),  0x3F,  //Enable dynamic payload length data pipe5\4\3\2\1\0
    (0x20|0x1D),  0x06  //Enables Dynamic Payload Length,Enables Payload with ACK
};


//************  Bank0 register 28 + 29 initialization value
const char Bank0_Reg28_29[4]=
{
    (0x20|0x1C),  0x3F,  //Enable dynamic payload length data pipe5\4\3\2\1\0
    (0x20|0x1D),  0x07  //Enables Dynamic Payload Length,Enables Payload with ACK,Enables the W_TX_PAYLOAD_NOACK command 
};


//************  Receive address datapipe 0
const char RX0_Address[6]=
{
//    address      data
    (0x20|0x0A),  0x34,  0x43,  0x10,   0x10,  0x01
};

//************  Transmitt address 
const char TX_Address[6]=
{
//    address      data
    (0x20|0x10),  0x34,  0x43,  0x10,   0x10,  0x01
};

[Ulf L. (ulf_l)]

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

[H. G. (ledi)]

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

[Ulf L. (ulf_l)]

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

[H. G. (ledi)]

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!

[Ulf L. (ulf_l)]

Hallo Heimo

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

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:

i=SPI_Read_Reg(29);//read Feature Register Payload With ACK¸ ACTIVATE 0x73),Payload With ACK (REG28,REG29).
if(i==0) // i!=0 showed that chip has been actived.so do not active again.
    SPI_Write_Reg(ACTIVATE_CMD,0x73);// Active

Gruß Ulf

[H. G. (ledi)]

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?

[Ulf L. (ulf_l)]

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

[ledi (Gast)]

Ein blöder Fehler im Quellcode war das Problem!

Datentransfer klappt auf den Pipes.
Receive OK!
Transmitt OK!

Ich verwende Pipe0 und Pipe1. Das LSB wird aber auch erkannt!
Das ist im Datenblatt sehr verwirrend geschrieben.

[Ulf L. (ulf_l)]

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

[H. G. (ledi)]

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?

[Holger S. (holli_1)]

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.

[H. G. (ledi)]

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.

[Ulf L. (ulf_l)]

Hallo Heimo

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

/**************************************************         
Function: SPI_Read_Buf();                                   
                                                            
Description:                                                
  Reads 'length' #of length from register 'reg'         
/**************************************************/        
void SPI_Read_Buf(UINT8 reg, UINT8 *pBuf, UINT8 length)     
{                                                           
  UINT8 status,byte_ctr;                              
                                                            
  CSN = 0;                        // Set CSN l
  status = SPI_RW(reg);           // Select register to write, and read status UINT8
                                                            
  for(byte_ctr=0;byte_ctr<length;byte_ctr++)           
    pBuf[byte_ctr] = SPI_RW(0);    // Perform SPI_RW to read UINT8 from RFM70 
                                                            
  CSN = 1;                           // Set CSN high again
               
}

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

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 S. (holli_1)]

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.

[bedrich (Gast)]

Guten Tag,

ich habe einen RFM70 als Empfänger per SPI am ATMega8 und zwecks 
Debuggen den ATMega8 über UART am PC COM1. Ein zweiter RFM70 sendet alle 
500ms 8Byte.

Ich empfange mit SPI Command R_RX_PL_WID (0x60) korrekt, dass 8 byte 
gelesen wurden. Probe: Sender aus, dann kommt nichts an. Der Versuch, 
die 8byte in ein Array zu puffern sieht so aus:

while(len--)
{
MyArray[i] = (read_reg(0x61));
i++;        
}

Problem: nur das erste Byte (MyArray[0]) wird korrekt gelesen, der Rest 
MyArray[1,2,3,...] sind Nullen (0x00), egal was ich sende.

Hat wer eine Idee? Weit kann's m.E. eigentlich nicht fehlen. Fehlt aber 
und macht mich gaaanz langsam wahnsinnig...

Grüße vom Bedrich

[Ulf L. (ulf_l)]

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

[bedrich (Gast)]

.... und das war genau der entscheidende Hinweis. Danke, Ulf!

[Andreas S. (bedrich)]

... 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).

[H. G. (ledi)]

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

address      data...
    (0x20|0x00),  0x40,  0x4B,  0x01,  0xE2,    //0xE2014B40  Address 0
    (0x20|0x01),  0xC0,  0x4B,  0x00,  0x00,    //0x00004BC0  Address 1
    (0x20|0x02),  0xD0,  0xFC,  0x8C,  0x02,    //0x028CFCD0  Address 2
    (0x20|0x03),  0x99,  0x00,  0x39,  0x41,    //0x41390099  Address 3  
    (0x20|0x04),  0xF9,  0x9E,  0x86,  0x0B,    //0x0B869ED9  Address 4
    (0x20|0x05),  0x24,  0x06,  0x7F,  0xA6,    //0xA67F0624  Address 5
    (0x20|0x0C),  0x00,  0x12,  0x73,  0x00,    //0x00127300  Address C
    (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

[Andreas S. (bedrich)]

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 ...

[H. G. (ledi)]

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

[Gerhard (Gast)]

Hallo,

ich versuche seit einigen Tagen, die Init zu verstehen.
Ziel soll es sein, die RFM70 auf Bascom anzusteuern.
Dazu möchte ich das Init-Beispiel von HopeRF 1:1 übersetzen.
Dabei stellt sich mir folgendes Rätsel:
erst wird Register 0 bis 29 initiiert, danach kommt folgender Code, den 
ich nicht verstehe. Meine mangelnde C-Kenntnis trägt da auch noch bei.

/*//reg 10 - Rx0 addr
  SPI_Write_Buf((WRITE_REG|10),RX0_Address,5);
  
//REG 11 - Rx1 addr
  SPI_Write_Buf((WRITE_REG|11),RX1_Address,5);

//REG 16 - TX addr
  SPI_Write_Buf((WRITE_REG|16),RX0_Address,5);*/

//reg 10 - Rx0 addr
  for(j=0;j<5;j++)
  {
    WriteArr[j]=RX0_Address[j];
  }
  SPI_Write_Buf((WRITE_REG|10),&(WriteArr[0]),5);
  
//REG 11 - Rx1 addr
  for(j=0;j<5;j++)
  {
    WriteArr[j]=RX1_Address[j];
  }
  SPI_Write_Buf((WRITE_REG|11),&(WriteArr[0]),5);
//REG 16 - TX addr
  for(j=0;j<5;j++)
  {
    WriteArr[j]=RX0_Address[j];
  }
  SPI_Write_Buf((WRITE_REG|16),&(WriteArr[0]),5);

was wird da gemacht? Erst die RX-Adressen für Pipe 0 und 1 und danach 
die TX-Adresse. OK. Aber dann kommen 3 Schleifen, die in meinen Augen 
das gleiche nochmals schicken.

Kann mir das bitte jemand erklären?

Gruß
Gerhard

[Yvo C. (Firma: www.twipnet.ch/) (majortwip)]

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

[Gerhard (Gast)]

Hallo,

lang nicht mehr rein geschaut hier...
Aber Antwort auf meine Frage kam leider eh keine. Das böse Wort "Bascom" 
schreckt hier wohl ab. Schade.

Mittlerweile hab ich, soweit ich es beurteilen kann, die Init richtig 
programmiert. Die Register sollten alle stimmen.

Meine Senderoutine funktioniert bereits. Die unterschiedlichen IRQ´s 
kommen, das Programm reagiert darauf korrekt. Ich sende dort immer 5 
Bytes, wobei eins ein Zähler ist, der bei jedem Durchgang inkrementiert 
wird.

Mein Empfänger tut noch nicht so wie er soll. Er empfängt immer 3 Pakete 
hintereinander korrekt, danach kommt der IRQ nicht mehr, obwohl im 
Fifo-Statusregister drin steht, daß das TX-Fifo voll ist.
Ich beschreib hier mal mein Empfangsroutine, vielleicht fällt jemandem 
was auf:
in einer Endlosschleife frage ich den IRQ-Pin ab. Ist dieser 0, frage 
ich R_RX_PL_WID, also die Paketlänge, ab. Soviele Bytes Payload lese ich 
dann aus dem Fifo aus. Danach schreibe ich eine 1 ins Status-Register 
ins RX_DR-Bit, um den IRQ zurückzusetzen.

Was hab ich vergessen oder was mach ich falsch?
Hier mal die Beispiel-Routine von HopeRF in C:

void Receive_Packet(void)
{
  UINT8 len,i,sta,fifo_sta,value,chksum,aa;
  UINT8 rx_buf[MAX_PACKET_LEN];

  sta=SPI_Read_Reg(STATUS);  // read register STATUS's value

  if((STATUS_RX_DR&sta) == 0x40)        // if receive data ready (RX_DR) interrupt
  {
    do
    {
      len=SPI_Read_Reg(R_RX_PL_WID_CMD);  // read len

      if(len<=MAX_PACKET_LEN)
      {
        SPI_Read_Buf(RD_RX_PLOAD,rx_buf,len);// read receive payload from RX_FIFO buffer
      }
      else
      {
        SPI_Write_Reg(FLUSH_RX,0);//flush Rx
      }

      fifo_sta=SPI_Read_Reg(FIFO_STATUS);  // read register FIFO_STATUS's value
              
    }while((fifo_sta&FIFO_STATUS_RX_EMPTY)==0); //while not empty
    
    chksum = 0;
    for(i=0;i<16;i++)
    {
      chksum +=rx_buf[i]; 
    }
    if(chksum==rx_buf[16]&&rx_buf[0]==0x30)
    {
      GREEN_LED = 1;
      delay_50ms();
      delay_50ms();
      GREEN_LED = 0;

      //Send_Packet(W_TX_PAYLOAD_NOACK_CMD,rx_buf,17);
      //SwitchToRxMode();//switch to RX mode  
    }  
  }
  SPI_Write_Reg(WRITE_REG|STATUS,sta);// clear RX_DR or TX_DS or MAX_RT interrupt flag  
}

ich habe diese Schleife noch nicht verstanden:

while((fifo_sta&FIFO_STATUS_RX_EMPTY)==0); //while not empty

Fas Fifo wird doch ausgelesen. Warum wird dann nochmals nachgeschaut, 
ob´s wirklich leer ist?

@Yvo: wenn das Ganze mal funktioniert, bereite ich den Code auf 
(Ausmisten und Kommentieren) und stell ihn in die Codesammlung ein. 
Versprochen.


Gruß
Gerhard

[Gerhard (Gast)]

Yvo Comte schrieb:
> 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.

Mir hilft auch keiner...
Wünsch Dir viel Spaß mit dem Datenblatt !!!


Gruß
Gerhard

[Yvo C. (Firma: www.twipnet.ch/) (majortwip)]

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

[Ulf (Gast)]

Hallo Gerhard

zum Init:
Die ersten drei Zeilen Kommandos werden nicht kompiliert, weil die in 
Kommentar-zeichen stehen.
/*  Kommentar Anfang
*/  Kommentar Ende

zum while

((fifo_sta&FIFO_STATUS_RX_EMPTY)==0);

Hier wir einfach geprüft, ob die Fifo-Queue leer ist. Wenn Du sicher 
stellen kannst, daß dein Speicher bei

SPI_Read_Buf(RD_RX_PLOAD,rx_buf,len);

 immer größer/gleich den übertragegen Bytes ist, dann kannst Du dir das

while((fifo_sta&FIFO_STATUS_RX_EMPTY)==0);

 vermutlich auch sparen.

Gruß Ulf

[Manfred (Gast)]

Hallo,

ich habe bisher erfolglos versucht, zwei RFM70 mit einem PIC-Controler 
zum laufen zu bringen. Irgend wie werde ich es schon schaffen. Dazu aber 
eine prinzipielle Frage: Was ist die maxmimale Geschwindigkeit, die ich 
mit den RFM70 erreichen kann? Ich meine damit, wie oft kann oder besser 
darf ich senden und wie schnell wird es gehen, wenn ich einen 
Sende/Empfangszyklus betrachte. Meine Datennutzlast wäre ca. 6-8 Byte.
Vielen Dank für eine Antwort

Gruß Manfred

[Gerhard (Gast)]

Hi,

wie schnell das geht, hab ich noch nicht probiert. Momentan sende ich 25 
mal pro Sekunde. Dabei ist aber ein recht umfangreiches Programm im µC 
die Bremse.
Wie oft willst Du senden?


Gruß
Gerhard

[Manfred (Gast)]

Hi,

ich habe die beiden Module jetzt am laufen mit einem PIC16F819 (es lag 
daran, dass ein Modul prinzipiell nicht ok war - Lötproblem). Ich sende 
jetzt wie in dem Beispiel von hoperf 17 Byte, aber alle 100msek. Klappt 
prima, dass 2. Modul schickt den gleichen String zurück und ich komme 
auf eine Gesamtzeit von ca. 70msek.

Gruß
Manfred

[Gerhard (Gast)]

Hi,

mit welcher Datenrate braucht er 70 msek? (Register 6 - air data rate)


Gruß
Gerhard

[Manfred (Gast)]

Hi,

das Register 6 steht auf 0x17, also 1Mbps. Ich meinte mit 70msek aber 
einen gesamten Zyklus vom Senden des Masters, Empfang beim Slave, 
Antwort (also Senden) des Slaves bis zum Empfang der Antwort beim 
Master.

Gruß
Manfred

[Gerhard (Gast)]

Dann sind das aber eigentlich 2 Sendungen, wenn ich dich richtig 
verstehe:
- Du sendest 17 Byte
- der Slave sendet das ACK
- danach sendet der Slave die 17 Byte zurück
- der Master sendet das ACK zum Slave

Meiner Meinung nach ist das eine mehr als ausreichende Performance.


Gruß
Gerhard

[Ulf (Gast)]

Hallo

Wenn Manfred mit dem Beispiel von Hope gearbeitet hat, ist da unter 
Umständen im NoACK-Mode gearbeitet worden. Das war meines Wissens die 
default-Einstellung im Beispiel-code.
Das mit dem ACK funktioniert aber super. Wenn es mehr auf die Sicherheit 
der Übertragung ankommt, würde ich das auf jeden Fall empfehlen.

Gruß Ulf

[Manfred (Gast)]

Hallo,

das Senden funktioniert wie von Gerhard beschrieben und ich arbeite 
wirklich mit dem Beispielcode von Hope. Da wird mit dem NoACK-Mode 
gearbeitet. Wird denn die gesamte Übertragungszeit länger, wenn ich mit 
dem ACK-Mode arbeiten würde? Warum ist dieser Mode sicherer, ich kann 
doch die Datenübertragung inhaltlich z.B. mit einer Checksumme 
überprüfen. Oder geht es um die Sicherheit der Übertragung auf der 
"Funkstrecke"? Was hat der ACK-Mode sonst für Vorteile?

Gruß
Manfred

[Ulf (Gast)]

Hallo Manfred

Das praktische am ACK mode ist, daß der Empfänger gleich die korrekte 
Übertragung quittiert, bzw. bei einer fehlerhaften Übertragung diese 
nochmals anstößt. Wie oft er das macht kann eingestellt werden. Ein 
weiterer Vorteil ist, daß Sende- und Empfangsrichtung nicht umgeschatet 
werden müssen, sondern das automatisch passiert. Zusätzlich hat man auch 
noch die Möglichkeit, beim ACK Daten mit zurück zu schicken. Auch hier 
müßte die Sende- und Empfangsrichtung nicht umgeschaltet werden.
Der Empfänger kann selbstverständlich auch mit einer CS prüfen, muß dann 
aber ggf. dem Sender erst noch mitteilen, daß was falsch war. Das muß 
alles in der SW gehandhabt werden. Im ACK-Mode macht das das Funkmodul 
autark.

Gruß Ulf

[Manfred (Gast)]

Hallo Ulf,

danke für die Tips. Ich werde demnächst mein Projekt mal versuchweise 
umstellen, habe aber im Moment nicht mehr die Zeit dazu.

Gruß
Manfred

[Yvu (Gast)]

Hei Ulf.
Du sagst,dass beim Ack gleich Daten zurückgesendet werden können.
Sind das die die beim Empfangen schon im TXpayload liegen? Kann man das 
Ack hinauszögern damit der uC noch schnell das Payload schreiben kann?

Jetzt ist ja:
Daten (gefehl "sende mir inhalt PinC") -->
Ack <--
uC liest RXFIFO, arbeitet, Schreibt TXFIFO
Daten (pinC) <--
Ack -->

Aber praktisch wäre ja:
Daten(sende mir xxx) -->
uC ....
Ack + Daten (pinx) <--
(Ack -->)

Gruss Yvo

[Ulf (Gast)]

Yvu schrieb:
> Aber praktisch wäre ja:
> Daten(sende mir xxx) -->
> uC ....
> Ack + Daten (pinx) <--
> (Ack

Hallo Yve

Genau so passiert das auch. Das ACK läßt sich aber nicht "rauszögern". 
Die Daten, die im ACK mit zurück geschickt werden, müssen praktisch 
schon vor dem Empfang der Daten bereit liegen. Das eignet sich daher 
nicht so als "Antwort", als vielmehr um z.B. zeitunkritische 
Satutsangaben vom Empfänger zum Sender zu schicken, wie z.B. der 
Batteriestand oder so was.
Weiter oben ist mir da schon von Holger geholfen worden. Am besten Du 
schaust Dir erst mal die Beiträge ab 
Beitrag "Re: Hat jemand Erfahrung mit dem 2,4GHz-Transceiver RFM70?" an. Da wurde ich von 
Holger recht gut auf die Schiene gesetzt. Wenn das nicht reicht, einfach 
nochmal hier schreiben. Dann müßte ich mich aber auch erst mal wieder in 
meine source reinfinden ;-).

Gruß Ulf

[Ulf L. (ulf_l)]

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

[Yvu (Gast)]

So, habs nun hingekriegt mit dem Code von hoperf.
Nun die Frage. Ich habe eine Zentrale mit nem rfm, rundherum mehrere 
slaves.
Sagen wir Master 1 mit Slaves 2 - 5.
Will ich nun an Slave 2 was senden muss tx vom Master 2 sein, ebenso 
dessen Rx0 wegen dem Autoack. Will ich nun an Slave 3 senden ist des 
Masters tx und rx0 auf 3.
Tx und rx0 bleiben im Slave auf 1,  rx1 ist 2(oder3...)
Rx1 vom Master auf 1.
Hab ich das richtig verstanden? Kann ich denn noch nach dem activate die 
tx und rx0 ändern?
Danke im Voraus!
Yvo

[H. G. (ledi)]

Ja, genau so!

Tx und Rx0 kannst du jederzeit ändern.

[Gerhard (Gast)]

Hallo,

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.
Was glaubt ihr, werden sie es überleben?


Gruß
Gerhard

[Harald F. (harald_f)]

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

[Stefan V. (zeh)]

> 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 ;-)

[Moritz Bente (Gast)]

Hallo Allerseits,

ich versuche verzweifelt eine Funkverbindung zwischen 2 RFM70 aufzubauen 
und es klappt nicht. Vielleicht kann mir jemand helfen?

Meine Konfiguration:
2x PIC18 mit RFM70 und Hope Quellcode

Es funktioniert:
SPI Kommunikation
- Kann Status register und alle Register lesen und schreiben. 
Stromverbrauch im RX mode steigt auch an bei beiden Modulen.
Habe den Quellcode von HOPE übernommen und alle Signale (SPI) auch 
überprüft dadurch das ich die STATUS Register (STATUS und FIFO STATUS) 
auch korrekt auslesen kann gehe ich zu 99% davon aus das die SPI 
Übertragung funktioniert.

Mein Problem ist wie folgt zu beschreiben:
Der Beispielcode sendet mit 1Hz ein test packet mit 17 Byte daten,
die rote LED blinkt. Der FIFO STATUS ändert sich dabei nicht. 
(TX&RX-FIFO EMPTY) STATUS REGISTER = 0x0E. Bei beiden Konfigurationen 
gleiches Ergebnis.
Auf der Empfangsseite ändert sich der STATUS auch nicht. Auf der 
Empfangsseite läuft der SELBE code nur dass das Programm 
SUB_PROGRAMM_1HZ auskommentiert ist.

Ist die Konfiguration überhaupt in der Lage zu funktionieren ohne das 
ich Sender und Empfänger entsprechend anpasse? Ich habe die Include 
Dateien vom Hope Beispiel Slave und Master auch schon probiert, keine 
andere Reaktion, Habe es auch mit einem Anderen Modul probiert keine 
Reaktion.

Habe auch schon auf AutoACK umgestellt und mir Register 0x08 ausgeben 
lassen. Folge war das der Counter hochzählt, da kein ACK zurückgekommen 
ist. Ein weiteres Indiez dafür das die SPI Kommunikation funktioniert.

Ich hoffe es hat jemand von euch eine IDEE warum ich hier hänge und 
nichts gesendet und empfangen wird.

Viele Grüße !

M. Bente

[Gerhard (Gast)]

Moritz Bente schrieb:
> Ist die Konfiguration überhaupt in der Lage zu funktionieren ohne das
>
> ich Sender und Empfänger entsprechend anpasse?

Hi,

also ich nutze auch für TX und RX die gleiche Init, lediglich in Bank 0 
Register 00 wird das letzte Bit unterschiedlich beschrieben.

Stell doch mal einen Register-Dump ein. So könnte man am einfachsten 
Vergleichen.
Ansonsten schlag ich vor, daß Du diesen Thread durchstudierst, sind 
schon viele Hinweise aufgeführt.


Gruß
Gerhard

[Moritz B. (interuper007)]

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

[Gerhard (Gast)]

ich hab das ganze in Bascom gemacht, tue mich schwer beim lesen von 
C-Code. Da wird bestimmt noch jemand anderes mit einsteigen.

Ich wär aber trotzdem noch für ein Register-Dump.


Gruß
Gerhard

[Moritz B. (interuper007)]

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!

[Moritz B. (interuper007)]

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

[Gerhard (Gast)]

Kontrolliere doch mal, ab auch wirklich die Bank1-Bytes in der richtigen 
Reihenfolge gesendet werden:
Zitat Datenblatt:
Note: The SPI timing is for bank 0 and register 9 to 14 at bank 1. For 
register 0 to 8 at bank 1, the byte order is inversed that the MSB byte 
is R/W before LSB byte.

Bank0 schaut eigentlich gut aus, vorausgesetzt Register 0 ist beim TX 
auf 0x0E gesetzt und RX- und TX-Adresse stimmen überein.

Dann noch die spontane Frage, ob Du "Activate" sendest, nachdem Du 
Register 1D entsperrt hast.


Gruß
Gerhard

[Andreas (Gast)]

Hallo zusammen!

Hat jemand schon versucht, die SPI des Funkmoduls ohne der Software-SPI 
der Beispielsoftware von HOPE zu realisieren?

Steh gerade vor dem Problem das es mit dem SPI-Interface des ATMegas 
nicht richtig funktioniert. Das Oszi-Bild der MOSI-Leitung zeigt einen 
einwandfreien Signalverlauf. Das Timing ist ansonsten auch in Ordnung, 
allerdings kommt auf der MISO-Leitung nicht das Signal zurück, das man 
erwartet. Die Daten, die von der MISO-Leitung kommen, stimmen leider 
nicht mit dem beschriebenen Byte überein!

Ich würde mich über eure Meinung hierzu sehr freuen...

Gruß
Andreas

void SPI_init (void)
{
  /* Set MOSI, CSN and SCK output, all others input */
  DDRB = (1<<MOSI) | (1<<SCK) | (1<<CE)| (1<<CSN);
  
  /* Set Chip Select to high */
  PORTB |= (1<<CSN);
  
  /* Disable SPI, Master, set clock rate fck/16 */
  SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0);  
}

void SPI_Write_Register (char cRegister, char cData)
{

  PORTB &=~ (1<<CSN);
  _delay_ms(2);
  
  char sende = (cRegister|0x20);
    
  /* Send Register address */
  SPDR = sende;
  /* Wait for transmission complete */
  while (!(SPSR & (1<<SPIF)));

  /* Send information for Register */
  SPDR = cData;
  /* Wait for transmission complete */
  while (!(SPSR & (1<<SPIF)));
  
  _delay_ms(2);
  PORTB |= (1<<CSN);
}

unsigned char SPI_Read_Register (unsigned char addr_Register)
{
  unsigned char value;

  // Activate the CS pin
  PORTB &=~ (1<<CSN);

  // Start Register Address transmission
  SPDR = addr_Register;
  // Wait for transmission complete
  while(!(SPSR & (1<<SPIF)));  
  
  //char status = SPDR;
  op_status = SPDR;
  
  // Start Register Address transmission
  SPDR = 0x00;
  // Wait for transmission complete
  while(!(SPSR & (1<<SPIF)));
  
  value = SPDR;
  
  // CS pin is not active
  PORTB |= (1<<CSN);

  return(value); 
}

[Moritz B. (interuper007)]

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

[Gerhard (Gast)]

Hallo,

Moritz Bente schrieb:
> Meinst du das mit dem ACTIVATE und Entsperren?
Ich meine das SPI-Command "Activate". Siehe Datenblatt Seite 13.

Moritz Bente schrieb:
> Weiß auch noch nicht wie ich überprüfen kann ob nun der Sender nicht
>
> sendet oder der Empfänger nicht empfängt -> ein Teufelskreis.
Du könntest nach dem Du den TX-FiFo beschrieben hast, das Register 17 
auslesen. Dort gibt´s die TX-Full- und TX-Empty-Flags.
Das gleiche gäb´s dort für RX. Dort könntest Du sehen ob Daten 
angekommen sind und nur der IRQ nicht kommt.
Für RX gäb´s auch noch das "R_RX_PL_WID"-Register, das Du auf >0 
überprüfen kannst.

Ansonsten wird´s glaub ich sehr schwierig für uns. Evtl. mal die 
Hardware überprüfen (Lötbrücken und so).


Gruß
Gerhard

[Moritz B. (interuper007)]

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

[Gerhard (Gast)]

nein, das TX-Full kommt erst, wenn kein Speicherplatz mehr frei (ich 
glaub max. 32 Bytes). Für Dich jetzt ohne Belang.

Jetzt musst Du nur noch schauen, warum nicht gesendet wird. Ich zitier 
mal von weiter oben:
Holger Sch. schrieb:
> 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.

Gruß
Gerhard

[Moritz B. (interuper007)]

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

[manchmal (Gast)]

Das Kommando R_RX_PAYLOAD_WID liest aus, wieviele Datenbytes das 
oberste, also das nächste Datenpaket das gelesen wird, hat.
Wenn also per "dynamic payload width" unterschiedlich große Datenpakete 
im RX_FIFO liegen, liefert das Kommando die Payload-Größe des nächsten 
Paketes zurück (1-32 Byte).

[Moritz B. (interuper007)]

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!

[Gerhard (Gast)]

Schön langsam weis ich auch nicht weiter.
Könntest noch den CE-Port des µC kontrollieren, ob dieser tatsächlich 
schaltet.


Gruß
Gerhard

[manchmal (Gast)]

Was macht ihr denn vor der Initialisierung des RFMs ?

Bei mir wird nach dem Anlegen der Spannung 100ms gewartet, dann kommt 
die LCD Init (dauert auch zwischen 100 und 200ms) danach kommt nochmal 
die 100ms Pause und dann die RFM70 Initialisierung.

Und dann setze ich den Chip_Enable-Pin auf High und lasse ihn so.

[Moritz B. (interuper007)]

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.

[Gerhard (Gast)]

ich glaub aber, daß der CE Port auf 0 sein muß, während der Fifo gefüllt 
wird. Danach für 1 mS auf 1 und wieder zurück auf 0. So funktioniert´s 
bei mir zumindest.

[Moritz B. (interuper007)]

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

-> keine Änderung zu vorher.

[Gerhard (Gast)]

ich hab bei mir nach dem Fifo-Schreiben noch 2ms delay drin. Ob das 
nötig ist?
hab momentan keine Einfälle mehr.

[Eike J. (Gast)]

Nur mal als Hinweis: Der Interupt-Pin IRQ ist in dem Beispiel vom Hope 
so maskiert, dass er einen active-low Impuls gibt, wenn erfolgreich 
gesendet ODER empfangen wurde. So muss man zur Kontrolle nicht die 
Register auslesen, sondern braucht nur beim Sender und Empfänger diesen 
Pin "überwachen".

[manchmal (Gast)]

Der Chip Enable Pin CE kann dauerhaft aktiv sein !!!

Senden tue ich so:
1. das Bit TX_DS (Bit 5) im Status Register prüfen.
2. wenn es "0" ist per W_TX_PAYLOAD Kommando Daten in den TX_FIFO 
schreiben
3. warten bis das Senden fertig ist. Der IRQ Pin wird dann Low
4. den IRQ löschen (Bit5, TX_DS im Status Register auf "1" setzen)
usw... 1. 2. 3. 4. ....

Für Reichweitentests, bei denen das Auto_ACK evtl. nicht mehr 
zurückkommt schreibe ich mit dem Kommando W_TX_PAYLOAD_NOACK. Dadurch 
wird für dieses Paket die AUTOACK Funktionalität deaktiviert.
Der Sender sendet dann ohne Rücksicht auf "Daten"-Verluste.
Mit dem Empfänger kann ich dann prüfen, wo ich Empfang habe.

[Moritz B. (interuper007)]

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 !

[Eike J. (Gast)]

Naja das würde bedeuten, dass das Senden schon mal klappt. Dann haste ja 
schon die Hälfte geschafft^^

[Gerhard (Gast)]

ich glaub eher, daß es nicht direkt am Code bzw. am Verfahren direkt 
liegt. Da ist irgendein blöder Fehler drin, den Du finden mußt. Oder 
irgendwas in Hardware.
Du hast nachgewiesen, daß die SPI-Kommunikation klappt, CE-Pin schaltet, 
Register sind gesetzt. Was Du noch nicht beantwortet hast, ist das Thema 
mit dem Activate-Command.

Hättest Du vielleicht einen Atmega? Dann könnte ich Dir ein Hex 
erstellen.
Wär viel einfacher und schneller als der Postweg.


Gruß
Gerhard

[Gerhard (Gast)]

... jetzt war ich zu langsam...

[Moritz B. (interuper007)]

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

[Moritz B. (interuper007)]

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

[Gerhard (Gast)]

Hallo Moritz,

mit C kann ich Dir leider gar nicht helfen.
Falls Du Bascom lesen kannst, könntest Du hiermit mal vergleichen:
http://www.mcselec.com/index.php?option=com_content&task=view&id=212&Itemid=57
Es geht dort zwar um den nRF24L01, das Vorgehen ist das Gleiche. Für´s 
RFM70 müssen nur mehr Register bei der Init gesetzt werden.
In der "Main_tx:" ist das vorgehen beim Senden - für mich - schön 
abgebilet.


Gruß und viel Glück
Gerhard

[Moritz B. (interuper007)]

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

[Gerhard (Gast)]

O.K., TX_DS kommt. Sendest Du mit AutoAck?
Das würde bedeuten, daß der Empfänger das ACK zurückgeschickt hat, und 
somit die Daten auch fehlerfrei angekommen sind.

[Moritz B. (interuper007)]

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.

[Gerhard (Gast)]

Hallo,

hast Du schon mal versucht, TX und RX zu tauschen? Ich meine dabei nicht 
nur die RFM-Module zu tauschen, sondern den Aufbau zu lassen und im 
Empfänger-µC den Sender-Code einzuspielen und umgekehrt. Wäre mal 
interessant ob dann der TX_DS-IRQ auch ncoh kommt.

Gerhard schrieb:
> also ich nutze auch für TX und RX die gleiche Init, lediglich in Bank 0
> Register 00 wird das letzte Bit unterschiedlich beschrieben.
ist das bei dir tatsächlich so?
ist der Channel,die TX- und die RX0-Adresse bei beiden tatsächlich 
gleich?

Was macht eigentlich der FIFI-Status im RX? Gibt´s dort eine 
Veränderung?


Gruß
Gerhard

[Moritz B. (interuper007)]

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

[Hope (Gast)]

Vor ca. einer Woche hatte ich in einem anderen Beitrag zum RFM70 meine 
Vorgehensweise zur Initialisierung der beiden Module ausführlich 
beschrieben.
Vor allem auch, wo und warum ich vom Hope-Beispiel abweiche (es werden 
z.B Register oder Bits beschrieben oder gesetzt, die "read only" sind), 
warum auch immer.
Und diese für manchen wohl hilfreiche Antwort, bzw. der Beitrag wurde 
entfernt ??????????

[Harald (Gast)]

Hi, im Hopebeispiel sind bei der Init noch einige Zahlendreher 
(Beispeilcode vs. Datenblatt) drin; manche wirken sich nur auf RX andere 
auf TX aus, und manche haben überhaupt keinen Einfluss.

Ist nicht ganz einfach letztlich was zum Laufen zu bringen.

[Gerhard (Gast)]

Hi,

also wenn Du TX und RX tauscht und jedesmal der TX_DS-IRQ kommt, glaub 
ich kannst Du die Hardware als Fehlerursache erst mal ausschliessen.
Meiner Meinung nach wäre es jetzt angebracht, wenn Du beide Codes hier 
reinstellst. Sonst rätseln wir an Heilig Abend immer noch rum.


Gruß
Gerhard

[Gerhard (Gast)]

hier ist noch ein Fehler drin:

Moritz Bente schrieb:
> 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, <---------------- Fehler !!!
> 0xA67F0624,
> 0x00000000,
> 0x00000000,
> 0x00000000,
> 0x00000000,
> 0x00000000,
> 0x00000000,
> 0x00127300,
> 0x36B48000,
> };

in der markierten Zeile muß stehen:
0x0B869E_F_9


Gruß
Gerhard

[Harald (Gast)]

Hi Gerhard, dieser Fehle rist mir auch aufgefallen, hat aber keinen 
Einfluss auf die Funktion (weder bei RX noch TX). Aber bei den 
zusätzlichen Registern, die gegenüber dem Original IC (US Produkt) 
beschrieben werden obwohl sie read only sind, liegt wohl noch einiges im 
Argen - wieso wehlab warum-. Geht in die Richtung, die oben HOPE 
beschrieben hat. Ich hatte vor ein paar Wochen meine Anwendung für einen 
ganz einfachen fall zum Laufen gebracht, mit viel Probieren und 
rumändern, steige doch aber nochmals wegen der Antennenpositionierung 
auf RFM12xx um. Baut man den RFM70 in ein gehäuse ein, so bricht die 
Reichweite komplett ein (bei Sichtverbindung TX -RX und damit meine ich 
wirklich direkte Sichtverbindung der beiden ICs) erreichte ich über 30 
Meter, im Plastikgehäuse mit etwas Metall als Befestigung ist das Ganze 
auf wenige Meter geschrumpft. Bei externer Antenne wäre das nicht 
passiert.

[Gerhard (Gast)]

hier gibt´s noch nen anderen Thread, in dem auch die F9 verwendet wird. 
Außerdem sind dort die Bytes für Bank 1 in der gedrehten Reihenfolge 
gezeigt.
Beitrag "Re: RFM70-Funkmodul funkt nicht!"
Vielleicht hilft´s ;-)

[Michael 9. (michael93)]

Hi,

dieser Thread hier ist echt hilfreich, vielen Dank dafür.

Nichtsdestotrotz will es bei mir nicht richtig funktionieren und ich 
glaube ich seh den Wald vor lauter Bäumen nicht mehr. Wäre also echt 
nett wenn einer von euch mal über meinen Code schauen könnte. Die Init 
der Bank 1 hab ich fast vollständig aus dem Beispielcode von Hope 
entnommen. Der Rest ist an den Beispielcode angelehnt. Die Init Bank 0 
hab ich etwas abgeändert, aber lt. Datenblatt sollten die Werte so alle 
i. O. sein.

Das komische ist, dass der Sender zu senden scheint. Im OBSERVE-TX 
Register, welches ich mir per UART an den PC ausgeben lasse zählt 
einwandfrei die Sendeversuche hoch. Am Empfänger passiert aber nichts 
(FIFO-STATUS Register).

Vielen Dank schonmal,
Michael

[Gerhard (Gast)]

Hi Michael,

kennen uns ja aus dem Modellbauforum.
Ich tue mich sehr schwer, euer C zu lesen. Ist für mich wie ne 
Fremdsprache.
Was ich nicht verstehe, warum du 2 unterschiedliche Init´s verwendest. 
Initiiere doch RX und TX mal mit der gleichen Init, nur das Register 0 
der Bank 0 muß im letzten Bit jeweils für TX oder RX gesetzt werden. 
Sonst können beide 100% gleich sein.
Weiterhin sendest du Activate, ohne vorhin zu Prüfen ob es nötig ist. 
Bin mir nicht sicher welche Auswirkung dies hat.

Dann: in der TX-Main verwendest Du folgende Zeile:

rfm70_W_REGISTER(CONFIG, ((1 << EN_CRC) | (1 << CRCO) | (1 << PWR_UP)));// | (1 << PRIM_RX)));

fehlt da nicht zum Schluß das letzte Bit, die "0" für PTX.
Wie gesagt, ist halt in C geschrieben, und ich kann das nicht 
zweifelsfrei deuten.

Was ich auch nicht finden kann, ist wo die TX-Adressen gesetz werden. 
RX_ADDR_P0 und P1 hab ich gefunden, aber TX_ADDR nicht.

Welchen µC verwendest Du? Bestimmt einen Atmega. Ich könnte Dir einen 
Code für den Empfänger stricken, dann wüsstest Du wenigstens ob der TX 
wirklich sendet.


Gruß und gute Nacht
Gerhard

[Johannes S. (johnjohn)]

Hallo,

Im "Projekt-Blog von Daniel Weber"(projects.web4clans.com/) gibts einen 
kurzen Artikel bezüglich RFM70 Funkmodul. Dort findet sich auch ein 
Verweis auf eine "RFM70 Arduino Library".
Im Artikel schreibt Daniel er habe auf Basis dieser Library eine eigene, 
für den ATmega32 geschreiben. Leider gibt es noch keine Downloads und 
Beispiele für letztere.


RFM70 Funkmodul Artikel[http://projects.web4clans.com/]
http://projects.web4clans.com/index.php/projekte/rfm70-funkmodul

Arduino RFM70 Library[http://code.google.com/]
http://code.google.com/p/odobot1/source/browse/#hg%2Flibraries%2Frfm70


Was haltet ihr von dieser "Arduinio Library"?
Brauchbar?


Freundliche Grüße,
Johannes

[Gerhard (Gast)]

Hi,

es zeigt zumindest ein vollständiges, hoffentlich funktionierendes 
Beispiel. Man muß es halt trotzdem noch auf seine Bedürnisse zustricken. 
Also Hausaufgaben machen und Datenblatt lesen + verstehen bleibt nicht 
aus.

Hier wird übrigends an der fraglichen Stelle der Bank-1-Init die "B9" 
verwendet. Somit das dritte Beispiel: B9, D9 und F9


Gruß
Gerhard

[Hope (Gast)]

Gerhard schrieb:
>> 0x0B869ED9, <---------------- Fehler !!!

Also ich sende hier 0x D9 9E 86 0B , wie es im Datenblatt steht (MSB 
zuerst)
und damit läuft alles prima.

[Gerhard (Gast)]

Gerhard schrieb:
> Hier wird übrigends an der fraglichen Stelle der Bank-1-Init die "B9"
> verwendet. Somit das dritte Beispiel: B9, D9 und F9

anscheinend ist alles möglich :-/
hab gestern mal getestet. D9 und F9. Kein Unterschied.


Gruß
Gerhard

[Harald (Gast)]

Hallo Gerhard,

ich hatte ja oben schon erwähnt, dass die beiden Bytes völlig belanglos 
sind für RX und TX - s. Originalhersteller des Bauteils. Eigentlich sind 
dies Read only Register, es weiss offenbar eh keiner, wieso diese 
überhaupt beschrieben werden müssen.

Gruß
Harald

[Michael 9. (michael93)]

Hi,

Gerhard, vielen Dank für deine Tipps, die haben mir sehr geholfen. Ich 
glaub das bisschen das gefehlt hat war (auch?) dass ich irgendwie nach 
der eigentlichen Init, die das Modul da in den Empfangsmodus schicken 
sollte, das PRX-Bit in CONFIG nochmal setzen muss. Jetzt klappts 
jedenfalls und bei meinem Empfänger kommt munter "Hello World!" an. Dann 
kanns mit dem eigentlichen Projekt eigentlich so langsam auch bei mir 
losgehen.

Viele Grüße,
Michael

[Gerhard (Gast)]

Hi Michael,

Glückwunsch !!!
und ich freu mich schon auf ein gemeinsames Layout :-)


Gruß
Gerhard

[Moritz B. (interuper007)]

Hallo!

Freut mich das es mal wieder einen Erfolg zu verzeichnen gibt! Auf 
welchem µC hast du es zum laufen gebracht? Und welcher Compiler wäre 
auch noch Interessant.
- Bei mir gibt es leider nichts neues -
Habe mit den D9, F9, B9 mal rumprobiert aber meinen Empfänger 
interessiert das nichts. Bin nach wie vor ohne konkreten Plan wie ich 
jetzt weitermachen soll. Aber trotzdem vielen Dank für die bisherige 
Anteilnahme vor allem @Gerhard!

Wenn noch jemandem etwas auffallen sollte oder jemand ne idee hat. Ich 
hänge mal meine Quellcode Dateien mit an. Sind jedoch zu ca. 99% die 
Beispielcode Dateien von Hope!
zu den Dateien: Die RFM70.h und RFM70_init.c sind 100% gleich deshalb 
habe ich sie nicht doppelt angehängt.
Die Verdrahtung ist wie in dem Code beschrieben(Hope-Beispiel)
main-master.c ist die "main" für den Sender
main-slave.c ist die "main" für den Empfänger

Vielen Dank schonmal im Vorraus

Moritz

[Michael 9. (michael93)]

Hi,

also meine RFMs laufen jeweils an einem ATMega32, einmal am STK500 und 
einmal an einem Selfmade-Board. Als Compiler verwende ich den avr-gcc 
den Ubuntu Natty mitbringt.

@Moritz: Deinen Code hab ich jetzt nicht genau gelesen, aber ich habe 
einen Tipp für dich, der mir öfters mal hilft: Lass dir über den UART 
(wen du einen zur Verfügung hast) Debugmeldungen ausgeben. Besonders 
wichtig sind da die diversen Status Register des RFM, die man sich an 
bestimmten Stellen ausgeben lassen sollte. Nur so weiß man besser, was 
IM RFM so passiert.

@Gerhard: Layouts sind bereits in arbeit, aber das für den Sender ist 
nicht so simpel, weil alles in das Gehäuse reingehen musst, das du im 
Modellbauforum gepostet hast - mit genau dem Akku und dem Display. 
Deshalb werden es dafür wohl sogar zwei getrennt, höhenversetzt 
montierte Platinen.

Grüße,
Michael

[Gerhard (Gast)]

Michael 93 schrieb:
> Deshalb werden es dafür wohl sogar zwei getrennt, höhenversetzt
> montierte Platinen.

Hi,

musste ich auch machen, da die Kreuzknüppel viel höher sind als das 
Display.
Die Höhe von Akku + Platine + Kreuzknüppel ist schon grenzwertig für das 
Gehäuse. Ich werde wohl meinen Lipo aufmachen und die Zellen 
nebeneinander einbauen.

@Moritz: mein Angebot, dir ein HEX-File für einen Atmega zu erstellen, 
steht immer noch. Deinen Code werd ich mir später mal anschauen.


Gruß
Gerhard

[Harald (Gast)]

Hallo Moritz,
habe mir deinen Code mal angesehen. Der ist ja soweit ich sehen konnte 
identishc mit dem Hope Code. Sollte so funktionieren. Ich vermute, dass 
dein TX noch nicht sauber sendet. Ich würde mal den Interrupt völlig 
deaktivieren und stattdessen in einer Warteschleife zyklisch alle 1 sec 
ein Datensatz versenden. Auch das Receive im Sender nach dem Senden 
würde ich mal deaktivieren und nur dafür sorgen dass mal sauber gesendet 
wird. In diesem Falle muss am INTR Pin ein periodischer Low Impuls 
anliegen (Oszi). Wenn du das ereicht ahst, machst du am Empfänger 
weiter.

Gruß
Harald

[Moritz B. (interuper007)]

Hallo!
Hab ich gemacht der Sender sendet nun dauerhaft und ich habe im Register 
Null mal im Sender nur den TX_DS Interupt angemacht. Am Interupt Pin des 
TX-Moduls bekomme ich auch eine Periodische Null! Der Empfänger macht 
jedoch immernoch nichts.

Grüße Moritz

[Harald (Gast)]

Dann greife mal Zwischenwerte im Empfänger ab mit LED Anzeige.Momentan 
geht ja nur eine LED an, wenn was sauber empfangen wird und eine wennwas 
sauber vom Empfänger wieder zurückgesendet wird. Lass dir mal mittels 
LED anzeigen, ob überhaupt was empfangen wird (Empfangsregister nicht 
null).

[Moritz B. (interuper007)]

Also momentan lasse ich mir auf dem PORTC den FIFO Status ausgeben! Der 
zeigt die ganze zeit 0x11! Also RX Empty und TX Empty. Auch wenn ich 
nicht zu Receive_packet gehe. Die ganze Zeit 0x11. Normalerweise müsste 
er ja wenigstens da eine Reaktion zeigen, oder?

[Harald (Gast)]

Ja. Ich nutze den PIC16F876...ich könnte dir den HEX Code für den 
Empfänger schicken. ich nutze aber nicht die gleichen PIC Pins zum RFM 
wie Hope. Müsste nochmal schauen, denke es war der PORT C und die POrt B 
Pins für die LEDs...müsste aber nochmal gucken.

[Moritz B. (interuper007)]

Jau das wäre super einen 18f876 habe ich da. Aber der hat keinen 
internen Oszillator, oder? Müsste ich dann die beschaltung noch genau 
bekommen!? Das wäre ja SUPER!

Grüße Moritz

[Harald (Gast)]

ich habe den 16F nicht 18F...aber die sind eventuell kompatibel, den AD 
Wandler musst eich auch deaktivieren , denke mal die sind 
kompatibel...überleg dirs mal, dann schicke ich dir morgen den hex code 
mit einer kurzen pinbelegung...hatte vor Wochen damit gearbeitet aber 
dann auf RFM12 umgestiegen wegen dem oben beschriebenen Antennenproblem

[Moritz B. (interuper007)]

Sorry, habe mich vertippt habe natürlich den 16f876 da. Also sollte 
funktionieren wenn du mir die Außenbeschaltung beschreibst. Wäre super!

Moritz

[Hope (Gast)]

Hope schrieb:
> Und diese für manchen wohl hilfreiche Antwort, bzw. der Beitrag wurde
> entfernt ??????????

oder er ist wieder aufgetaucht oder ich war nur zu dumm zum richtig 
suchen.
den hier meinte ich:

Beitrag "Arduino RFM70"

Die Controller sind PIC16F690er und die Programmierung habe ich mit 
Assembler selbst gemacht und nicht die hope Beispiele verwendet.
Vielleicht lief es deshalb innerhalb kürzester Zeit.

[Hope (Gast)]

Anbei noch ein paar Anregungen zur Montage der RFM70 SMD Module auf 
2,54mm Lochrasterplatinen oder an Flachbandkabel.

[Moritz B. (interuper007)]

Hallo ich bins mal wieder!
Habe einen kleinen Erfolg zu berichten. Habe mir 16F690 PIC's besorgt 
und den HOPE Code hinein gebrannt. Um überhaupt mal irgendwas zum laufen 
zu bringen und siehe da es funktioniert auf Anhieb einwandfrei! Jetzt 
werde ich versuchen Herauszufinden was beim Portieren auf die 18er Serie 
schief geht! Melde mich wenn ich es gefunden habe. Kann ja fast nur ne 
Compiler Eigenart sein.

Schöne Grüße

Moritz

[Daniel Weber (Gast)]

Hallo zusammen,

auf meiner oben erwähnten Seite finden sich jetzt auch die Quellcodes 
und ein Beispiel.

http://projects.web4clans.com
Direkter Link: http://projects.web4clans.com/?p=90

Viele Grüße
Daniel Weber

[CK (Gast)]

Hallo,

Ich versuche mich schon eine Woche an einer Kommunikation zweier RFM70 
Modulen mit Atmega32. Könnte mir jemand vielleicht einen fertigen C-Code 
zur Verfügung stellen??? Ein fertiges Avr-Projekt wäre natürlich ein 
Traum.

[P. Becker (Gast)]

der Code auf der oben genannten Seite ist doch vollständig. Das 
Einbinden in ein Projekt sollte doch kein Problem sein??

[Max D. (max_d)]

Der Chip auf dem RFM70 ist übrigens ein BK2421 von Beken.
Auf Ebay gibt's funkmodule vom Chinesen mit dem Chip drauf. Eine (lange) 
Suche nach dem Datenblatt von dem Chip ergab schnell eine auffällige 
Ähnlichkeit zu den RFMs, sogar die (sogar im rfm-dbl so genannte) beken 
Chip-Id (oder so ähnlich) ist identisch...
die chinesen module kosten 1,50€ und haben direkt dip pinout.

[Daniel Weber (Gast)]

hast du den Link oder genaue Bezeichnung da?

[g457 (Gast)]

> BK2421 [..] (lange) Suche nach dem Datenblatt [..]

Das Datenplatt hat tatsächlich eine verdächtige Ähnlichkeit mit dem von 
Hoperf. Ich bin mal so frei und häng den Link mit an, nicht dass sich 
noch wer nen Wolf sucht (war immerhin der zweite Link von Tante gugle 
[2]..).

Nix für ungut.

[1] http://www.szjjxic.com/uploadfile/cfile/201181303858778.pdf
[2] die Zugehörige Anfrage lautet hierzuworkstation 'BK2421 
filetype:pdf'

[Yorom (Gast)]

Ulf L. schrieb:
> 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

Hallo Ulf,

ich versuche auch grad über das ACK Daten an den Sender zurück zu 
schicken.
Ich sende eine 2Byte große Payload an den Sender über das CMD 
W_ACK_PAYLOAD, es kommen aber nur Daten im 2. Byte beim Sender an.
Habe testweise mal eine (ACK)Payload mit TEST[2] = {0xFF, 0xFF} immer 
nach dem Empfangen im RX als ACK in den TXFIFO mit dem CMD von oben 
geschrieben aber es kommt beim Sender immer nur {0x00, 0xFF} an.

Ich weiß das der Thread schon alt ist aber konntets du mehr als 1 Byte 
mit dem ACK übertragen?

Vielen Dank im Voraus.

[ousso b. (ousso_3)]

Hallo,

Ich versuche mich schon zwei Wochen an einer Kommunikation zweier RFM70
Modulen mit Atmega324p.  Wollte gerne den RFM70 Module testen doch 
leider kann ich nur Bascom . Hat jemand Beispielcode dafür?
Ein fertiges Bascom Avr-Projekt wäre natürlich ein Traum.

Vielen Dank im Vorraus
ousso b.

[Michael D. (etzen_michi)]

Nabend.

Arbeite mit den RFM70 aber via GCC.

Habe den Code von 0 auf selber geschrieben gehabt, ich schreibe mal ein 
wenig worauf ich meine das man Achten sollte:


Bei leicht unsauberer Spannung und sehr schnellen Abfragen 
hintereinander hängt sich das Gerät auf und läuft erst wieder nach 
Entladung (Spannungslos mchen und ca.5sec warten).

Versuch erstmal ohne AA und AutoACK zu arbeiten.

Anfangs mit fixen Datenlängen arbeiten.

Den Carrier Detect muss man im Register (fällt mir grad nicht ein) 
freischalten bevor man info bekommt.

[ousso b. (ousso_3)]

hallo Michael D.

ich sende nur 5bytes, ist das ok? ich stelle die bytes in Receive 
address data pipe 0 = Transmit address(reg.10) , das sind meine daten 
&h34 ,&h43 , &h10, &h10, &h01.
und wie kann ich den carrier detect freischalten?
ich versteh auch nicht was soll man mit dem ACTIVATE command machen?

gruß
ousso b.

[freddyv.95 (Gast)]

Hallo Zusammen,
gibts Erfahrungen, welche Datenraten erreicht werden können? Also 
komplett ohne ACK und Checks?
Es geht um eine DMX Übertragung.
Wenn ich mehrere Empfänger auf die Gleiche Adresse setze, empfangen die 
dann auch alle das Gleiche?

Vielen Dank!

[Laserbrenner (Gast)]

Hallo,
ich habe da mal ein eine Frage bezuglich der SPI-Commands, mir ist der 
unterschied/nutzen dieser drei Commands nicht ganz klar, vielleicht 
könnt ihr licht in die Sache bringen?


CMD: W_TX_PAYLOAD_NO ACK
bedeutet doch:
Schreibe zu sendene Daten in Tx-Sendespeicher (FIFO), OHNE eine ACK 
(Empfangsbestätigung)anforderung vom Empfänger.

CMD: W_TX_PAYLOAD
bedeutet doch:
Schreibe zu sendene Daten in Tx-Sendespeicher (FIFO) und hänge eine ACK 
(Empfangsbestätigung)anforderung vom Empfänger an.

CMD: W_ACK_PAYLOAD
bedeutet doch:
Schreibe zu sendene Daten für eine ACK-Antwort, die versendet wird wenn 
ein Datenpacket mit ACK-Bestätigung empfangen wird, zusätzlich kann die 
Sende-PIPE mit ausgewählt werden.

Habe ich die Sache soweit richtig verstanden?

gruß
Matthias