cancel
Showing results for 
Search instead for 
Did you mean: 

SPIRIT1 CSMA understanding problem?

kzkaram
Associate II
Posted on August 10, 2015 at 13:32

I am performing some tests on the CSMA feature. Specifically on the non persistent CCA method.

I have a test process whereby every 10s the transmitting module has its TX FIFO flushed, has its FIFO filled with 20 bytes of data, then the TX command (0x60) is issued. The transmission is basic packet protocol with fixed payload length of 20, GFSK1, 38.4k data rate, in the 868MHz band and I believe other related radio and protocol parameters are at least reasonably correct since the receiver is receving the packets just fine, although missing perhaps 10% at present (even at short range). Though this is something I have to figure out perhaps in terms of Quality acceptance filters, for the moment I also thought I'd try and test the CSMA feature on the transmitting unit.

So I have enabled non persistent CSMA (register 0x51 = 0x05), I have set up some Tcca and Tlisten values and other CSMA parameters (register 0x67 = 0x25, 0x66 = 0x04), I have set CS_mode to be static RSSI sensing (register 0x21 = 0xE3).

Now a strange thing seems to happen:

If I set RSSI_TH to some relatively low value like 0x21 the transmissions seem to be made ok (received at receiver unit) and the nterrupt information from the transmitter just after transmission shows that RSSI threshold was exceeded and that Tx data was sent. If I now increase RSSI_TH to something like 0x30 (which I consider to be significantly above the general noise floor that I'm seeing on this channel) then I try the transmission process again, what now happens is that the transmitter appears to remain stuck in what I'm guessing to be in carrier sense mode. I say this because I observe no received packet on the receiver side and also when I query the MC_STATE registers [1],[0] on the transmitter unit it returns 02,67 which suggests it is sitting in RX mode. Also if I read the interrupt flags, first time round I can see some undocumented bits are set, second time all 00 (which is to be expected if no activity is taking place due to auto clearing after first read).

So my question is - am I really understanding what the CSMA process is doing? Or is ther yet another mistake I am making with some parameter which could account for these observations.

My understanding of CCA is that if you raise the RSSI_TH then you should get more liklihood of transmission, not less. Because it implies that only high channel signals will be seen as channel not clear. Whereas a low RSSI_TH should pretty much result in failure to transmit at all times since the channel would be considered not clear at all times due to background noise being higher than the RSSI_TH.

Any suggestions?
4 REPLIES 4
kzkaram
Associate II
Posted on August 22, 2015 at 01:26

Have also been trying to do the same thing with persistent CSMA. In other words enable CSMA and enable Persistent CSM (0x51 -> 0x06). Then try TX. Same result. I.e if RSSI_TH set to some relatively high value eg 0x60 then the chip just stays in RX state after that point according to MC_STATE and nothing received at the receiver module. On the other hand if RSSI_TH is set to a low value such as 0x18 then the transmission is successful.

Is anyone from ST going to provide any insight into what might be the cause?

BTW I had submitted some questions to standard ST support  channels perhaps 3-4 months ago only to receive a message saying the query was in assigned state just a few days ago. Insult really. I'm getting a real bad feeling about ST. By contrast TI had technical staff visit our office and direct e-mail contacts. Perhaps the CC1200 is getting more attractive by the day...

Is this typical of ST in general or just the SPIRIT1 team anyone know?
Nickname4815_O
Associate II
Posted on August 24, 2015 at 15:06

Hello,

it is important to configure the device so that conflicting features are not simultaneously enabled .

In case of CSMA You must avoid:

- to strobe the RX command when the CSMA_ON bit is 1. That bit should be set to 1 immediatelly before strobing the Tx command and should be set to 0 when the Tx is done

- to set the CS BLANKING bit when the CSMA is enabled. Indeed, in this case the 2 features may cause a conflict in the digital machine of the device.

So, when You want to TX, You must be sure have disabled the CS_BLANKING clearing the bit 4 in the 0x27 and enable the CSMA. Always keep these 2 features mutually exclusive.

Regards,

F.

kzkaram
Associate II
Posted on August 25, 2015 at 01:55

CS_blanking was indeed the problem. I disabled it and now the CSMA appears to work correctly (i.e as I expect it).

I think such critical and non obvious facts:

- that the CSMA function must only be switched on before Tx and must be switched off immediately afterwards,

- that CS_blanking must be switched off before using CSMA

SHOULD be mentioned in the section on CSMA in the datasheet.

As a general comment I think that its a bit of a pain to have fiddle with all these settings (via SPI) each time you transit between Tx and Rx modes.

i did all the configuration but it doesnt work :( 

const spirit_reg_val_pair_t csma_protocol[] = {
PROTOCOL1_BASE, BIT1 + BIT2, //CSMA_ON+CSMA_PRES_ON
RSSI_FLT_BASE, (CS_MODE << 2), // static CS
RSSI_TH_BASE, RSSI_THRESHOLD, // RSSI thershold
CSMA_CONFIG1_BASE, CSMA_CCA_PERIOD_64TBIT,
CSMA_CONFIG0_BASE, (SPIRIT_CSMA_CCA_LENGTH << 4), 0xFF, 0xFF };   

//CSMA protocol added
#define SPIRIT_CSMA_CCA_LENGTH 2
#define CS_MODE 0
#define RSSI_THRESHOLD 20