SPIRIT1 RX Test

[lz1im]

Posted on May 18, 2015 at 13:07

Hello!

Is it possible to PERMANENTLY Read RSSI Level Reg., in order to make Receiver Msrmnts, like Sensitivity etc... ? Thanks!

[pecorino.salvatore-giorgio]

Posted on May 20, 2015 at 10:37

Hello,

It is possible to get information about RSSI by reading the register RSSI_LEVEL, address 0xC8, in a continuous loop like this below:1. Go in RX state2. Wait for defined period (according to the channel filter bandwidth)2. Send a SABORT command (to stop the RX operation)3. Read the RSSI_LEVEL register4. Go to point 1.About the time necessary to wait before SABORT command, please refer to www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00068699.pdf table 3.Best Regards,S

[lz1im]

Posted on May 22, 2015 at 14:39

I am very angri... Hi!

I am trying to make two nodes, one as Transmitter, other as Receiver. That nodes Communicate from TX toRX with 1.2kbps, 5kHz Deviation, 25 kHz channel filter, at 433 MHz base freq. and Basic Packet. Code from SPIRIT1 DK is: tmp[0] = 0x7D; // reg. 0x09 tmp[1] = 0x89; // reg. 0x0A tmp[2] = 0xEB; // reg. 0x0B tmp[3] = 0x01; // reg. 0x0C SpiritSpiWriteRegisters(0x09, 4, tmp); tmp[0] = 0x01; SpiritSpiWriteRegisters(0x10, 1, tmp); tmp[0] = 0x05; // reg. 0x1B tmp[1] = 0x35; // reg. 0x1C tmp[2] = 0x25; // reg. 0x1D SpiritSpiWriteRegisters(0x1B, 3, tmp); tmp[0] = 0x07; // reg. 0x31 tmp[1] = 0x1F; // reg. 0x32 tmp[2] = 0x50; // reg. 0x33 SpiritSpiWriteRegisters(0x31, 3, tmp); tmp[0] = 0x41; // reg. 0x4F tmp[1] = 0x40; // reg. 0x50 tmp[2] = 0x01; // reg. 0x51 SpiritSpiWriteRegisters(0x4F, 3, tmp); tmp[0] = 0x00; // reg. 0x6E tmp[1] = 0x00; // reg. 0x6F SpiritSpiWriteRegisters(0x6E, 2, tmp); On the TX side it's OK. From READY, then LOCKTX, then TX. Packet is on air, Radio Tester show about 10 mW, deviation is OK, and on ReceiverScanner IC-R5 I hear packet. Beautifull! BUT... On RX side nothing is happen, except that Level at the antenna in time when received packet, is about -65 dBm /from Register RSSI Level/. Of course, I made LOCKRX, then RX CMD, and stay infinitely at RX /No LDCR option are used/. First, I think that it is my mistake, because I made PCB from your Reference Design, and Microcontroller is ATMega644. Surfing on Internet, I discover another C-sources with UNDEFINED! Registers, COMMANDS, and STATES. They are UNDEFINED at ST datasheet about SPIRIT1. So, I read Whole Forum about Low Power RF Solutions and see that at 12/2/2014 huber.hans in post:Spirit1 stuck in setup PM state/0x3B/, he in SPIRIT Register Log, logged Registers that in Datasheet are Reserved, or Not explained, or even not defined! Moreover Mr. Panvini.Gaetano in his replay sayd that ''I don't see anything wrong in those registers values'', end of citate. Combine that with all I wrote above, I make a simple question: Is that Impossible to communicate with IC SPIRIT1 Without! any of ST development boards, or maybe the customer MUST buy with SPIRIT1, some pieces of STM32 microcontroller, or maybe Customer and Manufacturer should play HIDE-AND-SEEK Game?! So, am I right to be angry?

[pecorino.salvatore-giorgio]

Posted on May 25, 2015 at 10:24

Hello,

The ''Export code configuration...'' tool included in the SPIRIT1 DK GUI, version 2.0.0, is intend to be an easy way to export in terms of registers setting a desired configuration tested with the GUI.In this first release, not all the registers in the datasheet are included. So, there are some limitations in particular with the digital clock divider setting. This must be set (1) if the crystal oscillator on board is 24, 25 or 26 MHz. The limitation will be fixed in next release very soon.Included in the software package You have already downloaded, there is the folder Firmware in which we provide beside a low of example applications that can be a nice starting point for testing and development, also a firmware library that it is important to notice is platform independent.I would like to highlight this feature that means the firmware library has been written to be very easy portable in a whatever platform/microcontroller. To do so, the low level driver must be re-implemented according to the actual platform. In example we propose a version for STM32L (path Firmware\STM32L\SDK_Eval_STM32L) and a version for STM8L (path Firmware\STM8L\SDK_Eval_STM8L). That basically, it is just the SPI driver for read/write registers and send commands, and some functions to driver high/low the GPIO (for SHUTDOWN pin and interrupt if You want to use it). The functions are listed inside the file MCU_Interface.h.This allows You to use also the reference code in other microcontrollers.By the way, I guess You are using one of the reference board of the demokit, am I right? May You report me the crystal oscillator frequency? This can be useful to understand about the issue. I think the communication it is ok with the GUI and it is not ok through code, is it?S

[lz1im]

Posted on May 26, 2015 at 09:14

Hello,

Thanks for answer. Now I am not so angry, because I solved the problem. As I say in previous post, the problem is generated by not enough info in datasheet. Concretely, there is a bit in register XO_RCO_TEST to control divide-by-two clock on the input of ''digital macro''. On page 41 at  DM00047607 document /SPIRIT1 Datasheet/ we read:''The safest procedure to disable the divider without any risk of glitches in the digital clock is to switch into STANDBY mode, hence, !!!RESET!!! the bit field PD_CLKDIV in the XO_RCO_TEST register...'' I think, right sentence is !!!SET!!! the bit field PD_CLKDIV. Anyway, if in SPIRIT1 DK Software, setting 26MHZ instead of 52MHz, ''Export code configuration...'' export in conjunction with other registers, register 0xB4, maybe would be not possible to make /Me!/ that mistake. Anyway, setting the correct value of that bit, /PD_CLKDIV=1, because I use TCXO at 26MHz/ solve the problem. Now I work with SPIRIT1 with My own Board, as I wrote in prev. post, with ATMega644 microcontroller and SPIRIT1, and LCD display. SPIRIT1 work great! Maybe next revisions of Datasheet and DK would be more readable and helpful. However, it's all good, when finished good! Sorry about my bad English. Sincerely: Pavel Pavlov, M.Sc. Sr. Designer at Electron Consortium JSC, Sofia, Bulgaria.

[pecorino.salvatore-giorgio]

Posted on May 26, 2015 at 11:08

Hello,

Yes, there is a misleading statement in page 41 different from the bitfield description at page 82. This is already fixed in the next revision that will be released soon, together with a new version of the software package in which also this bit configuration will be exported.Thank You for Your feedback!S

[kzkaram]

Posted on August 14, 2015 at 20:08

So let's say I have my receiver permanently in Rx mode since it is listening for packets from remote devices, then does that mean I can't then get a measure of signal energy on that channel i.e to assess how 'busy' it is in general?

Ok so I thought maybe what I could do is occasionally switch of the RX using SABORT (cmd 0x67), then read the RSSI register, then go back to Rx mode agian (0x61). Just for fun I tried to do this at intervals of 2 seconds (even though I know such far apart spot checks are probably not going to tell the stry very well). So RX for 2s, then SABORT, then read RSSI_REG, Then go to RX again. I notice that every so often the value of the RSSI_REG comes back very low (typically 0) whereas the background is generally about 0x29. So why the occasional 0 values?

[pecorino.salvatore-giorgio]

Posted on August 24, 2015 at 10:44

Hello,

Yes, it is not possible to know the exactly value of the RSSI while the radio is in RX state.So, the SPIRIT1 performs a loop like this: RX for about 2 sec, READY state due to SABORT command and then RSSI_LEVEL register read operation.These are the right operations to read the RSSI level.Just try to check if the state transaction are correct in particular the SPIRIT1 is in READY state before reading the RSSI_LEVEL register.What is the setting for the RX channel filter?Best Regards,S

[kzkaram]

Posted on August 25, 2015 at 02:16

That is a bit of a drawback since it means I regularly have to exit and spend time outside Rx mode in order to get a measure of background channel activity (to make decisions on whether to hop to a different channel for example or give the user some indication of channel utilisation level).

Ok so I will try actively checking that the SPIRIT1 is in READY state, although at the moment what I do is simply have a 100us time delay before reading the RSSI reg, yet still there are occasional zero returns. I'm using the 'typical' example of ~ 38kb data rate, 20khz freq dev, and 100khz channel filter bandwidth, GFSK1.