• Resolved

RTOS / CC1310:CC1310 one-to-many way of thinking

Part Number: CC1310

Tool/software: TI-RTOS

Realize 1310 one-to-many, host A and four slaves 0, 1, 2, 3

The current idea is that when host A sends to the slave, the corresponding frequency of each slave sent is different.

 For example, the frequency that A sends to 0 is A is transmitted at 903 frequency, and 0 is accepted at 903 frequency.

Similarly, the frequency that A sends to 1 is A is transmitted at 905 frequency, while 1 is accepted at 905 frequency,A is sent to 2 and A is sent to 3 is the same.

This ensures that when host A sends to four slaves, the acceptance of the four slaves will not interfere.

When four slaves want to send data to host A, they all work at 915 frequency, which ensures that the host can accept the slave's data.

This way is the current way that I think of the least interference at the same time at different frequencies, and the feasibility has been verified. can be realised.

At present, there is a question to ask, is the receiving mode of the host's RF reception, can automatically accept the scanning of 903, 905,

that is, several different frequencies when accepting (I mean a complete acceptance Can automatically according to my configuration RX acceptance (if it can be configured), let it switch in 4 different frequencies to

accept), not accept one after the manual manually switch to other frequencies and then accept.

 If it can be configured as above, the transmission and reception of each slave can be the same frequency, but the frequency between each slave is different, which is better.

If possible, please give the relevant configuration items or examples

  • Hi Liu,

    It sounds like you are trying to implement a "frequency hopping" type of functionality. If this is what you are after, it could be worth looking into some of the TI stack offerings that exist supporting this such as the TI 15.4 stack.

    An alternative solution that would be easier is to leverage the address filtering functionality of the radio core. This means that you could assign static addresses to each device: host, slave 0 .. 4 and have them communicate to each other using this address.

    You could easily test this out using SmartRF studio by sending and receiving using different addresses for each device.

    Best regards,

    M-W

  • In reply to M-W:

    I don't know how to use address filtering at this time. I have a look at how to use it. Do you have an example that you can refer to?
  • In reply to lin hack:

    Hi Lin,

    There is no example showcasing this feature alone but you can easily test it using the normal rfPacketTx/rfPacketRx examples. Using address filtering is part of the radio commands, for proprietary radio RX commands (RF_cmdPropRx if you look at the smartrf_settings.c file included with the examples) it is the fields ".pktConf.bChkAddress", ".address0" and ".address1" that you want to set. You can read about these fields in more detail in the Technical Reference Manual page 1695.

    As a short example, if you enable address filtering for the RX command and set the addresses you expect, the radio will filter packages based on the first byte in the packet payload.

    If you need more advanced address filtering, the "Advance" versions of the proprietary commands offer more flexibility. An alternative here could be to look at the Easylink API offering as this provides an easy abstraction of the radio including address filtering (this should be part of most of the Easylink examples).

    Best regards,

    M-W

  • In reply to M-W:

    Thank you very much, I already know how to deal with it.