Onderwerp: Raspberry Pi performance box

Vier opties uit te werken dus. Ik start met optie 2. Correctie in het tijdsdomein want daar weet ik het minst van en lijkt me interessant. Vooral dat "fase" gebeuren eens uitzoeken...

Idee bij optie 2 is dat er een FFT analyse mee loopt met een window gevuld met zo recent mogelijk gemeten waarden. De breedte van zo'n window is altijd 2^N samples, bv 256, 512, 1024 etc. Zo'n analyse kost veel processortijd en kan daarom niet real-time gebeuren. Je dient dus óf de weergave van de net binnengekomen data te vertragen (ongewenst) óf de FFT analyse gebeurt in een specifieke thread die op de achtergrond niets anders doet dan dat. Thread geeft dan een seintje aan de hoofdtaak dat er data uit een nieuwe analyse beschikbaar is. Tijdhuishouding dient zeer precies te zijn, omdat de signalen in zo'n window een vaste fase hebben en het hele window repeteert. Deze methode werkt het best indien het signaal stationair is, dwz het spectrum én de fasen van de componenten gelijk blijven. Deze randvoorwaarde zou in redelijke mate het geval kunnen zijn onder vaste condities met een bepaalde seastate.

Ik heb wat eenvoudige testsignalen aangemaakt en hier analyses op losgelaten die het belang van die fasen duidelijk maken.


Hier een "ideaal" testsignaal van de som van 2 verschoven sinussen. De frequenties van beide componenten vallen precies in het midden van 2 bins uit het frequentiespectrum (0.537 Hz en 0.840 Hz). Dit is het blauwe signaal.
In het FFT spectrum kun je zien dat dit signaal slechts 2 componenten bevat (wat natuurlijk ook klopt - we hebben er slechts 2 ingestopt).
Het gereconstrueerde signaal ligt dan ook vrijwel perfect op het testsignaal. De grijze plot laat het verschil, de fout in de reproductie, zien en is zeer laag.

Het grappige is dat doordat de FFT een reëel en imaginair deel heeft, de fase ook bepaald is en dus gereconstrueerd kan worden. Deze fasen liggen vast in het window en herhalen zich dus één, twee, drie etc windowlengtes verderop. Alle door de FFT "gevangen" golflengtes/perioden passen preciés in het window.

Kijk maar (tijdas 512 samples verschoven - precies hetzelfde plaatje):


Dit is belangrijk, omdat een verse meting, op het moment dat dit gepresenteerd wordt, gecorrigeerd dient te worden door de waarde op het corresponderende moment uit de gereconstrueerde FFT-tijdreeks. Onhandige zin is dit. Je dient dus precies te weten op welke plek uit het window je op ieder moment bent:


De plaatjes hierboven waren een schoolvoorbeeld, waarbij het testsignaal zich door slechts 2 componenten liet beschrijven (door 2 cosinussen in principe - die 2 sinussen komen erbij om de fases goed te krijgen).

Nu iets lastiger en een heel klein beetje meer richting praktijk: de te corrigeren frequentie valt niet samen met een (discrete) bin:


Hier zie je dat er al >3 componenten (reconstructie gebruikt nu alleen de 3 grootste componenten uit de FFT) nodig zijn om het signaal te reconstrueren. Let ook op de "versmeerde" bijdragen rond 0.6 Hz. Het signaal lijkt nog redelijk op het testsignaal, echter één window later lopen de fases steeds verder uit elkaar en wordt het al behoorlijk rommelig:


Doordat de perioden van het testsignaal en het gereconstrueerde signaal een fractie van elkaar verschillen, gaan deze steeds verder uit elkaar lopen.

Dat is ook inherent aan de discrete FFT: er kunnen slechts een beperkt aantal frequenties geïdentificeerd worden. Door (veel) meer componenten mee te nemen (die de gehele piek in het spectrum meenemen) zal het vast beter kunnen worden. Maar waar stop je dan?

Overige nadelen/risico's:

• Rekenintensief; analyse zal altijd achter lopen. Dit is niet erg indien het een zuiver stationaire periodieke verstoring betreft, maar dat zal in de praktijk nooit (lang) het geval zijn
• Kleine fase fouten stapelen zich op naar verloop van tijd: analyse zal continue uitgevoerd moeten worden om de huidige omstandigheden te kunnen "tracken";
• Sampling stabiliteit dient erg constant te zijn (zie 3Noreen's verhaal)
• Filtert slechts één frequentie (of zeer nauwe band) weg. Bij een licht variërende periode in de te filteren verstoring zit deze methode er vaker naast dan raak.

Ben nu hoogstens "bewust onbekwaam" op FFT gebied, dus tips en aandachtspunten zijn welkom.

Ik neig steeds meer naar optie 3. Adaptief filteren in het frequentiedomein. Heb daar al wat mee gespeeld maar wil dat nog verder uitwerken. Op échte data...

Om dit soort spelletjes te kunnen spelen zul je denk ik wat beschikbare de processor kracht vrij moeten hebben. 50% belasting voordat je met je eigen programma begint is wel heel hoog. En hoe zit je met de geheugen stack ? Op het moment dat het Os gaat swappen naar de SD ben je alle suggestie van real time kwijt. Probeer alle video client side af te werken. Zelf schakel ik de hele GPU uit. (/opt/vc/bin/tvservice -o) Dat scheelt een hoop in de Rpi. Laat verder alle input, TCP of serieel door het Os uitvoeren. Geef je eigen applicatie een hoge prioriteit in het Os.
Zelf gebruik ik een gestripte Os minibian

Mijn systeem voert alleen FFT uit op min of meer real time signalen. In mijn geval GPS. In een aparte thread van het programma. Uitkomst hiervan wordt om de ± 2 sec ververst. In een C programma kun ik een onwaarschijnlijke hoeveelheid rekenwerk laten uitvoeren in 2000 µsec.
Het time signaal van de gps wordt opgevangen en samen met de daarna binnenkomende nmea RMC. Dit signaal wordt in een 3 dimensionale (time,speed,angle) array van 300 samples opgeslagen (3Mb). Alle bewerkingen op deze array worden met pointers uitgevoerd. Ook FFO. Ga niet lopen schuiven met 3Mb.

Tsja,

Rekenintensief, dat dacht ik al! Ik vind het onzin om hier een RPi3 voor aan te schaffen of de (best wel gelikte al zeg ik het zelf) grafische interface voor op te geven.
Het hangt voor mij sterk van de toegevoegde waarde hiervan af om te besluiten dit richting implementatie te brengen, wat vereist op andere vlakken processortijd terug te winnen - ik bv zou trager kunnen sampelen (niet handig voor de motioncorrectie) of de grafische interface met een lagere frequentie kunnen updaten dan ik nu doe bijvoorbeeld.

Heb jij al vergeleken wat bij jou deze FFT-reconstructie-substractie toevoegt tov bv adaptief filteren? Doe jij, functioneel gezien, hetzelfde zoals ik in de post hierboven voorstel? Herken je de nadelen die ik noem of zijn de voordelen voor jou groter?

Zelf heb ik nu een Rpi3. Daar ik de prijs van zo'n ding wel overkomelijk vind.

Bij het binnenkomen van nieuw RMC wordt na 85 - 105 µsec een gesynthetiseerde nmea VHW koers/snelheid richting stuurautomaat weggestuurd. Hier zit een kleine wacht cyclus in om jitter te beperken. Verder moet je kijken hoever je kunt met de doorgevoerde correctie. Ik ga niet verder dan 70%. En de bandbreedte van de FFT wordt beperkt. Het VHW bericht is lekker kort. Daarmee hoop ik weinig extra latency te veroorzaken. De ±100 µsec doet al zeer.
Alle andere signalen worden door een adaptief gefilterd zoals in jou model #3 Die signalen zijn bij nmea0183 bij lange na niet real time. Het wachten is op een CAN bus rechtstreeks op de Rpi die de nmea2000 kan inlezen.

Natuurlijk hoop ik dat jij je gelikte interface omzet naar HTML5+java. Die via een simpele web server op de Rpi beschikbaar is. Scheelt denk ik veel rekenkracht van de Rpi.

Ben heel benieuwd of je FFT ook de resonantie van een monohull er uithaalt. En of dat extra complicaties meebrengt.

Dank voor je reactie.
3Noreen schreef :
Daar hoef je niet op te wachten hoor! Gebruik ik ook, samen met een aantal tools uit het CANboat project.

Zal eens kijken hoe snel of traag de alglib DFT routine in Lazarus is...

Ben lang... Heel lang aan het experimenteren geweest met eerder genoemde ideeen:

1. Model-based disturbance correctie
2. FFT signaal analyse en correctie in tijdsdomein
3. FFT signaal analyse en correctie in frequentiedomein

1. Gaat goed in Excel, maar (veel) minder goed in PolarPlot op de RPi. Dit wordt veroorzaakt door (klein maar relevante) latancies waardoor het effective sampleinterval een paar ms varieert tussen de samples. Doordat de afgeleidde gebruikt wordt, geeft dit grote onnauwkeurigheden daarin. Dit valt alleen op te lossen door een "echte" motion sensor te gebruiken, die zelf al [deg/s] uitstuurt. De afgeleidde hoeft dan niet meer houtje-touwtje bepaald te worden.

2. Is zeer gevoelig voor synschronisatie in het tijdsdomein. De juiste correcie-waarde dient op het juiste tijdstip van de meting afgetrokken te worden. Dit is m.i. te gevoelig voor fouten. Bovendien vereist het een min of meer stationair signaal: zodra de amplitude of frequentie van de verstoring aan het veranderen is, zit deze methode er vaker naast dan juist.

3. Mogelijkheden van (stabiele) Notch-filtering is beperkt tot tweede orde filtering. Dit is te slap om het oorspronkelijke signaal intact te houden.

Optie (1) vind ik nog steeds het meest veelbelovend, echter dit vereist een nieuwe sensor. Dat vind ik de moeite niet waard, te meer omdat de ultrasone windunit van zichzelf al veel(!) stabieler is dan een mechanische windvaan die te ver doorslingert en andere nadelen van haar massa-traagheid ondervindt.

Ik heb het motion-correctie deel uit PolarPlot gesloopt.

Volgende aandachtspunt gaat worden het zelf uitsturen van een PGN om de performance op het netwerk te zetten. De Fuel Level PGN lijkt geschikt daarvoor. Ik heb daarvaan een "echte" die ik mooi uit kan pluizen en nabootsen.
Aanmaken van de CAN identifier, data fields en droog uitzenden lukt al, echter de uitdaging wordt om het network management netjes af te gaan handelen (ISO Address Request, ISO Address Claim, Product Information) etc. Genoeg uitdagingen

PolarPlot krijgt dan een "Black mode", waarbij alle grafische gimmicks uitgeschakeld worden en ik op elke klok aan boord een gesimuleerd "Fuel Level" kan zien van deze virtuele tank...

Nachtvlinder schreef :
De eerste stappen zijn gezet! Ik heb thuis een minimaal N2K netwerk aangelegd met 12V voeding, een van de Triton's, de niveauzender van de watertank (die nog steeds aan boord aangesloten moet worden) en natuurlijk de RPi.

Uitgeplozen hoe het N2K network management werkt om netjes een virtueel device aan te maken en conflicten met andere apparaten te voorkomen (dubbele adressen bijvoorbeeld). De CAN-interface van de RPi gedraagt zich volledig transparant: op eigen houtje wordt niets uitgezonden en kan als een ghost meegekeken worden met wat er op de bus gebeurt. Interessant te zien is wat er gebeurt wanneer:

1. Alléén de Triton aangesloten is (die best veel meuk uitzend naar een verder leeg netwerk, verlichtingsniveau's voor de in het netwerk aangesloten displays bijvoorbeeld)
2. De Level sender er vervolgens bij geprikt wordt (dat mag want is Plug&Play)

Er gebeurt dan het volgende:

1. Level sender meldt zich aan door een PGN 60928 (ISO Address Claim) te broadcasten
2. Triton snapt dat niet en wil dit nogmaals zien: Triton zend daartoe een PGN 59904 (ISO Request) uit tbv PGN 60928. Deze request is géén broadcast maar wordt specifiek verzonden naar het adres waar de Level sender zich initieel op aangemeld heeft
3. Level sender antwoordt nogmaals als in (1)
4. Triton wil nu meer weten en zend een PGN 59904 (ISO Request) uit tbv PGN 126996 (Product Information), weer specifiek naar het adres van de Level sender. Triton wordt opdringering indien dit verzoek niet binnen 1 s beantwoordt wordt en blijft bombarderen
5. Level sender broadcast de Product Information
6. Triton accepteert en het wordt rustiger
7. Level sender begint nu haar "normale" PGN 127505 (Fuel Level) uit te zenden

Om voor NMEA2000 certificering in aanmerking te komen (dat hoef en wil ik niet) dient er op nog een aantal méér ISO Requests geantwoord te worden, maar deze ben ik niet tegen gekomen. Ik laat het virtueel device gewoon een (vast) adress kiezen wat ver boven die van m'n andere apparaten (die niet verschuiven in de praktijk) ligt.

Op basis van dit gehobby ben ik erin geslaagd een virtueel device aan te maken, genaamd "PolarPlot Repeater". Omdat er in N2K geen standaard PGN's voor performance bestaan (althans niet in het openbaar), gebruik ik PGN 127508 (Battery Status). Het Voltage veld gebruik ik voor de performance; het Current veld voor de UA/DA. Dit laatste veld mag ook negatief zijn dus ik kan onderscheid maken tussen SB en BB (niet nodig eigenlijk maar zat er gratis bij). Bereik is ruim voldoende - tot wel 400% performance

Hieronder hoe het er in het echt uit ziet:

Netwerk is nét opgestart. Device List is leeg, behalve de Triton. Wanneer deze Device List opgeroepen wordt, zendt de Triton een ISO Request uit, nu alleen door zichzelf beantwoord...


Nu zendt het vitrueel device een ISO Address Claim uit. In de Device List verschijnt een "Unknown Device". Op de monitor boven de Triton (onderste 6 regels) zie je het bombardement met verzoeken om Product Information:


Nadat de Product Information PGN uitgezonden is stopt het bombardement en bestáát de PolarPlot Repeater!


Doorgeklikt naar "details":


En na het uitzenden van wat verzonnen data via PGN 127508:


De Repeat-functie komt er dan bijvoorbeeld zó uit te zien (vele mogelijkheden, tot 9 velden per scherm):


Of zo'n 2-line scherm in combinatie met UA/DA:


Het principe werkt dus. Nu PolarPlot gaan uitbreiden met deze "Black Mode" functionaliteit (ik deed het nu handmatig, vanuit Excel gegenereerd en via de CANtools uitgezonden). Één van de GPIO pinnen wordt daartoe een toggle, waarbij het grafisch gedeelte uitgeschakeld wordt en deze N2K interfacing aangezet wordt...

Calibratie deel 1 - log en kompas


Gisteren aan de hogerwal bij rustig stabiel weer een aantal calibratierondjes gevaren op de motor:

1. Totale duur 10 min: 3x rondje linksom, helmstok vast, lage snelheid;
2. Totale duur 12 min: 3x rondjes linksom, helmstok vast, hoge snelheid;
3. Duur 5 min: Voor-de-wind rechte lijn, variabele snelheid;
4. Duur 4 min: In-de-wind rechte lijn, variabele snelheid;
5. Duur 4 min: Halve wind rechte lijn, variabele snelhied.

Hieronder de gevaren cirkels en trajecten. Per meting is ruwe, ongefilterde data gelogged met 4 Hz.



Doel hiervan was om nog zonder de invloed van drift, helling en upwash iets te zeggen over de calibratie en consistentie van:

1. Log vs. SOG;
2. Kompas vs. COG;
3. Nulpunt windsensor (kijkt ie rechtuit);
4. Consistentie windsensor

1. Log vs. SOG
Voor-de-winds traject:



Te zien is dat de SOG sneller reageert op een snelheidstoename, maar ook dat het log bij toenemende snelheid op deze koers/golven in toenemende mate te weinig aan gaat wijzen.

In-de-winds traject:


Hier een vergelijkbaar effect. Tevens is te zien dat de SOG snéller reageert bij een "echte" snelheidstoename maar minder sterk vestoord wordt door golven.

Halve winds traject:


Op deze koers (beetje rollen) worden bovenstaande afwijkingen veel groter! De pieken en dalen in de BSP hebben een duidelijke correlatie met de helling, die op deze koers tussen -5 en +5 graden lag, echter dit verklaart niet de statische (structurele) afwijking (die gróter lijkt dan op de voor-de-windse koers).

Wat zou hier nog meer kunnen spelen? Zou een EM of ultrasoon log beter zijn wat dit betreft? Zeilend zullen de verschillen wss nog groter worden, maar ik had niet verwacht dat die koers-afhankelijk zou zijn. De gehele curve is eenvoudig te schalen en/of een offset te geven, maar het liefst corrigeer ik zo min mogelijk en corrigeer ik alleen als ik begrijp waarom.

2. Kompas vs. COG
COG (of heading indien op stromend water) wordt in Polarplot gebruikt om TWD te bepalen. Tevens wordt op stilstaand water het verschil tussen beide gebruikt om de drift te bepalen.

Onderstaand plaatje toont de gevaren rondjes (bij hoge snelheid dus weinig drift-effect). Te zien is dat de COG méér ruisig is dan het kompas. Beide data zijn ongefilterd; het verschil zou kunnen komen door de aard van de meting (COG wordt afgeleid uit de positie, waar het kompas een magnetische meting is - en daarvoor bedoeld is), maar vooral de plaatsing: GPS antenne staat uit het midden op de hekstoek, waar het kompas 1 m vóór de kiel staat in het midden van de boot. Dat is een stuk gunstiger.



Verder valt, door de schaal, uit deze gafiek weinig te halen over de deviatie.

Hieronder is daarom de afwijking van het kompas tov de COG uitgezet tegen de COG. Deze puntenwolk zijn de ruwe data uit alle drie de rondjes. Toevallige afwijkingen (een golf bv) in rondje één worden dan uitgemiddeld met die in een van de volgende rondjes.


Hier is te zien dat het kompas statisch plm 1.5 graad afwijkt van de COG. Een deel hiervan wordt veroorzaakt doordat de COG tov het ware noorden is en de kompas de magnetische heading weergeeft.

Ook is te zien (ook in de vorige plot) dat er veel ruis op de fout zit rond 100 en 210 graden. Dat komt doordat de COG daar erg ruisig is geweest, waarschijnlijk door de hoek van de boot op de golven. Het kompas is daar een stuk rustiger.

Wat volgens mij "echte" deviatie is, is het gedeelte vanaf 0, via 60 tot 120 graden. Bij 60 graden lijkt het kompas zo'n 2 graden te weinig aan te geven, waar die afwijking bij 0 en 120 graden weer gereduceerd is tot de variatie. Ik heb geprobeerd er een curve door te tekenen:



Kompas is nog niet gecalibreerd trouwens; dit is zoals het uit de doos ingebouwd is...

Zal deze test nog eens herhalen na calibratie bij windstil weer en méér rondjes. Ik verwacht dat een deviatietabel dan niet nodig zal zijn.

Calibratie deel 2 - windset


Nu een echte tegenvaller, wat óf te maken heeft met de windset opzich, of de manier waarop deze op de masttop gemonteerd is (een 600 mm aan 2 kanten omgezette aluminium pijp van 22 mm doorsnede). Of iets anders...




Onderstaande plot geeft weer hoe AWS vs. AWA zich gedraagt tijdens het rondjes-varen op lage en hoge vaarsnelheid (snelheid ook weergegeven):


Ik begrijp de pieken bij +50 en -40 graden absoluut niet. Dit geeft in ieder geval aan dat de windset 5 graden uit het hart van de boot meet (aangezien je +45 en -45 zou mogen verwachten als die pieken er dan tóch zijn), maar wat ik niet begrijp is waardoor die pieken ontstáán. Turbulentie of versnelling door de mast/dikke pijp? Dit is notabene motorend! Ook bij +130 en -120 een soort pieken (en die zijn echt consistent bij 3x hetzelfde rondje!)

Bagger in = bagger uit uiteraard. Ik ben niet verder gegaan; dit moet eerst opgelost worden. Andere montage of toch een traditionele mechanische windset?

Ter illustratie hoe de TWS eruit zou zien op basis van deze data (SOG ipv STW gebruikt omdat ik die op dit moment méér vertrouw). Onbruikbaar...



In alle gevallen 4 knopen verschil in TWS die systematisch lijkt te zijn met de AWA. 4 Knopen is bij deze windsnelheden ongeveer een verdubbeling van de winddruk!

Wie heeft dit soort dingen wel eens systematisch getest? Wat denken jullie? Andere windset, andere montage (rechte pijp omhoog bv)? Onder helling zal het verhaal nog véél ingewikkelder kunnen worden.

Ik heb nog wel een ouderwetsche analoge VDO unit voor je liggen als je er belang bij hebt

Is overigens ook nieuw nog steeds te koop voor een luttele 900 euro en das alleen de gever maar.....
Maar goed die ligt bij mij op een plank niets te doen.

Heb mijn oude Triton sensor ook nog, maar vraag me af of dit soort onnauwkeurigheden aan de installatie ligt of het type meting. Specificaties van de sensor zijn een stuk beter dan dit namelijk (ik heb de 150 uit onderstaande serie): www.airmar.com/uploads/brochures/100wx.pdf

Heb jij dit soort testen weleens gedaan? Binnen 10 min een groot aantal koersen varen en de TWS loggen/op een papiertje bijhouden? Uiteraard zal die sowiezo iets varieren, maar er mag geen correlatie met de orientatie van de boot zijn volgens mij.

Ik neig nu naar m'n oude Triton om te bouwen naar een vertikale versie (stijve, dunne en lichte koolstof pijp en aangepaste voet), maar begrijp wat ik zie nog niet...

+/- 45° en +/- 135° zijn volgens mij wel precies de plaatsen van de kolometjes die bovendeel en onderdeel met elkaar verbinden toch?

Ik vind idd de 4 evenredig verdeelde pieken over de kompasroos verdacht, gezien de 4 transducer/4 kolommen constructie....

Het blijven onnauwkeurige metingen van verschillende gevers opgeteld. Zoals je zelf ook al zegt: Bagger in= bagger uit.


Je boot en je mast bewegen ook nog, om maar wat te noemen. Wind en bootsnelheid komt 1 keer per seconde binnen neem ik aan.
Dan maakt het dus uit op welk moment je gever toevallig meet.

Ik denk dus niet dat je er ooit een consequent resultaat uit krijgt.

Mijn multiview geeft wel een consequent resultaat. Maar dat is hier op kantoor met een computer als 'gever' . Op de boot is het allemaal weer helemaal anders....

@Koezt, BB: dat móet het zijn inderdaad! Wel waardeloos dat zo'n professioneel geprijsd apparaat wordt aangeboden met dit soort "fabrieks-af" fouten.

Dat ding kost normaal eur 1400; gelukkig heb ik er (véél) minder voor betaald. Experiment (had er goede verwachtingen van - behalve bij heel weinig wind en regen) mislukt dus.

De oude Triton 508 komt dus terug. Hoeveel zin zou het hebben om die te modificeren naar een VMU die bv 1m boven de masttop uitsteekt? Dit ivm mijn fathead grootzeil en wellicht sterkere upwash verschijnselen bovenin. Hoe minder ik hoef te corrigeren achteraf, hoe liever.

En waarom kosten zijn die officiële VMU's zo godsgruwelijk veel geld? Komt dat door dat stokje carbon, de constructie van de extra sterke voet, of zouden dit principieel andere, nauwkeurigere sensoren zijn dan "de gewone"? Waarom zouden die nauwkeuriger zijn dan? het meetprincipe is toch exact gelijk?

Ik zoek me wild naar specificaties maar B&G, RM etc laten niets los, zelfs niet betreft de duurste types. NKE, Airmar etc wel, maar Airmar laat ik maar even liggen en NKE doet niet aan NMEA2000.

Heeft iemand wel eens testen gezien?

@Chris: met 4 Hz, maar de rondjes zijn in vergelijking daarmee zó langzaam gevaren dat zelfs vertragingen van meerdere seconden geen probleem zouden zijn. In dat opzicht is dit rondje een soort parameter-run, waarbij het systeem op elk tijdstip quasi-stationair is. Die plotjes met de verschillende vaarsnelheden zijn dat niet: die zijn alleen geldig indien de bootsnelheid haar eindwaarde (of iets daar omheen in dit geval) heeft bereikt. Ruisig is het sowiezo; ik had ook achteraf kunnen filteren natuurlijk. Als je alle data door hetzelfde filter haalt blijven de tijds-relaties instand.

Bij deze windset is echts iets fout met de meting an-sich (Koezt en BB zeggen dit ook).

Kun je misschien uitsluiten door het ding 45° te verdraaien en nog een keer de wind te loggen. Als je dan weer pieken krijg bij 0 en 180° en bij +/- 90° heb je je antwoord.

Ding moet overigens verticaal gebruikt worden. Speelt dat nog een rol?

Hij stond behoorlijk vertikaal nu, ik denk max 5 gr uit het lood (zie foto). Indien dát de oorzaak is van de pieken, belooft dat niet veel goeds over hoe het ding onder helling zal presteren. Referentievlak verschuift dan niet alleen tov de wind, maar wellicht zal het de luchtstoom dóór het apparaat nóg meer verstoren.

Interessant om het ding een stukje te verdraaien en nog eens te kijken, hoewel ik je theorie helemaal aanneem.

En ook de kompassensor zal bij scheefstand meetfouten gaan geven.

Staat overigens gewoon in de documentatie hoor.

De kompassensor gebruik ik niet. Er staat idd ergens beschreven dat ie vlak en vertikaal moet zijn geplaatst:

Die "errors in wind readings" heb ik geinterpreteerd net zoals een mechanische sensor deze heeft. Dus omdat je onder een hoek meet, meet je een COS(hoek) lagere snelheid. Denk jij dat dit meetprincipe in zichzelf niet onder helling kan werken om andere redenen zoals turbulentie? Dan is ie, ondanks de NMEA outputs alleen maar geschikt voor grote motorboten of koopvaardij; in ieder geval niet als meetinstrument in de mast van een zeilboot.

@Sunday, rooiedik: als jullie mee lezen: hoe consistent ervaren jullie je apparaten?

Ding cardanisch ophangen?

nogmaals bagger in -- etc

Gaat niet werken dit

De afgelopen dagen gewerkt aan de black-box-versie van PolarPlot, werknaam "PolarBare". Deze is van alle grafische gimmicks gestript en gebruikt geen video uitgang maar schrijft de berekeningsresultaten (performance en UA/DA) naar de bus. Deze data kan dan zowel binnen als buiten getoond worden, afhankelijk hoe je de aangesloten kaartplotter of repeaters instelt.

Ook opent dit de weg naar toepassing in "niet-Aurora" N2K/STng netwerken.

Na veel gepuzzel, getest en gedebug werkt het! En stabiel genoeg om mee aan boord te nemen verwacht ik.

Wat heb ik gedaan:

• In de parsing van binnenkomende PGN's is de ISO Request (PGN 59904) toegevoegd die de afhandeling voor de twee meest essentiële PGN's (60982 - ISO Address Claim en 126996 - Product Information) verzorgt.
• Dankzij een nieuwe feature in het CANboat project "socketcan-writer" kan nu op hoger niveau naar de bus geschreven worden. Dat scheelt een boel geprogrammeer en het debuggen (de manier waarop ik ontwikkel ) is een stuk eenvoudiger.
• Schrijven gaat via een extra TCP server die gepiped is naar deze nieuwe tool die naar de bus schrijft. Alles wat PolarBare naar die server schrijft wordt direct doorgestuurd via socketcan-writer naar de bus.
• De datagrammen van 60982 en 126996 uitgeplozen in Excel in een statisch en dynamisch stuk. Het dynamische stuk is het Source adres; dit kun je instellen in de configuratiefile op een adres wat de rest van je apparaten niet gebruiken. Bij mij aan boord zit alles tussen 0 en 30, dus ik heb 100 gekozen.

Wat zijn mijn leerpunten geweest:

• Een goed bedoelde update/upgrade heeft dingen kapot gemaakt: zo werkte de JSON parsing opeens niet meer. Ik weet niet of dat veroorzaakt werd door een verandering in Free Pascal, de JSON libraries of de CANboat utilities. Na terugdraaiien werkte alles weer.
• De Product Information PGN is een zogenaamd "fast packet", wat 134 byte aan gebruikte datavelden heeft. Deze PGN wordt in totaal 20 zinnen met elk 8 data bytes verzonden. Wanneer deze zonder pauze verstuurd worden, loopt de buffer van de socketcan-writer vol. Door tussen deze 20 berichten 50 ms pauze in te lassen gaat dit schrijven goed tussen het reeds op de bus aanwezige verkeer
• De CANsockets van Linux en de bijbehorende CAN-utils zijn heel erg flexibel in te zetten!

Hier het datagram van de ISO Address Claim. Je ziet dat dit één PGN is met 8 data bytes. Een byte is dan weer 8 bit. De verschillende velden lopen over byte grenzen heen! Dat is erg onhandig:




En deze hieronder is van de Product Information (134 data bytes als fast packet verzonden):




Om te testen (thuis) is de testomgeving een beetje ingewikkelder dan aan boord: om met eerder opgenomen data te kunnen testen én heen en weer te kunnen communiceren naar de nu aangesloten apparatuur (repeater en fuel sender), heb ik wat filtering toe moeten passen om te voorkomen dat de "echte" repeater over de zeik zou raken door een overschot van boord data - die nu natuurlijk geen response zou geven op ISO Requests Daarom zijn tijdelijk 2 virtuele CAN bussen aangemaakt (vcan0 en vcan1).

• Logfiles worden afgespeeld naar PolarBare; deze data komt nu niet aan bij de Triton;
• Performance en UA/UD data komen wél aan bij de Triton;
• Data van de Triton en Fuel Sender komen ook aan in PolarBare, gemixed met de data uit de logfile;

Nu ziet het er zó uit:



Straks aan boord verdwijnen de vituele can0 en can1 en gaat alles van en naar can0 (dat is de gateway van de PiCAN2 naar de hardware CAN bus). Dat ziet er een stuk eenvoudiger uit:


Een klein filmpje als bewijs Al het grafische moet ik er nog uit slopen (of, in plaats daarvan, een extra toggle in de configuratie file maken die het grafische stuk uitschakelt). Beeld ziet er nogal schokkerig uit; dit komt omdat de VNC server er tussen hangt en het geheel in de debug mode draait.

Weer iets uitgebreid omdat ik toch meer van wijzers houd dan getallen.

Ik stuur (via een extra PGN - er zijn nu 2 virtuele devices), nu de performance, UA (of UD) en target speed het netwerk op.

Onderstaand scherm heb ik geconfigureerd voor PolarBare. In het midden de performance, links de target en actuele snelheid; rechts de target en actuele true wind angle voor maximale VMG.

Nu echt mee naar de boot...

Indrukwekkend! Benieuwd naar de échte resultaten

Gepost met de officiële Zeilersforum-app

Dank je, ja ik ook. Wordt tijd om gewoon te gaan zeilen

Indien hier mensen zijn die het op hun N2K/STng netwerk willen testen/gebruiken, PB me maar. Buiten een RPi heb je alleen de interface nodig (eur 35 geloof ik).