Hi - is it possible to obtain raw (unscaled) profile data from the Ping1D? Thanks!
Hi @animmosmith, welcome to the forum 
Iām not certain what you mean by āscaledā data here - if you mean
- the profile data that the sensorās ADC collects then
- thatās whatās included in the 1300 - profile message
- if youāre using Ping Viewer then itās included in the sensor logs
- data thatās not scaled by the selected gain then
- thatās not possible because that gain is applied electrically in the receiving circuit, before the values are measured
Hi - many thanks for the quick response!
Iām reading directly from the 1300 - profile message.
Referring back to this thread, it seems that there is some on-board scaling rather than just raw ADC output. Or has this been updated in firmware since?
Thanks!
Hi @animmosmith,
The values are not raw data from the ADC, but the output of some algorithms to filter, adjust gain, add offset and more that I canāt give more details about.
Can you inform what you want to accomplish or the big picture ? With that we may help you more about your objective.
Hi Patrick - many thanks for your message.
Iām an oceanographer - Iām interested in mapping out the spatial distributions of scatterers (bubbles/plankton/sediment) and the ping 1D is a really nice, low cost/power package that could do this with access to the raw data from the ADC (and then calibration with known targets). I understand that your algorithms are proprietary, but it would be a really nice feature (and presumably a trivial amendment to the firmware for you) to bypass them completely and have access to the raw ADC values. Would you be interested in running some collaborative trials?
1 Like
Dear all,
I intend to measure acoustic attenuation of the environment by using the amplitudes but Iām just able to get the envelope data from the raw profile data.
How can I collect the raw data from the ping-python repository?
Looking forward to your response.
Mariana.
Hi @mlflavio, welcome to the forum
Interesting application
Iāve moved your post here because itās seemingly on the same topic. Just confirming, youāve got the profile data points already, but youāre interested in the raw ADC measurements that the sonar takes in order to determine the intensity of the returned ping echoes? If so, thatās currently not possible with the existing firmware.
If youāre instead saying youāre currently only able to get the distance estimates and youād like to receive profile data instead/as well then you should be able to do that with the get_profile() method (instead of the get_distance() method used in the example).
Cool!
This would be neat functionality to provide, but it may not be as trivial to provide as you expect - Iāll ask about it.
For context, the ADC samples are captured at a much higher rate than the current profile outputs are provided, so there may not be sufficient communication bandwidth in the serial connection to provide full resolution ADC values as theyāre measured, and the microcontroller likely doesnāt have sufficient memory to buffer the data from an entire transmission.
1 Like
Following up, with the current UART serial approach there would indeed be too much data to stream live (at either 8- or 12-bit ADC resolution), and not enough memory for buffering.
Hi Eliot - great to hear these further details and Iād be very interested in the USB interfaceā¦ Or might it be possible to output the gain and offset values that have been applied to each processed profile so that an approximation to the initial raw values could be back-calculated? Thanks!
Fair enough. Iāve noted that internally, but itās not something we currently have a target timeline for.
The profile messages from the Ping Sonar are for response strengths (to the transmitted pings), not raw acoustic measurements. The ADC samples the vibrations of the transducer (i.e. acoustic measurements), then thereās processing of that signal to get from āseveral sound wave samplesā over a period of time into āone response strength measurementā representing a datapoint within the profile. The number of sound wave samples per profile datapoint changes depending on the profile_data_length and the currently configured profile.scan_length and speed_of_sound.
Iām not sure what the deal is with the offset Patrick mentioned - I assume thatās not something that would change between pings, but Iāll ask to confirm.
Assuming the offset is constant, if your priority is just making the profiles comparable (rather than getting a conversion to a physical unit of sound intensity), then if you turn off āautoā mode each profile datapoint should have the same scaling and number of ADC samples, at the cost of needing to set reasonable values for the gain and scan range by yourself. If the samples per datapoint number isnāt important (Iām presuming the strengths are time-averaged anyway, although that may be incorrect) then you could keep auto mode on and use the profile.gain_setting values (which are already provided in the profile messages) to scale the profile datapoints into some form of comparable āpowerā estimate.
Hi there, I am looking to retrieve the returning echo in terms of a time-domain signal. Inside, the library returns the strength of the returing echo in a normalized range of 0 - 255. However, I want to see the actual time frequency signal which is if i set 750 kHz then that, and the returning one which is the echo.
In another word, I want the original sending pulse, and receiving pulse for each angle.
I dont see function to extract this, however, in ping viewer these signals are displayed. I am adding the image to better explanation. Community help would be great.
Hi @jonathan.w0w, welcome to the forum
Iāve moved your post here, because itās on effectively the same topic (but for the Ping360 instead of the Ping1D). Iād recommend reading through the above messages for relevant context.
The waterfall plot youāve shown is just a mirrored line plot of the normalised profile data reported by the sonar (device_data for the Ping360). Ping Viewer does not have access to some kind of hidden extra functionalities of the device - just the messages covered in the ping-protocol documentation.
Hi @EliotBR - just revisiting this project now. Many thanks for your response. Were you able to confirm the āoffsetā with Patrick?
Thanks!
Hi @animmosmith, the offset are just some initial points that are ignored.
1 Like
Just to clarify this, the āoffsetā is not applied to the values or the distance measurement - itās just the minimum distance thatās considered as valid, in order to ignore the region of saturated signal at the start of each ping (due to the sonar resonating after a transmission).