bluerobotics / ping-firmware

Repository for binary files associated with ping devices

Repository for Ping family firmware

ping-firmware's Issues

Don't report distance if there is no confidence

Right now the sensor tries to fix in any possible distance/measure, this should be avoided, the sensor should only report distance when it has the confidence that there is a real tracking point.

We may want to report distance 0 if it's invalid.

For more information:
https://discuss.bluerobotics.com/t/ping-sonar-operating-out-of-range/7903

Allow the user to disable automatic/period scan for track algorithm.

This functionality can break the functionality for users that want the sensor only to provide profiles.

Feature: increase resolution

Send 1000+ samples instead of a fixed 200

Ping: Add raw data output

Add set transmit duration

In manual mode, we should be able to control the transmit duration

Don't report 100% confidence with a saturated signal

Discussion in this forum thread

I’m unsure what the algorithm does when faced with a saturated signal (a peak with multiple full intensity values in a row, giving a flat top) - it may choose the first top value, or the middle one, or may use the derivatives to try to estimate where the actual top is most likely to be, or something else. Saturated signals are very difficult to calculate meaningful results from, because there’s a lot of missing data (it’s like looking at a photo of a mountain, but the top is cropped off - how can you tell where the peak is?).

... 100% confidence doesn’t seem very logical when a peak is effectively impossible to find in a region of saturated data ...

Add continuous output of distance and distance_simple

nack after request profile (1300)

On 3.26, sending a request (id 6) with a requested id for profile (1300), the response is a NACK with a message: 'bad continuous request id`.

The expected result is to receive a profile message and no nack.

Here is a saelae capture demonstrating the exchange:
example.zip

Auto gain feature is surprisingly slow

When using the auto gain feature the incoming ping stream becomes quite jerky, and and the maximum data rate slows significantly. Ideally auto gain would consume negligible time, especially when the return confidence is high - if it's getting a strong response then it's unlikely it would need to change anything.

As some numbers, on my desk the received data with auto mode on is at ~2kB/s, and manual mode with exactly the same setup is at ~6kB/s. Some amount of slowdown may be reasonable, but a 3x performance hit is quite unexpected, particularly given the confidence is at 100% so the scan range is barely changing. This seems likely to be a bug.

Screen.Recording.2022-10-28.at.11.34.30.am.mov

set default src_id to 1

Ping: Add raw signal output

Ping: add support for NMEA mode output

update for common message protocol compliance

Update to be compliant with the new revision of the common messages

Add ci + automatic deployment

Ping: Fix sensor response with high request rates

From ArduPilot/ardupilot#11321 (comment)

Support device ID filtering

The message format includes fields for receiver and sender IDs, but using them is documented as "not currently implemented", and they just get hardcoded to 0.

This is a valuable feature for people wanting to communicate with multiple devices on the same bus, as raised in this forum thread.

This seems conceptually straightforward to implement, with a msg.dst_device_id in (0, 255, self.device_id) check in the receiving code, and including the sender ID if there is one set, although full support would require also updating Ping Viewer and the various ping libraries to make use of the feature.

Add synchronous transmission capability

It will be nice to have some way to tell the device exactly when to transmit, and to be able to operate several devices in synchronization to prevent interference.

Disable distance track algorithm.

This is not necessary and can result in problems when people use ping as a pure profile sensor.

Fix `distance` messages to match spec

Currently the ping_number field is left at 0 for get_distance, and is set to the request number for get_profile, whereas the docs say it's the pulse/measurement count, which should continue counting even while no messages are being requested.

EDIT: re-tested with Ping-V3.29.0_auto and the number seems to be correct, just not currently set in the distance messages. Not sure whether I originally tested an earlier firmware version, or if I was just mistaken about it being set to the request number 🤷‍♂️

This seems like it should be quite straightforward to implement with a global count variable that's incremented whenever the device pings, and gets accessed when packing the messages that send it.

Issue raised in this forum post, and I've verified (using ping-python) both the "count profile requests instead of pings" behaviour and that the distance.ping_number field is consistently returned as 0 values.

Ping: respond to every message

Ping: Document sensor operation

Things like state at boot, request logic, manual vs auto mode, continuous output etc.

Adding Baud Rate Adaptive Function

It is known that the recently launched STM32 has supported the baud rate self-control capability, considering adding corresponding items in the protocol.

You can wait for a specific frame after opening.

The function is restarted after successive frame errors.

According to the requirement of the first data enabled by stm32, we can consider adding a specific character header, which will be automatically ignored in the original protocol.

Default device_id value to 1

The convention will be that the default device id matches the DEVICE TYPE.

Ping: Add valid parameter ranges to protocol spec

place null terminator in every string

Some strings are returned without a null termintator.