コグノスケ

ZephyrのOut-of-treeアプリケーションその7 - STM32のシリアル出力は簡単

目次: Zephyr

前回（2026年6月18日の日記参照）、Device tree overlayの例でシリアル出力ポートを変更（usart1 -- PB6/PB7）してシリアル出力しましたが、NUCLEOボードでシリアル出力を見るだけならこんな面倒なことはしなくて良いです。

• usart1 TX: PB6: Arduino Connector(CN5) 3番
• usart1 RX: PB7: Morpho Connector(CN7) 21番
• usart2 TX: PA2: Arduino Connector(CN9) 2番（SB63をブリッジする必要がある）
• usart2 RX: PA3: Arduino Connector(CN9) 1番（SB62をブリッジする必要がある）

前回このようにusart2がどこにも繋がっていないかのように書いてしまいましたが、SB63/SB62をブリッジしていない状態のusart2 TX/RXはSTM32用のデバッグI/F（ST-Link）のSTLK_RX/STLK_TXに接続されています。

USART2の行先

ST-LinkはSTLK_RX/TXのシリアル入出力をUSB CDC（Communication Device Class）デバイスとして見せてくれますから、ボードを接続しているマシンの/dev/ttyACM0をターミナルソフトで見ればボードのシリアル出力が確認できます。NUCLEOボードは良くできていて、電子工作で良く使われてる理由の一端を見た気がします。

誕生日のパラドックス

Twitter…じゃなくてXで「QuizKnockの誕生日のパラドックスの計算式が間違っている」って指摘を見かけました。YouTube動画（【確率ライン】低確率から高確率まで一直線に並べろ！【直感に反する】）の14:03〜辺りですね。こんな感じです。

指摘箇所の動画キャプチャ

文字起こしすると下記の通り。

30人のグループで、誕生日が同じ人の組が1組以上いる確率（1年は365日）
70.63％

30人でペアを作る組み合わせは、30C2 = 435通り
そのペアが同じ誕生日でない確率は、364/365
すなわち求める確率は、1 - (364/365)^435

「すなわち求める確率は〜」に書かれている式を計算すると69.68％で、答えの提示70.63％と矛盾します。調べてみると正しい式は1 - (365Pn / 365^n)らしく（誕生日のパラドックス - Wikipedia）、n = 30のとき70.63％になります。なるほどね。

間違いは誰にだってありますからそれ自体はどうでも良いんですよね、それより私が気になったのは式の結果です。物は試しで50人までの値を計算してグラフにしてみます。

OK/NGの計算式の結果

答えと微妙に違いますがそれでいて答えにかなり近い値が出ます。各ペアの誕生日が同じでない確率は独立ではないので間違いらしいのですが、近似値としてはなかなか面白いです。近似式ってことは、正しい式に比べて計算が楽であってほしいですけど……、どうだろね？そうでもなくない？って感じがします。

QuizKnockの名誉のために補足

ちなみに動画説明を見ると「概算を求める式です」みたいな説明が書かれています。確かに鶴崎さんが12:30辺りで正しい式を書いていますし、メンバーが誤解しているわけじゃないですね。ただクイズに答えるってのが動画の趣旨なので、式は正しくても(365P30 / 365^30)を暗算や筆算で求めるのは厳しすぎるのもわかる……。

あとQuizKnockのWebサイト記事（クラスに誕生日同じヤツ絶対いる説【絶対じゃないかも】）など、過去に何度か取り上げられていますがいずも正しい式が書かれていました。

記事ではなぜかうるう年（1年 = 366日）で計算していて、若干値が違いますけど、式は同じです。例えば30人の時、365日なら70.63％、366日なら70.53％です。

ADS-Bを送る時刻に注意

目次: 自宅サーバー

以前、Flightradar24のcontributorになる方法（2026年7月13日の日記参照）を紹介しました。ADS-Bの受信情報を送るシステムを構築してしばらく運用していたところ、いつのまにかcontributorからfreeに戻っていました。ええ？なんで？？

原因がわからんので調べます。まず入口の受信機側を見ましょう。ADS-B受信・デコードです。readsbは元気に動作していて、viewadsbで見ても大量に飛行機の情報が表示され続けるので、ADS-Bの電波受信とデコードに問題はなさそうです。

出口のWebサービス側も見ましょう。Flightradar24のstatusを見ると、STATUS Onlineなので通信はできていそうです。一方でAIRCRAFT SEEN 0になっているため、ADS-Bデータは送っているけど無効もしくは捨てているのかもしれません。Webサービス側より受信機側が怪しそうです。

時刻は大事

で、ADS-Bの受信機側（OKdo/radxa ROCK 5B、Linuxが動くARM SBC）を見ていたら、時刻が分単位でズレていることに気づきました。もしかして時間がズレすぎで、異常データ判定されてるのかな？裏付けを取るためにntpdateで時刻ずれを直してからfr24feedサービスを再起動したところ、AIRCRAFT SEENのカウントが増えるようになりました。やったぜ。

ROCK5Bは放置しているとどんどん時間がズレていってしまうこともわかったので、また同じ問題にハマらないように、ntpsecの設定にいくつかNTPサーバーを足しておきました。これで何とかなるでしょう。