Onderwerp: Sailing Performance Dashboard

Nachtvlinder schreef : Je krijgt een waarschuwing als de stroom (snelheid en/of hoek) boven de drempelwaarden daarvoor uit komt.
Dingen als stroom mee, tegen, van loef, van lij.

Je ziet dan ook de hoek tussen ideale UA of DA en de gevaren TWA veranderen. (de oranje OFF)
Daar kan ik natuurlijk eenvoudig een waarschuwing aan koppelen, maar je kunt ook die afwijking van de ideale hoek op een display krijgen.

Een waarschuwing maken voor andere TWA bij constante heading kan ook.
Ik zal een lijstje gaan bijhouden van interessante warnings

Nachtvlinder schreef :
Nobody is zeker niet 3Noreen.

Inmiddels SailingPD 1.5.1 op de Onedrive.
De copy-files voor NMEA-OUT en NMEA-IN worden nu automatisch geopend.
Dan moet wel de juiste directory aanwezig zijn (zoals ook in map op de Onedrive)
Naamgeving na suggestie van koko ook aangepast.
Voorbeeld van de NMEA-OUT:



Dan even een vraag over de data die uit de EV van RM komen.
In de N2K-data zitten eading, rate of turn (bocht maken), heave (dompen, verticaal), yaw (draaien om de mast, kortdurend), pitch (stampen) en roll (helling). Die dingen gaan met 10 Hz van de EV naar de AP (ACU) en zijn nuttig om die AP goed te laten sturen.
Er zijn voor Heading en RoT NMEA183-berichten beschikbaar, dus vertalen van die twee (naar HDG en ROT) is simpel.
Voor de andere 4 (heave, yaw, pitch en roll) kan elke leverancier van een converter N2K naar 183 (losse converter of mux) zijn eigen oplossing kiezen, maar het moet natuurlijk wel netjes binnen de mogelijkheden van NMEA183 blijven.
Heeft iemand een overzicht hoe de verschillende leveranciers dit probleem te lijf gaan?
De oplossing van de Miniplex 3 ken ik, van de andere weet ik niets.

Actisense vertaalt de attitude PGN (127257) niet naar NMEA0183:



Yacht Devices ook niet:



Maretron:





Kan Signal-K hier wel wat toevoegen wellicht? Is daar een standaard gedefinieerd voor PGN 127257?

Wat zou je met “heave” moeten/willen/kunnen trouwens? Dimensie is [m]. Meter tov wat??
En “yaw”? Wat zegt dat meer dan ROT?

Ok, dank je.
Maretron als enige, met een PMAROUT,Att, en dan 3 waarden.
Furuno doet ook zoiets: PFEC,GPatt.
Dat mag, een Prop MAR message. (of FEC)

Komt dat veel voor in de jachtjes, Maretron?

Heave kunnen we iig loggen (en displayen). Misschien golfperiodes mee uitrekenen, en hoogtes?

RoT is graden per minuut echte (langzamere) bochten, vermoedelijk tov de vertikaal.
Yaw zijn kortere afwijkingen van de algemene heading, en dan tov de boot-vertikaal, de mast dus.
Als je boot op zijn kant ligt wordt de pitch nul en de yaw de pitch

In een lange bocht zal RoT hoog zijn en yaw nul.
Bij een rechte koers met kleine slingertjes (golfjes, sturen) is er wel yaw maar geen RoT
Zo heb ik mij laten uitleggen

SailingPD schreef :
Ik denk het niet. Ik ben bang dat er geen nette, standaard, manier is deze data in te lezen. Gek eigenlijk, dat 0183 geen pitch en roll kende, had ik niet verwacht.

Een rate compass een belangrijke toevoeging voor de dynamische terugkoppeling aan een AP, is ook 20 Hz in een N2K netwerk:
Dat yaw dezelfde beweging kan zijn maar tov de vertikale scheepsas zou goed kunnen. Of dat voor een AP die een boot onder helling stuurt nuttiger is dan ROT, weet ik niet...

Eigenlijk zijn er 2 mogelijkheden:
- een proprietary bericht, zoals PFEC en PMAROUT
- een XDR met 4 veldjes per variabele: grootheid, waarde, eenheid, transducer

Zoiets dus $UPXDR,G,202,P,SailingPFPerf*7a

G voor General, P voor Procent, 202 de waarde, SailingPDPerf is de "transducer"

Nachtvlinder schreef :
IMU's hebben een sampling rate van > 50Hz

Bedoel je dat die hoge samplingrate de reden is dat deze data niet kan bestaan op een 0183 netwerk?

Ik probeer me te beperken tot het aandragen van al of niet relevante informatie. Er is een verband tussen Sample Rate en het kunnen waarnemen van een signaal.

Dat verband is hier beschreven: en.wikipedia.org/wiki/Nyquist%...non_sampling_theorem

Maar we proberen hier niet de sample rate vast te stellen die nodig is voor een reproductie van het originele signaal.... we proberen juist ruis en meetfouten te onderdrukken door filtering.

En er zijn toch nog wel bandbreedtebeperkingen.
Een ouderwetse 4800 bps COM is al vol met zo'n 10 NMEA-berichten per seconde.
En moderne snelle mux kan natuurlijk veel meer hebben, maar met wat talkers op 10 Hz en een lekkere hoeveelheid AIS-berichten is ook daar nog steeds overflow mogelijk.

Die 10 Hz is mooi over de N2K-bus van sensor naar AP, en zelfs daar vermoedelijk overkill: te hoge sample rate voor de mogelijke frekwenties van de bewegingen van de boot. Maar kwaad kan het niet.

SailingPD schreef :
Je wilt misschien niet het originele signaal reproduceren meer je schrijft zelf;

SailingPD schreef :
Het is heel goed denkbaar dat een systeem op basis van 0183 helemaal niet is staat is om dat te doen. Maar het kennen van de beperkingen is ook zinvol. 0183 is inderdaad uit de tijd van floppy disks. Nu kan 1 postduif met een micro SD aan zijn pootje een equivalente hoeveelheid data versturen van 7 miljoen floppy disks.

nobody schreef :
Als je elke seconde een op een random moment gemeten Heave hebt zit je zeker aan de veilige kant qua sample frequency. Golven van 0,5 Hz pak je dan ook nog Dat zijn kabbeltjes....
Ook heb je maxima en minima in die tijdreeks.
We gaan het zien!

1s Fs is zat daarvoor inderdaad. Probleem lijkt echter dat de benodigde N2K PGN’s niet bestaan in de 0183 wereld... ik zou het persoonlijk dan liever weglaten dan met zelf gekunstelde scentences te gaan werken, die verder geen enkele s/w of hardware ondersteunt.

Nachtvlinder schreef :
Het wordt niet zomaar zelfgeknutseld

De PFEC,GPatt komt op dit moment al uit een Miniplex 3.
De XDR is officieel NMEA183 en ook die komt (binnenkort) uit een Miniplex 3.

Uit een log van koko (RM EV via Miniplex 3):

$PFEC,GPatt,,+0.40,+16.62*51
$PFEC,GPatt,,+0.38,+16.65*59
$PFEC,GPatt,,+0.38,+16.69*55
$PFEC,GPatt,,+0.37,+16.71*53

Uiteraard pruts jij niet Da’s mooi, maar dus alleen bruikbaar bij diegenen met een hiervoor getweakte Miniplex-3.

Getweakt is niet het juiste woord. Nieuwste officiele release van de sw. Dat is het .

De XDR begrijpen in SailingPD gaat obv de keywords (Transducer ID) en de grootheden in de records.
Als andere leveranciers XPD gebruiken met andere keywords voor de Transducers is dat slechts een tabelletje aanpassen voor SailingPD.
Maar zoals je zelf al zei, behalve Maretron is er verder niets.....

Even voor de goede orde: de data uit de EV1 sensor komen idd via een Shipmodul miniplexer in de computer terecht als nmea bericht. Daar is niks voor aangepast aan de firmware van de multiplexer. Die huidige firmware in mijn Multiplexer zat er al in ver voor er überhaupt Sailing Performance Dashboard was. Gewoon de firmware die iedereen heeft dus.

Het was zelfs een onverwachte, maar aangename verrassing dat helling en pitch er uit kwam. We hadden alleen Heading en ROT verwacht op basis van de RM manual.

Nog beter, ik had begrepen dat Meindert “op speciaal verzoek” iets aan had gepast aan zijn software. Dat wees op een one-off...

Voor de vertalingen van de berichten uit de EV1 sensor is er inderdaad niks speciaal aangepast.

SailingPD schreef :
Dit is toch Pitch en Roll ? Niet Heave.

nobody schreef :
Klopt, met een leeg 1e veld voor HDG.
Heave zit niet in deze proprietary Furuno message, maar wel in de PGN uit de EV.

Angles-window van naam veranderd en uitgebreid:

Leuk! Waar komt “heave” nu vandaan (en wat kun je straks met die data)?

Zou RUD nog iets kunnen toevoegen? Niet dynamisch maar als indicatie dat de trim niet optimaal is?