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?
\$\begingroup\$
\$\endgroup\$
4
-
\$\begingroup\$ Not an electronics question, as far as I can tell. \$\endgroup\$– Brian CarltonAug 20, 2012 at 15:44
-
7\$\begingroup\$ I actually think that this is on-topic. There are some pieces of software that can capture serial data from a COM port (some of them even when another application is using the port), and the software is actually specialized enough that most people don't know it exists. The downside is that after spending some time looking for such software, I couldn't find any that works fine on post XP computers. \$\endgroup\$– AndrejaKoAug 20, 2012 at 16:03
-
\$\begingroup\$ are you looking for a tool like this? com0com.cvs.sourceforge.net/viewvc/com0com/hub4com/… \$\endgroup\$– kennyAug 20, 2012 at 17:34
-
\$\begingroup\$ related: "Display Hex in PuTTY for Serial". \$\endgroup\$– davidcaryOct 7, 2014 at 20:39
Add a comment
|
6 Answers
\$\begingroup\$
\$\endgroup\$
7
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?
-
\$\begingroup\$ Thank you! I am not looking for interpreting the data. All I want is to receive the raw data and be able to save them in a file. I am trying to find out whatt my Bluetooth device actually transmits. Would Bray's Terminal do that for me? \$\endgroup\$ Aug 20, 2012 at 15:16
-
\$\begingroup\$ @user11395 - yes, any decent terminal software will do this, I use Bray's Terminal too - Putty is another good one... A tip - if you have issues connectiing in Bray's Terminal, go to your BT module device properties in windows (Control Panel -> Bluetooth Devices, right click and select "properties"), and deselect and reselect the SPP service. \$\endgroup\$ Aug 20, 2012 at 16:03
-
\$\begingroup\$ thanks Oli. I am running Bray's Terminal but something seems to be wrong. I "rescan" the ports, I find port COM4, I connect to COM4 and then I can see data being captured. However I don't think that they are correct. I am not sure abouth the values of the Baud Rate / Data bits / Parity Stop Bits / Handshaking that I should choose. Any suggestions? \$\endgroup\$ Aug 20, 2012 at 16:27
-
\$\begingroup\$ Generally the modules come set to 9600,1,N (1 stop bit, no parity) but 115200 is also common (it may say what the defaults are wherever you bought it from) Set to no handshaking also. You can set the baud rate with an AT command (not over the wireless link, you must connect direct to module Rx/Tx pins) Before trying this, send a known character repeatedly and just start from the slowest baud and work your way up - one of them should produce the correct data. \$\endgroup\$ Aug 20, 2012 at 18:33
-
\$\begingroup\$ I managed to capture the data with Bray's terminal. No matter if I select a baud rate of 9600 or 115200 on Bray's terminal, I get the same data (which seem to be correct). Why do both options give the same result? Also, I found out that my device has a baud rate of 115200, but as far as I can see in my device manager, this COM port is set to a baud rate of 9600 (I guess by default). Should I change that? \$\endgroup\$ Aug 23, 2012 at 17:10
\$\begingroup\$
\$\endgroup\$
1
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.
-
\$\begingroup\$ I'm using Bray's in the latest version of Win 10 so it's still working at least in some cases. My computer has only COM3 installed. \$\endgroup\$ Nov 7, 2017 at 21:43
\$\begingroup\$
\$\endgroup\$
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:
\$\begingroup\$
\$\endgroup\$
1
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.
-
\$\begingroup\$ I managed to capture the data with Bray's terminal. No matter if I select a baud rate of 9600 or 115200 on Bray's terminal, I get the same data (which seem to be correct). Why do both options give the same result? Also, I found out that my device has a baud rate of 115200, but as far as I can see in my device manager, this COM port is set to a baud rate of 9600 (I guess by default). Should I change that? \$\endgroup\$ Aug 23, 2012 at 17:09
\$\begingroup\$
\$\endgroup\$
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).
