STM32 & Ping Protocol

Blue Robotics Software
1

Hi everyone!

I’ve been working on integrating the ping protocol and my Ping1D to my embedded system recently and I’ve ran into some issues. I’m able to request the protocol version and get a return message that makes sense using the following :

uint8_t pData[] = {
		        0x42, 0x52, 0x02, 0x00,
		        0x06, 0x00, 0x00, 0x00,
		        0x05, 0x00, 0xa1, 0x00
		    };
	return HAL_UART_Transmit(huart, pData, sizeof(pData), 100);

But when it comes to requesting the processor temperature (1213 message ID), the return message is… not what it’s supposed to be. Am I calculating something wrong or missunderstanding how to properly communicate with the Ping1D?

Requesting the data like this :

uint8_t pData[] = {
			0x42, 0x52, 0x02, 0x00,
			0x06, 0x00, 0x00, 0x00,
			0xBD, 0x04, 0x59, 0x05
	};

And reading the return :

uint8_t rData[12];
HAL_UART_Receive(huart, rData, sizeof(rData), 100);

But after this rData is mostly garbage from what I can see (Definitely not seeing the BR start). Just looking for a lead on what I’m doing wrong here… Thank you!

PS : I know I should be automating the checksum calculation but I wanted to simply follow the quickstart example and get started on retrieving some data for practical purposes :slight_smile:

Edit : Seems like the HAL is giving me a HAL_TIMEOUT for some reasons on the reading… Maybe 100ms is too short to retrieve the distance_simple…

2

If you’re getting a timeout you’re probably not getting any data, hence it looks like garbage. Are you sure your checksum is correct? Bad checksum would probably explain the timeout and the rest of it looks fine.

1 Like
3

My logic was :

0x42 = 66 (B)
0x52 = 82 (R)
0x0002 = 2 (Payload length)
0x0006 = 6 (Message ID, general request)
0x00 = 0 (Unused field)
0x00 = 0 (Unused field)
0x04BD = 1213 (written as 0xBD, 0x04 as it’s little-endian format) (Representing the id I want to request)

Which brings us to the checksum… 66+82+2+6+1213 = 1369.
1369 in hex would be 0x0559 denoted 0x59, 0x05 as little-endian again.

Unless I’m missunderstanding something, that should be the correct checksum.

4

Ah, there’s your problem. The checksum is a sum of BYTES, not fields. So 66+82+2+6+0x04+0xBD

3 Likes
5

Thank you! Will test this out on my end, but it definitely sounds like that is the issue!

6

According to this… The checksum would change to being = to 359. Which would be denoted 0x5D, 0x01 in little-endian. Even after changing this I still get relatively similar result where a HAL_Timeout is still the result of the receiving operation. I would start thinking that my sonar just isn’t communication but the initial handshake is working.

7

how did you get 359? I got 349.

8

Just a typo, I meant 349 indeed! Sorry for that. But the hex was correct for 349, being 0x5D, 0x01 I think. Starting to think it might be a hardware related issue but the fact that the handshake works leads me to think it’s not…

So my current logic is something like this :

uint8_t pData[] = {
			0x42, 0x52, 0x02, 0x00,
			0x06, 0x00, 0x00, 0x00,
			0xBD, 0x04, 0x5D, 0x01
	};

	HAL_StatusTypeDef status1 = HAL_UART_Transmit(huart, pData, sizeof(pData), 100);

	uint8_t rData[12];

	HAL_StatusTypeDef status2 = HAL_UART_Receive(huart, rData, sizeof(rData), 100);

Where status1 is HAL_OK and status2 is HAL_TIMEOUT. If I loop it to do the transmit & the receive on repeat until the status2 is HAL_OK as a test, it does become HAL_OK but the received data isn’t any different…