• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 573 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2642R: Minimal Jitter Broadcasting for Time Sync

Florin Tobler
Prodigy 90 points
Part Number: CC2642R
Hello,

In my application I send data as a broadcasting beacon from device to device. I am interested in getting a minimum jitter latency for a time synchronization.

Receiving and sending devices are both CC2642. One is set for advertising, the other for scanning. There could be multiple scanning devices, that's why I can't use a connection.

On the advertising device I set
Parameter
    .eventProps = GAP_ADV_PROP_LEGACY | GAP_ADV_PROP_SCANNABLE,
    .primIntMin = 32, //32 * 0.625ms = 20ms
    .primIntMax = 32, //32 * 0.625ms = 20ms
When I send a packet, data is set and then I start with:
    GapAdv_enable(handle, GAP_ADV_ENABLE_OPTIONS_USE_MAX, 0)
Once I get the Event GAP_EVT_ADV_START I stop it again.
I don't know if this is the correct way of sending a single Advertising packet. I cannot set the interval to 0 so there is always some jitter. When I measure passed time from sending to receiveing the GAP_EVT_ADV_START event I get 25-30ms.



On the scanning device I set
    SCAN_TYPE_PASSIVE
    interval = 16, //16 * 0.625ms = 10ms
    window = interval
    maxNumReport = 0
With interval=16 I get a stddev of 5ms jitter, which would be fine for my application. Problem is the packet loss is with 42% way too high.
With interval=128 I get a stddev of 15ms jitter, which is too much. Good thing is the packet loss goes down to 16% but is high. It's unclear for me why the times increase, there is something more going on than just giving more time, it also effects the report events.
With interval=800 I get times from 230-500ms, not worth making statistics.



My question, is this the right way of doing this? Can I improve my results by doing something different? Or is there a way to predict when a packet is being sent? 



Best Regards
Florin Tobler





  • 0
    TI__Mastermind 42070 points

    Hi Florin,

    I have assigned an expert to look into this. In the meantime, can you provide the SDK version you are using? Can you share which sample project you used as your base for your application? Are you using simple_central or multirole?

    Best Regards,

    Jan

  • 0
    TI__Guru** 101450 points

    Hi Florin, 

    Thank you for reaching out.

    I would recommend to enable the RF debug signals (see here), that way you'll have a better idea on the RF signals sent over the air.

    I am not totally sure using legacy advertising is the best option.
    - First, the legacy advertising are sent over three channels, so you cannot know if all the scanners receive the data at the same time. Using only one advertising channel would not help, as the scanner is still supposed to use the 3 channels (i.e. you'll have a 1/3 probability to have the scanner listening on the right channel).
    - Second, legacy advertisements are sent on pretty busy channels, so you may end up with packet losses.
    I would then, rather recommend to explore extended advertising. You could even explore an option implementing periodic advertising.

    One more idea, do you think it could help to make the measurement on a few packets (instead of one)? The idea would be to scan a few consecutive advertising and average the results. That way, the delay due to the handling of the event may be a bit more predictable.

    I hope this will help,

    Keep us updated.

    Best regards,

  • 0
    Prodigy 90 points

    Thanks for the answers.

    I am using SKD version 5.20

    My project has come a long way. It started from project zero, but not much is left original from there.
    I am using multirole.

    I will try with extended advertising to see if that changes something.

    Is there a way to get information faster than through the GAP_EVT_ADV_REPORT? I still don't understand why my timings go up with a larger scan interval.

    Best Regards
    Florin

  • +1 in reply to Florin Tobler
    TI__Guru** 101450 points

    Hi,

    Florin Tobler said:
    Is there a way to get information faster than through the GAP_EVT_ADV_REPORT?

    I am afraid, not.

    Florin Tobler said:
    I still don't understand why my timings go up with a larger scan interval.

    Looks a bit unexpected to me - especially for the larger intervals. I would recommend to turn on the RF debug signals to check when the radio is listening, and see the actual delay between the emission of the advertisement and its reception. 
    I would also recommend to see the air time usage(*) and see if at one point the issue could come from this.

    (*) The radio can either receive, either transmit, but not both at the same time. As you are using a multi-role example, I would recommend to verify if the radio has time to schedule all the RF operations you need. Here again, I would encourage you to enable the radio debug signals and use a logic analyzer.

    Best regards,

  • 0
    Prodigy 90 points

    Thank you, this resolved my issue.

    Problem was I had multirole going on and activated. If I set one device to only receive and the other to only transmit the results get better.

    Latency is 4.7ms and there are 3 discrete times where it gets received, each 800us apart.

    Scan Interval is at 800*0.625ms, also this issue is completely resolved.

    Best Regards
    Florin

  • 0 in reply to Florin Tobler
    TI__Guru** 101450 points

    Hi Florin,

    Thank you for telling us. This is awesome, well done!

    Best regards,

  • 0
    Prodigy 90 points
    Addendum:
    Forgot to add, above Oscilloscope Screenshot was with Legacy Advertising.

    The Same thing with Extended Advertising does not seem to work the same way:
    I get a latency of 9.4ms with what seems to be only single-digit microsecond jitter. Big problem is it is limited again by the Scan window. Which means for my case each 500ms I get only one report event, all other advertisements in between are lost. I can use a smaller scan window but it must be smaller than my advertising interval. Since I am unsure how this behaves in the field it imposes a risk.

    Another idea is to get which advertising channel the packet was received on and then calculate the latency for said channel. Is this possible? According to older form threads this information was unobtainable.

    I have already met the timing requirements for my application. I am not sure how long I want to continue searching.
    Best Regards,
    Florin