• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 469 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: LNA and TX Start pin mapping issue

Cherry Zhou
Mastermind 22235 points
Part Number: CC2642R
Other Parts Discussed in Thread: CC2640R2F, , CC2540

Hi team,

Here's an issue from the customer may need your help:

The LNA,TX start of the master and slave are mapped. Checking the 4 IO level changes with an oscilloscope. Host is cc2642r, and Slave is cc2640r2f. The slave uses notify to transmit to the host. The characteristic value is 19 bytes (DLE should be turned on by default and 251 bytes set). The connection interval is 20 ms.

Pin Mapping:

Slaver DIO0 (CH4 dark blue) TX START

DIO1 (CH3 Purple) LNA

Master DIO0 (C1 yellow) LNA

DIO1 (CH2 Blue) TX START

Question 1: In theory, 19 bytes of data are sent at a time and should only be sent and received once on a connection event, that is, only one LNA, TX pin change. Now it's finds that LNA,TX has multiple level changes (1,2,3,4 times) on a connection. Why is that?

Question 2: The figure shows that the LNA of the slave is at the top, should it be the TX at the top of each cycle?

Could you help check this case? Thanks.

Best Regards,

Cherry

  • 0
    TI__Mastermind 25810 points

    Hey Cherry,

    Cherry Zhou said:
    Question 1: In theory, 19 bytes of data are sent at a time and should only be sent and received once on a connection event, that is, only one LNA, TX pin change. Now it's finds that LNA,TX has multiple level changes (1,2,3,4 times) on a connection. Why is that?

    There can be a few reasons this occurs. One could be that the TX event to send 19 bytes was simply retried for some reason. The other packet could simply be a control procedure that was still pending. We really need to see a sniffer log showing the data packets exchanged over the air for a full explanation here. The sniffer log will show what packets are being sent and if the payload is indeed being segmented for some reason.

    Cherry Zhou said:
    Question 2: The figure shows that the LNA of the slave is at the top, should it be the TX at the top of each cycle?

    Unfortunately, I don't understand this question. Can you clarify? Are you referring to expected current draw for LNA vs TX?

  • 0 in reply to Ammar N
    TI__Mastermind 22235 points

    Hey Ammar,

    Thanks for your support here!

    Ammar N said:
    Unfortunately, I don't understand this question. Can you clarify? Are you referring to expected current draw for LNA vs TX?

    In a connection event, the host should send first and then the peripheral should send. While in the figure, The Slaver (CH4 dark blue) corresponds to TX START; (CH3 purple) corresponds to LNA Master (C1 yellow) corresponds to LNA; (CH2 blue) corresponds to TX START. The CH3 purple (LNA) in the figure starts the level change first, meaning that the slave receives first? Should be the host TX start (CH2 blue) first level change in theory?

    Regarding the sniffer log, the customer don't make the sniffer log and don't know how to do it. How should they do?

    Best Regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 25810 points

    Hey Cherry,

    Cherry Zhou said:
    Should be the host TX start (CH2 blue) first level change in theory?

    Hypothetically, if the central did have it's level change first and started to TX to the peripheral without the peripheral's RX already high and waiting for a message, then there is a chance the central's TX is not completely received and data is missed. The reason the level change happens on the peripheral first is that it is simply turning its receiver on in preparation for the central's TX.

    Cherry Zhou said:
    Regarding the sniffer log, the customer don't make the sniffer log and don't know how to do it. How should they do?

    Obtaining sniffer logs require extra hardware/software, usually a Frontline or Ellisys Sniffer to capture the packets over the air. If they can provide such logs, we can determine what packets are being sent accurately. For now, we may just be seeing the connection event followed by the the data being sent (which I assume is sent via a notification).

  • 0 in reply to Ammar N
    TI__Mastermind 22235 points

    Hello Ammar,

    Thanks for your support! Here again.

    After configuration, it finds that the IO configuration affects the level change of the connection time.

    IOID_0 | PIN_INPUT_EN | PIN_PULLDOWN | PIN_IRQ_POSEDGE, multiple level changes occur when configured to this mode.

    IOID_0 | PIN_INPUT_EN | PIN_PULLDOWN | PIN_IRQ_POSEDGE | PIN_HYSTERESIS, configured as PIN_HYSTERESIS, only one level flip at a connection event.

    The customer would like to figure out why here's such an effect. High level indicates the start of the transmit and receive, and low indicates the end of the transmit and receive, is that correct?  Dose HYSTERESIS represent a level delay (range of changes up and down)? The oscilloscope does capture a high and low level change.

    The mapping function is PINCC26XX_setMux(pin_handle,IOID_0,IOC_PORT_RFC_GPO0); // Map LNA enable pin RFC_GPO0 to DIO0.

    Ammar N said:
    (which I assume is sent via a notification).

    Yes, that's right.

    Ammar N said:
    If they can provide such logs, we can determine what packets are being sent accurately.

    They have tried to use SmartRF Packet Sniffer, but cannot record any related info.

    Thanks and Best Regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 25810 points

    Hey Cherry,

    From my understanding, configuring the PIN_HYSTERESIS option essentially defines a threshold before shifting the level of the GPIO. Put simply, this is used to reduce jitter/noise on the input line. Without hysteresis, you can expect more level changes if the voltage on the pin jumps between the high/low threshold. So this makes sense from a pin perspective.

    I'm curious as to why the pin is configured as an input? I would expect the pin to be configured as an output, so that the internal LNA/TX lines from the device are outputted to the radio. Here's a link to our Debugging RF output section of the User's Guide with code example to mux the LNA/TX lines to a GPIO.

    Cherry Zhou said:
    They have tried to use SmartRF Packet Sniffer, but cannot record any related info.

    Unfortunately this would not suffice to capture the Bluetooth LE sniffer log. I would search for a Frontline or Ellisys Sniffer to see the hardware required to capture the log. I would highly recommend a sniffer when developing a Bluetooth LE application.

  • 0 in reply to Ammar N
    TI__Mastermind 22235 points

    Hey Ammar,

    Ammar N said:
    Unfortunately this would not suffice to capture the Bluetooth LE sniffer log. I would search for a Frontline or Ellisys Sniffer to see the hardware required to capture the log. I would highly recommend a sniffer when developing a Bluetooth LE application.

    Is this one enough? (CC2540 USBdongle Protocol Analyzer PacketSniffer )

    https://item.taobao.com/item.htm?spm=a1z09.2.0.0.68172e8dZZ2YHp&id=36574805235&_u=e1n97bgta638

    Thanks and Best Regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 25810 points

    Hey Cherry,

    The CC2540 dongle cannot sniff BLE5.0 packets so this will not work. An Ellisys or Frontline sniffer (or similar) is required.