I recently had to use Wireshark with the nRF Sniffer plugin and Nordic nRF52840 dongle to spy on some less than working BLE coms between a Nordic nRF52833 and MicroChip RNDB451.
There's a good migration guide that shows the new characteristics. Of note is the notified TX characteristic 49535343-1E4D-4BD9-BA61-23C647249616.
I think something's up as I got an old OBS421 module working back in the early days of BLE and it had a notified characteristic. Enable notifications with a write to the CCCD and away you go, but more recently it stopped working with our new Nordic nRF52833 module and another engineer had to change it to a write request.
So I add the RNDB451 characteristics to the transparent UART module and voila! Doesn't work. And Putty was showing a couple errors coming from the RNDB451 upon connection - turns out the nRF5 SDK does not support PHY update requests from the RNDB451. But that wasn't the problem. So I dug out the nRF52840 dongle, installed Wireshark and setup nRF Sniffer to sniff on some BLE packets. Here are some useful links:
Sniffing Packets
Once installed following the above links, double-click the nRF Sniffer entry on the opening Wireshark screen. Depending on how many devices are in range, you may see a flood of advertising messages. By selecting the device of interest from the "Device" drop-down, you can filter out everything else. In this case, the RNDB451 dev kit defaults to advertising the name of the device, so it's easy to pick it out. And yes I'm rich; I have not one but two Anker Solix C1000s - highly recommended. I blurred the addresses so you can't steal them. Thieves!
Anyway, you can double-click on any of the advertisement packets and see what's inside, but you can do that with the nRF Connect app. What makes Wireshark/nRF Sniffer saucy is it's ability to sniff the packets once a connection is established. So after selecting the device from that drop-down, we can connect to it and see a bunch-o-stuff.
Too much information!
We don't need to see a bunch of empty packets, so add the handy btle.length != 0 filter.
Enable Notifications with a Write?
So there's that write command. Let's double-click to open it...
And there's the write value of 0100, which should enable notifications, but it does'nt. So let's switch up to a write request.
And now all of a sudden Wireshark knows that this is a request to enable notifications. Why? Well the AI says it might be because the RNDB451 requires a write request to enable notifications and Wireshark is showing the combined write request and notification acknowledge from the RNDB451 all in the same packet detail. Free Candy? Seems Legit.