Below is a partial email correspondence started with TI, as I was told to post here.
Issues:
1) Firmware: SmartRFStudio asks to 'update' to an older version of the development board firmware - is this correct or acceptable, or will I lose functionality? When I start RFStudio (the latest version available on the website, 1.3.2), I double-click on ‘Connected Devices’ and a window pops up saying ‘The Evaluation Board is running unknown firmware or an obsolete version of the standard firmware. Current Version: 2.4.8.02, Update to: 2.4.4.0 ?’
2) Other RFStudio: I can still open the control panel without this firmware update, and therefore play around with some register settings, but I cannot test and upload them. My workaround to this is rather simple, I simply input the register settings directly to the RF settings in the appropriate C file of the compiler. I’ve gotten the radio to work at the desired 500 KBaud, but I’d like to run TI’s tests just to know if everything is done correctly. Also, I noticed that when I input my desired settings (904 MHz base freq, 60 channels for hopping, 350 kHz channel spacing, 26 MHz Xtal freq, 499.878 kBaud, 464.28 RX filter BW, MSK, and 10 dBm TX power), the register settings seem to default to an infinite packet length, synchronous serial mode. I’ve changed the register settings to our desired variable-length packet mode (up to 255 bytes) and we utilize the TX and RX FIFO’s. I guess my question is – why is the only available ‘typical setting’ for 500kBaud this synchronous serial mode? If we saturate the channel with a full datastream, will the radios be able to handle the 500 kBaud throughput using the variable-length packet mode? Is our setup just non-typical or would we see problems transferring that much packetized data? I will continue to devise my own tests, but I have a feeling that the tests within RFStudio take into account the limitations of the radio much better than I could.
3) Transmission Time and Delay: Our goal is to transmit an 80 byte packet 720 times each second (roughly 460kbps). I am noticing, with settings above, that transmitting an 80-byte packet takes approximately 1.5ms (measured with a scope and interrupt GDO0, which goes high when a sync word is detected in transmit, and goes low when an end-of-packet is detected). I also set up a test point that measures the time between calling a function to send packet (writing burst register to the TX FIFO and beginning the process) and when the actual sync word is detected and transmission begins (also the GDO0 trigger above)... and there is a delay of 1.2ms! This seems a very high latency for the radio to begin transmission and results in our data being fully transmitted after a total delay of 2.7ms... Even if I could get the radio to transmit a fully packed data stream of 80 bytes / 1.5 ms (which seems unlikely), this only translates to roughly 426kBaud. I am not achieving the target 500kBaud data rate that is advertised. My RFSettings are listed below - those unlisted are default values.
void writeRFSettings(void) {
// Write register settings
CC_SPIWriteReg(TI_CCxxx0_IOCFG2, 0x00); // GDO2 RX FIFO > THRESHOLD to RX FIFO < THRESHOLD
CC_SPIWriteReg(TI_CCxxx0_IOCFG1, 0x0B); // Serial Clock
CC_SPIWriteReg(TI_CCxxx0_IOCFG0, 0x06); // Goes low on FIFO overflow/underflow
CC_SPIWriteReg(TI_CCxxx0_FIFOTHR, RF_FIFO_THR);
CC_SPIWriteReg(TI_CCxxx0_PKTLEN, 0xFF); // Packet length.
CC_SPIWriteReg(TI_CCxxx0_PKTCTRL1, 0x05); // Packet automation control.
// Address check, no broadcast = 1 + APPEND_STATUS = 4
CC_SPIWriteReg(TI_CCxxx0_PKTCTRL0, 0x05); // Packet automation control.
// variable packet = 1, enable CRC = 4
CC_SPIWriteReg(TI_CCxxx0_ADDR, RF_ADDRESS); // Device address.
CC_SPIWriteReg(TI_CCxxx0_CHANNR, 0x00); // Channel number.
CC_SPIWriteReg(TI_CCxxx0_FSCTRL1, 0x0B); // Freq synthesizer control.
CC_SPIWriteReg(TI_CCxxx0_FSCTRL0, 0x00); // Freq synthesizer control.
CC_SPIWriteReg(TI_CCxxx0_FREQ2, 0x22); // Freq control word, high byte
CC_SPIWriteReg(TI_CCxxx0_FREQ1, 0xC4); // Freq control word, mid byte.
CC_SPIWriteReg(TI_CCxxx0_FREQ0, 0xEC); // Freq control word, low byte.
CC_SPIWriteReg(TI_CCxxx0_MDMCFG4, 0x3E); // Modem configuration.
CC_SPIWriteReg(TI_CCxxx0_MDMCFG3, 0x0C); // Modem configuration.
CC_SPIWriteReg(TI_CCxxx0_MDMCFG2, 0x73); // Modem configuration.
CC_SPIWriteReg(TI_CCxxx0_MDMCFG1, 0x43); // Modem configuration.
CC_SPIWriteReg(TI_CCxxx0_MDMCFG0, 0xB9); // Modem configuration.
CC_SPIWriteReg(TI_CCxxx0_DEVIATN, 0x00); // Modem dev (when FSK mod en)
CC_SPIWriteReg(TI_CCxxx0_MCSM1 , 0x3F); //MainRadio Cntrl State Machine
CC_SPIWriteReg(TI_CCxxx0_MCSM0 , 0x18); //MainRadio Cntrl State Machine
CC_SPIWriteReg(TI_CCxxx0_FOCCFG, 0x1D); // Freq Offset Compens. Config
CC_SPIWriteReg(TI_CCxxx0_BSCFG, 0x1C); // Bit synchronization config.
CC_SPIWriteReg(TI_CCxxx0_AGCCTRL2, 0xC7); // AGC control.
CC_SPIWriteReg(TI_CCxxx0_AGCCTRL1, 0x00); // AGC control.
CC_SPIWriteReg(TI_CCxxx0_AGCCTRL0, 0xB2); // AGC control.
CC_SPIWriteReg(TI_CCxxx0_FREND1, 0xB6); // Front end RX configuration.
CC_SPIWriteReg(TI_CCxxx0_FREND0, 0x10); // Front end RX configuration.
CC_SPIWriteReg(TI_CCxxx0_FSCAL3, 0xEA); // Frequency synthesizer cal.
CC_SPIWriteReg(TI_CCxxx0_FSCAL2, 0x0A); // Frequency synthesizer cal.
CC_SPIWriteReg(TI_CCxxx0_FSCAL1, 0x00); // Frequency synthesizer cal.
CC_SPIWriteReg(TI_CCxxx0_FSCAL0, 0x1F); // Frequency synthesizer cal.
CC_SPIWriteReg(TI_CCxxx0_FSTEST, 0x59); // Frequency synthesizer cal.
CC_SPIWriteReg(TI_CCxxx0_TEST2, 0x88); // Various test settings.
CC_SPIWriteReg(TI_CCxxx0_TEST1, 0x31); // Various test settings.
CC_SPIWriteReg(TI_CCxxx0_TEST0, 0x0B); // Various test settings.
Any help is greatly appreciated. I will continue testing and be eying this forum frequently.
