2015年4月23日 星期四

得獎產品(CDI) 背後的開發故事(一)

在真正講得獎產品的開發故事之前,我先把產品的基本概念先簡單的帶一遍。

可以讓您很簡單的,很容易的瞭解這個產品的特色在哪?或許您也可以由此

也可以想一下他之所以得獎的道理。(說真的~真正的得獎理由我也不知道,

這個大概要問評審委員會比較清楚吧!)

或許有很多人不清楚說:CDI 這個東西在所謂機車噴油系統出現後,他還有什麼

市場產品價值呢?其實觀念很簡單,在所謂機電整合技術過程中,有很多過程

是大家所沒有留意到的。

我講一個很簡單的道理,就是大陸的經濟起飛在這幾年是世人所有目共睹的,

所以呢?就有很多人會跟您說:大陸有許多產品技術,就不用像以前這樣子,

一步一腳印的建設,可以直接跳到最後一哩路。譬如資訊網路。就不用像我們以前

那樣還要架設基礎配線,就直接用無線基地台就好了。對的~有些產品或建設

可以這樣子思考,但有某些產品或技術卻不是如此。

同樣的道理,中國大陸每一年的所謂的全國人大會議都會宣示他們的科技或什麼

產品技術要在一年或兩年內超英趕美...超越德國日本.....說了一大堆。

但我們私底下常開玩笑說:那他們可能要先想一下,什麼時候他們中國大陸可以

去抱回幾座諾貝爾獎再說!...有很多表面上許多科技產品都是建築在非常基礎研究

工作上的。或許您沒辦法體會,但如果您真的有真正的沈溺在技術開發N 年之後,

您就可以體會我所說的!...不要以為只會寫寫APP,兜幾個電路版就是搞科技技術了。

不信的話,您可以往下看人家產品開發的過程。
---
好吧,我們先來簡單的解說一下產品基本想法,如果您沒有機會去展覽會場聽我們

解說的話,看看這一篇文章也可以。

首先呢,所謂可程式化的CDI,簡單來說:就是保有一些可以讓使用者在產品應用上的

一些彈性,但我必須聲明的是:所謂可程式化的CDI 或包括市面上所謂改裝噴油電腦,

講實在一點它們可能都沒有您想像中的那麼偉大,所謂偉大的意思指的就是:

它們的基本能力還是有限的,機車引擎或是機車本身不會因為您一個簡單的可程式化

的CDI 或噴油電腦就可以讓您的車會飛天遁地的!畢竟機車或汽車它們基本上還是

屬於機械裝置,有很多基本觀念是不可能脫離現實太多的,而且如果這些東西如果

有這麼神,汽機車已經發展超過百年了,有很多技術也不一定輪到我們才會發揚光大的。

所以我們還是依照一個很簡單的基本理念走,您就比較可以接受這樣子的產品觀念。

當然也不用急著說:隨便改個東西,再來隨便改個電腦設定就好....點火可以玩玩,

但噴油系統沒您想的這麼單純...往下看完最後TPS 觀念後,您就會有一點感覺。

所謂可程式化就是要提供一個簡單的可以隨時修改的介面平台,也就是我們俗稱的

應用軟體,不管您是要用PC 或什麼作業系統,別忘了,終究他的對象還是簡單的人機介面。

我這個人就是不太喜歡老是在一個APP 裡,視窗翻來翻去的...再提醒一次,您是在玩

機械裝置,而不是所謂的網路連線遊戲...應用軟體寫得太複雜,也不會代表您比較厲害的!


您有沒有發現,這個軟體跟我以前很早發表的DOS 版 應用軟體有沒有很像啊?


至於硬體介面呢?想當然爾,如果您是我Blog 的粉絲的話,您應該對我USB的

基本技術不會有所懷疑的,其實我開始做這產品開發時,我也一度想偷懶就用

RS232 轉USB 的東西就好了。但後來客人一直跟我反應:Chamber ...您以為那些玩機車

的人都那麼清楚視窗軟體功能吧?...您還要人家去找那個USB 轉到RS232 之後,

還要去找是 COM1 或 COM2 ...甚至不知道已經到COM ?幾之後了。好吧...就順從民意,

把USB 介面改成HID...讓他可以真正做到Plug and Play 。這樣子的技術就不要再拿出來

吹噓了,甚至為了保留未來介面功能擴充功能,還要支援USB Cable 的韌體智能升級了。

這些在所謂的一般IT 產品非常司空見慣的技術,您也就理所當然要支持的。

以下就是我們的USB 下載傳輸線,我們稱之為 SparkLink 。

當它插入USB 孔之後,他就會自動偵測到您CDI (或ECU )是否存在了。

我想一般所謂的 RS232 轉USB 的標準線就比較難做到這一點了。

另外呢,竟然要搞到專屬的USB HID 傳輸線,我就想順便把一個功能也得做起來了:

看圖示最快:


就是如果我也可以順便讀取一些市售CDI 的進角圖,那不就更方便了嗎?

我也常常開玩笑說:您也不要忽略原廠的部品設定條件,尤其是日本YAMAHA

的引擎設定。人家之所以可以搞到全球小引擎界的大廠也是有兩把刷子的。

先學會尊重國際大廠,您才能做好產品。所以我有另一套所謂的 SparkLink+

的傳輸線可以拿來"逆向"讀取原廠的點火進角設定圖:以下就是以 Super 4 (Jog) 為例: 



所以很快的,我就可以從原廠的設定值裡,讀到原廠在這一棵引擎的原始設定值。

然後,直接複製到我們的平台上,再局部讓我們可以做一些些許的設定改變來探討

這顆引擎的特性。 (點火系統可以,但噴油電腦我認為是不太可能用這一招的啦!)

注意喔~我們搞可程式化CDI 不是在凸顯自己本身產品的優勢,而是想去協助客人

或市場有更大的發展空間。這一部份稍後我會再舉另一個明顯的例子。


------
至於這樣的平台,未來我就可以馬上擴充為 ECU 的發展平台了。

而在許多很傳統的CDI 開發過程中,我們也得到許多未來可以在ECU 開發中的寶貴經驗,


而這一部份,我們也將陸續跟各位說明。我想這一個簡單的可程式化CDI 算是

一個承先啟後中很重要的小引擎控制發展開發平台。這應該也算可能是得獎的一個因素吧。

-----

好吧,最後再來點出這個產品的另一個重要特色。之前所說的這些基本可程式化 CDI 功能

我個人認為也沒有比較特別的地方,會得獎或是在會場會得到國外買家目光的應該

是以下要說的幾個部分:

第一個是:不知道各位有沒有發現,我在點火角度監控方面的點火角度顯示是以

小數點為單位的。所以代表我這個點火角度控制是計算到小數點的。而不是外面

那一種最小是 ± 1度的。這就我說的。這裡面是有一套特殊的數學演算法的這可以

明明讓您是用 1 度 1度的調點火角度,但實際在控制輸出上可以真正達到小數點

完全可以達到機械特性上的平順感。我相信這一點可以讓我在ECU 開發中可以直接

沿用的!

第二個就是他也支持所謂的 TPS (油門位置感測器)輸入功能。市面上有哪些

CDI 有支援 TPS 的?就是YAMAHA 的 GTR (1P3x) 、新勁戰 (4C6x)  與東南亞一款

所謂 LC135 。國內光陽 的LEJ3 與三陽的HEB 。但我對國內這兩款比較沒興趣,

坦白講,這兩款車的進角設定真的有點給他奇怪...這裡就不談了。相對來說

YAMAHA 引擎的點火進角設定範圍廣,所以玩起來的感覺真的比較棒。

---
我們就先來說明一下這個TPS 的作用,很多人都會把TPS 的應用給誤解了。

在引擎控制觀念裡,不管是控制引擎供油或點火,我們所要參考的重要物理參數

是所謂的 Load (負載)觀念。而不是所謂真正的 TPS 。 但是呢,安裝TPS 感測器

卻是比較簡單容易。而TPS 在某種程度是可以模擬成Load 的觀念。...而在噴油系統內,

因為有所謂的MAP (進氣壓力感測器),所以Load 的觀念就被 MAP 給取代了。

TPS 在噴油系統的應用就比較像人機介面的輸入...但很多改裝噴油電腦卻都拿這個

TPS 來當噴油量輸入的一軸...真的怪怪的!如果真的噴油量的計算只靠 TPS 就夠了,

那我就開玩笑說:那噴油系統幹嘛還要花那麼多錢安裝 MAP Sensor 還有 ATEMP

(進氣溫度感測器)呢?那原廠的電腦不就是不懂得 Cost Down 的笨蛋嗎?

這一部份以後有機會再跟各位解釋。

---
但點火系統來說:TPS 的確有他特殊的應用觀念,因為我之前文章中有提到

點火控制對於引擎的影響比較即時,所以藉由 TPS 輸入某種程度也可以適度模擬

Load 改變的特性,而在傳統化油器的供油系統自然會因為引擎的負壓而能適時提供

供油量的改變。所以TPS 在這樣子的應用是可以接受的。也比較簡單就可以達到一定

的效果。所以,您一定要有這樣子的基本概念,您自然就會懂得TPS 的調整與設定方式。

這一部份往後有機會也會陸續說明。

關於原廠有支援TPS 的CDI 我們也可以用同樣的方法把他給"逆向"讀出來:

以下是 GTR 的原廠點火進角圖:

 








以上分別就是不同TPS 開度所讀到的進角圖,但因為是 3D 的進角圖,

所以我們的CDI 設定圖就要改成3D 表格了:


當然這只是約略的轉換設定表格,最終還是要實車驗證一下。不過,依我們的經驗

大概也八九不離十了。後來我們實際配置在實車上,騎了很久也沒啥問題,感覺

真的可以體會到支持TPS CDI 的引擎點火控制,的確與傳統 2D 進角圖不同。 

在這裡順便講個小故事,其實這樣的表格都是我們自己稍微設定一下就當作標準

基本進角設定給客人了...也沒有特殊去做什麼調整。因為真的沒有幾個人會懂得去

調整這樣的表格。有一回有個朋友裝在車上跑去騎幾回....結果突然過了很久也沒回來?

就一直很納悶?他到底騎到哪去了?!....結果等了約半小時他回來了。

一見到我就說:"不錯,我騎到我一位朋友那邊借了廢氣分析儀量了一下。

還過了檢測標準。"...

其實,這才是我們搞這些產品的主要目的:還是要跟原廠理念一樣:

還是多重視環保一下!

最後再提一下關於TPS 的使用觀念。這個觀念在噴油系統裡也是一樣適用的!

在所有噴油系統的眾多感測器裡,就屬這個TPS 沒有什麼物理觀念的!

所謂MAP (進氣壓力感測器),他真的是代表大氣壓力的真實情況,單位是 KPa。

ATEMP (進氣溫度感測器):也是真的代表進氣溫感測器...他的單位是 K ...等等。

您不能亂編或造假...一是一,就是一!計算噴油量就是如此。

但TPS 真的不是...所以在應用上他是以所謂的  % 比為單位的!

很討厭的是...他到底是以誰為基準?所以在應用上它就必須透過一個簡單的自我校正

功能來做歸零動作。那之後,電腦本身就要隨時作自我校正歸零動作!

一般我們俗稱為 Auto Zero 功能。...一種車款只要做一次就行了!



那您問我:如果沒做呢?或是我把 TPS 的訊號給拔掉呢?!會怎樣?

答案是當然電腦本身就會偵測到這個問題,隨即以 MIL (Malfunction Indicate Lamp) 

故障碼燈來提示:

大家可以去查所謂的 OBD-II 的所謂Trouble Codes : 

http://www.obd-codes.com/trouble_codes/   中所謂的 P0122/P0123  或P0222/P0223 。

所以在我這套系統中也會出現  22/23 的故障碼來提示您。

我還是比較喜歡照著標準規格來做,或許是因為我以前搞過USB系統,所以我真的

比較相信老外做事情嚴謹的態度。若當您發生此類故障碼時會怎樣?!

答案當然是:您有標準的偵測條件,當然您就會標準的替代備案(Remedial Action)...

這一部份往後我也會以實際操作範例來說明。

開玩笑...搞引擎控制系統耶!可不是搞一般IT 產品...搞不好是會出事的耶!

別人要怎麼玩,我不管,但我們的系統內...這一種要求是一定要啦。

我之前一直強調一件事:您搞IT 產品,寫控制韌體程式,您要用十根手指頭寫

程式...沒人管你。搞車用電子控制,可不能隨便開玩笑的!...而這一部份不用得

等到做所謂的噴油電腦程式再來說,其實在簡單的可程式化CDI 系統中您就可以

建立起這樣的基本安全觀念了。況且在比較單純架構的CDI 系統內,比較容易釐清

以建立基本引擎控制概念。所以才回應說,不要隨隨便便說:幾年要超英趕美...

您的基礎研究理論有沒有好好建立起來是比較重要的啦!

先分享這一部份給各位。下回待續...



15 則留言:

  1. 1. oversampling 技術可提升AD 取樣到小數點
    2. boot loader 技術可讓使用者更新韌體

    回覆刪除
    回覆
    1. 玩過電動機(馬達)的會很清楚,oversample這招是沒有用的。信號單週內就要決定下一週期的控制,如何用oversample?不如用積分控制。

      刪除
    2. 我想,你說的大概是,不是對輸入信號作 Oversampling ADC,
      而是對輸出作 Delta-Sigma Modulator 積分,常見於 DAC 。
      這的確可以增加輸出精確度到小數點。

      刪除
    3. 我想不管是什麼方法...最主要的觀念還是在於:

      寫程式不能只靠兩隻手,十根手指頭邊想編寫程式。

      尤其像寫這一種車用控制程式,還是要有一些事先前置作業的推導工作。

      我也相信現在在台灣要隨隨便便找個會寫程式的工程師應該都不難。

      只是我們常講的:當您進一行後,如何入一行的在這個領域裡很專業的寫出

      這些領域裡看得懂的東西。...

      說真的啦~大家所講的這些 Oversampling/Boot Loader/ Delta-Sigma .....或許在

      科技界或電子領域裡大家都可以像賣弄學問的講出一大堆理論與道理。

      但是呢?真正應用在車用領域裡...還真的沒有幾個人想去瞭解這些東西。

      反正就是車子玩起來,能順又好用最重要。....

      工程師會這些觀念是應該的,那是為了把東西做好。

      但也不代表您就可以到各個領域裡所向無敵... 也算是我個人一個小小的經驗吧。

      刪除
    4. 看來真的是完全不了解。電動機的驅動信號是隨機械角一直在改變。一直變動的信號取oversample也只有得到平均值。重點在取樣時機,在固定機械角取到的信號反而比較有用。所以一般就取一次,若是要取平均值,我個人則是加長Sampling time而不是使用oversampling。
      另外使用積分式ADC我也做過,變成一種浮動倍率式ADC,原理類似Delta-Sigma,其實就是看了很多次的Delta-Sigma的資料,索性自己做看看,沒想到用軟體也是可以做出來。

      刪除
    5. 提到浮動倍率ADC,個人做過用PGA的,數位電阻式,積分式。都做完一遍後,還將軟體合併。好玩的是真的可以合在同一支程式上。現在MCU ADC幾乎不用錢,會使用的狀況下,可以省下很多電路。再配合數位信號處理程式,往往精度超過原電路設計者預期。

      刪除
    6. Boot Loader實在不想提。用了十年以上,但在PM的要求下已是過度擴張。
      公司要求所有Download方法皆有放入。
      結果有:UART, SPI, USB Device, USB Host(Disk), SPI Flash(Buffer), SD Card(Buffer)
      Boot Loader成長到128KB。
      我還想設計16KB程式空間內解決SD卡更新。結果看到MCU支援Quad-Spi Flash上執行程式。
      一看就知道,不用在Boot Loader上花功夫了。反正MCU內部Flash整個都當Boot Loader也沒有差了。
      應用程式直接燒在Quad-Spi Flash上執行就好了。
      Boot Loader小型式時代也過去了。不要太著墨在上面的發展。

      刪除
    7. 現在比Boot Loader重要的是放入小型Interpreter。用來做動態程式發展及除錯。
      因為程式空間因Quad-Spi Flash得到解放。所以可以放入小型Interpreter。
      目前還沒有試驗在quad-spi Flash上做函式編譯。在編在RAM上執行是沒有問題,過去是因空間太小無法有效使用。
      若是可以成功,使用者界面就可以由客戶自行去修改了。

      刪除
    8. 說真的啦~我實在不想在這樣子的標題文章裡,在討論這些所謂 Firmware 小細節。

      我承認:在科技業裡就您所說的,千百種 Boot Loader 方式或架構如何?!

      我們會覺得很訝異嗎?!那不是好的產品技術規劃,那只不過在操勞或折磨工程師而已。

      看看世上好的產品或一流品牌的產品,有人像我們這一種玩法嗎?!

      您說:一棵人造衛星打上太空,還要在那邊一天到晚改Boot Loader的方式嗎?!

      這都在在的凸顯說:整天瞎忙,窮忙的搞技術。這就是我們台灣許多科技的縮影。

      如果是這一種天天改規格,常常換架構...都只是因為客人隨便一句話。連自己為什麼

      要這麼聽客人說的?!那就讓您十年磨一劍,磨的也只不夠是廚房裡的刀劍而已。

      ----
      我之前不是舉過一個例子嗎?!為什麼您在專業領域裡真的有磨出一套理論基礎或經驗法則。

      那您為什麼還要一天到晚在找新的MCU 或新的方案來搞產品開發呢?!

      難道您所謂十年磨一劍的道理,都是架構在這些所謂的新的MCU 或新IC 方案上嗎?!

      為什麼不是人家來找您合作開新MCU或新的解決方案?

      想一想:我們搞技術搞這麼多年了,無非就是想找回屬於工程師的那一份尊嚴與自信?

      也就是有沒有機會自己來訂產品規格?讓別人來相信您的專業是值得依賴的!

      以前幹工程師都一直很羨慕人家為什麼可以開規格?訂規格?不就是人家的技術層次

      已經可以放眼天下的獨到見解了。....那不就我們幹工程師一生的目標嗎?

      就是因為我們有了可以訂規格的能力,所以可以去作自己想作的事物...

      這也不就是屬於我們自己的尊嚴嗎?!....

      我最近常想:小孩子時,要好好的用功讀書,畢了業就好好從基層工程師做起...

      結了婚就要好好當人家的好老公,養育小孩....。

      每一個階段都有屬於那一個階段該作的事情,因為那是不同的年紀有不同的責任與目標。

      那很簡單....作那麼多年了,我為什麼還要在這裡跟您研究討論哪一種Boot Loader 或

      哪一種MCU 比較好用?!.......
      ----

      不好意思喔~好像有點情緒反應喔!...但有時要想一想:就像這一次得獎一樣,

      那真的是我一個人獨力完成的產品與作品。我到底是應該感到高興呢?還是難過?!

      還是我更應該往前看才對?!--- 我想這才是我比較想知道的事情。

      刪除
    9. 這種感覺好像 AK-47 (公差大) v.s M-16 (公差小) 到底哪一把好用 ?
      在 Vietnam 就拿 AK-47,在 Afghanistan 就拿 M-16.

      刪除
  2. 不是公差問題。我換個方法來描述。ADC取oversample真的不是萬能。我以MCU取聲音取樣,MIC有效頻寬大約26KHz,信號跳動率很高,oversample會濾除高頻。另外個是開高取樣率,RAM也不足。要是後面又掛上FFT做頻譜分析,也沒有多的執行力去做oversample計算。產品要處理的事一堆,使用適度的精度及執行力很重要,要平衡,不是一招用到底。

    回覆刪除
  3. 衛星使用Forth語言,確實沒有Boot Loader。可以一邊工作,一邊加新程式。我目前是以Forth語言做為小型Interpreter做為MCU內建指令系統。以MCU來說,一邊工作,一邊加程式並回報新程式執行狀況並不是新技術。實際上是一種被一般人忘記的技術。個人在十年前看到有人在8051上一邊執行,一邊加入新程式,實感訝異,才知原來人外有人天外有天。去要來原始碼及燒錄檔,一看才16KB燒錄檔。16KB內含有語言及作業系統對很多人來說根本不可能。也是因為看到無法相信的技術,才知自己對MCU了解實在太少。
    現在,我很少找新MCU,基本上新MCU的功能只要一天就看會了。比較多的時間在想新應用或對於MCU生態的影響。反正價格已是低到不行,何不用新的?

    回覆刪除
  4. 來函轉貼!

    匿名 已針對您的文章「得獎產品(CDI) 背後的開發故事(一)」留下新意見:

    蜂兄之說,很厚實建全
    賈公之述,很務實靈活

    我對Forth的觀點:
    向上看:把硬體,軟體化==>可把各異質CPU同化成一個同質虛擬CPU,用Forth 高階指令包裝各異質的實體CPU機械碼Machine Code(各自的指令集)
    向下看:把軟體,硬體化==>所以可以得到最精簡的OS作業系統(包括最簡統系統工具集),包括互動式交談介面(直譯器Interpreter)及預編式編程(編譯器compiler)

    最佳實例: eForth 整個系統不到 3K Bytes(丁陳 博士有PC版及51版)

    苦工人主 小P

    回覆刪除
  5. 來函轉貼:

    匿名 已針對您的文章「機車整流器的設計故事(一)」留下新意見:

    最近留語言功能怪怪的,一直無法成功留言.

    由 匿名 於 2015年5月13日 下午11:57 張貼在 ChamberPlus System Level Studio

    回覆刪除