ArduinoIDEから生AVRマイコンに書き込み

Arduinoのスケッチを、工場出荷状態（ブートローダなし）の生AVRマイコンに書き込む手順を確認してみました。先人の情報によりArduinoIDEから違和感なく書き込みできるようになりました。

事前準備
ArduinoIDEには、"書込装置を使って書き込む"というメニューがありますがやってみると失敗してしまいます。ファイル⇒環境設定で"より詳細な情報を表示する"にチェックを入れて確認するとavrdudeのエラーが出ています。

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch
         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
         Using Port                    : usb
         Using Programmer              : stk500v2
スケッチの書き込み中にエラーが発生しました
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
avrdude done.  Thank you.

これはAtmel Studio 7.0とセットでArduinoIDEと互換性のないJungoドライバがインストールされてしまうことが原因で、ArduinoIDEがAVRISP MK IIを認識できない状態のようです。
解決策として、Jungoドライバと共存できるようにlibusb-win32ドライバをインストールします。AVRISP mkII を接続したままlibusb-win32-devel-filter-1.2.6.0.exeを実行。ウィザードの最終段階でLaunch filter installer wizardにチェック。Install a device filterとして、リストからAVRISP mkIIを指定してインストールします。（参考記事1、参考記事2）

ArduinoIDE/AVRISP mkIIを使ったスケッチの書き込み

さらに、kosakalabの開発環境を導入してデバイスを選んで開発できるようにしてみました。ここでは、デバイスとしてATmega328、クロックは内蔵8MHzを指定しています。この段階ではヒューズビットの書き換えまでは反映していません。

ArduinoIDE/AVRISP mkIIを使ったヒューズビットの書き換え

kosakalabの開発環境では、ツール⇒ブートローダを書き込む とすると、ダミー操作のブートローダ書込を行った後にヒューズビットの書き換えとプログラムの消去が行われます。このため改めてプログラムを書き込む操作が必要です。

互換基板でArduinoを試す

食わず嫌いだったArduinoを試してみます。いきなり互換基板から入るのもどうかと思いますが、たまたま手元にあったArduino UNO R3互換の中国製NHduino UNO基板でまずはLチカしてみることにしました。Windows10ならUSBシリアルI/F CH340Gのドライバはあっさりと自動認識してくれましたし、電源はUSB給電だしラクで良いです。

Arduino IDEをインストールして、、、
よくある解説通りにファイル⇒スケッチ例⇒01.Basics⇒Blink

次にターゲット基板を指定しましょう。ツール⇒ボード としたら、既にArduino/Genuino UNOが選択されていました。また、デバイスマネージャによるとCH340GはCOM3として認識されているので、シリアルポートをそれに合わせます。

次にプログラムを書き込んでみます。右矢印をクリック（スケッチ⇒マイコンボードに書き込む Ctrl+U と同じ）するとコンパイルされたプログラムがUSBシリアルを通じて書き込まれます。Lチカのサンプルもあっさり動作。これは簡単です！

オーダーメイド枕で熟睡感を実感

このところどうも寝付きが良くありません。いびきをかいているようだし、良い睡眠がとれていない気がします。前から気になってましたが、息苦しくなって目が覚めたり朝になると枕を押しのけてうつぶせ寝をしています。これはひょっとして枕が合っていないのではないか、というわけで家人が愛用しているオーダーメイド枕を自分でも試してみることにしました。

・・・結果は、途中で目が覚めることもありませんし、何より朝になっても枕の上でちゃんと寝てる自分にびっくりでした。さらに特筆すべきは、横向きの寝やすさでしょうか。ベストな高さに調節しているから当然なんですが、今までの低反発枕では得られない使い心地です。
購入以来毎日、熟睡感を実感しています。これが睡眠の本来の姿なのかと思いますが、今までは何だったのかという思いです。枕の影響は大きいものなんですね、これほど効果があるとは予想外でした。

枕は、山形県天童市の天童プップで購入したものです。私は店頭に出向きましたが、Webを見ると通販が主力のようです。オーダーメイドですが身体に合わせて1時間ほどかけて丁寧に調整してくれます。枕そのものはシンプルな構造で、内部の4つの袋に入れるポリエチレンビーズの量を5グラム単位で調節してくれました。

地上デジタル放送のパイロット信号

地デジのパイロット信号のことがブログ記事に書かれていました。地デジのスペクトルは、台形の形をしていてスペアナでズームアップしてみてもノイズのようなものが見えるばかり。ほんとうにそれが見えるのか試してみました。
スペアナを所定の周波数にセットしてズームアップすると、13chの台形スペクトルの上端にそのパイロット信号らしきモノが見えます。アベレージングをかけると確かにキャリアが浮かび上がってきました。

ARIBの標準規格 STD-B31 地上デジタルテレビジョン放送の伝送方式 を紐解いて頑張って調べたところ、これはCP(Continual Pilot)という受信機の同期・復調用の信号だとわかりました。（ARIBの規格書、以前は自由にダウンロードできたのに今は有料になってます）さて、前述のブログ記事には、

上端パイロット信号は公称周波数+39/14MHz（+2.785714MHz）

とあります。これをARIBの規格書で調べてみましょう。
地デジのキャリア総数は5617。上端のキャリアは地デジの公称周波数から高い方へ（5617-1）/2 = 2808本目。
ここで地デジのセグメント帯域幅は6MHz/14≒428.571kHz。キャリアの周波数間隔はセグメント帯域幅の432分の1なので、428.571kHz/432≒0.992kHzです。
つまり上端キャリアの周波数は、地デジの公称周波数から (6/14) / 432 × 2808 = (39/14) [MHz]高いということで、元記事と計算が合いました。
ところで、地デジの公称周波数は物理チャンネルの中心周波数より 1/7 [MHz] 高くオフセットがかかっているので上のスペアナ画面のように 物理チャンネル13ch（中心周波数473MHz）の場合、上端パイロットの周波数は、473 + 41/14 = 475.928,571,4... [MHz] となります。
次にパイロット信号を拡大すると左側に2本のキャリアが見えてきます。それぞれセグメント番号12 キャリア番号422と425のAC(Auxiliary Channnel)信号です。AC信号は、変調波の伝送制御に関する付加情報または地震動警報情報の伝送に使われるそうです。
左側と真ん中のキャリアの周波数差は0.992kHz×3=2.976kHz。
真ん中とパイロット信号の周波数差は0.992kHz×7=6.944kHzとなるはずですが、スペアナ画面のマーカー値とは微妙に違いますね。FFTビンの都合で少しズレて見えているのかも（想像）です。
CPは連続キャリアでBPSK変調、ACはDBPSK変調されていて、信号レベルはそれぞれ同じのようです。

斬新！猫に蛸です。

デザインは昔々からのもの。専門家曰く猫（招き猫）と蛸（多幸）の目出度い組み合わせ。

サイドはこんな感じ。手作りゆえ土人形の表情はすべて違います。

山形県米沢市・相良人形

TRIO FMチューナ KT-9900 近代化改修： FPGA書き込みケーブルが使えない

FPGAのソフトを少し変更し、書き込もうとしましたが、iMPACT が書き込みケーブルを認識しません。デバイスマネージャはちゃんと認識しているのになぜ？

Console画面をよく見るとこんなメッセージが。

Connecting to cable (Usb Port - USB21).
Checking cable driver.
 Driver file xusb_xlp.sys found.
 Driver version: src=1029, dest=1029.
 Driver windrvr6.sys version = 11.5.0.0. WinDriver v11.5.0 Jungo Connectivity (c) 1997 - 2014 Build Date: Jan 26 2014 x86_64 64bit SYS 13:30:18, version = 1150.
Invalid device driver license.Cable connection failed.

Webの記事を参考にデバイスマネージャからドライバーの更新を試しましたがNG。次にドライバの再インストールを行って無事認識できました。

• デバイスマネージャでJungo ConnectivityのWinDriverをアンインストール
• C:\Windows\System32\drivers\windrvr6.sysを削除
• スタートを右クリック ⇒ コマンドプロンプト（管理者）⇒ C:\Xilinx\14.7\ISE_DS\ISE\bin\nt64\install_drivers.exe を実行

しかし、1月にはちゃんと動いていたのに何が原因だったんだろう？

TRIO FMチューナ KT-9900 近代化改修： フロントエンドの利得低下

フロントエンドを改修してミキサに入る前で信号を引き出して使っています。当初の利得は13～14dBでしたが、気がつくとほぼ0dBに低下していました。これは、新品交換したはずのトリマコンデンサの不良が原因で再度別のものに交換して対応完了。結果的に利得は18～19dBに上がりました。

当初はアンプの不良を疑い、2段あるFETの直流電圧をテスタで測定したところ正常でした。それならと、スペアナで直接レベルを見てようということでBNCケーブルにみの虫クリップを取り付けたテストリード線を作りました。直流カットのためコンデンサも直列に入れてます。これを使って、FETの段ごとの利得を確認しますが極端に利得が下がっているわけではないようです。

次に、同調調整をやり直します。すると、コイルの同調コアが1個割れていることに気がつきました。

割れたコアはドライバーで回しても空回りするばかり。千枚通しを駆使し砕いて丁寧に除去します。代わりに昔の東光のRFコイルのコアを移植して使います。このコアの交換後に再調整しましたが状況は改善しません。更には、調整中にまたコアが割れて回せなくなり心が折れそうになります。

さらに同調調整を進めていると今度は、トリマコンデンサを回すと大きくレベル変動するのに気がつきました。場合によっては10dB以上乱高下します。これ、新品交換したはずでしたがどうやら接触不良のようです。ジャンク箱を探すと表面実装用？エアトリマがあったので代わりに交換しました。

トリマコンデンサを交換して利得を測ってみると、結果的に従前よりも利得が上がっていました。利得差がトリマコンデンサの影響だったのかはよくわからないところです。

• 76MHz受信時： 17.8dB
• 83MHz受信時： 18.9dB
• 90MHz受信時： 19.3dB