Onderwerp: Sailing Performance Dashboard

Ik zou willen kunnen zien performance op stil staand water of gecompenseerd voor stroming, en optimale upwind/downwind angle.

De stuurman moet eigenlijk in 1 oogopslag kunnen zien of hij goed of fout zit en wanneer de trimmers iets moeten gaan doen.

Deze B&G race processor is NMEA2000 gecertificeerd en connected (geen 0183 meer...). Dat betekent dat er op z’n minst proprietery PGN’s bestaan die getest en geregistreerd zijn lijkt mij?

Ik dacht dat “ons” hobbyisten probleem was dat we niet zonder betaald lid te zijn bij de specs konden komen waardoor we alleen kunnen backengineeren. Maar er bestaan dus geen “performance PGN’s”!? Wat stuurt die Hercules dan naar de N2K bus? Dat zal toch bekend zijn bij de Nmea organisatie?

Menno schreef : Die paden zijn een goede oplossing voor data die de applicatie zelf genereert en beheert. Voor een configuratiefile die de gebruiker zelf aan moet maken is dit niet handig omdat "AppData" hidden is. Daarvoor is een "eigen" directory in

C:\Users\<username>

of

C:\Users\<username>\Documents

de aangewezen plaats

Nachtvlinder schreef : Er bestaan inderdaad geen standaard performance PGN's die in de NMEA 2000 standard gepubliceerd zijn. Die Hercules stuur daarvoor proprietary PGN's uit. Die zijn alleen bekend bij de fabrikant en bij de NMEA. De policy is wel dat wanneer ergens proprietary PGN's voor zijn gedefinieerd en er komen uiteindelijk voor het zelfde doel "standard" PGN's, dat het gebruik van de proprietary PGN's niet meer mag. Maar er is niemand die daar op toeziet. Een mooi voorbeeld daarvan is CZone: een bedrijf dat allerlei schakel-"doosjes" maakt met inputs om schakelaars en sensoren te detecteren en outputs om dingen in- en uit te schakelen. Daarvoor heeft CZone proprietary PGN's gedefiniëerd, en later zijn er standard Switch en Status PGN's in de standaard opgenomen. Maar nog steeds gebruikt CZone z'n proprietary PGN's en die worden zelfs ondersteund door veel plotters/MFD's omdat zij de eersten waren die dit deden. Op een NMEA 2000 Standards Committee meeting in 2017 waar ik bij was, werd er over gesproken om CZone de vertellen dat ze moesten overstappen op standaard PGN's. Maar daar bleef het bij, voor zover ik weet.

Dankje voor dit kijkje in de keuken!

mhsprang schreef :
Laat dat nou zijn waar het bij mij allemaal staat

c:\users\<username>\documents\bootdocumenten\sailingpd

Ik ga geen ondoorzichtige dingen uithalen om 1 click (een armzalige click ) uit te sparen.

@nachtvlinder: dat instelvoorbeeld dat je geeft van Firefox is voor veel mensen alweer veel ingewikkelder dan 1 click om de directory te selecteren.....

@Meindert, succes daar bij NMEA !

Een van de testers is erin geslaagd data uit SailingPD via een Miniplex3 en met NMEA2000 PGN op zijn Raymarine i70 display te krijgen.
Daarvoor is een $SPXDR,G,%performance,P,SailPerf*hh bericht gebruikt vanuit SailingPD, omgezet in een PGN voor toerental, en vervolgens via N2K naar de i70.

Dat werkt dus! En straks wellicht nog beter via de officiele N2K-performance-berichten.

Proficiat

Baasklusje schreef :
Absoluut: heel veel succes gewenst!

Baasklusje schreef :
Wow, Cool!

De port naar Linux is onderhanden.
Eigenlijk (lijkt het, maar 'there is always another bug', zei Murphy al) valt dat erg mee:
- de winsound (piepjes bij de knopjes) eruit als er geen Windows is
- wat aanpassingen bij het testen en openen van een poort (COM in Windows, TTY etc voor Linux).

Voor de rest niets, dankzij Python (multi-platform immers).
Een Linux-executable ervan maken voor distributie is de volgende stap.

Wordt vervolgd. (dat ik ooit nog iets voor Linux zou maken )

Waar blijft Brambo....

Baasklusje schreef : Mmm... integreren in de firmware van de MiniPlex en dan op de WiFi variant een web pagina waar alle gegevens op staan. Is dat een idee?

Als in: geen pc meer nodig?

mhsprang schreef :
Ik zat zelf te denken aan "zet SignalK op een pi-zero en voeg daar de dataverwerking van Sailing PD aan toe". Zeg maar zelfde idee, andere hardware. De ene is meer hobbyen, de ander plug en play (beide in principe zonder complete pc, @koko).

Een verbinding naar een seriele poort lijkt mij niet noodzakelijk, omdat je bij SignalK hetzij met NMEA-data, hetzij met SignalK werkt (voor de start dus in 1e instantie NMEA). Maar dan heb je meer aanpassingen in de code.

En of je bij de opzet naar een MiniPlex of SignalK of Kplex verbindt is volgens mij een keus die de gebruiker maar moet maken. Ik zou verder de gebruikersinterface simpel houden, omdat die waarschijnlijk alleen gebruikt wordt voor de installatie en de 1e gebruikstest. Een klokje kan wel met een webapp van SignalK (of retour op het N2k netwerk).

Geen idee of een Pi-tje genoeg geheugen en cpu heeft voor dit soort dingen.

Als SailingPD live recordjes verwerkt die met ca 1 per seconde wind- en snelheidsgegevens leveren (normale NMEA183-installatie) dan komen er elke seconde tussen de 20 en (zeg) 120 records binnen. Veel is afhankelijk van de hoeveelheid AIS-records (die niet verwerkt worden).
Om dat te verwerken kost op mijn laptop 2 a 3% CPU.
Dan hebben we het over een Intel Core i5 met 4 maal 2.20 GHz, 8 GB geheugen en SSD.
Ik lees dan een pi-zero 1 GHz en 512 MB geheugen is.
Als daar dat ook nog Signal K bij moet denk ik dat het krakend tot stilstand komt.
Bijna 10 keer minder processing én 16 keer zo weinig geheugen.
En dat is dan met 1 Hz NMEA183. Als we 10Hz gaan verwerken (N2K positie en snelheid. NKE apparatuur levert zelfs 25 Hz) is het helemaal een verloren zaak.

Wat Signal K betreft vraag ik me al heel lang af wat dat nou kan toevoegen.
De bron van alle data is nog altijd en overal NMEA183 en/of NMEA2000.
Er zijn geen Signal K gevers. Bestaan niet. Dus ook Signal K moet NMEA183 en/of NMEA2000 eten.
Dat kan de combinatie van een mux en een PC prima zelf.
Daar dus geen toegevoegde waarde.
Aan de display-kant zie ik voor SailingPD ook geen toegevoegde waarde.
Voor veel van de informatie die uit SailingPD komt is geen kant-en-klare Signal K routine of app. Dat moet je dan dus gaan maken. Terwijl SailingPD al NMEA183/2000 levert voor op instrumenten, wifi-berichten over UDP, en een heel scherm vol met informatie op de PC (of een slave scherm).
De flauwekul van 'mooie metertjes' wil ik niet; een meter-display neemt 20 keer meer plaats in dan een cijfertje, en 95% van de oppervlakte van die meters is nutteloos.

Enige waar ik nog Signal K mogelijk voor overweeg is aan de outputkant: een kleine webserver in SailingPD die JSON uitspuugt waar appjes op een handheld dan iets leuks van kunnen maken, voor wie dat per sé wil. Ironman heeft daar al voorzetjes voor gemaakt.

Baasklusje schreef : Daar zou ik me dan ook op richten, NMEA0183/netwerk. Geef even aan UDP10110 of TCP10110 (en het liefst de poort configureerbaar, zodat dit ook 20220 of 30330 kan worden om conflicten te voorkomen).

De rest zou ik me geen zorgen over maken, behalve dan het feit dat meer gebruikers naar de data kijken dan naar de user interface.

Op een RPI4 1.5GHz zal het werken. Of het op een pi-zero werkt is jouw probleem niet. Ik zou alleen opgeven "geschikt voor x86_64/armhf/arm64" (en streep door wat niet van toepassing is als je met gecompileerde software werkt).

Baasklusje schreef : Hier moet ik toch wel lichtelijk om grijnzen. Een MiniPlex verwerkt met gemak 300 AIS zinnen per seconde, vertaalt ze naar NMEA 2000 en stuurt ze weer uit. Dat levert ongeveer 50% processorbelasting op, voor een 8 bitter op 30 MHz en 16 kByte werkgeheugen. Ga me nou niet vertellen dat je bang bent dat een RPi moeite gaat hebben met SailingPD

Overigens vind ik SignalK waardeloos en iets voor luie programmeurs die JSON meteen zonder een regel code schrijven kunnen omzetten in een object. Als je dan kijkt wat een GPRMC zin met positie, COG, SOG, datum, tijd, variatie en GPS status, alles binnen de maximale 82 karakters van een NMEA 0183 zin, oplevert na omzetten naar SignalK/JSON: een stuk tekst van bijna 900 karakters! Bloatware anyone?

koko schreef : Dan niet mee, nee. Een tablet of smartphone zou dan genoeg zijn.

Baasklusje schreef : Kijk, da's leuk.
Hier wel opgezet, maar niet kunnen testen. Zonder gps vindt SPD niet leuk. Dus de boot moet eerst naar buiten.

Baasklusje schreef :
Het logje wat je van mij hebt is gemaakt met een Raspberry 2.

Baasklusje schreef :

mhsprang schreef : Dat zou best heel interessant kunnen zijn, sailingPD als blackbox.

Met output naar nmea2000 en via wifi op een webpagina op je telefoon/pad/pc.

Moet je wel op enige wijze de definitie csv files kunnen oploaden (polar, etc), intikken is niet praktisch, zeker bij meerdere versies.
En de output een beetje kunnen configureren zodat die het doet op de displays in jouw boot.
En een 'default' selectie, want spd heeft nu nog een aantal vragen bij opstarten.

Als die miniplex dan ook nog eens zo slim zou zijn om te kunnen switchen tussen een wifi client en access point (client als mn boot netwerk\hotspot aan staat en ap als die er niet is), dan kan je er een postzegel deze kant uit opplakken.

mhsprang schreef :
Dat weet ik niet....
Ik weet wel dat als mijn boord-PC (die CORE i5) lekker bezig is tijdens serieus varen (24uurs) er nogal wat gevraagd wordt.
- WinGPS met per seconde een scherm-update
- Tactictool (vroeger ) voor elke seconde performance-berekening
- RAK24 voor het plannen van de route. Dat vreet CPUcycles; zomaar een half uur of langer 100% cpu.
- dan af en toe even over de hotspot 30 Mb harmoniegrib ophalen

Dan eet de PC de volle 5 A die hij aan kan en gaat de ventilator op volle toeren.
Ik denk dat een RPi ervan zou smelten
mhsprang schreef :
Factor 11 bloatware. En geen toegevoegde waarde, want de data zijn nog steeds wat er al in die RMC stond....
Voldoet wel aan de 1e wet van Bill Gates:
"software has an unlimited capability to eat up cpu cycles" .

Even over de wifi die reuver noemde:
SailingPD doet nu een COM-poort lezen (echte of virtuele), en voor de Linux-liefhebbers luistert het binnenkort ook naar een TeleType Zie onder.
Ik ga ervan uit dat mensen die SailingPD willen gebruiken al een ander stukje software draaiend hebben voor navigatie of zo. Die software kan dan via wifi NMEA krijgen (al dan niet 11 keer opgeblazen via Signal K) en de recordjes vervolgens weer aanbieden via een virtuele COM aan SailingPD. OpenCPN kan dat (Froufrou gebruikt het zo).
Ook is er voldoende software die een verbinding (COM, TCP, UDP, wifi) kan splitten in meerdere viruele COM-poorten.NavmonPC kan dat, met uitgebreide routing-mogelijkheden, Franson GPSgate kan het ook. Beide gratis.
(terzijde: weet iemand of een Signal K server ook een virtuele COM kan aanmaken? Dat zou wel leuk zijn. NMEA-in, 11 keer bloaten, weer terugkrimpen, en dan NMEA183 er weer uit
Bijna net zo erg als PC-to-PC FAX.....)
Bovendien wil je soms dat de NMEA die uitgestuurd wordt door je navigatieprogramma (naar AP en instrumenten) ook weer in SailingPD binnenkomt. De RMB uit de navigatie wil je zeker in SailingPD hebben, dat levert heel veel info (layline, ETE, VMGwp etc).
Dus je moet dan een verbinding tussen die 2 programma's hebben. Dat kan prima met NavMonPC. Simpel de output (iig de RMB uit de navigatie) routen naar SPD. Het zal ook via de mux kunnen denk ik.
Al met al voldoende redenen om geen wifi in SailingPD te ondersteunen. Het veroorzaakt extra complexiteit voor de gebruiker en het zal minder stabiel zijn. Ten minste 24 uur zonder enige hik blijven werken is wel een eis

en.wikipedia.org/wiki/Teletype_Corporation

Baasklusje schreef :
RPM, das toch: Real Performance Measurement?

Real Performance Monitor Engine!