Nem tudom, hogy ildomos-e, vagy érdemes-e egy hobbieletronikai fórumon olyan programok használatát javasolni, amelyek ára 350 000 - 1 400 000 Ft között mozog? Bővebben: link

Szia! A Lazarus is jó választás lehet, gyorsan lehet sikereket elérni, nem is kell nagyon bele mélyedni egy egy egyszerűbb alkalmazáshoz. Ingyenes program, free Pascalon alapul, olyasmi mint a Delphi.

Nem akciósak az biztos, de mindegyikből van próbaverzió. Ha lejár újra lehet rakni és megint működik 1 hónapig, bár ehhez a registry-ből ki kell törölni a dolgait.

Szia
Én a c#-ot javaslom. Nem vagyok programozó, de viszonylag kevés utánajárással és olvasgatással sikerült RS232->RS485->PIC kommunikációt összehozni. Ráadásul egy kis GUI-t is tudtam mellé rittyenteni szinte zéró tudással. Ha érdekel szívesen megosztom a tapasztalataimat privátban. A melléletben van egy kép, jelenleg itt tartok. Ha valami hasonló kell akkor keress meg.
Üdv.

Legegyszerűbben Visual C# segítségével tudsz írni soros porton kommunikáló alkalmazást. Az összes többi már bonyolultabb, több időt, utánajárást követel meg. C#- ban van soros port komponens, amit az ember csak drag&drop- pal feldob a GUI-ra, beállítod a kommunikáció paramétereit, beregisztrálsz egy eseménykezelő függvényt és már megy is. A net rogyásig van ilyen példákkal. Kutakodj egy kicsit!

Köszönöm szépen a hozzászólásaitokat. Ahogy leszűrtem válaszaitokból a C# lesz az én problémámra a megoldás. Egyelőre sajnos sok időm vagy épp erőm nincs bele merülni de ahogy lesz, nekifogok. Esetleg ha valakinek bármi olvasmámya (pdf) van ezzel kapcsolatban akkor megkérem ossza meg.

Kellemes hétvégét.

Szia
Ide nem tudtam feltölteni mert túl nagy a file. Küldtem privátban mailt.
Üdv.

Sziasztok .Gondolkodom egy ilyen programozó beszerzésén,használta már valaki?mi a tapasztalat.üdv szepi003

Sziasztok. Valaki tudna nekem segíteni abban, hogy a .sid fájlformátumban (C64, 6581 Sid) hogyan tárolódnak az adatok? Melyik byte a cím, melyik az adat? Kevés elérhető anyag van róla neten, amit találtam róla az nem túl sok. Angolul van egy leírás, de abba nincs benne csak annyi, hogy big endian formában vannak az adatok, de hogy melyik lenne a cím és melyik az adat... Vagy egyáltalán nem is úgy tárolja?

SID file format

SID 6581 datasheet

Szia!

Az általad linkelt doksik alapján már elméletileg implementálható, benne van minden. Azazhogy mégsem. Az adatok jelentésének magyarázata nem maradéktalan. Gyanúm szerint a "data" részbe egy C64 program kerül, amely úgymond előállítja a zenét.

A datasheetben megtalálod, az SID melyik regisztere mire való. Az ott említett "address" pinek ezek valamelyikének kiválasztására szolgálnak. Ha a CPU (MPU) kiválasztotta a regisztercímet, a "data" pineken keresztül írhatja/olvashatja az adott regisztert.

A fájlban található adatokat a 6510 nyomja le a SID torkán, valamint ha jól értelmeztem, akkor az ehhez szükséges 6581 drivert ugyancsak a fájl tartalmazza.

Az, hogy a hexakupacból melyik bájt a cím, és melyik az adat, az nem a 6581 függvénye, hanem a processzoré, amely vezérli azt. A 6510 utasításkészletének kellene utánanézned. Semmiképpen nem ajánlom, hogy valami hexeditorral vagy hasonlóval kísérletezz. Keress inkább egy C64-hez / 6510 -hez való compilert (BASIC, Pascal, C, Assembly - ezek mind elérhetők)

UI.:
Utánajártam (Bővebben: Link) a kedvedért; igazam volt:

Sziasztok!

Nem tudom hogy ebbe a topikba illik-e a kérdés..
Egy atmega32-re írok programot. Analóg beolvasás során létrehozok egy adatsort. Ezt szeretném kijelezni. Ez eddig működik is. Olyan mint triggerelés nélküli jel, beolvasás után kiteszi a kijelzőre.
Szeretném valahogy fix pontról indítani a jelet, mintha triggerelve lenne. Ehhez szükséges volna kijelölnöm egy kezdőpontot.
Az eszközben majd az lenne a jó, hogy a mért frekvencia emelkedésénél a kijelzett ábra (közel) ugyan az marad, tehát egy végpontot is kellene ismerni. Magyarul ahogy bárki egy pillanat alatt meghatároz egy ábrán egy periódust ránézésre, így volna jó meghatározni a mintavett jel periódusát.
Ha ez valahogy megoldható, akkor már az előző mérés frekvenciáját meg tudom határozni, amivel a következő mérés időalapját úgy tudom beállítani, hogy a mintavétel időköze a kijelzésnél 1-1,5periódus legyen. Vagy akár hosszabb adatsorból a megfelelő részt ránagyítva is megoldható.
Tudtok abban segíteni, hogyan lehetne "megfogni" a jelet?

Szia!

Lehet, hogy csak én vagyok így vele, de nem teljesen világos számomra a kérdésed lényege. Ebben a formában túlságosan absztraktnak érzem ahhoz, hogy előcsalhassuk a - biztosan létező - megoldást.
Ha egy picit összedettebben meg tudnád fogalmazni, talán volna tippem, bár lehet, hogy valaki más így is meg tudja neked válaszolni (szoftverfejlesztő vagyok, az elektro tudásom minimális).

Szia!
Amit szeretnél annak az elméleti alapja a Fourier transzformációban leledzik. Azaz minden periodikus (elvileg nem periodikus függvényekre is igaz, de ezt most hagyjuk) függvény felírható szinuszfügevények összegeként. Ha egy periodikus jelre ezt megteszed, akkor megkeresed a legkisebb frekvenciájú komponenst, és máris megvan a keresett frekvencia. Ezt a teljes spektrumra megcsinálni nagyon nagy erőfeszítés (rengeteg számítás), ezért léteznek egyszerűbb megközelítések (Fast Fourier Transform, FFT);
Pl.: A jelsorozatnak kiszámolod az átlagértékét, és ezzel összekomparálod a mért jelet. Ha egy periódusban csak kétszer halad át rajta, akkor könnyen meghatározható a "nullátmenet"-ekből a periódus idő.
Szintén egyszerűsíti a helyzetet ha tudod, hogy milyen tartományban van a keresett frekvencia, mert akkor máris kevesebb a számítási igény.

Ja vagy úgy! A minimum és maximum érték ezesetben célravezetőbb lehet, mint az átlagérték, mert nagyobb a valószínűsége, hogy ezek a jelszintek periódusonként csak egyszer fordulnak elő.

Nem tudom, hogyan gondolod, a jelek mintavételezése nem mindig pont ugyanakkora értéket eredményez, így a maximumok és a minimumok sem egyformák. De ha egyszerűbb neked ez a megközelítés, akkor hajrá!

Köszönöm mindkettőtöknek

Azt szeretném, ha független a jel alakjától és frekvenciájától az lcd-n egy-másfél periódus jelenne meg, mely nem szalad se jobbra, se balra. Ez lehet nem egyértelmű, de egy triggerelt képet szeretnék, mely - szkópos hasonlattal élve - magát az idő alapú eltérítést úgy állítja be saját magának, hogy a mérést végző ne lásson frekvencia változást, csak a jelalakot. Számára ez a hasznos információ.

A csatolt képen látjátok, hogy az ilyen típusú méréseknél milyen jelalakra lehet (leginkább) számítani. Ha még be is lengedezik, mint bal alsó ábrán, akkor lehet nem éri el a minimum szintet.

Minimumokat keresni jó ötlet, hiszen eddigi tapasztalat alapján ebből periódusonként legtöbbször csak 1 van. Felvázolok egy lehetőséget, talán lehet belőle megoldást kovácsolni.
Indítok egy mérést, az eredményt tárolom. Megkeresek egy minimum helyet. Ettől kicsit magasabb értéket keresek (innen időben előre haladva) (+5% az overall min max viszonylatban) Ha ezt megtalálom, és feltételezem, hogy egy kicsit még lejjebb megy, majd ismét emelkedik (hiszen minimum hely), akkor ahol 0 az érintő meredeksége, ott kezdődik a következő periódus, ez a minimum hely. Ebből talán meg lehetne határozni, hogy a mérés eredménye a letárolt adatokból mettől meddig kerüljön ki a kijelzőre.

Tulajdonképpen csak egy equals_with_fault_tolerance függvényt kell leimplementálni ehhez. Hacsak nincsenek tüskék a jelben, amik tovább bonyolítják a helyzetet, megkeresed a jel globális minimumát, majd a hibatűrő összehasonlítással kikeresed a lokális minimumokat. Ezek helyzetéből ki tudod számítani az átlagos periódusidőt és már csak egy tetszőleges időbeli pontot kell kinevezned periódus-kezdetnek. Ez a pont célszerűen, a maximum érték elérését megelőző, ahhoz legközelebbi olyan pillanat, amikor a jelszint a legközelebb áll az átlagértékhez.

Szia!

Rengeted plusz programozástól és hibás megjelenítéstől megkímélnéd magad, ha a vennél egy motor fordulatszám jelet valahonnan, és arra triggerelnél. Persze ha erre nincs lehetőség, az más kérdés... ez egy szép feladat mikrokontolleren.
Ha csak járó motornál kell a nyomás görbe (tehát amikor van égés), akkor érdemes nyomás-csúcsra triggerelni mert abból csak egy van.

Valahogy így képzeltem el. Közben kiderült, hogy a fordulatszám 800 és 1800 között mérendő, tehát sokkal kisebb tartományon kell mérni. Jónak tűnik, mert így talán könnyebben megtalálom a "második" minimum helyet, mert tudom hogy időben melyik tartományban kell keresni az első minimum után. Most már csak ki kéne próbálni.
Elképzeltem valami hasonlót, próbáltam is megfogalmazni de sajnos nem tudom. Kézzel lábbal még el tudnám mutogatni valahogy. (elképzeltem 2 egymásba ágyazott for ciklust. Az első lépteti az ablakolásra kijelölt fv hosszát, a belső pedig ennek a fv-nek a helyét. A belsőben e két dimenziós ablakolásnál felvett a fv-ek különbségét tároltam. Ahol ez minimum volt ott van egyezésem (hiszen 2 egyforma fv különbsége 0))
Tudsz erről az "equals_with_fault_tolerance" fv-ről leírást linkelni?

Szia!

Sajnos nem vehetek fordulatszám jelet. Ennek ismeretében tényleg rém egyszerű lenne a dolog. Ha semmiképp sem fog menni csupán a nyomásméréssel, akkor vagy nem sikerül a projekt, vagy ettől félve lehet, hogy mégis engedik gyújtást felhasználni.
Az bosszant hogy egy 8 éves gyerek meg tudná mutatni a sorminta hosszát(periódust) a kifestőben, C-ben leprogramozni pedig......khm, nehéz.

Nyomás csúcs nem csak egy lehet, mert a nyomásmérés a fojtószelep és a szívó szelep között lévő, gyárilag lezárt kiállásnál történik meg. Ha pl nem zár jól a szívó, akkor lesz egy nyomáshullám "visszafelé". Ez azt fogja eredményezni, hogy a csúcsra triggerelés miatt nem a kívánt főtengely elfordulási szögnél fog indulni az ábra. Azért jó tehát a minimum érték keresése, mert az - eddigi tapasztalatok alapján - periódusonként csak egy helyen fordul elő.

Sikerült minimumra triggerelnem.
Van a feldolgozott adat tömböm. Ebből készül el a graph-nevű tömb. Ez utóbbi úgy készül, hogy keresek minimum értéket (és helyet) a datában. Ennek a hossza picit több mint a mérni kívánt leghosszabb periódus, így biztos bele fog esni egy min hely. A graph-első eleme tehát ettől indul, és addig jelez ki, míg a kijelző el nem fogy.
Bonyolultabb lesz a periódus a végét az lcd széléhez "nyújtani", de dolgozom rajta

Ha a vizsgált jelalakban egy periódusban biztosan csak egy negatív csúcs van, akkor tényleg elegendő a minimumra triggerelned.
A szkópokban kézzel állítható a trigger, és ugye nem csak azért, hogy a jelet jobbra-balra tologathassuk.
Ha a jelben tüskék, hupszlik vannak (erre van egy szép függvénytani kifejezés, ami nem jut eszembe - vagyis hogy a függvény egy adott Y értéket több X helyen is felvehet), akkor a triggerelés sem mindig egyértelmű, ilyenkor lehet a szkópokon állítani a triggerszinten, hogy találjunk egy fix megjelenítést, ne ugráljon a jel ide-oda. Még így sem mindig tökéletes az eredmény (gondoljunk egy szép zajos jelre).
Amit ezzel mondani akarok az az, hogy érdemes lehet egy ilyen manuális triggerszint-állítási funkciót beépítened.
Aztán lehetne azzal finomítani pl., hogy nagyjából tudod azt, hogy hol várod a következő periódus kezdetét. Beállítható lenne egy tűrés, ami attól függ, hogy mennyit változhat a periódusidő egy periódus alatt. Ugye a vizsgált fordulatszám sem ugorhat fel nulláról maximumra egy pillanat alatt.
Ha behatárolod, hogy hol várható a következő periódus kezdete, akkor az ezen időtartományon kívül jelentkező véletlenszerű bazi nagy impulzusok sem fogják a triggerelést megzavarni.

Lehetne valami 2 gombos trigger, mint a kapcsolós potméter elvén, csak digitálisan, hogy min érték alatt ne elveszítse a triggert/jelet, hanem magának nézzen egy minimumot és átvált pl 30Pa-ről minPa-ra.
A zajra meg a fft lenne jó, viszont 20MHz-en 8 biten, kissé lassú lenne. Most úgy néz ki, a mérésem, hogy egymás után van 8 A/D beolvasásom, majd kis delay, és utána ismét. Ezt eddig 127x tette meg, és akkor ért el a kijelző végére.
Volt már éles teszt, motor mellett, gyújtás sem zavarta be, nem zajosodott el a jel. Ezen a számítási teljesítményen nem hiszem, hogy sokkal több beleférne az időbe. Folyamatosan megy most is a kontroller, csak az előbb leírt helyen delay-el valami 127*610uSec-et. 2,5-3Hz lehet a sebessége a komplett rendszernek.
A következő periódus keresése: minimumot keresek abban a tartományban, ahol tudom hogy fordulatszámok miatt lennie kell. Szóval előre kiszámoltam hol keressen.
Ha összeállnak majd az igények, és a kód részletek, akkor majd úgyis át kell szervezni, hogy minél gyorsabb legyen, addig is örülök annak hogy lefut, és úgy viselkedik ahogy kell neki.

Ha nem zajos a jeled, akkor ez szerencse, de arra is lenne egy tippem: aluláteresztő szűrő.
Most nem a bonyolult FIR, meg IIR szűrőre gondoltam, azokat ilyen hardverrel nyilván nem lehet valós időben megoldani.
Csúszó átlagolás. Én hívom így, nem tudom, hogy mi a módszer hivatalos neve. Egyszerű átlagolás, aminek a hatása hasonló ahhoz, mintha az analóg jeledet egy aluláteresztő szűrőn engedted volna át, a hátránya is a némi késleltetés.
Végy pl. egy 10 elemű tömböt. Töltsd fel a jelalak első 10 elemével.Számold ki a számtani átlagukat. Ennek eredménye lesz a kimeneti jelalak első eleme. Most vedd ki a tömbből a bemeneti jelalak első elemét, rakd be helyette a 11. elemet. Ismét számolj egy átlagot, ami a kimeneti jelalak 2. eleme lesz. Így tovább. A tömb méretét növelve csökken az "aluláteresztő szűrő" frekvenciája.
Ha a kimeneti jelalakra triggerelsz, akkor a magasabb frekvenciájú zavarok kevésbé befolyásolják a triggerelést, nem lesz a képernyődön egy jobbra-balra zizegő jelalakod.

Nem kéne annak olyan bonyolultnak lennie, ha tisztességesen alkalmazod az MVC/MVP patternt (már amennyire a procedurális környezet engedi ugye). Szeparáld el a megjelenítéssel foglalkozó kódot a méregetés/számolgatás logikájától. Nagyon sokat tud segíteni, ha koherens modulokba van szervezve a kód.

Használtam valami hasonlót már máskor, gyorsulásmérő adatainak feldolgozásához. Az lett az eredménye, hogy a feldolgozás utáni adatsorból kirajzolt fv meredekségét korlátozza, szóval rising edge bemenet esetén valamekkora meredekséggel emelkedett annak maximális értékéig.
Jobb ez az ötleted, mert abban nincsen "elveszített" mérés. Míg én 4-8 mérésből kapok egy eredményt, nálad minden mérésre jut. Ki kellene rajzolni mindkét metódus eredményét, és akkor látszódna max hány mérést átlagolhatok /jelentős/ adatvesztés nélkül.

Nem ismerem ezeket a pattern-eket sajnos, de leginkább az általános C fv-ekből szoktam legózni.
Csatoltam egy kódrészletet, kb ilyen "stílusban" szoktam írogatni. Nincs benne semmi bonyolult, de működik Van még benne sok fölösleges dolog, ez volt az első sikeres triggerelés.

Pár dolgot megjegyeznék a mondatodhoz. Nem térnék ki sokmindenre, egyrészt mert nem vagyok egy DSP zseni, másrészt meg nagyon bő a téma:
- a mozgóátlag valójában egy FIR szűrő, ahol minden minta 1/N-es együtthatóval van súlyozva
- pl az elsőrendű aluláteresztő IIR szűrő implementálva nagyon primitív és a mozgóátlaghoz képest jelentős számítási kapacitást lehet spórolni vele:
y = (1-a)*mért_jel+a*y_régi, ahol 'a' 0 és 1 közötti szám. 'a'-val adod meg a "szűrés mértékét" Ha ügyesen implementálja az ember, akkor a szorzásokat vissza lehet vezetni bittologatásra, így igen gyors lesz a számítása, simán alkalmazható lassú, 8 bites kontrollereken is

Csatoltam egy példát az IIR-re. Itt megfigyelheted, hogy az 'a' értéke milyen hatással lesz a szűrt jelre.

Tényleg hatékony. Az a varázsa, hogy az előző mérésekre alapoz, de ennek a mértékét beállíthatja a felhasználó. Azt nem értem, hogy a kiinduló/mért adat fv miért válzozik amikor A értékét megváltoztatom.

Az csak a véletlen szám-generátor függvény miatt van, nincs köze a szűréshez.