Nobuyoshi Sato (発信者情報開示本Booth) @[email protected]

最後に0xa5が来るパターンを見つけたので頑張ってリカバリーするようにしたんだけど、そもそもチェックサムとかもないフォーマットだし、送信側の計算能力からしてCRCは無理だし。

6chのEEGの信号だと17バイトのパケットを送っていてパケットが壊れているエラー率が6.76%、2chに減らすと9バイトに減ってエラー率が2.46%。でも2chに減らすと互換性がなくなる。
パケットの先頭の2バイトが同期用の0xa5 0x5aで最後がなんだかわからないけど0x01なので、最後までちゃんとずれずに読めたら成功にした。

シリアル通信の取りこぼし対策、なんかないかねぇ。

今どきのマシンで52600bpsでシリアルポートをたたいて、取りこぼしなんて起きないよなあ。

昨晩、いろいろ試してるArduinoベースの心電計・筋電計用のパッドを、お風呂から上がって汗が引いたら貼り付けてから寝たわけだが。貼り付け位置を記録していないのを朝になって思い出して、ベッドに寝たまま裸の自撮り写真を撮ってた。1チャネル分の心電計として使えるが、どこに貼るべきなのかとか。

noatimeが効いている感じではあるんだけど。そのあと、tunefsでTRIMを有効にしたんだな。SDカードでTRIM相当の命令があるかわからんが、RPIのLinuxで/dev/mmcblk0に見えてれば問題ないらしいし。ふーん。

ROCK 4 SEに入れたFreeBSDがファイルシステムに負荷をかけると再起動しちゃう問題なんだけど。/usr/srcとそのコピーのdiffみたいな基本的に書き込みが起きないdiff -urでも再起動しちゃうので、atimeの書き込みか??と思ってnoatimeをつけてマウントして様子を見ている。

新しいSDカードでシバいてたらやっぱり死んだので、SDカードのハードウェアの問題じゃないなあ。eMMCのモジュールが来るまで待ちか。

早く本人事件でもmintsを使わせてくれ～。

第二回弁論期日に行ってきたぞ、と。正確には準備期日なんだけど、被告が電話参加だからでしかない。あと、Twitter APIの https://developer.twitter.com/ja/docs/twitter-api にあるドキュメントを印刷して出したらとんでもない量でな。そもそも印刷することなんて想定してないもん。でも、裁判所には紙で提出だし。

なんか、SDカードの耐久性の問題の気がしてきた。高耐久タイプにもかかわらず、だけど。

ROCK4 SEにFreeBSD 13.2を入れて、rm -rf hogeみたいなファイルシステムへの負荷で死ぬの、別のSDカードにddでイメージを移したら一応再現していない。まあ、今のところ、だろうし、元のSDカードにしても新品だし。
ただ、ロットが違うのか、同じ32GBでも10セクタ少なかったり多かったり。

ソヴィエト岩手で30度を超えてるの、ちょっとあり得ない。

rm -rf hogeとかでファイルシステムに負荷をかけるとROCK 4 SEが死ぬ問題、電源周りとかファイルシステムの空き容量の問題じゃなさそう。ということで、同じ品種の別のSDカードにddで移してる。

ROCK 4 SEにmicroSDHCに書き込んで突っ込んだFreeBSD 13.2だけど、rm -rf hogeOSごと落ちる...。なんでだ。microSDHCは新品同然で、しかも高耐久品...。