Onderwerp: Raspberry Pi performance box

Gregor is vrijwillig slachtoffer geworden - ergens in augustus gaan we de boel bij hem aan boord aansluiten.

Vóór die tijd rest mij nog om alles méér fool-proof te maken, addressen van devices eenvoudig instelbaar te maken en te ondervangen hoe het geheel werkt indien bepaalde instrumenten (bv een heading of GPS) niet aanwezig zijn op het netwerk.

Omdat dat helemaal geen leuk werk is, eerst nog een uitbereiding Inmiddels gaat het aanmaken van virtuele devices goed en lijkt dit de manier om verder te standaardiseren zonder "misbruik" van bepaalde PGN's. Voor het performancegetal, UA/DA en targetspeed kan dit niet anders, omdat de PGN's daarvoor niet bestaan (of niet gebackengineered zijn).

Wat ik van plan ben is om PolarPlot ook als "true wind" computer in te zetten. Op mijn netwerk is de windsensor (apparaat 10) "dom" en spuugt alléén apparent wind data het netwerk op. Mijn MFD (apparaat 5) zet zichzelf daarbij in om de true wind te berekenen en publiceert deze. Er worden door de MFD 2 types true wind berekend:

• True (boat referenced)
• True (ground referenced to North)

Deze 2 ga ik sowiezo ook (gecorrigeerd...) aanbieden. Er bestaat binnen N2K echter nog een derde (en vierde...) soort true wind:

1. True (ground referenced to North)
2. Magnetic (ground referenced to Magnetic North)
3. Apparent
4. True (boat referenced)
5. True (water referenced)

Zou het nuttig zijn die laatste (nr 5) toe te voegen?

Dit is de kompasrichting waarin je, meedobberend met de stroom, de wind zou pijlen. Dit is dus niet de richting van de geowind (nr 1). Als je deze true wind op een kaart in zou tekenen, kun je daaruit afleiden wat de (met de stroming van dat moment) bezeilde kompassectoren zijn. Deze bezeilde sector mag je dan weer niet intekenen op deze kaart, omdat de stroming je zal verzetten.

Heeft dit zin of misleidt dit alleen maar? Het gaat ook weer een stukje verder en begint méér op een "tactiek functie" te lijken, wat niet tot de uitgangspunten behoorde.

Weer aardige voortgang kunnen maken de laatste week. Zowel uitgebreid getest, een aantal extra opties ingebouwd en begonnen aan een technische handleiding (yuk). Ook de configuratiefile uitgebreid en van commentaar voorzien zodat er enige gebruikersvriendelijkheid ontstaat.

Een forumlid gaat het systeem op zijn RM netwerk testen/gebruiken; daarvoor moet het een stukje uit de nerd/hobbiesfeer getrokken worden, aangezien het volgende doel nu een gebruikersklaar systeem is geworden. Dat is best een uitdaging.

Als extra functionaliteit is er bij gekomen:

• Logging autostart/-stop: Vanaf een instelbare vaarsnelheid start de datalogging. Wordt er eenmaal gelogged en zakt en blijft de snelheid onder die grens gedurende een (instelbare) tijd, dan stopt de logging. Op die manier een soort dode band ingebouwd;
• Er worden extra data het netwerk op gestuurd, namelijk een aantal gecalibreerde sensorwaarden en andere relevante outputs van PolarPlot. Deze data (bijvoorbeeld een gecalibreerd log of TWA/TWS) kun je dan ook op andere plaatsen aan boord gebruiken. Beschikbaar is nu: Performance, TargetSpeed, PolarSpeed, UA/DA (diegene die van toepassing is), TWA, TWS en TWD
• Switchen tussen Tidal en non-Tidal mode kan nu via de MFD's of plotter. Door een "dubbelklik" op de Night Mode instelling op een van de aangesloten apparaten te doen (2x wisselen binnen 2 s), ziet PolarPlot dat er een Tidal mode change gevraagd wordt. Feedback naar de gebruiker over welke mode geselecteerd is verloopt via deze zelfde backlight. Night Mode = Tidal (ezelsbrug: "zee, lange tochten, 's nachts") en Day Mode = Non-Tidal (ezelsbrug: "dagtochtje, binnenwater").
• Shutdown van de Raspberry Pi kan nu ook via de MFD's of plotter. Door het backlight van een of meer aangesloten apparaten in de allerlaagste stand (die is zó donker dat je die niet gebruikt, zelfs niet zonder maan) te zetten, detecteert de Pi dat ie uit moet. Logfiles worden dan netjes afgesloten en het systeem wordt uitgezet. Feedback door de laatste 10 s de schermverlichting van zeer fel tot gedimd te laten knipperen.

Helaas is het op afstand clonen van de image voor het forumlid niet gelukt: 4 GB over 4000 km zal wel wat bitjes om hebben laten vallen. Dat wordt dus toch nog wat nerden straks aan boord.

Devicelist, product info en dataschermen zien er als hieronder uit. Rechtsonder heb ik 2 schermen geconfigureerd die mij erg handig lijken om de performance gerelateerde informatie te presenteren.

Ook tegen een bug in de Triton aangelopen: de TWD wordt wél ingelezen en in de stripchart geplot, echter niet (op datzelfde scherm) getalsmatig weergegeven. Bij voldoende data (heading, boatspeed) berekent de Triton die (dat getal) dat blijkbaar zélf. Dat mag niet, want er bestaat een PGN voor en die zou m.i. voorrang moeten krijgen.

Heb je toevallig ook een autopiloot in je netwerk? Volgens mij een BenG ding dat windberekeningen automatisch door de pilot gedaan worden, zodra die op t netwetk verschijnt. Als ik de piloot uitzet daarna, en de mfd aanlaat, valt toch de twa en twd weg. Misschien is er bij jou ook xoiets asn de hand met de triton?

Gepost met de officiële Zeilersforum-app

Nachtvlinder schreef :
Leuk dat je het voor een breder publiek toegankelijk gaat maken. Mijn spul zal me zelf kennende in de hobby sfeer blijven.

Wat betreft drift ben ik wel iets verder gekomen. Afgezien van dat het nu nog in een onoverzichtelijke reeks e-machten gevat is heb ik wel sterke aanwijzingen dat de seastate gevat kan worden in de standaarddeviatie van roll&pitch en dus een factor over de drift vormt.
Nachtvlinder schreef :
Is het zo'n zwaar systeem ? Wat is de uitkomst van het commando df -h in het terminal venster ?

666 schreef :
Ik begrijp wat je zegt en inderdaad stuurt ook mijn AP deze data uit als ie aanstaat, maar de hier weergegeven case is veel eenvoudiger. De data en plaatjes die je in mijn laatste post ziet zijn op een hotelkamer tot stand gekomen, met alléén de door PolarPlot verstuurde data. Voor zover relevant is dat alléén:

PGN 130306 (Wind), waarbij in de ISO Address Claim:
Device Function = 130 (Atmospheric)
Device Class = 85 (External Environment)

Deze PGN wordt per cyclus 2x gebroadcast met afwisselend onderstaande waarden in het "Reference" veld:
1: Magnetic (ground referenced to Magnetic North) (=TWD en TWS)
3: True (boat referenced) (=TWA en (zelfde) TWS)

Dit wordt ook zo herkend door de Triton en zelfs gekozen bij "auto Data Source select".

De Triton die ik hier mee voed hééft niet eens data beschikbaar om zélf hieruit de TWD te kunnen berekenen (de Heading zou nodig zijn)! Blijkbaar ontvangt de Triton deze TWD juist, althans hij wordt weergegeven in het "Data" scherm (zie plaatje) én op de stripchart geplot. De numerieke weergave bóven die stripchart doet ie niet vreemd genoeg!

Om verder uit te zoeken welke "undocumented feature" dit betreft heb ik PolarPlot uitgebreid, waardoor nu ook de gecalibreerde/gecorrigeerde waarden uitgezonden worden voor:

• PGN 127250 (Vessel Heading, Magnetic)
• PGN 130306 (Wind, Apparent)
• PGN 128259 (Speed, Water referenced, Paddle wheel)

Als ik hiermee naar dezelfde stripchart kijk, staat er boven die stripchart wél de TWD (getalsmatig) weergegeven!

Blijkbaar wordt de op het netwerk ontvangen waarde van TWD geplot, maar de (door de Triton) berekende waarde van TWD als getal getoont. Dat is niet consistent.

Om zeker te weten straks een consistente dataset te hebben (en de Triton niet op eigen houtje een ongecalibreerde boatspeed gaat gebruiken om TWD te bepalen, laat ik dit zo: de TWD (als getal) die de Triton berekent is nu gelijk aan wat in de stripchart geplot wordt.

Verder voordeel is dat nu (op zowel de repeaters binnen, buiten en op de plotter) de gecorrigeerde AWA weergegeven wordt. Deze is gecorrigeerd voor masthoogte en helling en geeft beter aan wat de zeilen voelen dan de Windex. Kan de AP ook gebruiken om op te sturen.

Zowel de applicatie als het netwerk kan dit prima aan: als ik op 10 Hz draai is de processorload zo'n 8% en de CAN busload zo'n 3%...

3Noreen schreef :
Nou, stel je daar niet teveel van voor hoor! Al zou ik het leuk vinden hier meer mensen mee blij te maken (en een brede testgroep te hebben), is het meer om mezelf te forceren netjes te documenteren en zowel de code als de configuratiefile onderhoudbaar te houden. Een IT persoon zal er om lachen als ie naar de code kijkt

3Noreen schreef :
Interessant! Jij leert van op basis van echte data niet uit boekjes! Jouw situatie zal ook niet veel in boekjes staan denk ik.
Ben benieuwd naar hoe dit gaat werken. Ik schat de drift (op stromend water) uit de klassieke LWY=K*Heel/BSP^2, echter in hoge golven zal ook voor een monuhull de gemiddelde Heel een te lage drift schatten, waar eenzelfde (maar constante) Heel op vlak water wél redelijk klopt.
De Polardata geldt natuurlijk ook slechts voor vlak water trouwens!

Corrigeer jij de factor in deze relatie op basis van de bewegingen in de gemeten roll&pitch?

3Noreen schreef :
Nee hoor! ZF lid had alleen nog geen image dus ik heb hem een bitwise gecloned image verzonden. Blijkbaar comprimeert dat tot 4 GB. Ik heb de grafische schil niet meer nodig, maar staat nog wel op het image. Zag ook iets van een "Minibian", een minimalistische Linux omgeving zonder alle overbodige meuk. Ben daar nog niet mee bezig geweest (omdat het zo prima draait, eigenlijk). Dan zou ik ook meteen met een "read-only" systeem willen gaan werken, echter mijn Linux vaardigheden zijn vrij beperkt.

Is dit iets? Lijkt ruimte te hebben voor 2 uitbereidingsboardjes. Is geen "Blackbox" meer dan, maar wel netjes in te bouwen achter instrumentenpaneel...

Afgelopen vrijdag het spul bij en met ZF lid Gregor aan boord geinstalleerd.

Gregor gebruikt zowel een NMEA0183/STng converter, een iTC-interface om een aantal "oudere" analoge sensoren te gebruiken, als een aantal native STng apparaten.

We hebben eerst zijn Pi als een ghost mee laten kijken op zijn netwerk om de CAN addressen van de bronapparaten te achterhalen (de iTC bijvoorbeeld, heeft 1 address maar zendt 4 PGN's uit), verder 5 vrije addressen bepaald waar PolarPlot haar virtuele devices op aanmaakt.

2 Onverwachtte dingetjes ontdekt:
-de bronselectie op zijn netwerk lukte niet handmatig. Hierdoor is het niet eenduidig welke wind-source zijn systeem kiest (bv de door PolarPlot gecorrigeerde True Wind data of deze data door z'n bestaande E7 berekend);

-de puck van zijn AP stopt met uitzenden van de heading zodra PP deze heading gaat uitzenden. Dat gaf een loop, omdat PP deze ruwe data nodig heeft.

Beide issues lijken opgelost na een software update van de E7 na contact met de (uitstekende!) helpdesk.

Hieronder (rechter klok) het performance scherm zoals Gregor dat geconfigureerd heeft:




Accu Volt = target speed;
Accu Amp = target UA/DA (nu UA...);
Brandstof = performance%

Ik ga nog flags maken om de uitgezonden gecalibreerde heading, wind en boatspeed uit te kunnen zetten, indien een netwerk slechts met 1 datasource per PGN om kan gaan.

Verder vind ik (maar dat is persoonlijk, kan ook zijn omdat ik er flink mee gespeeld heb...) mijn Navico N2K apparatuur veel flexibeler in te stellen. RM/STng lijkt de interface in haar apparatuur ontworpen te hebben voor eenvoud, vgl OSx met Linux. Als je af wilt wijken van wat RM voor je heeft bedacht wat goed voor je is wordt het lastig. Kan ook een early release van de software zijn geweest, aangezien de handmatige bronselectie na de update wel beschikbaar kwam.

Was een interessante en leerzame dag. Bijzonder te zien dat het ogenschijnlijk dichtgetimmerde Raymarine netwerk toch ontsloten kan worden. Eens met de laatste alinea; een B&G-meter aangesloten op het Raymarine netwerk laat zich een stuk eenvoudiger configureren.

Inmiddels weer een paar maanden verder. Gregor (en ik in mindere mate) is fanatiek aan het testen geweest, wat een paar erg irritante bugjes aan het licht heeft gebracht (o.a. een "memory leak" - wist niet eens dat dat bestónd!) maar vooral een aantal praktische feature-requests. Bugs zijn eruit en het spul lijkt stabiel te draaien nu. Onderstaand de laatste "revision history", voor zover je dat zo kunt noemen bij een hobby-produkt:

171017
Bug fix for target speed calculation for TWA<0 and TWA between last TWA entry in polar table and UA

171017
Implemented simulation mode. Requires new polarsettings.txt file. Prevent data acquisition loop to read values
from N2KD server rather reads fixed input values from polarsettings.txt file

171014
Console output formatting polishing. Format, highlights and colors

171012
Implemented TrackLogYYMMDD.csv outputfiles, compatible with GPSvisualiser input files.
Interval set in polarsettings.txt as (TrackInterval * Execution_ms)

171011
Corrected Execution_ms for speed of main loop. Minimum execution time is 30 ms!

171011
Implemwented UTC_offset and VAR_deg entries in polarsettings.txt

171010
Implemented logging interval integer to write PolarLog entries every (LogInterval * Execution_ms) milliseconds

171008
Fixed memory leak

170930
Increased SocketCAN write buffers from 1 (default) to 1000 to avoid lost data on lost arbitration
(sudo ifconfig can0 txqueuelen 1000)

170928
Fixed invalid arccos argument for undefined TWA (for TWS=0 scenario)

Nu met Gregor in een veel interessantere fase, het calibreren zélf en vullen van de correctietabellen. Daarover meer in het andere draadje, omdat dat niet specifiek met PolarPlot te maken heeft...

Nu het zaakje stabiel draait, rest om het project af te ronden nog:

• Gebruikers-/calibratiehandleiding schrijven
• Shutdown-proof en meer robuuste "embedded" implementatie

Omdat ik absoluut geen zin heb in dat eerste, ben ik aan het stoeien met het laatste, meer technische punt. Stoeien omdat ik geen Linux-nerd ben maar dit toch een beetje vereist is, eigenlijk...

Voor de Pi bestaan er een aantal op maat gemaakte Linux distributies. Zo is er de standaard Raspbian, geleverd met een X grafische interface en vele toeters en bellen. Deze gebruik ik om de ontwikkelomgeving op te draaien, maar ook draait hier de laatste versie nog steeds op, aan boord.

Er bestaat een uitgeklede versie, Minibian, waarbij de grafische omgeving gestript is. Nog steeds echter is deze distributie overloaded met drivers en software voor functionaliteit die ik helemaal niet nodig heb. Ook zou een read-only filesysteem mooi zijn, zodat de Pi robuust wordt voor een plotselinge power-down. En aangezien het zich moet gaan gedragen als een normaal boordinstrument, wil je ook niet telkens door een shutdown-procedure gaan. Nu moet (en kan) dat wel door een van de displays buiten op verlichtingsniveau "2" te zetten. De software ziet dit en sluit de Pi dan netjes af. Nu geimplementeerd voor B&G systemen. Dit zijn echter proprietary PGN's, wat zou betekenen dat je voor elke merk weer iets nieuws moet verzinnen (RM zal andere PGN's gebruiken voor de verlichtingsniveau's in een netwerkgroup, bijvoorbeeld).

Heb het nu aan de praat gekregen in een superkleine en erg snelle omgeving die precies doet wat ik wil. Het is een variant van Tinycore, genaamd piCore. Ultraklein en kan zonder add-ons iets meer dan niets.

Vergelijk:

• Raspbian Stretch: 1.6 GB
• Raspbian Stretch light: 350 MB
• Minibian: 225 MB
• piCore: 45 MB

piCore start koud binnen 7 s op; met netwerk en CAN drivers binnen 10 s. Het is een read-only systeem. Bij elke power-up/herstart wordt het gehele filesysteem binnen een sec vanuit de SD kaart (partitie wordt direct ge-unmount...) in RAM geladen. Net zo "vers" als bij de eerste installatie. Alles wat je in dit systeem aanvult, verwijdert of verprutst gebeurt in RAM en wordt bij een volgende start teniet gedaan. Extra functionaliteit (WiFi ondersteuning, drivers en zelfs een texteditor) kun je downloaden als .tcz extensie en al of niet automatisch laden. Deze extensies worden op een deel van het SD kaartje bewaard. Met een "backup" optie kun je selectief aangeven welke handmatig toegevoegde files/executables je nog meer wilt bewaren. Deze worden dan gecomprimeerd op de SD kaart gezet en tijdens het booten gekopieerd naar het filesysteem in RAM.

Je weet dus exact (en bepaalt zélf) wat er aan het standaard systeem gesleuteld wordt.

En het draait

Het systeem zélf past nu in een image van <50 MB, wat eenvoudig te verspreiden valt. De executable zit daarbij in. De configuratiefile en gegenereerde datafiles worden gelezen/geschreven naar een USB stick. Zolang de naam daarvan vast ligt, wordt deze automatisch gemount (maakt niet uit in welke USB poort je deze stopt) en weet PolarPlot hoe het zich op een bepaalde boot moet gedragen.

Bedoeling was er een hotspot of access point van te maken, zodat je point-to-point kunt verbinden en op afstand de datafiles van de USB stick kunt halen of de configuratiefile kunt editen. Dit is echter niet eenvoudig te standaardiseren, omdat elke WiFi dongle andere drivers benodigt en niet alle chipsets deze "AP mode" ondersteunen. Op de Pi3 met ingebouwde Wifi zou dat wel een mogelijkheid zijn overigens. Anyway nu kun je gewoon de USB stick in je laptop stoppen en er mee doen wat je wilt.

Zo, in het kader van de oude koeien...
Ik ben op zoek naar iets waarmee ik
- kan kalibreren (boatspeed op basis van helling bv)
- een schappelijke polar kan gebruiken en idealiter optimaliseren
- aanhakend bij mijn b&g zeus3/triton/dst800 etc setup
- met een rpi oid

En kwam dit oude draadje tegen wat hier toch wel dicht bij zit.
Leeft dit nog? En is het te ‘consumeren’?

Bij mij aan boord gebruik ik het systeem altijd als ik zeil. Probleemloos. Bij Gregor is het ook gecommissioned, bij holtere is nazorg nodig. Een middag in een loods zonder mast/winsdet zal adressen veranderd hebben.

Antwoord is dus “nee”, het is geen consumentenprodukt. Als je handig bent met de Pi, een beetje technisch aangelegd en je jezelf wilt verdiepen in deze materie wil ik je telefonisch best helpen en de software geven; makkelijker is als je met je boot en de aangeschafte hardware naar Amsterdam of Stellendam komt, dan krijgen we het wel aan de praat.

Bedenk dat OpenCPN ook een basic polar-performance tool heeft, echter het soort calibraties die je noemt zijn daar niet mogelijk en de data wordt niet uitgezonden; is alleen lokaal beschikbaar (meestal binnen).

QTVLM zendt die performancedata wel uit desgewenst.
Ik heb dit niet geprobeerd maar e.e.a. zou in de mux zichtbaar moeten worden!

Volgens de manual:

Zie foto...blijkbaar ook Raymarine. Ik heb echter geen idee hoe die zinnen eruit zien of waarmee weer te geven.
Ik heb dat programma niet ingesteld als navigatiesoftware maar gebruik het alleen om wat wheatherrouting mee te proberen.

Misschiennn morgen regent het de hele dag......

He, da’s interessant! In je multiplexer kun je de uitgestuurde nmea0183 zinnen vast bekijken in een soort debug window - zal een custom identifier zijn waar RM klokken iets mee kunnen? Volgende stap is hoe dat dan om te zetten naar n2k...

rovinggecko schreef :
Het begint met een sensor die enigszins betrouwbaar de snelheid door het water meet. Ik heb van alles geprobeerd maar van zo'n peddelwiel log kreeg ik geen metingen uit van enige nauwkeurigheid. Ik bleef een foutmarge geschat van rond de 20% zitten. Er zijn teveel factoren die de meting beïnvloeden. Vorig jaar de laatste ontdekking dat een schoon onderwaterschip een lagere meting geeft. Dit kan ik al helemaal niet verklaren. Ik zou juist denken dat de boundry layer dunner wordt en daarmee een hogere snelheid meet.
Ik houd het er op dat het hele ding zich in een turbulente laag bevind.

uit mijn aantekeningen over NKE nmea zinnen

/*"$PNKEP,01,10.1,N,,K*43xxx" veld 2 is Target speed*/
/*"$PNKEP,03,345.5,67,81*43xxx" veld 2 optimum angle from 0 to 359° veld 3 upwind/downwind performance from 0 to 99 veld 4 performance from 0 to 99%*/

Zichtbaar te maken met de NKE app.

Prima ervaringen met een ultrasoon log: wijkt op stilstaand water nooit meer dan 0.1 kn af van de SOG uit de GPS. Wel af en toe “locking” problemen bij overgang zout-zout, na droogvallen of modderige geultjes waar het turbulent stroomt of grote swirls aanwezig zijn in het meetpad. Na zo’n 10 min komt de “fix” dan terug. Zal z’n algorithme dan opnieuw aan het inregelen zijn oid denk ik. Meting vindt plaats ahv deeltjes in de waterkolom tussen 20 en 100 cm onder de sensor.

Corrigeren van mijn paddlewieltjeslog op basis van helling heb ik nooit gedaan; PolarPlot kan dat wel. Ook kun je daarmee een n-punts lineairisatie doen. Of dat zin heeft hangt zoals 3Noreen zegt van heel veel dingen af. Ook van de boot denk ik. Je dient in ieder geval veel data te loggen om een model te maken (niet stromend water) tussen STW als functie van SOG en helling. Op basis van dat model (zal ruisig zijn!) zou je dan beide correcties kunnen bepalen. Dit kost tijd en moet je leuk vinden...

Dank voor alle antwoorden en het aanbod.
Ben niet onhandig (maar zeker geen expert) met de rpi.
Zal eerst even spelen met openplotter en die met ngt-1 aanhaken en eens met opencpn kijken naar de polar etc. En me dan hier weer melden om eens met polarplot te spelen.