Hi guys,
recently purchase the ping360, it works amazing with the pingviewer software provided but not so much with the brping library.
When we run the example code on brping with python. The data field are populated with 200 reading in hex format. We then convert this hex format to decimal and from what we see is the result shows from 0 - 255. We use standard setting that come with the example which is:
+p.set_transmit_frequency(800)
+p.set_sample_period(80)
+p.set_number_of_samples(200)
4 quick questions:
What does this 200 hex value in the data field represent?
If in the case we just want to scan at 30 meter range how do we setup these parameters?
Or at least when we change the range in pingviewer how does these parameter change?
Are you guys gonna keep supporting this product? If not can we submit for a paypal refund?
The reason i ask is because I got reply from the support state simply that āI couldnāt offer more help!ā. This concern me at the consumer end, because it sound like you guys give up on the product.
I know that you guys been working hard to put this amazing product out but help me out here since im not asking for a full documentation ( i know his takes time). I just need to understand how the data been process then me and my team can write up the code for it our self.
Or anyone in the forum have the answer, I am more than happy to listen
This is not the full response you received from Daniel. The full email reads as follows:
Hi Alex,
Thanks for the email.
Right now we donāt have any documentation to interpret the raw data array that represents the echo strength. Weāve opened up an issue to better document that and provide some examples on how to use the device data, you can follow the progress on that here: Improve examples to teach how to use the profile data Ā· Issue #77 Ā· bluerobotics/ping-python Ā· GitHub
Sorry I couldnāt be of more help! Let me know if you have any questions.
Best regards,
Daniel explains that although we do not currently have detailed documentation, we are working on fully documenting the protocol, and links to an open issue where you can track the software teams progress on this documentation. Iām sorry if the response was unclear in any way!
Note the āBETAā tag on the on the product page, along with the following explanation:
Note: The Ping360 scanning sonar is currently in beta. Itās well-tested and we are confident in the hardware design, but we intend to improve the features and performance with software updates in the near future.
There a lot of work that went into the Ping360 hardware, firmware, and Pingviewer, and there is still more work to be done. As the āBETAā tag explains, we are fully confident in the current hardware, and the software is in a state where it is fully usable and core functionality (ie navigation and object/range finding in a traditional human readable interface) is solid. However, we are still in the process of fully documenting everything and adding more niche features for specific applications. We feel it is more important to get a product out earlier and in the hands of users while it is perfectly adequate for 98% of use cases, rather than holding it back excessively long to add more software features that are not necessary for most users.
I apologize if this āBETAā tag is unclear or gave you any false impressions, we try to be as clear as possible with our product description so customers know what to expect.
Rest assured that we are fully committed to supporting all our products, hardware and software, over the long term. I believe the open nature of our platform and constant updates to all our software including ArduSub, Companion, and QGC over the past several years demonstrate that. The Ping echosounder has already received a couple firmware updates since launch, and we are currently working on further updates to improve functionality.
Some updates and documentation simply take time to implement- the Ping360 launched barely two months ago, I believe for the most part we have been focusing on improving Pingviewer stability across multiple operating systems and various hardware configurations since then.
I am not familiar with the inner workings Ping360 and software myself, but perhaps @patrickelectric or @williangalvani can help answer some of your technical questions.
If you are unhappy with your Ping360, please contact sales@bluerobotics.com with your order number if you would like to proceed with a return.
8 bit binary data array representing sonar echo strength
This array [of size N] represents the N points equally spaced between the sensor transducer and the range that the sensor is configured to scan. E.g:
For a range of 2m or 2000mm, using a scan of 200 points, each index of the vector [i] will represent i*2000/200 mm, where:
data[0]; // 0mm
data[1]; // 10mm
...
The value of each points is normalized inside the 0-255 range, where 255 is the maximum power decoded by the A-D converter.
/** This is a pseudocode example **/
// This is the default mode for now
transducer_message.set_mode(1);
// The desired gain [0-2]
transducer_message.set_gain_setting(gain);
// Set the transducer position in gradian [0-400]
transducer_message.set_angle(angle);
// Signal transmitted duration between 1-1000ĀµS
transducer_message.set_transmit_duration(transmit_duration);
// Time interval between individual signal intensity samples in 25ns
// increments (80 to 40000 == 2 microseconds to 1000 microseconds)
transducer_message.set_sample_period(sample_period);
// Acoustic operating frequency, frequency range is 500kHz to 1000kHz,
// but 740 is a good practical frequency for different scenarios
transducer_message.set_transmit_frequency(transmit_frequency);
// Number of samples per reflected signal [200-1200]
transducer_message.set_number_of_samples(num_points);
// Value that set the transition request [0, 1]
// if you want a profile this should be 1
transducer_message.set_transmit(transmit);
Now, different from Ping1D, Ping360 has a low abstraction level for the sensor functionality, making it super flexible if someone wants to do some specific tasks and magic tuning.
But, if you just want to do a normal scan like PingViewer, some math and knowledge of how the sonar work is necessary, E.g:
For a 30m with 1200 points, low gain and the head position at 180Āŗ | Ļ rad |200įµ.
/*
From the documentation:
_firmwareMinTransmitDuration = 5;
_firmwareMaxTransmitDuration = 500;
_samplePeriodSickDuration = 25e-9;
*/
num_points = 1200; // 1200 points
gain = 0; // Low gain
angle = 200; // 200įµ
transmit_frequency = 740; // Default frequency
/* Calculate the sample period and transmit duration
for a specific range */
range = 30; // 30m range
sample_period = calculateSamplePeriod(range);
transmit_duration = adjustTransmitDuration(range);
// Create the transducer message now with the new values
...
And here is a simple example of such functions:
/**
* @brief Calculate the sample period based in the new range
*
*/
float calculateSamplePeriod(distance)
{
return 2*distance/(num_points*speed_of_sound*_samplePeriodSickDuration);
}
/**
* @brief Adjust the transmit duration for a specific range
* Per firmware engineer:
* 1. Starting point is TxPulse in usec = ((one-way range in metres) * 8000) / (Velocity of sound in metres
* per second)
* 2. Then check that TxPulse is wide enough for currently selected sample interval in usec, i.e.,
* if TxPulse < (2.5 * sample interval) then TxPulse = (2.5 * sample interval)
* 3. Perform limit checking
*
* @return Transmit duration
*/
float adjustTransmitDuration(distance)
{
// 1
transmit_duration = 8000 * distance / _speed_of_sound);
// 2 (transmit duration is microseconds, samplePeriod() is nanoseconds)
transmit_duration = max(2.5*samplePeriod()/1000, duration);
// 3
return max(_firmwareMinTransmitDuration, min(transmitDurationMax(), transmit_duration));
}
/**
* @brief The maximum transmit duration that will be applied is limited internally by the
* firmware to prevent damage to the hardware
* The maximum transmit duration is equal to 64 * the sample period in microseconds
*
* @return The maximum transmit duration possible
*/
float transmitDurationMax()
{
return min(_firmwareMaxTransmitDuration, samplePeriod() * 64e6);
}
/**
* @brief Sample period in ns
*
* @return double
*/
float samplePeriod()
{
return sample_period*_samplePeriodSickDuration;
}
I believe that Adam has answered that in the previous post.
If you are facing problems do understand what is the profile and how to interpret the data, this documentation can also help:
Please, let us know if you have any further question, we are always improving our documentation with examples and our libraries with higher abstraction layers. But for now, we are still working to improve Ping360 usability for people that donāt want to deal with the sonar math and logic.
Hi Adam,
Sorry about the confusion that i cause,
The reply you quote was for Alex, not me (Khang@ydt.com.au), where he ask Alex have any more question for him. On my reply it end at āSorry I couldnāt offer more helpā.
I notice the BETA tag and have no doubt in the quality of the hardware that your awesome team put together, we have been a long time customer with you guys and have to say that the quality is fantastic. But i did not aware that software support classified as āfeatureā or āperformanceā. I think i misunderstood the BETA tag.
