ESL Tutorial - Unexplained byte in responses

[Scott Grubb]

Hi,

I've been working through the Nordic Bluetooth ESL Tutorial and have the sample code up and running (using a nRF52833 DK as the tag and a nRF5340 DK as the access point).

I've been able to send commands and receive responses via the console, but I'm seeing an extra byte in the responses that I can't find described in any of the documentation.

For example,

> esl_c pawr update_pawr 0xA 0 pings the first 4 tags in group 0.

I only have one tag and I get the following response:

0x0434100300 where

0x04 = Tag 0, Length 4 bytes
0x34 = ???
0x10 = Basic state (the correct response to a ping)
0x0300 = 16-bit status field

> esl_c pawr update_pawr 0xF 0 reads sensor 0 data from the first 4 tags in group 0.

I get the following response:

0x05342e007f08 where

0x05 = Tag 0, Length 5 bytes
0x34 = ???
0x2e = Sensor report, Length 2 bytes
0x7F08 = 16-bit sensor data

Where is the 0x34 coming from, and what does it signify?  It's in all of the responses.

Thanks

Scott

[Amanda Hsieh]

Hi, 

Check the 1- Nordic Bluetooth ESL Tutorial v0.9.1.pdf in the Downloaded kit (here), page. 25:

Regards,
Amanda H.

[Scott Grubb]

Hi,

Thanks for this.  That explains it!  Do you happen to know if this is something particular to Nordic's implementation of ESL?  I don't think it's mentioned in the ESL Service documentation (but I might have missed it there too).

Scott

[Amanda Hsieh]

It's defined in https://bitbucket.org/bluetooth-SIG/public/src/8c192a8effd1574d0c83e72ad91407511bcad209/assigned_numbers/core/ad_types.yaml#lines-179,180,181

[Scott Grubb]

Thanks again.  One other question related to ESL/PAwR: do you know how the tags were configured to obtain the power consumption figures shown here: (+) Periodic Advertising with Responses (PAwR): A practical guide - Software - nRF Connect SDK guides - Nordic DevZone?

I've disabled all unused peripherals on the tag (including the UART) but am struggling to get the power consumption down to anything like these levels when running the ESL demo.  The lowest I have achieved so far using the default PaWR timing parameters is around 170uA.

Thanks

Scott 

[Amanda Hsieh]

Hi, 

Scott Grubb said:

I've disabled all unused peripherals on the tag (including the UART)

How did you disable the unused peripherals? Did you refer to the Disable unused pins and peripherals?

[Scott Grubb]

Hi Amanda,

Thanks again for your help with all of these ESL questions.  I had disabled the unused peripherals as per the guide but the problem turned out to be an external sensor that was being initialised too soon after power-on. It's now working.

I'm now trying to adjust the PaWR timing parameters but I don't seem to be able to adjust the Subevent Interval below 8 without causing the Central ESL app to stop working.  For example, the following works:

CONFIG_ESL_PAWR_INTERVAL_MIN=1024

CONFIG_ESL_PAWR_INTERVAL_MAX=1024

CONFIG_ESL_CLIENT_MAX_GROUP=128

CONFIG_ESL_SUBEVENT_INTERVAL=8

CONFIG_ESL_RESPONSE_SLOT_DELAY=4

CONFIG_ESL_RESPONSE_SLOT_SPACING=2

CONFIG_ESL_NUM_RESPONSE_SLOTS=8

CONFIG_ESL_CLIENT_MAX_RESPONSE_SLOT_BUFFER=8

but this doesn't:

CONFIG_ESL_PAWR_INTERVAL_MIN=768

CONFIG_ESL_PAWR_INTERVAL_MAX=768

CONFIG_ESL_CLIENT_MAX_GROUP=128

CONFIG_ESL_SUBEVENT_INTERVAL=6

CONFIG_ESL_RESPONSE_SLOT_DELAY=4

CONFIG_ESL_RESPONSE_SLOT_SPACING=2

CONFIG_ESL_NUM_RESPONSE_SLOTS=8

CONFIG_ESL_CLIENT_MAX_RESPONSE_SLOT_BUFFER=8

I can't see anything obvious in the central_esl code but I thought that maybe CONFIG_ESL_SUBEVENT_INTERVAL was being divided by 8 somewhere which was causing values less than 8 to result in an error.  There are no clues in the log, because when the problem occurs, it also stops the VCP from working.

Regards

Scott

[Amanda Hsieh]

The latest issue is away from the original scope. Please create a new support case. Thanks.