• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 409 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.

CC1352P7: A question regarding a possible mistake "CC13xx Long Range Modes" document, and related questions.

Omid Kandelusy
Prodigy 160 points
Part Number: CC1352P7
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Reading the "CC13xx Long Range Modes" written by Sverre Helen and published on December 2018 [link], I had to stop at this part:


"There are several takeaways from Table 2. First of all, higher DSSS rates offer higher sensitivity gain. This, of course, comes at the expense of longer packet durations."


This does not make sense.

The whole concept behind the direct sequence spread spectrum is to increase the chip rate while the pulse duration is the same.
This is a direct application of Fourier transform and the core concept of time-domain-frequency domain relation in which we know smaller pulse width in time domain results in a wider sinc squared function in the frequency domain and that's the basis of the direct sequence spread spectrum.

What DSSS systems do, is maintain the symbol duration while replacing the original symbol pulse with so many short-duration pulses.
This will spread the spectrum as I said due to the Fourier Transform of the new signal.

So, if I am right, then it is not correct to say that increasing the spreader code length would increase the packet duration.

I am wondering why it is mentioned that "this, of course, comes at the expense of longer packet duration"

Also, is there any data on the symbol duration for different physical layer configuration? If so, where I can find that document?

Thanks.



 

  • 0
    TI__Guru* 86071 points

    I agree that the app note migh be a bit confusing/not correct when it comes to terminology.

    However, for the SimpleLink LRM PHY what is stated in the app note is true:

    • For every input bit, the convolution encoder produces two output bits
    • 4 different spreader lengths are supported (1, 2, 4, 8)

    For a given symbol rate, the data rate is given as:

    Data rate = Sumbol rate / (2*DSSS)

    That measn that when you, for this proprietary PHY, increase DSSS, the data rate goes down.

    Not sure what you are refering to when asking for "any data on the symbol duration for different physical layer configuration"

    For SimpleLink LRM there are two PHYs settings that are characterized and availabe in SmartRF Studio (and sysConfig).

    Both have a symbol rate of 20 ksps.

    The one with DSSS = 4 have then a data rate of 2.5 kbps and the one with DSSS = 2 have a data rate of 5 kbps

    Siri

  • 0 in reply to Siri
    Prodigy 160 points

    My question is not about the DSSS and FEC configuration.

    It is simply the fact that it is wrong to say that when using DSSS you will have longer packet duration. 

    In a legitimate DSSS system, you do not have such a thing as data rate = Symbol Rate/ (DSSS spreading ratio * Convolutional encoder rate).

    THIS IS WHAT IS HAPPENING IN A DSSS system:

    a 1-bit  raw data before spreading:  |---------| 

    above After spearing with 5 chips: _|-|_|-|_

    They have the same duration, but the second one has higher fluctuations in time-domain which translates into a wider spectrum.
    The above both have the same data rate of 1 bit/x seconds where x is duration of the original pulse. In other words, multiplying the the spreading chips does NOT change the data rate.


    If what TI does is anything different from what is happening in the above example, they should not call it a DSSS.

    if what TI does is just replace a bit with more bits, that's not called DSSS, this added overhead might be called just a pulse shaping.

  • 0 in reply to Omid Kandelusy
    TI__Guru* 86071 points

    I will forward your feedback to R&D.

  • 0 in reply to Siri
    Prodigy 160 points

    Thanks Siri, I have not yet received any feed-back from your R&D. team. Could you please follow up with them? or is there a way to directly contact them?

  • 0 in reply to Omid Kandelusy
    TI__Guru* 86071 points

    I have forwarded your input that you think that the app note are using the terminology wrong, and R&D has made a JIRA ticket that they should use another terminology in the app note.

    I do not have a timeline for when this will be updated.

    Siri