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

[Vláďa Anděl]

Když jsme dělali už skoro před 20 lety dataloger pro monitorování 
baterek na železničních vozidlech, tehdy ještě na CF kartu, taky měl 
kolega snahu šetřit data tím, že při změně menší než něco se nebude 
zapisovat. Dalo mu to spoustu práce a nakonec to nikdo nechtěl, chtěli 
vědět, co se tam skutečně děje a na objemu dat jim nezáleželo. 
Vzorkovalo se po 20 ms a jezdilo to na té tramvaji třeba 14 dní. Asi s 
nějakou vyšší inteligencí na eliminaci šumu by to šlo, jenže já snímám 
děj, kde se něco děje neustále.

Jen taková zajímavost z těch tramvají - jak jsou někde k dispozici data, 
i když za úplně jiným účelem, začnou se zjišťovat věci... Z průběhu 
proudu baterie se dalo vykoukat, že někteří řidiči brzdí správně, 
nejdřív motorem do odporů a až úplně na konci třecí brzdou. Někteří 
brzdili třecí brzdou už ze začátku. A začalo se vysvětlovat, proč jen na 
některých tramvajích musí měnit špalky každou chvíli a bylo tam prý 
okolo toho dost dusno :-)

Anděl

Dne 10.12.2024 v 1:21 Slavomir Skopalik napsal(a):
> 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
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list