Hi John,

I hope it is fixed now, let me know if not.

Best Regards,
Bence

Hi John,

I have acquired some screenshot to highlight the "latency" what you measured.

I've used Long Packet TX example with 250 ksps bitrate and 300 KHz deviation, 8 byte preamble, 2 byte syncword and 255 byte payload with no CRC, enabled whitening (for balanced spectrum occupancy), and setting the TX_STATE to GPIO 0, and TX_DATA to GPIO 1. I let the other settings on their default state.

On the following picture we'll see, that the preamble is not 4(G)FSK but 2FSK modulated. This means that we should taking care when we calculating it's transmission time: it is 8*8 symbol transmitted on the 250 ksps bitrate, therefore we can take it account as 8*8*2 [bit] / 500 [kbit/s]. 


So the whole packet transmission takes (8*2+2+255)*8/500.000 s => 4.368 ms.

First let see the logic captures:

From pushing the button to start packet transmission does take ~13 ms (it has high variance). It's OK, it depends on the application code.
The device is in TX_STATE for 4.56 ms. It is 192 us longer as expected. We see 3 nIRQ high-to-low transition: two on TX_FIFO_ALMOST_EMPTY and one on the PACKET_SENT events, and since the latter happened before the TX_STATE went down, we got explanation for 60 out of 192 us.
The datasheet states that the synthesizer has 50 us Settling time. This can highlighted zooming on the start of the packet:
From TX_STATE to TX_DATA's first transition we measure 87 us. Now we are missing only 33 us, what can be found at the end of the packet, the last bit of TX_DATA to pull down event on nIRQ pin:Measuring from the first to the last bit is exactly what we expect: 4.368 ms:
Let see now the transmitted waveform (Frequency vs Time): the trigger event is the rising edge of TX_STATE GPIO pin.
The transmission starts after 100 us, and it lasts for 4.377 ms.

Triggering on the falling edge of the TX_STATE pin and adding some offset, we could measure the delay between the transmission end, and the GPIO signal, it is about 87 us. (100 + 87 is what we measured with the logic analyzer measuring TX_STATE).

Pushing 255 byte to the TX FIFO takes 255*8/SPI_dr + T_CTS_OH, where SPI_dr stands for SPI datarate, and T_CTS_OH the overhead comes from reading the CTS, but the most part of the writing sequence can be handled during ongoing packet transmission, therefore it may not generate additional latency. 

Summing that all, you cannot reach eventually the 500 kbps data traffic with the radio in FIFO mode, due to the internal blocks and the packet's overhead (preamble, syncword, CRC). You should measure transmission time to TX_START rising edge to PACKET_SENT nIRQ falling edge (it'll be still below 500 kbps in your case, but more than 440 kbps), beyond that the application's responsibility to add minimal latency with careful designed FIFO loading method and interrupt handling.

Best Regards,
Bence

Hi John,

I have acquired some screenshot to highlight the "latency" what you measured.

I've used Long Packet TX example with 250 ksps bitrate and 300 KHz deviation, 8 byte preamble, 2 byte syncword and 255 byte payload with no CRC, enabled whitening (for balanced spectrum occupancy), and setting the TX_STATE to GPIO 0, and TX_DATA to GPIO 1. I let the other settings on their default state.

On the following picture we'll see, that the preamble is not 4(G)FSK but 2FSK modulated. This means that we should taking care when we calculating it's transmission time: it is 8*8 symbol transmitted on the 250 ksps bitrate, therefore we can take it account as 8*8*2 [bit] / 500 [kbit/s]. 


So the whole packet transmission takes (8*2+2+255)*8/500.000 s => 4.368 ms.

First let see the logic captures:

From pushing the button to start packet transmission does take ~13 ms (it has high variance). It's OK, it depends on the application code.
The device is in TX_STATE for 4.56 ms. It is 192 us longer as expected. We see 3 nIRQ high-to-low transition: two on TX_FIFO_ALMOST_EMPTY and one on the PACKET_SENT events, and since the latter happened before the TX_STATE went down, we got explanation for 60 out of 192 us.
The datasheet states that the synthesizer has 50 us Settling time. This can highlighted zooming on the start of the packet:
From TX_STATE to TX_DATA's first transition we measure 87 us. Now we are missing only 33 us, what can be found at the end of the packet, the last bit of TX_DATA to pull down event on nIRQ pin:Measuring from the first to the last bit is exactly what we expect: 4.368 ms:
Let see now the transmitted waveform (Frequency vs Time): the trigger event is the rising edge of TX_STATE GPIO pin.
The transmission starts after 100 us, and it lasts for 4.377 ms.

Triggering on the falling edge of the TX_STATE pin and adding some offset, we could measure the delay between the transmission end, and the GPIO signal, it is about 87 us. (100 + 87 is what we measured with the logic analyzer measuring TX_STATE).

Pushing 255 byte to the TX FIFO takes 255*8/SPI_dr + T_CTS_OH, where SPI_dr stands for SPI datarate, and T_CTS_OH the overhead comes from reading the CTS, but the most part of the writing sequence can be handled during ongoing packet transmission, therefore it may not generate additional latency. 

Summing that all, you cannot reach eventually the 500 kbps data traffic with the radio in FIFO mode, due to the internal blocks and the packet's overhead (preamble, syncword, CRC). You should measure transmission time to TX_START rising edge to PACKET_SENT nIRQ falling edge (it'll be still below 500 kbps in your case, but more than 440 kbps), beyond that the application's responsibility to add minimal latency with careful designed FIFO loading method and interrupt handling.

Best Regards,
Bence

Hi John,

It may be hard to find, but if you compare the 2nd logic capture (A1 - A2 markers' distance is 4.56 ms) with the 5th (or you can calculate from comparing the presumption against the 2nd logic screenshot), you shall see where the 192 us come from.

In general the more the packet length is, the more the bitrate what you can achieve, due the useful data (payload) proportion to the packet length grows, and radio state transition overhead decreases, therefore theoretically you may get close infinitely to 500 kbps with this settings, with infinite long packets (what is similar to direct mode in practice, though it not supported with 4FSK modulation). In the transmitting period, during payload transmission you will have 500 kbps datarate, but transmitting the preamble, syncword, CRC, etc., state transition and waiting in idle (say other than TX) state will require time as well decreasing overall datarate. 

The actual datarate is up to the application: how do you handle the received packets (Are the receiver is ready to receive the next packet?), how do you feed the FIFO (Is the next payload ready to send before the former had been transmitted?), so I can't define exactly how much datarate would you have.

Best Regards,
Bence

Hi Zoey,

Which example application (that was what I meant by project, sorry) are you using?
Did you get a RAIL_EVENT_RX_PACKET_RECEIVED event?

Best Regards,
Bence

Hi Bowen,

The default setting on each device is 1 mapped to the +Fdev deviation level both for TX and RX mode.

You can invert both TX and RX bits individually on Si4463 (MODEM_MAP_CONTROL property's ENINV_* bitfields) and inseparably on Si4432 (Reg 71h, eninv bit), furthermore there is always an option to invert bits by software (though it's less recommended).

Best Regards,
Bence

Hi Alex,

Did you enable PA Conversion plugin?

You also have to keep in mind that the actual output power depends on your board and antenna design. The recommended way to solve this problem is to create a PA conversion curve documented in AN1127, and enable the PA conversions plugin with the generated header:

Simplicity Studio ships with conversion curve headers for Silicon Labs boards - if you create a project for a Silicon Labs board, simply enable the PA Conversions plugin to include the correct header for your board.

From RAIL Tutorial: Multi-PHY usecases and examples

See RAIL Documentation (Power Amplifier Initialization section) for more information.

Best Regards,
Bence

Hi Nic,

Please read the RAIL API documentation:
- RAIL_TX_OPTION_SYNC_WORD_ID for TX option,
- RAIL_RX_OPTION_ENABLE_DUALSYNC for RX option,
- RAIL_PacketDetails_t structure's syncWordId field for getting the received packet's syncword.

Note that the second syncword unfortunately does not generated into the log file, but that is in the radio configuration.

Best Regards,
Bence
 

Hi Zoey,

Please give a more detailed description on your issue:
1. What kind of project do you talking about?
2. Do you mean by "extracting the value" that you want to read RX FIFO?

For understanding packet transmission and reception you should read RAIL Tutorial: Combining Transmit and Receive and API documentation (maybe the RAIL_PeekRxPacket() API is what you are looking for).

Best Regards,
Bence

Best Regards,
Bence

Hi Nic,

Please read your generator's datasheet or user manual to get to know how could you generate preamble-like signal (I suppose sine waveform is not that what you want) with gaussian filter. You could compare the generator's signal to the EFR's signal with signal analyzer as well.

Best Regards,
Bence