Ping360 - failed to initialize auto transmit mode

Hi There,

Summary

We are working with Ping360. After the recent discussion, we started using the C++ library. We are having problems that we don’t understand why.

Before I describe the problems any further, I want to make it clear that Ping360 works with the Desktop client. Although I’m not certain about it, the problem we are having seems to be language/environment independent. What would be the issue here?

We can not control auto_transmit mode.

What we can do

  • We can send a protocol version message (ID: 5) and receive the protocol version from the device.
  • We can send a device information message (ID: 4) and receive the device information from the device.
  • We can send an autotransmit message (Id: 2602).

What we can not do

  • Either we can not receive any auto transmit messages.
  • Or the device does not emit any auto transmit messages.

Detailed packages

# Protocol version
Message[0-7]:   42	52	02	00	06	00	00	00
Message[8-15]:  05	00
Cheksum:        a1	00
# Device information
Message[0-7]:   42	52	02	00	06	00	00	00
Message:[8-15]: 04	00
Cheksum:        a0	00
# Auto transmit
Message[0-7]:   42	52	10	00	2a	0a	00	00
Message[8-15]:  01	01	64	00	10	04	bc	02
Message[16-23]: e2	04	c8	00	2c	01	05	14
Cheksum:        04	04

We can not control set_transducer

What we can do

  • We can send a protocol version message (ID: 5) and receive the protocol version from the device.
  • We can send a device information message (ID: 4) and receive the device information from the device.
  • We can send a transducer message (Id: 2601).

What we can not do

  • Either we can not send it properly
  • Or the device does understand us for some reason.
  • We can not make the transducer head turn in the intended direction.
  • When we request a data device responds as with NACK message.

Detailed packages

Here is the hex of the messages that we sent:

# Protocol version
Message[0-7]:   42	52	02	00	06	00	00	00	
Message[8-15]:  05	00	
Cheksum:        a1	00
# Device information
Message[0-7]:   42	52	02	00	06	00	00	00	
Message:[8-15]: 04	00	
Cheksum:        a0	00
# Transducer
Message[0-7]:   42	52	0e	00	29	0a	00	00	
Message[8-15]:  01	01	c8	00	64	00	10	04	
Message[16-23]: bc	02	e2	04	01	00	
Cheksum:        bc	03

After requesting the device_data (2300) message, the response from Ping360, A NACK message.

Message[0-7]:   42	52	02	00	06	00	00	00	
Message[8-15]:  fc	08	
Cheksum:        a0	01

Hi @incebellipipo,

auto_transmit is a part of the protocol specification, but isn’t yet available in Ping360 devices. There’s a new firmware that’s been tested somewhat internally, but it’s not yet public, and there isn’t yet a publicly available firmware updater either.

There was supposed to be a message about that not being available yet in the ping protocol docs, but apparently they haven’t rebuilt properly since that change was put in, so it’s not showing yet.

Thank you @EliotBR , that explains why auto_transmit is not working.

I updated the first post that I send. I forget to mention that we are getting NACK after requesting device_data from ping360. How should we approach this problem?

nack messages have a nack_message field, which should indicate the cause of the nack. What message are you receiving?

That’s the message that we are receiving.

Parsing that, I get

--------------------------------------------------
ID: 6 - general_request
Header: start_1: 66 start_2: 82 payload_length: 2 message_id: 6 src_device_id: 0 dst_device_id: 0
Payload:
  - requested_id: 2300
Checksum: 416 check: 416 pass: True

→ That’s not a nack, it’s a general_request message asking for a 2300 (device_data) message, so presumably that’s the message you sent, not the response from the Ping360 :slight_smile:

Hmm, very interesting. Very much so much interesting.

Because the message I’m sending is the message below:

I’ll continue investigating. I’ll be updating the thread going forward.

How are you determining what you’ve sent vs what you’ve received? That parses to

--------------------------------------------------
ID: 2601 - transducer
Header: start_1: 66 start_2: 82 payload_length: 14 message_id: 2601 src_device_id: 0 dst_device_id: 0
Payload:
  - mode: 1
  - gain_setting: 1
  - angle: 200
  - transmit_duration: 100
  - sample_period: 1040
  - transmit_frequency: 700
  - number_of_samples: 1250
  - transmit: 1
  - reserved: 0
Checksum: 956 check: 956 pass: True

which is definitely the response from the device ← I misunderstood, so that is incorrect - my apologies.

I have breakpoints in the code. That’s how I see what I’m receiving and what I’m sending.

I’m using a branch that is not yet merged to master. Which has an open pull request on it. Add ping360 device generation by patrickelectric · Pull Request #38 · bluerobotics/ping-cpp · GitHub

I’m using Ping360::set_transducer method. When I follow the breakpoints, it leads me to the PingPort::write. ping-cpp/ping-device.cpp at 6a9db504d82b27ca257170a666562361bdddda19 · patrickelectric/ping-cpp · GitHub

I’m pretty sure that I’m the one who’s sending the message. Definitely, ping360 is not sending that to me.

I need to be sure that I’m getting the concept: If I want to get device_data, I should send transducer right? And then wait for the reply that is device_data? Am I mistaken?

No worries;

I misunderstood which message it was - I’ve corrected my comment.

It seems like you either aren’t getting a reply from the Ping360, or just aren’t recording it. As I understand it the Ping360 can’t have sent you a request for a 2300 message, so perhaps you’re getting no response from it (or not recording the response), and instead thinking that the next message you sent is what it responded with or something?


If it’s helpful, I’m using ping-python to parse your messages.

from brping import PingParser

parser = PingParser()

def parse(message):
    # convert human-readable hex string into just the data 
    data_string = ''.join(part.split(':')[1].strip()
                          for part in message.split('\n'))
    # parse the data, converting string characters back into the hex bytes
    for i in range(len(data_string), 2):
        result = parser.parse_byte(int(data_string[i:i+2], 16))
    # check if message data was valid
    assert result == p.NEW_MESSAGE, "incomplete/invalid message"
    return parser.rx_msg

# test direct copy of code block
message = '''Message[0-7]:   42	52	02	00	06	00	00	00	
Message[8-15]:  fc	08	
Cheksum:        a0	01'''

print(parse(message))
2 Likes

That should be correct, yes :slight_smile:

5 posts were split to a new topic: Ping360 not changing angle with ping-cpp