Search
在 Python 中實作 DSP : 超過 70 個以上的範例，FFT，濾波器設計，IIR，FIR，Window Filters，卷積，線性系統等
在本課程結束時，你應該能夠使用 python 開發卷積核心演算法( Convolution Kernel algorithm )，使用 python 開發17種不同類型的視窗過濾器
https://softnshare.com/%e5%be%9e%e5%9f%ba%e7%a4%8e%e9%96%8b%e5%a7%8b%e5%ad%b8%e7%bf%92%e5%9f%ba%e6%96%bc-python-%e7%9a%84%e6%95%b8%e4%bd%8d%e8%a8%8a%e8%99%9f%e8%99%95%e7%90%86-dsp/
#汽車電子 #雷達 #工業感測器 #接收降頻轉換器 #連續波雷達接收器
#毫米波積體電路MMIC #低雜訊放大器LNA #鎖相迴路PLL #鑒頻鑒相器PFD
【關鍵 3dB 降噪，提升雷達靈敏度和檢測範圍】
「毫米波接收降頻轉換器」可同時放大、並直接轉換成 24 GHz 的高品質、高幅度頻段或低頻率接收訊號，便於連接至類比—數位轉換器 (ADC) 或類比前端 (AFE)。若內建整合式溫度感測器，不僅可省下離散感測零組件，在系統組裝與測試過程中，亦不需額外耗費時間和資源進行校準，特別適用於對能效有高要求的應用，如：汽車 ADAS 雷達、微波雷達感測器，以及工業用雷達系統等高頻應用。
具有 4 通道、24GHz 的毫米波積體電路 (MMIC) 接收器，其四個 RF 頻道可將高頻降轉成差動基頻訊號，然後可直接進入一個特殊的多通道 ADC，使用數位波束成形技術進入類比接收器。這些數位訊號可利用在一個系統微處理器上運作的快速傅立葉變換 (FFT) 和其他複雜的雷達探測軟體演算法來估測，以實現探測出現在雷達感測器系統前的目標，並計算目標速度、距離和位置。其上所有 RF 輸入皆為簡單的單端輸入，而這些都在內部連接到整合式平衡至非平衡轉換器，以用於轉換接收器訊號為差動信號，來達成更高的性能放大和降頻轉換處理。
許多以積體電路為基礎的雷達系統發射器和接收器的雜訊檢測範圍有限，導致臨近較大物體、雷達系統在檢測更小的物體或標的物時會有所限制。在實際雷達應用上，吵雜的目標環境 (包括地面雜波的存在)，都會增加系統相位雜訊、減低雷達接收器的敏感度；過高的系統雜訊會遮蓋或隱藏小型標的物、阻礙檢測，恐影響感測器安全。若能將雜訊係數降低 3 dB，加上配套的發射器晶片和鎖相迴路高性能的相位雜訊，不但可實現更高的接收系統訊號雜訊比 (SNR)，並提供可靠檢測，參數估計能更快產生結果。
延伸閱讀：
《高性能整合式24 GHz 調頻連續波雷達接收器晶片技術》
http://compotechasia.com/a/ji___yong/2016/0419/31710.html
(點擊內文標題即可閱讀全文)
#亞德諾半導體ADI #ADF5901 #ADF5904 #ADF4159
[本文將於發佈次日下午轉載至 LinkedIn、Twitter 和 Google+ 公司官方專頁，歡迎關注]：
https://www.linkedin.com/company/compotechasia
https://twitter.com/lookCOMPOTECH
https://goo.gl/YU0rHY
【好文推薦】腦力科技之四：要複雜還是要簡單
成大資工係蘇文鈺教授從台灣企業看輕底層IT（忽略對OS、編譯器等等底層技術的投入）的價值，只顧搶商機的幾個真實小故事，來談臺灣資訊產業的困境和短視。
好文一篇，經蘇老師同意特轉貼！
"許多傳統的技術因為其他領域的技術的高度發展而導致被淘汰，也有許多早被丟棄在一邊多年的技術卻因此而重生。可是因為許多人無法看到幾個世代以來的技術發展過程，也欠缺終身學習的思維，因此常常固執的固守一項當下看來成功的技術與做法，這些人或公司最終都是會招致失敗的後果。
by 成功大學資訊工程學系蘇文鈺教授"
之前的po文，我修了一下文字。若是之前看過的可以跳過。
[腦力科技之四 要複雜還是要簡單]
前面說到的Dave Wilson要價數十萬美元的喇叭WAMM是個大傢伙，整個喇叭是多個分開的模組所構成，非常複雜，所以一般不熟WAMM人要把它調整好是很困難的，難怪要出動Dave Wilson本尊才行。問題是要聽好聲音一定要弄得這麼複雜嗎?
簡單的喇叭，一顆單體裝在一片木板上就可能可以很好聽了。到底要複雜，還是要簡單，其實這問題說是難回答的也不見得，想通後，也可以很簡單。以下是聖嚴師父說過的一個故事:
在我小的時候，有一天傍晚，我父親跟我正好經過一條河邊的小路，有一群鴨子本來在河岸上休息，見到我們父子倆走過，或許是受驚了，也或許是要讓路給我們，總之一群鴨子全部都下了河，從河的這一邊，游到另一邊去。接著又上岸去玩了。
父親看著在河裡游的鴨子，告訴我說：「孩子，你看到了嗎？這群鴨子裡，有大鴨、有小鴨。大鴨游出來的是大的路，小鴨游出來的是小的路。不管是大路還是小路，都是自己游出來的路，而且都到了河的對岸。」
又說：「孩子啊，人要學這些鴨子。你長大之後，不管游出大路或小路都沒有關係。可是不游是不行的，因為不游的話就沒有路可走了。」
也就是說，簡單有簡單的用處，複雜的有複雜的好，做的好，都有活路。
我們這個年紀的人當年用的是Apple II，學程式是從Basic入手，然後是Fortran，接著是Pascal和C，後兩者最大的障礙是要把當時認為抽象的資料結構(data structure)以及資料存放的位址(address)和指標(pointer)的關係搞懂。相對於Basic不知到複雜多少，可是用C能做的事，其實用 Basic也做的到，只不過後者做起來可能會很麻煩而已，程式可讀性與可再被利用性會大幅降低。後來一點我才知道其實所有的高階語言都會透過編譯器(compiler)轉為更低階的assembly(組合語言)，所以實際上電腦是依照組合語言一步一步執行的，一個高階語言的指令通常是以多個低階語言來完成。當年在開發工具不足的情況下，我甚至被迫要直接用6502與Z80的機器碼(machine code)來寫程式，因為當時根本沒有如現在這些方便的滑鼠，鍵盤與螢幕可以用。一份工作是要用高階一點的語言來實做，還是用低階的語言來完成，應該依照需求與當下的技術成熟狀況來決定，而不是高階的就一定比較好，低階的就比較一定差，例如多數驅動程式，不用低階語言來做是不行的。反之亦然。
後來我的工作跟使用TI(德州儀器)的C3X與C4X等數位訊號處理器(Digital Signal Processors)有關，一些數位訊號處理的程式我與我的夥伴們都用組合語言來寫，因為編譯器轉出來的程式執行效率實在太差了。可是幾年以後，編譯器越來越強大，所編出來的程式的效能就慢慢提高了，在非關鍵處，我們已經不再堅持用組合語言來寫了。
後來的程式語言越演變越複雜，功能也越來越強大，從簡單的C，到後來的物件導向(Object Oriented)，從為數不多的語言，到因為不同的需求而被開發的新語言如Java，LISP，Pearl，Python，Forth等等甚至有為了設計電路的硬體描述語言(HDL) ，慢慢的學校裡對組合語言的要求變少，學生也不願意學，造成許多需要低階語言的工作找不到人來做，不然就只好把人招進了公司後再來訓練。緊接著，為了不同的目的而開發的新的工具軟體變多了，例如為了特殊的資料流(data flow)程式模型而被開發的StreamIt，以至於目前開發iOS App而廣為使用的Object C(我們之後有機會再來談這個語言)，為了平行程式所被開發的如OpenMP或MPI(Message Passing Interface)，這世界上有關於寫程式這件事所被開發出了來工具多到滿出來，編譯器與中介軟體(middleware)越來越強大，各式各樣的新語言，新應用等等就越多。可是不要忘了，即使是有這麼多五花八門的產物，這世界上有一些角落裡的工作還是需要使用組合語言來做。
有些事需要用複雜的方式來做，有的事卻需要用簡單的方式來做。原本一隻簡單的程式，因為可以平行化，如今我們因為有多核心的機器與可平行的程式模型可以用，所以程式設計師會用更複雜的方式如多執行緒(multithread)，資料流(data flow)，Map-Reduce(如Hadoop)，CUDA與OpenCL等來實做，程式的複雜度看起來提高很多，可是執行所需的時間實際上卻大幅降低。又如，在數位訊號處理裡常用的旋積(Convolution)，本來是可以用沒幾行的程式就可以寫出來，但是因為快速富利葉轉換(FFT)的關係，讓我們可以在頻率域(Frequency Domain)裡運算以減少計算時間，但是程式複雜度卻高出許多。可是，因為多核心架構硬體與平行的程式模型的出現，加上時間域(Time Domain)的旋積具備高度可平行化的特性，現在反而是回到時間域來計算要快得多，同時也少了一些在頻率域(Frequency Domain)運算所造成的缺點，過去為了在頻率域運算所開發出來的演算法反而變得沒有多大用處了。
許多傳統的技術因為其他領域的技術的高度發展而導致被淘汰，也有許多早被丟棄在一邊多年的技術卻因此而重生。可是因為許多人無法看到幾個世代以來的技術發展過程，也欠缺終身學習的思維，因此常常固執的固守一項當下看來成功的技術與做法，這些人或公司最終都是會招致失敗的後果。
以上我們說了許多軟體的發展，接著來說硬體，尤其是電腦的核心，CPU(中央處理單元)，也就是大家常聽到的Intel Pentium，IBM PowerPC或是ARM Cortex等等。早年的CPU如Apple II用的6502到今日的主流多核心CPU，其複雜度不知道已經高出多少倍，30年前的大型主機(我大學時用的是CDC Cyber，全校共用)的計算能力可能比不上今天的一部桌上型電腦。有一陣子，簡單架構的CPU不容易被聽到(但是實際上他們的用處很廣呢!)，一般人知道的CPU都是INTEL出的(因為廣告打得兇)，那時的人類似乎除了INTEL X86架構的CPU之外都不需要其他的了。可是曾幾何時，INTEL感受到ARM的架構簡單的省電CPU的強力威脅，所以INTEL也希望把它的CPU變成簡單又省電，但是與此同時，ARM卻在把它的CPU變得功能更強大，但是卻也更耗電。你們說，這兩家公司在爭的商機是甚麼呢?相信只要在這個產業的人都知道他們在玩什麼把戲。大家都知道的東西，在CPU設計落後先進國家的台灣在高階CPU上也就沒什麼好搶的了，那台灣的機會在哪裡呢?(當然，現在的聯發科跟晶心科技這兩家策略與市場都不一樣的公司看來是很有機會佔有一定的市場，有興趣的人可以去研究一下這兩家公司的CPU策略)
有一天，有朋友打電話給我，聊起他現在的公司也在做CPU，而且是八位元，或甚至位元數更低的CPU。我說，這麼低單價的東西有什麼好做的。他說，其實市場的量真正大的是簡單型的CPU，因為太多應用只需要用到簡單的CPU，這時連8051都還嫌太複雜，而且目前設計界常用的Arduino也可以在稍微複雜一點的八位元CPU跑起來。只要做的夠便宜夠省電，利潤還是有的。但是這其中還有一個大問題，那就是即使是這麼簡單的CPU，在今天的情況，工具鍊(toolchain)還是要完整，才會賣得出去。他問我可不可以幫他做編譯器，我說這非我專長，實在是愛莫能助。我不禁想，這年頭連賣一顆幾毛錢的CPU都要開始建完整工具鍊了，這錢還真難賺啊!
又有一次，有間廠商打電話過來問我有沒有興趣做一個建教合作計畫，是關於多核心的系統軟體的。那時候我一聽到多核心，腎上腺素就上來了，也沒多問細節就說可以見面討論。過兩天，我們一起聚在一起開了個會，才知道這個多核心原來是拿8051來當核心。我心想，連8051都拿來做多核心，會不會太奇怪。不過既然廠商堅持有他們的市場與考量，也可以賣得出去，我這商場門外漢就不好說甚麼了。接下來廠商希望我們可以幫忙做兩件事，第一件是為這顆多核心打造一個多核心作業系統，第二件是做一套中介軟體讓不同核心之間可以快速交換資料。當我心裡還在盤算著，且認為這應該可以做得到的時候，接著聽到的話讓我差點從椅子上掉下來。他說，但是這一切希望在16K bytes之內做到，而且在半年內做完，經費是30萬。接著我只能說我願意考慮看看，其實心裡說的是謝謝再連絡並祝福他們會成功，一刻鐘後我堆滿一臉笑容來隱藏底下的鐵青送他們出門。
這些事讓我想起來台灣過去幾年有關IC設計的問題，甚至是更多產業所面對的問題。那就是太重視硬體了，以為只要把硬體做出來，就可以賣出去的時代早就已經過去了，而目前全世界最大的高科技公司其實都是軟體為主的公司，連聯發科的軟體工程師數目早就超過硬體工程師的數目了。假如連一顆八位元的不到的CPU都需要一大堆軟體工具鍊，那麼我實在不清楚很多公司只注重看來是實際出貨用的硬體在想什麼，會逐漸失去商機不奇怪啊!我自己會想，要是早個十年我知道軟體的工具練會這麼重要，那麼我不就賺翻了嗎?可是上面的第二個故事告訴我，在台灣，不被重視的就是不被重視，早做也沒用。很多廠商把技術看得太廉價了，但是這家公司至少還願意出錢，有的台灣公司即使本身很賺錢卻根本就連錢都不出就想獲得技術。
2010之前的好幾年，韓國的政府讓許多家大學(我沒記錯的話是八家，連漢陽與首爾都在其中)，參與企業(就是三星啦!)一起trace Android的核心的時候，台灣在做甚麼呢?大喊自由軟體，然後只要寫寫不知道能不能用的Java App就可以有獎金或補助。等到三星智慧型手機崛起，火燒屁股時，才急急忙忙由政府底下的若干研究單位出面協調，同時希望學界也能出面幫忙。
這整件事的荒謬在於，第一，商場如戰場，都火燒屁股，要馬上上戰場去賣的東西讓學界來幫忙怎麼會來得及呢？第二，學生寫的軟體你敢用嗎？一旦有bug不是退貨退到瘋掉？第三，這種核心技術早就該知道要做了，不然派個探子去美國，甚至是韓國轉一圈，也知道人家在做甚麼。然後，既然都火燒屁股又要找學界專家來幫忙，為什麼不乾脆花大錢挖學界懂這東西的一整個團隊進公司體系，還要找官方與半官方的機構出面協調，這不是浪費時間呢？台灣不是最流行超時工作，讓工程師燒肝（燒乾）工作的嗎？高薪一堆人進來，以台灣工程師的素質之高，其實不會沒救的。不過，我看到的情況只能用失望兩個字來形容。
有時人要挖空心思才可以看到商機，有時只要好好照著道理來做就會有商機，賣系統（不管是複雜到手機還是其他簡單的系統應用IC）卻不重視軟體就是沒照著道理來做。目前台灣所製造的電腦產品，只要是要用到稍微大型的軟體系統如Android，或甚至是小到一個小型的RTOS(即時作業系統)，有多少是台灣所原創的呢？不能原創的原因很多，公司不重視軟體人才此其一，會教又提供學生實作機會的學校不多（因為做這類苦工無法出High Impact Factor的論文啊！）也是主因，政府科技與教育政策一樣難辭其咎。以編譯器（compiler）這樣傳統的學問來說，不管時代怎麼變，不變的是它對產業總是非常的重要，學校裡有多少人還在做編譯器的研究呢？再來恐怕都要找不到人來教了，因為有多少教授願意做一個傳統又難以發表High Impact Factor論文的研究呢？過幾年，整個硬體產業要是變成硬體慘業，我是一點也不意外。即使沒完蛋，還不是要乖乖每年繳一大堆權利金給外國提供軟體的廠商嗎？
你若是問我，難道台灣真的沒有那種看到軟體工具鍊與大型軟體的機會，堅持信念，終於媳婦熬成婆的團隊嗎？當然有，我也好希望我也是其中之一。可惜我沒有這麼堅強的毅力，要不然也不用在這裡狗吠火車了。
前面說過的話，這裡再重複一遍，但是用意與前面不同，這裡是希望為上面這幾段故事做小結：
許多傳統的技術因為其他領域的技術的高度發展而導致被淘汰，也有許多早被丟棄在一邊多年的技術卻因此而重生。可是因為許多人無法看到幾個世代以來的技術發展過程，也欠缺終身學習的思維，因此常常固執的固守一項當下看來成功的技術與做法，這些人或公司最終都是會招致失敗的後果。
時代在改變，有些事也會跟著變，但是有些事卻也一直不變，變與不變之間，要視實際狀況決定。就跟聖嚴師父說的一樣，大鴨子與小鴨子，只要願意努力前進，都可以游出自己的路。
此文基于自己最初学习引力波数据处理的时候，研究Pyhon/MATLAB 等编程语言和程序包中的`fft` 具体含义的科学笔记。 ... <看更多>
fft 相关的一些资料. Contribute to binbinyantai20161003/fft-related-files development by creating an account on GitHub. ... <看更多>
fft算法 在 4 8 快速傅立叶变换FFT算法- YouTube 的推薦與評價
4 8 快速傅立叶变换 FFT算法. 95 views · 3 years ago ...more. 刘先生. 7.56K. Subscribe. 7.56K subscribers. 0. Share. Save. Report. Comments. ... <看更多>