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

[Petr Labaj]

Ukládání jen v případě vyšší odchylky mi přijde zrádné, protože se i 
malá odchylka může kumulovat.
Proto jsem navrhoval ukládat u signálu beze změn (bez velkých změn) 
každou sekundu jeho průměrnou hodnotu v té sekundě.
Tak bude k dispozici celý průběh té nezajímavé ustálené fáze, jen s 
hrubší granulitou. Ne 2000 hodnot za sekundu, ale jen jedna, průměrná.
Navíc implementace takového algoritmu je triviální. Dá se naprogramovat 
během odpolední kávy nebo posezení na záchodě.
A rozlišení 1 sekunda je snad dostatečné, a je takové "lidské".
Nebo to fakt poskakuje tak rychle, že sekunda je i v ustáleném stavu moc?

Ty tramvaje mě překvapily. Myslel bych si, že brždění funguje 
automaticky. Tedy že technika sama napřed zapojí elektrodynamické brzdění.
A teprve v malé rychlosti nebo v případě těžkého zašlápnutí brzdy, kdy 
by to nestačilo, tak přidá třecí brzdu.
Proč tím zatěžovat lidskou obsluhu?

PL

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

Dne 10.12.2024 v 15:57 Vláďa Anděl napsal(a):
> 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.