Some initial data (from three trials of each) - Ping360 via ethernet connection:
| Angular Step Size [gradians] | Distance [m] | Sample Period [ticks] | Transmit Duration [us] | Ping Viewer avg. time [s] | Python avg. time [s] | Python slower by |
|---|---|---|---|---|---|---|
| 1 | 2 | 88 | 11 | 10.74 | 11.80 | 9.84% |
| 1 | 20 | 888 | 107 | 20.57 | 21.61 | 5.04% |
| 1 | 50 | 2222 | 267 | 37.6 | 38.42 | 2.17% |
| 10 | 2 | 88 | 11 | 3.29 | 3.29 | 0.00% |
| 10 | 20 | 888 | 107 | 4.19 | 4.32 | 3.18% |
| 10 | 50 | 2222 | 267 | 5.89 | 6.01 | 1.98% |
On average, Python was 3.70% slower (so, measurable, but not too bad).
Common testing parameters:
| parameter | value |
|---|---|
| gain | 0 (low) |
| sector angle | 360 degrees |
| speed of sound | 1500 |
| transmit freq | 750kHz |
| number of samples | 1200 |
I would note that the update to 0.1.2 included this PR, which provided a 27% speedup for a Ping360 (tested on a 2M baud USB-serial connection), so performance-wise that update is quite important for ping-python being anywhere close to the C++/Ping Viewer performance.
I should be able to change my interface over and do some USB-serial tests next week ![]()