Drivers for the sub-GHz CC1101 and CC1120 radios

[adamdunkels]

This patch contributes the latest Thingsquare drivers for the sub-GHz radios CC1101 and CC1120, along with a few updates to the Cooja emulation of the chips. There are also updates to the MSPsim emulation code: contiki-os/mspsim#4

These drivers are used in several commercial products and should be pretty solid by now.

[uknoblic]

Adam, will there be support for the CC1200 as well? I m currently working on a CC1200 driver (based on preliminary work for the CC1120, but with some modifications as e.g. proposed by TI). Maybe it would make sense to "bundle" this work also to get drivers which are at least compatible on the radio interface?

[alignan]

Nice and most awaited patch! 👍

On Tue, Mar 24, 2015 at 4:30 PM, uknoblic notifications@github.com wrote:

Adam, will there be support for the CC1200 as well? I m currently working
on a CC1200 driver (based on preliminary work for the CC1120, but with some
modifications as e.g. proposed by TI). Maybe it would make sense to
"bundle" this work also to get drivers which are at least compatible on the
radio interface?

—
Reply to this email directly or view it on GitHub
#1002 (comment).

Antonio Liñan
[image: http://]about.me/antoniolignan
http://about.me/antoniolignan?promo=email_sig

[adamdunkels]

@uknoblic We have an CC1200 driver that we use internally at Thingsquare, but it is not yet ready to be released. The differences between the CC1120 and the CC1200 are pretty small though.

[jonnteolsson]

I like this :) Does anyone have plans to add a platform to support the drivers in this pull?

[alignan]

Myself, see:

http://zolertia.io/product/hardware/re-mote

This is the first prototype, we may move to the CC1200 later.

Any other?

On Wed, Mar 25, 2015 at 9:15 AM, Jonas Olsson notifications@github.com
wrote:

I like this :) Does anyone have plans to add a platform to support the
drivers in this pull?

—
Reply to this email directly or view it on GitHub
#1002 (comment).

Antonio Liñan
[image: http://]about.me/antoniolignan
http://about.me/antoniolignan?promo=email_sig

[adamdunkels]

I think @uknoblic has an upcoming platform with CC1120 + ENC28j60 as well.

[uknoblic]

Yes, we are already using an CC1200. Our platform (cc2538-cc1200-eth) is ment as a low cost gateway solution and will serve both as a development platform and end product (withh enclosure).

[adamdunkels]

Very cool!

[msloth]

Looks very nice, do you have an ETA on when it will be available?

[uknoblic]

We plan to release this device it end of may.

[jonnteolsson]

I was very well aware of those two nice platforms! Both looks amazing :) Anyone else?

Making it super easy to connect to the Internet will definitely help speed-up the IoT market.

[g-oikonomou]

👍 👍 👍 for the feature, but I do have some questions:

• If we don't need makefiles for CC2420 and CC2520, why do we need them here?
• Why are we putting -msp-arch.c under /dev and not under cpu/msp430/<wherever>
• Why are there blocks of code wrapped inside #if 0 instead of inside a meaningful config (if needed) or instead of removed altogether?
• There are traces of TS' CSL in this pull. Intentional?
• I am not a huge fan of defining stuff in the middle of a function. Is it just me? :)

[g-oikonomou]

@adamdunkels Adam, this is kicking and screaming to get merged. Any comments on my questions above?

[alignan]

This is msp430 specific, not portable to other platforms, i.e cc2538dk.

[alignan]

Also the BV macro is not defined for all platforms, perhaps replace by (1 << 5) or include this macro in a different PR?

[uknoblic]

Hi, with regard to my PR for the cc1200 (#1083) driver, shouldn't we consider at least to reach an agreement with regard to the channel setup? In the cc1200 driver, i use the channel setup as described in the 802.15.4g (SUN-PHY). This setup will give us (for 50kbps FSK) the following three channels (speaking for ETSI SRDs, old bands "g1, g2, g3, g4"): 868.325 MHz (new: g1.1), 868.925 MHz (new: g1.2) + 869.525 MHz (new: g1.3). In many European countries the complete band 863 - 870 (g1) MHz is available anyway (www.erodocdb.dk/Docs/doc98/official/pdf/Rec7003e.PDF).

I would also propose to have a look at the way i calculate the frequency registers (kHz resolution) which is not as restrictive as the way it is done here (16th MHz resolution for the cc1120).

[LanshunNie]

Thanks for these great drivers. It help us a lot.

When using this CC1120 driver with Contikimac, a bug appears, i.e. radio does not sleep after receiving a packet. Would anyone helps us out?

Let me explain the bug in detail.
We port this driver to a custom platform--MSP430F5418A+CC1120 @433MHz. When receiver detects a packet by CCA, receive it and deliver it to Contikimac, radio should go to sleep. However, it stays in IDLE state with a current about 2.5mA and only goes to sleep if the next duty cycle period doesn't detect any packet. By examing it carefully, we found that cc1120_rx_interrupt() is called after delivering packet to RDC layer, i.e. NETSTACK_RDC.input();. The "state()" statement in this function will turn radio on and keep it in IDLE.
So, my question is how to fix this bug elegantly in order to achieve ultra-low power?
Thanks in advance.
@adamdunkels

[LanshunNie]

If we add a NETSTACK_RADIO.off() in the end of pollhandler() function, the radio will be turned off.
But, it seems that this fix decreases packet delivery ratio slightly, : (.

[alexrayne]

i`ve merge this code easy, why this still not in master?

[MartenBE]

Is there any problem with these drivers which prevents them to be merged into master?