Home        Store        Learn        Blog

Can Arduino get raw sampling data array of 1D sonar?

Hello there. I’m using 1D Ping Sonar Altimeter and Echosounder.
Ping viewer and Arduino sample program (ping1d-simple.ino) provided by Blue Robotics official successfully worked and I can get distance and confidence by Arduino.

Now I want to get whole sampling data received by sonar. I think distance and confidence are the data obtained by processing raw echo intensity data array such as “time 0: intensity 0.1, time 1: intensity 0.15, …, time M: intensity 1.0(when wave came), …, time N: intensity 0.0 (end of sampling)” received by sonar in predetermined sampling rate.

So, my question is can I get raw received data array of sonar by Arduino?
I understand “if(!request(Ping1DNamespace::Some_function))” function in Arduino sample code which is called when user want to treat Some_function data. If there is the way, which function I should specify for getting raw echo intensity data (I thought “Continuous_start” may be related because of the name, but I could not understand what continuous_start truly means and use it)?

Any advice here is greatly appreciated. Thanks!

Hi @ken555, welcome to the forum :slight_smile:

The full intensity data from a profile is provided in the profile’ message. There’s an example of requesting and receiving that in the ping1d-advanced.ino example, but it’s commented out by default because it may not work fully/correctly using software serial (I’m unsure if that still applies, but it should definitely at least work for hardware serial).

The continuous start message is used to start a continuous stream of profile messages from the sensor, that can then be actively read in and processed by the program. I had a look around and it doesn’t seem like there’s a convenient way to receive the results using ping-arduino, because the request method sends a message and waits for a single response, and the read and waitMessage methods (which could be used to receive subsequent profiles in the stream) are both declared as private.

More generally, I’m not sure how well an Arduino would be able to handle a continuous stream of profiles - it may be better for it to request them as required anyway. If you’re using an Arduino (e.g. Mega) with hardware serial and 115200 baud and finding that repeated requests are too slow for your use-case you could potentially move the waitMessage declaration to public and then use the continuous streaming functionality, but definitely try just repeated requests first :slight_smile:

Dear @EliotBR
Thank you for your quick and detailed advice!
The difference between HardwareSerial and SoftwareSerial is very interesting. Actually, I tried to get profile message, but it failed despite Arduino seemed to get some serial data. It might related to the loss of SoftwareSerial and private class.
I haven’t tried the improved version yet, but I’ll try it in the next few days.
Thank you so much!

1 Like

I spoke with our software team this morning re baud rates and software vs hardware serial - there’s something of an update on that here:

If you’re using features that require 115200 baud or long messages then it’s still recommended to use hardware serial. Software serial may work at that speed, but is apparently known to be somewhat unreliable above 9600 baud, and in particular has issues with long messages (like profile data) or if there’s much other code running in the same program.

Just the normal request(Ping1DNamespace::Profile) approach shouldn’t have any issues with private declaration, because request is declared public. There may be issues with Software serial though, as mentioned in my comment above, and in the code :slight_smile: