Frequently jump into rx interrupt handler in CC101 asynchronous serial mode

Hi Siri,

Thanks for your reply.

Sorry I made a mistake in my first description. We ARE using 0x0D or 0x4D for IOCFG2. And you said it, we are using FIFO when in FSK. :-)

Well, do you mean that there might be much raw noise coupled into or genterated in our RF reception path?   Considering the RX interrrupt triggered in a frequency of around 1-10KHz even though there is no sender, do you have any further suggections here?   Embarrassingly, the noise frequency is close to our RX payload baudrate, it is hard for us to process by MCU sampling. Meanwhile, we are in an complex embedded system, and we could not afford such a process waste by such a frequent garbage interrupt.

Thanks again!

Yiming Li

Hi Yiming

There will always be a lot of noise on the air and if you are using async serial mode the MCU must handle this by doing oversampling etc. You will see that if you take your FSK settings and run the radio in async. mode instead of FIFO mode the same is the case there. You will also see that with your ASK settings and the radio in FIFO mode you will be able to send and receive packets even if there are noise on the air.

Can I ask you why you do not want to use FIFO mode and let the radio take care of all the processing?

If you send me info about your packet format I can see if there is a way for the radio to receive these packets without using async. mode.

BR

Siri

Hi Siri,

Thanks for your reply.

First, why we expect to use async serial mode of CC1101:  we expect to use the CC1101 on our ARM9 board to communicate with some devices following 2262/2272 serial protocols, where serial bits streams in few kbps are modulated onto or demodulated from a 433MHz/315MHz carrier in a method of OOK. These simple devices are very cheap and popular in China market of security and smart-home industries.  If we could support 2262/2272 via cc1101 in our system, it will be more flexible than other 2262/2272 chips as well.  Attached please find some information about 2262/2272 and a popular OOK implemenation for your information. For your information, the PDF is a datasheet of 2272 chip. Please quickly examin the sections "code bits" and "code words" in pages 6-7 for packet format. And the JPEG is the schematic of how the serial bits are OOK modulated onto 315MHz carrier.6406.PT2272_Datasheet.pdf 

Second, some progress following your previous guideline: You might have said it. Following your previous guideline, we did some experiments trying to filter and reduce the unexpected noise. And there is some progress achieved.  (1) Add a capacitor serially with inductor near the anttenna (i.e. L123 of tipical application circuit from CC1101 datasheet),  to make something like a "band-pass" at our working carrier frequency. Ensure the impedance matching with the help of smith chart. (2) Make a better contact of chip ground pad to the PCB ground plane.  Then, the occurrency of jumping into RX interrupt are occational other than frequent if there is no sender. And we could extract expected serial bits. The reason might be excluding noises coupled in from outside or reduce internal SSN noise etc. And These improvement in async serial mode makes no damage to the communication in FSK mode.  Sure, there still are unpected garbage data sometimes in a possibility of 1 of 5-10 caused by noise. We notices that there is still some small glitch with a period of around 1/8 to 1/6 occationally which could be captured by the MCU interrupt but they are not what we want. Therefore (3) we are considerding about adding some AC terminators into the GDO2 line to see whether it will be helpful.

However, according to the experiments to the cc1101 and your reply, I also doubt whether there will be a practical upper limitation of improvement if in hardware/electronical manner.  If CC1101 is quite sensitive to even little weak noise in async serial mode, or a little nosise will change the state of GDOx unexpectedly,our above improvement are only an improvement, other than a safe solution.

If you have some good suggestions or solutions to achieve a good result like other-than async serial mode. Please kindlly tell us. Meanwhile actually we don't know how to handle "over-sample" in our complex embedded system with a low overhead.  If you would share some more information with this as well, it will be appreciated.

Thanks, and Best regards,

Yiming Li

Hi Yiming

I will only comment on the packet format, and then I will have someone else comment on the rest as I am a SW engineer.

It might be possible to configure the radio with a data rate equal to 1/α.

A0 is 32α and is

11110000 00000000 11110000 00000000 = 0xF000F000 (BIT 0)

11111111 11110000 11111111 11110000 = 0xFFF0FFF0 (BIT 1) or

11110000 00000000 11111111 11110000 = 0xF000FFF0 (BIT f)

If the receiver knows what A0 is this can be used as a sync word, and the radio can be programmed to fixed packet length to receive the reminding code word (11 x 32 α) = 44 bytes.

The 44 bytes can then be read from the FIFO and decoded back to 11 code bits.

BIT 0, BIT 1, and BIT f are not very good sync words and you have no regular preamble, but it is worth a try.

BR

Siri

Hi Siri,

Thanks a lot for your reply with nice ideas and suggestions . It IS worth a try if we could use FIFO here. Since, at least, we could "receive" messages in a basic of frame, other than in a basic of pulse edge.  Within a manner of pulse edge, MCU have to handle  the interrupt on each edge of GDO2 pulse, which will take up the CPU process greatly. That is, FIFO method will save CPU resources to do us better.

Well come out two following questions on FIFO and Sync word, would you please kindly help us with a further clarification? Thanks in advance.

1. How to config the CC1101 registers to enable RX FIFO for OOK signal?

 If we expect to expoit FIFO of CC1101 for the reception of such an OOK signal, how to configure the key registers of CC1101?  e.g.  what value should we used for MDMCFG2.bit6-4 etc? Since the datasheet says FIFO will be disabled in async serial mode. Possiblly I misunderstood the datasheet. If so, please kindly calarify.

2. Will it cause problems if Sync Word is the same with those bits of reminding code word in a high possibility?

First, since the address of 2262 sender could be configured normally by jumpers, we could fix all A0s in our system easily and used "as"  Sync word. Therefore the word in your last reply "If the receiver knows what A0 is this can be used as a sync word...." could be achieved without any problem. 

However as you know, all A0-A11 could only be '0', '1', or 'f', one of the three options, which means that, if we select one of the three "as" Sync word, it might be in a high possibility to be the same with some other bits of the reminding code word. Will it cause problems? If yes,  any good suggestions to compensate for it? 

Anyway, this method is a good one since, at least, we could define 'f' for an example for A0, and avoid 'f' in other reminding bits, even thougth it might reduce the max number of addressible nodes.

Meanwhile, I will have a try using your method and update shortly. Hope to have a good result!

Thanks and Best regards,

Yiming Li

In asynchronous serial mode you only get the raw data oversampled by 8 x symbol rate. There is no data deciscion nor synchronization. You will get jitter (especially for weak input signal) that are 1/8 of the configured symbol period. The interfacing MCU needs to handle this jitter.

Ideas:

- A majority value of three or five input samples to produce each output sample (for 8x oversampling)
- Swallow any pulses that last less than four input samples (for 8x oversampling)

Hi Yiming

Please use SmartRF Studio to generate you settings. Select a typical setting with a data rate close to what you want to achieve as a starting point. The register setup you get will then be for FIFO mode.

Change data rate, sync word etc. to match your protocol. In the advance tab, select fixed packet length mode and set packet length to 44. Manually changed the register settings for ASK/OOK as described in DN022  and use the code export function to get the settings Studio has generated.

If you find the correct sync word it is not a problem for the radio that the sync word is present in the payload of the packet as well. Once sync is found the radio will receive 44 bytes and then exit RX.

The challenge is that you do not have a preamble so it might be that the radio does not find the first sync word but rather get a hit in the middle of the packet. If you see that this is problem you can try to reduce the length of the sync word you are looking for (for example the 16 LSB of A0) and then use CS gating of sync detection instead to avoid false sync detects.

BR

Siri