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

Úterý Prosinec 10 01:21:23 CET 2024

Pokud neni pozadavek na bezztratovou kompresi,

tak lze pouzit toto:

Pokud je aktualni hodnota rozdila od minule o epsilon, tak se hodnota 
ulozi s casovou znackou a nastavi do minule.

Pokud ne, tak se hodnota zahodi.

Jeste je tam pro jistotu nastaveno ulozeni vzorku vzdy po cca 4 hodinach.

Tim se vyvzorkuje dynamicky dej, ale ustaleny sum je eliminovan.

Neni to dokonale, ale celkem ucine.

Takto to pak zobrazujeme i v grafech.

Slavek

Ing. Slavomir Skopalik
Executive Head
Elekt Labs s.r.o.
MASA - Collection and evaluation of data from machines and laboratories
http://eng.elektlabs.com/products-and-services/masa
-----------------------------------------------------------------
Address:
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
---------------------------------------------------------------
Mobile: +420 724 207 851
skype:skopaliks
e-mail:skopalik na elektlabs.com
http://www.elektlabs.com

On 10.12.24 01:04, Petr Labaj wrote:
> 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.
>>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list