This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SmartRF Studio 7 and CC430 Chronos problems

Other Parts Discussed in Thread: TEST2

Hello,

 

while evaluating the TI chronos with the SmartRF Studio 7 (version 1.4.9 and 1.3.2) I observe the register content of the CC430 is often partially lost. This is observable with two effects:

first: the device does not work as expected (e.g. channel spacing in the RF parameters does some times not match the effective register content (observable in TX with a spectrum analyzer))

second: every time I read the register contents back with the "Refresh" button, i get new register contents differing from what was programmed (highlighted in red) for example in the MDMCFGx registers.

This behaviour is observable with both Chonos watches (one 433 and one 868 version) I own.

The Host PC is running WinXp SP2 and the SmartRfg Studio is run with admin rights (I also tried normal user)

 

Any ideas about what goes wrong?

 

Thanks in advance! 

JensM

jensD.

This MCFMDMCFG0

  • Hi Jens,

    Thanks for the feedback. Can you give a description of the steps you do when your second problem appear? I would like to try recreate the problem here.

    For the first problem, are there other ways the device does not work as expected?

    Regards,

    Bjørn

  • Hello Bjoern,

     

    for the second problem: I just load a complete configuration file that was previously saved. I can then observe in the log window, that the registers are all written. When I then hit the button "refresh" below the register list, I get changed values. The affected registers are highlighted in red. See image below.

    It seems as always the same registers a lost, when i try the "refresh" button.

    For the device behaviour itself: I was up to date not able to receive a single bit with the chronos when used with the SmartRF studio. The device itself works well with the default SW though. I can get it to contiuously transmit the acceleration data to the PC dongle. So the HW itself seems to work. I suspect the receiver bandwith and other register contents prevent any reasonable reception. Transmission works mostly with smart RF studio: At least I see something on the spectrum analyzer.

    But when used with the SmartRF studio: no luck. Even when I set up both chronos watches under the SmartRF studio with the same settings (loaded from a file) I am not able to tranfer packets from one device to the other. Well, the antenna setup is not perfect, but when the devices are within centimeters from each other that should not matter.

    So, my interpretation of the behaviour is some communication glitch between the chronos watch and the SmartRF studio.

  • Hi,

    Thanks  for the description. For the second problem, I can confirm that I see the same here. I think the problem is caused by some registers are written during loading of the config which should have been write protected i.e. if you systematically remove some of the registers from the saved config file you will see that the problems disappear.

    We will investigate this further and hopefully fix it until next version of SmartRF Studio.

    Regards,

    Bjørn

     

  • Hi,

     

    thanks for the workaround. Indeed, when I delete some of the register contents in the XML config file, the error with the lost/changed register contents goes away.

    Luckily you guys introduced the XML settings format in the latest version of SmartRF studio. In the binary version it would not have been so easy.

    I will now go on to test the actual device behaviour.

    If someone else needs this workaround:

    I deleted these registers: (I'm not sure whether the RF1Axxx registers are needed in the config file)

    <Register>

        <Name>AGCTEST</Name>
                <Value>0x3f</Value>
            </Register>
            <Register>

            <Name>FSTEST</Name>
                <Value>0x59</Value>
            </Register>
    <Register>
                <Name>LQI</Name>
                <Value>0x5e</Value>
            </Register>
            <Register>
                <Name>MARCSTATE</Name>
                <Value>0x11</Value>
            </Register>

            <Register>
                <Name>PKTSTATUS</Name>
                <Value>0x20</Value>
            </Register>
            <Register>
                <Name>PTEST</Name>
                <Value>0x7f</Value>
            </Register>
            <Register>
                <Name>RF1ADINW</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ADOUT0W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ADOUT1W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ADOUT2W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIE</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIES</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFCTL0</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFCTL1</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFCTL2</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFERR</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFERRV</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFG</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIFIV</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIN</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AINSTR1W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AINSTR2W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AINSTRW</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1AIV</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ARXFIFO</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ASTAT0W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ASTAT1W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ASTAT2W</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RF1ATXFIFO</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>RSSI</Name>
                <Value>0xb4</Value>
            </Register>
            <Register>
                <Name>RXBYTES</Name>
                <Value>0xc1</Value>
            </Register>

    <Register>
                <Name>TEST0</Name>
                <Value>0x0b</Value>
            </Register>
            <Register>
                <Name>TEST1</Name>
                <Value>0x35</Value>
            </Register>
            <Register>
                <Name>TEST2</Name>
                <Value>0x81</Value>
            </Register>
            <Register>
                <Name>TXBYTES</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>VCO_VC_DAC</Name>
                <Value>0xfd</Value>
            </Register>
            <Register>
                <Name>VERSION</Name>
                <Value>0x06</Value>
            </Register>

    <Register>
                <Name>WORTIME0</Name>
                <Value>0x00</Value>
            </Register>
            <Register>
                <Name>WORTIME1</Name>
                <Value>0x00</Value>
            </Register>

  • Hi,

     

    additional info:

    even with the apparent register problem solved due to the workaround, I can't seem to get the CC430 to receive anything in connection with the SmartRF studio.

    Even when I go back to the easy mode and select the same settings in both CC430 Chronos devices, which are only 1 cm apart, there is no reception at all. Even if I switch to the expert mode and reload the same setting as for the easy mode (by saving and manipulating the XML-file) I do not even get any RSSI reception in the "continous RX" tab. (the RSSI level stays below -110 dBm). But a spectrum analyzer shows significant output.

    When I reverse the RX-TX-role of the devices back and forth I see each time a clear output at the expected frequency on the spectrum analyzer, so the settings seem to be OK.

    Currently I come to the conclusion that the RX mode is not working at all under SmartRf studio in connection with the CC430 chronos watches.

    One additional test with the activation of the Bluerobin heart rate sim in connection with the separate USB dongle showed repeated output around 433.65 MHz the RSSI signal in the sutiable chronos watch stayed below -110 dBm.

    A very confusing feature in SmartRf studio is that the setting under easy mode and expert mode seem to be completely separate. I would have expected that when I switch from the easy mode to the expert mode that the current register settings are taken as the base for all settings. Saving in easy mode and reading back in expert mode does also not work since the mode is changed to the state when the settings were saved. I had to manipulate the XML file to read the registers back in expert mode that were previously saved in easy mode.

  • Hi,

    I think you should try having more distance between the two devices. The radios might get saturation if they are placed too close to each other. I have a test setup with one EM-CC430F5137-900, and one Chronos device on my desk. They are placed about 50 cm apart, and I can get a link between them. However when sending from the CC430EM I see that not all packets are received by the Chronos (only about 50% of them). This is probably because the USB interface to the Chronos is slower than the one on the CC430EM, so the CC430EM is sending packets with too short interval. The CC430 support in SmartRF Studio was developed and tested with CC430 EM's originally, but has later been extended to support the Chronos device also. If you send 1 and 1 packet manually they should all be received.

    As you say Expert Mode and Easy Mode are completely separate, and they have separate register settings (these are defined by the XML files typical_settings.xml and easymode_settings.xml if you want to tweak them). The idea of Easy Mode was a mode where it is very simple to get a link up between two devices without having to worry about parameters like data rate, modulation, just simply select an Easy Mode setting, select TX or RX and press start. In Expert Mode you can tweak all of the parameters. The parameters panel is by default disabled in Easy Mode, but it can still be enabled by checking "RF parameters". We have not really considered the use case where you save registers in Easy Mode and load them back in Expert Mode. A way around is as you say to manipulate the saved config file. You can also extend the files typical_settings.xml or easymode_settings.xml with your own settings if you like. Thanks for the input on this.

    Regards,

    Bjørn