Ping360 sonar stops scanning

[EliotBR (Eliot)]

@wang

1. I have updated to 0.1.3. There was no stopping for like 30 seconds when I ran my code for the first time. Then when I restarted the sonar, it stopped scanning frequently like before.

We’ve just fixed a ping-python bug that was causing an issue somewhere else, but may also be related to this. Please try updating to 0.1.4 in case that helps

@wang

2. I have changed to ethernet configuration. The sonar is connected directly to the ethernet port of the BeagleBone.
3. There was no problem when connected to the laptop with Pingviewer, but had problem when used bluerobotics-ping with Beaglebone Black. I do not use converter.

Ok, good to know, thanks.

@wang

4. Instead of using transmitAngle, I tried to use command control_transducer()+wait_message(). When I only used control_transducer, there was no stop, but when I included wait_message, it stopped. So what I can do now is to set the timeout parameter in wait_message to be a small value instead of using the default value 4. But this means I may miss some data right? But I don’t want the sonar stop scanning.

The Ping Protocol Ping360 transducer docs specify

@Ping Protocol - Ping360 Transducer

To allow for the worst case response time the command timeout should be set to 4000 msec.

which is why it’s set to 4 (seconds) in the code. It should be possible to dynamically set a lower value if you know you don’t need the full time (which I’m planning to do in a library update, but that may not occur until some time next year).

If you’re interested, the main steps I’m aware of that are likely factored into that “worst case” time are:

• up to 399 gradians of (clockwise) motor rotation while it gets to the hall effect sensor to calibrate the zero position, along with some time to detect/initialise (unsure how long this part takes)
• up to 200 gradians of rotation to get to the requested ping position (unsure how long this takes, but it could likely be timed quite easily - the time allocated could be reduced if you know where the requested position is relative to the current position)
• 1200ms for the transmitting + receiving of a 1200 sample ping with a 1000us sample period (could be reduced if you’re using fewer samples and/or a lower sample period)
• some time to send the response message (this may depend on communication mode + configuration (e.g. serial baudrate), as well as how many samples are included)

I’d note that if you’re having connection issues it’s likely best to fix those before focusing on minimising timeouts, but that said, having a failsafe that doesn’t wait around longer than absolutely necessary is still a good idea

@wang

5. In the function control_transducer(self, mode, gain_setting, angle, transmit_duration, sample_period, transmit_frequency, number_of_samples, transmit, reserved), I cannot find the explanation of the last two parameters : transmit and reserved. Could you tell me what they mean?

The protocol docs I linked to above are the best source of information for things like this. In this case reserved is a reserved parameter, so your best bet is following how it’s used elsewhere in the existing implementations (e.g. in the transmitAngle function it’s just set to 0).