Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   1309 / 1319
(#) silent15 válasza sdrlab hozzászólására (») Dec 3, 2020 /
 
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
(#) sdrlab válasza silent15 hozzászólására (») Dec 3, 2020 /
 
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?
(#) silent15 válasza sdrlab hozzászólására (») Dec 3, 2020 /
 
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ó.
(#) sdrlab válasza silent15 hozzászólására (») Dec 3, 2020 /
 
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?
(#) silent15 válasza sdrlab hozzászólására (») Dec 3, 2020 /
 
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).
(#) silent15 válasza sdrlab hozzászólására (») Dec 3, 2020 /
 
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.
(#) sdrlab válasza silent15 hozzászólására (») Dec 3, 2020 /
 
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?
(#) sdrlab válasza silent15 hozzászólására (») Dec 3, 2020 /
 
É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!
(#) silent15 válasza sdrlab hozzászólására (») Dec 3, 2020 /
 
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.

negyszog.png
    
(#) silent15 válasza silent15 hozzászólására (») Dec 3, 2020 /
 
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.
(#) sdrlab válasza silent15 hozzászólására (») Dec 3, 2020 /
 
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...
(#) silent15 válasza sdrlab hozzászólására (») Dec 3, 2020 /
 
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).

vicc.jpg
    
(#) sdrlab válasza silent15 hozzászólására (») Dec 4, 2020 /
 
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....
A hozzászólás módosítva: Dec 4, 2020
(#) silent15 válasza sdrlab hozzászólására (») Dec 4, 2020 /
 
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.)
(#) sdrlab válasza silent15 hozzászólására (») Dec 4, 2020 /
 
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!
Idézet:
„persze a 256.25-ös osztás a 0-40 kHz-re vonatkozik, de én csak az első 128 adatpontot veszem ki”

Hát itt a hiba! ) Ezt honnan vetted?? A 0-20kHz-es tartomány az az FFT fele, nem negyede!
(#) silent15 válasza sdrlab hozzászólására (») Dec 4, 2020 /
 
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?
(#) sdrlab válasza silent15 hozzászólására (») Dec 4, 2020 /
 
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...
(#) silent15 válasza sdrlab hozzászólására (») Dec 4, 2020 /
 
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.
(#) sdrlab válasza silent15 hozzászólására (») Dec 4, 2020 /
 
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?
(#) silent15 válasza sdrlab hozzászólására (») Dec 4, 2020 /
 
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.
A hozzászólás módosítva: Dec 4, 2020
(#) sdrlab válasza silent15 hozzászólására (») Dec 4, 2020 /
 
Akkor passz... Nem tudom, hol csúszhat el a dolog...
(#) ha1drp válasza silent15 hozzászólására (») Dec 5, 2020 /
 
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.
(#) sszasza hozzászólása Feb 17, 2021 /
 
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.
(#) superuser válasza sszasza hozzászólására (») Feb 17, 2021 /
 
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
A hozzászólás módosítva: Feb 17, 2021
(#) tomi52 hozzászólása Máj 10, 2021 /
 
Üdv Mindenkinek!

Egy kérdésem lenne: PICkit-3-am van, érdemes-e venni "MPLAB(R) Snap In-Circuit Debugger"-t? Nyerek vele valamit?
(#) pipi válasza tomi52 hozzászólására (») Máj 10, 2021 /
 
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
(#) Zoli_bácsi hozzászólása Dec 3, 2021 /
 
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.
(#) bbatka válasza Zoli_bácsi hozzászólására (») Dec 3, 2021 /
 
Ilyesmivel én még nem találkoztam és nem is hallottam róla. Szerintem egyszerűen programozd kimenetnek.
(#) pbalazs válasza Zoli_bácsi hozzászólására (») Dec 3, 2021 / 4
 
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.
(#) Zoli_bácsi válasza pbalazs hozzászólására (») Dec 3, 2021 /
 
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.
Következő: »»   1309 / 1319
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem