Onderwerp: Sailing Performance Dashboard op de Raspberry Pi

hanst en andere Triton2 gebruikers,

In het sailsteer display en laylines display is te kiezen waar de data van de te plotten laylines vandaan komt:




Hebben jullie geprobeerd die data via de plug-in aan te leveren worden? Ik heb al wel de Target TWA voor elkaar, maar die lijkt het niet te zijn…

SPD interpoleert de target TWA op basis van de polarTWSen rond de actuele TWS.
Je zal dus niet zomaar een target TWA uit de polar zien, tenzij de TWS precies een TWS uit de polar is.
Geen idee hoe de Triton2 dat doet....

In veel polars zit er rond 13 TWS een flinke knik in de DA, zomaar van 150 naar 175 graden. SPD levert de geinterpoleerde DA.

Je hebt de target wind angle op polar gezet? = h5000 = spd

Baasklusje schreef : De triton/zeus zelf? Prut: met grote sprongen.
Neem aan dat de h5000 dat beter doet, maar beter dan spd zou me verbazen eigenlijk.

Ik kan het nu niet testen, maar ik verwacht dat de Triton2/Vulcan/Zeus SPD TWA kunnen laten zien als laylines als:
- True Wind Direction beschikbaar is.
- B&G performance plugin Target Wind Angle doorgeeft
- Triton2/Zeus/Vulcan op 'polar' staat.

Mijn verwachting is dat op de stand 'polar' de unit niet zelf een TWA gaat bedenken (bijv via fixed manual), maar de TWA van buiten verwacht, typisch van de H5000, maar nu dus van de B&G performance plugin.

Dat verwacht ik ook.

Jumpinjack schreef :
Zo is dat

Ik noem even een paar kleinigheden:
- AWA gecorrigeerd voor helling, drift en upwash
- AWS gecorrigeerd voor helling
- AWA en AWS naar keuze te dempen door wat waarnemingen te middelen
- TWA en TWS te berekenen met watersnelheid (die gecorrigeerd is voor afwijkingen per snelheid en helling)
- TWA en TWS ook te berekenen met (iets gefilterde) SOG in de lengterichting van de boot.
- TWS genormaliseerd voor 10 meter hoogte (zoals in de polar)

Als dat geen goede True Wind oplevert....

De html pagina met websocket werkt:



Wat betreft opmaak kan het vast beter maar goed, het is een begin....

Ik heb hem naar Baasklusje gestuurd in de hoop dat hij hem even checkt.

hanst schreef :
Er lijkt meer voor nodig te zijn

Op dit moment geef ik onderstaande data aan de Triton, target TWA staat daar bij (Triton berekent zelf TWD en die wordt netjes in de Sailsteer pagina weergegeven)


Als ik handmatig de target angles in wil voeren, wordt gevraagd naar UA én DA:


De plugin geeft er maar één door nu. Dat kan ofwel UA ofwel DA zijn, afhankelijk of TWA voor of achterlijker dan dwars inkomt. Zou dit scherm dat verwachten, twee verschillende target hoeken tegelijk? Als ik nu “Polar” kies als target angle input, gebeurt er niets in elk geval

Een ander punt is de “laylines” pagina. Die is niet beschikbaar bij mij. In de handleiding staat dat daar een H5000 voor aangesloten moet zijn. Op basis van welke PGN ziet een Triton dat!?

PS: ik denk dat sowiezo die “opposite track heading” doorgegeven moet worden? En er zal een waypoint aktief moeten zijn. Bijft over die laylines distance en TTG (voor beide laylines). Zou de triton dat zelf berekenen, of zal dat ook van buiten moeten komen?

Version 3.3.7 of 25 March 2022
- In the webserver data the value (in degrees) of a detected windshift was overwritten by the text of a shift message. This is now corrected, by changing the key windshift in webserverselection.txt to windshift-deg. If you use webserver data, please change this key.

- A new value is added to the webserver output: the version of SPD . Key used in webserverselection.txt is SPD-Version .

Ik ben nu wat aan het pielen om te kijken wat er voor nodig is. Heb nu zo'n beetje alles aangezet, maar krijg nog geen laylines.

Wel in de Data Sources nu een onderdeel 'Layline' met daaronder
- Heading on Opposite Tack (default) (die is er)
- Distance to Layline (is er niet)
- Time to Layline (is er niet)

Ik heb wat dingen geprobeerd en ook gekeken of ik Distance to Layline en Time to Layline kan toevoegen, maar dat is nog niet gelukt.

Volgens de H5000 SailSteer page:

Hier lijkt 'actual' dus de Target TWA te moeten nemen. Kun je dat eens proberen?

Beetje onduidelijk.....
De target lijkt me de UA of DA uit de polar voor de actuele TWS.
Dat zou de optimale laylines moeten opleveren, als je echt die UA weet te zeilen zonder drift.

De actuele TWA is realistischer. Die zeil je echt, vermoedelijk iets ruimer dan de UA.
Dat levert net wat andere laylines op, maar wel degene die je nodig hebt bij deze TWA.
(eigenlijk moet het TWA + Leeway zijn....)

Overigens moet je altijd bij laylines uit de buurt blijven.
Als je doorvaart tot de layline verspeel je al je mogelijkheden als de wind iets draait.
Als er een header komt kun je eigenlijk niet overstag want je zit al helemaal aan de buitenkant, en als er een lifter komt overzeil je je waypoint.
Het ziet er leuk uit, maar je hebt er weinig aan

Die Target TWA is de input, samen met TWD en Opposite Target TWA.
Die kunnen uit de polar komen, maar zouden, zoals je zegt, meer actual moeten zijn met leeway etc. Dat is wat de SPD of de H5000 voor je uitrekend.

Waar het mij mij om gaat is wat die layline op het scherm bepaald, niet wie die berekend.
SPD kan het berekenen en dan met B&G Performance plugin die waarde doorgeven aan de displays.

Als het goed wordt berekend en je gebruikt het goed (dus niet als TomTom), dan lijkt het mij wel waardevol om het zo grafisch in beeld te hebben.

Misschien ten overvloede, maar er moet wel een waypoint actief zijn om laylines te zien.

Gepost met de officiële Zeilersforum-app

Ik ben in SPD de routine voor Distance en Time to Layline aan het vervangen door een betere.
Met de hoek tussen COG en BTW , de DTW en de TWA kun je voor elke TWA uitrekenen hoe ver het nog is naar de layline. Maakt niet uit of de laylines haaks op elkaar staan of niet. (en dat is zeker niet zo bij afkruisen!).
Voor veel schepen zal die 90 graden niet kloppen. Ze varen hoger of ruimer, hebben meer of minder drift (golven!) enzovoorts.

De nieuwe routine neemt aan dat de TWA na tack of jybe hetzelfde is als ervoor (namelijk in de buurt van de UA of DA, je bent immers aan het op- of afkruisen). Of je daarbij in de buurt zit moet je zelf blijven checken

Stroom neem ik niet mee. Die kan en zal veranderen terwijl je vaart (kentering, afname, toename, andere geul) dus een voorspelling doen over stroom op een volgend rakje is per definitie een gok....

Als SPD eenmaal headless draait, heb je er geen omkijken meer naar. Bij een update of als je een config aanpassing doet, kan het echter zijn dat er met de data of met het opstarten iets mis gaat.

Om het beheer makkelijker te maken heb ik 2 wensen:
- In headless mode de applicatie niet stoppen als er geen data is.
- in headless mode bij het opstarten de output ook in een log file wegschrijven zodat ik kan vinden waar het mis gaat.

SPD draait als een service op de pi en je wil de output daarvan makkelijk terug kunnen vinden en je wil niet dat die service stopt.

Voor de eerste wens is er de optie run on empty. Is die niet voldoende?

Voor de tweede, mag dat naar de std out van Python?

Baasklusje schreef :
Bij Run On Empty in combinatie met web kreeg ik vreemde resultaten, maar dat zou het wel moeten doen. Ik zet headless nu op printer in plaats van web om eerst maar eens alle output te zien. Als je bij web ook alle output naar std out schrijft voor het opstarten van de websocket, zou dat al veel helpen.

Ik krijg nu deze melding. Mogelijk omdat een bestand niet gevonden of gelezen kan worden?
Sailing Performance Dashboard: Deadly Error. Headless cannot be combined with no for samefiles, Program stops

Het ook naar printer sturen van alle meldingen igv headless web is simpel, dat kan ik zo toevoegen.
Dat zal vast geen problemen elders geven.

Het (vertraagd, Msg delay web = 5 ) lezen van die meldingen via de webserver werkt niet goed genoeg?

Met altijd doordraaien heb ik wel een probleem.

Hoe het nu werkt:
er wordt eerst het gekozen channel geopend (serial, UDP, TCP) en getest op de aanwezigheid van de juiste NMEA. Er moet een RMC en een VWR of MWV zijn. Zo nee, dan stop.

Als dat slaagt dat gaat de loop in SPD draaien om records te vinden.
Daar kan wat in fout gaan: zender stopt, Serial stekker eruit, TCPverbinding onderbroken, UDPzender stopt.
Dan 'gewoon doorgaan' leidt tot een hangend SPD (eindeloos wachtend op NMEA).

Om de zaak weer aan de praat te krijgen moet eerst het channel weer werkend gemaakt worden.
Voor serial is dat het openen van een COM (of TTY) poort, voor TCP het maken van een socket en dan de verbinding connecten. Die dingen gebeuren nu veel eerder in SPD (voor de loop).
Herstellen binnen de loop zou wel kunnen, maar er is geen enkele garantie dat het dan wel zal werken (de USBstekker kan er nog steeds uitliggen, etc).
En dan hangt de boel alsnog.

De gekozen oplossingen:

- serial: stoppen met een foutmelding, na een time out van 10 seconden (tegen hick ups).

- TCP: stoppen met een foutmelding, na een time out van 10 seconden, TENZIJ Run on Empty = Y: dan wordt 6 time outs (samen 1 minuut) gewacht of er nog iets komt. Die 6 kan meer gemaakt als dat helpt...

- UDP: stoppen, met een foutmelding, na een time out van 10 seconden, TENZIJ Run on Empty = Y: dan wordt eindeloos gewacht of er nog iets komt. UDP heeft geen verbinding, is alleen luisteren, dus kan eindeloos wachten en SPD zal doorgaan als er weer data komt.

De melding "Deadly Error. Headless cannot be combined with no for samefiles, Program stops" krijg je omdat je nu headless printer gebruikt.
Dat stelt SPD de vraag of de vorige files (boat, polar etc) weer gebruikt moeten worden.
Daar moet een antwoord op getypt worden
yes , en de files worden gebruikt.
iets anders (ook een lege enter) betekent no, en dan moet je filenamen gaan opgeven. Dat is dan weer onmogelijk when headless.... en dus een deadly error.

michaelh schreef :
Dat gebeurt al....
de webserver wordt zo snel mogelijk gestart, maar dat kan pas na het inlezen van sendoverwifi.ini.

Voor dat moment gaan alle meldingen naar printer (std out), want de webserver queue is er nog niet.
Dat zijn:

"Directory not correctly chosen or no picture background.gif"
"File error","Sendoverwifi file gone or damaged. Default values now active for all keys."
"Processlist file gone or damaged. Default values now active for all keys."

Bij de eerste stopt SPD want hij heeft geen idee waar alle files ergens staan.
Bij de 2e en 3e gaat SPD door met default values (zie manual), en dat kan zeer vreemde effecten geven

Na een succesvol inlezen van sendoverwifi.ini wordt de webserver queue gestart en komen de meldingen via de webserver.

In headless web mode worden alle berichten nu ook naar de standaard output geschreven (web en printer dus).
Hoeven onze headless friends niet zo snel meer te lezen.

Ook herstarten van TCP en serieel na uitval verbinding ingebouwd. Zie

zie zeilersforum.nl/index.php/foru...d?start=1275#1394149

Baasklusje schreef :
Langzaamaan gaat het weer wat doen. De web output doet het weer. Enige is dat ik niet de web/printer output meldingen krijg die ik verwacht. Waarschijnlijk staat er ergens in een file een foute waarde.

Bij web zie ik het volgende in de output:

SPD Running cheapo headless, headless.txt exists. Using web
Traceback (most recent call last):
File "sailingPD.py", line 823, in <module>
LookupError: unknown encoding: idna
[70] Failed to execute script 'sailingPD' due to unhandled exception!

En bij printer zie ik het volgende in de output:

SPD Running cheapo headless, headless.txt exists. Using printer
Traceback (most recent call last):
File "sailingPD.py", line 1655, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character '\U0001f601' in position 0: ordinal not in range(128)
[110] Failed to execute script 'sailingPD' due to unhandled exception!

Als ik weet wat daar gebeurt, ben ik waarschijnlijk weer een stap verder.
Over het snel lezen: van Menno begreep ik dat er een queue is voor de web output en dat er meldingen weggegooid worden als de queue vol is. Nu komen er alleen bij het opstarten veel meldingen tegelijk. Misschien handig om die queue wat groter te maken, zodat er bij het opstarten ook voldoende ruimte is en de meldingen niet vertraagd hoeven te worden?

regel 823:

thisPC_IP=(socket.gethostbyname(socket.gethostname()))

wellicht werkt die functie niet (goed) op de Pi?
Zou toch wel moeten, is standaard Python.

Regel 1655: if printer: print(hl, shiftmsg) (# printer True is igv headless)

Daarin zit unicode '\U0001f601' : een smiley.

Kan de Pi niet tegen zeker?

Het gaat bij jou daarmee nu fout omdat de web-output nu ook allemaal in printer terecht komt....