Sign in to follow this  
Followers 0
none2

CC110L / AIR Bosterpack with OOK sends a Bit too much

5 posts in this topic

TI Launchpad with MSP430G2553 @ 1 MHz and AIR Booster Pack with Anaren LR09A (CC110L [the light version of CC1101] with 27 MHz xtal and 900 MHz PCB antenna).

 






 

The following code is supposed to send a single byte with OOK at 868 MHz.

After choosing the correct XTAL frequency and removing "hidden" settings CRC_EN and APPEND_STATUS from the output of SMARTRF Studio 7 (note it also outputs invalid value 0x127 for RESERVED @ 0x2A -> see the datasheet, the default 0x7F is erroneously output as decimal), the byte is being sent, but if the last bit is set, an additional bit is added to that it has twice the intended bit time.

See the attached resulting waveform for 0xB1 (0b10110001), recorded as AF with rtl-sdr / SDR# and shown in Audacity.

Are there any settings that could cause this? Am I doing anything wrong? The Errata only mention sending a byte twice.


#include <msp430.h>
#include "stdint.h"
#include "stdbool.h"

// Anaren AIR booster pack with LR09A (868/9xx MHz)
// CC110L
#define GDO2_BIT BIT0 // P1
#define SCLK_BIT BIT5 // P1
#define MISO_BIT BIT6 // P1
#define MOSI_BIT BIT7 // P1

#define GDO0_BIT BIT6 // P2
#define CSN_BIT BIT7 // P2

// 2553
//#define LEDrd_BIT BIT0 // P1
#define RX_BIT BIT1 // P1
#define TX_BIT BIT2 // P1
#define button_BIT BIT3 // P1
//#define LEDgn_BIT BIT6 // P1

uint8_t status;
uint8_t test;

uint8_t
softSPI(
uint8_t write
)
{
uint8_t read = 0;

P1OUT &= ~(SCLK_BIT);

uint8_t n;
for(n=8; n--{

// OUT
if (write & 1<<n){
P1OUT |= MOSI_BIT;
}
else{
P1OUT &= ~(MOSI_BIT);
}

// CLOCK
P1OUT |= SCLK_BIT;

// IN
if (P1IN & MISO_BIT){
read |= 1<<n;
}

P1OUT &= ~(SCLK_BIT);
}

return read;
}

uint8_t
CC(
bool rw,
bool burst,
uint8_t address,
uint8_t data
)
{
uint8_t header =
(rw<<7) //
|(burst<<6) //
|(address & 0x3F) // 0x00 to 0x2E.
;

P2OUT &= ~(CSN_BIT);
while(P1IN & MISO_BIT);

/*uint8_t*/ status = softSPI(header);
uint8_t read = softSPI(data);

P2OUT |= CSN_BIT;

return read;
}

uint8_t CS(
bool rw,
uint8_t address
)
{
uint8_t header =
(rw<<7) //
//|(0<<6) //
|(address & 0x3D) // 0x30 through 0x3D).
;

P2OUT &= ~(CSN_BIT);
while(P1IN & MISO_BIT);

uint8_t status = softSPI(header);

P2OUT |= CSN_BIT;

return status;
}

int main(void) {

// Stop watchdog timer
WDTCTL = WDTPW | WDTHOLD;

BCSCTL1 = CALBC1_1MHZ;
DCOCTL = CALDCO_1MHZ;

// serial
P1DIR = TX_BIT;
P2DIR = 0;

// CC110x soft-SPI
P1DIR |= (MOSI_BIT | SCLK_BIT);

P2OUT |= CSN_BIT;
P2DIR |= (CSN_BIT);
P2SEL &= ~(CSN_BIT);
P2SEL2 &= ~(CSN_BIT);

// Manual Reset

// Set SCLK = 1 and SI = 0.
P1OUT |= (SCLK_BIT);
P1OUT &= ~(MOSI_BIT);

// Strobe CSn low / high.
//P2OUT &= ~(CSN_BIT);
//P2OUT |= CSN_BIT;
// Hold CSn low and then high for at least 40

post-49620-0-41861400-1478851727_thumb.png

Share this post


Link to post
Share on other sites
  CC(false, false, 0x0029, 0x89);   // RESERVED_0X29      Use setting from SmartRF Studio
  CC(false, false, 0x002A, 0x127);  // RESERVED_0X2A      Use setting from SmartRF Studio
  CC(false, false, 0x002B, 0x63);   // RESERVED_0X2B      Use setting from SmartRF Studio

I just noticed that SmartRF studio incorrectly outputs _all_ the values for RESERVED, not just for 0x2A. These are simply decimal values prepended with "0x" by the output formatter. The cause is twofold:

whoever wrote the file "C:\Program Files (x86)\Texas Instruments\SmartRF Tools\SmartRF Studio 7\config\xml\cc110L\register_definition.xml" did not stick to the standard hexadecimal notation used for all other values, maybe assuming the software could handle it (after all, the toolchain does). Whoever wrote the software failed to range or type-test these values.

 

"C:\Program Files (x86)\Texas Instruments\SmartRF Tools\SmartRF Studio 7\bin\version.txt" says

build #release23

 

Exe version is 2.4.3.0

 

I'd say this is a bug!

Share this post


Link to post
Share on other sites

In your CC you have:
      |(address & 0x3F)  // 0x00 to 0x2E.
and in your CS you have:
      |(address & 0x3D)  // 0x30 through 0x3D).

Your
    CS(0, 0x30);  // Reset
    CS(0, 0x3D);  // NOP, TX FIFO free
gives the correct adr, but your
    CS(1, 0x3A);  // flush RX FIFO
    CS(1, 0x3B);  // flush TX FIFO
gives 0x3A & 0x3D -> 0x38 and 0x3B & 0x3D -> 0x39
should it not have be with 0x3F instead of 0x3D
 

Share this post


Link to post
Share on other sites

Thanks again for pointing out my mistake.

I've changed the address mask to 0x3F but it does not affect the bit duplication.

Of course an easy workaround is to pad the data with zero bits at the end. Or, if the receiver does not care, just ignore it.

It does waste a bit time of RF energy, though..

If someone could replicate, I'd be very interested. Chip version reads 7 (I think I bought the module when it came out).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0