Onderwerp: Sailing Performance Dashboard op de Raspberry Pi

Jumpinjack schreef :
Wat uit de webserver komt zijn wel de waarden die ik ook op het scherm van SPD zie.
Zou het ergens in Node Red mis gaan???

In de node red flow zit een debug node die je aan kan zetten zodat je kan zien wat de websocket ontvangt. Heb je een voorbeeld bij welke waarde het mis gaat? Er zit natuurlijk wel op verschillende plaatsen omrekening m/s - kts, deg - rad. Er kan nog wel wat missen, maar dat is zo aan te passen..

Eigenlijk op een hele berg variabelen, maar t probleem zie ik in de performance %.
Als in chromium de websocket lees dan zie ik bv AWS 13.1
In signalk en node red zie ik environment.wind.speedApparent 6.53
Maar dat zijn eenheids conversies m/s vs kts dus dat klopt wel.

Maar voor performance.polarSpeedRatio zie ik bv 39.1 in signalk\node red , en rond de 80 in SPD.
Er is geen eenheids conversie hiervoor, toch?

Ik zie voor de performance variabelen (%) in node red ook de kts/ms conversie er voor. Daar zal t probleem zitten.

Performance is al uitgerekend toch…? Die zou enkel en alleen gemapt moeten worden..

Gewoon een truuk om te proberen mij 2x zo hard te laten zeilen

Jumpinjack schreef :
Dat heb ik nou tegen signal K

Zelfs als je kant-en-klare data aanlevert moet er per sé iets mee gedaan worden en wordt de informatie verneukt.

Het is een eenheden verhaal denk ik met wellicht nog wat bugjes in de node red conversie en/of de hanst plugin.

SK streeft SI na: snelheid in m/s, RPM in /s, hoeken in radialen, performance als fractie bv. 0183 heeft vaak meerdere eenheden in een sensence, 2000 soms een keuze. Er moet vanuit de SPD output totdat de data op de klokjes staat dus soms 2x omgerekend worden.

Heb even de eenheden conversie m/s - m/s gemaakt (uitgezet dus) voor de performance %'s.
En dat geeft het juiste resultaat.

Is makkelijk aangepast , dat is dan weer t voordeel van signalk / node red

Hallo,

Fantastisch werk allemaal. Ik heb nu SPD ook werkend op mijn Pi, inclusief SignalK, afspelen van filestream (ik zie de Capolavoro vrolijk varen bij Texel op OpenCPN). Polar via preprocessor ook allemaal gelukt. Het gaat me benieuwen hoe dat straks gaat helpen.


Ik heb wel wat moeite met de ‘sendoverwifi’ configuratie. Ik gebruik de Pi als access point en multiplexer met VNC als client op het AP. Als ik de ethernet kabel thuis uitplug, blijft SPD klagen ‘cannot send UDP messages’, welke UDP settings in SPD ‘sendoverwifi’ ik ook probeer. Ook als ik UDP messages op ‘N’ zet. Ik zou eigenlijk verwachten (en hopen) dat de messages op het lokale AP network gebroadcast worden, net als de SignalK TCP data. Hebben jullie een idee wat goede configuratie settings zouden kunnen zijn voor een Pi met alleen een AP maar zonder externe internet verbinding? De manual geeft niet genoeg houvast.
Volgens mij verder alles standaard ingesteld:
- AP: 192.168.4.1
-SignalK: 127.0.0.1 naar 10110, zichtbaar in SPD en OpenCPN, en op externe tablet

Groet, Patrick

De start van de webserver en de UDP-socket voor zenden (zoals gedefinieerd in sendoverwifi) gebeurt maar 1 keer, bij de start van SPD.
Je kunt dus NIET live veranderen daar.
Wel de selectie van UDP-berichten en ook de webserverdata (via webserverselection) maar niet de 'harde' eigenschappen van de socket en de webserver-queue. Daarvoor is opnieuw starten nodig.
Helpt dat?

Nee, helaas niet. Ik snap wel dat je niks live veranderen kunt. Maar blijkbaar snap ik dus niet goed genoeg over hoe UDP werkt en hoe uitzending vanuit SPD op een lokaal pi AP werkt.

Nogmaals, als ik naast het AP ook een verbinding met mijn home netwerk heb, kan ik daarop wel de UDP messages zien op de ingestelde port (5005). Daar zie ik dus wel udp messages op het home network, maar niet op het pi AP network.

Mijn verwachting zou zijn dat je ook de UDP broadcasted messages op het pi AP netwerk kunt hebben en ‘afvangen’. Ook als er geen verbinding is met een extern netwerk. In plaats daarvan krijg ik dus de error melding, en daarnaast zie ik niks in de UDP monitor. Het hoeft van mij voorlopig nog niet terug naar SignalK en zo wat michaelh kan, maar de error message begrijpen en de udp berichten zien is voldoende.

De zender (Pi met SPD) de ontvanger van UDP moeten wel in hetzelfde netwerk zitten.
Een internetverbinding is niet nodig....

Dat zitten ze zeker… Opencpn, SPD en SignalK op Pi, en telefoon en tablet op AP hotspot van dezelfde Pi. Foutmelding cannnot send UDP..

Maar: ethernet kabel erin, en tablet en telefoon op Home wifi network, en voila, alles werkt conform verwacht.

Groet, Patrick

We hebben al eerder gezien dat python op de pi kieskeurig is voor een bind op de juiste interface. Welke mogelijkheden heb je al gehad?

Volgens mij heel wat
- no messages, dus op ‘N’
- no webserver, op ‘N’

UDPip:
- 255.255.255.255 (broadcast?)
- 192.168.4.1 (pi AP self)
- 192.158.4.255
+ vs ports
Webserver
- 192.168.4.1
- 0.0.0.0
- localhost
- 127.0.0.1 (SignalK)
- 128.0.0.1 (gewoon iets proberen)
+vs ports

En dit dus in allerlei Y/N combinaties.

Eigenlijk zou ik moeten weten wat er precies in python staat wanneer de aanroep de foutmelding oplevert.

Groet.

Stukje code voor het verzenden van NMEA over UDP:

Dezelfde regels natuurlijk voor 18 andere NMEA berichten dan deze VTG.

let op: NMEA gaat eruit over SP_NMEA_IP,SP_NMEA_PORT , beide in te stellen in boatspecifics.
(dus niet over de port die in sendoverwifi is opgegeven voor de non-NMEA-messages.)

Aha.
Die laatste zinnen doen het.
Als ik IP van AP hotspot invul als volgt (zowel in bootspecifics als sendoverwifi): 192.168.4.255
Dan werkt alles, fout weg, UDP komt binnen. What a wonderful season it will be…
Nu nog proberen aan alle regels van de 24 uurs te voldoen, driekleurenlicht en zo
Thanks.

Uit nieuwsgierigheid, welke nmea berichten ga je versturen en waarheen?

Voorlopig niet heel veel bijzonders hoor.
Ik wilde aanvankelijk eigenlijk alle belangrijkste gegevens snelheid, wind, diepte op de de tablet hebben, daarop navigeer ik met OpenCPN. Maar ik heb nog geen boord netwerk. Dus ik heb een Pi ingericht met als bedoeling multiplexer, als experiment om te kijken of ik inderdaad al het ST60 spul kan verbinden. De boot is uit 2005, dus het werkt allemaal, maar nog niet met externe devices. Maar op de Pi werkt nu ook SPD, dat is helemaal geweldig als lerend zeiler, dus dan wil je de hoofd-performance getallen natuurlijk ook naar de tablet hebben, en de trim tips. Eerst via VNC naar de Pi, dat werkt nu al, maar later misschien met extra geprogrammeerde schermpjes.

Ik had natuurlijk ook een kant en klare oplossing kunnen kopen, maar je moet toch wat in de winter.

Krijg hier UDP ook binnen via signalk.
Maar, daar komt de XDR en DIY messages niet bij mee.
Lijkt er op dat node-red hier de beste manier is.

Jumpinjack schreef :
Wel aangezet in boatspecifics en $data erin? DIY is default leeg...

$SPDIY,$advice1,$advice2,$advice3

[NMEAoutput]
MTW = N
RMB = N
VTG = Y
GLL = N
BOD = N
BWC = N
BWR = N
MWV = N
VHW = N
VLW = N
RPM = N
XDR = Y
NKEP = N
SMDPRFW = Y
SMDPRFP = Y
MVW = N
MVP = N
DIY = Y

DIY had ik toegevoegd in de boatspecifics.
Aan de nmea messafe definitie niets gedaan.

Nog even gechecked, messages staan in de nmeaout log file. Ook met bv perf getallen wordt t niet door signalk gehapt.

dan moeten ze meekomen, die XDR en DYI.
de beide SMDPR kunne wel uit, die zijn leeg.
Snapt Signal K XDR en DYI wel?

En kan je ze zien met een UDPviewer op SP_NMEA_PORT ? (ik wel)

Er vanuit gaande dat de XDR juist gevuld is kan je die in signalk krijgen met een xdr-parser-plugin. Voor de diy moet je zelf een signalk plugin schrijven. Ook niet lastig, maar dan is de node red route toch makkelijker en flexibeler.

Via serial werkte de xdr parser plugin prima, via udp niet. Zou ik moeten zoeken waar dit zit.
Voor nu wordt t node-red. Met de laatste tweaks makkelijker.