This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is it possible to record HCI logs using nRF52840?

Hi all.

I have written an application using a softdevice and I want to analyse an interesing behavior I don't understand at the moment.
So I want to record a trace/log of the used HCI commands to see what's going on on deeper levels.

Is this possible?

Thanks in advance
Cheers Michael

Parents
  • HI Vidar.

    I have used your code to monitor the not resolved advertised addresses.
    My address to resolve is not listed in this list.
    This means the address has been resolved immediately after the first appearance? Right?

    But it is still possible that the connection-request it not sent immediately after resolving the address after the same advertisement.
    How long does it take to resolve a random address? Maybe it takes too long, so the next advertisement has to be used for the connection request or the connect request can't be sent just after resolving the address due to other limitations.

    Cheers Michael

  • Hi Michael,

    The address resolving happens on the fly.

    My address to resolve is not listed in this list.

    The application is responsible for managing the list, and it should contain IRK for your peer device, not the address. Does the "input address" ever match your address though?

    Cheers,

    Vidar

  • Yes, the Nordic board is a kind of remote control. A button is pressed, the led is enabled and a command is sent

    .

    Have a nice weekend.

    Cheers Michael

  • Hello Michael,

    Thank you for the clarification, I was a bit confused at first, but I believe it's more clear now. The problem was that I assumed this was related to address matching on a peripheral device, not on a central. So I was basically expecting to see ignored connection requests. That is my fault.

    Michael-1965 said:
    Yes, the IRK is visible in the list, but I don't see the advertised address of my device as "input address".
    But Nordic has connected to my device.

    My monitoring code is set up to trigger the interrupt when the input address does *not* match the whitelist. And the fact that you do not get this event for your device indicates to me that the random address is always resolved correctly with the IRK held in your whitelist.

    The address matching happens in real-time and should not impact the performance. Have you made any observations that indicate otherwise? Another thing, the peripheral is advertising for almost 20 seconds, are you sure the central is actively scanning during this time (I'm not sure if the LED indication is supposed to be active high or not)?

    Cheers,

    Vidar

  • Hi Vidar.

    Thanks for your feedback. We are getting closer to the problem.

    Ok, your test code proves the address is resolved always, just from the beginning.

    In the attached picture you see:

    • First the button is pressed, goes to low
    • This triggers the event, the led is turned on, the GPIO signal goes to low, led is active low.
    • Now, scanning is started, the devices in the white list are searched.
    • The first triple of advertisements appears. According to your test code the address is resolved, but why is there no connection request? The device is scanning already for about 100ms. Please use the Ellisys trace for better resolution to see it better. There is also no CRC problem of the advertisements.
    • The second triple of advertisements appears. Here the connection request is sent, the central connects, the command is sent, and after this, the connection is canceled and the led is turned off.

    I think, starting the scanning will not use much time, so why is the first triple of advertisements not used for a connection?

    Because my application should have the smallest possible latency for sending the remote command, it is important for me to know, what's going on here.


    Cheers Michael


  • Hi Michael,

    Do you get a connection request to the first adv. packet sometimes, and are you starting scanning by calling sd_ble_gap_connect() or do you call sd_ble_gap_scan_start() first?

    The Softdevice should have no problem with sending a connection request to the first packet if it actually receives it. But some advertisements will be lost if you are testing in a noisy environment or if you don't scan 100% of the time (ie scan_windows != scan_interval).

    Michael-1965 said:
    Please use the Ellisys trace for better resolution to see it better

     Maybe you could double-check to see if you sent me the correct trace. I didn't find any connections in the one you sent, only advertising from the peripheral was displayed.

    Cheers,

    Vidar

  • Hi Vidar.

    I have done a lot of tries and have never seen a connection request to the first adv. packets.
    I use "nrf_ble_scan_start" which calls "sd_ble_gap_scan_start".

    The environment is not very noisy and scan_window = scan_interval = 80.

    Maybe the filters are still set in your Ellisys trace, please delete the filters. You should see traffic then.

    I have also done another try: I have paired two different devices and configured the white-list to look for these two. The effect is similar:
    The advs of the first device is visible, but no connection is taking place.
    Then the advs of the second device is visible, a connection request is sent then and it works.
    This proves the address is resolved in real-time, because both devices have different IRKs.

    It looks for me like the client needs to resolve first an address and has to do some preparations to be able to resolve and connect at the next time.

    Cheers Michael

Reply
  • Hi Vidar.

    I have done a lot of tries and have never seen a connection request to the first adv. packets.
    I use "nrf_ble_scan_start" which calls "sd_ble_gap_scan_start".

    The environment is not very noisy and scan_window = scan_interval = 80.

    Maybe the filters are still set in your Ellisys trace, please delete the filters. You should see traffic then.

    I have also done another try: I have paired two different devices and configured the white-list to look for these two. The effect is similar:
    The advs of the first device is visible, but no connection is taking place.
    Then the advs of the second device is visible, a connection request is sent then and it works.
    This proves the address is resolved in real-time, because both devices have different IRKs.

    It looks for me like the client needs to resolve first an address and has to do some preparations to be able to resolve and connect at the next time.

    Cheers Michael

Children
Related