To my understanding, the EFR32BG1 doesn't support the modulation used by Bluetooth EDR, but it seems like it can be configured for Basic Rate (GFSK, 1MBit, BT=0.5), am I correct? Does anyone have the full radio parameters (.isc file) for BR?

Also, does the PTI capture all the traffic seen on a specific channel in case address filtering is disabled?

Hi,

I am currently using EFR32FG14 series transceiver for my application. How could we test the SPI communication of the transceiver with a master device ? Is there any supporting documents or application notes from SiLABs ?

I am trying to use the “long range” OQPSK settings at 915mhz in simplicity studio, both with and without FEC, with a SLWSTK6060B eval kit. Using the PER test application, the receiver is not able to receive any packets. 

We have confirmed using a spectrum analyzer that the transmitter is transmitting, but no packets make it to the receiver. We can make the PER application work fine with other modulation and bitrate settings  

Is there anything we should be doing differently to make these work?

Will Silabs offer a SIGFOX stack for EFR? I saw some presentations from Sigfox with Silabs radios but never heard about a SIGFOX product.

Environment

The hardware is based on an Si1062 (revision G) with an Si4460 B1B as RF chip (PART_INFO and FUNC_INFO ROMID 3 and FW version 3.0.15, therefor chip revision B1B).
The goal is for the product to connect to a base station consuming as little power as possible.

Normal Operation

In normal operation the MCU starts the wake-up timer on the RF CPU and goes to sleep.
Every 2s the RF CPU is woken up by the WUT and listens for 4ms. If a packet is received, the RF CPU wakes up the MCU. In our setup no base station is present, hence there should only be short current pulses every 2s.

Issue

Sometimes the RF CPU is awake for approximately 2s instead of 4ms.
The current peaks to 9.7mA instead of 900nA. This is however influenced by a capacitor on the PCB that filters the power supply. This abnormal behaviour brings the battery voltage to collapse (from ca. 2.4V to 1.4V) and reduces the life span of the battery powered product massively. In the measuremt setup the device was powered by a DC power analzyer to test the behaviour repeatedly. The error occurs seemingly ramdom every 2 to 18 hours. If the RF chip recognizes a valid preamble it is configured to trigger an intterupt, this was not the case.

We suspect the state machine of the RF CPU not working correctly due to the low voltage (2.4V). Might there be another reason for the state machine to stay in the RX state for 2s?

We tried implementing a workaround that supervises the battery voltage and shuts down the RF chip on low voltage (ca. 1.85V). That did not work with reasonable current consumption (see https://www.silabs.com/community/wireless/proprietary/forum.topic.html/not_able_to_supervisevddonsi1062insuspendsle-eyms).

Environment

The hardware is based on an Si1062 (revision G) with an Si4460 B1B as RF chip (PART_INFO and FUNC_INFO ROMID 3 and FW version 3.0.15, therefor chip revision B1B).
The goal is to monitor the supply voltage in rx mode and to detect undervoltage (1.8V - 2V) consuming as little power as possible, hence the MCU should be in sleep mode.

Attempt 1: RF chip low_batt_thresh

We tried to use the low battery threshold of the rf chip, as the wake-up timer is active anyway. The voltage supervision was configured as follows:
- setting CHIP_INT_STATUS_EN in INT_CTL_ENABLE
- setting LOW_BATT_EN in INT_CTL_CHIP_ENABLE
- setting THRESHOLDin in GLOBAL_LOW_BATT_THRESH

When polling LOW_BATT_PEND in GET_CHIP_STATUS the undervoltage transition was detectable. To reduce power consumption the MCU should be in sleep mode and the RF chip should supervise the voltage on every WUT tick and trigger a intterupt (nIRQ) if below threshold.

Although the WUT was running (veryfied by current measurement) no interrupt was ever triggered.

Are there any other steps needed in order to use the battery supervision with interrupts on the RF chip?

Attempt 2: MCU VDD_MON

In another attempt we tried to use the MCU VDDMON. The datasheets states that VDD not monitored in sleep mode. A quick test showed that the VDDMON is running in run and idle mode and not running in suspend and sleep mode.
Is that correct?

I am able to receive the packet from the board, on parsing the packet, I believe two modes exist, packet and FIFO mode, but I don't find packet mode reliant and efficient .

I went through the example for simple_trx using Fifo mode, but couldn't understand if I will be parsing the packet properly.

For example:

I have a preamble of 32 bits, sync word of 32 bits , no header, and I have a payload of 24 bytes, which I have to separate into three databyte and carry out the functions based on that. I will be ignoring the CRC too.

Can anyone explain me on how to proceed here

Dear all, 

I have a question regarding the bandwidth allocation of my application. I'm using the EFR32MG12P433F1025GL125 demo board and I've selected through the .isc, in the proprietary configurator, this PHY configuration: 868 2GFSK 38.4Kbps 20.  This automatic configuration should have 20 kHZ of deviation which means about 40 kHZ of bandwith. To check my actual main lobe on the spectrum analyzer I'm sending a continuous stream carrier with this function: RAIL_StartTxStream(railHandle,0,RAIL_STREAM_CARRIER_WAVE); However I'm facing a bandwith occupancy of about 200kHz. Is that normal? I've tried other configurations as well (even a couple of custom ones) but nothing changed. How can I fix that? I need to send packets on a narrow band spectrum of 10 to 50 kHZ of bandwith at most.

Thank you!

Hi,

I'm trying to configure the smaRTClock with LFO as described by the datasheet. But i cannot find any info in the datasheet about what register the LFOEN bit is located.

I'm using the Si1082 chip.

We are testing the communication performance with very long frames (larger than 1024 bytes). The board we are using is attached as the following:

Parts:
  EFR32FG14P233F256GM48

Boards:
  Wireless Starter Kit Mainboard (BRD4001A Rev A01)
  EFR32FG14 2400/868 MHz 13 dBm Dual Band Radio Board (SLWRB4257B)

We adopt pure FSK (de)modulation in the TX/RX. The frequency compensation is disabled in the AFC. And we disable all the symbol coding, channel coding and CRC functionality to send and receive raw bits. 

However, the FSK (de)modulation has severe "drift", especially in the long frame. We give an example of the packet trace of 2048 bytes. We want to send a repeated sequence like the following:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

Each sequence is 64 bytes consists of 32 bytes 0x00 and 32 bytes 0xFF. The basic sequence will repeat for  32 times to form the frame of 2048 bytes.

However, the received frame is like this:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
FF FF 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
 

It can be observed some 0xFF just after 0x00 becomes 0x00 gradually and some 0x00 just after 0xFF becomes 0xFF gradually. Finally, the basic sequence will begin with several 0xFF and some 0xFF in the middle of the sequence becomes 0x00.

I don't know the reason for this kind of phenomenon. Maybe it's caused by center frequency offset or hardware imperfection. However, we need an accurate and stable boundary to distinguish 0 and 1 in FSK (de)modulation. In the 1024 bytes frame, this phenomenon still exists. In the 512 bytes frame, this phenomenon is eased. In our experiment, we need at leash 2048 bytes. Also, I don't think the extra channel or symbol coding will help a lot, because this error derives fundamentally from the hardware (de)modulator.

It will very nice of you if you can provide some explanation or a feasible solution.   Very grateful!

Hi Silabs,

will the EFR32xG21 support Proprietary and  will Silabs  release a  Proprietary SDK ?

we need a SOC support 2.4 GHz Proprietary :

  Flash  >=512K,

  RAM  >= 128k

  MCU Clock Speed >=48MHz (>60MHz will better)

  Excellent receiver sensitivity(GFSK)  –105 dBm@125-kbps 

  Tx Power : range from -10dbm to 20dbm

Suitable for systems targeting compliance with worldwide radio frequency regulations @20dbm :

      – EN 300 328, (Europe)

      – EN 300 440 Category 2

      – FCC CFR47 Part 15

      – ARIB STD-T66 (Japan))

– AES 128- and 256-bit Crypto Accelerator

– ECC and RSA Public Key Hardware Accelerator

– SHA2 Accelerator (Full suite up to SHA-512)

– True Random Number Generator 

Thanks,

Nan

Hi,

SI4455 is set like that on emitter and receiver (two SI4455):

Changing channel on both devices  works fine, and If I set emitter on channel 1 and receiver on anything else except 4, it receives nothing.

Indeed, if receiver is set on channel 4, it keeps receiving some frames from time to time. I put the emitter far away from receiver, but no change.

Have you any idea ?

Best regards.

Hello,

using the GET_REV Command, the first two bytes of the Product ID i receive are always 0 0 ( with multiple 4012s), the next two bytes got different values. Can this be possible or might there be an error?

Best regards,

Philipp

Hello,

I have a custom design that I am having a software issue in. Occasionally when I receive an INVALID_SYNC interrupt from the SI chip, the sequence of commands I use for recovery causes the CTS line on the SI chip to lock high (I'm reading it via GPIO). In my code, if it is high for > 5 seconds I assume the SI chip is locked up and reset it. However, I'd like to prevent it from locking up in the first place.

Here is my code structure for an invalid sync:

/* State change to */
SiChangeState(SI446X_CMD_CHANGE_STATE_ARG_NEXT_STATE1_NEW_STATE_ENUM_SLEEP);

/* Reset FIFO */
if(!SiResetFIFO(SI446X_CMD_FIFO_INFO_ARG_FIFO_RX_BIT)){
    SendDebug("At InvalidSync\r\n");
}
            
/* Restart RX Process */
SiStartRX();

Here is my SiChangeState() Code:

bool SiChangeState(SiStates State)
{
    Data[0]=SI446X_CMD_ID_CHANGE_STATE;                           //Command to Change State
    Data[1]=State;                                                //Desired state
    if(!WriteRadioSPI(Data, SI446X_CMD_ARG_COUNT_CHANGE_STATE, true)){
        SendDebug("SiChangeStateFailed\r\n");
        return false;
    }
    return true;    
}

Here is my SiFIFOReset() Code:

bool SiResetFIFO(uint8_t FIFO)
{
    Data[0]=SI446X_CMD_ID_FIFO_INFO;  //Command to reset FIFO buffers
    Data[1]=FIFO;                     //Reset given FIFO
    if(!WriteRadioSPI(Data,2, true)){
        SendDebug("SiFIFOResetFailed\r\n");
        return false;
    }
    return true;                      //Return success
}

Both of them use WriteRadioSPI() to communicate with the SI chip:

bool WriteRadioSPI(uint8_t * data, uint16_t len, bool RelCS)
{
    uint16_t i;
    uint8_t * pdata;
    uint8_t temp;

    //Check Radio CTS Line
    if(!check_si_cts_line()) {
        SendDebug("CTS Failed WRS at CMD: ");
        SendDebugHex(data, len);
        return false;
    } 

    pdata=data;
    SetRadioCS();

    SPI2STATbits.SPIROV=0;                  //Clear overflow errors
    IFS1bits.SPI2RXIF=0;                    //Clear the RX interrupt
    while (SPI2STATbits.SPIRBF)
    {
        temp=SPI2BUF;                       //Purge RX Buffer
    }
    IFS1bits.SPI2RXIF=0;                    //Clear the RX interrupt

    for (i=0;i<len;i++)
    {
        temp=*pdata++;
        SPI2BUF=temp;   //Send the data
        while (!SPI2STATbits.SPITBE){};     //Wait for the transmit buffer to empty
        while (!IFS1bits.SPI2RXIF){};       //Wait for the receive buffer to fill
        temp=SPI2BUF;                       //Read and discard
    }
    while (SPI2STATbits.SPIBUSY){};         //What for the SPI to shift out all the data

    if (RelCS)
    {
        ClearRadioCS();
    }
    return true;
}

During that FIFO reset for an INVALIDSYNC word, it occasionally locks up at the check_si_cts_line() inside WriteRadioSPI(). However, that function is utilized many other places, as is WriteRadioSPI(). This occurs at different frequencies, and not every time an invalid sync occurs... Does anyone have any idea what could cause such behavior?

EDIT:

Also here is check_si_cts_line():

bool check_si_cts_line()
{
    uint64_t cts_timeout = SysTime + 5000; //5 Second Timeout
    bool printed = false;
    while(!RadioCTS()) {
        ClearWDT();
        if(SysTime > cts_timeout && !printed) {
            printed = true;
            si_restart_si446x();
            return false;
        }
    };
    return true;
}