Hi Gabriel,

Sorry for the late reply!

I'm happy that you could resolve the issue. However, I have some comments on your notes above.

I did further tests on this issue, and found that the CMD_ERROR interrupt was caused because there is a CRC_ERROR on the previous packet (as it is documented in the device's errata).

I enabled CRC on Field 1 because I wanted to create similar CRC configuration on both the TX and RX side. It would be also consistent configuration, if the CRC transmission would be disabled on F1 on the TX side.

You should also consider the Field 1's content when variable length configuration is used, since it defines how much bytes are sent out by the transmitter and expected by the receiver. If in the first byte you store 0xC5 as it is the default value, it is obviously wrong, if you want to send out packets up to 63 bytes of payload.

If you set up CRC transmission on Field 1, the CRC will be calculated only in this field, and it will be placed right after Field 1. I don't think that's what you want.

Enabling split packet configuration (where the RX and TX packet handler is different) would make the configurator GUI too complicated for most users, as well as it is rarely needed. I'm confident that all configuration is shared between RX and TX, since the split configuration is disabled.

Best Regards,
Bence

Hi Gabriel,

Sorry for the late reply!

I'm happy that you could resolve the issue. However, I have some comments on your notes above.

I did further tests on this issue, and found that the CMD_ERROR interrupt was caused because there is a CRC_ERROR on the previous packet (as it is documented in the device's errata).

I enabled CRC on Field 1 because I wanted to create similar CRC configuration on both the TX and RX side. It would be also consistent configuration, if the CRC transmission would be disabled on F1 on the TX side.

CORRECTION:
You should also consider the Field 1's content when variable length configuration is used, since it does not define how much bytes are sent out by the transmitter, but defines the expected packet length on the receiver. If in the first byte you store 0xC5 as it is the default value, it is obviously wrong, if you want the RX to receive out packets up to 63 bytes.

If you set up CRC transmission on Field 1, the CRC will be calculated only in this field, and it will be placed right after Field 1. I don't think that's what you want.

Enabling split packet configuration (where the RX and TX packet handler is different) would make the configurator GUI too complicated for most users, as well as it is rarely needed. I'm confident that all configuration is shared between RX and TX, since the split configuration is disabled.

Best Regards,
Bence

Hi Juan,

I want to highlight, that there might be two issues, which were addressed by Jim:
1. By importing your radio configuration into a RAILTest project the packet transmission fails due to the RAILTest's default packet isn't in accordance with your variable length configuration: it fires a RAIL_EVENT_TX_ABORTED event, and the TX shuts off before the first preamble chip.
2. Even if the packet is transmitted correctly, the detection performance will be terrible poor on the RX side, due to the inappropriate packet detection mechanism. It can be configured in the Advanced fields section of the radio configurator GUI.

I did not test the configuration Jim shared - I suppose it uses correct detection configuration - using the following config resulted much better detection performance (i.e., the PER decreased dramatically), than what you have in radioConfigDSSSEnabled.isc.



Let us know, if you managed to get it work, or if you have any concerns!

Best Regards,
Bence

Hi George,

The best method I can suggest is to use the GPIOs to monitor the active state on the radios.
- use TX_STATE and RX_STATE to see, whether the radio is operating in the expected state (to confirm that the remote is in RX when the controller transmits the "feedback data"),
- use RX_DATA and TX_DATA signals to compare the transmitted and the received packet (to confirm that the controller sends out the "feedback data", and the controller got the entire packet transmitted by the remote).

Also, you may check how much time does the logging take as well as that the configured auto state transition options passed along with the START_RX/START_TX commands (see the last 3, RXTIMEOUT/RXVALID/RXINVALID_STATE arguments) meet your application's requirement.

Best Regards,
Bence

Hi Yogita,

This is a duplicate of another community post with the literally same title. Please, find the answer in that thread:
https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/can_we_use_si4432to-Ulf1

Next time, please, regard our forum guidelines:
https://www.silabs.com/community/wireless/proprietary/forum.topic.html/tips_for_troubleshootingandaskingquestions-ZBhS

Best Regards,
Bence

Hi Gabriel,

The first thing I observed in your Si4464 radio configuration is that the CRC on the first field is transmitted, but not checked at the receiver side:

It causes CRC errors on every packets.

I tested the Si4464 configuration. I imported the configuration into Custom packet TX/RX projects, monitored TX_DATA_CLK and TX_DATA signals on the transmitter, and the RX_STATE, RX_DATA, RX_DATA_CLK and SYNC_WORD_DETECT signals on the receiver.

If I left the Check CRC at the end of this field checkbox (see the PKT_FIELD_1_CRC_CONFIG.CHECK_CRC bitfield's documentation) unchecked at the first field's configuration, the receiver produced CRC error, due it missed the last two bytes (the CRC2 part, since it did not expect the 2 bytes length CRC1). With this config the radio remains in RX state, but for the subsequent packet, the radio shuts off at the middle of the packet, and it lefts RX state for a short period. This sequence repeats on every two packets. Find my result in the CRC_no_check.logicdata file.

Once I enabled CRC1 on the receiver side, everything seemed to work correctly: the buzzer on the development board beeped, and there was no missing packet. I also captured it with my logic analyzer (CRC_check.logicdata).

Let us know if it solves the issue at your end!

Best Regards,
Bence

Hi Gabriel,

I have concerns about your solution you've found in your previous post, therefore I recommend to clarify first the CRC configuration.
- The attached screenshots are not so informative. You might share instead of those the project .xml files exported by WDS both for Si4464 and Si4463.

"If I check the FIFO length after the failed CRC I get a length that is much longer than my actual packet."
- It might be because improper variable length packet configuration. With the .xml files we can check it too.

Also, in the device's errata we have an item which describes a similar issue what you observed (2.14).
- Could you confirm, that there are no spurious CMD_ERR interrupts occur on the Si4464?
- Regarding the errata documentation, please confirm, that the device is not operating in the 479-639 MHz band.

Best Regards,
Bence

Hi Timothy,

I have some questions on this issue as well as some ideas to help localize the root cause.
- Did you test it on an unmodified RAILTest project? Could you confirm, that you selected BRD4164 at the project creation? Which radio configuration had you used?
- Could you repeat these tests it in a radiated setup (just to rule out the possibility that the spectrum analyzer fails due to it got damaged/has been saturated)? Do you see difference on different power levels using antennas? 
- What are the responses to the getPower and getPowerConfig CLI commands?
- What kind of test signal did you use? I suggest to use stream signal (CW/PN9; see the setTxStream command) for that purpose.

Best Regards,
Bence

Hi Bidault,

This application seems to me absolute feasible with an EFR32 device. You should set up the special IQ data source. Also, it might be possible that even the "FM demodulated" signal (i.e., the RX_DEMOD_DATA data source) is suitable for your needs.

We need more information on this application to give a more specific answer:
- What is the target part you want to use?
- Did you made any preliminary tests?
- What would be the target interface between the STM and the EFR32?
- Also, further details on the wireless protocol you want to be compatible with would be helpful.

Let me share some references which might be useful:
- For a high IQ sample rate example see this post.
- For a quick summary on this mode visit this page.
- Also, we have a tutorial article on the Special Data Modes which discusses further the available data sources.
- You can find more information on how the sample rate and the RX bandwidth depends on each other under this post. 

Regarding the EFR32's DSP capabilities I recommend to search for it or open a new question in our 32-bit MCU SDK Forum.

Best Regards,
Bence

Hi Gabriel,

The latched RSSI value resets whenever the radio starts an RX operation (see similar issues here, here, here, here and here), even if it is done automatically (see the START_RX command's NEXT_STATE arguments). Also, make sure that the RSSI latching isn't disabled and the MODEM_RSSI_CONTROL.LATCH bitfield chooses the latch time correctly (certain latching instants depend on the averaging settings as per the API documentation of this field).

Regarding the normal RSSI stuck issue: could you confirm, that the radio is in RX state in these cases (either by monitoring the RX_STATE GPIO signal or by issuing a REQUEST_DEVICE_STATE command once the radio is in "locked state")?

For a brief overview on how the RSSI works on EZRadioPRO radios visit this article.

Best Regards,
Bence