ZED BoardでPLを自作した場合のDMAのやりかた

ZED Boardで、AXI HighPerformance Portを通じて、PLからPSのDDR3 SDRAMにアクセスするハードウェアを以前作りました。

HPポートを通じてPLからDDR3にアクセスすれば、DMAができるわけです。

OSを使わないStandAloneなプログラムで動いている場合はそれほど難しくなかったのですが、Linuxが動かそうとしてカスタマイズしたPLのBitStreamを埋め込んだboot.binで起動しようとすると、Linuxがパニックを起こしてハングしてしまいます。

で、ついに、当社の優秀なスタッフが、ZED BoardでのDMAを実現してくれました。そのやり方を簡単にまとめると・・

1. 基本的に、ZED BoardのDeviceTree(dtbファイル)を逆変換してソース(dtsファイル)を作り、編集してdtbに変換することでカスタマイズDeviceTreeを作る。
2. PLをカスタマイズしたBitStreamでLinuxを起動させようとすると、起動中にqspiがどうの、というメッセージが出て止まってしまう。これを回避するには、devicetreeの、ps7_qspi_0にbus-num = <0>;を追加すればOK。
3. ファイルシステムのエラーを回避するには、bootargsにroot=/dev/ram rw initrd=0x800000,8M earlyprintk rootfstype=ext4 rootwait devtmpfs.mount=0を追加する。
4. bootargsにmem=128Mを追加する。これで、Linuxが使用するメモリを128MBに抑えるることができ、0x08000000～0x1fffffffはLinuxの管理外になるので、FPGAから自由に使用できるようになる。
5. AXIスレーブとして作った制御レジスタがある場合、DeviceTreeからaxi_ext_slave_conn…(0xB8800000～)のような記述は削除する。これを削除しないと、キャッシュが効いてしまうので正しくアクセスできない。
6. ZED Boardでは物理アドレス0x08000000～0x1fffffffにはDDR3 SDRAMが配置されている。LinuxのプログラムからDDR3を参照するにはmmap()関数を使って、まずこの領域の仮想アドレスを取得する。
   なお、mmap()の前に、open()で/dev/memを開く。メモリの読み書きの同期にはmsync()を使う。最後にmunmap()で解放すること。

こんな手順をふむことで、LinuxからFPGAのPLにアクセスし、DMAを行うことができるようになりました。

これで、Linuxのネットワーク機能と、FPGAの高速な演算を使える環境が整いました。

18bit A/D変換ボードの設計完了

2月はいろんな仕事があって、遅れ遅れになっていましたが、18bit ADCボードの設計がようやく出来上がりました。

このボードは、真の18bitの性能を広く世に普及させるために生まれました。適当に作ったのでは決して18bitの性能は出ません。このボードは3か月間、検証を重ね、ノイズを減らす工夫をしてきました。

真の18bit 2Mspsの性能と、最新FPGAでのディジタル信号処理が融合したとき、きっと新しい計測の世界が開けるでしょう。

トラ技ARMライタのCMSIS-DAP&USB-CDCファームウェア

トラ技ARMライタ用のCMSIS-DAP&USB-CDCファームウェアを開発しています。

ついにCMSIS-DAPとUSB-CDC(仮想COMポート)が共存したマルチファンクションデバイスができるようになりました。

LPC11U35に書き込むファームウェアとデバイスドライバのINFファイルを以下においておきます。

「TrgArmWr_beta1.zip」をダウンロード

ただし、現在はまだ作りかけなので、

• ボーレートの変更ができない
• USB→UART方向の転送しかできない

という制約があります。

UART→USB方向の転送はまだできません。

あまり実用的ではないので、急いでアップデートする必要はないと思います。ドライバのインストールは難しいかもしれません。失敗すると元のファームウェアに戻してもドライバを認識させるのが難しいので、本当に急いでアップデートする必要はありません。

---

いままでも、CMSIS-DAPとUSB-CDCを共存させようとしていたのですが、うまく動かずに悩んでいましたが、ようやく原因がわかってきました。

1. HIDはふつうはデバイスドライバが不要なのですが、USB-CDCとのマルチファンクションデバイスにした場合は、CDC側のデバイスドライバがないと、HID側も認識してくれなくなります。
2. 現在はインタフェース0がCDCコントロール、インタフェース1がCDCデータ、インタフェース2がHIDです。マルチファンクションデバイスでCDCのように複数のインタフェースを使うデバイスを作る場合、どこが区切りかわかりません。そこで、IAD（インタフェースアソシエーションディスクリプタ）というのを用意して、2個のインタフェースは同一グループだ、と知らせてやります。
   
3. CDC側のドライバで、INFファイルには、
   %TrgArmWrDesc% = DriverInstall, USB\VID_0D28&PID_0019&MI_00
   というふうに&MI_00をつけます。マルチファンクションデバイスの最初のものという意味なのでしょう。
4. デバイス全体のストリングディスクリプタだけではなく、Interface2のHIDのインタフェースディスクリプタのiInterfaceが挿すストリングディスクリプタを「Toragi-LPC Writer CMSIS-DAP」に変えておかないと、MDK-ARM等がCMSIS-DAPとして探してくれなくなるようです。
   
5. PCに挿すと、Device Qualifierディスクリプタを探しに来てSTALLを返していますが、これは異常ではなく正常な動作でした。STALLで問題ありません。このSTALLを返さないように・・という努力は無駄です。
   

そのような改良を行ったところ、マルチファンクションデバイスとして認識してくれるようになりました。

Artix-7ボードの新リビジョンを製造します

最近、急にArtix-7ボードの出荷件数が増えています！

嬉しいです。

本日、いろいろな会社や個人の方から計8台分の見積もり依頼をいただきました。

2つの商社からほぼ同じ時間に「TKDN-ART7-2を4台」という見積もり依頼をいただきましたが、これはおそらく相見積なので合わせて4個とカウントしています。

現行ロットの残りはあと８台しかありません。きっと、あと数日で完売するでしょう。早い者勝ち状態になっています。

かねてから次期ロットを製造しようとしていたのですが、せっかくなのでいくつか気になっているところ修正しようと思いました。

修正箇所は、

• USBのVBUS用の過電圧保護ICをバイパスできるようにする
• 5Vの電源入力部分にコンデンサを入れて急激な電圧変化に耐えられるようにする
• コンフィグ用のSPI ROMを、SOIC8からMLP8に変更する
• クロックラインをプルダウンする抵抗を入れて、分圧できるようにする

といった点です。

【過電圧保護ICについて】

いま、USB3.0のVBUSには、NCP361とかいう過電圧保護ICを入れています。USBのVBUSは普通は5Vですが、世の中には7Vとかを出してくる凶悪なやつがいるそうです。（粗悪なUSB充電器とか）

そういうものにつないだときに、EZ-USB FX3が壊れないように過電圧保護ICを入れています。NCP361は約5.6V以上になるとシャットダウンしてくれるICです。ですが、このICは500mAしか流せません。

すると、負荷が急激な電流変化を起こす（たとえば、FPGAのコンフィグ時やFX3のRenumeration時）と電圧降下を起こしてしまいます。それを防止するため、現在のArtix-7ボードには5Vのラインに100μFのコンデンサを入れて、この電圧変化に追従できるようにしています。

しかしならが、7Vも出してくる粗悪な充電器をArtix-7ボードにつなぐシチュエーションはあまりないと思います。だから、このICをバイパスできるようにしようと、ジャンパを設けることにしました。バイパスすれば、過電圧保護ICの許容電流をきにせず、USB3.0の限界まで電流を取り出せるようになるのですから。

【SPI ROMの入手について】

コンフィグ用のSPI ROMには、現在はMicronのN25Q128A11ESE40FというSPI ROMを使っています。このSPI ROMは128Mbitで、1.8Vの電源電圧で動作し、SOIC8ピンです。

ところが、人気のROMなのか、世界中のディストリビュータから在庫が消えてしまいました。チップワンとかいう商社に注文した分は「やっぱり在庫がありませんでした」メールが送られてきました。やっぱり、この商社はチップストップですね。

Newarkというところに在庫があったので注文したのですが、1か月くらい動きがありません。問い合わせても「イギリス在庫だから3週間くらいかかる」というわけのわからない回答があったので3週間待ったのですが、ステータスに変化はありません。

Digikeyに発注していた分でさえも、突然、「出荷できなくなりました。ごめんなさい」メールが来ました。

・・・

本当に入手できなくなってしまったようです。

・・・

途方に暮れていたのですが、2つの代替方法があることに気が付きました。

SOIC8ではなく、MLP8のN25Q128A11EF840EならDigikeyに在庫があります。

また、SpansionのS25FS128SAGMFI101というのがUSのDigikeyにありました。（今はもうない） S25FSはiMPACTも対応しているらしいので、これを購入して試してみたのですが、なんかiMPACTはダメっぽいです。

そこで、次のロットではMLP8のN25Q128A11EF840Eで作ることにしました。とりあえずDigiekyで60個を確保しておきました。これで1～2か月は持つはずです。

【露出パッドについて】

MLP8パッケージは露出パッドがあります。だから、基板を作り直さなければなりません。データシートによれば露出パッドは内部でGNDにPULLされているから他の電位につなぐな、と書かれています。テスターで測ったところ、露出パッドとGNDとの間の抵抗値は0.8MΩくらいでした。

露出パッド≠GNDでした。GNDに直結しているわけではないようです。

【基板屋さんにデータを送ってみたら・・】

基本的に現在のArtix-7ボードの改版なので、ほとんど同じパターンのはずなのですが「ギャップが狭い箇所があるので作れない」という電話が来ました。

こういう箇所なので、同電位なので問題ないのですが、

今回の担当者さんには気になったのでしょう。

そういうわけで、1日追加になりました。

次のArtix-7のロットは3月頭に基板が出来上がってきて、3月8日くらいに実装が上がって、出荷可能になると思います。

ZED BoardのプログラムをFlashAir経由で書き換える(続き)

Flash Airを使ってZEDボードの書き換えをしようとしています。Flash Airとは、東芝のWi-Fi内蔵SDカードです。

前回のブログでは不安定だったと書きましたが、どうやらjquery.jsが入っていなかったためでした。一度ファイルシステムが壊れてしまったときに消えてしまったようです。

upload.cgiでファイルを転送した後にSDカード側から書き換えるのはとても危険ですね。FlashAirの本来の使い方はSDカード側から書き込んで、Wi-Fi側は読み出し専用にするべきということなのでしょう。つまり、デジカメの画像閲覧と。

それで、できあがった最終的なFlashAirのソースはこちら。これをList.htmとしてSD_WLANフォルダの中に入れてください。

<!doctype html>
<html>
<head>
<title>FlashAir</title>
<meta charset="UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="copyright" content="(c) 2013, Fixstars Corporation. All rights reserved.">
<meta name="copyright" content="(c) 2013, Nahitafu.">
<meta name="author" content="Ryuji Naitou">
<script type="text/javascript" src="/SD_WLAN/js/jquery.js"></script>
<script type="text/javascript" src="/SD_WLAN/js/main.js"></script>
</head>
<body>
<div id="header">
<h1>FlashAirでZED Board書き込み</h1>
<div style="font-size:small">
By なひたふ  詳細はこちら→<a HREF="http://nahitafu.cocolog-nifty.com/nahitafu/2014/02/zed-boardflas-1.html">http://nahitafu.cocolog-nifty.com/nahitafu/2014/02/zed-boardflas-1.html</a>
</div>
<hr>
<h2>現在のファイル一覧</h2>
<div id="list">
</div>
<hr>
<h2>Boot.binのアップロード</h2>
    アップロードしたいファイルを選んでください<br>
    <input type="file" id='file' name='file' style='width:480px'><br>
    <button id="cmdUpload">Upload</button>
<div id="footer" style="font-size:small">
<hr>
素敵なZYNQライフを
</div>
</body>
</html>

それから、SD_WLANフォルダにjsフォルダを作って、FlashAirチュートリアルの中のadvanced_tutorial_02.zipの中にあるmain.jsと、http://jquery.com/download/にあるjquery-1.11.0.min.jsをjquery.jsにリネームして入れます。

なお、Flash Airには２種類のバージョンがあるようで、下記の写真で見て右上にW-02と書かれたFlash Airで使えると思います。

http://www.amazon.co.jp/s/ref=nb_sb_noss?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&url=search-alias%3Delectronics&field-keywords=Flash+Air+

また、FlashAIRのCONFIGファイルは前回のブログを参照してください。

<hr>

いまデバッグしているボードはこんな感じです。

ZEDボードのメザニンに拡張ボードをつないでいるので、ZEDボード裏面にあるSDカードの抜き差しがとても面倒です。そこで、FlashAirを使って・・

Web経由でboot.binの転送ができるようになりました。

これで快適なZYNQライフが愉しめそうです。

ZED BoardのプログラムをFlashAir経由で書き換える

  ZED Boardはプログラムの書き換えが面倒です。

SDカードにboot.binを書いて、挿して、書いて、挿して・・の繰り返し。しかもSDカードソケットが基板の裏にあるのもいやな感じです。

この作業を避けるために、東芝のFlashAirというSDカード型無線LANを使ってみることにしまいた。

しかし、最初にハマったことは、SSIDなどを設定しても、無線LANから認識されない・・。どうやらデフォルトでは無線LANのアクセスポイントになっているみたいです。要するに親機になっています。

下記のドキュメントを見ながら、子機モード（ステーションモード）に変更します。

https://flashair-developers.com/ja/documents/tutorials/advanced/1/

で、たまたまなのかよくわかりませんが、APPNAMEに大文字が入っていると名前でアクセスできなかったりとか、いろいろてこずりました。結局CONFIGファイルは以下のようになりました。

[Vendor]

APPMODE=5
APPNAME=zynqcard
APPSSID=JITAKU
APPNETWORKKEY=*********
APPAUTOTIME=30000000
APPINFO=0123ABCD4567EFGH
CIPATH=/DCIM/100__TSB/FA000001.JPG
VERSION=F19BAW3AW2.00.01
CID=*******************************
PRODUCT=FlashAir
VENDOR=TOSHIBA
MASTERCODE=************
UPLOAD=1
DNSMODE=1
LOCK=1

これでようやく無線LANの子機として認識されるようになりました。IPアドレスはDHCPで割り当てられるようで、固定IPにする方法はわかりませんでした。

さて、FlashAirに無線LAN経由でファイル共有して、boot.binを送り込みたいところなのですが、それはなぜかできませんでした。\\zynqcardとやっても出てきません。

仕方ないので、FlashAirのAPIにあるupload.cgiというのを使うことにしました。FlashAir Developersのチュートリアルの中にFlashAirへのアップロードというページがあるので、ここにあるadvanced_tutorial_02.zipを解凍して、List.htmとjsフォルダを、SD_WLANフォルダの中に放り込みます。

すると、デフォルトの画面がこう変わります。

さすがに素朴すぎるので、2時間くらいかけてBootStrapで綺麗に作り直していたらカードの抜き差しに失敗して全部消えてしまいました。この画面をこだわっても意味がないので、タイトルの文言を変えるくらいにしておいたほうがいいでしょう。

これでブラウザ経由でboot.binを送り込めるようになりました。ただし、upload.cgi経由で送り込んだプログラムはWindowsにUSBメモリとして認識されているSDカード側からは更新されていないように見えてしまうので、非常に危険な状態です。このままWindows側から書き換えたりすると壊れてしまうようです。

実際にZED Boardを起動して、boot.binを書き換えて、PS-RSTをやってみると、

ちゃんと新しく送り込んだプログラムで動作するようになります。無線LANのせいなのか、ZYNQのリセットのせいなのか、まだ不安定な感じがします。

少しでも抜き差しの手間から解放されれば・・と思ってやっていた作業ですが、FlashAirと格闘するのに4時間くらい費やしてしまったので、トータルでは時間的に損したかもしれません。

続きはこちら

トラ技ARMライタは速いのか、遅いのか、

私、なひたふが書いたトラ技ARMライタの記事がトラ技3月号に掲載されました。
※ちなみに、基板を設計したのは私ではありません。

久々の寄稿なので、記事が載るのは嬉しいものです。こっ恥ずかしいのでまだ読んでいませんが。

トラ技ARMライタはCMSIS-DAPをLPC11U35に移植したもので、中身はふつうのCMSIS-DAPです。

Twitterでとんすけさんという方から、STM32F4へのダウンロードが遅いというご指摘があったので、このCMSIS-DAPの速度を測ってみました。

まず、トラ技ARMライタにSTM32F3Discoveryをつなぎます。そして、uVision4を使って適当なサンプルプロジェクトをビルドし、デバッガを起動します。

そのときのパケットをキャプチャしてみました。

CMSIS-DAPのプロトコルでは、データ転送は0x05か、または0x06というコマンドが使われます。0x05はいろいろなレジスタに値を設定したりマスク値を登録したりするときに使われます。0x06は1つのレジスタにたくさんのデータを転送することができるので、こちらのほうが若干高速なはずです。

上のuVision4のパケットでは0x06のほうを使っているようです。

しかし、CMSIS-DAPは、HIDというプロトコルのレポートというパケットに乗せて送っています。このレポートは最短2msの間隔でしか出すことができないようで、しかも、1つのレポートは64バイトなので14個のDWORDしか入りません。

したがって、14×4Byte÷0.002秒 = 28kB/secというのが理論的な最高速度になるはずです。

これは、トラ技ARMライタが悪いのではなく、CMSIS-DAPがHIDに乗せて送るという仕様に由来するボトルネックです。

もちろん、HIDのレポートのサイズを大きくしたり間隔を縮めるようなディスクリプタにすればもっと速くできるかもしれませんが、ホストのソフトが対応していなければなりませんので、たぶんダメでしょう。MDK-ARMもLPCXpressoも、CMSIS-DAPへの対応はまだ完全ではないので、そういう裏技的なことをしたらたぶん動かないと予想されます。

ちなみに、ULINK/MEのパケットも見てみましたが、やはりHIDを使っていて64Byte単位なので、似たり寄ったりだと思います。OUTパケットの間隔が3msなので、CMSIS-DAPより遅いかもしれません。

ST-Linkは、HIDではなくVendor定義のクラスになっています。64B固定ではないので、ちょっと速度が期待できるかもしれません。

結論を言うと、uVision4やLPCXpressoからトラ技ARMライタ（CMSIS-DAP）を使った場合は28kB/sは達成できると思います。

ただ、OpenOCDから使った場合はわかりません。1MiBのダウンロードに8分以上かかったという報告もいただいているので、OpenOCDからCMSIS-DAPに、ブロック転送を使わずに1WORDずつ送っているのかもしれません。

◆追記

その後、とんすけさんのツイートにより、OpenOCD&CMSIS-DAPの転送速度は2kB/sという情報をいただきました。MDK-ARM&CMSIS-DAPのちょうど14分の1になので、ブロック転送を使わずに1Wordずつ送っている可能性が濃厚です。

トラ技ARMライタ基板のJTAGを触ってみた結果

トラ技ARMライタ基板にはNXP社のLPC11U35が乗っています。

このLPC11U35はJTAGインタフェースを持っていて、バウンダリスキャンにも対応しているようです。このICの動作はJTAGバウンダリスキャンで見たり、操作したりできるでしょうか？

では、さっそくやってみることにしましょう。

まず、トラ技ARMライタにピンを立てます。ピン配置は、

• 1-GND
• 4-RESET
• 7-TCK
• 15-TDI
• 16-TMS
• 17-TDO
• 18-TRST
• 40-VCC(3.3V)

のようです。ピンをはんだ付けすると、こうなりました。

そして、バウンダリスキャンツールのMITOUJTAGを起動します。自動認識ってやってみると・・「 自動認識を行いましたが、JTAGデバイスが見つかりませんでした」と出て検出されません。

なるほど。わかりました。このLPC11U35のJTAGを使うには、2つの原則があります。

1. フラッシュROMにユーザコードが書き込まれていてはいけない
2. RESET端子はLowでなければならない

そこで、デバッガを使ってフラッシュROMを綺麗に消し去ります。そして、RESET端子をHighにした後、Lowに引っ張って、再び自動認識してみると・・

やった！検出されました。でも、検出されたデバイスの型番が違う・・・

とりあえず、「はい」を押します。

いろいろな候補が出てきました。

なるほどNXPさんのARMは、どれもこれもJTAGのIDCODEが一緒なのですね！LPC11UｘｘもLPC800も全部同じ x000002Bになっている。だから電気的に区別できない。

とりあえず、LPC11Uxx_Rev_B_HVQFN33_v00.bsdlを選びます。すると・・

ちゃんと認識されました。

このトラ技ARMライタ基板の2つのLEDは、ピン7とピン12につながっているようです。そこで、EXTESTモードにして、これらのピンをカチカチしてみます。

当然ながら、基板上のLEDが光りました。これらの端子からLを出力すると、LEDが光るようです。

そこで、for文のループの中で回す簡単なスクリプトを書いたら、

JEXPORT int jmain() {
	j_bypass();
	j_sample();j_extest(); // AJFGで端子を操作するにはこの行を有効にしてください
	for(int i=0;i<1000;i++)
	{
		PIO0_21_CT16B1_MAT0_SSP1_MOSI  = ((i & 1) ? 1 : 0);
		PIO0_20_CT16B1_CAP0           <= ((i & 2) ? 1 : 0);
		Sleep(100);
	}
	return 0;
}

JTAGでLEDチカチカができました。波形で見てみましょう。

ISPと書かれたプッシュスイッチを押すと3番ピンと8番ピンが反応しています（上の波形の下２個）。それ以外のピンが動いているのは、すべてのピンが入力でプルアップ等がされていないからだと思われます。

最初は全く認識されなくて焦ったLPC11U35ですが、最後にJTAGを使うときの注意点をまとめておきます。

• JTAGを使うには、フラッシュROMは空で、RESETはLowにしなければならない。
• プログラムが動いている状態では、バウンダリスキャンも、デバッグ機能も使えない。
• JTAGを使ってデバッグはできない。デバッグに使えるのはSWDのみである。

ということです。

18bitA/Dボードの再設計

これまで約2か月間、検証を重ねてきたAD7986 18bit ADCボードは、

• 1LSB=約30uV。ノイズは1.5LSB程度（A/D変換器自体の性能）。S/N比は約100dB。
• 可変ゲインプリアンプを1000倍に設定にすれば、1LSB=約30nVまで可能。
• プリアンプ部のひずみ率は-95dB以下。
• サンプリング周波数は2MHz

という性能が達成できました。

機能としては、

• FPGAに直接取り込んでフィルタリングなどのディジタル処理が可能
• USB2.0またはUSB3.0インタフェースで取り込み可能（ソフトウェアも付属）
• 低消費電力

これまでの検証結果を反映するべく設計をやりなおしています。

改良点は以下のとおり。

• アナログの差動信号を受け入れられるよう、ゲイン可変差動入力OPアンプを追加
• ADCの入力に過電圧保護ダイオードを追加
• ADCに与える差動入力のコモン電圧を2.5Vにする
• DAC出力のOPアンプの接続方法を変えて、-2.5～2.5V出力可能にする
• 絶縁型バッファを取り除き、普通の2電源バッファに置き換える
• 基板の層数を4層にする
• アナログ入力の入力抵抗(50Ω)を、ジャンパでON/OFFできるようにする
• 電源IC(LT3439EFE)のGNDをつなぎ忘れていた問題の修正
• 2.5V電圧リファレンスの出力にOPアンプを追加（ただしジャンパ可能）

月曜日に1日で再設計できるかな・・と思ったのですが、とても無理でした。

水曜日に出図をし2月中の発売を目指します。価格は約6万円を目指します。

1000倍の可変ゲインアンプを18bit ADCにつないでみる

AnalogDevicesからAD8253ARMZという可変ゲインアンプが出ています。

AD8253ARMZは、差動入力のインスツルメンテーションアンプで、ゲインはx1、x10、x100、x1000と、プログラマブルです。ゲインの変更はA0とA1という2本のディジタル信号で設定するようになっています。

計測用のADCを作っているので、ゲインはやはり可変であったほうが良いので、このアンプを18bit ADCにつないでみることにしました。

このように秋月のピッチ変換基板を用いて実装し、数cmの配線を引き延ばしてつないでいます。拡大すると、

こんなふうになっています。

さて、さっそくゲインを1000倍(+60dB)にして無信号時の波形を取ってみました。

約50mVの振幅で揺れています。ゲインが1000倍なので、この元の信号は50μVだったはずです。実は、これはスイッチング電源から飛んでくるノイズです。

ゲインを変えて周波数解析してみると、ピークの周波数は40kHzくらいのところにあることがわかります。ゲインを1000倍(+60dB)にしてもそれほど大きなノイズは見えてきません。

ゲインx1のときには50μVくらいのノイズがもともとあって、それは18bit ADCでの約1LSBに相当します。ゲインx1000にすると50mV(1000LSBくらい)くらいと考えるとつじつまがあいます。

50μVくらいのノイズがもとからあるのでは、1000倍する意味がありません。OPアンプの熱雑音もそれくらいなのですが、あきらかに特定の周波数で来ています。したがって、このノイズを減らす必要があります。

ピッチ変換基板を空中配線でつないでいるのがノイズの原因かもしれないので、電源にOSコンデンサをつないだり指で押さえたりしていたら、

1000倍増幅後のノイズの振幅は15mVくらいまでに減りました。周波数解析をしてみると、40kHzの成分は-83dBくらいにまで減りました。FFT解析しても際立ったピークが見えているわけではなくなりました。

つまり、このスイッチング電源からのノイズはおそらく空間を飛んできているのであって、適当につないだリード線が拾ってしまっているのでしょう。だから基板をしっかり作れば削減可能と思われます。

AD8253ARMZは大変すばらしいアンプなのですが、4つほど欠点があります。

1. ゲイン1では電圧換算ノイズが40nV/√Hzもある。これは18bit ADCの1LSBに相当する。ゲイン10以上では10nV/√Hzと小さいが。
2. ひずみ率は-110dBと書かれているが、データシート上のグラフでは-87dBくらいに見える。よくわからない。
3. せっかく差動入力なのに、出力はシングルエンド
4. 入力バイアス電流はGNDに逃さなければならない。浮かせていてはいけない。

なので、現在採用しているOPA211AIDRのほうがよさそうです。ただ、ゲイン可変というのは魅力的なので、OPA211AIDRとAD8253ARMZを両方のせるのが良いのかもしれません。

• 低ノイズ・低ひずみの測定をしたいなら、OPA211AIDRを使う。
• nVオーダーの測定をしたいならAD8253ARMZで増幅しておく
• 高インピーダンスの差動入力にしたいならAD8253ARMZ
• 低インピーダンスの差動入力でよいならTHS4521

こういったのを選択できるような回路構成が良いのか・・

ただ、18bit ADCの分解能は30μVなので、これをADCボード上で1000倍に増幅して30nVが見えるかというと、それは難しいと思います。nVオーダーを測りたいなら、センサ側であらかじめ増幅しておくべきだと思います。

うーん、悩ましい。

状態変数型の発振器と18bit ADC

今週の水曜日に、優秀なスタッフが状態変数型の発振器をサクッと作ってくれました。

18bit ADCの特性を見てみたいと思ったときに、市販のDDS型のファンクションジェネレータではひずみが大きいので、正弦波発振器がほしかったのです。

そこで、「トラ技などのバックナンバーを見て作って」と頼んだら、わずか半日で作ってくれました。いつも予想よりも短い時間で作ってくれます。

それを今日、ようやく試してみることができました。

上の写真の左下に映っているのがその発振器です。電池で動きます。

これはトラ技2003年7月号に乗っていた馬場清太郎さんの記事の回路を作ったものです。馬場さんの記事ではNJM4580だったので、周波数が1kHzで設計されていました。

今回は20kHzで発振させたかったので、周波数特性がよさそうで秋月で売っていたLME49860を選び、定数も計算しなおして変更したとのことです。

まず、オシロで見た波形。綺麗な正弦波に見えています。

ただし振幅が8Vもあります。もともと馬場さんの回路のとおりなのですが、ちょっと大きすぎるので、減らしました。

ADCで取り込んだ波形がこちら。

2.4Vくらいに減っています。そして、これをFFTすると・・

なんと、基本波の-26dBに対して３次高調波は-123dB。５次高調波も-123dB!!

97dBも下がっています。-97dBcということなのでしょう。

馬場さんの記事では『8V_RMS出力時のひずみ率は0.0005%です。』ってさらっと書いてあるので、理想的には-100dBというわけです。無調整でそれに近い値が出ているのはすごいと思います。FETの最適な動作点を探したり、コンデンサやOPアンプを取り換えていけば達成できるかもしれません。馬場さんの回路すごい。

で、この0.0005%という値がどこから出てきたのかということなのですが、NJM4580のデータシートには1kHzでのひずみ率が0.0005%というグラフが描かれているので、おそらくその値なのでしょう。

ひずみが、発振器によるものなのか、ADCボード上のプリアンプなのかを切り分けるのが大変です。

今回の回路で発振器に使ったLME49860のひずみ率は0.00003%。なんと-130dBcです。

ADCボードにはOPA211とTHS4521という2つのOPアンプが乗っています。OPA211のひずみ率は、負荷が軽ければ-130dBくらいです。だから無視してよい。THS4521の3次ひずみは、20kHzでの規定は書かれていませんが、おそらく-110dBcくらいだと思います。

だから、得られた-97dBcという性能が、発振回路の問題なのか、THS4521によるひずみなのかはわかりまりません。

ちなみに、発振器を外した状態ではこんな感じなので、同軸ケーブル等が特にノイズは拾っているということはなさそうです。

オーディオマニアの人が低ひずみの発振器をこだわって自作する気分が少しだけわかりました。

P.S.　あらためて2003年7月のトラ技を読み返してみると、昔のトラ技はめちゃくちゃ面白い。今のも面白いけど。

P.S.2　OPアンプの出力にLPFを入れてからADCボードにつないだりすると、逆にひずみが増えた。軽い負荷で動かすのが良いみたいだ。