Arduino古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタクルがあります。モジュラージャックの種別はRJなんとか(RJ11など)という名前で呼ばれます。数字が違うと何か違うのは知っていましたが、今まで気にしていませんでした。最近、趣味で早打ちターゲットを作っていて電子回路&基板を書いているんですが、部品の1つにRJ14(6極4芯)を使っていて、そのときRJ11〜18までRJなんとかシリーズがたくさんあることを知りました。電子回路作成ツールのKiCadの部品リストによれば、下記の種類があるそうです。6P4C(6極4線)どの規格で定められているのか?RJなんとかとは何か?RJ13とRJ14は何が違う?と気になったので規格に当たってみました。1976(PDFへのリンク)にて定義されています。古そうだなとは思いましたが、まさか50年前の規格だったとは......。Register)は連邦官報のことです。FRはPDF形式で配布されていますが、PDF形式と言いつつ中身はスキャン画像の羅列でした。古い文書だと仕方ないですね。ところがOCRを掛けてくれているらしく文字列検索ができます。アメリカ政府ありがとう。Code(USOC)です。installations.(適当訳)これらUSOCは一般的な電話会社のサービス注文コードです。電話加入者が電話会社に対し、下記の§68.502(a)(1)に記載されているジャック以外の標準ジャックの設置を希望する場合は、設置を要求するときに適切なUSOCを指定するものとします。§68.502(a)(1)というのはRJ11のことを指しています。RJなんとかは電話会社に設置を頼むときの注文番号だったんですね。RJ14は書いてあるがRJ13は見当たらない次はRJ13とRJ14の違いを調べます。FRからRJ14Cの規格を見つけました、こんな定義です。手書きの図が良い味出してますね。RJ14の定義しかしRJ13は載っていませんでした。後で追加された規格なのか?残念ながらRJ13とRJ14の違いはわからないままです......。1996年(PDFへのリンク)の方が見やすいかもしれません。Regulations)は連邦規則集という名前だそうで、CFRはアメリカ政府が発行している規則集です。法律に準ずるものらしいですが、法律の専門家ではないので詳しいことはわかりません。47はTelecommunicationの話題で、Vol.1からVol.5まであります。Vol.3の一部しか見てないですけど......。00:07)コメント一覧コメントはありません。bullseyeイメージは10分ほど?放置していると画面が消えてロック画面に戻る設定になっています。これはこれでありがたい動作ですが実験用に使っていてキーボードを繋いでいないことがあるので、ロック画面への移行と、画面が消える動作を無効化する方法をメモしておきます。[ロック画面を有効にする]をOFFにすれば良いみたいです。再起動後も設定を覚えてくれています。[ブランク画面にするまでの時間]などから設定できます。ロック画面と違って設定を覚えてくれない?みたいで、再起動すると元に戻ってしまいます。理由が良くわからない......困った。Windowに頑張ってもらうことにします。DPMSの状態の設定と取得にはxsetを使います。Systemのアプリと同様にDISPLAY=:0などのように、どのディスプレイか指定する必要があります。0と指定すれば良いです。DPMSの設定は最後の方に表示されます。autostartで毎回起動時に勝手に設定する仕掛けにします。システム全体ならば/etc/xdg/autostart/に、ユーザーごとに設定したいなら.config/autostart/に設定ファイルを作成します。ファイル名は何でも良いですが、今回はxset.desktopという名前にしました。0X-GNOME-Autostart-Phase=Initializationファイルを作成したら再起動して、DPMSが望み通りの設定に変わるか確かめます。[セッションと起動](xfce4-session-settings)からも作成&設定できるはずです。11:47)コメント一覧コメントはありません。SBCとお話する取り組みの続編です。今回はbluez-dbusを使ってBluetoothデバイスと通信します。データ通信の仕組み前回の話と少し重複しますが、Bluetoothデバイス特にBLEデバイスとはGATTプロファイルを使って通信します。BLEデバイスはサーバーになります。サーバーはService(=提供する機能)を1つもしくは複数持っていて、Service、Characteristic、ValueとDescriptorが入れ子の構造になっています。GATTサーバー(BLEデバイス)ServiceCharacteristicValueDescriptorDescriptor...GATTのデータ送受信はCharacteristicのValueを読み書きすることで実現します。簡単な送信側(Write)からご紹介します。null);バイト配列を用意してwriteValue()を呼びます。書き換え属性を持っているCharacteristicでないと書き込みが失敗します。次は受信側(Read)です。writeValue()と同様にreadValue()も用意されていて、最後にReadした値を読み出せます。一度読んだ値なのか新しい値なのか区別が付きません、つまり値の更新の有無がわかりません。GattRx.readValue(null);ではこの方法はダメなのか?というとそんなことはありません。一定時間ごとに現在値を見たい場合、例えば「温度計の値を1分ごとに読み出す」といった用途で役立ちます。一方でストリームデータを扱う場合、新しい値がきたときだけ読み出したいので更新を検出する必要があります。検出には少しややこしい処理が必要です。bluez-dbusは何かの状態変化が起きるとPropertiesChangedというイベントで知らせてくることを利用します。使い方は、AbstractPropertiesChangedHandlerを継承したハンドラクラスを作成ハンドラクラスのインスタンスをDeviceManagerに登録BluetoothGattCharacteristicのstartNotify()を呼ぶ(BLEデバイスからのNotifyを検知できるようになる)コードで書くと下記のようになります。PropertiesChangedHandler(...);deviceManager.registerPropertyHandler(handler);GattRx.startNotify();PropertiesChangedハンドラはCharacteristicsの値の更新も、別の関係ないイベントも何でも受け取るので、何のイベントが発生したか判定する必要があります。bluez-dbusのBluetoothGattCharacteristicクラスと、PropertiesChangedクラスはいずれもD-Busのパス(/org/bluez/hci0/dev_xx_xx_xx_xx_xx_xx/service0028/char0029のような文字列)を返すメソッドを持っていますので、D-Busのパスが一致するかどうかで確かめます。変化した値と名前のMapをgetPropertiesChanged()で取得できるので、全要素を調べて名前がValueであり、バイト配列を保持していればCharacteristicの値の変化を通知するイベントのはずです。}}自分でBLEデバイス側の実装をしているなら、意図しないイベントが混ざることはありません。上記のコードのように簡素なチェック(例えば単にバイト配列かどうかだけチェック)でも動作するはずです。23:03)コメント一覧コメントはありません。早いもので41歳になりました。昨年の日記(2023年3月10日の日記参照)を見ると、コロナの流行を心配していました。コロナの流行は相変わらずのように思いますが、世の人々はもう対策に疲れたのか、感染リスクを無視して暮らすスタイルが定着したようです。個人的には感染しないに越したことはないので、これからもマスクなど予防は心がけたいと思います。花粉症にもなりたくないし......。働き方はリモート10割から、リモート:出社=7:3〜5:5くらいの割合に落ち着きつつあります。オフィスに用事がなければ行かないなんて、昔では考えられない通勤スタイルですね。この働き方の利点は「遠隔地に居る人」が気にならなくなることです。オフィスに集まる場合を除けば、家も沖縄も北海道も大して変わらないのです。実際、東京から離れて住んでいる人もいるようですね。03:34)コメント一覧コメントはありません。車またまた車のバッテリーが干上がって死にました。写真は撮っていませんが2Vくらいになっていたように思います。今日はディーラーでの半年点検の日でディーラーに行かなければならないので、ジャンプスタートしてエンジンをかけてディーラーまで行きました。去年買った(2023年4月22日の日記参照)KashimuraのジャンプスターターKD-238が大活躍です。活躍しないほうが本当は良いけど。ディーラーに辿り着いて車を預けたら、ディーラーの駐車場から動かそうとしたらバッテリーが上がってて動かせなかった、ジャンプスタートしたと言われました。ごめんね......。ディーラーからの意外な提案またバッテリー交換で財布が軽くなるな〜と思っていたら、整備士さんからは意外な提案が返ってきました。一時的にディーラー所有のバッテリーに交換して車を返す上がった方のバッテリーは1週間掛けて充電してみるバッテリーが充電できたら連絡するからまた来てほしいとのこと。バッテリー交換以外の新たなパターンに出会いました。交換して1年、走行距離も1000km程度、バッテリーはこんなに劣化しないはず?と判断したみたいです。安く何とかしてみたい、というご提案だと理解して素直に承諾しました。バッテリー復活なるか?いつもと違うので楽しみですね。00:56)コメント一覧コメントはありません。SBCとお話する取り組みの続編です。今回はbluez-dbusを使ってBluetoothデバイスの列挙、GATTのServiceの列挙を行います。アダプタとデバイスの列挙DeviceManagerというクラスとDeviceManagerクラスのスタティックメソッドが、bluez-dbusを使うときの根っこになります。DeviceManagerのインスタンスを作成するため最初にcreateInstance()を呼ぶ必要があります。これ以降はDeviceManager.getInstance()でDeviceManagerのインスタンスが取得できます。引数はfalseならシステム全体用のバスインタフェース、trueなら現在のログインセッション用のバスインタフェースに接続します。Bluetoothの仕組みとは関係なくて、Bluezが依存しているD-Busの仕組みが透けて見えています。falseで良いはず。bluez-dbusの初期化、createInstance()の呼び出し//一番最初に1回呼ぶDeviceManager.createInstance(false);//以降はgetInstance()でDeviceManagerオブジェクトを取得できるDeviceManager.getInstance();システムに存在するBluetoothアダプターの一覧を得る方法はこんな感じです。deviceManager.getAdapters();Bluetoothアダプターを1つ選んだら、Bluetoothデバイスを探して(Discovery)、ある程度時間を置いて見つかったデバイスの一覧を取得します。deviceManager.getDevices(true);注意点としてはstartDiscovery()とstopDiscovery()の間はある程度の時間を開けないとデバイスが1個も見つかりません。Energy)デバイスとはGATTプロファイルを使って通信します。Protocol)という属性をやり取りするプロトコルがあります。GATTはATTプロトコルの上で汎用的(Generic)にデータを通信するための取り決め(プロファイル)になります。GATTというかATTはクライアント・サーバー方式のプロトコルでして、BLEデバイスはサーバーになります。サーバーはService(=提供する機能)を1つもしくは複数持っています。1つのService内にはCharacteristicが並んでおり、CharacteristicにはValueとDescriptorが並んでいます。GATTサーバー(BLEデバイス)ServiceCharacteristicValueDescriptorDescriptor...CharacteristicValueDescriptorServiceCharacteristic...Characteristic...通信に使うのはCharacteristicですが、いきなりCharacteristicを列挙することはできません。上位側にあるServiceから列挙します。Serviceを探すにはconnect()してgetGattServices()を呼びます。connect()とdisconnect()は数秒レベルで時間がかかります。C3に対してペアリングなしで接続しています。ペアリングなし=通信路の盗聴や乗っ取りをされる可能性があります。今回は特に困らないのでこのまま話を進めますが、盗聴や乗っ取りをされると困る場合はペアリングをする必要があります。ペアリングの方法もご紹介したいですが、今はやり方がわかりません。わかったらまた別の日記にでも書きます。device.getGattServices();device.disconnect();GATTのService内のCharacteristicを探すにはgetGattCharacteristics()を呼びます。srv.getGattCharacteristics();CharacteristicのDescriptorも取得できます(getGattDescriptors()メソッドを使います)が、今回は特に必要ありませんので列挙するためのコードは割愛します。送受信の方法はまた今度。23:03)コメント一覧コメントはありません。Piを組み合わせて的あてゲームを作っています。Bを使っているものの、販売終了につき新品が手に入りません。今は1台あれば良いので困りませんが、後でN増しするとき困りそうです。3Bくらいの価格(5,000円くらい)まず値段的にx86のノートPCやNUCは購入候補から外れます(中古品でも厳しい)。4)がちょうど良さそうでした。1GB版に決めました。Bを置き換えるにふさわしい製品だと思いますが、私の使い方だと1点だけ問題があって、Javaの画面描画が致命的に遅いです。5秒に1回くらいしか描画されません。このままでは使いたい目的に合いません。最初にGPUが有効になっているか確認です。GPU使用率を/sys/devices/platform/fed60000.gpu/utilizationを見ると、無負荷のときは0、アプリ起動時で20くらいでGPUは動いています。暇しているというか余裕すらありそうです。Javaのライブラリ系orアプリ実装の問題でしょう。次にJavaのライブラリ系を確認です。現在、画面描画のダブルバッファリングに使っているのはBufferStrategyで、BufferStrategyが返すVolatileImageのisAccelerated()はTrueを返します。OpenGLによるHW描画が使われているようです。これも問題なさそうです。残るはアプリ実装の問題ですね。余談ですが下記のようにGraphics2D経由で確認すると、Graphics2D経由でisAccelerated()を呼ぶ((Graphics2D)strategy.getDrawGraphics()).getDeviceConfiguration().getImageCapabilities().isAccelerated()なぜかisAccelerated()がFalseになります。Graphics2Dのアンチエイリアス機能が遅いタイトルの通りですが、アプリ実装が原因でした。コードでいえば下記の部分です。RenderingHints.VALUE_TEXT_ANTIALIAS_ON);図形描画とテキスト描画のアンチエイリアスをONにして使っていましたが、このうち図形描画のアンチエイリアスをONにすると著しく描画速度が下がることがわかりました。Bは双方のアンチエイリアスをONにしても特に問題がなかったため、気づくまで結構手間取りました。図形描画のアンチエイリアスは今のところ見た目にさほど影響がないので、OFFにしました。テキスト描画のアンチエイリアスも描画速度に多少影響ありますが、OFFにすると見た目が悪くなりすぎるので、ONのまま使います。問題の解決はしていませんが、回避できたのは良かったです。Cの不良在庫化を避けられました......。01:18)コメント一覧コメントはありません。08:30)「おー、面白いですね。最終勤務日でした、入門カードや会社のPCを返却してきました。マンガ紹介一覧が欲しくなったので作りました。マンガ紹介お気に入りのマンガ紹介シリーズ。最近完結した短めの作品を紹介します。