• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 51 subscribers
  • Views 9087 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.

cc2540 frequency hopping sequence

wireHound
Intellectual 430 points

Other Parts Discussed in Thread: CC2540

Is there any documentation that describes the frequency hopping sequence done by the cc2540 radio?  If so where can I go to find it?  I need information to demonstrate that the sequence meets the requirements specified by FCC.

Thanks...

  • 0
    TI__Genius 10955 points

    You should not try to certify Bluetooth Low Energy as a frequency hopping system, as opposed to traditional Bluetooth (BR/EDR). See the following white paper from Bluetooth SIG: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=237781

    The frequency hopping sequence (frequency hopping used here as an engineering term for describing the algorithm, not for regulatory aspects) can be found in the Bluetooth core spec, https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737, Volume 6, Part B.

  • 0 in reply to hec
    Intellectual 430 points

    I have started a project based of the SimpleBLECentral and SimpleBLEPeripheral TI sample projects.  Are those projects set to be 'traditional Bluetooth'?

    How can I tell in the code what a project is set to, (traditional or AFH)?

    If a peripheral is set to support a frequency hopping system can it also support traditional Bluetooth as well?

  • 0 in reply to wireHound
    TI__Genius 10955 points

    By "Traditional Bluetooth", I meant what is often referred to as BR/EDR (Basic rate/ehnanced data rate) in the Bluetooth world, which means the modes that are compatible with older Core spec versions such as v 2.1. CC2540 only supports Bluetooth Low Energy (introduced in Bluetooth 4.0). You should therefore never try to certify a CC2540 based system as frequecy hopping.

  • 0 in reply to hec
    Intellectual 430 points

    The Bluetooth documentation refers to 2 Bluetooth systems.  BR and LE.  BR can support the optional EDR.  So I can have one of 3 different configurations.  A BR/EDR configuration, LE configuration, or a combined BR/EDR and LE configuration.  I want to certify my module as a LE module with the 'LE configuration'.  The agency that is testing my module and submitting it to FCC for certification is requesting a description of how the channels are managed.  They want a description for the report on how channels are chosen, how often they are used and what determines the pattern that they are changed.  If I understand it correctly, the LE configuration employs a frequency hopping method that  set up in an algorithm based off of a 'hop' interval that is a randomly chosen number between 5 and 16.  This number is communicated between the two connecting devices during a connection event.  Is this correct?  Is this what FCC needs for certification?  Or do I need to provide more detail like time on channel, before changing to next channel, and how it keeps channel usage equal?

    Thanks for your responses they have been helpful.

  • 0 in reply to wireHound
    TI__Genius 10955 points

    Please refer them to the white paper that I linked above. Bluetooth LE should not be certified as an FHSS system, but rather as a system using digital modulation techniques:

    15.247(a)(2): Systems using digital modulation techniques may operate in the 902 - 928 MHz, 2400 - 2483.5 MHz, and 5725 - 5850 MHz bands. The minimum 6 dB bandwidth shall be at least 500 kHz.

    This regulation does not require any frequency hopping, and in certain configurations, a BLE system will operate on a single frequency (an advertiser with only one channel in its channel map). Since it is not a frequency hopping system, I strongly believe they don't need the information they are requesting. If they try to test a Bluetooth LE system (using any solution on the market) as an FHSS system, it will fail! If they want information on the frequency agility done in Bluetooth LE for their own education, they can read the Bluetooth core spec (link above), Volume 6, Part B. Your understanding of this spec is correct for a system in a connection. When not in a connection, a BLE system will send advertising packets on 1, 2, or 3 advertising channels.

  • 0 in reply to hec
    Intellectual 430 points

    Hec, thank you for responses they have been very helpful.

    Thanks...

  • 0 in reply to hec
    Intellectual 265 points

    What you say is actually misleading. The problem is not with the advertising channels, but with connection event timing (max. 4s), and the data channel selection scheme, in which the minimum number of channels used in a connection is not defined by the actual (v4.2 and before) specification. If you see the white paper, you will find the notes stating:

    "Frequency hopping spread spectrum systems (FHSS) in the 2400-2483.5 MHz are in FCC 15.247(1) (iii) required to a) use at least 15 channels and b) when hopping, the transmission also must comply with a 0.4 second/channel maximum dwell time."

    If we are talking about the legacy inquiry process, it is not FHSS also, as the FCC document you referred states in the first paragraph:

    "The system receivers shall have input bandwidths that match the hopping channel bandwidths of their corresponding transmitters and shall shift frequencies in synchronization with the transmitted signals."

    Following your arguments, if we take into consideraton the discovery processes, neither legacy, nor LE will pass. Moreover the communication can be achieved using the legacy inquiry process also, using the EIR packets (though its a quite slow method).

    It is very interesting though, that how Legacy Bluetooth passed till now...

  • 0 in reply to Andras Balogh
    TI__Genius 10955 points

    Andras Balogh said:
    What you say is actually misleading. The problem is not with the advertising channels, but with connection event timing (max. 4s), and the data channel selection scheme, in which the minimum number of channels used in a connection is not defined by the actual (v4.2 and before) specification. If you see the white paper, you will find the notes stating:

    I used advertising channels as an example, because it is the most obvious case where trying to certify as FHSS would fail. You are absolutely right that data channels can't pass as FHSS,  either.

    I don't have enough knowledge of Bluetooth BR/EDR to comment on the regulatory requirements there.

    By the way, this thread is 2 1/2 years old.

  • 0 in reply to hec
    Intellectual 265 points

    hec said:

    I used advertising channels as an example, because it is the most obvious case where trying to certify as FHSS would fail. You are absolutely right that data channels can't pass as FHSS,  either.

    I don't have enough knowledge of Bluetooth BR/EDR to comment on the regulatory requirements there.

    And your statements were misleading. Restating an argument will not lead anywhere.

    hec said:

    By the way, this thread is 2 1/2 years old.



    ...which makes this issue far more concerning.

  • 0 in reply to Andras Balogh
    TI__Genius 10955 points

    I don't follow you. My point here is that you need to certify Bluetooth Low Energy as a non-FHSS system (see the white paper from Bluetooth SIG for details on which clause to use for each regulation). The reasons I gave for not being able to certify it as FHSS are surely incomplete; they may even be incorrect. But as long as you are able to pass the clauses that you declare compliance to, it doesn't matter whether or not you are compliant to the FHSS clause in each standard, or why not.

  • 0 in reply to hec
    Intellectual 265 points

    hec said:
    I don't follow you. My point here is that you need to certify Bluetooth Low Energy as a non-FHSS system (see the white paper from Bluetooth SIG for details on which clause to use for each regulation). The reasons I gave for not being able to certify it as FHSS are surely incomplete; they may even be incorrect. But as long as you are able to pass the clauses that you declare compliance to, it doesn't matter whether or not you are compliant to the FHSS clause in each standard, or why not.

    There is a misunderstating. I am not arguing with your point. The BLE shall not be certified as an FHSS system. I am arguing with your example. There is no FHSS system that could work without a synchronization process, which is done using the discovery and connection establishment procedures both in BLE and BR/EDR systems (GAP). This way, as the BR/EDR inquiry and paging (non-connected states) are clearly not FHSS processes, there is absolutely no sense in FHSS requirement when Link Layer is in Advertising, Iniating, or Scanning state. Only the Connected states should matter, otherwise neither of the FHSS technologies in the ISM/UNI bands, that are using in-band synchronization, would ever pass.

  • 0 in reply to Andras Balogh
    TI__Genius 10955 points

    You seem to forget that the advertising channels in BLE are not only used for connection establishment, but may also be used for broadcasting data. A BLE device may be a broadcaster that doesn't even have the capability of forming a connection.

    As I said, I don't have detailed knowledge of BR/EDR. But it is my understanding that the transmitter in the connection establishment phase will perform FHSS that is compliant to the regulations. It makes sense that the receiver FCC requirement you quote doesn't apply until a connection has been established.

  • 0 in reply to hec
    Intellectual 265 points

    hec said:
    You seem to forget that the advertising channels in BLE are not only used for connection establishment, but may also be used for broadcasting data. A BLE device may be a broadcaster that doesn't even have the capability of forming a connection.

    The FCC document does not distinguish between packet types. There are signals, that are transmitted or received, no matter what is placed in there. Moreover there are no states or roles defined also.

    hec said:
    As I said, I don't have detailed knowledge of BR/EDR. But it is my understanding that the transmitter in the connection establishment phase will perform FHSS that is compliant to the regulations. It makes sense that the receiver FCC requirement you quote doesn't apply until a connection has been established.

    As the FHSS compliance is applied for the whole system, there is no sense in distinguishing between these also.

  • 0 in reply to Andras Balogh
    TI__Genius 10955 points

    Andras Balogh said:
    The FCC document does not distinguish between packet types. There are signals, that are transmitted or received, no matter what is placed in there. Moreover there are no states or roles defined also.

    Exactly. Which means that my argument was valid all the time.

    Andras Balogh said:
    As the FHSS compliance is applied for the whole system, there is no sense in distinguishing between these also.

    Fine, but for BLE, the transmitter isn't compliant, which means that the system can't be compliant. As I have already said, I don't know what makes BR/EDR compliant, but it is not important for this thread (at least the original topic).

    I will leave it at that. The important conclusion of this thread is that a BLE device should be FCC certified as a "system using digital modulation techniques", and I believe we can agree on that. This information is now probably well known by all test houses, but it was less known back in 2012 (which I believe is also why the Bluetooth SIG needed to write the white paper I referred to).

  • 0 in reply to hec
    Intellectual 265 points

    Changing the originally argued questions and arguments (again) is not an elegant way of ending a conversation.

    But I agree that this has become off topic, as the FCC definitions are not clear enough to make any progression in this issue. I think I will write directly to a person, who is involved much more in the question. If you have some contact, I would appreciate if you wrote it in private.

    If I have any advance with the question, I will post it here in the future.