Hello, questions and suggestions.

[Mike]

Hi all

I've been developing a very similar project for some time now but found your group recently - actually I emailed Rob a year or so back and exchanged a few emails, but got sidetracked on actually building the boat (http://captainunlikely.com) rather than writing software. As specifications, like sex, are better when done with other people, I'm now in the process of switching my server across to using the Signal K message format as documented at http://signalk.org/specification/index.html#schemas/signalk.json. And I've got quite a few questions as a result, and a few suggestions.

I apologise if some of these have come up already in past emails, if so feel free to point them out.

1. $VESSEL.design.name - this is described as "the common name for the sensor", which I guess is a copy/paste error. Is this the AIS "Ship Type" field from AIS Type 5 message - so would have values like "Trawler", "Bulk carrier" and so on?

2. AIS vessel dimensions are missing - although you have LWL and beam, the actual fore/after/port/starboard dimensions are important. Imagine a half-mile long supertanker, with the antenna at the stern - simply knowing the LWL isn't enough to know where the boat ends and clear water begins. I'd suggest adding a "$VESSEL.design.bounds" array with four items, [<distance to bow> <distance to starboard> <distance to stern> <distance to port>], i.e. the dimensions moving clockwise around the ship. All of that information is available from an AIS Type 5 message.

3. AIS transponder class - A or B. This is useful because it could give some indication of what sort of information is available and how often it's updated. I'd suggest a new "$VESSEL.communication.aisclass" key with a value of "A" or "B"

4. In the $VESSEL.communication.gnss object, I can only list the number of satellites, not their ID, elevation and azimuth (which I concede isn't that important, but is kind of neat to plot). I'm also not clear if it's number of satellites in use for a fix, or number of satellites visible.

5. AIS vessel IMO number - the unique number for commercial shipping, is absent - suggest a new "$VESSEL.communications.imo" field (a string). Again this is extracted from AIS Type 5 message.

6. You have a "$VESSEL.environment.airPressureChangeRateAlarm" field, but no "airPressureChangeRate". Is this deliberate because the intention is for the server to not keep track of state? Generally I think that's a good idea, but air pressure is one of those things in which the change over time is more useful than the actual value. If I turn up to the boat and turn on the UI ready for the days sailing I won't have any air pressure history even though my server has been monitoring the barometer all night. This seems a shame, especially if it's dropped 6 bar in the last hour.

7. If you're going to wire up your boat with enough sensors to require a schema, you're going to have a thermometer in your cabin! Yet although I have "waterTemp" and "airTemp", there is no "cabinTemp". Suggest an "$VESSEL.environment.cabinTemp" field.

8. Suggest a new "intrusionAlarm" entry in the "alarms" datastructure - again, same logic as for cabin temperature, if you're going to wire your boat up with custom circuits everywhere there's going to be a reed switch on the main hatch...

9. Suggest a new field "$VESSEL.steering.mastAngle", for those of us with rotating masts. If you have a masthead wind direction sensor, this has to be corrected with the mast angle, so this information will typically be available.

10. You haven't got any data structure describing the electrical system on the boat. Coincidentally this is what I've spent most of the last six months on. I'm happy to draft a proposed structure for this - as well as battery capacity, charge state, current and voltage, there should be a facility to monitor each circuit on the boat (if available), so you can switch on/off cabin lights from your GUI, can see how much current your fridge is drawing and so on.

Overall it looks really good, and I'm looking forward to being able to throw my server into the pot of available implementations once it's cleaned up a bit.

Cheers... Mike

[rob...@42.co.nz]

Hi Mike,

Yes by all means join and contribute. I added some comments below, but in the last few days we have made some significant advances in the model, security, and handling of alarms and metadata. See https://github.com/SignalK/specification/wiki/SignalK-Data-Model

We still need to finalise these changes but they solve a number of long-standing issues like multiple values for the same datapoint, and your comments are welcome.

We do a lot of discussion on slack.com at present, hence the forum is quiet. I will send you an invite separately

Rob

On Sunday, February 1, 2015 at 5:35:17 AM UTC+13, Mike wrote:

Hi all

I've been developing a very similar project for some time now but found your group recently - actually I emailed Rob a year or so back and exchanged a few emails, but got sidetracked on actually building the boat (http://captainunlikely.com) rather than writing software. As specifications, like sex, are better when done with other people, I'm now in the process of switching my server across to using the Signal K message format as documented at http://signalk.org/specification/index.html#schemas/signalk.json. And I've got quite a few questions as a result, and a few suggestions.

I apologise if some of these have come up already in past emails, if so feel free to point them out.

1. $VESSEL.design.name - this is described as "the common name for the sensor", which I guess is a copy/paste error. Is this the AIS "Ship Type" field from AIS Type 5 message - so would have values like "Trawler", "Bulk carrier" and so on?

**The design section is a preliminary holder, so we have yet to answer these question fully. I think the design name is maker-model, but a class would be useful

2. AIS vessel dimensions are missing - although you have LWL and beam, the actual fore/after/port/starboard dimensions are important. Imagine a half-mile long supertanker, with the antenna at the stern - simply knowing the LWL isn't enough to know where the boat ends and clear water begins. I'd suggest adding a "$VESSEL.design.bounds" array with four items, [<distance to bow> <distance to starboard> <distance to stern> <distance to port>], i.e. the dimensions moving clockwise around the ship. All of that information is available from an AIS Type 5 message.

**As above

3. AIS transponder class - A or B. This is useful because it could give some indication of what sort of information is available and how often it's updated. I'd suggest a new "$VESSEL.communication.aisclass" key with a value of "A" or "B"

**As above, and maybe an issue on github

4. In the $VESSEL.communication.gnss object, I can only list the number of satellites, not their ID, elevation and azimuth (which I concede isn't that important, but is kind of neat to plot). I'm also not clear if it's number of satellites in use for a fix, or number of satellites visible.

** add an issue to the spec on github, and maybe propose a structure

5. AIS vessel IMO number - the unique number for commercial shipping, is absent - suggest a new "$VESSEL.communications.imo" field (a string). Again this is extracted from AIS Type 5 message.

**github again
 

6. You have a "$VESSEL.environment.airPressureChangeRateAlarm" field, but no "airPressureChangeRate". Is this deliberate because the intention is for the server to not keep track of state? Generally I think that's a good idea, but air pressure is one of those things in which the change over time is more useful than the actual value. If I turn up to the boat and turn on the UI ready for the days sailing I won't have any air pressure history even though my server has been monitoring the barometer all night. This seems a shame, especially if it's dropped 6 bar in the last hour.

** the current alarms structure is not workable long term, see the new structure at https://github.com/SignalK/specification/wiki/Metadata-for-Data-Values

7. If you're going to wire up your boat with enough sensors to require a schema, you're going to have a thermometer in your cabin! Yet although I have "waterTemp" and "airTemp", there is no "cabinTemp". Suggest an "$VESSEL.environment.cabinTemp" field.

** See metadata and multiple values doc

8. Suggest a new "intrusionAlarm" entry in the "alarms" datastructure - again, same logic as for cabin temperature, if you're going to wire your boat up with custom circuits everywhere there's going to be a reed switch on the main hatch...

9. Suggest a new field "$VESSEL.steering.mastAngle", for those of us with rotating masts. If you have a masthead wind direction sensor, this has to be corrected with the mast angle, so this information will typically be available.

** add issue on github

10. You haven't got any data structure describing the electrical system on the boat. Coincidentally this is what I've spent most of the last six months on. I'm happy to draft a proposed structure for this - as well as battery capacity, charge state, current and voltage, there should be a facility to monitor each circuit on the boat (if available), so you can switch on/off cabin lights from your GUI, can see how much current your fridge is drawing and so on.

** A couple of our members are doing this now on slack, so if you join slack you can help out?

[Tim Mathews]

On 01/31/2015 11:35 AM, Mike wrote:

1. $VESSEL.design.name - this is described as "the common name for the sensor", which I guess is a copy/paste error. Is this the AIS "Ship Type" field from AIS Type 5 message - so would have values like "Trawler", "Bulk carrier" and so on?

Like Rob said, I think this is the model of the boat, e.g. Catalina 27 or some such and not the AIS classification.

4. In the $VESSEL.communication.gnss object, I can only list the number of satellites, not their ID, elevation and azimuth (which I concede isn't that important, but is kind of neat to plot). I'm also not clear if it's number of satellites in use for a fix, or number of satellites visible.

GNSS info is definitely incomplete. I started work on this a while ago, but never really followed up. If you want to own this, I can send you what I've got, but it predates the JSON-schema style documentation, so I'm not sure how much use it would be. Was basically a transliteration of the N2K PGNs specific to sat nav.

9. Suggest a new field "$VESSEL.steering.mastAngle", for those of us with rotating masts. If you have a masthead wind direction sensor, this has to be corrected with the mast angle, so this information will typically be available.

Mast angle would be useful. There isn't anything like it in the NMEA 2000 standard (that I'm aware of), so that would be something we have on them. :-)

10. You haven't got any data structure describing the electrical system on the boat. Coincidentally this is what I've spent most of the last six months on. I'm happy to draft a proposed structure for this - as well as battery capacity, charge state, current and voltage, there should be a facility to monitor each circuit on the boat (if available), so you can switch on/off cabin lights from your GUI, can see how much current your fridge is drawing and so on.

Al Thomason has been working on this, specifically related to DC electrical systems. See https://github.com/SignalK/specification/pull/52 for more info. I've also been working on this, focusing more on AC systems. See https://github.com/SignalK/specification/pull/52.

-Tim

[Mike Bremford]

Thanks guys - I'm now signed up to slack.com and will continue conversation there once I absorb what's been going on.

-----------------------------------------------------
Mike Bremford - CTO                   mi...@bfo.com
Big Faceless Organization             http://bfo.com

--
You received this message because you are subscribed to the Google Groups "Signal K" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signalk+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Wetmore]

Could you send a general invite to the list for where you are discussing SignalK on slack.com?  I had missed that this forum was dormant.

alex

---

From: sig...@googlegroups.com <sig...@googlegroups.com> on behalf of rob...@42.co.nz <rob...@42.co.nz>
Sent: Saturday, January 31, 2015 1:39 PM
To: sig...@googlegroups.com
Subject: Re: Hello, questions and suggestions.

 

[Al Thomason]

Mike,

 

Great.  Looking forward to having you help me out J

 

 

-al-

 

 

 

Viking Star

45' Monk Sr. / McQueen

mvVikingStar.blogspot.com

 

From: sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Mike Bremford
Sent: Monday, February 02, 2015 10:20 AM
To: sig...@googlegroups.com
Subject: Re: Hello, questions and suggestions.

 

Thanks guys - I'm now signed up to slack.com and will continue conversation there once I absorb what's been going on.

[rob...@42.co.nz]

Alex,

The forum isnt dormant, just unloved - we have been 'slack' so to speak.

The use of slack was to allow us to chat offline while we worked on things, so we could co-ordinate. We didnt want to fill the forum with large amounts of irrelevant chatter. But it swallowed our attention and we need to attend to the forum too.

I will work with the others on some policy for forum vs slack, as it would be counter-productive to add all the forum members. I'm not sure if you can read us publicly, try https://signalk-dev.slack.com.

I will contact you privately re an invite

Rob

[Bob Easterday]

I too would like an invite to the slack group. I'm developing a signalK-centric App for iOS and have a few questions. 

[sc...@scottbender.net]

You don't need an invite: http://slack-invite.signalk.org