Deftige meetopstelling voor luisprekerparameters

[timpert]

Dat doe ik nu. Net als Klippel overigens, die gebruikt geeneens de RS232. Klippel levert een voorgeconfigureerde controller en stelt het gewenste bereik in met de externe besturingslijntjes. Zo kan je ook tussen de 8 programma's schakelen.

Nadeel is dat de resolutie van de analoge uitgang beduidend lager is dan die van de sensor zelf. De analoge scaling is wel in te stellen, maar je moet dus kiezen tussen bereik en resolutie. Maar als je de digitale waarden gebruikt krijg je allebei.

[OWC]

Nadeel is dat de resolutie van de analoge uitgang beduidend lager is dan die van de sensor zelf. De analoge scaling is wel in te stellen, maar je moet dus kiezen tussen bereik en resolutie. Maar als je de digitale waarden gebruikt krijg je allebei.

Ja dat heeft volgens mij met de microcontroller en DAC te maken die aan boord zit.

De vorige die had was van Omron, en na lang heen-en-weer mailen, bleek die ineens een proprietary digitale uitgang te hebben.
En (net als jij) had ik niet echt zin om NOG een project te hebben, lol
Of ik moest een hele dure extra unit erbij kopen (waar ik geen zin in had).

Wel jammer, want die kon tot 16kHz samplen

Ik snap alleen niet helemaal waarom de sampling en clock van de de laser een probleem zou zijn als het een analoge output is?

[timpert]

Het is inderdaad een kleiner probleem dan wanneer de bron en DAQ niet synchroon lopen, dus dat laatste pak ik eerder aan. Maar het is wel een van de vele puntjes die op de I's gezet kunnen worden. Als ik de digitale waarden gebruik is gelijkloop wel vereist, en dat geeft veruit de mooiste resultaten.

[OWC]

Maaruhm, even alles op een rijtje.

Wat heb je nu precies werkend?
Van je eerdere berichten begreep ik namelijk dat Kms(x) nog niet werkte, maar nu wel?

[timpert]

Ik heb nu de lineaire parameters en BL(x) werkend. Ik kan er pas volgende week weer mee verder.

[OWC]

Oh okay, het leek even dat je de rest ook had.

Hier nog meer interessant leesvoer van meneer Novak om het via een harmonic control methode te doen;

[OWC]

Eindelijk

[timpert]

Doet 'ie ut al?

[OWC]

Ja!

Duurder even, kreeg in het begin onzin metingen.
Maar de averaging stond standaard aan, dat werkt dan natuurlijk niet lol

Hoe meer ik er over denk, hoe meer het zinnig is om hier even een eigen platform en PCB voor te maken.
Er zijn namelijk wel een paar dingen die anders heel onpraktisch worden.

- referentie nul instellen, dat kan met de multi purpose pin, maar is knullig om dat handmatig te doen

- veel belangrijker is de boel kalibreren, het makkelijkste gaat dat met van die precisie blokjes.
Die zijn helemaal niet zo duur en heel nauwkeurig tot <1 micron.
Probleem is nu dat een geluidskaart niks kan met DC signalen.
Nu zou je dit eerste met een scope oid kunnen doen, de output van de LDS is namelijk 1 op 1.

Vervolgens moet je dan ook nog de geluidskaart, preamp ed kalibreren.
Dat kan dan vervolgens weer met een een sinus signaal.

Al-met-al wordt dat mega onpraktisch op deze manier.

Ik moet nog even mijn geluidskaart doormeten (EMU Tracker pre), maar die heeft ook duidelijk een HP op iets van 10-15Hz oid.
Idem voor de eindversterker.

Overigens loopt het signaal van de LDS van 0-10V, met een max van +15V
Dus die kan zo in elke audio device die ook phantoom spanning aan boord heeft (= 48V)

[timpert]

Als je alleen AC gekoppeld meet, dan hoef je de uitgang toch niet op nul te stellen? Dan is het juist handig om niet op nul te stellen, zodat je de afstand tot de sensor fysiek netjes in het midden van het bereik kan zetten. Ik meet DC gekoppeld, dus voor mij is nul stellen wel handig, zeker wanneer ik de gevoeligheid opdraai. De procedure is bij mij momenteel als volgt:

• Sensor op absoluut (nulstelling opheffen), volledig bereik op de analoge uitgang
• Met de zwaluwstaart de uitlezing op het display van de controller zo dicht mogelijk naar 0 draaien, dan zit je midden in het meetbereik
• Speaker laten wapperen bij de gewenste amplitude van het meetsignaal om de totale uitwijking te bepalen
• Sensor op het juiste bereik instellen en via de RS232 op nul stellen
• Meting doen
• Nulstelling via RS232 weer opheffen en de sensor weer op het grootste bereik zetten

[OWC]

ls je alleen AC gekoppeld meet, dan hoef je de uitgang toch niet op nul te stellen?

Nee, in principe niet.

De DLS heeft echter wel een bereik waarin je moet blijven voor de nul-positie.
Daarnaast wordt ook de nauwkeurigheid buiten een bepaald bereik slechter.
En praktisch gezien loop je dan eerder tegen de positieve of negatieve limiet aan (afhankelijk waar de offset is)
Hoewel dat in mijn geval ±15mm is, dus behoorlijk veel lol.
Dit zou je zelfs nog kunnen vergroten naar 29mm door twee metingen te doen en die te mergen.

Ik bedenk mij alleen net, dat als je wilt weten hoe symmetrisch de ophanging reageert, je dit wellicht niet eens met een AC ADC kunt doen?

Een DC ADC biedt trouwens nog een voordeel, we kunnen dan namelijk ook Re meten.

Hoe ijk jij je opstelling nu dan trouwens?
Want de waardes die je in je programma krijgt zul je toch een ijking moeten geven?
mm/V in dit geval.

Tenzij je heel exact weet wat je pre-amp etc doet, maar dat is wel gedoe en niet heel nauwkeurig.
Dat kan dus alleen maar met een afstand die nauwkeuriger is dan de resolutie + (lineaire) onnauwkeurigheid van de LDS.
Of als tweede, maar minder nauwkeurig, alternatief een sinus signaal insturen zodra bekend is wat de mm/V waarde is van de LDS.

[timpert]

Een DC ADC biedt trouwens nog een voordeel, we kunnen dan namelijk ook Re meten.

Dat doe ik nu ook al, aan het begin van de meting kan je kiezen om een waarde voor Re in te vullen, 'm te meten met een extern DC bronnetje (in mijn geval een oud maar erg handig Delta Elektronika CST100 stroombronnetje) of te schatten uit het AC impedantieverloop (onnauwkeurig).

Hoe ijk jij je opstelling nu dan trouwens?

Mijn DAQ kan worden geijkt en gejusteerd met een programmaatje dat onderdeel is van het softwarepakket, maar dat bleek de laatste keer dat ik 'm checkte niet nodig. Een voordeel van een "echte" DAQ is dat de driver meteen corrigeert voor de ijking en een floating point array met gemeten spanning in Volt ophoest waarin ook al de preamp gain (omschakelbaar tussen 1x en 10x) is verdisconteerd. De sensor check ik door 'm een stukje op te schuiven, met de schuifmaat op te meten hoe veel ik 'm heb opgeschoven en dat met het display op de controller te checken. Vervolgens berekenen hoe veel spanningsverandering het ding zou moeten produceren op grond van de ingestelde gevoeligheid, en dat nameten met de multimeter. Maar ook die kon ik gewoon op de fabriekswaarden laten staan, voor beide koppen, want ze bleken allebei binnen spec voor zover ik dat met mijn ietwat primitieve methode kon checken.

Dit zou je zelfs nog kunnen vergroten naar 29mm door twee metingen te doen en die te mergen.

Dan moet je sensor wel subiet zich herstellen na een "out of range". Mijn beide Keyence sensoren (zowel mijn LK-G5000 sensoren als mijn oudere LK-081) hebben even de tijd nodig om van de schrik te bekomen als ze de lichtspot zijn kwijtgeraakt, dit heeft met name te maken met de auto exposure die de sterkte van de laser aanpast om een goed signaal te krijgen. Voordat je een valide signaal krijgt moet eerst de exposure weer goed zijn ingesteld.

[markbakk]

Chapeau hoor!
@Bart

Een DC ADC biedt trouwens nog een voordeel, we kunnen dan namelijk ook Re meten.

Dat begreep ik niet, of bedoel je dat je de ADC ook als stroom/spanningsmeter wil gebruiken?

[OWC]

@markbakk:
Precies dat

[Chocomel]

Wauw, ik zie je topic nu pas. Mooi werk!

[timpert]

Ik had een onvoorziene vertraging. De laptop die ik gebruikte is voorzien van een klassieke "barrel jack" voedingsplug, en maakte via het voedingssnoer een aardlus samen met de versterker. Dat zorgde voor nogal wat interferentie omdat de min uit de laptopvoeding aan aarde hangt en de DC voedingsstroom voert. Meten deed ik daarom met de laptop op batterijvoeding. Die "barrel jack" heeft ook als rottige eigenschap om eerst de plus te verbinden, en dan pas de min. Als je de voeding insteekt gaat dus kortstondig de voedingsstroom van de laptop (inclusief inrush) door de mantels van de signaal coax lopen, en dat werd de DAQ module op een gegeven moment te veel. Een EMI onderdrukkingsspoeltje gaf de geest en de opstelling werkte niet meer.

Wat profaniteiten en een uurtje foutzoeken en solderen verder werkte de DAQ weer, maar om in de toekomst verdere ellende te voorkomen heb ik toch maar een USB isolator ertussen gezet, en de laptop vervangen door een oude desktop (die ik gratis van mijn werk kon meenemen) omdat die geen voedingsstroom door de aardgeleider heeft lopen. De aardlus is opgelost, python en alle libraries staan op de desktop en de opstelling werkt weer netjes en vooral storingsvrij. Windows heb ik ook even en passant geupgrade naar W11, dus de opstelling blijft het ook na volgend jaar doen. En door...

[OWC]

Windows heb ik ook even en passant geupgrade naar W11

Je bedoelt gedowngrade

Heb afgelopen weken ook even geen tijd gehad, beetje druk met werk.
Moet daarnaast ook nog even een oplossing vinden voor een ADC.

Ik heb nog even rondgevraagd naar mensen met een Klippel LSI systeem.
Het lijkt er inderdaad op dat Klippel een soort van (roze) ruis oid gebruikt voor de metingen.

Ik ga Novak nog even contacteren, zij gebruiken volgens mij een net iets andere methode.

Ground-loops blijven altijd lastig.
Jaren geen last van gehad, maar heb het nu ook behoorlijk.
Welke USB isolator heb je precies gekocht?

[timpert]

een soort van (roze) ruis oid

Klippel gebruikt een zogenaamde "sparse multitone", dat is een signaal dat bestaat uit sinussen die in frequentie logaritmisch over het gewenste bereik verdeeld zijn met willekeurige fase om de crest factor een beetje in bedwang te houden. Ik heb zo'n signaal al eens met mijn functiegenerator gemaakt, het klinkt een beetje alsof iemand met een zeer royale derrière op de toetsen van een vals orgel is gaan zitten. Door de logaritmische verdeling is de energie per octaaf/decade constant, net als bij roze ruis. Door het aantal tonen juist te kiezen komen er in het oorspronkelijke signaal geen frequenties voor die elkaars harmonischen zijn, dus vervormingsproducten komen tevoorschijn als nieuwe lijnen in het spectrum.

Het probleem waar ik toen tegenaan liep was dat mijn functiegenerator en DAQ niet synchroon geklokt zijn, waardoor er spectrale lek in de FFT optrad en het signaal een stuk minder goed bruikbaar werd. Een klein experimentje leerde dat ik vrij makkelijk een gedwongen trilling aan het 24 MHz kristal in de DAQ kan opleggen, als ik die 24 MHz uit het tweede kanaal van de functiegenerator haal zijn ze wel synchroon en is de lek verdwenen.

Mijn functiegenerator lust een externe referentieklok van 10 MHz, daarom heb ik een doosje ontworpen dat de 10/20/50 kHz sampleklok van de lasersensor als ingang neemt en met 2 PLLs een klok van 10 MHz en een klok van 24 MHz produceert voor de generator en DAQ. Zo lopen ze alle drie met elkaar in de pas en kan ik ook de digitale data uit de sensorcontroller gebruiken voor maximale signaalkwaliteit. Ik vond "the rug" wel een passende naam voor dat doosje. Printje en onderdelen verwacht ik na het weekend te ontvangen.

Mijn USB isolator is een Exsys EX-1452IS, geheel in de spirit van dit project tweedehands aangeschaft.

[OWC]

Het probleem waar ik toen tegenaan liep was dat mijn functiegenerator en DAQ niet synchroon geklokt zijn

Die DAQ heeft toch ook een DAC aan boord?

[timpert]

Dat klopt, maar die kan alleen maar een heel klein ringbuffertje van maximaal 8192 samples afspelen en niet streamen. Dat is veel te weinig voor een sparse multitone of een periodiek ruissignaal. Mijn functiegenerator heeft in arbitrary mode een buffer van 2 miljoen samples en een vrij te kiezen samplerate, dus daarmee kan je een multitone met een frequentieresolutie van 0,025 Hz of een periodiek ruissignaal van 40 seconden produceren bij een samplerate van 50 kHz. Die samplerate wordt als "the rug" werkt ook nog eens exact gelijk aan die van de lasersensor en van de DAQ, waardoor iedere frequentie in het bronsignaal precies door 1 lijn in het FFT spectrum wordt weergegeven, en dat is wat je wil.

[Henkjan]

That rug really tied the room together.

[timpert]

Juistem!

Ik heb alvast de externe 24 MHz klokingang op de DAQ module gemaakt. Daarvoor heb ik de tachometer ingang opgeofferd, want die gebruik ik toch niet. Ik heb met een weerstandsdeler en een 10 pF condensator de externe klok aan de Xtal-in van de master oscillator verbonden, zodat de externe klok zwak gekoppeld is en de oscillator gewoon zelfstandig werkt zolang er niks is verbonden. Als ik een 24 MHz klok met een amplitude van > 1,7 Vpp aanbied, gaat de klok over van een spontane naar een gedwongen trilling en loopt de DAQ synchroon met de externe klok. USB communicatie blijft doorgaan, dus je kan gewoon tijdens bedrijf de externe klok in- en uitschakelen.

Heeft dat nou zin? Ja! Allereerst een voor- meting, dus zonder gesynchroniseerde klokken. De DAQ is hier ingesteld op een samplefrequentie van 50 kSPS en acquireert gedurende 2 seconden (100.000 samples dus) voor een frequentieresolutie van 0,5 Hz. De functiegenerator genereert 5 kHz bij een amplitude (piekwaarde) van 1 V en is direct aan de DAQ gekoppeld. Als ik van de geacquireerde golfvorm een FFT neem verwacht ik de 5 kHz lijn te vinden op x-positie 10.000 (5.000 / 0,5) met hoogte 50.000. Helaas pist 'ie een beetje naast de pot:

Dit is een uitsnede van het spectrum, 10 op de x-as is positie 10.000 in het het spectrum. De piek zit niet op positie 10.000 maar op positie 9.999 en is 47.000 hoog, een meetfout van 6% dus als ik alleen naar de hoogte van de piek kijk. Ook is er veel spectrale lek te zien, op de naastgelegen lijnen is de amplitude significant groter dan 0. Natuurlijk is het nog steeds mogelijk om het signaal hieruit te reconstrueren, maar handig is dat niet. Dat kan beter.

Ik heb kanaal 2 van de functiegenerator nu op 24 MHz ingesteld, en verbonden met de nieuw gemaakte externe klok ingang. Het kristal gaat over in een gedwongen trilling, en de klokken van de functiegnerator en DAQ zijn nu gesynchroniseerd. Zelfde proefje levert nu dit spectrum op:

Bingo! De na- meting heeft de piek nu op positie 10.000 (waar 'ie hoort), de amplitude is de verwachte 50.000 en op posities 9.999 en 10.001 is de FFT weer netjes terug naar nul. De meetfout en spectrale lek zijn verdwenen, maar even belangrijk is dat de posities van de pieken in het spectrum in het gemeten signaal exact vastliggen en op voorhand te berekenen zijn.

Overigens is deze stijl van plotten niet helemaal gepast: er horen alleen punten in te staan die niet door een lijn zijn verbonden. Ik was echter te lui om de grafieken te formatteren, dus je ziet gewoon de default matplotlib stijl.

[markbakk]

Doe-het-zelf synchrone AD/DA… chapeau hoor

[timpert]

En het "sparse multitone" signaal werkt ook. Het signaal is gemaakt door eerst 201 frequenties logaritmisch te verdelen over de frequentieband (in dit geval 5 Hz - 20 kHz) en vervolgens sinussen van die frequenties met willekeurige startfase bij elkaar op te tellen. Dat resulteert in een breedbandig testsignaal met een crestfactor van ongeveer 5. Bij een tijdsduur van 10 seconden wordt de frequentieresolutie 0,1 Hz, de gekozen frequenties zijn uiteraard afgerond op hele veelvouden daarvan. Met een meting van 10 seconden kan je vervolgens bijvoorbeeld een impedantie bepalen, dat ziet er dan zo uit:

Deze grafiek is wat minder schoon dan een "stepped sine" meting, maar de tijdsduur van de meting is ook veel korter. Een "stepped sine" meting duurt net geen 4 minuten, deze meting is in 10 seconden klaar. Mocht je je nou afvragen hoe zoiets klinkt en eruit ziet, hier een filmpje van de meting. Voordat je op play drukt een waarschuwing: het is een erg onaangenaam geluid, dus pas op met het volume.

Met dit signaal is het ook mogelijk om niet-lineaire parameters te bepalen. Later dit weekend probeer ik nog even periodieke roze ruis te genereren.

[timpert]

En weer wat gevorderd. The Rug werkt! Het printje detecteert de frequentie op de STROBE uitgang van de lasersensor controller, deelt die afhankelijk van de frequentie door 1 (voor 10 kHz sampling), 2 (voor 20 kHz sampling) of 5 (voor 50+ kHz sampling) en stuurt de resulterende 10 kHz naar de beide PLLs als referentie. De oscillatoren zijn MEMS VCO's die de 10 MHz en 24 MHz referenties produceren voor respectievelijk de functiegenerator en de DAQ. Hier het kale bordje dat ligt te wachten op een wasbeurt:

Gesopt en ingeblikt ziet het er zo uit, de ribbonkabel die links uit de behuizing komt gaat naar de controller:

Hier is het ding gelockt terwijl de samplerate van de lasersensor op 50 kHz staat. Nu zou je verwachten dat, wanneer beide PLLs gelockt zijn, de 24 en 10 MHz ook exact een factor 2,4 van elkaar verschillen. Dat is heel makkelijk te checken door op de functiegenerator de 10 MHz als referentieklok aan te bieden, en vervolgens op de frequentiemeetingang de 24 MHz aan te bieden en de frequentie te meten. Je zou exact 24 MHz moeten krijgen.

Dat lijkt vrij aardig te kloppen. Gedurende 5 minuten is de gemiddelde frequentie 24,000000 MHz, de hoogst gemeten frequentie 24,000000 en de laagst gemeten frequentie 24,000000 MHz met een deviatie van 0,000 ppm. Ik denk wel dat het ding werkt.

Maar dat is niet alles. Het is me gelukt om de controller te bedienen en uit te lezen via USB en Ethernet, waar ik tot voor kort alleen nog RS232 kon gebruiken. Het snelheidsverschil is tamelijk overtuigend. Om te testen heb ik de interne buffer met 1.200.000 datapunten gevuld en vervolgens uitgelezen over USB, Ethernet en RS232 met de volgende resultaten:

• USB: 3,22 seconden
• LAN: 3,72 seconden
• RS232: 929 seconden (geen tikfout!)

Hoewel USB het snelst is, ga ik toch voor Ethernet vanwege de galvanische scheiding. 1.200.000 punten komt overeen met een meting van 24 seconden, en het binnenhalen van de resultaten daarvan kost nu enkele seconden in plaats van een dik kwartier. Omdat de laser, de DAQ en de functiegenerator op exact dezelfde samplerate werken, is de digitale data die ik van de laser download direct bruikbaar. Ik denk dat ik hiermee wel zo'n beetje de maximale prestaties uit alle hardware heb gemolken.