Hello,
By default, Ping Viewer limits the scan distance to 50 m. If you’d like to configure longer ranges, you can enable Debug Mode in Ping Viewer, which removes that restriction.
That said, the current OSS firmware has been primarily developed for operation up to roughly 100 m, although operation at those distances has not been extensively characterized yet. While longer ranges can be configured, performance will degrade significantly and may result in very poor resolution, reduced target detectability, or no useful returns at all. For long-range operation, you’ll generally need to use maximum gain.
Regarding the saturated output, there are a couple of things that may be contributing:
1. Blind zone and transmit duration:
A strong return near the beginning of the profile followed by a rapid drop-off is often related to the transmit pulse and recovery period.
The current hardware has a blind zone immediately after transmission. The size of this blind zone increases with transmit duration, and transmit duration increases as the configured scan length increases.
For example, if you’re configuring a manual 50 m scan but only care about targets at 5 m, the firmware may transmit significantly more acoustic energy than necessary, which can increase the blind zone and reduce near-range performance or completely hide near echoes.
In this scenario, if your target is within the blind zone, it may never appear in the received profile.
When auto gain is enabled in Ping Viewer, the firmware attempts to compensate for this automatically by adjusting parameters such as transmit duration and operating range. One limitation of the current implementation is that it relies on multiple consecutive pings to converge reliably. If the ping rate is very low (large ping interval) or if profiles are triggered manually one at a time, the output may appear unstable or produce inconsistent results.
2. DC-offset settling (not likely your case):
A fully saturated output that is often observed at startup or immediately after changing gain settings is usually related to internal DC offset compensation. Current OSS firmware requires several pings to settle and estimate the proper offset. Similar to the previous point, if the ping rate is low, you may need to allow several pings to occur after startup or after changing gain before the data becomes stable.
If your application allows continuous operation, I would recommend using a reasonably high ping rate (for example, 10~30 Hz), allowing the firmware to manage transmission timing automatically. The firmware will not transmit a new pulse until the previous acquisition has been fully processed, so no data will be lost.
Normalization and enhancement controls
At the moment, Ping Viewer does not expose controls for the OSS-specific processing options such as normalization and enhancement. Those parameters can currently be configured through libraries such as brping.
It’s also worth noting that the current OSS firmware intentionally uses a relatively simple processing pipeline. For now, the project is primarily intended as a platform for experimentation, custom DSP development, and access to lower-level sonar data. Work is ongoing to add more advanced processing approaches, including IQ-based processing and chirp demodulation, which will enable significantly more sophisticated DSP techniques.
A few additional details would help find a better configuration for your case:
- Are you running the firmware exactly as provided in the repository, or have you modified it?
- Are you manually adjusting parameters such as gain, scan start, and scan length, or are you using auto gain mode?
- Are you using it in continuous mode with a specific ping interval or manually triggering profiles?
- Is your goal simple range estimation, or are you developing custom DSP algorithms on the MCU or host computer?
- Is your intention to use it primarily in Ping Viewer, or as a sonar data source for another system?
With that information we can probably suggest a more suitable configuration for your setup.