Interessant, nu komen we op het gebied van real-time signaal theorie. Lang geleden voor mij dus schieten mag!
Daarbij gebruikt Polarplot stukken synchrone code (heet dat zo? Ik doel op een vaste, getimede executie) gecombineerd met asynchrone, event-driven data-handling. Absoluut niet real-time dus! Windows is ook geen real-time systeem: het systeem-timertje wat ik gebruik om de hoofdlus en logging te timen geeft alléén een event als daar even tijd voor is. De intervals tussen de timestamps van de PC klok (wat een system-call is) liggen (bij 10 Hz) tussen 95 ms en 109 ms! Dat is al een jitter van 14%; RMS zal de jitter rond 10% liggen.
Wat Erwin beschrijft zie ik als methode om de timing toch synchroon te kunnen houden (door correcties op de data in het tijdsdomein te doen op basis van die time-stamps). Eigenlijk ben je de data aan het her-klokken.
Zou dit ook nodig zijn indien het systeem een aantal keren sneller is dan de kritische snelheid van die toepassing, ofwel kunnen we er hier zonder die correcties mee weg komen?
De vraag is denk ik of dit alles echt van belang is bij deze toepassing. Ockam en B&G units draaien (real-time?) op 4 Hz en doen aan motion-correctie bij die snelheid.
Stel dat er (op die 10 Hz) af en toe een sample gemist wordt of een heel sample te laat binnenkomt. Is dat dan een probleem, wetende dat een 4 Hz timing in de praktijk voldoende is? Ik denk zelf dat jitter (zelfs als de klokruis 50% van dT zou zijn) nog steeds geen echt probleem is.
Wat 3Noreen en Boarderbas noemen zou ook van belang kunnen zijn. Valt (bij deze implementatie) alleen op te lossen door te filteren. Een eerste orde filter met tau=1s geeft al een group delay van >0.5s dacht ik. Zo'n filter dient dan op
alle metingen toegepast te worden, zodat de dataset synchroon blijft. De traagste (laagst-gesampelde) meting zal bepalend zijn.
Verder zou het nog zo kunnen zijn dat een of meer van de sensoren zélf aan filtering doen. Formeel dient aan elke AD conversie een pre-sampling filter vooraf te zijn gegaan om aliasing in het digitale domein te voorkomen. Stel dat een analoog signaal met 5 Hz gesampled gaat worden, dan is de maximale frequentie die je kunt registreren 2.5 Hz (Nyquist, Fs/2). Dit vergt dan een pre-sample filter wat alle harmonischen met hogere frequentie wegfiltert. Doe je dat met een (slap) eerste orde filter (geen goed idee in het algemeen, je ziet vaker brick-wall filters), dan heeft zo'n eerste order filter een tijdsconstante van 0.5 s. Dat geeft dus een vertraging aan deze meting, terwijl een sneller bemonsterd signaal deze vertraging niet heeft.
Hierbeneden nogmaals de AWA en HDG, bemonsterd en gelogd met 20 Hz. Nu zie je duidelijk hick-ups ontstaan. Ook zie je dat dit ook de frequentie van de HDG sensor is, aangezien je vaker gelijke opeenvolgende samples ziet.
Op de bus kijken lijkt me nuttig, echter aan de sensoren zelf valt weinig te tweaken. Ik vermoed dat het er in Polarplot (in déze opzet) gefilterd moet gaan worden (zeker met tau=0.5s) en de mast-motion niet gebruikt kan worden...