Svenska ElektronikForumet

Hej!

Mitt problem är följande: Jag har en fft som genererar en endimensionell array med låt säga längd 1024 (positiva tal tillhörande 2^n helt enkelt).

Det jag vill göra är att rita upp resultatet på en skärm som en pixelrad med okänd upplösning. Så Mitt dilemma består i att få en array med längd 2^n att snyggt ritas upp på skärmen..

Då divisionen mellan skärmens upplösning och 2^n kommer ha en rest som kan bli rätt stor, ex: skärmupplösning 513 och fft av längd 1024, 1024 mod 513=511, går det inte att dela upp och ta medelvärdet av "kvoten antal" element.

Känns som att lösningen borde ha herren Gauss i namnet men jag är lost.
Nån som har gjort nått likande tidigare och som kan peka mig i rätt riktning?

Tack på förhand!

Omsampling kallas detta. Hur noga behöver det vara och behöver det gå snabbt? Om det inte är så noga utan bara ska bli en kurva som visas på skärmen kan du t.ex. falta med ett kort hanning-fönster eller liknande som du flyttar framåt över fft-datat (detta behöver inte ske i heltalssteg). Hm... inte så bra förklaring inser jag, men beroende på bakgrund kanske du fattar ändå.

Måste fftn köras på en tvåpotens-längd? Många implementationer är rätt snabba på andra längder också numera, och då är det kanske enklare att ta en längd som är en multipel av målupplösningen direkt.

Tack för ordet omsampling, det var precis det som behövdes för att få fäste i Google!

Jag vill nog inte ändra för mycket i fft implementationen då detta körs på en android mobil (Java med google's dalvik registerbaserade vm.. ).
Så ja, jag är nog dessvärre rätt bunden till tvåpotenser.
Har inte så jättekoll på hanning-fönster men ska läsa på lite.

Tack!

Om vektorn är längre än skärmen är bred så är det ju bara att skala vektor-index vid rendering. Pseudokod för enkel och dum uppritning:
Ovan metod hoppar som synes över värden i vektorn så istället kan man ju ta hänsyn till dem på lite olika sätt beroende på vad som är intressant; max, min, snittet, etc.

Om skärmbredden skulle vara större än vektorlängden skulle man istället upprepa en del värden och det gör ju inget.

Det du beskriver är vad jag skulle kalla decimering (i fallet fler punkter i fft än vid uppritning). Om man gör det på sättet som du beskriver uppstår så kallad vikning. För att undvika detta behövs ett lågpassfilter (t.ex. hanning-fönstret jag skrev om).

Om kurvan ska ritas snyggt på skärmen kommer du behöva använda någon algoritm för att att ta hand om vikning ändå (brukar kallas anti-aliasing). Beroende på vilken sådan kurvritningsalgoritm du använder så kanske det inte gör något att du har för många datapunkter i den underliggande fftn. Jag har använt den här för att rita linjer mellan punkter, och den funkar bra även med flyttal som data. Då klarar du dig säkert med att enbart linjärinterpolera mellan fft-punkterna.

Ja, jag sade ju det:

hanzibal skrev:Ovan metod hoppar som synes över värden i vektorn så istället kan man ju ta hänsyn till dem på lite olika sätt beroende på vad som är intressant; max, min, snittet, etc

Jo, Det låter nog som jag får gör nått sånt. Slänger upp ett skärmskott för att visa vad jag gör. Det är alltså de vertikala pixelraderna som är problemet.
(Skärmen rullar sveper åt höger med tiden, varje vertikal pixelrad är en uppsättning samples som genomgått fouriertransformering, dvs. tid i x led, frekvens i y led.)

Sorry. Det gjorde du ju! Jag ville mest utveckla metoden lite och få fram att man behöver långpassfilter som tar hänsyn till flera värden om det ska bli bra.

Aha, jag tänkte mig frekvens i X-led och intensitet i Y-led som en grafisk EQ men problemt är ju samma, fast vertikalt.

Ser ut som att du låter "svärtan" återspegla intensiteten. Egentligen ser man ju då signalen i tiden med alla frekvenskomponenter överlagrade på varandra - är det ljud?

EDIT: Överväg att använda en färgskala istället för gråskala - kan tänkas bli både informativt och snyggt

Aha, ett spektrogram. Men då fattar jag inte. FFT-längden påverkar väll bara antalet pixlar på höjden. Hur kan det ge upphov till de vertikala linjerna? Det borde väl vara kopplat till uppdateringshastigheten?

Mja, alltså den uppdaterar skärmen och skriver till en ny vertikal pixelrad varje gång den har samplat det antal sampels den behöver (fft’n räknas ut parallellt ).

De skrivs ut så att varje gång den har samplat klart ritats det nya resultatet en pixel åt höger i x-led tills den når högerkanten varvid den börjar om vid vänsterkanten osv. osv

Längs upp i fönstret är de höga frekvenserna, längs ned – DC. Ljusa färg = hög intensitet, svart= ingen intensitet. Jag ska fixa snyggare, logaritmisk, färgskala - men det är ju slutpolering.

Det den gör just nu är att ritar upp fft resultatet i Y-led, det bara råkar bli så att skärmen är så liten att den inte börjar rita ut de negativa frekvenserna.

Men ja, problemet består ju i att få en vektor av längd n att ”fördelas” till en annan av längd m (m>n).

Har funderat på detta med lågpass, kommer det inte innebära att signalen blir rätt ”utsmetad”?

superx: Förstår inte helt vad du menar? (Kanske jag råkar svara på det med detta inlägg)

Edit: Ändrade (m>n) till (n>m).

Tja, jag förstår bara inte hur det du frågar om kan orsaka de vertikala linjerna.

Och visst blir informationen utsmetad. Tricket är att välja lågpassfilter så att den blir precis lagom utsmetad för målupplösningen.

Jag förstod det som att fft-vektorn är längre än skärmen är hög och inte tvärt om.

Om vektorn är kortare än skärmhöjden kommer vissa fft-värden att ritas ut flera gånger men man missar ju inget och det gör väl inget eller?

Tror superx menar de nästan hela vertikala linjerna som uppträder med ganska jämna mellanrum - dessa skulle ju innebära att nästan hela spektrat är närvarande vid dessa tidspunkter - stämmer det? Om inte så är det kanske fel i fft-algoritmen eller så förekommer störningar, mätfel eller annat.

Lijerna beror nog på att jag stötte till mobilen, så ja, det är hela frekvensomfånget som är aktivt, den är rätt känslig just nu. Har inte kommit till inställning, uppritning osv. då jag först vill kunna se vad jag håller på med.

Och ja, fft'n är längre än skärmen, skrev som vanligt fel med större än symbolen, skyller på tidsomställning.
Rätt är:
"problemet består ju i att få en vektor av längd n att ”fördelas” till en annan av längd m (n>m)."

Ändrar i mitt tidigare inlägg.

> Hur kan det ge upphov till de vertikala linjerna?

De har inte med frågan att göra.
Hela frågan handlar om skalning...