首先，微處理器被編程為80MHz Olimex PIC32，焊接到PIC32-PINGUINO-OTG開發板。（對于那些曾經使用Arduino板進行修改的人：它是相同的，只有更快的芯片和更少的內置庫）算法必須以固定的時間間隔對輸入信號進行采樣，將此信號轉換為頻域，并可視化檢測到的頻率在16x16x5 LED矩陣上。

當然，在編寫任何代碼之前，我們必須弄清楚如何將輸入樣本轉換為頻率分布。通過對輸入信號應用離散傅里葉變換（DFT），在信號處理中始終完成這一事情。給定以恒定頻率采樣的信號，DFT輸出一組落在信號中的幅度或頻帶。例如，當您的信號主要由中間C（或Do）音調組成時，DFT將為頻帶分配相對較高的幅度并匹配相應的262 Hz頻率。

然而，人耳以對數方式感知聲音，這意味著聲音信號的頻率加倍僅被視為線性更高的音調。為了彌補這一點，我們使用了Constant Q變換（CQT）代替DFT。簡而言之，在DFT返回頻帶f-2f-3f-4f-等的幅度的情況下，CQT與頻帶f-2f-4f-8f-etc一起工作。

因此，從理論角度來看，3DSA所需的算法非常簡單：以規則的時間間隔對輸入信號進行采樣，對16個頻帶應用CQT計算幅度，并使16個LED列中的每一個適當地閃爍。鑒于Pinguino開發板支持C，我們假設實現這個算法不會那么難。但是，總會出現一些挑戰：

第一個障礙：如果您只有一個線程，您如何定期采樣信號？一個簡單的解決方案是獲取樣本，計算CQT和可視化，讓線程休眠直到某個時間段已經過去，然后再開始新的樣本 - 計算 - 可視化循環。但是，我們希望我們的采樣率為14 KHz，這在80 MHz微處理器上留下了課程，而不是樣本之間的6k個時鐘周期來計算CQT。這證明是不夠的 - 最后我們為每個計算 - 可視化周期使用了~1M個時鐘周期，因此我們必須弄清楚如何在進行CQT計算和舊樣本的LED可視化時采集新樣本。

在仔細閱讀了許多Pinguino論壇之后，解決方案以中斷的形式出現：一段比其他代碼具有更高優先級的代碼，并由處理器以指定的時間間隔執行。由于Pinguino開發人員沒有為PIC32上的中斷提供C庫，因此我們必須通過將某些處理器位設置為正確值來手動實現此功能。成長為Java程序員后，我幾乎可以感受到代碼中的硅片

另一個大障礙是PIC32芯片不存在的浮點功能。在我們的CQT實現的內部循環中執行任何浮點運算會使代碼減慢一個數量級，從而以幻燈片形式轉換LED可視化（現在我知道如何使用舊GPU）。為了解決這個問題，我們使用了一個臨時的定點數字格式，使用了10個小數位。這是一個復雜的乘法，但完成了工作。