Re: vykreslování grafů z velkého množství dat

[Petr Labaj]

Udělal bych to tak, že ten zapisující procesor by si udržoval 
10-sekundové klouzající okno.
Pokud by se po 1 sekundu data neměnila, do logu by se zapsala časová 
značka a průměrná hodnota v té sekundě.
Pokud by došlo k nějaké anomálii, tak by se do logu zapsala ta 
10-sekundová podrobná historie a zapisovalo by se vše až do doby, než by 
se zase data vrátila do stabilního stavu. A ještě dalších 10 sekund.
Proto by to chtělo třeba to ESP32, aby procesor měl trochu paměti. 
BluePill má jen 20 kByte, to je trochu málo. Pokud ARM, tak by to chtělo 
aspoň BlackPill, tj. se STM32F4xx.

Výsledná uložená data by pak zřejmě měla cca 1000x menší velikost bez 
ztráty informace. Takže místo gigabajtů jen megabajty, tedy snadno 
poslatelné i mailem a podobně.
A měla by rovnou vypíchnuté oblasti, kdy se dělo něco zajímavého.
V takovém režimu by se to dalo zřejmě provozovat opravdu skoro furt. Ani 
tu flashku by to moc neojelo.

PL

*******************

Dne 10.12.2024 v 0:20 Jan Waclawek napsal(a):
> [preposielam]
>
> Dobry vecer,
>
> p.Labaj vystihol ste to velmi dobre, ze problem ma dve roviny. Hardware a software. Pricom hardware ma tie problemy dva. Prvy je pravidelne vzorkovanie co 500us nove data, a druhy je zapis bloku dat do nejakeho pomaleho zariadenia s dlhou odozvou. Ono aj SD-karta ma nejake ms na zapis bloku. Takze je tu problem vzorkovanie 500us a zapis dat v milisekundach. To sa riesi pohodlne tou dual-port RAM, co som ju spominal rano v mojom emaily, ktory uz davno zapadol prachom.
>
> A teraz este ku tej softwarovej casti. Budete potrebovat nejaky editor, ktory Vam umozni rozsekat povedzme 1GByte file na mensie subory. To tiez nie je trivialny task a rozne textove editory to riesia inak. S niektorymi sa pri takto velkom file neda vobec pracovat.  Berte to prosim p.Andel s rezervou, je to moja skusenost spred cca. 15rokov. Mozno to Vase audacity to vie bez problemov urobit. To neviem zase ja. Ale rozhodne budete tie velke logy spracovavat v mensich suboroch, mozno po dnoch a po hodinach. Tu si myslim, ze p.Labaj ma dobry napad, ze predspracovanie by mohol urobit ten procesor alebo mikrokontroler, ktory sa bude starat o zapis dat do pomalych pamati a komunikovat s PC, tie data budete musiet totiz nejako dostat aj do PC.
>
> A.
> Ten úkol má 2 roviny.
> Jeden je rychlost sběru dat, které to musí bez zakoktání ukládat.
> A druhá je pak výsledný objem dat a práce s ním.
>
> Osciloskop určitě dokáže sejmout rychle nějaké vzorky, je to jeho práce.
> Ale zase většinou není dělaný ta to, aby to kontinuálně snímal několik dní.
> A má na to snímání a bufferování dat příslušný HW.
>
> On to podobně v jenom z předchozích mailů pojal pan Hudeček. Kde spočítal,
> že je to za sekundu nějaký objem dat, a že to tedy nic není.
>
> Ale to nejsou data za sekundu. To by byly po nějakém bufferování nějakým
> HW. Třeba to ESP32, od Číňana za 45 Kč holý modul nebo za 100 Kč i s deskou.
> Pak už to samozřejmě pro PC není řádný problém.
> Ale problém může nastat, pokud ta data chodí pravidelně každých 500us.
> A pokud se na chvíli PC zaobírá něčím jiným, tak mu nebufferovaný vzorek
> může utéct.
>
> Je to problém, který se řeší třeba při SW ovládání CNC. Tam těch dat, které
> PC pošle driveru krokáčů nebo serv, není moc. Kdyby se to spočítalo jako
> kB za sekundu, tak je to sranda.
> Ale jde tam o přesné načasování toho odesílání. A často to třeba ani moderní
> nabušené PC se spoustou GHz nezvládá, ale nějaký starý střep s pomalým
> Atomem klidně ano. Jen proto, že má líp vyřešené latence, resp. jitter
> té latence.
>
> Prostě podle mě PC s Windows není pro real-time aplikace vhodná platforma.
> A stejně tak podle mě u velkých dat stojí zato se zamyslet jak s nimi
> nakládat.
> A ne je jenom zednicky hrnout na velkou hromadu s tím, že "výkonný stroj
> to zvládne". A když něco nestíhá, tak přidáme GHz a GByte, místo abychom
> se zamysleli.
>
> Ze školy (asi ze základky) si to pamatuju jako rozdíl mezi intenzívním a
> extenzivním
> rozvojem zemědělství. U intenzivního se snažíme mít vysoké výnosy a malé
> ztráty.
> U extenzivního prostě osázíme větší plochu a kašleme na efektivitu.
>
> PL
>
> PS. Nicméně mezitím se vysvětlilo, že to pan Anděl bude mít bufferované
> nějakým
> svým oblíbeným Silabsem a ukládat dedikovaným HW.
> Takže už zbývá jen druhá rovina problému - práce s obrovskou spoustou
> dat, ze
> kterých zřejmě 99.95% bude k ničemu.
> Takže kdyby to ukládání řešil něčím inteligentním (třeba tím BluePill
> nebo ESP32),
> tak by mohl předzpracování řešit hned na něm a ukládat jen zajímavé sekce.
> A mít tak možnost s rozumným množstvím dat udělal záznam třeba celý rok,
> případně furt.
>