Samplingssystem

[Electricguy]

När jag lekte med Arduino som ljud DSP för att trycka ihop, dra ut och invertera ljud så körde jag med biased analog in och en 8-bit R2R ladder DAC. Det samplade med 38kHz har jag för mig och lät helvete så illa. Gammal testinspelning med galaxens sämsta låt.

[Spisblinkaren]

Ja, det lät ju inte så bra

Nu ska iofs jag inte använda Arduino för att spela in och återge musik med kvalitet, jag ska spela in enskilda rena toner vilket jag tror är nåt helt annat än att sampla musik typ med alla frekvenser på en och samma gång, liksom.

Jag kommer nog göra programmet som så att jag börjar lägga ut 6Hz och samplar sen lägger jag ut nån frekvens strax över (jag får se vad det blir för logaritmiskt increment) och samplar osv.

MVH/Roger

[Spisblinkaren]

Då är det faktiskt bara programmeringen kvar, så enkelt är det att starta upp ett Arduino-projekt!

Men vi måste sakta oss i backarna och fråga oss om detta verkligen kan fungera?

Låt oss titta på vad vi har till förfogande.

Klockfrekvensen hos UNO är: 16MHz.

Grova uträkningar av generator-sidan:
Säg att jag vill ha minst 10 steg tidsmässigt i signalerna, för 60kHz innebär det att signalen måste genereras med minst 600kHz frekvens.

När signalen genereras så måste ett digitalt värde alltså ligga ute på "bussen" minst 600kHz, detta värde måste också hinnas "konverteras" till rätt analogt värde, låga värden på R2R minimerar uppladdningstider pga ingångskapacitans hos OP.

Jag har god lust att välja 1k/2k för R2R pga detta, av databladet att döma ska I/O kunna leverera hela 40mA så små motstånd är inget problem.

Ja, det ser ut som om generationen av digital sinus inte är några problem.

Grova uträkningar av A/D-sidan:
UNO nyttjar successiva approximationer, knappast världens snabbaste konvertering men är enkel.

A/D'n är på tio bitar vilket ungefär innebär 1000 LSB.

Jag är lite osäker på hur succesiva approximationer går till och framförallt hur många klockcykler som går åt, det är ju inte 1000 men säg i alla fall 100.

100 cykler ger 16M/100=160kHz som max kvarvarande systemfrekvens dvs den kan göra nya samplingar 160kHz.

Med andra ord kan 60kHz bara samplas max tre gånger.

Allt detta utan hänsyn tagen till processorns overhead dvs administarativa rutiner såsom t.ex interrupt-rutiner och annat.

Nu skulle jag vilja veta mer exakt hur många cykler det går åt att konvertera ett sampel till nåt digitalt (att det är fler än 10 dvs en per bit är ju uppenbart), för det här ser inte så bra ut

MVH/Roger
PS
Jag kommer nog köra den strukturen jag ritat i senaste schemat nedan även om OUT_A kan göras enklare men jag gillar att enkelt kunna debugga DC-värdena efter A1:a när jag bygger systemet. Jag kommer förmodligen också implementera IN_B och koppla den till A1 ty jag har en OP över i kapseln, men även om riktiga fyr-pol mätningar är bäst så har jag kommit fram till att enkelheten med 2-pol mätningar överväger krånglet (t.ex har man redan värdena och fasen i generatorn, annars måste man räkna fram dom i samband med sampling). Dessutom kan man t.ex mäta frekvens och fas hos det förstärkeriet man har och dra bort det alternativt, och detta är den avgörande synpunkten, så kan man nyttja det förstärkeri man ändå kommer nyttja dvs även om fas/amplitud blir påverkad av framförvarande förstärkeri så blir mätningen relavant för själva upplevelsen.

[SeniorLemuren]

Kan detta vara av intresse?

Arduino provides an convenient way to read analog input this using the analogRead() function. Without going into much details the analogRead() function takes 100 microseconds leading to a theoretical sampling rate of 9600 Hz.

The first part of the OScope project is to implement the Arduino sketch to read the input values from an analog pin. In this article will describe how to achieve a reliable sampling of analog signals up to 615 KHz using some advanced techniques.

[Spisblinkaren]

Mycket intressant, tackar för detta!

Jag vill ha prescale 2, oavsett att hen säger nåt så kufiskt som

Note that prescale values below 16 are not recommended because the ADC clock is rated.

Och trots att hans program bara var på några få rader så fattar jag absolut ingenting

Så jag får kolla upp det på nåt annat sätt, kanske via Arduino's forum där jag redan är medlem.

Men nu har du lärt mig vart akilles-hälen finns i alla fall, det har med prescale att göra.

Plötsligt känns projektet möjligt igen

MVH/Roger
PS
Jag har som sagt lekt lite med UNO tidigare och den är förvånadsvärt enkel att komma igång med, jag byggde ett helt projekt inlusive sampling och lagring på SD med tidsstämpling (RTC) på bara några månader (även om jag fick viss hjälp från IT-kunniga personer och kollegor) och vad jag började med var ett medlevererat exempel på hur man blinkar med en LED.

Ett eventuellt problem kvar dock, flera portar kan inte sättas strikt parallellt ty de måste sättas sekvensiellt (vill jag minnas) så frågan är hur den genererade sinusen kommer att se ut i praktiken, en nödlösning vore annars seriell D/A men dels vill jag inte komplicera konstruktionen mer, dels tillkommer då ytterligare fördröjning om minst 8 LSB (fast på generator-sidan har jag vissa preliminära marginaler).

Nu slår det mig nåt roligt, tänk om man sätter alla I/O sekvensiellt UTAN att värdet laddas ut innan det är klart, för att när precis alla I/O är satta helt enkelt latcha ut värdet med hjälp av en 8-bitars Latch/FF?

I praktiken blir det tidsmässigt ingen skillnad jämfört med seriell D/A men förfarandet är enklare (och roligare).

[Spisblinkaren]

Jag har börjat fundera kring en annan approach:

1) XR2206 som sinus-generator
2) Dedikerad Sample&Hold-krets för samplingen
3) Batteriuppbackat RAM i ZIF för lagringen (och flyttningen)

XR2206 sägs preliminärt kunna hantera ett frekvensspann på 1:2000 dvs 15Hz till 30kHz är möjligt.

Jag har länge drömt om att lagra data på batteriuppbackat RAM i andra sammanhang, tänker att man bara behöver skapa nån slags avläsningskrets och nån slags protokoll-adaptionskrets för att kunna läsa in det till en dator.

USB är ju populärt nu för tiden men ett enklare protokoll är serieporten på äldre datorer, bara en RS232-krets och några kondingar så kan man kommunicera med datorn.

Skrivning och läsning till RAM är mycket enkelt jämfört med flash t.ex.

MVH/Roger

[Spisblinkaren]

Jag har kommit på att det digitala värdet som ska konverteras måste komma ut från systemet helt parallellt för annars får jag odefinierbara skutt i det analoga värdet.

Så jag har infört en F/F som klockar ut värdet först när alla I/O-portar är satta, detta innebär dock en extra fördröjning om 9 klockcykler, en fördröjning som också varje symbol/värde måste ha.

Nu är frågan hur liten jag kan göra fördröjningen, för samplingen har jag lärt mig att halva systemklockan (16MHz) är maxhastighet, så E-klockan (effektiv klocka eller Enable-klocka) verkar kunna gå med 8MHz som maximal frekvens.

Tidigare påtalade jag att jag vill att högsta frekvens (60kHz) ska vara upplöst i 10 steg, här fick jag då ut 600kHz som symbolhastighet.

Man ser redan här att detta blir knapert men speciellt tydligt blir det om man multiplicerar 600kHz med "latch-fördröjningen"
dvs 9 klockcykler som då ger ett krav på E-klockan om 5,4MHz.

Nu är vi väldigt nära max E-klocka, så nära att det inte finns några egentliga klockcykler för processorn att göra nåt annat, typ att ta hand om samplingen "samtidigt", exekvera interrupt-rutiner osv.

Jag vill nog påstå att detta inte fungerar, hade jag haft en frekvensmarginal på en faktor 10 så hade det nog gått men det har jag inte.

Och två UNO vill jag inte behöva använda.

Jag får tänka om och göra en diskret lösning.

Vilket jag ändå gillar bäst här i världen

MVH/Roger

[rvl]

Så du har fler än åtta "bitar" ut? (Jag ser prick 8 i schemat, men numreringen går från 0 till 9???) Med åtta pinnar borde det inte vara problem, eftersom de går att koppla till samma port.

[Spisblinkaren]

Så du har fler än åtta "bitar" ut? (Jag ser prick 8 i schemat, men numreringen går från 0 till 9???) Med åtta pinnar borde det inte vara problem, eftersom de går att koppla till samma port.

Hej rvl!

Nej, jag har exakt 8 bitar ut, numreringen stämmer dock inte ty IO_2 & IO_3 sitter till vänster för de har inbyggt "interrupt-on-change" som jag nog vill använda.

Menar du alltså att alla 8 bitarna kan kopplas till samma port?

När jag satte portar har jag för mig att jag var tvungen att sätta en port åt gången, nämligen.

Men om alla 8 bitarna kan kopplas till samma port, ja då får jag ju dom marginaler jag behöver och detta system blir plötsligt realiserbart igen

Tack!

MVH/Roger

[Spisblinkaren]

Jag älskar logikkretsar!

Eftersom UNO går på knäna för att kunna möta mina krav har jag börjat tänka i andra banor.

Vem har sagt att en R2R-stege måste vara R2R?

Varför inte vikta pinnarna på ett sådant sätt att en helt vanlig binärräknare kan generera sinus direkt?

Om man kunde det blir sinus-genereringen nästan löjligt enkel, det är bara att låta en räknare räkna olika fort helt enkelt.

Om sedan högsta frekvens är 500kHz (säger vi) så delas den lätt ner med en faktor två från en DIL 1MHz kristall.

En finess sen är att man kombinerar binärräknare och dekadräknare för att generera dom frekvenser man vill ha, man kommer dock behöva nyttja nåt slags PROM för att få med alla neddelningskombinationer.

Det blir inte helt enkelt men jag gillar sånt här (dvs att slippa programmera i högnivåspråk).

Men det huvudsakliga argumentet är att de parallella bitarna inte behöver vara lika viktade vilket i princip gör att en fyrkantsoscillator + räknare + "R2R" kan generera sinus direkt.

Vad tror Ni om det?

MVH/Roger

[pstrand]

Hej!

Borde väll gå att realisera i mjukvara.

Lite "Pseudokod". Inget som testkörts, men en ide kanske

Kod: Markera allt

/* Values to write to IO-PORT, max 256 value for the whole sinus */
uint8_t dac_table[] = { xx,xx,xx,xx ..... };

/* Delay between samples */
static void delay_to_next_value(uint32_t delay)
{
	volatile uint32_t i;
	
	for (i=0; i<delay; i++) {};
}

/* Make Sinus sweep */
void sinus_sweep (uint32 start_delay, uint32_t end_delay)
{
	uint32_t i;
	
	while (start_delay > end_delay)
	{
		for (i=0; i<sizeof (dac_table); i++)
		{
			HW_IO_PORT = dac_table[i];		/* Write value to port */
			delay_to_next_value (start_delay);
		}
		start_delay--;
	}
}

int main ()
{
	/* Long delay, low freq, short delay high freq.
	sinus_sweep (1000000, 1);
	
	return 0;
}

[Spisblinkaren]

Hej!

Tack för ditt programförslag, mycket intressant.

Dock förstår jag inte så mycket ty jag har bara knapphändiga erfarenheter och du skriver lite för "duktigt" med t.ex komplicerade variabeltyper modell "uint32_t", vad sjutton är det för nåt?

Vänta lite, uint16 är vanlig unsigned int, eller hur?

Och 65000 räcker nog inte, därav uint32, eller hur?

Men vad betyder snobbtillägget "_t" i sammanhanget?

Sen tycker jag att deklarationen av den självklara tabellen "uint8_t dac_table[] = { xx,xx,xx,xx ..... };" är diffus för betyder alla par av x två nibblar, eller? Och varför måste man ange dom på det sättet det står ju redan uint8_t, liksom, väldigt skum syntax.

Slutligen, betyder "HW_IO_PORT = dac_table;" att flera portar kan sättas samtidigt och hur specificerar man då exakt vilka portar man vill använda?

Nej, jag blev inte mycket klokare på det här men tack för att du försökte!

Fast samtidigt har jag ju alldeles ovan förklarat att UNO går på knäna dvs jag behöver nog göra på annat vis.

MVH/Roger
PS
Men om man kan skriva parallellt till ett gäng portar och skruva ner prescalern så går det att få till en UNO-lösning, jag får se hur jag gör men jag känner att det dyker upp så många frågetecken i samband med programmering att det blir svårt att ro detta i land vilket gör en diskret lösning som jag "förstår" mycket mer attraktivt. Jag kan nämligen logikkretsar men jag kan ingasomhelst högnivåspråk (förutom Xilinx ECS som dock är ett grid-cad program ).

[pstrand]

Ok,

"Men vad betyder snobbtillägget "_t" i sammanhanget?"

Jag tycker att du ska vara lite mer försiktig med dina kommentarer när man försöker hjälpa till och inte slänga ut en massa "oförskämdheter"

Det är vedertagen praxis idag åtminstone på dom företag som jag sitter som konsult på att använda, och inget "snobbigt alls".

se exempelvis

http://en.cppreference.com/w/c/types/integer

uint32_t = unsigned int (unsigned long).
uint16_t = unsigned short.
uint8_t = unsigned char.

och det andra är ett deklaration av den arrayen som innehåller dom värderna som sinusvågen är uppbyggd av.

ex:
uint8_t dac_table[] = {1,2,3,4,5,6,7,8};

Tabell som innehåller 8 värden

dac_table[0] = 1
dac_table[1] = 2
....
dac_table[5] = 6

Kan tyvärr inte bli enklare.

Det är ju vanlig standard "C"

Ta och läs denna så kommer du att förstå saker och ting mycket bättre.

https://www.ime.usp.br/~pf/Kernighan-Ri ... -Ebook.pdf

[SeniorLemuren]

Om du har problem med att få Uno att räcka till, varför inte klämma till med en Arduino Due

It has 54 digital input/output pins (of which 12 can be used as PWM outputs), 12 analog inputs, 4 UARTs (hardware serial ports), a 84 MHz clock, an USB OTG capable connection, 2 DAC (digital to analog).

Programmeras med samma plattform som UNO.

[Spisblinkaren]

Tack för hjälpen även om jag inte förstog så mycket.

MVH/Roger