While testing the Ping360 auto_transmit function, I observed the following behaviors:
When the difference between start_angle and stop_angle is greater than 180°:
The system performs only an incremental (CW) sweep and does not execute the decremental (CCW) sweep.
When start_angle > stop_angle with a negative resolution:
The device repeatedly outputs data only for the start_angle and start_angle + 10 gradians.
It does not continue sweeping up to the specified stop_angle.
When the difference between start_angle and stop_angle is ≤ 180°:
Both CW and CCW sweeps occur as expected.
However, some angles are occasionally skipped or missing during the scan.
Additionally, I noticed that sometimes the transmitted data includes an angle slightly beyond the stop angle (stop_angle + resolution), while at other times it does not.
Could you please clarify how the auto_transmit function determines:
When to stop the current sweep and initiate the return (reverse) sweep, and
Under what conditions it skips the decremental sweep or omits certain angles?
I’ve moved your duplicated comments into a dedicated thread, to reduce topic fragmentation and confusion.
The Ping360 firmware is proprietary, and I do not have access to its source. The conditions you’re outlining are not supported options in our Ping Viewer software (so are not regularly tested), and I do not believe there is a clear public specification of the intended behaviour.
How are you specifying the angles, and how much is it overshooting by?
As one possible explanation, the Ping360 operates using gradians, so if your input code is in degrees then it makes sense that sometimes the rounding/conversion doesn’t line up perfectly.
If you’re using more than one motor step between transmissions then as a guess it might go past the specified stop angle by as much as the transmit spacing - 1 step, to avoid “missing” the end of the scan region (i.e. the firmware may consider the requested region to be a “required coverage” area, rather than “angular limits the transmissions must stay within”).
Without seeing the source I’m afraid I can’t tell you what the exact condition is for this. If you want I can ask internally whether that’s information that can be determined and shared, but I’m unsure how worthwhile that would be.
As you’ve found, that seems to be whenever the sector width is greater than a half circle. I presume this was implemented because for large sector widths it’s more valuable to jump from the sector end to the sector start than to re-cover the area that was just covered.
With smaller sectors that approach doesn’t make sense, because to get the transducer back to the starting angle it must either move back through the coverage region (in which case you may as well scan), or continue forward (in which case it’s moving further than it needs to).
Within the scanning range this shouldn’t happen, so if it is then I would assume it’s being caused by some kind of communication or networking error (possibly from electrical noise and/or limited network capacity). It’s hard to say more without more context about your testing conditions.
If you’re able to reproduce this on a bench setup, with a wired connection and minimal other data load, then it could also indicate a bug in the firmware, or some kind of hardware issue with the device.