Lehet, hogy pont az értelmezés hiányától érződik hiányosnak. Ha csak beleolvasok egy könyvbe, de nem olvasom el teljesen, nem fogom tudni, hogy miről szólt.
Nekifutok még egyszer. Matlabbal generáltam 3 szinusz jelet, amit összeadtam. Egy 250, 8000 illetve 14000 Hz-es jelről van szó, különböző amplitúdóval. Ez a képen a felső grafikon. Az alsó pedig a Matlab beépített FFT algoritmusával generált frekvenciatartomány/amplitúdó grafikon. Ez lenne az etalon kimenetem, ezt, vagy legalábbis közel ezt szeretném a PIC-en is visszakapni. A Matlab adathalmazát átalakítottam 1.15 formátumra és a programmemóriában eltároltam. Ezen lefuttatva a Microchip saját FFTComplexIP függvényét, nem kimondottan ezt kapom vissza. Mint írtam, kapok egy tüskét 233 Hz környékén. Ezt mondjuk, hogy a 250 Hz-es komponens, az eredeti jelnél. Ezen felül van egy 7100 Hz és 12890 Hz környékén. A mérés eltérése 6.8, 8, illetve 11.2 % mérési pontatlanság az eredeti jelekhez képest. A kérdésem ez lenne, hogy ez a pontatlanság honnan jöhet ?

Matlabbal 513 adatpontot generáltam, így az utolsót levágtam a programmemóriába másolás során. Ez maximálisan 0.2% mérési hibát tudna bevinni. Mivel komplex számokról lenne szó, így figyeltem, hogy az adatok jól töltődjenek be. A valós komponens a kombinált szinusz értéke, míg az imaginárius komponens a példa által is megadott módon nulla mindegyik tagnak.

Maga az amplitúdó nagysága egész pontos, a 250 Hz-es pontnál 0.37 helyett, 0.35-öt mér, így ezzel nincs különösebben bajom.

Tehát van e bárkinek is ötlete, hogy miért kerül ez a csúszás az időtartomány kimenetébe?
Aki idáig elolvasta, annak nagyon köszönöm!

Üdv: Tamás

Azt a könyvet hiába olvasod el 3x is, ha értelmetlenül van megfogalmazva, vajon mit vársz?!! Ezzel amit most leírtál, kellett volna kezdeni, mert ebből érthető, mit csináltál, mit vártál, és mit kaptál?!!

Az, hogy hány pontot generáltál, és belőle mennyit vágtál le, biztosan nem érdekes, pontatlanságot nem visz be! A lényeg a kettő hatványa itt, az FFT tulajdonságai miatt csak ilyen méretű tömbökre tud számolni.
Ahogy írtad, kb 78Hz egy lépés, így 3,2 lépés jönne ki a 250Hz-re. Értelemszerűen ez a 234Hz-es bin-en fog jelentkezni elsősorban. A másik kettő viszont el van csúszva. Ráadásul, mintha arányaiban is más lenne a csúszás mértéke...
Hogyan kapod ezeket az értékeket? Az FFT függvény kimenetéből hogy számolod vissza az amplitúdót?

Mivel ugye a helyben történő feldolgozást alkalmazó függvényt használom, így abba a tömbbe visszakapott értékpároknak a négyzetösszegének gyökét tekintem az amplitúdónak. A csatolt képek közül a frequencyMagnitude tömbbe számoltam ki ezeket az értékeket. (Mivel értelmes adat csak az első 256 helyen van, így ez a tömb az 512 bemeneti méret pontos fele. A sigCmpx a már feldolgozott tömb. Itt az elejét lenyitogattam. Látható a DC eltolás, illetve az említett ~234 Hz-es rész.

Csatolom a teljes tömböt. Ami furcsa még, hogy nem csak a kívánt helyeken látok kimenetet, de egész más helyeken is. Készítettem a kimenetből egy diagrammot. Látható, hogy az én frekvenciáim is ott vannak, de több másik helyen is elég nagy kiugrások vannak. Harmonikusok lehetnek ? Ha igen, lehet a Matlabos FFT kiszűri ezeket a Microchipes pedig nem? A problémám ezzel annyi, hogy ezek a kiugrások már összemérhetőek a ténylegesen hasznos infóval, így pedig ez nem használható.

Ez a csv abból a matlab által generál, 3 frekis jelből keletkezett?? Mert ha igen, akkor itt valami nagyon nem stimmel. az ok, hogy a te jeleid is mintha benne lennének, nade milyen kis amplitúdóval?!
El tudod küldeni az eredeti legenerált számhalmazt?

A CSV a már lefuttatott FFT kimenete.
Csatolom a legenerált számhalmazt a Matlabból (Ez a teljesen eredeti adathalmaz, az összerakott szinuszokkal - MatlabEredeti.xlsx), illetve a szintén Matlabban átalakított 1.15 formátumú kimenetet (ezt szúrom be a tömbbe a PIC-nél - 1_15_formatum_matlab.txt).

Most Matlabban felnagyítottam a legenerált adatot. Az adatot először átalakítom -1 és 1 közötti értékre, majd ezt felszorzom 32768-al és ezt adom be a PIC-nek. Eszerint a leírás szerint.

Most annyi változott, hogy a peakFrequency-t és a bin-t megtalálja, 8kHz-nél, ami még jó is lehet, viszont kirajzoltatva iszonyatosan csúnya a kimenet. Ez a négyzetösszeg gyöke amit csatolok.

Egy biztos: az eredeti adathalmazod jó!
Abból én csak azt a 3 frekvenciát kapom, pontos helyeken, amiről szó van...

Mi az az 1,15 formátum? Nem lehet, hogy ott csúszik el, a konverziónál?

Én úgy látom, a negatív előjelű számokat rosszul konvertáltad 1.15-be!

Ezen kívül, érdemes átgondolnod jól van e kondicionálva az amplitúdó?! Mert nem -1 és 1 határokat közelít meg, hanem jóval kevesebbet!

Köszönöm, megnézem hol csúszik el a dolog!

Közben "játszottam" egy kicsit Matlabban is, és ugyanezekkel a paraméterekkel kigeneráltam négyszögjelet is, ezzel már sokkal érdekesebb eredményeket kapok.

Maradni fogok a szinusz jelnél és megpróbálom kijavítani a formátumot és legalább valami használható eredményt kicsikarni ebből.

Jó hír, legalábbis jobb Sikerült kijavítanom az adatgenerálásnál a hibát. Most már szépen működik a kontrolleren az FFT. Csatolok egy képet a próba jelről Matlabból és a PIC álltal számolt értékekről (négyzetösszeg gyöke).

Tanulságok, elkövetett hibák, segítség az utókornak:
-sdrlabnak igaza volt, nem jól alakítottam át az adatot, emiatt rossz formátumba került be a függvénybe
-A bemenetetet a függvény tényleg -0.5 és 0.5 között várja az adatokat, különben túlcsordul és fals értéket fog adni.
-Matlabban összeraktam a kimeneti jelemet, teljesen mindegy milyen amplitúdóval, frekvenciával, akár több komponensből, a lényeg, hogy a végén a -0,5 és 0,5 tartományba tuszkoljuk bele.
-Ezt át kell alakítani 1.15 formátumba.
-Az FFT előtt ezzel az adattal már semmit nem kell csinálni.

Ami kicsit furcsa, de végül leesett: Bemenetnek 512 adatpontunk van. Amikor az FFT ezt feldolgozza, nekünk már csak 256 értelmes adatpontunk lesz, viszont ez a teljes tartomány (0-40 kHz). Mivel mi értelmes adatot csak ennek a felénél várunk (mintavételi törvény értelmében), ezért ténylegesen a 0 - 20 kHz tartományt ennek az első 128 pontja fogja jelenteni. Így míg az elején egy pontot a 40000 / 512 jelentette, most már a 40000 / 256. Így az idexeket nem az eddigi 78,125-el kell szorozni, hanem 156,25-el. Példa kép így az 51-es indexen álló érték a 51 * 156,25 = 7968,75 ~ 8000 Hz-et fogja jelenteni.

Még az amplitúdót is át kell skáláznom, ezt is érdekesen módosítja el ez a könyvtár, de holnap is van nap.

Köszönöm a segítséget, ha van rá igény szívesen megosztom a Matlab kódot is és az MpLab projektet is.

Akkor furán működik az az FFT, mert ennek nem így kéne lennie! Ugyanannyi kimeneti pont képződik normális esetben, mint amennyi bemenő volt, viszont a te esetedben ez lenne a teljes 40kHz-es spektrum! Ennek csak az első felét használhatod jelen esetben(a másik fele "tükörkép"), így jönne ki a ~78Hz/bin. Én ezzel számolva kaptam meg a helyes eredményeket...

Itt jön ki, hogy elég hiányos ennek a dokumentációja. A példakódban a VectorMax függvény használatánál is az adatpontok felét adja be hossznak, ebből gondolom, hogy a függvény valahogy N/2 kimenetet hoz létre. Így viszont már kijönne a dolog. Mindenesetre furcsa... (de legalább működik).

Belenéztem találomra a TB3141 microchipes leírásba, ott egyből a 2. oldalon megemlítik, hogy -0,5...0,5 közé kell esnie az adatoknak!
Viszont, ott is csak úgy számolják az 1 binre jutó frekvenciát, ahogyan kellene. Ezek szerint valami még nincs rendben a programodban...
A VectorMax azért kapja csak a felét, mivel ahogy említettem, a másik fele lényegében csak tükörkép(addig, amíg valós komplex adatokkal nem számolsz!!!). Így felesleges a másik felén keresgélni ugyanazt az adatot.... De ettől az még a kimenet részét képezi, és valódi komplex adatoknál ott is önálló adat van, nem tükörkép....

Viszont mivel nálam csak valós része van az adatoknak, ezért az tényleg csak egy tükörkép. Ezesetben a 0-40 kHz nem szűkül le az 512 bemeneti ponthoz képest csak 256 pontra ? Mert ha igen, és feltételezzük, hogy tényleg nem fogok valóban komplex adatot beadni, akkor a 0-20 kHz-es tartományra stimmel a 128 adatpont és ezzel együtt a 256,25 Hz / osztás. (persze a 256.25-ös osztás a 0-40 kHz-re vonatkozik, de én csak az első 128 adatpontot veszem ki.)

Az 512 pont a bemeneten adathalmaz. A kimeneten spektrális összetevők halmaza, 0-40kHz tartományban. Mivel csak a valós részt használod, így ez a 0-40kHz feloszlik egy 0-20kHz és egy 20kHz-0 tartományra, folytonosan tekintve a kimeneti adathalmazt. Ebből értelemszerűen neked elég csak az első fele, a második már nem hordoz többlet infót. De ettől még az 1 bin-re jutó frekvencia, az ugyanannyi lesz, az csak a mintavételi frekvenciától, és az FFT hosszától függ!

Hát itt a hiba! ) Ezt honnan vetted?? A 0-20kHz-es tartomány az az FFT fele, nem negyede!

Valami más turpisság lesz itt szerintem. Beadom az 512 adatpontot. Feldolgozom az adatot és a sigCmpx-en belüli adatokból legenerálom a négyzetösszegek gyökét (amit most sikerült átskáláznom és század pontosságra visszaadja az amplitúdót). A szimmetriatengely 127. és 128. pont között van. Foglalkoztál már esetleg konkrétan ezzel a függvénnyel és ezzel a könyvtárral (dsp.h / libdsp-elf.a)? Mik a tapasztalatok ezzel kapcsolatban?

Most láttam először..., mikrovezérlőn eddig nem volt szükségem FFT analízisre. De a beidézett doksi szerint is úgy működik, ahogy írtam, és ahogy kellene...

Kigeneráltam még egy összetett jelet, hogy ne csak játék legyen a számokkal. Az új jelben van 400 Hz, 11500 Hz és 19500 Hz. A PIC tökéletesen megtalálja, az amplitúdók is stimmelnek, de ehhez a 156,25-ös szorzót kell használom (Most látom, hogy a korábbi hozzászólásban elírtam, nem 256 hanem 156).

Most hogy jobban átnéztem, valóban 255 és 256 között lesz a szimmetriatengely. Ez azt jelentené, hogy 0-40 kHz 256 adatpontban az tényleg 156,25 Hz / osztás. A másik 256 pedig ennek a szimmetriája lesz. A sigCmpx változóban viszont nem ezt látom. Azon gondolkozok, hogy mivel az IP verziót használom, ennek ára lehet és a szimmetrikus részt használja fel a cserékhez?
Persze megint ott tartunk, hogy nincs agyondokumentálva, így csak feltételezek.

A lényeg, hogy jól és stabilan működik szimulátorban, most akkor ki lehet próbálni valós jelekkel, közben meg lehet leesik a tantusz.

Még mindig nem érted teljesen.... A 0-40kHz tartomány a teljes 512(FFT hossz)-re vonatkozik, nem a felére! De komplex adatok nélkül csak 2x20kHz tartományra oszlik fel, tükörképesen! A teljes, monoton 0-40kHz-es tartomány csak a teljes komplex bemenőadatokkal kapható meg!
Lehet, hogy nem jól töltöd fel már a bemeneti puffert sem, és onnan a kavarodás nálad?! Elvileg egy 512 elemű real értéket tartalmazó tömböt, és egy 0-kat tartalmazó img ugyanakkora adathalmazt kellene adnod neki. Ezt teszed?

Ezt teszem. A dsp.h-ban van deffiniálva a fractcomplex struktúra. Az FFTComplexIP is ilyen típusú tömböt vár bemenetnek. Ebben van egy fractional valós rész és egy szintén fractional imaginárius rész. Nekem a fractcomplexből van 512 elemem. Ez tehát 512 valós/imaginárius pár. Az imaginárius mindíg nulla, az átalakított érték csak a valós részbe töltődik be (lásd kép).

UI: A fractional a háttérben egy int.

Akkor passz... Nem tudom, hol csúszhat el a dolog...

Pár éve Mikroe fordítóval készítettem FFT programot. Akkor utána is néztem, hogy működik a DSP a DspicxP33x sorozatú kontrollereken. Erről egyébként az adatlap is értekezik. Lényegében az FFT két lépésben valósul meg. Az első maga az FFT a második lépésben az adatok rendezése ez valami "bit reverse complex" néven fut. Nem ismerem az azóta kiadott gyári lib-et, így lehet hozzászólásom semmit nem ér, ez esetben elnézést az időrablásért, de hátha segít.

Sziasztok, tudtok-e megoldást arra hogy az XC8 compiler a változókat ugyanabban a sorrendben foglalja le a memóriá(k)ban, ahogy a C fileban írom? (mint az mplab C18 a pragma data 0xcim után szép sorban tette) Nekem mindig összekutyulja, hacsak egyesével meg nem adom a címeket mindnek.

ha az uni0n szót helyesen írva tartalmazza a hozzászólás, akkor nem jelenik meg

Szóval
a) berakod a változókat egy uni0n-ba egy tömbbel
b) struct-ban definiálod a változókat

Üdv Mindenkinek!

Egy kérdésem lenne: PICkit-3-am van, érdemes-e venni "MPLAB(R) Snap In-Circuit Debugger"-t? Nyerek vele valamit?

Ha jól csalódok, emlékeim szerint az utóbbi nem tud magasfeszültségű égetést, szóval nem tud minden pic tipust... Esetleg szoftveres töréspontban tudhat többet, de meg kell nézni...
itt van összehasonlítás a pk4-el, meg megnézhető a pk3 paraméterei is

PIC gerjedésre keresem a megoldást. Építettem egy kísérletező panelt, ami pusztán abból áll, hogy a PIC lábai egy csatlakozó sorra szimplán, direktben ki van vezetve. Érdekes, hogy csak az RB port környékén gejed, ha közelítem a kezem. (A PIC-ben futó program megbolondul.) A régi tesztpanelen úgy volt megcsinálva, hogy a PIC kivezetése először egy csatlakozó sorra megy, aztán egy ULN2803-as IC, majd LED. Itt nem gerjed semmi, tapogathatom bátran.

Kérdés: Hogyan tudom ezt a zavart kivédeni, a lehető legegyszerűbben? Esetleg az összes lábat egy 10K lehúzó ellenállásal kössem GND-re. majd így vezessem ki a csatlakozóra?

Köszönöm.

Ilyesmivel én még nem találkoztam és nem is hallottam róla. Szerintem egyszerűen programozd kimenetnek.

Nekem akkor volt hasonló élményem, amikor valamelyik láb (talán LVP) programozásra volt konfigurálva figyelmetlenségből, de én applikációból használtam. Ha közelítettem kézzel, akkor megbolondult. Amint átállítottam sima portra, megjavult.

Na ezt most kipróbáltam. Ha az LVP-t átállítom "Disable" módra, megjavul. Tapogathatom bátran. Ha viszont az LVP "Enable" Akkor azonnal meghülyül, ha közelítek hozzá.

Összerakom az eredeti kísérletező panelt, aztán referálok.

Köszönöm.