Onderwerp: SailingPD performance weergeven op je boot

FrouFrou heeft Performance van 100+ hoor, hou daar maar rekening mee

Gepost met de officiële Zeilersforum-app

roozeboos schreef :
Nee, ik weet alleen dat het beter niet negatief kan worden.

roozeboos schreef :
Jezus Chris, je weet wel beter toch

koko schreef :
Heet 'ie echt zo?

Lijkt 'ie ook op zijn gehoornde broer?

.

Ik bespreek het verder persoonlijk.

Dat verwijderen is verstandig, koko.
Chris heeft weer even poging gedaan iets op te stoken met een onbenullig commentaartje, het bekende werk.
Dat nou juist hij twijfels uitspreekt over mijn kennis van performance is wel apart.
Zijn geheugen zal hem vast wat in de steek laten. Een opfrissing:
- lang geleden, toen de roosmux werd bedacht, heb ik roos (in posts en PB's) de details van een polar uitgelegd.
- ook verteld hoe ik zou interpoleren tussen TWSen (de gemeten TWS is zelden gelijk aan een tabelwaarde) en TWA's (idem).
- ook verteld hoe in Tactictool van Willem Amels een NMEA-bericht wordt 'misbruikt' om er performance in te zetten. (ik heb het ook niet van mezelf, dank Willem! ). Ik gebruikte dat toen al een jaar of 10.
- de suggestie gedaan om te laten zien of je binnen de polar vaart of buiten (De UA en DA)
- de P achter performance uit een roosmux staat dan ook voor echte performance binnen de polar
- de V erachter betekent dat je te hoog of te laag stuurt.

Het feit dat ik dat allemaal nog precies weet zonder ooit een roosmux gezien te hebben (laat staan gebruikt, ik ben van de miniplexen) mag wellicht gezien worden als bewijs voor bovenstaande.

Dus.... laat verder maar. Ik weet wat performance is....
@chris: ga hier nu niet weer op reageren. Dit is mijn projectdraadje. En mijn geheugen is veel beter dan het jouwe.

Het was alleen maar een kritische vraag, dat mag toch? Zo niet, dan hoor ik dat graag.
Het was niet opstoken. Dat doe ik allang niet meer.

En dank voor je hulp. Toch nog een veer in je xxx

Van mij mag je dat wat jij kritisch en wij zuigen en saboteren noemen achterwege laten in een projectdraadje.
Je hebt je eigen commerciële projectdraadjes toch, dan kun je daar spelen

Naar aanleiding van wat e-mails met Zeilbroer, NKE-gebruiker, een kleine toevoeging gedaan.
Er waren al de $bestup en $bestdown, die doorgeven wat in de polar staat als de beste opkruis- en afkruis-hoek bij een gegeven TWS.
De NKE-spullen kiezen op basis van de TWA of ze de beste UA of de beste DA laten zien.
TWA < 90: dan de UA (opkruisen), anders de DA, want dan ben je vast aan het afkruisen.

Dus de variabele $bestangle toegevoegd, die kan in elk willekeurig NMEArecord dat SailingPD kan maken.
Niet specifiek in PNKEP record, de $bestangle kun je in elk voor jou handig veld van de NMEATemplates zetten. En dan komt afhankelijk van de TWA de ene of de andere in beeld.
Op het Dashboard staan de bestup en bestdown allebei, dus geen noodzaak voor de bestangle daar.
Dank Zeilbroer frou frou voor de info!

Ik zou dan ook de performance% gewoon altijd positief houden. Heb er zelf voor gekozen om VMG wanneer downwinds varend ook positief te houden (ook al vaar je effectief van de wind weg). Zie het als VMC, die is ook positief...

VMG is meestal negatief als je van een waypoint wegvaart. VMG tov Wind ook.
Ik maak dus vanzelf ook de VMGperf negatief als je van de wind af vaart.
Er staat VMG to Wind op het Dashboard.....

VMC is altijd een verwarrend dingetje. Wat is jouw definitie?

PS ik zag in de beschrijving van de OCPN tactic dat CMG Course Made Good in kts is. Beetje mal, kts.
CMG is de koers (graden) die je gedaan hebt, COG is de koers die je nu doet.

Jammer dat dit draadje wordt vervuild met dit soort uitspraken:

citaat: Jezus Chris

Heet 'ie echt zo?
Lijkt 'ie ook op zijn gehoornde broer?

Echt belachelijk dit soort uitspraken!

Chris had ook kunnen kiezen om SailingPD performance enthousiast te omarmen en te onderzoeken waar hij mogelijk zou kunnen samenwerken om tot iets moois te komen. In plaats daarvan kiest hij ervoor stelselmatig nieuwe initiatieven te bekritiseren en op zijn eigen producten te wijzen. Dat dat weerstand oproept begrijp ik goed, dat daarbij zijn rol van sponsor ook nog dubieus wordt gevonden ook.

Neemt niet weg dat de genoemde bewoordingen inderdaad wat anders hadden gekund wat mij betreft.

FrouFrou kan niet wachten om te gaan varen en testen.
Negatieve Performance, achteruit de box uit.
Of is het alleen schroefwater, de SOG is nul...

Let op de gepersonaliseerde window-naam en de mooie foto

Zo, t kostte wat moeite, maar N2k aan de laptop dmv actisense ngt-1, door Signal l, virtuele com poort en dan naar SPD.
Dat werkt. Tenminste, met de wind in simulatie stand en zonder gps (want staat binnen), dus zag 1000% performance langs komen. Maar, t werkt.

Nu thuis (te koud op de boot) kijken hoe ik t weer andersom van SPD via signal k naar n2k krijg voor op t schermpje. Wordt nog even puzzelen...

Top! Stap 1 is gezet!

Vandaag is de FrouFrou op het water aan het testen; alles werkte, maar ongetwijfeld hebben de zeilbroers nog wensen, vooral de computerbroer schijnt erg precies te zijn
Dit was denk ik het eerste tochtje op het water, snel stromend water nog wel!

Ze studeren nu op de SPDlogfile, boordevol met nuttige informatie...

Ben benieuwd!

Qua schermindeling: daar waar je als gimmick nu je pasfoto oid neer kunt zetten heb je in feite ruimte over: zou het nuttig zijn die ruimte te benutten voor (ja: grafisch!) een aantal trends?

Ik denk aan grootheden waarvan het nuttig is het verloop in een oogopslag te kunnen zien, bv TWD, TWS en stromings-schatting. Dit is in feite wel taktische informatie, maar toch al beschikbaar en kan handig zijn te bepalen wanneer het bv gunstig wordt overstag te gaan.

Ben je bv met stroom tegen aan het kruizen, dan kun je zien welke kant van een stroomrafel je moet zitten.

tsja, grafiekjes....
Mijn ervaring met Tactictool (met stripcharts) is dat ik er nooit naar keek.
SailingPD geeft ook al 3 trends weer: richting geowind SHift), Kts True wind +- en Kts Geowind +- .

Komt bij dat mensen SailingPD zullen gebruiken naast een navigatietool op de PC: OCPN, WinGPS, etc.
Dan hebt je twee (virtuele) COM-poorten nodig.
Als je daarvoor dan NavMonPC gebruikt heb je meteen stripcharts voor wind en water, met instelbare tijd en grenswaarden. OpenCPN kan dat vast ook: charts maken en de NMEA doorsturen naar SPD.

Wat betreft kruisen op stroom (mee of tegen): aan de VMG performance kun je meteen zien waar de stroom het gunstigst (mee of tegen) is. Gewoon dat percentage omhoog brengen!

Plaatje van NavMonPC en SailingPD, dezelfde NMEAstream gebruikend:

Beetje lopen puzzelen.
Als ik kijk naar de PGNs die op mijn N2K netwerk in gebruik zijn en die map naar vertaalde 0183 records dan zijn ze allemaal al in gebruik, behalve RPM en XDR.
Meerdere devices met dezelfde message is lastig. Dus aleen RPM en XDR beschikbaar om wat door te sturen.

RPM
RPM kan meerdere engines aan.
$PDRPM, E, 1, &sogperf, $sogperf, A
Dit is 'engine 1'. Zou het mogelijk zijn om meerdere lines aan te maken?
$PDRPM, E, 2, &targetspeed, $targetspeed, A

XDR
Hier wordt het interessant met Signal k. Er is een XDR-parser plugin.
XDR is een set van 4 velden.
$UPXDR, G, %sogperf, P, SailPerf
Je kan dit mappen naar een Signal k variabele. Met een beetje mazzel kan ik dit door mappen naar bv batterij of tank levels.
In de parser kan je iedere XDR variabele ('SailPerf' in de SPD definitie) doormappen naar een andere Signal k variabele. En eventueel een eenheid conversie doen voor de data.

Ook voor XDR de vraag (analoog aan RPM), is het mogelijk om meerdere 'sets van 4' te maken met andere positie 4 waardes?

Als ik weer op de boot ben zal ik kijken of ik in ieder geval een eerste versie door kan mappen en op de display krijgen.

Er is hoop

Creatieve ideeën Bas!

Hoe het werkt:
- elk NMEATemplate is er 1 van, en die worden gelezen uit de NMEATemplatesfile.
- Dus er wordt 1 RPM ingelezen, geen twee. Ik zou er twee kunnen maken (RPM,E,1 en RPM,E,2)
- Dat vereist wat aanpassingen aan het programma, het is het toevoegen van een nieuw recordtype (bij inlezen, vullen, loggen en naar USB zenden). Het kan. Zelf 2 RPMs in de Templates zetten zal er toe leiden dat alleen de laatste van de twee wordt gebruikt.
-let op, de RPM in N2K is 1 byte groot. Max waarde is 124 (hoger is voor foutmeldingen). 124 is m.i.te weinig voor Performance.

Dan XDR.
In een XDR kunnen maximaal 4 groepen van 4 velden. Dat komt door het maximum aantal posities in een NMEA183 bericht, uit mijn hoofd 82 characters incl $ etc.
De layout is nu $UPXDR,G,%sogperf,P,SailPerf voor de 1e groep van 4.
De G is voor Generic, de %sogperf is een getal, de P staat voor Procent en de SailPerf is de Transducer ID. Dit is allemaal officieel NMEA; een XDR hoort die 4 velden te hebben.
DIt voorbeeld heeft (van de eerste , tot het eind) zo'n 19 characters Payload, ex de header.
De %sogperf wordt een getal van 4 posities, en 'SailPerf' zou korter kunnen, dus het kan ietsje korter.
En dit soort blokjes van 4 kan er dus 3 a 4 keer in, in 1 XDR.
Als SignalK netjes de hele XDR kan parsen dan kan er meer mee in 1 XDR.

Voor XDR geldt hetzelfde als voor RPM: er wordt er 1 gelezen. Geen twee. Ook dat zou wel kunnen, maar vereist dezelfde wijzigingen aan het programma als een extra RPM. Het kan.

Dan nog dit: bij het inlezen van de NMEATemplates wordt hard gecontroleerd of er geen teksten in staan waar het programma niets mee kan. Een tikfout in een $variabele, of een schrijffout in SailPerf, wordt afgevangen. Dat is nodig om ergere fouten tijdens uitvoering te voorkomen.
SailPerf bijvoorbeeld staat daar zo omdat het plan is om daarmee in een Miniplex een Proprietary bericht over performance te maken. Dan moet die transducer, SailPerf, wel herkend worden door de miniplex.
Hetzelfde geldt voor de Signal K Parser.
Een tikfout (SailPref) zou ertoe kunnen leiden dat mensen denken dat het programma of hun mux of hun display het niet doet, terwijl het hun eigen tikfout is Tik op de vingers dus bij inlezen:
In het programma dat de templates leest staat:
Zoals je ziet, nogal een controle. Alle letters die in een NMEA183 kunnen voorkomen, de 1 en de 2 voor motornummer, de G en P en SailPerf uit de XDR. En alles met $ is een variabele uit het programma.
Ik kan simpel deze lijst uitbreiden met de keywords die Signal K herkent.
Maar de controle blijft wel nodig.... we moeten de gebruiker een beetje tegen zichzelf beschermen
De XDR zelf aanpassen in de templates is eenvoudig.
Als jij een lijstje van wat door Signal K herkende variabelen levert stop ik ze in de XDR.

Duidelijk verhaal Thomas.
Ik zal met de huidige versie eens kijken wat t doet op de boot. Als dat werkt kunnen we kijken naar uitbreiden.

Als uiteindelijk alles werkt, en je bakken aan data hebt, hoeveel moeite is het dan om een algoritme eroverheen te leggen voor een voorspellende waarde? Kan je op basis van alle data die je ziet (allemaal in het verleden) ook een verwachting geven over wat de wind gaat doen. Zeg over 1 minuut, of 30 seconden een shift van zoveel of zoveel?

Gr Michel

Dan komen we bij de AI, Big Data......

Voor wind lijkt me dat lastig. Daar zijn zoveel factoren van invloed.
En het verleden is bij het weer niet de beste voorspeller.... anders zou de weersverwachting altijd wel zeggen dat het 'morgen hetzelfde weer wordt als vandaag'. . Vaak goed, vaak ook erg fout.
Voor de wind zou ik op Harmonie vertrouwen.

Bovendien zou dat allemaal live uitgerekend moeten worden:
- een patroon in de actuele wind ontdekken
- dat vergelijken met alle patronen uit het verleden (big data)
- en dan een voorspelling maken
- en dat allemaal terwijl er ook nog snel veel NMEA moet worden verwerkt.

Voor andere dingen zal het vast wel zinvol kunnen. Voorbeeldjes:
- Veel golven geeft veel Pitch. Dat remt en de mast zwiept ook nog open neer. Slecht voor de performance. Je zou dus (door analyse van PDlogs) vast kunnen stellen wat de impact van een hoeveelheid Pitch op Performance is. En daar kan je wat mee: andere polar laden, berekening aanpassen, you name it.
- Veel roerhoek op rechte stukken is een signaal voor slechte trim. Kan een waarschuwing opleveren.
- Meer heel dan de target heel is een teken van te weinig bemanning of te bolle zeilen
Er is nog veel meer te verzinnen op basis van combinaties van waarnemingen.

Zo heb ik na een 24uur eens in de log(van Tactictool) geanalyseerd of daglicht van invloed is op sturen.
En jawel, in het donker stuurt men rechtere lijnen (op het lampje van de boei af; overdag zie je die boei pas veel later). De vraag is natuurlijk of dat goed is, rechtere lijnen als je de tell tales niet kan zien is misschien wel fout..... dat kun je dan weer zien aan Performance in donker en overdag.
Allemaal stuff om waarschuwingen uit af te leiden.
Je hebt vast ideeën voor wat van die dingen!

Ik denk meer in toepassingen inderdaad, de taal die jullie spreken om het te bouwen is voor mij net als Fins