Uitlezen / signaal verwerking audio interface.

Dat zal toch afhangen van de betreffende implementatie op die interface?

Een of ander standaard audio opneem programma, en dan achteraf door een of ander nabewerkings programma halen?

Of moet het "real time"?

Er zijn vast tientallen programma's die dat kunnen.

Zonder PC / USB ... Misschien is een Teensy interessant. 't is een ARM uC op zo'n 600MHz en er zitten uitgebreide bibliotheken bij om audio signalen te bewerken.

Vreemde eenden bijten:
Ik weet dat ngSpice (In KiCad of anders) opties heeft om een audio file als input voor een simulatie te gebruiken.

Of iets richting Matlab, GNU Octave of python met matplotlib en dergelijke. Daar zitten ook afwegingen tussen hoeveel je "voorgeprogrammeerd" wilt hebben en hoeveel flexibiliteit je wilt.

Afgezien van de frequentie klinkt dit als iets wat een wat uitgebreide SDR ontvanger zou kunnen.

Ha Arco,

Ik heb een sound box gekozen van Focusrite de scarlett 4i4 deze is redelijk recht toe recht aan dus niet te veel ruis en vervorming in het analoge signaal pad.
Er is een control center als software heel mooi voor de musici in de studio of on stage maar niet direct voor de electronics/physics.

@ Kortsluiting_Online,

Ja daar noem je er een paar Matlab dat gebruik ik voor uitlezen meetapparatuur maar of daar zo'n krachtige DSP engine in zit zal je wel moeten aanschaffen?
De andere programma's wel wat mee gedaan KiCad voor tekenen maar te weinig om een twee drie aan de slag te gaan.
Ik had ook geen idee dat je daar iets mee kon op dit terrein dus ik heb een drie tal boeken gekocht om Python te leren maar..... of dat in dit leven nog lukt dat vraag ik me af ?
Wat een taal wie heeft dat gemaakt man man, eerlijk gezegd dat typen is niet mijn ding maar ja.....

@Frederick E. Terman,

Dat was mijn eerste idee verleden jaar een SDRplay RSP1B aangeschaft maar dan moet ik twee hebben voor kruiscorrelatie twee gescheiden paden.
Die scarlett 4i4 heeft twee gescheiden paden dus twee keer een twee kanalen ADC 24 bit maar wel een synchrone klok.
Dat voordeel zou ik ook met twee keer een RSP1B hebben is denk ik zeker het overwegen waard geen DC ontvanger nodig ?
Maar de RSP1B is een 14bit ADC misschien voldoende eens kijken, waarom ging ik richting twee SDR ontvangers gescheiden voeding gescheiden klok die ik wel kan corrigeren of een digitale sync??
Waarom ik daar vanaf gestapt ben ? ik heb geen idee misschien toch de resolutie van de converter.

PS: even mijn papieren er bij gepakt, want waarom ben ik er niet mee doorgegaan wel interessant @Frederick E. Terman.

Ik zit eigenlijk in de hoek van:

coherente meting (fase + amplitude)
zeer kleine verschillen detecteren
waarschijnlijk lage IF / baseband analyse
hoge dynamiek daarom 24-bit idee

Dit is géén "radio luisteren" probleem
Dit is een meetprobleem

Wat een SDR zoals de SDRplay RSP1B echt is

Belangrijk:

14-bit ADC (effectief vaak ~11–12 ENOB)
interne tuner (mixer + LO + filters)
AGC / gain stages
USB streaming
niet ontworpen als meetinstrument

Dit introduceert:

fase jitter (LO)
amplitude variatie (gain chain)
temperatuur drift
onbekende interne DSP stappen

14-bit vs 24-bit (dit is de kern)
14-bit SDR (praktisch):
~70 dB bruikbare dynamiek
ruisvloer relatief hoog
afhankelijk van gain instellingen
24-bit audio/meet ADC:
110–130 dB dynamiek
extreem lage ruisvloer
lineair gedrag

Voor mijn toepassing (fase + kleine verschillen):

die extra ~50 dB is geen luxe — dat is het verschil tussen “zien” en “niet zien”

En zo kwam ik verleden jaar op veel meer verschillen dit niet te overbruggen waren dus heb ik geen tweede aangeschaft en eigenlijk deze nog nooit aan een antenne gehangen over....

Ik denk dat mijn 100 MHz DC ontvanger het beste betaalbaar is.

Groet,
Henk.