Indecipherable Data on Serial Monitor

Question

I have ready made working electronic product. I am applying reverse engineering on it. The WiFi module is connected to micro-controller via UART( RX & TX). The android app sends command to WiFi and micro-controller works as per the command. I have attached a USB to TTL cable on RX and TX also command ground as well of WiFi module. The cable is connected to serial monitor on PC. When the app send data to WiFi, the serial monitor shows Indecipherable value. I have checked every baud rate possible. Instead of USB to TTL cable, I also used HC05 Bluetooth module. But it shows Indecipherable data. How can I get the readable values on my serial monitor. Do i need to disconnect micro controller from WiFi?

No RS232 is used in whole design.

The first two images has similar data but with different baud rate. First image data is set at 4800 and second one at 9600 with No parity, 8 bit data, stop bit 1. "0D" is just enter command( For readability).

Answer 1

It looks like 4800 bps is the correct speed. The 9600 data is obviously (!) the same data sampled twice as often. Here is how you do that analysis:

Here's the 9600 baud data as it would appear as a bit sequence. The data is written LSB first, and I've represented the start and stop bits as lower-case o (zero) and i (one), respectively.

|06      ||3F      ||60      ||0C      ||FE      ||80      ||60      ||CC      |
o01100000io11111100io00000110io00110000io01111111io00000001io00000110io00110011i

Here's the 4800 baud data, stretched out to the same time scale:

| 71               | | 24              || 0F              | | A4               |
o 1 0 0 0  1 1 1 0 io 0 0 1 0  0 1 0 0 io 1 1 1 1 0 0 0 0 i o 0 0 1 0  0 1 0 1 i

Note that each bit in the lower stream corresponds to two bits of the same value in the upper stream. Keep in mind that when running at 9600, your wiretap is resynchronizing on a high-to-low transition, so there's a little bit of "slop" around the byte boundaries at that speed.

It's also clear that an even slower speed would NOT be correct — there are single isolated ones and zeros in the data at 4800, which means that this is the minimum sampling rate for this data.

Answer 2

The first hex screengrab (at 4800 baud) looks promising:

What you are seeing is a 4-byte message. The message is not in ASCII so it's not human readable. The message is coded in binary (or hexadecimal, if you prefer) and so we need to view and interpret it in that way. Binary typically results in shorter messages than ASCII.

Figure 1. The ASCII table may help in some cases. 'OD', which appears in your screengrabs, is the 'CR' (carriage return) character.

• Each line starts with ASCII character 'q' (0h71). It's probably a preamble.
• The second character in the responses you have posted is ASCII '$' (0h23) or '#' (0h24).
• The third character is fixed as 0h0F.
• The fourth character appears to be a checksum. You can confirm this using your computer's calculator in Programmer mode. Select 'byte' data type (to truncate to 8-bits):
  • 0h71 + 0h24 + 0h0F = 0hA4.
  • 0h71 + 0h23 + 0h0F = 0hA3.

You haven't given any information what you did to generate the $ and # symbols so I can't help any further at this time.