Enhancement: Alerting system via NMEA 0183 to build a low-budget rescue information by hardware

[TomKeepCalm]

I was looking for a cheap solution to build a simple but effective "person over board" info-system by the person it is over board :-)
The idea was to use a radio bell like this:
https://www.ebay.de/itm/363012447777

I was able to locate the connection between the receiving chip and the logic chip, disconnect it and use a level shifter to connect it to an input and output pin of a Raspi. Now I have 2 devices, so to speak. One which recieves the code from the bell button, up to 300m! and one which can issue visual and acoustic alarms. If anyone is interested in it. I'm happy to provide information. So much for the hardware.

What I did next is automatically generate a mob notification in SignalK via Node-Red when the code was received. This method could also be used, for example, to switch off an autopilot if the boat is alone now ;-)

But I would like to have this information in AvNav for info or, for example, the mob alarm from AvNav in Signalk to start the acoustic signal from the bell.

I think the easiest way to implement this would be bidirectional communication with NMEA0183 sentences. I have already created an issue for the way out of SignalK:
SignalK/signalk-to-nmea0183#89

Sorry for the long text :-)

[wellenvogel]

Very interesting part.
Not sure which would be the right way to go. I will try to integrate at least reading of some SK notifications when directly being connected to AvNav. Writing is a bit more complex as it requires authentication at the SK server.
Already discussed a bit with the K guys - and for now maybe there is a t least an easy solution for co-located SignalK (i.e. on the same machine).
The problematic part is the quitiing of alarms. I have to crosscheck if the current model of alarm quitting in AvNav fit's to the SK notification schema.
For NMEA - maybe the MOB sentence would be interesting - https://www.nmea.org/Assets/21030814%20nmea%200183_man%20overboard%20notification_mob_sentence%20amendment.pdf
Not sure what the status is and how much implementations are available.
What you currently could do to send notifications from AvNav towards SK is to use the AvNav commands (as every alarm triggers a command). See e.g. #141

[TomKeepCalm]

Thanks for your fast reply!
Some thoughts:

MOB sentence sounds good :-)

I find some other sentences here: https://gpsd.gitlab.io/gpsd/NMEA.html
ACK ,AKD, ALA, but there is no documentation, maybe the "Acknowledgement" sentences are used anywhere to quitting alerting.

In SignalK its quite simple, following the instruction https://signalk.org/specification/1.5.0/doc/notifications.html
writing null to the path notifications.mob by using node-red and its done. Of course the output of this null via nmea is missing.

[TomKeepCalm]

Dfifferent approachs:

1. May its possible to make alarms available via api to do this stuff via plugin?
2. New AVNAlarmHandler for quitting.
   New parameter for starting speciffic alarm: startAlarmPin (similar to stopAlarmPin) Is this pin is defined as output may its possible to set it high or low programmatically anythere.

[AWeerWolf]

Agreed with the NMEA sentence for MOB :
$--MOB,hhhhh,a,hhmmss.ss,x,xxxxxx,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxxxxxxx,x*hh
Can be found here : https://www.nmea.org/Assets/21030814%20nmea%200183_man%20overboard%20notification_mob_sentence%20amendment.pdf

So we can create a button (based on an ESP32) we can have in the cockpit that sends this kind of sentence.
The message is trapped by SignalK.
The AvNAV application get the message from SignalK
The AvNAV can then create the appropriate WayPoint and so on.

[TomKeepCalm]

I have the system running successfully now (unfortunately still without AvNav).
I'm very happy how it works and I think it could be used e.g. for "Remote Control Anchor Alarm Activation" #206
also be suitable.

It has the following advantages:

• extremely inexpensive <20 euros, example: https://www.ebay.de/itm/124651986423?var=425585067260
• very low power consumption
• separate signal output via sound and light, therefore e.g. independent of volume settings)
• Transmitter waterproof IP55 (according to manufacturer)
• Battery lasts 25 years (according to manufacturer)
• Range up to 300m (according to manufacturer)
• The send buttons have different IDs and can therefore be used for different purposes.

Workload approx. 50h:

• Receiver hack: conversion to 5V, separation of receiver chip and logic chip wiring -> now goes to the RPi, construction of a voltage divider to 3.3V for the input at the RPi GPIO (2 resistors), the GPIO output goes directly to the receiver.
• Selection of the software and creation of a node-red flow.
• Tests in SignalK.

Only thing missing to make it perfect is the notification connection between SignalK <-> AVNav and extensive tests of course :-)

If someone is interested in I'm happy to provide pictures for the hack of the receiver as well as my Node-Red flow.

[wellenvogel]

Things like that are always really interesting.
Maybe you would like to share what you did including some description.
But I think it is out of the scope of this issue.
The next AvNav version will have a first integration of SignalK and AvNav Alarms (already availabe in the daily builds).
For a perfect system this needs one more step.
Personally I would for sure not rely on NodeRed->SignalK->AvNav for a MOB function. To many parts that could fail.
For setting an anchor watch it would be OK for me.
But this depends on your personal preferences.

[TomKeepCalm]

Thank you for the update !!!
And of course , you are right about the MOB chain, but everyone should know what we are doing here. It is open software and hardware. Think it's far away from any certification :-) If you don't trust it, you should rather get a professional system with possible recourse claims.

[TomKeepCalm]

I made some tests with new daily build 20220413 about the SignalKHandler:
The connection works well:
I receive the notification mob at AvNav from SK and could cancel it by clicking the alarm field what was appearing (new notification mob is set to null at SK) Great!
The other way:
The sendWp feature works great as well. It will send all info of the next waypoint if I push mob button and set a new notification mob. The alarm could canceled if new notification mob is set to null from elsewhere at SK.

Only one small thing, how it's possible to control the functionality of mob button from outside too?

Another good thing is that I could deactivate the SocketWriter to SK now, bacause the only thing it was used for was the send of next waypoint and unfortunatly I got ( at this version) an error at SK fromavnav: connect ECONNREFUSED ::1:28628
I cound'nt figure out why.

[AWeerWolf]

Hi Tom,
I am interested in the hack of the receiver and your NodeRed Flow.
Would be nice to share.
Thanks,
Regards

[wellenvogel]

@TomKeepCalm : For the connection issue: try to replace localhost with 127.0.0.1 - this could most probably fix the issue. It depends on how your system is set up - if it prefers ipv6, localhost could resolve to an ipv6 address - and this will not work.
But you are right - not necessary any more.

For the MOB button:
Not (yet) possible.
This requires some changes in the router (this server currently cannot st up this MOB by it's own) - and I will do this in one of the next steps.
But I still wanted to release the new SK integration right now.

[TomKeepCalm]

@wellenvogel: Everything is working now, I have deactivated the Socked writer.
Don't hurry with MOB button, I m really surprized that you have integrated the notification feature so fast :-)

@AWeerWolf: How should we do this? It is better to make a new topic (elsewhere) or would you like to send you some description directly?

[wellenvogel]

most parts implemented with release 20220421.
I just leave this open for the remaining part:
(1) send NMEA MOB
(2) trigger the complete MOB function from SK (and from a plugin)