New library for RF22, RFM22 radio modules

Hi Mike!
Are you using frec hopping or only a conventional frec at the library?

Other thing is, how do you do when you ask at mesh for other node to send his beacon and two nodes can send the beacon, how them know that one must Tx before other?, have some order for this? the node Id for example?

At router's table, it use RSSI as variable to decide how will be the next node to send the packet?

I will write an encription library for the data payload

Best Regards
Frank

Frank:
No frequency hopping is used.
Random retry timers are used for reliable datagrams
Router table does not use rssi to decide: last reply wins

Cheers.

Have you all the network operation theory writed in some document?

The only thing that i can't understand about MESH is if each node repeats each datagram, how this datagram first reach the destination node after jump several times, and how the destination NODE respond to this datagram. I think that in both cases they will not use the same node. I think that the route have different direction.

I mean, if the server wants to send a command to the last node in the network, at the firts node that repeat the datagram it will be send back to the same node that generate this datagram, how the node send to others nodes and not go back to the server?

I must read some theoryy!!

Best Regards
Frank

Just a quick question: Does the library only support the RFM22 or does it cover the RFM22B as well? And RFM23 and RFM23B (lower power versions)?

Actually another question: From what I can make out of the RFM22 documentation you need to control the TX_ANT and RX_ANT pins to switch the antenna to the right pins on the chip depending on if transmitting or receiving. There seems to be no mention of this in the code or docs AFAICT - I guess this is because the package isn't assuming a particular module, just the RF22 chip.

However the RFM22 module is probably rather dominant in the RF22 market, it would be good to support it... Or have I missed something here?

According to http://arduino.cc/forum/index.php?topic=50417.0 and to my tests, the tx_ant and rx_ant pins arent needed. I leave them floating and it seems to work fine.

mikem:
According to Arduino Forum and to my tests, the tx_ant and rx_ant pins arent needed. I leave them floating and it seems to work fine.

Ah, I'm wondering if this is a difference between the DIP and SMT versions of the RFM22. The SMT version I have definitely have an antenna switch chip (6 pin near ANT) that must be driven correctly. However I suspect all the RFM22 modules have this as the chips RX side can't survive the full output power from the TX side (17dBm) without a switch according to the documentation. By contrast the lower powered RFM23 doesn't have one.

If the pins are left floating its unlikely you'd get any appreciable power off the device (limiting the range greatly) - there's also a risk of generating harmonics that splatter over other bands, which is not a good thing. There is also the risk of burning out the PA at full power since the VSWR will be badly off.

The ones Im using are identical to the one in the picture at:

If it really needs tx_ant and rx_ant pins to be controlled externally, then I will need to make some changes to the library.

But... surely the controller chip on board knows when it want to transmit and recieve and should be controlling the antenna switch itself? Why would it expect an external processor to control the antenna switch for it?

Cheers.

The datasheet suggests using GPIO0 and GPIO1 to control them - GPIO's can be set to the TXstate and RXstate for instance or directly controlled via SPI. Its worth checking which modules have a switch (I'm suspecting its 22's and not 23's but I don't really trust the datasheets as they seem to cover the silicon only with module information as an afterthought)

Have you seen a 22B or 23B BTW?

The ones Im using are RFM22B-S2 as per the sparkfun page:

The data sheet for that one at:

does not mention tx_ant or rx_ant at all. The table on page 64 has 'NC' in hte places where there was tx_ant and rx_ant on the RFM22.

So looks to me like they are not connected in the RF22B.

mikem:
The ones Im using are identical to the one in the picture at:

RFM22B-S2 SMD Wireless Transceiver - 434MHz - WRL-10153 - SparkFun Electronics

If it really needs tx_ant and rx_ant pins to be controlled externally, then I will need to make some changes to the library.

But... surely the controller chip on board knows when it want to transmit and recieve and should be controlling the antenna switch itself? Why would it expect an external processor to control the antenna switch for it?

Cheers.

As you state, it does seem strange that we have to manually switch these pins when the chip knows that it is going to transmit or receive. Doesn't make sense!

However on page 62 of ver 1.1 of the HopeRF manual it states:

"Tx Antenna select input pin, When RFM22 is TX state,TX_ANT should be = 1, RX_ANT should be = 0"

and

"Rx Antenna select input pin, When RFM2 2 is RX state,RX_ANT should be = 1, TX_ANT should be = 0"

Whether these are asserted through the GPIO pins of the RFM22B or by the I/O of the Arduino is left to us, but either way they need to be toggled by the program.

The RF22 library was written for the RFM22B devices and AFAICS, the tx_ant and rx_ant pins dont need to be connected for the RFM22B. May be different for the RFM22 devices, but RF22 library does not support them.

If you go to http://www.sparkfun.com/datasheets/Wireless/General/RFM22B.pdf you will find version 1.1 of the 22B-23B manual.
(strangely this is a more up to date version than that on the HopeRF site which is version 1.0).

On page 58 of this manual there is Figure 32A it clearly shows TX_ANT and RX_ANT connected and on page 62 it refers to asserting them. The confusing part is that they roll the 22B and 23B manual into one. The 23B does not have these pins and therefore they are not discussed in reference to this module. It is a bit confusing as to when they are talking about one module or the other.

I will send off an email to HopeRF to get a definitive answer.

lemming, yes I see your point.
Let me know what Hope says. If I need to make changes to the lib I will.

Cheers.

I think that the two antenna outputs got a reason, and is not about who antenna transmit and who receive.

At radio systems you got a coverage problem when the frecuencies goes very high, and this situation do not correct using more power at the transmiter or at the receiver. This is an signal angle problem and is so complex that the signal loose all the power is like it pass for virtual 0 degree and loose itself.

The only way to correct this situation is use another antenna equal to the first but in a different polarization angle, at cellular systems they use a second receiver w/a second receiver antenna to correct this sum both receivers signals.

At the PDF the diversity antenna algorithm is included on the chip firmware, but the antenna switch is external via PIN/GAS diodes, this antenna switch is controlled via the GPIO PINS, that means that this SW is EXTERNAL and is not included on the RFM22/23 PCB.

Build a antenna SW at this frecuencies will be very hard!

Best Regards
Frank

mikem:
The RF22 library was written for the RFM22B devices and AFAICS, the tx_ant and rx_ant pins dont need to be connected for the RFM22B. May be different for the RFM22 devices, but RF22 library does not support them.

Ah that explains it - haven't seen RF22B silicon myself.

For the RFM22 all that's needed to support the pins is

    spiWrite (RF22_REG_0B_GPIO_CONFIGURATION0, 0xD2) ; // TX state
    spiWrite (RF22_REG_0C_GPIO_CONFIGURATION1, 0xD5) ; // RX state

And then connect GPIO0 pin to TX_ANT and GPIO1 to RX_ANT as in the RFM22 datasheet.

The RF22B's lower power levels mean its matching network doesn't need to be isolated from the RX input during TX as it can take the power levels without frying. For the RF22 this isn't safe at high powers (17dBm is 4.5V p-p into 50 ohms) hence the antenna switch chip on the RFM22 module.

From the module, the Tx/Rx switch is inside the silicon.

Now for the atenna diversity application, the chip don't have built-in the antenna switch, you MUST build this polarization switch external to the RFM22 device.

The control from this switch is made via GPIO outputs, the inputs TX-ANT and RX-ANT is like a SDPT-SW sensor, because the radio can be used for high speed radio links, the radio must know when the SPDT switch is ready to transmit, i mean when the selected antenna is successfuly connected

8.9. Antenna Diversity
To mitigate the problem of frequency-selective fading due to multi-path propagation, some transceiver systems use a scheme known as antenna diversity. In this scheme, two antennas are used. Each time the transceiver enters RX mode the receive signal strength from each antenna is evaluated. This evaluation process takes place during the preamble portion of the packet. The antenna with the strongest received signal is then used for the remainder of that RX packet. The same antenna will also be used for the next corresponding TX packet.
This chip fully supports antenna diversity with an integrated antenna diversity control algorithm. The required signals needed to control an external SPDT RF switch (such as PIN diode or GaAs switch) are available on the GPIOx pins. The operation of these GPIO signals is programmable to allow for different antenna diversity architectures and configurations. The antdiv[2:0] bits are found in register 08h “Operating & Function Control 2.”
The GPIO pins are capable of sourcing up to 5 mA of current, so it may be used directly to forward-bias a PIN diode if desired.

This idea is widely used on high speed radios.

OK, I have modified the library so that GPIO0 and GPIO1 are set to follow tx_state and rx_state respectively, and updated the doc to show connections from GPIO0 to TX_ANT and GPIO1 to RX_ANT.

After doing this I saw abut 5 db higher output on transmit at higher levels with my RFM22B-S2

New version 1.7 of RF22 library is now uploaded.

Feedback please.

Hmm, the plot is thickening... Firstly I went to look at my order for the RFM22's I have - I am pretty sure they were originally sparkfun ones but I sourced them from SKPang here in the UK in November last year. I presume the RFM22B has superseded these now, but there must be lots of the the non-B versions out there...

Secondly I looked at the breakout board photo on the Sparkfun website: SparkFun RF Transceiver Breakout - RFM22B-S2 (434 MHz) - WRL-10154 - SparkFun Electronics It shows a RF22S chip rather than a RF22B on the module (which although not identical in layout to my RFM22 has an antenna switch chip.).

It also shows the breakout board does not connect to ANT_TX and ANT_RX at all... Despite being loaded with a module that requires them...

So it seems Sparkfun weren't aware of the issue when selling previous modules, which I presume the photos come from. Also its not clear that they have their data right on the newer RFM22B modules, claiming 17dBm rather than 13dBm....

Then again can anyone trust the Hope RF datasheets anyway (they certainly confuse/conflate the chip v. module specs).

If anyone has a good photo of an alleged RFM22_B_ module its easy to tell if it has a 6-leg antenna-switch chip on it... If it has then the ANT_TX and ANT_RX pins need driving. Also if anyone has done a range test at 17dBm at 9600baud and 30kHz deviation - should be over a mile by my calculations with quarter-wave antennas.

I've just had a play on the new 1.7 version on my "RFM02S Rev 0.2" modules (version code reads as 0x02 BTW). Just tried the rf22_test example:

(Firstly just to say the ANT_TX and ANT_RX pins are doing the right thing :wink:

test_rssi code doesn't work until I add some more delays in a couple of places - presume this is silicon differences. It was getting stuck after reporting just 3 of the 5 frequencies (and reporting FF for each). Adding delay(2) after setModeRx in test_rssi meant all 5 were reported (as FF),changing delayMicroseconds(200) to 1600 meant more sensible RSSI values started to appear...

test_tx seems to be putting out RF (according to passive rx probe), but test_rx() on the other module isn't doing anything in response (not even the "recv 1 failed" message appears).

I presume all the tests work fine on RFM22B modules?

I noticed a couple of things about the library BTW - you do timeout tests that don't work at wraparound (see waitAvailableTimeout() in RF22.cpp for instance).

Also you assume that the chip can't fall out of tx or tx modes by itself (it can) and you cache the believed tx/tx/idle state in the library.
Thus a call to setModeRx() for example might do nothing even when the chips in Idle mode.

[ I may find time to trawl through all the differences in the RF22 v RF22B datasheets for some answers.. ]