1. Clarify to yourself what the specific issue is.
2. Apply basic troubleshooting:
3. Consult the datasheets and reference manuals. Sources include:
4. Search to see if someone has asked the same question already.
5. If you use custom hardware, try to reproduce the issue on a Silicon Labs kit
6. If you have a big firmware project, try to reproduce the issue on one of the Silicon Labs examples with minimal modification
7. If you have a radio configuration problem, try to reproduce it with RAILTest or WDS
8. Include the relevant parts of your development setup in the problem description. Examples include:
9. Include steps to reproduce the problem or specific conditions the problem occurs in.
10. Be patient and avoid making duplicates of your question.
For general community usage please refer to the Silicon Labs Community Guidelines.
I am attempting to limit power consumption on my SI radio since it will be running on battery. My idea was to use LDC mode and configure it so that the LDC/WUT periods are such that I will never miss a preamble. Current configuration:
Preamble of 40 bits, 57600bps, Preamble RX Thresh 20 bits.
Since my preamble is 694us long, I cannot sleep for more than ~300 us at a time.
I was a little confused on the WUT/LDC configuration since the datasheet and API doc have the same calculations, but the API units are seconds, while the datasheet has ms. Which one is correct?
I assumed ms, and calculated a WUT_R of 4, WUT_M of 153, giving a WUT of around 0.3ms. I did the same with the LDC so that LDC+WUT = around .6ms. This should allow me to never miss a packet.
However the response time from SLEEP to RX is 440us, so is this even possible? Or will I need to lengthen my preamble if I want to do this scheme?
I'm working on a multiprotocol application (ble+proprietary) on the EFR32MG12P132F1024GM48.
With small packets everithing is fine, but when I try to transmit packets larger than 97 bytes the SoC goes in Default_Handler.
I tried this, however I cannot find the description of the NVIC registers anywhere, therefore I cannot go deeper.
So, here the questions are two:
- why do the radio blocks when I try try to send big packets?
- where is the documentation about NVIC registers?
We are currently using the Si4362-C in direct mode.
This is because we have a protocol that is quite slow with long transmissions. It allows us to turn off the receiver for parts of the transmission we don't care about. We then re-enable the receiver at the right time to resume sampling RX_DATA (with a timer running on the application MCU).
We are wondering if it would be possible to use the RX FIFO for this case, as it would simplify the interface to the application MCU.
We know that the FIFO can only be used with the Packet Handler, so this is not the intended use case.
However, we hope that we can use the following settings to achieve this:
Set PREAMBLE_CONFIG_STD_1:RX_THRESH = 0, which is explicitly allowed to skip preamble checking.
Set SYNC_CONFIG:LENGTH = LEN_1_BYTES and SYNC_CONFIG2:LENGTH_SUB = SUB_6 to have a 2 bit sync word.
Set SYNC_CONFIG:RX_ERRORS >= 2 to have the packet handler accept any 2 bits as a valid sync word.
Set PKT_LEN:INFINITE_LEN = INFINITE to keep the packet handler filling the FIFO.
Is SYNC_CONFIG2:LENGTH_SUB supported on Si4362-C? The setting is mentioned in the description for SYNC_CONFIG:LENGTH, but is not documented, in contrast to the Si446x variants.
Is there anything that would prevent us from doing this as described above?
Is there another way to get the chip to sample to the RX FIFO upon START_RX with no condition?
Hello,I did some sensitivity tests with the EFR32FG14 and its not looking too good (roughly -108 dB without any PER). This is with 4FSK, 868 Mhz center, low bps (1.2 kbps, TX power set to default for the trx app) and attenuating the signal slowly while keeping the receiver inside the RF shieldbox. I would like to know what would be the reason for the poor sensitivity and if there are other gecko product that has better sensitivity (sub-gig, low bps, 4FSK/OQPSK).
I am modifying a working program to be used in a new system. The new system transfers data to the Si1060 via a 19200 Baud rate UART compared to the previous system being 115200 Baud rate. To achieve this baud rate I had Timer0 prescale the system clock by 12. However implementing this change seems to create a fault as I am no longer receiving a packet on the connected receiver. My initial guess at the problem is that the data from the UART is being put into the transmit FIFO to slow and the packet is being completed with incomplete data. Any information or background you might have on this issue would be a great help, Thanks.
We are currently using the rail library to create a radio configuration on 915 MHz. the radio configuration contains 25 channels. In the current state, the radio misses 50% of the messages. I think the preamble detection isn’t right.
In my understanding, the settings; “number of symbols in timing window” and “number of timing windows to detect”, are there to set the preamble detection length. Correct me if I am wrong. Now I am searching for a way to set the invalid preamble length/period, but I can’t find where I can set this.
Also, I have difficulties to calculate the right settings for:
I have read the AN971, but I think it’s a little hazy in some sections and I can’t get a clear sense of the relation between the different settings.
Can someone provide me with more information about the rail configuration and how to set the preamble detection right
SDK: Flex SDK 220.127.116.11
Radio library: Rail library
Thank you for your help.
I am working with an EFR32BG12P433F1024GM48 to use the antenna diversity mode and i have a question about the antenna configuration. I have an adaptation network connected to 2G4RF_IOP and 2G4RF_ION pins. On the output there is a switch which is controlled by the PB13 input. If the value of the input is '0' the antenna 0 would be selected and if the value is '1' the antenna 1 would be selected. Knowing this i don't know what values i have to give to ant0Loc, ant0Port, ant0Pin, ant1Loc...
Thank you for helping,
i get the config file from WDS, the chip can not tx ook carrier in the direct synchronous/asynchronous mode, but fsk and cw mode are ok.
i want to use the si4463 in tx direct mode, ook modulation, synchronous or asynchronous mode. how to do?
I'm trying to program an Si4010 and I'm having lots of problems. I tried importing one of the example projects into Simplicity Studio (keyfob_demo_2) but when I try to build it, I get the following error:
*** FATAL ERROR L224: DUPLICATE KEYWORD OR CONFLICTING CONTROL POS: 292 -0X0DFF) XD (0X0E00-0X107F) STACK (?STACK (0X90)) RAMSIZE (256) CODE (# make: *** [tone_demo.omf] Error 1
I've seen a few places online say that you need the old 8 bit IDE to build these projects, so I tried downloading it -- but the link is dead!
So now I'm back to trying to get the project to build in simplicity studio. What part number do I use?? For some reason by default it is set to C8051F300-E-GM and the 8051 SDK. Is this correct?
I possibly have a stupid question regarding Direct Mode (predefined setup in WDS3) using the SILABS EVBs and SI4468 modules.
I have two of these units and I try to investigate Direct Mode.
Maybe I misunderstood something, but I can not find any hint about what Direct RX and Direct TX does on the EVBs (except in AN632). I think I understand the meaning of Direct Mode, but I need some more information to be able to use Direct Mode with the SDK.
I would like to connect a pattern generator for some investigations.
In AN632 it stated: The modulation source is one of the selected GPIO, the
user needs to feed the data through this pin.
But I can not recognize a pin selection for TX data input.
With the default setup I currently just get a stable RX Data Clock if the TX is active and a free running RX Data Clock if TX is off.
Can anybody help please ?
Thanks a lot.
We are using Silicon labs SI4356 FSK receiver in our product. We are facing following issues in the receiver,
Please provide your support to the above issues. I have attached the receiver circuit we are using.