• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 16 subscribers
  • Views 248 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2340R5: Send and receive with frequency hopping and proprietary protocol

Andreas- Kleimaier
Prodigy 30 points
Part Number: CC2340R5

I use the proprietary rcl_settings_msk_250_kbps

I want to transmit 20 bytes from the master and after that I want to receive 20 byte as an answer from the slave

This is working fine until I switch the frequencies

If I do a permanent switching of the the frequency through this channel list

e.g.

transmit on channel 0 wait 2ms (do a reception in between) then jump to the next channel and so on.... 

volatile const uint32_t ChannelList[]= { 2404000000, 2408000000,
2412000000, 2416000000,
2420000000, 2424000000,
2428000000, 2432000000};

(if I change all frequencies in this table to the same like 2424000000 everything is working fine)

I receive everything on the slave side but the answer from the slave is only sporadic received at the master side.

For me it seems like the receiver needs more time to be stable after I changed the frequencies.

What is the minimum timing? and how can I keep this timing?

 Is there an example for doing some kind of this ping pong with frequency hopping?

  • 0
    TI__Mastermind 33600 points

    Hi,

    I'd recommend increasing 2msec to 5msec.

    The timings here may be used to derive the minimum wait time between TX to TX in your setup.

    1. t_sw = 550usec (minimum time from end of one RF cmd to start of next RF cmd, from my measurements)
    2. t_tx = 960usec (minimum time it takes for a TX packet to complete: (4 byte preamble + 4 byte syncword + 1 byte length field + 20 byte payload + 1 byte CRC) * 8 bits/byte / 250kbps == 0.00096sec)
    3. t_rx = 960usec (t_tx + window, with window=0); (window is how early the RX needs to start before the TX happens in order to receive it, for minimum estimate assume window==0)

    Typical flow on your master device is TX --> RX --> TX and the payloads are 20 bytes.
    So total time between start of TX to start of next TX is: 2*t_sw + t_tx + t_rx == 3020usec == 3.02msec.

    In practice, adding some time for 3.window makes sense, try window=t_sw, getting a total of 3.57msec.

    You may also need to account for startup times of TX and RX, 500usec is a reasonable estimate for each: 3.57msec + 2*500usec == 4.57msec.

    These timing can be used for reference, adjust as needed for your application.

    Thanks,
    Toby