Onderwerp: Sailing Performance Dashboard

Top! Ga ik uitproberen.

Jumpinjack schreef :
Watte precies?

Inmiddels de 3 variabelen voor trimadviezen ook opgenomen in de leesroutine voor de NMEAtemplates.
advice1, advice2, advice3.
Zal de manual ook even aanpassen.

Let op: de MV-records voor de multiview komen uit een andere poort dan de UDP-NMEA.
Dit omdat de MV luistert naar 10110
Je kunt wel in boatspecifics zelf beide poorten opgeven (en ook gelijk maken)

Zal ik een DIY record type toevoegen? Misschien kan je daar dan alles in stoppen wat je naar SignalK wil transporteren. Kan nu ook met MVP en MVW en de beide PSMD's natuurlijk. Die zijn een eigen formaatje.
Ik heb geen enkel idee wat Signal K allemaal zou kunnen ontvangen......
Jij wel?

v3.1.0 is onderweg van Github.

Version 3.1.0 of 29 January 2022
- Home made NMEA records are now also going out over UDP, even if the NMEA source is a TCP connection. So, when network is used (not serial), all record types with an Y are sent over UDP.

- A new home made record type is added: $SPDIY. In this Do It Yourself record you can put whatever $variable you want (as long as it is in the list of $variables). You can create a long record with lots of data. But on the receiving end you have to make sure there is an application that understands it….. Could be a way to communicate a lot of data simply with Signal K (we hope).

- This new DIY record will be output over UDP or over serial, and it will be copied to copy-nmea-out.

Nu niet meer vragen om meer

Ik heb een nieuwe node red flow gemaakt om de waarden van SPD in te lezen. Zie bijlage.
Uitgangspunt is minder interne berichten in node red en daarmee als het goed is minder belasting van de pi.

Wat ik ook aangepast heb, is dat de flow er nu tegen kan als je vanuit SPD de waarden niet stuurt.
Je kan dus in webserverselection.txt nu heel selectief aan zetten wat je in signal k wil zien.
Aan de node red kant is het nu ook overzichtelijker, waardoor je daar ook makkelijker de waarden die je wil zien aan of uit kan zetten.

Er kunnen nog fouten in de flow zitten. Mocht iemand willen testen en nog fouten zien, geef dat dan even door, pas ik het weer aan zodat er een goede basis staat.

@michaelh,

laat je even weten als ik deze flow kan meenemen in de SPD download?

Nog wijzigingen voor jouw handleiding erbij?

michaelh schreef : Zal t binnekort even testen.

Ok, wat lopen spelen.

- De nieuwe node red flow werkt prima. Stuk minder load en als ik in SPD messages trim dan blijft t prima werken.
- De UDP stroom krijg ik niet aan de praat. Moet daar nog eens verder naar kijken, zal wel ergens een setup gemist hebben ofzo.
- Als ik de vlag zet dat SPD blijft draaien als er even geen input is, dan blijft ie draaien, maar krijg ik tegelijk een loop met pop ups.
- de headless mode werkt top. Load is dan heel laag en werkt prima. Betekent wel dat als ik SPD weer uit wil zetten een een ouderwetse kill command is op de terminal, maar dat is prima want zal weinig voorkomen.

- UDP stroom: NMEAmessages bedoel je? Moet je er wel 1 of meer aanzetten in boatspecifics.
Je doet TCP-NMEA in toch?

- loop met pop ups: tsja... als er geen NNMEA input komt maar de TCP-verbinding nog wel intact is gaat de lezende loop in SPD door (hoeft niet op volgende records te wachten) en loopt dan via een time out in een fout: geen data gekregen. Die fout geeft de melding dat er niets binnenkomt. Steeds weer. Ik zou natuurlijk na een aantal keer daarmee kunnen stoppen, maar dan weet je weer niet of de NMEA alweer binnenkomt. Zal er eens over denken. Volgens mij had ik gewezen op de risico's van run on empty Dit is er een.

Overigens, als de TCP connectie echt verbroken is dan wordt die niet weer opgestart door SPD.
Die verbinding maken gebeurt vóór de SPD-records-loop. Dus in dat geval blijft er een eindeloos lopend SPD over dat steeds zegt dat er geen records binnenkomen.... Nog zo'n risico
SPD maakt geen onderscheid tussen deze 2 oorzaken van gebrek aan data (geen TCP of wel TCP maar geen berichten).

- uitzetten in headless mode: dat kan wel netjes.
Als je in een browser naar de webserver kijkt (IP:Port/demo) dan is daar een quit-knop. Klik! (alleen in headless mode, niet met actief scherm, dan heb je een echte knop!)
Op een andere manier (tekst) 'quit' sturen naar de webserver werkt ook.
Eigenlijk zou de Node Red 2 kanten op moeten werken, en die button-commando's (stuk of 10) ook moeten kunnen versturen.

Houden de gebruikers het nog een beetje bij ?

Hier is V3.2.0

Version 3.2.0 of 2 February 2022
- Gracefull degradation and shutdown now when a NMEA-TCP connection breaks down and run on empty is set to Y.
Six ten-second time outs will pass before SPD quits.
When the whole TCP-connection is gone (not just the NMEA data stream) you have to correct that by restarting the NMEA source and then SPD. SPD will not re-start the TCP connection automatically in this situation as it cannot know what the cause of the loss of the connection is.

When using UDP-NMEA SPD will still wait forever for records coming in. You can stop SPD if you want to. Or you can repair your UDP NMEA source.

- A few new keys in boatspecifics section [Trimadvice]
heel delta = 5 difference between actual heel and target
off BTW = 10 difference between COG and BTW
perf limit = 95 performance limit
speak advice = Y will allow spoken advice for some warnings

The first 3 values determine when an advice wille be triggered: this happens when the difference between target and actual is bigger than the value given (for heel delta and off BTW) or is lower than the limit (for performance)
Spoken advice = Y will give you a short spoken message; currently 3 of them: “pinching”, “too deep” and “off course”. Deze speciaal voor de stuurman op de boot van koko

- The connection of the webserver output to Node Red and Signal K has been improved by michaelh. Better performance, new variables and improved flexibility. A new version of the connecting json is included.

De spraak-output (alleen voor Windows) is handig.
Ik doe een bluetooth draadloze accu-speaker in de kuip.
Die roept dan als we wat fout doen. Hoef je niet naar displays te kijken.
Als dat ook voor linux kan dan komt het in SPD. Er lijkt wat ontwikkeling in speech engines te zijn....

Baasklusje schreef :
Your wish....

Wat mooi!

Moeten we in de headless mode nog iets hebben om van polar te wisselen (andere csv inlezen) bij een live SPD? Met scherm kan dat met een tk-fileselectie-schermpje.

Vragen naar een filenaam wordt me te lastig (headless), maar wat wel zou kunnen is wisselen van polar.
We kunnen in de startupfiles.txt een extra polarfilenaam opnemen en dan bij de knop IO&Files de 'andere' altijd inlezen (igv headless, file kiezen met scherm blijft dan wel).
Dan kun je swappen tussen 2 polars. En je kunt startupfiles.txt editen en zo nog een andere polar activeren.
En als je beide namen hetzelfde maakt in startupfiles.txt dan leest SPD wel de polar,maar dat is dan gewoon dezelfde.

is dat wat?

Het werkt aardig zo via node red. Als ik via node red SPD ook nog opgestart krijg, is dat een mooi begin om mee te varen. Maar daarna liever wat meer interactieve mogelijkheden dan extra zaken via ini files sturen.

Misschien kan je wat services bedenken waar je uiteindelijk dan de applicatie mee kan samenstellen. Denk aan de preprocessor om een polar in te lezen aanroepen en deze daarna vervolgens te selecteren. Als SPD een service kan bieden die de beschikbare polars teruggeeft, kan je er daarna in de client een kiezen en die aan de volgende service doorgeven. De service om de polar te selecteren kan spd met scherm ook gebruiken.

Voor de quit service kan je ook bedenken dat je een headless service hebt en dat de client (ook SPD met scherm) zelf kan vragen of de gebruiker het zeker weet.

Het uit elkaar halen van de interactie bij het opstarten in aparte services is nog een uitdaging denk ik. Bij het opstarten met headless / printer vraagt SPD of juiste files geselecteerd zijn. Mooier zou zijn als je de op te starten files makkelijker mee kan geven aan SPD. Dit kan door startupfiles naar ini aan te passen. Maar je zou in headless ook kunnen wachten tot je een start commando krijgt, waar de juiste gegevens aan meegegeven worden. Een headless applicatie vereist wat meer design, maar komt waarschijnlijk de modulariteit en functionaliteit ten goede. Zeker als je verschillende mogelijke user interfaces terug krijgt.

V3.3.0

- Stopping irregularities removed in headless situations

- A few new pieces of trim advice added:

In waves when pitching on a beat and also performance is affected negatively, the advice is to increase power and bear off a bit.

When beating to windward with a bit of a wide angle, say 5 to 10 degrees above UA, the advice is to luff a bit

For this, you can have 2 extra lines in boatspecifics:
[Trimadvice]
high pitch = Y
pitch limit = 10

High pitch Y will enable the pitch warnings.
Pitch limit is in degrees, and pitch is measered as the difference between the highest positive pitch (bow up) and biggest negative pitch (dive) in a 10 seconds time frame.
Of course, a pitch measuring device is required (like a RM-EV)

Overzicht trimadviezen uit de manual:

Overview of messages and conditions:
• When heel above target + heeldelta, TWS above 10 kts and performance below limit:
“big heel,slow : cunning on, more twist, reef"

• When heel above target + heeldelta and TWS above 10 kts
“big heel: traveller down, weight to luff"

• When heel lower than target - heeldelta
"low heel: less twist, slack forestay"
"low heel: traveller luff , more sail"

• When rudder angle above rudder angle high and performance below the limit
"rudder: traveller lee ,tighten forestay"
"rudder: less heel, flatten, more twist"

• When in light air (TWS 1-7 kts) and performance below the limit:
"light air: twist, vang slack, more sail"
"light air: traveller luff, add twist "

• When just slow, performance below limit:
“performance too low "

• When sailing higher than UA and performance suffering:
"pinching, fall xx degrees"

• When sailing upwind but 5 to 10 degrees too low:
"too low, luff xx degrees"

• When sailing downwind at a too wide TWA and also performance suffers:
“too deep, luff xx degrees"

• When sailing a TWA between 65 and 100 and performance is too low:
"jib sheet out, jib twist less, vang on "

• When pitching more than pitch limit, going upwind and performance is suffering:
"high pitch, add more power and bear off"

• When actual COG is more than offbtw from the active BTW:
"off course to waypoint. Correct course"

Kleine toevoeging:
de meters verlies bij een tack of jibe.

De performance zou op 100% moeten blijven, maar dat doet ie niet natuurlijk.
Met de SOG en de duur van de manoeuvre kun je dan de verloren meters uitrekenen.
Dit houdt even geen rekening met de gewonnen meters recht tegen de wind in.
In het bericht de performance en TWA (en boeg) voor en na de tack, en de verloren meters.
Voorbeeld is van de 24uurs, van halve wind naar halve wind om de SB18 heen.

Leuk dit, wordt een soort “expert knowledge base”

Ik ben benieuwd hoe bruikbaar de adviezen in de praktijk zijn. Als er elke 5 s een ander advies komt, heb je er niet zoveel aan. Misschien dan een filtering die slechts eens per bv 5 minuten het advies geeft waar je het meeste aan hebt? Een soort coach in plaats van 10 roepende ouders langs de lijn zeg maar?

Zijn er al mensen die dit aan het praktijk testen zijn?

Nu hebben we een volgende 'AI' bemanningslid die gaat meestemmen. Wordt druk. Gelukkig hoeft die niets te eten en te drinken.

Thomas, kan je er niet ergens in kwijt "SPi erop. NU!'?

Anyway .... ben heel benieuwd hoe dit gaat werken inderdaad.
Respect voor ieders kennis. Ik plak wat extra tell tales, telt dat ook?

Gr michel

Bij deze de nieuwe flow in node red.
Aanpassingen:
- De data (src) naar signalk was niet helemaal juist, waardoor SailingPD output niet in een node-red dashboard getoond kon worden.
- Een control panel, met de knoppen die SailingPD via de websocket ondersteunt (vereist node-red-dashboard).
- De headless web output via de websocket naast het controlpanel (vereist node-red-dashboard).

Mooi michaelh!

Ik maak even een nieuwe download, v3.3.1
Momentje

Beauty schreef :
In zekere zin zit dat er al in.....
-te weinig helling en te lage performance en TWA>90, dan roept ie om meer zeil

Ik ben niet zo bang dat er veel tegenstrijdige adviezen komen.
Wel blijft ee advies staan totdat het probleem opgelost is (teveel helling, te lage performance, teveel roer, te weinig helling). Een volhardende coach, zeg maar

En je kunt natuurlijk zelf alle adviezen uitschakelen, op vakantie bijvoorbeeld

Baasklusje schreef :
Hij gaat ook zeuren op een geven moment? Dan wil ik wel een beloning als ik iets goed gedaan heb. Unicorn of muzikaal bliepje ofzo?

Nachtvlinder schreef :
Een lieve damesstem die 'hundred' zegt? Dat is er al

Version 3.3.2 of 11 February 2022
- The file that remembers the 5 files (boatspecifics, polar, heelpolar, deviation and stw-correction) used during last successful start was a txt file but now is an ini file, startupfiles.ini in /systemfiles/

[startupfiles]
boatfile = /sailingpd/boatspecifics/boatspecifics.ini
polarfile = /sailingpd/polars/ polar.csv
heelpolarfile = /sailingpd/heelpolars/ heelpolar.csv
deviationfile /sailingpd/deviation/ 2D deviation.csv
stwcorrfile = /sailingpd/stwcorrection/stw 2D.csv

At startup with the same files,first the ini is looked for. If available, it is used.
If no ini, the txt version will be used.
Then, after a successful start, both the ini and the txt version are written for the next start. Next time, the ini will be used.
This way, users automatically change over from txt to ini.
If you edit startupfiles manually, make sure you edit the ini version if it exists! You can delete the txt version if you want.

Voor onze 10 Hz medemensen:

SPD geeft elke cycle (dus meestal 1 Hz) 1, 2, of 3 adviezen (indien nodig).
Die adviezen zijn verschillend voor een even en een oneven cycle (de teller in SPD die het aantal cycles telt).
Zo kan je om de seconde verschillende (aanvullende) adviezen krijgen.

Voor de 10 Hz medemens werd dat een beetje veel: 60 adviezen per 2 seconden.
Dat is nu teruggebracht naar 3 per seconde, door ze 9 keer niet te wijzigen.

Binnenkort in v3.3.3
Tot die tijd nog even heel snel lezen!

Dit klinkt bijna als een kandidaat voor alarm management en rationalisatie Voorkomen van alarm flooding en bovenaan de belangrijkste alarmen.

Of zoiets (word cloud)? Het advies dat het vaakst terugkomt en/of waarvan meer positief effect verwacht wordt benadrukken? Of als een pareto-lijstje?



Ik ben erg benieuwd hoe het allemaal gaat werken, straks in het echt! De adviezen zijn nu allemaal vlak zonder prioriteit toch? Of kan een gebruiker straks instellen vanaf welke afwijking er een advies komt? Eens per 2? minuten bewust worden van mijn grootste fout om die op te kunnen lossen lijkt mij waardevol; om de 10 s een andere melding wordt meer “ruis” ben ik bang. Hoe gaat dit met historische data in de tests?