RFM22S vs Si4432

[stevech]

This question is on two topics: (1) RFM22S (S?) versus Si4432 (my findings), and (2) clear channel assessment problems. This long post has some info likely useful to some of you...

I'm testing a number of same-size PCB modules - some are HopeRF RFM22S (note the S suffix.. not sure how that relates to the RFM22B - if anyone knows), and other I'm testing use the Si4432 sold by Dorji.com via Tindie.com.
I have the RF22 lib running for both, and the two modules do interoperate fine. I don't know how close the RFM22's (B  and  S) are to the Si4432. Both return the same ID code and revision number.

Both have the on-PCB TX/RX switch that is driven by GPIO0 and GPIO1. However, the Dorji module has the TX/RX switch wired opposite of the HopeRF. So I change the GPIO0/1 usage according to which module type is in use, at run time, overriding the assumption made in the RF22 lib.

In my 6 module test setup the two different PCBs do interoperate - I'm mainly using the reliable datagram of RF22 lib. I have a comprehensive test program for a star topology with, e.g., 4 clients sending messages to one defined server. And another PCB module is a passive "sniffer" that displays all detail in all frames including ACKs being sent for any source/destination or broadcast. This all works fine except for collisions.

The clear channel assessment issue I have is:
The Doji Si4432 work as the data sheet says, in terms of setting the CCA threshold RSSI achieved bit in status 2, and optionally interrupting. When there is no signal being transmitted, the RSSI register on that radio returns the expected noise floor RSSI, in the 30's (RSSI scale not dBm).

The RFM22S does not. In no-signal conditions, its RSSI is either noise or an oscillation causing the RSSI readings to be very high, like 80's and 90's. The CCA threshold exceeded bit is thus noisy too. If I set the CCA threshold register to an absurd 95, the CCA exceeded bit stops toggling.  The question then is: I have an identical radio config for the Si4432 and RFM22S and identical  code. Either I have some subtle error unique to the HopeRF, or the RFM22S receiver is oscillating causing the random RSSI readings, or the RFM22S has a design flaw. Anyone encountered this?

It's kind of like a voice radio receiver for FM that has squelch - so that the Si4432 I have reports a low RSSI (30s) but the RFM22S does not (or I have some odd error).

This precludes me using the CCA mechanism in the HopeRF modules. I've inquired of HopeRF but so far, no response. I don't know if some HopeRF modules have an RFM22B that behaves differently; all mine are RFM22S.

------
I implemented a hacky work-around for the HopeRF modules: In the RF22 lib interrupt handler, I added to the interrupt on "valid preamble" received a line of code to store the systick counter (time) at which the interrupt occurred. And I have a new class method to get that time from my app. A scheme for CCA is to check how long since the last preamble was received. This helps intra-system collisions. But CCA needs to do energy detection so that any transmission from other devices can cause my pending transmission to delay (e.g., exponential backoff as in 802.11 and 802.15.4.).  The rssi value in these chips say they update when a preamble is detected. This suggests it does not do energy detection where other devices' transmissions don't have the same sort of preamble.

By the way: I'm doing this RF22 lib work on a 96MHz ARM Cortex M4 with an Arduino compatibility package. 64K RAM, 256K flash. Low cost. But I shouldn't advert here.

Steve

[Mike McCauley]

Hi Steve,

thanks for your detailed note.

Re the reversed GPIO connections on some radios, you may note that the source
for RF::init has a #define to let you achieve the same thing.

The odd RSSI reading on that device sounds like a hardware design issue where
its receiving its own LO.

Cheers.

--
Mike McCauley VK4AMM mi...@airspayce.com
Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.airspayce.com
Phone +61 7 5598-7474 Fax +61 7 5598-7070

[Steve Childress]

On the GPIO0,1 and the antenna switch... yes, I saw that #ifdef. But I have mix of radios with opposing wiring. So my application code retains in EEPROM which kind of radio is attached and then issues one or the other setting for GPIO0,1.   Ideally, this could be a method in the library.

On the CCA issue and random RSSI readings... the boards are RFM22B-S, with a HopeRF chip marked RF22S. I've asked HopeRF if these are literally the Si4432 - since the boards I have from Dorji with the SI4432 per se don't have this noisy RSSI.  Seems unlikely that the RFM22B-S boards (I have 4) would all do this, if it were a design issue. Meanwhile I'm using my alternative method for CCA assessment: age of last-received header-is-valid interrupt.

I also note: Isn't it true that the non-ISR application and library level code SHALL NOT (without disabling interrupts/ATOMIC ACCESS) do a function that uses the SPI port - where the ISR could simultaneously do so? In my app, I had a temperatureRead() while the receiver or transmitter might be enabled and might interrupt. I changed that call to temperatureRead() to be done when I have the radio in the idle state. I suppose this is widely known... a common mutual exclusion issue.

cheers, Steve Childress

--
You received this message because you are subscribed to a topic in the Google Groups "RF22-Arduino" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rf22-arduino/93DGC7QFkhI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rf22-arduino...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike McCauley]

Hello Stve,

RadioHead will have new function setGpioReversed() for the RF22 driver.

Cheers.