Windlasses in the Signal K schema

[preeve9534]

The proposal for an N2K Windlass Network Messages protocol has now firmed up so the data values used to describe a windlass in at least N2K world are now known and amenable to working into the Signal K framework.

At the moment the top-level schema in the specification doesn't seem to have an obvious root under which windlass objects would fit - I wonder if they constitute a top-level entity? In natural language semantics, a windlass is a type of hoist, but it would seem to me rather pedantic to adopt 'hoists.windlasses.' as a root, but I can see 'windlasses.numeric-id' working (in N2K derived data numeric-id would simply be the windlass instance number).

I have a project which will need access to windlass data, so I'm happy to kick this discussion off if that seems appropriate and wouldn't step on other toes.

[sbender9]

Hmm... good question.

In theory you could have similar data on winches. Where would that go? "hoist" would make sense for a halyard, but maybe not for a jib sheet?

[preeve9534]

I guess a windlass is a type of (horizontal) winch and a capstan is a type of (verical) winch. If it weren't for N2Ks use of the term windlass for the specific anchoring role and popular usage amongst nautical types then I would probably be saying just use the term winch for everything. Maybe:

winches
    + windlasses
           + *n*
    + capstans
           + *n*
    + hoists
           + *n*
    + *n* (for general line handling winches - jibs, halyards and so on)

[sbender9]

Works for me.

[preeve9534]

Some ideas for winch properties:

   currentState: enum( 0 | 1 | 2 ) - meaning ( "Stopped", "Retrieving", "Deploying" ), required
   currentSpeed: natural - winch operating speed (if known) - may be one of the ids in available speeds

   inService [ 0 | 1 ] [ "no", "yes" ]
   availableSpeeds: [
       {
         id: natural - speed identifier
         speed: real - this speed's nominal handling velocity in m/s
       }
   ]
   powerType [ "manual", "electrical", "hydraulic" ]

A consumer of currentState with access to other properties can compute deployed/retrieved line length, run time and so on.

[sbender9]

Take a look at the current spec. I would make some changes.

No need use the word "current". Just use "state" and "speed". For example, we use "navigation.position", not "navigation.currentPosition"

Enums are always strings and all camelCase. So "stopped", "retrieving", etc. no numbers, they're not human readable. We haven't really settled on booleans yet. I'm ok with 0 or 1 or "yes" or "no", but pick one.

availableSpeeds and powerType should be meta data since they are static and never change.

[preeve9534]

Ok. So we don't get our heads at odds around sketching out and drafting, I've expressed the ideas above in what might be something near spec style. See attached. I have not considered windlasses / capstans yet.

I was unsure how to deal with the level under winches where the key options are "windlasses", "capstans" or n (a similar situation exists in Signal K under "electrical.switches.", but I couldn't seem to find the spec for that).

So, noting that the Signal K spec uses a general alphanumeric pattern in places where an instance number might go, I have followed suit. Do I need to elaborate the regex at this top level so that it disallows "windlasses" and "capstans".

Hope this makes sense.

winches.json.zip

[preeve9534]

A stab at some extra properties specific to a windlass.

"windcapProperties": {
      "title": "Properties specific to a windlass or capstan",
      "description": "Properties which characterise a windlass or capstan, over and above a winch",
      "type": "object",
      "properties": {
        "deploymentState": {
          "description": "Windlass/capstan rode deployment state",
          "type": "string",
          "enum": [ "docked", "nearlyDocked", "deployed", "fullyDeployed" ]
        },
        "rodeType": {
          "description": "Currently detected rode type",
          "type": "string",
          "enum": [ "rope", "chain" ]
        },
        "rodeCounter": {
          "description": "Rode counter value in metres",
          "units": "m",
          "$ref": "../definitions.json#/definitions/numberValue"
        },
        "lineSpeed": {
          "description": "Rode deployment speed",
          "units": "m/s",
          "$ref": "../definitions.json#/definitions/numberValue"
        }
      }
    }

[preeve9534]

It would be useful to include some property which relates to power supply quality. This is crudely addressed in the N2K windlass protocol status report PGNs, but only for electrically operated windlasses. I think that the property actually associates with a winch and it might be that a simple:

powerSupplyCondition: [ "normal" | "overVoltage" | "underCurrent" | "lowPressure" | ]

Would be enough.

I scanned the spec to see if this had been dealt with elsewhere, but couldn't find a good match. Does anyone know if there is anything in there already or anything in the pipeline?

[preeve9534]

lastOperation should use "deploy" and "retrieve" rather than "in" and "out".

[preeve9534]

Is this worthy of a fork?

[tkurki]

I think this is worth heeding: https://github.com/SignalK/specification/pull/596/files#diff-0da48234b7539142bfd25b4e7e5883c10f17d37d54228d72720a7d3bd2849118R17-R19

Move the essentially arbitrary WINCH type name out of the path and into meta information so that tank keys are just arbitrary ids and the type separately in the data model

Not being a native maritime english speaker I don't see much value between being able to tell windlass from a capstan, but I give you the benefit of doubt on that. However I would like to automatically add an anchor icon in a hypothetical UI to the anchor winch, without knowing that I need to look for both windlasses and capstans.

Having said that: all classifications are wrong, but some are more useful than others - no need to go into analysis paralysis, but let's give this a decent amount of thought.

PS Pull Request with some added JSON or just copypasted formatted in a comment is vastly easier to grok than a zipped json attachment with .draft ending. Read it in browser, read it in email on a phone, nothing to download, nothing to unzip, nothing to doubleclick and not have opened in an editor...just saying.

PS2 JSON schema is hard to read and write - I find it more fruitful to discuss the schema additions in outline form first.

PS3 Thanks for opening the discussion and the effort so far!

[preeve9534]

Hello Teppo,

Ironically, it was my comment on the spec v2 thread that suggested taking the arbitrary tank names away and into meta data. However, in this winches proposal I was trying to conform to the style of v1 and so avoid opening myself to the charge of drifting away from current norms. I'm more than happy to take my own recommended route with winches.

My personal tendency is to call that thing at the front of my boat the anchor winch, but then I get picked up on that from time to time. However, the terms "windlass" and "capstan" are in widespread use and I think are helpful because of the semantics around drum orientation which in my view is probably not worth capturing as a winch property but is worth retaining as an aid to comprehension.

Given all of that, I'm happy with the form:

winches id*

My feeling is the user can be expected to apply due diligence with values in (say) a winches.id.meta.type": [ "generic" | "windlass" | "capstan" | "hoist" ] if they want, for example, to display an anchor icon. Also, I think the issue of what ground tackle (or anything else) a winch operates is outside the domain of the winch specification per-se and somewhere up in the realm of application knowledge. Your use case example is, in any case, I think invald: I have sailed on ships where there have been windlasses or capstans dedicated to raising and lowering spars so one cannot make the assumption "windlass -> anchor".

Re PS. Pull request. See my previous post. I did not want to make a gratuitous entry into schema world without some feedback from the maintainers about whether or not this extension activity is welcome; whether or not it was already under development and so on. So, I was reluctant to start issuing pull requests without some sort of heads up. Completely agree re utility, ease of use and so on, so taking your and Scott's engagement as a heads up I'll proceed as you suggest.

Re PS2. Well. I started this thread with outline stuff and, probably mistakenly, felt I was being encouraged to tighten up. So, I tightened up, checked the JSON specs, and as much for my benefit as anything else recast the informal as a JSON draft. Don't really care one way or another how we move forwards, but consistent guidance on project working style is helpful. This isn't a criticism, just an observation.

Re PS3. You are most welcome!

On Mon, 7 Dec 2020 at 19:31, Teppo Kurki notifications@github.com wrote:

I think this is worth heeding: https://github.com/SignalK/specification/pull/596/files#diff-0da48234b7539142bfd25b4e7e5883c10f17d37d54228d72720a7d3bd2849118R17-R19

Move the essentially arbitrary WINCH type name out of the path and into meta information so that tank keys are just arbitrary ids and the type separately in the data model

Not being a native maritime english speaker I don't see much value between being able to tell windlass from a capstan, but I give you the benefit of doubt on that. However I would like to automatically add an anchor icon in a hypothetical UI to the anchor winch, without knowing that I need to look for both windlasses and capstans.

Having said that: all classifications are wrong, but some are more useful than others - no need to go into analysis paralysis, but let's give this a decent amount of thought.

PS Pull Request with some added JSON or just copypasted formatted in a comment is vastly easier to grok than a zipped json attachment with .draft ending. Read it in browser, read it in email on a phone, nothing to download, nothing to unzip, nothing to doubleclick and not have opened in an editor...just saying.

PS2 JSON schema is hard to read and write - I find it more fruitful to discuss the schema additions in outline form first.

PS3 Thanks for opening the discussion and the effort so far!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/600#issuecomment-740131516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2BPMMOGOG2ZGV67VBZLNTSTUURTANCNFSM4UONYLBA .

-- Paul Reeve

Email: preeve@pdjr.eu UK mobile: +44.7786.528092 NL mobile: +31.630.242748

[preeve9534]

@tkurki - I just created a draft pull request in a new winches branch reflecting your and Scott's comments above. Hope that was what you expected. If not...

[tkurki]

Hmm where?

[preeve9534]

There now.

On Wed, 9 Dec 2020 at 18:56, Teppo Kurki notifications@github.com wrote:

Hmm where?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SignalK/specification/issues/600#issuecomment-741979283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE2BPMJSZ347FAPOFCJEFH3ST7B7TANCNFSM4UONYLBA .

-- Paul Reeve

Email: preeve@pdjr.eu UK mobile: +44.7786.528092 NL mobile: +31.630.242748