CC430 in SmartRF studio

What register settings are you using in SmartRF Studio? Could you please post them as a xml config file to be opened in SmartRF Studio.

Hi Martin,

Just using the first set of settings in expert mode changing frequency to 433Mhz.

Please see the settings below (not sure how to attach the file here)

Regards,

Sergey

// Rf settings for CC430

RF_SETTINGS code rfSettings = {

0x06, // IOCFG0 GDO0 Output Configuration

0x47, // FIFOTHR RX FIFO and TX FIFO Thresholds

0x05, // PKTCTRL0 Packet Automation Control

0x06, // FSCTRL1 Frequency Synthesizer Control

0x21, // FREQ2 Frequency Control Word, High Byte

0x62, // FREQ1 Frequency Control Word, Middle Byte

0x76, // FREQ0 Frequency Control Word, Low Byte

0xF5, // MDMCFG4 Modem Configuration

0x83, // MDMCFG3 Modem Configuration

0x13, // MDMCFG2 Modem Configuration

0x15, // DEVIATN Modem Deviation Setting

0x10, // MCSM0 Main Radio Control State Machine Configuration

0x16, // FOCCFG Frequency Offset Compensation Configuration

0xFB, // WORCTRL Wake On Radio Control

0xE9, // FSCAL3 Frequency Synthesizer Calibration

0x2A, // FSCAL2 Frequency Synthesizer Calibration

0x00, // FSCAL1 Frequency Synthesizer Calibration

0x1F, // FSCAL0 Frequency Synthesizer Calibration

0x81, // TEST2 Various Test Settings

0x35, // TEST1 Various Test Settings

0x09, // TEST0 Various Test Settings

};

What version of the Chronos watch do you have i terms of frequency? Do you have the 433 version?

yes its 433Mhz of course.

Was just checking the box and it says Date: 52/2010, so may be there was some fix after that?

Regards,

Sergey

Hi,

You could also try set a longer packet interval on the sender side to see if that has effect (This can be adjusted in the Packet TX panel under 'Advanced').

Regards,

Bjørn

Hi Bjorn,

Thanks for the advice ill try doing that.

But I'm afraid it wont help. Initially i started by running Simpliciti application that would broadcast a packet every 5 seconds. It did work if I used 2 watches, but doesnt work when I send from the custom board.

Please note that I dont have external crystall on XIN/XOUT installed, so I'm using only internal clock. Can that be an issue?

Regards,

Sergey

It could be the two devices are on slightly different frequency if the crystal on one or both is not very accurate. You could try increase the RX BW on the receiver and see if that helps.

Bjørn

Sounds like an idea. Sorry for the stupid question but what would be the reasonable value to increase it by?

Thanks,

Sergey

You could try one of the settings in Studio that has a high RX BW originally, and if it doesnt work maybe try double it and see if that helps.

Regards,

Bjørn

Hi,

it may also help to disable the CRC feature in PKTCTRL0: Bit 2 = 0 or reduce the sync word size on both sides in a first step. Once you at least receive something, you can go further.

Regards,

Dirk

Bjorn,

I tried using profile with the highest RX BW 540 Khz, unfortunately it hasnt helped.

I also tried setting Packet TX and Continuous RX and it should probably gives some peaks on the receiver, unfortunately no activity has been detected.

What else could we try?

Thanks,

Sergey

Dirk,

I tried turning CRC off per your advice, also setting sync to 15/16 and no sync. That still didnt help...

Any more ideas?

Thanks,

Sergey

Hi Sergey,

now, it becomes a little bit difficult without the hardware at hand. But you may try the following: In MCSM0, you set the PO_TIMEOUT to the smallest possible value. could you increase this (0x10 ->  0x18 or 0x1C)?  This allows the oscillator to become stable.

Try to send a huge preamble: if continuous communication works, but packet mode does not, the preamble may improve the fix. -> MDMCFG1 = 0x70

Maybe, the TI experts can advise if the FOCCFG settings are correct. I am not sure about FOC_BS_CS_GATE.

Regards,

Dirk

Hi Dirk,

thanks for the help. However I wasnt able to find the PO_TIMEOUT in MCSM0.

A weird thing happen Last evening I was able to transmit and receive separate packages. Today in the morning I was not able to repeat the success. And now it did work again. This is a bit weird, sounds more like a hardware issue - pressure or temperature changes and crystal is behaving incorrectly may be?

It does work stable on reception!

I'm using TXC 9C-26.000MEEJ-T as a crystal and 2x15pF capacitors.

Any ideas?

Thanks for the help!

Sergey

Hi Sergey,

first of all, congratulations, now you can monitor your actiions and final success is not very far. Many HW issues can be caught in software. Your load capacitance sounds rather high to me, but this depends on your layout. You may try 2x <10pF, but I don't think that this will be required.

I rather assume that in the evening, the devices were at the right temperature, and worked well together. Therefore, I recommend the following:

a) µC stabilization
Please check that the internal (µC) oscillator has sufficient time to stabilize after reset, a loop before your init will help here. I recognize very strange behaviour, when this is not guaranteed and if the PLL lock is not taken into account.
I always start using a stable 3v3 power supply before switching to lower voltages that may require lower clock speed.

b) RF stabilization
When switching to Rx and Tx state, you already do autocalibration (0x18: MCSM0– Main Radio Control State Machine Configuration bits 4 and 5). Bit 2 and 3 define the timeout for the oscillator and voltage to become stable. Try using the highest value (3) until your system is really stable.

c) radio issues
First of all, please connect the two boards using a coaxial cable and attenuators providing at least 20dB attenuation. This blanks out other devices disurbing you, and differences caused by your exact positions, multi-paths and so on.
As you are now able to to receive packets, you can try to play with the frequency offset and check the RSSI to find the best center frequency. In an iterative process, modify the Rx filter bandwidth to end up with the expected bandwith as discussed above.

I hope this helps a little,

Dirk

According to the data sheet, the crystal you are using is 18 pF of load capacitance. If the board you designed has a load capacitor to ground on each lead of the crystal, then these caps need to be 2x the load capacitance in order to get the proper loading. This is because two caps to ground on the crystal leads is equivalent to two capacitors in series between the two leads. For ac signals the common ground acts as connection node. If you are using 15 pf load capacitors, your crystal frequency is probably off by 10s of kHz and so your cc430 output frequency willl also be off by 10s of kHz. I know this for a fact because my cc430 design was off by 70 kHz because I used 1x load capacitor values for the capacitors on my design. 

 You can test this by setting one unit to continuous recieve, and then set your board design to continuous xmit and vary the frequency of the xmit board in 10 khz steps and see when the receiver signal peaks.

Hi Timothy, i have just one board with 2x 15pF, not even sure why HW developers installed them. All other boards have 27pF installed on them, but with the same issue. May be 27 is not enough and we have to put 36pF with this crystal.

Ill give it a go, thanks for the hint.

Regards,

Sergey

Hi guys,

Thanks for all the support. Just wanted to tell you that the problem has been resolved. We changed the 26Mhz crystals to the ones suggested by TI and all operations within SmartRF studio started working.

However having problems turning RXON mode in SimplicciTI, the code crashes when trying to run step by step with the following output:

MSP430: Trouble Reading Memory Block at 0x10000 on Page 0 of Length 0xf: Invalid parameter(s)
MSP430: Trouble Reading Memory Block at 0x10000 on Page 0 of Length 0x77: Invalid parameter(s)

Anybody has experience with this?

Thanks,

Sergey