Ping1D Firmware

Blue Robotics Products Ping Sonar Devices
1

I’m reading back firmware version 3.28 from my Ping1D.

The current firmware version available is 3.29, but I cannot find any description of what has changed between these two versions and hence whether I need to update to the latest version.

I also can’t find any description of the functional difference between the Ping1D and the Ping2 other than the statement that the Ping2 is “more capable”. In what way is it more capable?

Thanks

2

Hi @psupine,

Apologies - there have definitely been some limitations to our communication around these topics, including some inconsistency around our own terminology.

From a previous response:

Come to think of it, that may help to reduce some of your recent power supply concerns…

To clarify terms here:

  • Ping1D is a message set in the ping protocol, intended for 1-dimensional sonar devices (e.g. with a single transducer, currently expected to be echosounders). It can be relevant to multiple different devices, as long as they support the specified functionality
  • “Ping2” was a name we (briefly) called a hardware revision of our Ping Sonar device, before deciding it was more confusing than helpful
    • This is admittedly made extra confusing by the firmware version naming, which we’ve intended to change but haven’t yet completed, partially because doing so would also require updating Ping Viewer’s automatic firmware finding

From the revision history (in the Technical Details section of the Ping Sonar product page), the primary user-related changes are:

3

Hi @Eliot

Ah. Definitely worth trying 3.29 then. I have now managed to avoid the rebooting problem, but the current slamming is still ugly.

–

I knew the more recent version of Ping Sonar changed the transducer to one with a narrower cone, and the FW rev numbering of “Ping2” (from the GIT pages) would seem to indicate a complete firmware rewrite. Are there are no other h/w changes that should matter to me?

The reason I’m asking these particular questions is that yesterday I was writing the discovery code where I read the protocol, device id, device version and firmware versions. But I don’t have any idea of the range of devices and versions that I could expect to support. So far it doesn’t matter because I have (N=1) devices and supporting them all is rather trivial.

Is the most recent protocol still 1.0.0 ? As far as writing the driver, can I just ignore the device and firmware version ? Can I assume that protocol changes will retain backward compatibility?

4

Unfortunately it was just a flawed renaming - both iterations use the same electronics, and I believe the only meaningful change to the firmware is enabling the longer scanning distance (which I’m not convinced should be hardcoded to start with, but the protocol doesn’t currently support changing it, so we have separate releases for now).

There’s no meaningful limit on this, as external companies could introduce compatible but technically distinct devices, with their own firmware versions.

As something of a side note, the protocol mentions a configurable device ID (for differentiating instances of the same device type on a network), but that hasn’t been implemented in the existing Ping Sonar firmware.

The device type is currently the primary indicator of which message set(s) a given device is expected to support. That said, if you know you’re only connecting echosounders then yes, you could currently ignore both the device type and firmware version, although that’s not guaranteed to continue working in the future (e.g. if new features get released, like the auto_transmit functionality that was added to the ping360 message set, and/or if there’s a device introduced that doesn’t support some existing features (perhaps if new features can replace them)).

The open firmware introduces some exciting possibilities around extra, optional capabilities, but there isn’t yet a dedicated mechanism for supporting that, short of trying messages and seeing which ones get affirmative responses.

There could potentially be some convenience to knowing which features a given firmware version supports, without needing to query them. More generally I’m hoping (and actively pushing for) a cleanup of the protocol to better support different capabilities between firmware instances, which could conceivably include a new mechanism/message for requesting the messages the firmware supports…

If there ends up being an expectation that the interfacing code knows about feature support for a given device’s firmware version then your driver may have issues supporting that device.

5

Hi @EliotBR.

Thanks for providing all that extra background.

It looks like the overall message is that it’s a bit of a mess at the moment and that I shouldn’t fret too hard about solving the general case until it’s cleaned up.

I’m somewhat interested in the OSS possibilities of the Pinger hardware and am happy to contribute to that effort at some point. I still have a million coding tasks of my own to work through. << sigh >>

I’m not sure how this would work from a cold start. Suppose that I have 2 Ping1ds on the same bus, both of which think they are device 0. Somehow I have to address one of them to be able to tell it to be device 1. How can I do this?

One option would be to address the unique h/w identifier (UDID), but you’d either have to know it in advance or poke at (part of) it. That would require some kind of collision detection but I’m not sure how that’d work. Pre-reading the UDID for each device plugged in one at a time is the only way I can see this working. The device_id is then assigned as a short handle by addressing the UDID when everything is plugged in together.

This is another topic for another day. (Edit: I’ve got a protocol idea for this now that doesn’t require pre-read)