Raw profile data from Ping1D?

Hi - is it possible to obtain raw (unscaled) profile data from the Ping1D? Thanks!

Hi @animmosmith, welcome to the forum :slight_smile:

Iā€™m not certain what you mean by ā€œscaledā€ data here - if you mean

  1. the profile data that the sensorā€™s ADC collects then
  2. 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 :slight_smile:

Interesting application :slight_smile:

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! :slight_smile:

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 :slight_smile:

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).