Onderwerp: Sailing Performance Dashboard

Kijk die uitleg heeft weer een stuk geholpen.
Ik kan het programma nu opstarten en de NMEA data komt binnen. We zijn op de goede weg.

Krijg wel nog een paar meldingen maar die kloppen neem ik aan omdat ik op dit moment stil lig in een box.

Wat moet je doen om het op een rpi werkend te krijgen? Ik heb alles uitgepakt in een folder, hoe start ik het nu op?

zeilbootje schreef :
Eerste melding is welke records gevonden zijn die gebruikt gaan worden.
Als er geen RMC (SOG en COG) en/of geen VWR of MWV (wind) gevonden wordt stopt SPD. Het gaat dus goed.

Tweede is dat er geen records met Heading binnenkomen. Die komen meestal uit een kompassensor van de stuurautomaat. Heb je die?
Gek is dat er weleen HDGc in beeld staat in het Course window.
Dat wijst op een HDG-bericht.

SPD kijkt de eerste 150 records even na, om te zien wat er binnenkomt.
Als daar geen heading bij is krijg je dit tweede bericht.
Kan best zijn dat er bij die 1e 150 geen hdg zat, en later wel.

Veel plezier ermee! Lekker op knopjes drukken en naar de cijfertjes kijken

XanderB schreef :
Eerst je gewenste boatspecifics file maken en dan in de folder sailingpd.exe aanklikken.

Vandaag SPD eens flink onderhanden genomen wat betreft de NMEA-verbinding over TCP en UDP.
De uitdaging daar is dat je niet weet hoe de NMEArecords via die netwerkverbindingenn binnenkomen.

Bij Serial, COM, is het simpel. Steeds een regel lezen van de COMpoort (tty) en dan heb je 1 NMEArecord.

Bij TCP en UDP kan dat anders zijn.
Daar gaat SPD een vast aantal bytes lezen (ik doe 512).
En daarin zitten dan meerdere NMEArecords.
In 512 bytes gaan er gemiddeld een stuk of 15.
Bijvoorbeeld NavmonPC doet dat, die stuurt lange berichten.
Bij UDP gaat het soms gelukkig handig per record.

Die lange berichten worden dus nu keurig uitgesplitst, dat was eerder niet zo netjes geregeld.

Er kunnen nog steeds verrassingen zijn; allerlei apparaten kunnen dat aanbieden van NMEA toch weer op hun eigen manier doen.
Eerst nog even aan boord met de Miniplex UDP en TCP testen, en dan komt SPD 3.8.0
Handig voor mensen met een Vesper, @NV Minder hickups!

Hé mooi, dat zou fijn zijn: hoef ik niet meer via die COM-omweg!

Gisteren de eerste log kunnen maken tijdens het varen, zie bijgevoegd bestand (indien het interessant is). Ik had alleen geen snelheid door het water, het schroepradje zat vast. Vandaag schoon gemaakt en morgen weer een log maken.

Mijn Windows PC en scherm is binnen gemonteerd en kan ik niet vanaf het stuurwiel zien. Ik wil dus de webserver functie gaan gebruiken zodat ik op de ipad buiten de info te zien krijg. Alleen krijg ik de web-serer niet werkend.

Heeft SPD zelf een web-server ingebouwd? In het sendoverwifi bestand zie ik wel het volgende staan:

Webserver = Y
Webservername = 0.0.0.0
Webserverport = 9090

Maar de bestandsnaam (sendoverwifi) suggereerd dat de gegevens naar een web-server worden toegestuurd. Echter het systeem diagram van SPD geeft aan dat er een web-serer ingebouwd is. Wanneer ik localhost:9090 of 127.0.0.1:9090 invoer dan gebeurt er niks, kan de web-pagina niet vinden.

Deze bevindingen kpmen uit versie 3.7.5.

De webserver zit in SPD.

Zorg dat je PC en je iPad aan hetzelfde wifinetwerk hangen (van een hotspot of van een multiplexer)
Om klokjes te krijgen moet de hotspot wel internet toegang hebben; klokjes komen van google.

Ga dan met de browser op de iPad naar 'ipadresvandepc':9090/SPDfull.html
Of naar een van de andere html pagina's die je in web_root ziet staan (op de PC).

Het IPadres van de PC zie je staan tijdens de opstart (in het scherm dat alle instellingen laat zien) en ook na een klik op de knop I/O&files.

SPDadviceanddials.html is ook goed om naar te kijken

@zeilbootje:
je mux(?) maakt vaak de RMB berichten in de war.
Ze zitten vastgeknoopt achter de RMC:


$MARMC,101303.86,A,5427.45800,N,1137.44000,E,3.35,224.2,280722,,E,A,S*UU$MXRMB,,,,,000I,,,,,,,,*1D
$MARMC,101305.34,A,5427.45800,N,1137.44000,E,3.13,228.9,280722,,E,A,S*UU$MXRMB,,,,,000I,,,,,,,,*1D

en soms de RMC achter iets anders, hier de GSV:

$ECGSV,5,3,18,27,55,154,50,32,22,126,40,65,50,062,38,66,38,152,47*60$MARMC,101306.34,A,5427.45700,N,1137.41

Bij zulke berichten zal SPD de 2e missen; er wordt naar ee $ gezocht en dan 1 bericht erachter.

Aha, ik moet de html file naam erbij zetten in de balk, dat was ik vergeten, nu werkt het. Weer een stapjes verder.

Baasklusje schreef :
Hhhmm dat is raar, hoe is dit op te lossen. Hen de RoosMux draaien en de NMEA data komt over de USB aansluiting binnen. Is dit een com poort instelling/configuratie?

ik vrees dat het een foutje in de mux is....

Baasklusje schreef :
Ik stuur even een mail naar Chris, misschien kan hij er wat mee.

In de NMEA out van SPD zie ik alleen een VTG:

$SPVTG,71,T,71,M,42.5,N,296,K,A*17
$SPVTG,72,T,72,M,42.5,N,296,K,A*17
$SPVTG,73,T,73,M,42.5,N,296,K,A*17

Wilde je niet ook via motortoerental de performance zien (of ben ik even in de war)?

Baasklusje schreef :
Nee motor toerental hoef ik niet, sterker nog kan ik niet zien. Mijn Yanmar motor heeft geen NMEA connectie (helaas).

En is “alleen” VTG goed of fout?

zeilbootje schreef :
Je hebt geen instrumenten aan Nmea2000 hangen gezien de roosmux, denk ik.

De VTG geeft performance op een NMEA0183 instrument weer, als je dat op COG zet.
MAAR alleen als er geen echte COG op dat instrument ook binnenkomt.

Die VTG kan geen kwaad maar doet ook niets
Zet hem op N in boatspecifics.

Blij met de html pagina's ?

Ik heb Raymarine spullen aan boord. De plotter, stuurautomaat, electronisch compass, gps etc. zijn allemaal via SeatalkNG verbonden. De plotter heeft een NMEA0183 verbinding en die is met de Roosmux verbonden te samen met de AIS transponder en de marifoon. Omdat ik op de iPad alle gegevens kan zien, heading, speed through water, sob, soc, etc. verwacht ik dat deze ook over de USB poort naar SPD worden gestuurd. Dus alle data moet in SPD beschikbaar zijn. Wat mis je dan in de log?

html pagina’s moet ik nog even verder bekijken, kids zijn net terug van het shoppen, morgen weer varen en een nieuwe log maken.

je log:

- watersnelheid is er niet, dus stroom berekenen gaat fout.
-heading is altjd precies COG
COG HDG
217 217
218 218
224 224
225 225
226 226
228 228
230 230
231 231
232 232
Dat zal wel in de mux zo zijn ingesteld (maak hdg = cog, of zo)
in heading zou je de echte heading uit het elec kompas willen zien.

geen van deze, allemaal 0:
RoT PITCH YAW RUDANG

dus geen sensor voor Rate of Turn, Pitch en Yaw? (zoals een EV1)
Geen roerstandsensor?

HDG is toch wat het electronisch compass aangeeft?

Ik heb geen instelling in de mux mbt hdg, zal het nog even nakijken maar kan me niet herinneren.

Ik heb een EV400 stuurautomaat met een EV1 als compass gever. En ik heb zeker ook een roerstand gever, ik zie de roer stand netjes op de Raymarine apparatuur.

zeilbootje schreef :
waarschijnlijk heb je die data uit de log functie van het instelprogramma?. Die heeft de eigenschap dat hij op tijd logt. Dus soms zie je dan meerdere berichten in 1 regel. en sommige berichten beginnen in het bericht op een nieuwe regel. Daar is verder niet zoveel aan te doen. En ook verder niet belangrijk, want in de echte usb en nmea uitgangen gaat dat wel goed.

Ieder bericht waar dan ook vandaan wordt netjes volgens nmea0183 verstuurd.

Met veel AIS data kan dat behoorlijk snel gaan, overigens.

Nee, de logging komt niet uit het instel programma maar uit het performance programma die via de seriële poort op de mux is aangesloten.

Dat het instel programma soms berichten aan elkaar plakt (volgens jouw uitleg) is idd wat ik eerder heb gezien en wat je ook al had uitgelegd. Dus dat is bekend idd.

nou ik ikan me niet voorstellen dat het via de normale uitgangen fout gaat. Dan was dat al veel eerder gezien, in die tien jaar....

ik zie wel dat je "RMB genereren door mux" aan hebt staan, waarom is dat? Dat is voor de mux polar functie.

Overigens kan BK de nmea afhandeling ook wat robuuster maken. Kijk naar $ en * en checksum erna inlezen en controleren.
Dan weer vanaf volgende byte zoeken naar de $. Dat is 10 minuten programmeerwerk.

Roozeblij schreef :
Dit gaat even buiten mijn kennis, Baasklusje heeft dit geconstateerd in de logging. Geen idee natuurlijk waar het fout gaat, die kennis heb ik niet om er over te oordelen. Hoe kan ik dit testen/verifiëren? Hoe kan ik uitzoeken waar een mogelijke fout zit?
Roozeblij schreef :
Je hebt helemaal gelijk, die stond nog aan. Waarschijnlijk een overblijfsel van het testen uit het verleden. Ik heb het vinkje uitgezet.

ik heb nog een toevoeging aan mijn postje gedaan, jij hoeft dat niet uit te zoeken. BK kan het oplossen.
Dat doet ie vast wel.

Ik snap het al.
Je hebt NMEA2000 spullen (EV, ACU met roerstandgever).
Die maken NMEA2000 berichten met roerstand, heading, helling, pitch.

Maar de roosmux heeft geen NMEA2000, en die berichten uit je apparaten worden dus niet naar NMEA0183 vertaald. En ze gaan dus ook niet SPD in, want ze zijn er niet.

@chris:

SPD kijkt natuurlijk waar een bericht begint ($) en eindigt (* en checksum).
Het vindt dus alle berichten, ook als ze achter elkaar zitten (zoals via TCP en soms UDP, waar er vele in een block met bytes zitten).
De log van SPD logt een bericht precies zo als het binnenkomt. De regel (over serial) die binnenkomt gaat zo de log in.
En daarna gaat SPD in de string zoeken naar $ (meerdere indien die er zijn) en indien gewenst ! (voor AIS te loggen).
Er raakt niets kwijt....