A quick scan, and i’m by no means a bluetooth expert.
Your pool name is POOL01
The setup of connection between your device and the EQ seems to happen at packets # 915-918
Packets 919 → 930 seem to be setting up the bluetooth link-layer agreements (versions, features, length with the REQ - Request followed by the RSP - Response).
From there I did a quick google to try and filter some noise out, and found this as a copy paste straight into the filter bar:
btle.data_header.length > 0 || btle.advertising_header.pdu_type == 0x05
This shows only connection requests and non-zero data packets. (brings 3288 captured packets down to 182)
For reference the “Slave_0xaf9a8dad” is the EQ and the “Master_0xaf9a8dad” is the bluetooth device/application.
it would be nice to know what you are doing within the app at various time through the capture. But applying a tiny bit of ethernet experience (which may be way wrong), it doesn’t look like data payload was captured.
eg: packet request 1206 and response 1209 seem to be a fetch of what your Device Name is which is POOL01
So focusing on 1206 & 1209 for a little bit of learning, and this “Bluetooth Assigned Numbers” document ( Assigned Numbers (windows.net) )
We see in packet 1209, that it has inside Bluetooth Attribute Protocol, “Attribute Data” Handle 0x0003. The “Device Name” POOL01 is responded with 0x2a00. Which from the document link above is on page 83/393 “device Name” “0x2A00”.
But I cannot make out much else, unless it’s buried in the “unknown” space of the bluetooth spectrum, or if we don’t know what you were doing during the capture. Hope thats a start?