I can point Bob in the right direction if he were doing this on Linux or Windows, and MacOS is similar to Linux. iPhone is a step too far for me! I’m confident it’s possible because iPhones run iOS, which is based on MacOS, so should be similar ‘under the bonnet’.
But, might be difficult because smart phones are race-tuned to support smart phone functionality, not as a general purpose platform, and Bluetooth is a layered system function, part of the network stack. Development is often done cross-platform, so the functionality Bob needs may not be cheap or readily accessible.
That said try looking for Bluetooth Analyzer, Diagnostic, Logger, Debugger etc. There are plenty of app developers who need to understand where Bluetooth might be failing, but most work at high-level, and don’t need to look at the data. I don’t know what’s available for iPhone (or Android).
Bluetooth is based on a short range radio link operating in the 2.4GHz band. It channel hops and is packetised, so receiving and transmitting it is best left to the hardware!
The Bluetooth hardware presents to the operating system as a network peripheral that behaves in much the same way as an Ethernet Card, WiFi, ADSL etc. The operating system receives and orders packets, then wakes up the program that started the connection, presenting it with a block of data. The data might be encrypted.
Wireshark is the go to tool for examining network traffic on Linux, Windows and MacOS. It’s an advanced packet sniffer. There’s at least one Packet Sniffer for iPhone. Take a bit of setting up and not easy to learn because sniffers are full-throttle diagnostic tools, but packet sniffing is a good place to start. Might find Bob’s meter sends plain text data, that can be easily logged and read.
A packet sniffer may not be enough. It won’t decrypt. That, and decoding the data format is down to the program. The sniffer might reveal clues. The Bluetooth header identifies the protocol, Bob’s meter is probably serial, but serial can carry text or binary data. Text is human readable, binary requires more work, identifying how each field was packed. Other protocols are possible. The header also identifies if a CODEC is needed, as when the data-stream is audio/visual. Worst case, reverse engineering an encrypted proprietary data stream is hard work!
Dave