Hi Greg,

There is no such tool available, but we see the demand from customers, so it may change in the future.

Tamás 

Hi Tony,

In general the more your protocol is adaptive, the more energy you can save. I'll try to share some knowledge or idea that might help to improve your protocol, but the method will be defined by your application, thus I recommend first to clear your needs.

- First of all you should clear what is required (e.g. numbers like maximum latency, maximum nodes, number of channels), then take the averages (how will it work in usually, what's the average number of nodes, how much time will be one particular channel or one particular node occupied), and if it is economically worth, you could spend time with thinking and implementing methods to handle low occupancy cases optimized.
- You should be facing with the following questions (and I suppose you already did it): what's the purpose of using synchronous hopping? Is it for expanding bandwidth, for security reason, or for protection from interference; how is the network formed: are there servers and clients; which device can initiate communication, when and how? 
- If the protocol is connection based you could use one fix channel for advertising, and setting connection parameters. Decreasing packet loss with long preambles and scanning through multiple channels to form a connection is not a good energy saving method, furthermore it increases channel occupancy.
- I think BLE serves as a great example of implementing synchronous hopping network reducing the energy consumption along TDMA (enabling periodical sleep). Maybe you could get useful ideas from the Bluetooth Forum.

We cannot help to define your requirements, and without the requirements we are not able to propose solutions.
We can provide more detailed answers covering technical information for more concrete descriptions.

Best Regards,
Bence

Hi kumar rajan,

I am so sorry for the late reply.  For transmit, there is no obvious difference as the explanation describes that the distinction has become more cosmetic than functional, as the RAIL_WriteTxFifo() and RAIL_SetTxFifoThreshold() APIs and related RAIL_EVENT_TX_FIFO_ALMOST_EMPTY event can be used in either mode.  For receive, if the size of the packet is more than rx fifo, we should use fifo mode. Another situation: if application wants to decode parts of packet (such as head of the packet) while receiving, we should use fifo mode.  On packet mode, if errors happens, rollback will occur automatically. In case of that, the application won't consider about the received data, but RAIL can inform the related events to application. If it is needed, the application can handle these events.  If a whole packet is received, RAIL_EVENT_RX_PACKET_RECEIVED will happen, but  RAIL_EVENT_RX_FIFO_ALMOST_FULL cannot affect in packet mode.

Thanks,

Bo

Hi,

See this article about sync word selection:

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2012/07/09/ezradiopro_and_sync-JoD6

Regards,

Tamás

Hi,

Did you check the documentation at https://docs.silabs.com/rail/latest/group-auto-ack?

BR,

/sza2

Please move to this link for check.

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/06/01/rail_tutorial_5_tim-WvQg

See "State Timing" section.

Hi,

RAIL implements an 512 byte long (by default) RX FIFO accessible with packet handles. The most usual method to download a packet is getting the payload in a radio interrupt context (in the event handler), but you could download it later using the RAIL_HoldRxPacket() API. It will prevent overwriting the RX FIFO's region where the packet has been stored, so it's the application's responsibility to release the packet with the RAIL_ReleaseRxPacket() API after processing it (e.g. storing into a local buffer).

For further information see RAIL API Docs and the RAIL Tutorial 4.

Best Regards,
Bence

Hi Aaron,

Sorry for saying that, but the project has a couple of errors and misunderstanding:
- All of the variables used in interrupt context should be declared as volatile (I mean here the counters, but the RX buffer may be volatile as well; the latter has no effect, but it's still a good habit to do that);
- You set in the ISC file 253 byte length payload + 1 byte header (I don't see why it is required, typically the header is used as a packet length indicator when variable length frames are configured), and 252 as PACKET_LENGTH, what is the length of the TX buffer;

Note that you can’t use any arbitrary size, EFR32 creates a FIFO ring buffer on this memory area, and it can only handle buffer sizes of a power of 2 between 64 and 4096 (see RAIL Tutorial 2)

- these line are confused:

RAIL_SetRxFifoThreshold(railHandle, RX_BUFFER_SIZE - RX_BUFFER_SIZE / 10);
RAIL_SetTxFifoThreshold(railHandle, TX_BUFFER_SIZE - TX_BUFFER_SIZE / 10);

Why do you set the thresholds to zero or what for do you define those? Those API's are relevant when long packets are transmitted and received (see RAIL: Simple TRX with FIFO example);
- printing from interrupt context is a very bad habit, do not do that, the interrupt handlers should be designed to finish as soon as possible! You could set (volatile) flags, which are monitored in the main loop;
- Instead of getting the payload with RAIL_ReadRxFifo() you have to use RAIL_CopyRxPacket() (see the referred tutorial article above);
- The payload is neither initialized nor the whitening engine is enabled: this means that the receiver may loss the synchronization with the transmitter: you send a 0x00 payload, what is like transmitting only a carrier for long time;
- You called RAIL_WriteTxFifo() form the startTx() and from the radio event handler, I'm not sure is this what you want to do: the packet (252 byte length) always fits to the reserved 256 byte length TX FIFO. You have not to use RAIL_EVENT_TX_FIFO_ALMOST_EMPTY at all;
- Calling RAIL_StartTx() twice from startTx() is also wrong. Remove the first one!
- For transmitting 10 packets with the least amount of time between them you should monitor TX state (RAIL_GetRadioState()) or rather set a flag in RAIL_EVENT_TX_PACKET_SENT's handler as Simple TRX example does. I'm curious how many time the startTx() has been called pushing the button once. :) 

Best Regards,
Bence

Hi,

I couldn't find the exact changelog, but Flex 2.6.0 was the first SDK which properly supported antenna diversity in RAIL, so errors like this could happen.

Andras