Looking for RFM22B demo code working with PIC

[lcn]

Hello,

I'm fighting against 2 x RFM22B-S2 modules to get them working with a PIC. ( i use a 18F2620 )
I simply would like to get a working demo because i can't get communication working on these modules.

I've spend long time on the datasheet and on the Hoperf demo code without success.
I will really appreciate if someone would share a working demo code, ie sending a demo sentence 'Hello World' to the distant module.

Many thanks for your help,

[robotai]

One guy claimed worked example in below link. But it is in PIC Basic. Hope it help.

http://www.protonbasic.co.uk/showthread.php/62004-Has-anyone-used-the-RFM22-wireless-transceiver-fro-Hope-Electronics

[jamesbond]

I think this can help you. This is for the pic16f610 but i used it in many pics.
It also works whit the rfm23b and rfm23bp (1W  good antenna distance 5Km.)

[lcn]

Thank you  jamesbond,

May i ask you if i may have the entire MPLAB C18 project files please ?

Can you tell me :
what #include <htc.h> is for ?
i also do not see well what 'loop' unsigned char is for.

--

I've planned to use SPI libraries for my project.
Later, i will try to replace the SPI software routine ( write_cmd)  by SPI library once i get the code working.


Many thanks for your help,

[jamesbond]

I have not use it in c18 but i think you can easely export it to c18, or use the xc8 compiler(includes pic18).
#include <htc.h> is used by the hi-tech c compiler.
unsigned char "loop" is used for the const "datasize".
I always use these functions when i start a new rfm22/23 project.
 

[lcn]

Thanks,

As a simple test purpose and in order to validate that SPI communication from Pic to RFM22 modules works well,

I would to light and switch off a led connected to RFM22 GPIO 2 :

I've PIC SPI comms to work in SPI mode 0 at frequency 10 MHz.

According to the datasheet I need to set 0x0D register.
But, I do not understand well what D3 to D0 are for ...

Datasheet page 55 does not light me on these bits. ( gpio2[4] to gpio2[0] )

Register 0x0E is not clear for me as well ...
Can you help me on this please ?

[jamesbond]

I hope this help

http://www.hoperf.com/upload/rf/AN440.pdf   
read page 16 to 19 for gpio in and outputs.
You can use these ports if you have a shortage of ports on your PIC

Its better to process the data in your PIC and do with it what you want.
I use this rfm22 module in a mass product whit a cheap PIC so i do not use the SPI communication.     
Some comments added in the file to clarify.

[lcn]

With the application note i see better now, many thanks

I've tried to send over SPI the software reset command to the RFM22 module :

rfm_write(0x07,0x80);         // Software reset

MOSI line, µC sends as register address : 0x87 due to the mask : 0x07 | 0x80
it adds a '0' to the MSB of the address byte (WRITE MODE)

and sends 0x80 as value to the register afterwards.

My SPI clock is about 2.5Mhz, but i can see with my analyser that MISO line does not respond anything.
I don't understand know why ( see attached screen capture )
Could my SPI configuration be wrong ?

Do you have any idea ?

[jamesbond]

the write_rfm seems good.
to read a regisiter first write address and then read the data (see rfm_read() ).

WRITING to rfm22 start whit bit7=1 & bit 6 to 0 is address then followed by data.
READING to rfm22  start whit bit7=0 & bit 6 to 0 is address / dataread.
see datasheet SPI communication page 14.


in function write_cmd i first reset SDI,  depending on bit7 in cmd set SDI
cmd is not anded whit 0x80   

SDI=0;                          //  SDI LOW   ( MOSI )
if(cmd&0x80)SDI=1;       //  if (bit7 in cmd is HIGH) SDI HIGH

I do not know if you have a pair of modules to test whit.
The best way to start is one in send mode whit intervals of aprox. 50mS.
And the second one in recieve mode attached to a lcd and try to get the data from the sender.
Start first in "software SPI" and when its working good, go to the PIC SPI. 

[lcn]

Hello

Still no better result with my SPI transmission.
I do not understand why MOSI line starts BEFORE SCK clock edges.  

On the capture below when i try to send : rfm_write(0x0E,0b00000100);     // 0x04
Register address is 0x8E but we can edges start earlier than SCK.
I can also see the MISO line does not respond anything when the register is written.  ( it stays at 0x00 )

http://imageshack.us/f/442/spicapture.png/

I've set the SPI transmission to be MODE 0 (0,0)  CPHA = 0 / CKP-CPOL = 0
Is this correct for RFM22 modules ?

Any help will be much appreciated.

[jamesbond]

mode 0 is OK for the rfm modules.
the software SPI do exactly the same.
when writing an register the the MISO will NOT respond.

 
you write (0x0E,0x04) in the rfm_write() bit 7 in register address is set to 1 result in (0x8E,04) this is write register. // this works
When you read the register, bit 7 must be 0 !!  .So only write (0x0E) to the register and then clock data in.
 
i try to explain it whit this..

                                             register                 data
WRITE register-     MOSI     1-0-0-0-1-1-1-0    0-0-0-0-0-1-0-0   // this is OK in your image

                                             register                 data                             
READ  register-      MOSI    0-0-0-0-1-1-1-0                               //  bit 7 = 0 !!!!     you must send this byte via SPI (0x0E)             
                          MISO                                0-0-0-0-0-1-0-0   //  and then clock the data in via MISO 

the difference in read and write is bit 7 in register address.

[lcn]

Thanks,
 
It is good to know i should not expect to have any response back on the MISO line when writing a data to a register.
To read sequence of a register, i mask bit 7 with the following :

address &= 0b01111111;      // address &= 0x7F;

--
In order to confirm SPI communication works fine,

I'm trying to set GPIO2 to '1' and put it back to '0' in order to test my SPI communication. ( i've a led + resistor connected to GPIO2 )
The following code does NOT light the led connected to GPIO2  
Do you confirm the code below it is correct ?

Code:

 rfm_write(0x07,0x01);                         // Goes to READY MODE   (sends 0x87 as register address)
  rfm_write(0x0D,0b11001010);                   // Set GPIO2 as output ( sends 0xCA as register address)

  rfm_write(0x0E,0b00000100);                   // GPIO2 is '1'  : ON
  Delay100us_TMR2();
  rfm_write(0x0E,0b00000000);                   // GPIO2 is '0'  : OFF
  Delay100us_TMR2();

[jamesbond]

I've just tested the GPIO2 port connected to a led USING YOUR code, and here its working fine.

Please check.

Is your SDN pin from RFM22 LOW ?? it must be
Before a read or write command NSEL must be LOW,   on exit back to HIGH !!     // see software SPI
check if there is any respond on your analyzer when you do a read register command.
Is MISO pin configured as input ?
After read command you have generate 8 clock pulses to read out the MISO.

[lcn]

Yes, i CS pin (NSEL) is always '1' and goes to '0' during the SPI read/write sequence.
We can see it on the SPI capture.

For the read sequence i indeed send the anded register address with mask 0x7F followed by 8 SCK clock edges.
But the reading gets outstanding results.

If i do the following and immediately read the register back, i get a different value ...

Code:

rfm_write(0x0E,0b00000100);                   // GPIO2 is '1'  : ON
value = rfm_read(0x0E);

In my case i get value = 0x03 instead of 0x04   
I will post later today the SPI writing and reading capture i get for those 2 lines of codes.

But would you please try them on your side and tell me what you get when you read 0x0E ?

--

Can you also tell me what capacitor register (0x09) register is for ?  I do not understand well the datasheet for that one.
For register 0x0A : is it an output frequency that could be sent on GPIO2 for external purposes ?   if so i do not need it at all.

[jamesbond]

 When i write register 0x0E and read it back, i also get a false read.
 So i have to do more tests to find out how to get a correct read.
 That is good news for you.

 I am sure that this works..
 I use this to read my battery voltage.
 If you vary the power a little around 3.3V the value of "value" will change.
         
  rfm_write(0x07,0x41);      //enable low batt. register                 
  do{
    value=rfm_read(0x1B);  //read batt. voltage
    //your delay
  }while(1);

  you can also try this. this is the tx header register . can do no harm
  rfm_write(0x3A,0x40);   //change the value for test
  value=rfm_read(0x3A);
 

  register 0x09 is to adjust the frequency of the crystal.
   
  register 0x0A to divide the clock frequency for external use on GPIO2 

[jamesbond]

when i write(0x0D,0b11000011) and subsequently read(0x0E) i actually read a change on the GPIO2 port.  //just tested
when write(0x0D,0b11001010) and read (0x0E) i get 0x00.

If registor 0x0D is set to "direct digital output" , you can only write to bit 2 in register Ox0E.
if you read bit 2 it returns invalid data or 0.
And when configured as "direct digital input" you can only read bit 2.

see page 19 in datasheet http://www.hoperf.com/upload/rf/AN440.pdf

You read 0x03.
Your GPIO0 and GPIO1 are set to default value "microcontroller clock".
Can you see anything on the GPIO0 and GPIO1 pins?

I am curious about your new testresults.   

[lcn]

Actually most of the time MISO line responds 0x00

If i send the following :

Code:

rfm_write(0x0D,0b00001010);     // (0x0D,0x0A) GPIO2 is direct digital output
rfm_write(0x0E,0b00000100);     // (0x0E,0x04)
rfm_write(0x0E,0b00000000);     // (0x0E,0x00)

rfm_write(0x07,0x41);              //enable low batt. register
value = rfm_read(0x1B);           //read batt. voltage

I get this : http://img195.imageshack.us/img195/638/capture1mk.png
---

If i send these lines,

Code:

rfm_write(0x3A,0x40);           //change the value for test
value = rfm_read(0x3A);
value = rfm_read(0x03);

i get this : http://img812.imageshack.us/img812/4909/capture2me.png

But, look at MOSI line, especially when we write 0xBA : MOSI starts earlier than SCK clock edges, it is not normal i think.
I'm suspecting an SPI issue.

---

register 0x09 is to adjust the frequency of the crystal.

This is only if we need to generate a clock for an external device, isn't it ?
I guess this register does impact the wireless transmission, doesn't it ?

[jamesbond]

i think the MOSI  line works fine.
 the data on MOSI must be "low or high" before the RISING edge of the clock.
 this is not the problem.

 is your PIC powered to 5V and the rfm22 to 3.3V.
 is there any level shifter between  the PIC and the RFM22.
 is your MISO dataline OK ?  not pulled low by PIC or anything else?
 Disconnect MISO from PIC to rfm22 and use a oscilloscope to see if there is a squarewave on the rfm22 side.
 At last, go to software SPI to make sure that it works. 


 Yes, the GPIO2 microcontroller output can be use for clock or timer input .
 I guess this register(0x09) slightly correct the crystal frequency, but this has no impact to your SPI communication.   

[lcn]

Is your PIC powered to 5V and the rfm22 to 3.3V ?

The whole board is 3.3V powered.
Here is attached my schematic.     SEE RFM22.PDF

Good news : finally the SPI communication works fine.  
Look at the attached captures.

I send the following :

Code:

       rfm_write(0x07,0x41);           //enable low batt. register
        lecture = rfm_read(0x1B);       //read batt. voltage

Battery register returns 31, it means measured voltage is >3.2V , it is correct.
See CAPTURE3.PNG

---

Code:

       rfm_write(0x3A,0xAA);           //change the value for test
        lecture=rfm_read(0x3A);

0x3A is read back from the register.
See CAPTURE3.PNG

Actually, i think the SPI transmission was working since the beginning.
But for my tests, i'm using Microchip ICD3 debugger and i've made a STOP point just after a SPI sequence to capture it with my logic analyser.
This always capture 0x00 on the MOSI line, i can't explain why.

If i do not set a STOP point in the code and let it run continuisly, and take a piece of SPI frames with the logic analyser, i can see correct results.

[lcn]

Do you confirm the following has to be placed into the infinite loop of the program ?

Code:

   rx_mode();  //put in rx mode

          while(IRQ==1);  //wait for low  (can also be done in interrupt)
          loop=datasize;  //read the data out the rfm
          do{
            datastr[--loop]=rfm_read(0x7F);
          }while(loop!=0);

   // process the data in datastr[]   for example: switch relay / send via rs232 / store data in eeprom / pwm
   

         // collect data and put it in datastr[]
   tx_mode();   //send data in datastr[]

When you wait for reception, you test the following :

Code:

while(IRQ==1);

Did you previously set RFM22 IRQ pin in the init function to get that pin low when a string is being received ?
i did not find where ...

--------------

I've made 2 identical boards with RFM22 module.
I would like to program the first one as 'sender' and the second one as 'receiver'

ie : the 'sender' board sends the string 'HELLO WORD'
if the receiver board gets this string, i would like it lights the LED connected to its GPIO2

Can you tell how to do that please ?

[jamesbond]

Nice to read that it works.

Have you succeeded in turning the LED on and off ?

see page 51 in the datasheet for output by low battery detector register.
my board  power is 3.3 V. and the battery register(0x1B)  returns 0x1E.

while(IRQ==1);   this is a active waitloop. it's better to use the pin interrupt and use interrupt function.
IRQ is the NIRQ output pin on the rfm22.   in this case a not well-chosen name by me.

/*
// example for the reciever board .            set " #define datasize" to the number of characters to recieve, in your case 10
rfm_init();
do{
     rx_mode();  //put rfm22 in rx mode
     while(IRQ==1);  //wait for low  (can also be done in interrupt)
     loop=datasize;  //read the data out the rfm
     do{
          datastr[--loop]=rfm_read(0x7F);
     }while(loop!=0);

   // process the data in datastr[]   for example: switch relay / send via rs232 / store data in eeprom / pwm
   if  ( datastr[] == 'HELLO WORD' ) {   // for example
            // your code
                  rfm_write(0x0D,0b11001010);                   // Set GPIO2 as output ( sends 0xCA as register address)
                  rfm_write(0x0E,0b00000100);                   // GPIO2 is '1'  : ON
                  }
}while(1);
*/


/*
// example for the transmitter board.         also set " #define datasize" to 10
rfm_init();
do{
   if(pushbutton is low){     // if there is any
      put 'HELLO WORD' in datatstr[];     
      tx_mode();   //send data in datastr[]
   }
 wait(time); //your waitloop
}while(1);
*/

[lcn]

I'm now testing the 2 modules together.

The sender is properly sending the string HELLO WORLD by starting from the end : DLROW OLLEH
I can see the FIFO filling on the SPI frames.

At the moment, i continusly send every 3 seconds the same string.

--

However, the receiver looks not working properly :
The program never sees IRQ pins going low.

so the program stays here :  ( in red )

     rx_mode();  //put rfm22 in rx mode
     
     while(IRQ==1);  //wait for low  (can also be done in interrupt)
     
     loop=datasize;  //read the data out the rfm
     do{
          datastr[--loop]=rfm_read(0x7F);
     }while(loop!=0);

I've check with the logic analyser : rx_mode(); is correctly run : TX-ANT is indeed set to '0' and RX-ANT is set to '1'
all looks good from that side.

The issue is only that IRQ pin never goes to '0' ...

How could we be sure that IRQ register is properly set to generate a low level on IRQ pin when a correct string reception happens ?

[jamesbond]

 Have you set datasize to 11 =  'HELLO WORLD'  on both boards ?
 I said 10 because the text  was 'HELLO WORD' .

 Use for this test identical rfm_init()  in transmitter and reciever boards ,  you can customize it later.
 When there is a lot of noise on the frequency you use, create at least on one board an antenna.
 A piece of wire will do. 
 
 If the FIFO in the receiver is full this pin goes low and read datastr[].

[lcn]

Ok I will redo some tests, because I have set datastr size to 20
So it might be too long and FIFO never gets full with 'HELLO WORLD' string

Maybe this explain why nIRQ pin does not go get low.

[lcn]

I still have no chance,
i have set the sizze to 12 in order to handle the contents of the string :   HELLO WORLD\0
Even i have modified the size of the nIRQ pin won't go low.

i have no idea how i could debug it.
Not really easy to find out if the issue comes from sender or receiver . 
How can i be sure that sender module sends something and receiver receives a string ?

--

Are your RFM modules 433Mhz or 868 Mhz ?
Mine are normally 433 Mhz.  ( can't be sure since nothing is written on it )

[jamesbond]

best way is a hf-reciever if you have one. I'am not.

Second method.
put a 1 ohm resistor in the power line to the rfm22.
view on an oscilloscoop the voltage over the resistor.
if the powerconsumption rise at setting testoutput=1 and fall at testoutput=0 you can assume the transmitter sends.
if your testboards are identical,try this on both boards to test if the two modules working properly. (see attachment)

the nIRQ is also used by the FIFO in the tx_mode.
you can test the nIRQ pin if there is any response when sending

i use 868Mhz, its normaly written on the back side .     

[lcn]

Yes, I have 2 identical boards, as same the picture I sent.
One as been programmed to transmit the string every 3 seconds, the second module is programmed as receiver.

My modules are 433mhz, do you think I should modify frequency registers ?
I guess I should not use the same init config that you have sent in your code ?

What line of the code sets nIRQ pin going low when FIFO gets full ?
I do not find it.

I will double check on the sender module if nIRQ goes low, but if I remember well I think so !
So issue might come from the receiver.



Posted on: April 11, 2013, 11:10:03 23:10 - Automerged
I've checked again the logic analyser capture of TX_mode();

i can see the following :
Before TX_mode starts, nIRQ pin was '1' and will stay '1' while TX_mode runs

-At the beginning of TX_mode();  i can see TX-ANT pin going '1'
- FIFO is cleared, we read see on logic analyser (0x88),(0x03) - (0x88),(0x00)
- Then, i can see many 12 couples of (0xFF), (character hexa code of the string sent)
- I see (0x87),(0x09) and (0x87),(0x04)
- TX_ANT goes '0'
- nIRQ pin goes '0' at about 90ms AFTER TX-ANT went '0'   not sure this is normal

Normally, if i'm not wrong , at the end of TX_mode
we first wait ( do nothing ) until nIRQ is '1'
then if nIRQ goes low TX_ANT is set to '0'

Code:

  while(RFM_nIRQ!=0);
  RFM_TX_ANT = 0;

In the reality, TX-ANT goes '0' first and nIRQ goes '0' 90ms later.
This was also confirmed by my debugger, i PAUSE the code run i can see that programs waits on that line :

Code:

while(RFM_nIRQ!=0);

When my board is not transmitting anything current sucked is : 25mA
During TX_mode current reached 45 mA, so TX_mode sucks about 20mA .

[jamesbond]

After executing rfm_init() the nIRQ =1.
The first time (after the rfm_init())  you enter tx_mode the nIRQ=1 until the FIFO is empty.(if nIRQ=0  FIFO is emtpy and transmission is completed)
If only the TX_mode is in a loop, the nIRQ stays low.
nIRQ=1 after rfm_write(0x07,0x09); //start sending.
 
It seems that your PIC do not read the nIRQ.
In this case you disconnect the antenna (TX_ANT=0) before the the rfm22 has finished transmitting.
The transmission time of 90mS seems OK.
To test you can force the 90mS wait time (rfm =sending)  by inserting a waitloop (100mS) before the while(RFM_nIQR!=0);

the increase of current during tx mode indicates that the rfm is trying to send.
The exact current i do not know.
 

[lcn]

Hello

I'm back with good news  
The SENDER & RECEIVER modules are now working perfectly.

Thank you very much Jamebond for your help, i wouldn't success without your advices.

For people who following this post i've attached the SPI capture when RFM22-S2 modules receives a string from the SENDER module.
In this capture, the RX_string lenght was set to 12 and we receive the message "Hi!"

I also attach the SPI capture for the SENDER module, the message in TX_string sent out is "Hi!"

In order to read them, you need to download the free logic analyser software : http://www.saleae.com/downloads


My modules are 433Mhz, so i had to modify in RFM_init(); the frequency settings as below :

Code:

/**** FREQUENCY SETTING ****/
  rfm_write(0x73,0x00);             // freq offset
  rfm_write(0x74,0x00);             // freq offset
  rfm_write(0x75,0x53);             // hbsel = 0, sbsel =1, fb = 19
  rfm_write(0x76,0x64);             // 25600 = 0x6400 for 434Mhz
  rfm_write(0x77,0x00);             // freq offset
  rfm_write(0x79,0x00);             // no freqhopping
  rfm_write(0x7A,0x00);             // no freqhopping

Hope it could help.

--

Since the modules are now communicating together, i've found that TX & RX headers are not used in the code provided by Jamesbond.

-Would you please tell me how to enable them ?
Are they supposed to enhance the occuracy of the transmission ? as suggested at page 43 of the datasheet ( preambles )

Jamesbond code is using GFSK mode, but what are antenna diversity and AFC enabled ?
I do not understand well the datasheet on these points.


- I still have problem to calculate the TX/RX frequencies for the modules.

Does a software calculator exist to calculate 0x75 - 0x76 - 0x77 registers ?

I need to use 4 pairs of modules for my project and would like to set differents frequencies on each of them in order to avoid TX/RX collisions.
ie : 433.1 Mhz, 433.4 Mhz, 434.1 Mhz, 434.7 Mhz

[jamesbond]

Good to hear that it work.

I found this a while ago, maybe  you can use it.
http://www.hoperf.com/upload/rf/RF22B%2023B%2031B%2042B%2043B%20Register%20Settings_RevB1-v5.xls

About TX and RX headers, change one byte in the header of the sender and see if the receiver still receives data.

the antenna diversity is also not clear to me.I have to read the datasheet again.I will do soon.

AFC enabled is Automatic frequency control = to lock on the frequency of sender. 

[lcn]

Hello,

I've received new modules i ordered : RFM23BP

I do confirm these are fully compatibles with RFM22B code.

For test purposes i've used a RFM23BP module as 'sender' and a RFM22B module as 'receiver'
The communication works properly so modules are compliants each other and code as well.

However i've found RFM23BP module gets very hot, 2 chips on the board go up than 150°C (302°F)   
( my test code transmit a string every 3 seconds )

Does anyone also confirm that RFM23BP modules are very hot when they are in use ?

[TucoRamirez]

So do you have a FLIR Thermal Camera ...  Interesting !!

[jamesbond]

the rfm22 and 23bp are pin compatible
only the TXON and RXON pins are driven inverted.
refer to datasheet to be sure.

[lcn]

Many thanks Jamesbond i did not notice that.

In order to enhance the transmit & receive distance, i would like to use a 433Mhz antenna instead of 17,4 cm copper wire.

I've found a Aurel antenna in my stock, maybe a newbie question but i don't know how to connect it to the module.
See the antenna picture attached below.

Should connect the end of the black wire to RFM antenna pin ?
and red wire would be a virtual ground staying unconnected ?

The Aurel antenna measure 19,8 cm , isn't it too long for 433Mhz purposes ?

Posted on: May 02, 2013, 07:55:54 19:55 - Automerged
I'm back with new tests done with RFM23BP modules
i've inverted the states of RX_ON and TX_ON.

But my RFM23BP module set as emetter is not working properly  

Actually it gets stuck in tx_mode() : it waits for nIRQ going low but is does not, i don't know why  

--->  while(RFM_nIRQ == 1);     // Wait nIRQ goes HIGH to LOW : will mean packet has been transmitted
        RFM_TX_ON = 1;            // Transmission completed, disable TX antenna


In the mean time GPIO2 is '1' but it should not because the init function has previously set it to low state and tx_mode does not change GPIO2 state at all.
So this is another outstanding thing.


Edit :
I've found that the board works properly approximately 1 time / 20 start/restart cycles.
If i power off and put back several times, sometimes the RFM23 board inits and works properly, i don't know why.

[jamesbond]

calculation for 1/4 whip antenna (300/433)/4 = 17.3cm.

The connection between RFM module and antenna should be as short as possible.
For a strong antenna signal you need a ground plane.
See datasheet    http://www.rfm.com/corp/appdata/antenna.pdf.
I use a piece of brass rod mounted on a PCB which is also the grond plane.
This is good for 5km distance.


I had the same problem as you in tx-mode.It took me a day to find the problem.
It has something to do whit the smart reset on the rfm module.

I replaced the 5V voltage regulator for a 1Amp and more stable type.
Add a extra capacitor to the input of the voltage regulator.
There should be no voltage drop in the 5 volts while transmitting.
 
Check your pcb for ground loops. This was the main problem in my pcb.

I hope this helps you.Let me know your progress !

[lcn]

I've made some deeper tests with my debugger :

I've tried to make a stop point in tx_mode function when code reaches :

Code:

RFM_TX_ON = 1;            // Transmission completed, disable TX antenna

It is just after nIRQ pin state test.

Code:

while(RFM_nIRQ == 1);     // Wait nIRQ goes HIGH to LOW : will mean packet has been transmitted

Actually the debugger never stops because it does not see nIRQ going low.
The SPI capture i got with logic analyser confirms this too.

According to logic analyser capture, i can see tx_mode function transmits each characters of the string properly,
even the lines below are also well transmitted on the SPI line, nIRQ don't turn to low state when the transmission ends, thus TX_ANT is not desactivated and not set back to high state.

Code:

rfm_write(0x07,0x09);     // TX in Manual Transmit Mode : ON  - READY Mode - (nIRQ goes high '1')
rfm_write(0x05,0x04);     // Packet Sense Interrupt enabled. (nIRQ will go low when a packet will be transmitted)

I'm not using PCB yet, i'm testing my RFM23BP module with a Lab board powered by +12V battery and +5V LDO regulator.
Because i'm using a battery as power supply i should not get dropdown voltage at regulator input, i've added a 330uF tantalium cap close to RFM23 power pins but this does not help.


Edit : added SPI capture file from Saleae Logic Analyser showing RFM23 tx_mode() function

[bbarney]

would be better if you posted a bitmap or other more common picture format like jpeg or png
not everyone has the software to read your file

[jamesbond]

Sorry for the late response.

I still think the problem is in RFM23bp module.

I use the voltage regulator L7805CV which is 1.5A from ST.
In previous post I had said 1A, this should be 1.5A.

I had the same problem.Maybe 1 of 5 transmissions were succesful, in all the other cases it stopped also at the IRQ loop.
The rfm23bp itself never leave the tx_mode, that is the the reason for the high temperature.
You can check that bij measuring the current.
 
In Previous post I forgot to mention to measure Gpio ports on logic level on a scope.
On my testboard the gpio ports of the rfm23bp are 3.3V at a supply voltage of 5V at the rfm23bp ?
At last i had powered the pic16 on 3.3V and rfm23bp at 5V.

Look carefully at the wiring of your board and experiment with that.

[lcn]

Actually i do use the same regulator like you.
I'm using +12V battery cell + regulator as power supply.
There is 10uF cap at regulator Vin pin and 330uF tantalium cap at Vout side.

I'm using a lab board for my tests and RFM23BP module is wired to it with small wires soldered on it, maybe because lab boards are not shielded, it could explain this trouble ?

Has your PCB 2 layers with ground plane on both sides ?

[jamesbond]

On my modules the underside is fully grounded.

I have a bitmap of my pcb attached. Maybe it is usefull for you.
to clarify the strange drawing method.
The original is a autocad dwg so I can easily import it to a usable format for my cnc machine.
This pcb is in low numbers in production, it should be improved in the future.

As you can see the pic16 is powered to 3.3V only for the input/output levels on the rfm23bp
The logic levels on my rfm23bp are not 5V.It is better to check that on your modules.

Has you measure the current to see if the tx-mode is terminated on expected point.

[lcn]

Hello,

I've asked some questions to Hoperf support, here are their answer :

Our RFM23BP module, power is 5V, for the PA ont the module need 5V power supply, but there is a LDO on the module, so our RF IC on the module also powered by the 3.3V, so the module connect to the MCU should be 3.3V power.
When you set the module work in transmitter, whether the area of the module GND and your board GND connected is enough large ?  For the module has a large power, so it need enough area GND.

So RFM23 modules are 3.3V compatibles.
In order to solve the transmission issue i've built a 2 layers PCB with ground plane on both sides.
I'm waiting to receive them from Futurlec

I will update that post with the results once that new board will be tested.

[lcn]

Hello

I'm back, i've build a RFM23BP module on a 2 layers PCB with grounded background.

But, in transmission mode, most of the time nIRQ does not go low and i don't know why it won't to !
The code stays wainting tx_mode(); function on : while(RFM_nIRQ == 1);

Code:

 // During transmission process nIRQ is HIGH, transmission takes about 90ms
  // nIRQ will go LOW once transmission completed.
  while(RFM_nIRQ == 1);     // Wait nIRQ goes HIGH to LOW : will mean packet has been transmitted (tant que nIRQ = 1 -> attente)

Note the regulator i've used is a 3A LDO from Exar : SPX29300T-L-5-0

Sometimes transmission works during a couple of secondes and then gets locked on the while test ...

[lcn]

Hello,

Did someone ever test the Frequency HOPPING on RFM22B / RFM23BP modules ?

I have set a table with some hopping values to be written into 0x79 register, the TX module is able to hope frequency for a tranmission but i do not see to the RX module could hope properly.

Code:

// Select Numbers of Frequency channels
#define NB_HOPPING_CHANNELS 6
// Select the hopping channels between 0-255
// Frequency = CARRIER_FREQUENCY + (StepSize(xx khz)* Channel_Number)
unsigned char hop_list[NB_HOPPING_CHANNELS] = {37,4,34,45,28,3};


void Hopping(void)
{
CH++;
if (CH > NB_HOPPING_CHANNELS) CH=0;
rfm_write(0x79, hop_list[CH]);
}

Any suggestion or idea would be much appreciated.

[Ikaros]

I have tried but in vein.

Maybe HopeRF can give a hand, but had not time to look into it more.

They are quite difficult to handle...

[movf_jmpz]

According to freq hopping, are you waiting enough long for osc to stabilize carrier ?
If not, then your transmittion may be rejected by RFM22...