Vysokorychlostne meranie Analogoveho vstupu

[djwiktor]

Caute borci,

mozno uz niekto ma nejake skusenosti, tak skusim tu.

Potrebujem merat 2-3 analogove vstupy, kde sa napetia pohbuju 0-5V ( po uprave 3.3 ak treba) . Acquisition time pod 100us na kanal rpi 12bit rozliseni, alebo <60us pri 10bit.
Potrebujem ich samplovat co najrychlejsie, a zaroven logovat v PC do suboru, vratane casovej znacky ( idealne v ms, ale aj sekundove rozlisenie postaci).
Zobrazenie nie je potrebne v grafoch.


Nemate dakto nejaky tip, kde nieco podobne kupit v cene do 200€ ?


Momentalne to robim s Arduinom, na 230400 baud mam dva kanaly nasamplovane a ulozene s 10bit rozlisenim. Oba kanaly dokhromady sa mi nacitaju za priblizne 460us. Na menej sa neviem dostat, hoci samotny seriak na 230400 pri 13 bytoch vychadza iba na nejakych 60us a citanie analogu vychadza na 32us na kanal, t.j. 64us na dva kanaly plus spracovanie 40us. Takze v sumare by to malo byt plus minus 180us dohromady. Asi to uz bude skor problem v smaotnej serial kniznici, ale tak daleko som sa este nedostal.

[jenda23]

Podle mě používat ubohý knihovny Arduina je utopie, pokud použiješ třeba 500 kSPS ADC na SPI kde není problém ho hnát na 10MHz SCK. taky si myslim že data z ADCka si schopen dostat přes HW SPI do takových 5-8us na kanál. Ovšem data bych nelifroval online, ale použil bych nějakou vyrovnávací paměť a popřípadě kompresi dat aby si nemusel chrlit tolik čísel... a i samotné převodníky na UART který předpokládám že používáš podporují i větší baudovou rychlost. Ovšem jsem to nikdy nezkoušel takže netušim jaká je ztrátovost dat při takovéto rychlosti.

[peterple]

Zabudni na arduino pohodičku ktorú urobil niekto iný tak aby to stačilo na 99% vecí. Tá tvoja medzi ne nepatrí. Napríklad tam majú zamontovaný Timer pre milis funkciu. a ten niečo koštuje. Treba si to urobiť celé vlastné.
Pokliaľ by si zliezol až na asm tak je reálne posielať sériákom až na rýchlosti 921.6kbps. Stačí tam mať kryštál 14.7456MHz a fičí to.

-- Spojený príspevok 14 Apr 2017, 09:28 --

A ešte nechápem načo prenášaš 13 byte keď na to stačia 4?
Edit: Chyba, vlastne stačia iba 3.

[Kado]

v datashite pre megu328p sa pise, ze ak chces z ADC dostat skutocnych 10bit, tak clk pre adc hw modul by mal byt 50-200khz, ked ratam s 200khz a tym, ze cas "normalnej" konverzie jedneho kanala trva 13cyklov, tak prevod pre 1.kanal bude trvat 65us, tym mas dva kanale 65x2=130us + este to treba spracovat a poslat cez uart...

este som tam nezaratal cas Sample&Hold, co je +1,5cyklu pre "normal conversion"
takze 72,5us x 2 = 145usec pre dva kanale (teoreticka hodnota, nie je zaratany cas pre spracovanie cpu jednotkou)

takze zabudni na interny adc v mega328

[peterple]

Overhead na spracovanie a poslanie nie je žiadny. za 130μs čo trvá prevod to spracujem a pošlem a ešte sa budem 128μs flákať.

[jenda23]

perteple jenže on to asi chrlí do terminálu a těch zbejvajících 10byte mu zabírá nejspíš info o datu, čase získání vzorku a jeho pořadovém čísle, popřípadě nějakej oddělovací znak, enter, CF atd, který lifruje společně s hodnotou AD převodu ven.... teda předpokládam, proto posílá tolik.

[peterple]

Nuž ak chce aby mu to lietalo ako stíhačka, tak nemôže okrem dvoch pasažierov voziť ešte aj 10 letušiek. ADC si treba dať do Free Running mode a potom sú poradové čísla a aj nejaké časové značky zbytočné. A na oddelovač tam sú 4 nevyužité bity (3*8 - 2*10 = 4).

[djwiktor]

No sa tu teda rozbehla diskusia, ani som to necakal

K veci :

Momentalne som sa dostal na 180us, co je zhruba maximum co sa z atmegy a serioveho portu da ziskat v pripade posielania dat von ako string retazca ( hodnota,hodnota CR/LF)

S kolegom v praci sme to este preberali a vychodiskom na zrychlenie je urobit z ADC binarku, vratane bufferu na arduine, a posielat von binarne data. Momentalne ale porobim dake merania na tych 180us, je mozne ze uz viac nebudem potrebovat. Experiment preveri.

[peterple]

Momentalne som sa dostal na 180us, co je zhruba maximum co sa z atmegy a serioveho portu da ziskat v pripade posielania dat von ako string retazca ( hodnota,hodnota CR/LF)

Nesúhlasím. Maximum to možno je pre C++ s arduino knižnicami. Keď to vezme do ruky assemblerista, tak to urobí minimálne desaťkrát rýchlejšie.

[MiloPS3]

pokud ti nebude vadit posun o delku trvani prevodu (popripade odeslani dat) tak bych skusil

spustit prevod 1 kanalu
pockat na prevod 1 kanalu / precist
prepnout na 2 kanal
spustit prevod 2 kanalu
odeslat hodnotu 1 kanalu
pockat na prevod 2 kanalu / precist
prepnout na 1 kanal
spustit prevod 1 kanalu
odeslat hodnotu 2 kanalu
pockat na prevod 1 kanalu / precist
.
.

to by se melo trochu zkratit

[Kado]

akym clk ides do ADC prevodnika? zaujima ma to preto, lebo hore pisem veci z datashitu, ze ak chces dostat rozlisenie 10 bit, tak clk pre ADC je max 200kHz, v tom pripade mi vychadza, ze dlzka jedneho prevodu (Sample&Hold + ConversionTime) trva 1,5+13cyklov = 72,5us, co nesplna tvoje zadanie pre 10bit rozlisenie < 60us

[djwiktor]

Tu je kod, ktory tam bezi momentalne. Nic zlozite. PS je nastaveny na 32, t.j. ADC clk je 500kHz. Robil som s tym asi 50 merani na 2 cipoch a v rozsahu teplot 0 az +40 som nezistil pokles rozlisenia o viac ako 0.5LSB co plne dostacuje tomu co potrebujem.
Samozrejme ak zistim casom, ze je to uplne slepa ulica ( co zatial nie je ) tak prejdem na cortex cip. Ale ten este nemam tak prezuty
ako 328p.

Kód: Vybrať všetko

const unsigned char PS_16 = (1 << ADPS2);
const unsigned char PS_32 = (1 << ADPS2) | (1 << ADPS0);
const unsigned char PS_64 = (1 << ADPS2) | (1 << ADPS1);
const unsigned char PS_128 = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0);


void setup() {
Serial.begin(230400);
ADCSRA &= ~PS_128;  // remove bits set by Arduino library
ADCSRA |= PS_32;    // set  prescaler to 32 
DIDR0 = 0x03;  // disable Data Input Register for ADC0 & ADC1
}

void loop() {

  String data = String(analogRead(0))+","+ String(analogRead(1));
  Serial.println(data);
   
}

Este doplnim... robil som teraz nejake merania s inym terminalom ( Teraterm) .. a pri zratani riadkov na 1 sekundu, je to 17380 zaznamov priemerne na jednu sekundu, co je 57us na CH1+CH2 - teda okolo 30us na kanal vratane posielania na port. Teda za predpokladu, ze teraterm neoblbuje, co ale nepredpokladam, lebo som to skusal asi 10x aj s tym, ze som sledoval cas sekundovy, teda co je v logu, vyzera ze aj sedi.

Takze dam tomu sancu najblizsie v terene a uvidim ako sa to chova....
Ked uz sme pri tom - nema niekto napad ako tieto cisla spracovat do grafov ? Kedze excel je obmedzeny na 32000 bodov - sice to viem so skriptom obist a mat posuvnik pod grafom, ale nie je to ono.

[peterple]

To vysielanie beží na pozadí, takže sa robí počas tých dvoch prevodov. Teda ta vôbec nebrzdí. Samozrejme ak to nepreženieš a nedávaš viac dát ako sa dá za ten čas poslať. To sa dá veľmi ľahko overiť napríklad osciloskopomi. Stačí nabrať trochu signálu TxD a ak je tam za CR LF pauza tak je to v poriadku. Ak je pravda že prenášaš 13 byte tak by to malo trvať práve tých 56,4μs čo si zhruba nameral v terminále.
Neviem ako presne pracuje analogRead ale ak je ADC clock 500kHz tak by prevod trval 26μs. Teda to vysielanie je o máličko pomalšie.
Ak by si potreboval trochu skrátiť ten prenos tak by si mohol prenášať nie desiatkové čísla ale hexa. Bude v nich menej číslic a aj konverzia je rýchlešia. A excel si s tým poradí.

Pravdepodobne ani nevadí ten timer čo počíta čas na arduine. Aj to beží na pozadí takže by to malo všetko postíhať. Akurát ti to máličko posúva dobu štartu prevodu. Takže nevieš moc presne aký čas ubehol medzi dvomi riadkami.

Zrýchliť a spresniť sa to dá ešte tak že nepoužiješ analogRead. Ale ako som písal nastavíš si free running mód na ADC a on potom pobeží sám. Stačí ak v loop budeš kontrolovať príznak ukončenia prevodu a prepínať mux.
Ak to vysielanie zmákneš pod 52μs tak by tie vzorky mali mať vždy rovnakú dobu medzi sebou.

Na graf použi Excel 2010 ten už nemá na počet bodov obmedzenie.
https://support.office.com/en-us/articl ... Excel_2010