I have a Bluetooth transmitting device and my PC (Windows 7) is connected to it and configured as if it was connected through a RS232 serial port (COM4). How can I capture the raw data transmitted by the Bluetooth device, or, equivalently, the raw data received in COM4?
You can use a standard terminal program to capture the data in different formats. I suggest using Bray's Terminal, it's really easy and has a lot of options!
Or do you want to capture and interpret the data in some kind of own application?
The best solution I have found, though a bit crude, is Tera Term http://ttssh2.sourceforge.jp/index.html.en.
Bray's doesn't play nicely with Windows 8. While it is impossible to tell what exactly it is doing without the source, it appears that it is making some assumption about the location of a registry setting.
portmon also did not work for me on Windows 8.
My personal favourite terminal emulator for debugging is RealTerm which has a nice range of display options for embedded systems. Both RS-232 and TCP/IP operate fine under Windows 7 x64 and below (I haven't tried under Win 8 but don't have any reason to think it wouldn't work). A few features I find especially useful are:
- ASCII / HEX view of data
- Capture files can include timestamps
- There's an easy way to send binary data sequences
- Hardware flow control pins can easily be monitored / changed
There are also quite a few other options for I2C, SPI, Dallas 1-wire and GPIB. I haven't personally used those features but there's a good summary on the SourceForge page above. Here's a screen capture of the main display tab view:
I'd recommend bray as well, if you're not sure about the baud rate open up the hardware manager, browse to COM ports and select properties, it's listed there though not always accurate.
There's portmon: a sysinternals tool that act as a datascope for COM ports.
Depending upon your exact requirements, it may be helpful to use a microcontroller which can capture and time-stamp the data and then forward it to the PC. The UARTs historically found on typical PCs have only been able to record accurate timing information or capture 9-bit data by having the processor grab each byte as it arrives, without buffering; later operating systems and drivers are generally not equipped to do that, and UART-to-USB chips are hopeless in that regard. If your PC can receive data at twice your desired data rate, you could have a microcontroller receive bytes of data and for each byte send out two bytes. The first byte would have the MSB set, report the MSB (or two MSB's if 9-bit) of the incoming data in the next bit(s), and use the bottom 5 (or 4) bits to report amount of time (0-30 or 0-14) since the middle of the previous byte's stop bit (measured in units of e.g. one bit time). The second byte would have the MSB clear and contain the remaining 7 bits of data. When no data is being transmitted, FF pacing characters would be sent every 30 (or 14) bit times. Software receiving these reports would thus be able to reconstruct very precisely (within one bit time) the exact timing of incoming data. If the data rate feeding the PC was four times the data rate being monitored, one could use this general scheme to multiplex two receive channels into one PC port (use a bit of the header byte to identify whether it contained data for the first or second port). While timing things accurate to one bit time may seem excessive, there are times it can be useful, especially when monitoring the two sides of a communications link (e.g. to judge how long it takes one device to respond to data sent by the other).
protected by Community♦ Jun 26 '17 at 9:33
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?