アナログスイッチADG884を利用してDSPラジオとインターネットラジオの出力を切替える

週間スケジュールを設定できるDSPラジオ（RDA5807）を製作したが、聴きたい番組が放送されていない時間帯（特に野球シーズン）がある。その時間帯にはインターネットラジオ（PCM5102やUDA1334を利用）を聴くことにしている。ただ、手近な所に２台並べて置く必要があり、切り替えも面倒である。

そこで、DSPラジオとインターネットラジオを合体し、両方スケジュール可能なDSP＆INETラジオを製作しようと考えている。

コントロールするMCU（プロセッサ）とスピーカーが一台で済むというメリットもある。

プロトタイプを製作したところで、課題が２つ見つかった。

1. WiFiが至近にあるとDSPラジオに電波障害（感度低下）が生じる。
2. スピーカー出力を切り替える手段が必要である。

課題１．について説明する。

DSPラジオがある放送局を受信開始した時点で、MCUからWiFiにアクセス（例えば接続やインターネットラジオ受信）すると、WiFiの電波（強い）により受信していた放送局に受信障害が生じ、その状態が記憶されてしまい、DSPラジオの電源をOFFするまで受信障害が続くのである。

RDA5807のデータシートのブロック図には”Limiter”と”PGA”の記載があり、感度調整の機能がある。しかし、ソフトウェアから制御する方法は不明である。

そのため、対処として、「WiFiの接続を完了してから、DSPラジオの受信を開始する」と「DSPラジオの受信時はインターネットラジオ受信を停止する」という２つの事を行った。

ただし、「（インターネットラジオからDSPラジオに切り替える時に）インターネットラジオ受信を停止する」簡単な方法が見つけられず、「WiFiを一旦切断して、再接続する」という強硬手段になっている。

課題の２であるが、最初、DSPラジオとインターネットラジオの出力を並列にスピーカーに接続するという乱暴な実験（PCM5102は出力側にカップリングコンデンサがないタイプなのでマネしないで）を行ってみた。音は出るが、音量が極端に小さくなるという失敗の結果に終わった。

出力を（物理的な）スイッチで切り替える方法ではなく、プログラムから行いたかったので、アナログスイッチを探した。見つけたのがADG884である。ON抵抗が低く（0.3Ω位）、400mA程度の電流が流せるので、今回の用途にピッタリである。このチップはAliexpressから入手可能である。

ただ、注文時には気がつかなかったのであるが、ピンの間隔が0.5mmのSSOP10というタイプで、変換基板（これもAliexpressから追加購入）が必要な上、ハンダ付けが非常に困難である。

ADG884の利用例はネット上に見つからなかった（データシートは見つかった）。以下は試行錯誤の結果である。

ADG884は電源電圧が3.3Vで動作する。アナログスイッチが２回路（S1,S2）あり、ステレオであれば、チップが１個で済む。デバイスに関して、A系（S1A、S2A）とB系（S1B、S2B）のRチャネル、Lチャネルを同時に切替えることができる。IN1、IN2の端子は3V入力で制御できるので、MCU（XIAO ESP32S3）のGPIO44を並列に直結している。

既定（IN1、IN2をHIGH）では、A系（DSPラジオ）がON、B系（インターネットラジオ）がOFFで、IN1、IN2をLOWにするとA系がOFF、B系がONとなるように制御している。

以下に回路図を示す。

以下は実験的に製作したセットの写真である。RDA5807の基板（以前、製作）とPCM5102＋XIAO ESP32S3の基板（サンハヤトのブレッドボードを模した基板を利用）をジャンパー線で配線している。SSOP10の変換基板上の小さなチップがADG884である。使用感として、音量・音質への影響は殆ど感じられなかった（合格！）。

動作確認を行った時のスケッチ（プロト）はGithubにある。操作はWeb経由で行う。DSPラジオとインターネットラジオの切り替え、スケジュール設定など基本的な操作は可能である。

蛍光灯の２０２７年問題でマンションの管理組合はパニック

蛍光灯が２０２７年末に製造・輸出入が禁止されることが決まり、その対応でマンションの管理組合はパニックに陥っている。「蛍光管」だけの問題であれば、「蛍光管」と互換性（これも実は問題があるが…）のあるLEDランプに交換すれば済むのであるが、マンションには非常灯（非常照明）と兼用の蛍光灯があって、LEDの物と交換できない（物理的に不可能の場合（注）があるが、基本的に以下に述べる規制による）。

（注）平常時はグローランプ点灯（一般の蛍光灯）で、非常時に高周波点灯になるタイプの非常灯がある（次の写真）。また平常時から高周波点灯のタイプもある。この場合、LEDタイプの物は使えない。

非常灯には充電池が内蔵されていて、停電時に30分（60分タイプもある）しか点灯しない。したがって実用性には疑問がある（最近はスマホに懐中電灯機能があるので余計そう感じる）。

しかしながら、非常灯には、建築基準法と消防法の規制があって、設置が義務付けられている個所がある。さらに定期点検と報告（「12条点検」と言われている）が義務付けられていて、もし点検で不点灯だと自治体の指導を受けることになる（自治体による）。今回、都合の悪いことは、予め決められた型の「蛍光管」にしか交換（非常灯の認定外になる）できないのである。

つまり、２０２７年問題に対応するためには、蛍光灯（機器）ごと認定されたLEDタイプの物に交換するしかないのである。

LEDタイプの物に交換するには、工事費、経費を含めると１灯当たり、５万円かかるという話がある。

蛍光灯タイプの非常灯はマンションの避難階段（屋内の場合）に設置されていて、踊り場にも必要（これも規制）なので、階数が多いとかなりの数（額）になる。

管理組合では、機器交換の予算を組んでいないので、急な多額出費（修繕積立金の取り崩し（ただでさえ赤字なのに）が必要で、総会あるは臨時総会の決議事項になる）となる。

蛍光灯が水銀問題で禁止になるのはやむを得ないとしても、交換のための補助金制度等（あるいは12条点検結果、必要となった交換時期の猶予）を設けるのが、規制側の責任ではないだろうか。管理組合は本当に困っている。

最後に、もし、交換する場合は必ず複数の業者の見積もりを取ること。機器の価格はメーカーによってかなり差があり（どこが安いとかはここでは書けませんが）また、施工業者の値付けもかなり差があります。

また、交換工事には電気工事士の資格が必要で、昨今の人手不足のため工賃が値上がりしているそうです。

週間スケジュールが可能なRDA5807 FM DSPラジオ（XIAO ESP32S3 Bluetooth版）

ESP32をBluetoothで制御できることは確認済なので、それを発展させて、DSPラジオを操作することを考えた。以前製作した週間スケジュールが可能なRDA5807 FM DSPラジオ（通信にはWiFiを使用）の仕様を目標に、Bluetooth（以下BLE（Bluetooth Low Energy））を通信手段に使用し、実現した。コントローラには、BLEの動作が確認できたXIAO ESP32S3を使用した。作成したスケッチと利用方法はGithubに登録してある。

BLEのメリットは、WiFiのようにアクセス環境やSSIDやパスワードの設定が不要なので、機器に詳しくない人（さらにArduinoの開発環境を知らない人）にも使ってもらえることである。

今回、PCとESP32S3（XIAO製）はBLEで通信するが、PC側はブラウザ（Chrome）がサポートするWeb Bluetooth APIが利用できる。操作画面の作成はHTMLを利用し、プログラムはjavascriptでコーディングする（BLEにはWiFiのようにWebサーバーのサポートが無いので外部ファイルとして作成し、ブラウザからロードする）。

ESP32S3側（「ペリフェラル」と呼ぶ）には、BLEの規格である「GATT」に準拠したサービスを立ち上げておく必要がある。このサービスのデータ構造には、「GATT」の「Current time service 」を流用した。色々あるBLEのSCANツールから検索できるので便利である。

データ構造の要素には、「キャラクタリスティック 」と「ディスクリプタ 」があり、PC側（「セントラル」と呼ぶ）から読み書きできる。

「読み」は情報の検索（例えば週間スケジュールの読み込み）、「書き」はコマンドの伝達（例えば、DSPラジオの音量の変更）に利用する。

PC側からのjavascriptによる「キャラクタリスティック 」と「ディスクリプタ 」の読み書きは、非同期に実行されるので、「Promise」と呼ばれるオブジェクトを使ったコーディングにする必要がある。

ESP32S3側では、これらの読み書きの要求は、各「キャラクタリスティック 」と各「ディスクリプタ 」ごとに定義されたコールバック関数で処理する。

全体として、「見通しが悪く、簡単ではない」という印象である。

HTMLで作成した画面を以下に示す。

利用者がArduinoの開発環境を利用しないで使い始められるよう、ラジオ局の初期登録をブラウザからできるようにしている。

電源ON後に、ブラウザに上の画面を定義したHTMLファイルをロードし、BLEスキャンを行って、このDSPラジオに接続し、現在時刻を設定すると動作可能となる（「Connect to ESP32」、「Set current time to ESP32 RTC」ボタンをクリック）。

目標の機能は、ほぼ実現しているが、BLEの制限（一度に送受信できるデータ量（おそらく200バイト以下））により、スケジュールの表示が、1日（曜日）単位になっている。

また、BLEの特性で接続が直ぐに切れてしまう（この環境では約30秒）ため、操作の都度、接続操作が必要で、使い勝手が良くない。

（基板はXIAO ESP32C3の物を流用した。ピン数と電源関係のピン位置が同じなので流用できる）

「えきねっとｘ楽天カードｘ新幹線eチケット」の利用は落とし穴がいっぱい

所要があって、札幌から青森（新青森）まで移動した。札幌から新幹線の乗り継ぎ駅である新函館北斗までは在来線の特急を利用する。新函館北斗から新青森までは新幹線である。

「えきねっと」は何度も利用しているが、新幹線eチケットは今回初めて利用した。

１．「えきねっと」において楽天カードを使うと「不正検知」になる

「えきねっと」においてクレジットカードを使う際は「３Dセキュア」の設定が必須である。楽天カードにおける「３Dセキュア」は、最近、スマホのショートメッセージを使う方式に変更されたのであるが、以降、利用すると必ず「不正検知システム」に引っかかるようになってしまった。

「えきねっと」においては、クレジットカード情報を登録する際、「３Dセキュア」の認証が行われるが、スマホに通知された認証コードを入力し、「認証されました」とメッセージが出た後、「えきねっと」の購入手順では次のステップに進めなくなる。

一方、楽天カードからは登録してあるメールアドレスに、「不正検知」があったため利用停止にした旨のメールが届く。このメールにはURL（72時間有効とある）が記載されていて、ブラウザからアクセスして、本人の利用である旨回答する必要がある。放置するとカードがそのまま利用停止になってしまう。なお、回答は楽天カードのe-NAVIからも可能である。「不正検知」の対応策としては、まず（履歴が残っている可能性があるので）「えきねっと」からログアウトする。次に、e-NAVIか通知メールから本人の利用である旨回答する。これでカードが利用可能になるので、再度「えきねっと」にログインし、購入手続きを行う。やり直しになるので面倒この上ない。

２．eチケットを利用しないと割引が受けられない？

事前購入では「トクだ値」割引が受けられるはずであるが、「えきねっと」の購入手順において、eチケットではなく、紙のきっぷを選ぶと「トクだ値」割引が表示されない。eチケットは交通系ICカード（「切符」の代替になる）との紐づけ（ICカードの番号を利用）が必要であり、手元には、人数分のICカードはなかったが、eチケットを選択した（実はこれが次の落とし穴となった）。不足のICカードは「Kitaca」を購入（デポジット500円＋チャージ分1500円）した。余計な出費である。後日、人数分のICカードとの紐づけを行い、これでOKと思っていた。

「その他のきっぷ」を選ぶと割引が表示されない（割引なしの特急券のみ）。一方、「新幹線eチケット」を選ぶと割引（「トクだ値」）が表示される。「ICカードを登録してご乗車」とある（まるで必須のような表現である）。

３．10年間未使用のまま経過した交通系ICカードでは乗車できない

当日になって、旅行を開始後、eチケットに紐づけした交通系ICカードの内の一枚が、新函館北斗での新幹線への乗り換え時に改札でエラーとなり乗車できない事態になった。事前に、JRの券売機でチャージ残高を確認し、eチケットの紐づけもできたので、問題はないと思っていた。

乗り換え窓口で相談すると、別のICカードに紐づけしなおすか、紙の切符を発券するしかないとのこと。乗り換え時間は20分しかなかったので、急遽、紙の切符を発券してもらうことにした。この際、追加料金や割引が無効になるということはなかった（結局、ICカードは不要ではないか）。なお、紙の切符の発券には、購入時のクレジットカード、「えきねっと」の会員番号、受け取りコード番号（QRコードは不可）のうちのどれかが必要である。

わざわざ、事前に紐づけさせておいて、土壇場で使えないというのは、全体システムの不整合であり、欠陥だと言って良いと思う（乗り換えにはICカードの番号が読めればよいだけのに、「改札システム」は最終利用日（ICカードに記録されている）から10年経過していると問答無用で利用不可にしている。一方、「えきねっと」では（ICカードを読めないので）最終利用日が確認できない）。

以上を経験してみて、これも「落とし穴」かと気づいたのだが、eチケットの利用は止めて、紙の切符を発券しておけば良かったということである。

今回の利用で感じたeチケットの欠点は、紙の切符で得られた情報（列車名、座席番号、出発時刻）が簡単に得られないことである。これは非常に不便であった（改札通過後に座席票発行機が利用できるらしい。気が付かなかった）。紙の切符（の表示）で保証された内容が、eチケットでは何も外に表示されない（違うICカードを持参しているかもしれない。実際の乗車時に改札機を通すまで分からない）。

ちなみに、札幌から新函館北斗まで利用する特急は事前に紙の切符を発券しておく必要がある。同一旅程の内、一部の紙の切符を発券するとeチケットの内容は変更できなくなる（購入途中で以下に示す警告が出る）。つまり、eチケットの発券前は変更可能という利点は享受できず、最初から、全て、紙の切符を発券するのが正解だったのである。

XIAO_ESP32S3によるインターネットラジオの製作

Seeed StudioのXIAO ESP32S3が「技適」対応（スイッチサイエンスと秋月電子で入手可能）になっていたので、入手した。3年前の記事では、ESP32 DEVKITでインターネットラジオを製作したが、XIAO_ESP32S3はコンパクトなので魅力的である。スケッチ（プログラム）は開発環境やライブラリが新しくなっているので、そのまま流用とは行かず、作り直しになってしまった。作成したスケッチと構成部品との接続情報はGitHubに登録してある。

前回からの変更点であるが、まず（WiFi機能は必須なので）NTPサーバーを参照する時計機能を内蔵することにした。これにより、スリープ機能で使っているタイマー割り込み機能（制限が多く、最新のESP32開発環境（3.0）ではAPIの互換性がない）を利用しなくてすむ。また、スリープまでの残り時間を表示できるようになった。

OLED（表示装置SSD1306）のライブラリはAdafruitのものに変更し、EEPROMのライブラリはPreferencesに変更した。I2S_Audioのライブラリは現在もメンテナンスされているので、現時点で入手したものを利用させてもらう。

I2S DACは、UDA1334とPCM5102の基板が、変わらず安価に入手可能なので引き続き利用する（どちらも動作可能。ただPCM5102はスピーカー接続時はパワー不足）。

Arduino IDEは、2.1.0、espressifのESP32開発環境は「XIAO_ESP32S3」が利用可能な2.0.17とした（Arduino IDEのボードマネージャからインストール。古いとXIAO_ESP32S3が選択できない）。

Webブラウザからの操作をメインにするため、タクトスイッチは接続しないことにした（コード上ではサポートしている）。ブラウザの操作画面も１画面で済むようにアップデートしている。

XIAO_ESP32S3がコンパクトなので、5cmｘ8cmのブレッドボードに実装可能である。今回は、XIAO_ESP32C3＆RDA5807用のプリント基板が手元にあったのでパターンカットと配線追加を行い流用した。XIAO_ESP32S3とXIAO_ESP32C3では、ピンとGPIOの割り当てが異なるので、コード側で対応が必要である。

※注　XIAO_ESP32C3では、このインターネットラジオの実現は不可。

なお、XIAO_ESP32S3にはPSRAMが搭載されているので、バッファのサイズが約800KBに拡張されるため、回線の遅延に対する安定度の向上が期待できる。

セットの写真、埃よけのアクリルケースに収めた。XIAO_ESP32S3に「技適」マークが見える。I2S DACはUDA1334を利用している。電源はスマホのUSBアダプタ（5V）から接続。

Webブラウザからの操作画面（操作方法はGithubを参照）を以下に示す。

このインターネットラジオはMP3またはAACストリームのラジオ局に対応しているので、SHOUTCASTにおいて、「TYPE」がMP3あるいはAACと表示されているラジオ局を選び、Winamp（.pls）ファイルをダウンロードして、その中のURLをブラウザの操作画面の「Preference Settings 」に設定し、試聴（TEST SET）してみて、安定に受信でき、かつ気に入ったラジオ局があれば保存（SAVE）して、引き続き楽しむことができる。

※注　利用する場合は自己責任でお願いします。

docomoでない場合にD払いを使っていてdocomoにMNPすると面倒なことになる

スマホを2台持ちしている人は結構多いと思う。２年程度で買い替えるので、新規やMNPで移行してきて、手元には２台のスマホがある。旧スマホでは、docomo以外の回線業者（OCNモバイルONE）でd払いを使っていた。新スマホ（docomoではない）に移行した時には、d払いアプリをインストールしてdアカウントでログインするだけで移行できた。以来、新スマホでd払いを利用していた。

現在、OCNモバイルONEでは新規の申し込みは終了していて、docomoのirumoへのMNP移行キャンペーンを行っている。先行きが分からないので、今回、旧スマホのMNPの申し込みを行った。

旧スマホのMNPでの開通は問題なく完了したが、開通と同時に新スマホのd払いアプリがログオフされて、その後、d払いアプリへのログインができなくなった。

一方、docomoに移行した旧スマホでは、dアカウントでd払いアプリへログインすることが出来た。dポイントの残高はそのままであったが、なんとd払い残高が０になっていた。

dアカウントに登録してあるメールをみたところ、「【d払い】重要_d払い残高お預かりのお知らせ」というメールが届いていて、「d払い残高を預かった」とあった。この残高の返金には２、３日を要するとある。

つまり、移行時の残高は２、３日利用できないということである。d払いをメインに利用している人には大変困った事態になる。

そのまま、２日が過ぎ、「【d払い】重要_d払い残高返金手続きのお知らせ」というメールが届いた。「d払い残高の利用登録をお願い」とあり、自動で返金されるようである。d払い残高の利用登録はとっくに行っているが残高は０のままである。

上のメールから３時間たっても残高が０のままであったので、docomoのサポートに電話で問い合わせを行った。30分以上説明したが、一般論ばかり（受付者が何か処置できるわけではない）で埒があかないので電話を切ろうとしている所に、旧スマホにショートメッセージの通知が入り、「【d払い】重要_d払い残高返金完了のお知らせ」とのこと。旧スマホのd払い残高は反映されていた。何故、こんな面倒な手順になっているのか理解できない。ｄアカウントに紐づいているｄ払い残高は開通と同時に反映されるべきである。

新スマホのd払いアプリはログインできないままなので、d払いを利用する場合は、旧スマホを持って歩かなければならない。面倒である。

ちなみに、楽天ペイでは、こんな事にはならず、２台とも楽天ペイアプリが利用できている。d払いアプリを、docomo回線に紐づけるからこんな面倒なことになるのだと思う。

【追記】

結局、新スマホ（docomoではない）にd払いのアプリを新しくインストールしました。別のアカウントを作成するため、メールアドレスがもう一つ必要になるほか、本人確認（マイナンバーカードでの署名利用の登録がお勧め。運転免許での登録は写真撮影の位置合わせが難しく途中で断念）が必要です。旧スマホで貯まったｄポイントや残高は新スマホに簡単に送る（QRコード利用）ことができます。これで、旧スマホを持ち歩く必要は（殆ど）無くなります。

日産ノート e－POWERは車酔いし易い

最近の車は色々な機能が搭載されているので乗る度にブログのネタになってしまう。日産ノート e－POWERについては既に記事にしているが、短時間の運転だったので、もう少し長い時間運転してみたいと思っていた。今回、レンタカーを借りる機会があったのでノート e－POWERを選択してみた。

まず、気が付いたのはルームミラーが、モニタ表示になっていたことである。これには大変違和感を感じた。鏡のルームミラーの場合は、実際に見ていなくても視界に入っていれば後続の車の動向が何となく感じられていた。車が徐々に近づいてきているのを「感じる」ことができた。それがモニタ表示になると、いきなり後続の車が直近の直後に出現するのである。これには何度もハッとさせられた。どうも、モニタ表示だと、モニタ内に映る物体同士の距離感がつかめないようである。あと、室内が映らないため同乗者の様子が分からないのは欠点である。モニタ表示のルームミラーは「なし」だと思った次第である。説明書によると、鏡のルームミラーとの切り替えスイッチはルームミラーの裏側にあるとのことなので、次回は切り替えて乗ることにしよう。

ノート e－POWERの宣伝文句に「ワンペダル」というのがある。これは回生ブレーキ（エンジンブレーキと同じ様にモーターを使って減速させる。減速時に発電する電力でバッテリーを充電する）により、アクセルを緩めると制動力が働くのでブレーキペダルを踏まなくて良いという意味である（口の悪い人は「ゴーカート」みたいと言う）。しかしながら、これは慣れないと結構ストレスである。例えば、交差点の赤信号では、惰性で停止位置まで走って止まるが、アクセルを緩めるタイミングは「感覚」である。この回生ブレーキが効くと途中で失速してしまい、いつもの「感覚」が通用しなくなり、大抵、アクセルを追加で踏むハメになる。今回は半日運転したが、ベストな「感覚」（回生ブレーキが効かないアクセルの踏み加減は微妙で足が攣りそう）が掴めなかった。

この回生ブレーキには、もう一つの副作用がある。今回、家族が後席に同乗していたのだが、レンタカーを返却した後で、車に酔ったと言われたのである（ルームミラーに映らないので様子が分からなかった）。これまでオートマ車に同乗していて、酔ったと言われたことはないので、詳細を聴いてみると、回生ブレーキによる減速時の加速度が原因だと分かった。同乗者がいる場合、通常のオートマ車の運転では加減速による加速度を感じさせないよう丁寧な運転を心掛けているのだが、回生ブレーキでは車酔いの許容の範囲を超えてしまったようである。

返却時に、この回生ブレーキにより、今回の走行距離の約１割の電力を節約できたというレポートを見せてもらったが、上に述べた「負の効果」を考慮すると、「どうかな？」という疑問は残った。運転モードを「エコ」ではなく「ノーマル」にするとガソリン車に近い感覚になるそうなので、次回は「ノーマル」を選択しよう。最近の車は「テン乗り」が難しい。

Bluetoothを使ってESP32のRTC（時計）を設定する

DSPラジオのコントローラ（MCU）に時計機能を持たせるととても便利である。

ESP32にはWiFi機能があり、NTPを参照すれば現在時刻を得て、ESP32のRTC（時計）を設定することができる。この方法には２つ難点がある。WiFiのアクセスポイントが必要な点と、SSDとパスワードをプログラムに記述する点である。

他に何か方法はないかと思案して、ESP32のBluetoothは利用できないか調べて見た。最初、Bluetoothを使って、スマホの時刻を参照できないものかと考えた。BluetoothにはGATTという規格があり、その中に「Current time」サービスがあることに気が付いた。ESP32からスマホに問い合わせれば時刻が分かりそうである。しかしながら、スマホの「Current time」サービスは常時動作しているものではなく、このサービスを起動した上で、スマホ側から通知（notify）してもらわないといけないらしい（iPhone対応のライブラリを見つけたが、iPhoneが無い上に、コンパイルがエラーになったので評価できず）。その様な便利なスマホのアプリはないかと検索してみたが見つからなかった。

次に、ESP32側で「Current time」サービスを動作させて、外部から時刻を設定することはできないかを検討することにした。GATTのサービスを動作させる方法や外部から値を書き込む方法については、ネット上に先達の参考資料（ツールとして「nRF Connect for Mobile（スマホアプリ）」の使い方も含む）等があり、目途がついた。

一方、外部からBluetoothを使ってESP32にアクセスするには、スマホ（Android）のプログラムを作成する必要があるが、これについては、数年前に経験があるものの、開発環境とスキルの再構築には時間がかかりそうなので、諦めた。他に何かないか調べてみると、「Web Bluetooth」という技術があり、例えばPCのブラウザからBluetoothを使ってESP32にアクセスすることができそうである。

さらに手っ取り早い方法として、Googleのサイトにサンプルがあり、Chromeを使って試すことができる。ただし、PCにはBluetooth機能（内蔵）かBluetoothのUSBドングルが必要である。またはスマホのChromeからでも試すことができる。

ESP32上に「Current time」サービスを動作させるためのスケッチ（ArduinoIDE2.0で作成）はGitHubに登録してある。また「Web Bluetooth」を利用して、PCのブラウザからBluetooth経由で、このESP32にアクセスして現在時刻を設定するHTMLも登録してある。スマホ（Android）のChromeでの動作も確認した。なお、上のスケッチには「Lチカ」を行うコードも含めてある。今後、DSPラジオの制御にも使えそうである。写真は実験の様子。

電子工作家にとってのAmazon、AliExpress雑感

最近、Amazonの無料配送の金額が2000円から3500円に引き上げられた。これは、これまで飛び越えられていた跳び箱が、２段追加された様なもので、超えるには全力を出す必要がある。もともと少額のパーツを金額分集めて注文していただけに、購入の機会がかなり減ることになると思う。

Amazonには中華の業者が入り込んでいて、電子工作のパーツ類が割と揃っている。代表的なパーツの番号を入力するとヒットすることが多い。ただし、それらの配送方法について、注意する必要がある。

出荷元がAmazonになっている場合はAmazonの配送センターからの国内配送なので不着になることは無いと言って良い。出荷元が中華業者の場合は、中国からの配送（「何日以内に発送」とあることが多い）になるので、中国国内の郵便事情により不着になる可能性がある。不着の場合は返金になるが、一か月待たされた挙句のことなので予定が立たない（この6年間、約40点のパーツ注文で２回あった）。

出荷元がAmazonの場合は、価格が若干上乗せ（Amazonの保管料・手数料？1セット当たりの料金なので少額のパーツではかなりの割合になる）されているので注意が必要である。出荷元が中華業者の物と価格を比較してみると良い。

一方、AliExpress（以AliEx）は、私の電子工作の範囲においては入手できないパーツは無いと言って良い。最近「Choice」というサービスを始めていて、1500円以上まとめて注文すると無料配送（配送期間も大幅に短縮、7から10日）になる。これまでも、３点以上を同時期にまとめて注文すると配送センターで一つにまとめ、配送期間を短縮するサービスがあったが、それを一般化したのだと思う（「３点まとめて」は「百円ショップ」というサービスになっている）。

ただし、「Choice」の価格には配送料が組み込まれているようであり、単品よりも若干高めである。

AliExを、これまで利用してみて、不思議（感心）なのは、不着になることが殆どないことである。不着は、これまで（約6年間、Amazonの倍は利用している）１回だけで、この時は中華業者の方から輸送途中に紛失したので返金するという連絡があった。

おそらく、AliExでは、不着への対策をとっていて、通関まで自社の監視下において（郵便事情の影響を受けないようにして）いるものと推測する。

ちなみに、単品の場合、国内配送は、日本郵便（追跡不可）のポスト配送であった。「Choice」、「３点まとめて」の場合は、日本の宅配業者に引き継がれ、最近の例では、ヤマト運輸（追跡可能）であった。

1500円（AliEx）と3500円（Amazon）では勝負にならないと思うが…

追加情報として、いつも少額なので、消費税（AliExは10％お得）、関税をとられたことは無い。

あと、念のため、AliExにはクレジットカードではなく、記名式のプリペイドカード（Webmoney）を登録している。

最近入手したGPS受信モジュール、動作の確認はできた。

プリント基板の設計コンテストに応募してみた

前回のプリント基板制作では、リカバリしたものの、凡ミスがあった。このブログを見たPCBWAYの担当者さんから「再挑戦しませんか。支援しますよ」という連絡があり、私もリベンジしたいと思っていたので、お誘いに応じることにした。

修正は、部品の配置を見直して、抵抗を2本を追加するだけなので難しくない。ただし、チェックは念入りに行った。

注文のためにPCBWAYのサイトを見たところ、”KiCad Open Source Design Contest”の募集（4/2－6/2）を行っているのに気が付いた。

PCBWAYでは、ユーザーによるPCB（プリント基板）設計の成果を共有するための”共有プロジェクト”を実施している。

”共有プロジェクト”では、定期的にコンテストを実施していて、丁度、今が募集期間になっている。入賞者には賞金が授与されるとあったが、こちらは参加賞の”Pi Pico”を狙うことにした。大急ぎで、再注文し、PCB上での動作を確認して応募すれば間に合うと考えた。
PCBの注文時に、PCBWAYの担当者さんに連絡したところ、なんと費用の全額をアカウントに入金してくれた（感謝です）。

修正版のPCBは、注文から７日目に到着、PCBが設計通りであることを確認後、早速、部品の実装にとりかかる。その翌日、動作にも問題がないことを確認できたので、ひとまず安堵。いよいよ、コンテストへの応募に着手である。

コンテストには、応募サイトから以下の物を登録する必要がある。

• 簡潔な説明文（英語、140字以内）
• ガーバーデータ（基板の設計データ、KiCadで出力）
• 説明文（英語、簡単なエディタがある）
• 実物の写真
• 回路図（KiCadにて作成済）
• プログラム（GitHubに登録されていたライブラリのサンプルを改修）
• 部品表（KiCadで作成）
• 使用した設計ツール（KiCad、Arduino IDE）

プログラムについては、ライブラリのサンプルがArduino pro mini対応であった物を、Pi Pico対応に改修し、若干の機能追加した物をGitHubに登録した。

既に、”共有プロジェクト”に公開されているので、応募の審査はパスしたようである。

なお、今回の成果は、埃避けのアクリルケースに収容し、受信性能の確認中である。