Onderwerp: Sailing Performance Dashboard

Baasklusje schreef :
Maar natuurlijk veel beter dan XML.

nobody schreef :
Tsja, dat moderne Linux toch

In een Model 37 heb ik zo rond 1974 nog eens een bekertje koffie laten vallen. Daar houden ze niet van. Grote kortsluiting in een apparaat van 160 kg zwaar..... Maar wel het begin van RS232 serial!

Ik heb helemaal niets tegen XML. Dank zij XML etc hebben we nu al die mooie koppelingen tussen toepassingen via het internet. Maar XML gebruiken om iets 11 keer zo groot te maken en inhoudelijk niets toe te voegen.....

Werkt windows serieel protocol nog steeds met hardware interrupts of emulatie daarvan ? Modern !

nobody schreef :
Er is wel wat verbeterd natuurlijk.
Van de 25-pins stekker zijn we naar 9 pins gegaan en nu (USB-C) zijn we weer terug bij 24, met veel meer snelheid en functionaliteit.
Zit verbazend veel in zo'n klein USB-C stekkertje!

@Baas , google even op hardware interrupt.

nobody schreef :
Maak je geen zorgen
Ik ken alle 25 pinnen van de RS232 nog uit mijn hoofd.
En ik heb hier nog een Commodore PET 1977 met op een van de pinnen van de bus die eruit komt een rechtstreekse verbinding met de NMI van de Rockwell 6502 processor.
Die heeft een IRQ-pin en een NMI-pin.
Weet jij nog waar NMI voor staat?

Nog even over de CPUbelasting.

NavmonPC leest een NMEAlog (van de Frou frou die net het Molengat in vaart) op afspeelsnelheid 1 (is ongeveer 1 set records per seconde, net als in het echt)
NavmonPC speelt de records door naar WinGPS, dat met 1/sec de kaart updated.
NavmonPC speelt de records ook door naar SailingPD.



Op de CORE i5 met 8 Gb geheugen krijg je dan dit, gesorteerd op CPUgebruik:



Lijkt me geen goed framboosplan.

Baasklusje schreef : Dat was 10 jaar geleden misschien zo, maar tegenwoordig wordt er denk ik minstens net zo veel JSON gebruikt voor dat doel.

Vast wel, het is wat sneller en makkelijker. Maar het zijn wel broertje en zusje....
Ik ben nog uit de tijd dat je over elke bit zelf moest nadenken.
Met een 55 of 110 bps verbinding liet je het wel uit je hoofd om van 66 bytes in een RMC-bericht 900 JSON bytes te maken
Dan perste je in 1 byte steeds 2 characters als dat toevallig kon en had je er maar 33 nodig

Ooit heb ik de Basic interpreter in de Apple II en de Commodore PET 2001 ge-disassembled, om te kijken hoe dat ding werkte. Het was dé Basic interpreter in alle micro's met een 6502 processor vanaf 1977.
Het ding is door Bill Gates zelf geprogrammeerd, met Paul Allen (de 2 oprichters van MSFT).
Het vreemde was dat, afhankelijk van waar(welk geheugenadres) af je de disassembly deed, er vaak een heel ander programma tevoorschijn kwam.
Nu heeft die 6502 1-byte opcodes en dan 0, 1 of 2 bytes data erachter.
Disassembly vanaf adres 0 (waarbij adres 1 dus vaak de data van de opcode op adres 0 was) toonde een heel ander programma dan disassembly vanaf adres 1.
Je zou zeggen dat adres 1 data was van de opcode op adres 0, maar die waarde was ook een opcode. Enzovoorts.
Gates heeft dat dus expres zo gemaakt: hele stukken geheugen die twee of meer verschillende programma's TEGELIJK bevatten, net afhankelijk van waar je begon. Dat bespaarde flink op de 4 k geheugen die de Basic interpreter mocht gebruiken
Zo zuinig waren we vroeger, jongelui

Prachtig stuk werk maar ik ben van mening dat er over de gehele GUI nog wel het één en ander te verbeteren valt. Die ziet er op zijn zachtst gezegd nogal gedateerd en onoverzichtelijk uit. Frontend is ook een geheel eigen specialisme. Ben zelden programmeurs tegen gekomen die daar iets van bakken.

SailingPD schreef :
Boatcontroller in combo et Actisense? Heb overigens begrepen dat de nieuwste BC een directe NMEA 2000 zal hebben.

silerberend schreef :
Ik wilde gewoon zoveel mogelijk cijfertjes en een paar met natte, koude vingers te bedienen knoppen. Dat is gelukt
Voor mensen die niet meteen weten wat elk cijfertje betekent ziet het er inderdaad verwarrend uit.
Moeten ze hun best maar doen.

Eigenlijk is het nauwelijks een GUI.
Geen menubalk, geen uitklappende menu'tjes, niets wat je op een bewegende boot niet lekker kan bedienen. Geen wijzertjes op niet-leesbare wijzerplaten.
Alleen 100% pure informatie, geen toeters en bellen, ook geen spiegeltjes en kraaltjes.
Ook geen Facebook-integratie om meteen je ervaringen te kunnen delen.

En helaas kan het gemiddelde (of bovengemiddelde) menselijk brein dat niet verwerken. Gevolg: geen acceptatie. Dan is het niets meer of minder dan een leuk projectje van een paar nerds. Zou erg jammer zijn.

Och, waarom?
Bij ons wordt de weergave buiten maar zeer beperkt. De rest laten we voor wat het is, dat staat binnen op de pc waar niemand kijkt.
Daarbij, die hele materie is al geen kattepis om echt te gebruiken in je zeilactiviteit. De selectie heeft vooraf al wel plaatsgevonden vermoedelijk.

Een vraag die zomaar opborrelt:
Kun je ook sec de gecorrigeerde snelheid en koers laten zien n.a.v. de deviatietabel en de stw correctie?

holtere schreef :
Je bedoelt de HDGc en de STWc die op het scherm staan?
Die zijn nu niet als variabele beschikbaar voor in de NMEArecords.
Wel de onderdelen ervan, dus de gemeten waarden en de correcties.
Die 4 zitten wel in de logrecords.

Wil je 2 variabelen erbij voor op je meters? 5 minuten werk. Zeg het maar.

Dat is misschien niet gek toch?
Heb je meteen de juiste waarde mits je tabellen kloppen.
Of ben ik de enige?

silerberend schreef :
Je moet dat scherm zien als een naslagwerk: even iets opzoeken als je ergens over twijfelt.
Het is niet om de hele tijd naar te kijken.

De meest relevante info komt al op je displays in de kuip, naar eigen keuze uit 40 variabelen.
Kan ook op je telefoon of tablet, en over een tijdje vast wel via een webserver naar een appje.

Bovendien kun je elk windowtje van het scherm wegklikken en alleen overhouden wat je wilt.
Voorbeeld staat in de manual:

WinGPS met performance erin.

holtere schreef :
Zelfs als je de enige bent maak ik het even.

edit: klaar. $hdgc en $stwc. Wel even wachten op versie 1.7.5

Baasklusje schreef :

Yazz schreef :
Idd... Was wel handig als die 6502 weer eens op de loop ging

Baasklusje schreef :
Zoals je in je logbestanden zou kijken? Begrijpelijk. Maar dat lijkt niet helemaal alleen de bedoeling te zijn zie het getoonde voorbeeld in Wingps. Ik heb zeer grote waardering voor de geleverde prestatie. Maar mijn advies blijft. Wellicht is er op ZF iemand die er, echt los van alle techniek, naar zou willen kijken. Hoe je informatie rubriceert, rangschikt en presenteert op een manier dat die door mensen makkelijk te verwerken is, is een wetenschap op zichzelf. Ik gun dit project iemand die dat beheerst. Ik zou zelfs willen aanraden om actief naar zo iemand te zoeken. Veel succes met project.

Omdat de wijze waarop je variabelen uitrekent me fascineert. Naar aanleiding van een achter de schermen discussie met Baasklusje is even de interesse bij mij gewekt of er verschillen zouden zitten tussen de snelheid over de grond als je die uitrekent op basis van positie A en positie B 60 seconden na elkaar en de gemiddelde SOG direct uit de gps.
Wat bijkt. Weinig verschil. Tussen de 1-2%

Gevaren route (als gpx, zichtbaar gemaakt in openCPN)





excel bestand toegevoegd.

silerberend schreef :
Nee, in de log kijk je pas achteraf, om samenhangen en zo te vinden. Ik vaar inmiddels een jaar of 15 met Tactictool (simpelere voorloper) en na een wedstrijd zit er heel veel erg nuttige info in zo'n log. Je kan per overstag zien hoeveel roer je gegeven hebt, hoe snel je weer op snelheid bent enzovoorts enzovoorts. 's Nachts blijken mensen rechtere lijnen te sturen dan overdag (lichtje in de boei die je overdag nog niet ziet). Is dat goed of slecht? Dat blijkt dan weer uit de performance. Enzovoorts.

Met naslag bedoel ik:
- even naar de kaartentafel, kijken of de verwachte stroom er al is en hoeveel
- even zien of de wind over de grond al aan de voorspelde ruiming of krimp begonnen is
- checken hoe lang het nog is naar een layline
- en ga zo maar door.
Het is net als in een vliegtuigcockpit. Heel veel metertjes, de meeste niet bedoeld om de hele tijd naar te kijken. Dingen die je niet elke seconde wil weten, maar wel elk half uur of zo.

De dingen die je wel elke seconde wil weten staan voor je neus op een display of je handheld:
performance, afwijking van optimale UA of DA, VMG etc.

Ik ben het met je eens dat programmeurs geen ideale ontwerpers van userinterfaces zijn.
Ik ben dan ook geen programmeur, maar wel ooit opgeleid tot psycholoog, specialisatie funktieleer, en dat gaat voor een heel groot deel over perceptie: waarnemen

Heb je een voorbeeld of idee hoe zo'n scherm eruit moet zien voor me?
Er staan nu 56 variabelen op. Per groep aan of uit te zetten. En dus terug te brengen tot nul. Black box die NMEA uitzendt naar je meters.
56 dials kan niet. Veel moeten bedienen om even iets tevoorschijn te halen kan niet (geen tijd, natte handen, bewegende boot, muis weggerold).

3Noreen schreef :
En gemiddeld 0,59 % afwijking....

Nou zit er in die 2 posities A en B al ruis, en in de GPS-SOG ook.
Vermoedelijk zijn ze alle 3 al uitgebreid gefilterd voordat je ze te zien krijgt, dus de ergste ruis zal er wel al uit zijn.
De berekeningen die een GPS uithaalt om uit 3+ satellieten posities te vinden zijn complex....

Wat ik nou eens zou willen weten:
als je op hogere frekwenties data gaat aanbieden (10Hz GPS, 10Hz kompas en andere sensoren), hoeveel meer ruis introduceer je dan?? Elke meting heeft een meetfout, 10 metingen hebben er 10.
Die kun je dan weer filteren/middelen, maar wordt het resultaat daar dan beter van als je naar waarnemingen op menselijke schaal gaat kijken (zeg 5 a 10 seconden gemiddelden)?
Dat het voor een AP wel nuttig is lijkt me duidelijk.