MacのTahoeではNAS(Q-NAP TS-230)のtimemachineがコケる

世の中でも同じ問題は出ているんだろうけど、M4 MacBook-ProをTahoeにアップデートしてtimemachine実行すると失敗する

原因は生成A.Iの回答によるとSMBまわりがTahoeでかなり変更が入っているようで、低消費電力型のNAS(TS-230)では通信が失敗するらしい

—————————————–

P.S. 2025/11/22

本件は以下のリンクの記述がまとまっていると思う

https://hireido.blogspot.com/2025/11/timemachine-macos-tahoe-261.html

—————————————–

バックアップ取れない(復旧もできない)のは怖すぎだから、急遽USB SSD(SunDiskの1TB)を購入依頼した、Mac OS側のパッチ出るまではそれで凌ぐ

手持ちは2.5インチタイプかM.2で容量も少ないから、汎用でポータブルタイプ用途にもちょうど良いタイミングかもしれない

アプリはともかく、データ領域でバックアップできるところはM.2 SSDにバックアップを取っておいた

P.S. 2025/11/19

SSD入手できたのでバックアップ取ってみた、SSD使用領域450GB超えてるぐらいだけどおよそ30分でバックアップ完了、ディスクを複数記述しておけば交互にバックアップ取るらしいから、いずれそういう使いかでも良いかもしれない

気持ちもう少し短めのケーブルでも良さそうに思う

 

admin

PlateauのデータをUnityにインポートしてみる(ヘビー級)

国交省の進めているプロジェクトにPlateauという、都市データを三次元データ化して例えば防災などに役立てようというものがありますが、三次元データは色んなアプリにインポートできるというのでやってみた

メジャーどころはBlenderとUnityかと思うけどUnityでやってみた、ただしSDKがUnity6は扱えないから、それ以前のバージョンで

手順は(https://scrapbox.io/lecture-nakayasu/PLATEAU_SDK_for_UnityによるCityGMLからOBJ変換を参照)、

① Plateau SDKをUnityにインストールする

https://github.com/Project-PLATEAU/PLATEAU-SDK-for-Unity/releases

② 三次元データをインポート

https://www.geospatial.jp/ckan/dataset/plateau-14212-atsugi-shi-2023/resource/fb7ea888-8d6a-43d5-a3c3-1557007bfce9

近隣で厚木市のデータをインポートしましたが、データサイズが巨大で狭い区画指定じゃないと、Unityがハングしてしまいます

こんな感じで相模川の中洲が見えているところになります、遠方にはビルが見えるから厚木駅方向ですかね

但しこの程度でも、

モデルの精度が高いとメモリは大量に消費するから、相当範囲を限定しないと使えなさそう

 

admin

STM32を使ってみる

表示含めて基本のロジックは組み込み(ラズピコスペアナ)

でラズピコ2使ったオーディオ帯域のスペアナとオシロスコープ作ってみたけど、ラズピコではいくつかの制限あって、中でも大きなのはDMAがちゃんと使えない、ADCの実効精度が出ないなど、イマイチなのでペリフェラルの制御機能に優れたSTM32シリーズを使ってみようと思う

部品は以下を秋月に発注したけど、F4シリーズならオーディオ帯域のFFTには能力的にかなり余裕ありそうだ

・Nucleo

https://akizukidenshi.com/catalog/g/g107723/

・BNCコネクタ

https://akizukidenshi.com/catalog/g/g105362/

・オペアンプ

https://akizukidenshi.com/catalog/g/g100069/

・ユニバーサル基板(95*72)

https://akizukidenshi.com/catalog/g/g103232/

・パスコン(0.1μ, 2.2μ, 10μ)

https://akizukidenshi.com/catalog/c/ccapacitr/

・三端子レギュレーター

https://akizukidenshi.com/catalog/g/g111299/

 

開発環境は最初はCubeIDE使うんだろうね、その後はVScodeの拡張機能かな、ラズピコの環境構築に似てはいる、但し言語は基本的にはCになるね、組み込み向けのアプリケーション考えれば当然と言えば当然だけど

CubeIDEだけインストしてみたけど、利用実績多いだろうから洗練された見かけと、サンプルコードも非常に多い

 

admin

ソーラー充電のログ取ってみた結果

ソーラーシステムの電圧ログを取ってみる

この記事のフォローになります

8日間程度のデータですが、

 

こんな感じです、ソーラー電圧は日中の光を受けて電力発生している時間帯にはピークが見えます、この先継続しても12.4V程度は下回りそうにないので十分に効果はあると言えそうです、発電量が一番低下するのは太陽の高度から冬至の頃だからその頃に再度ログ取ってみようかと思う

但し真夏の太陽と違って、晴れてもバッテリーを満充電にするようなパワーはない模様

 

admin

Visual Scripting(VS)の存在意義それほどないかもね

Unity解説本も生成A.I前提で書籍が記述されてるよ

この本一通り実行してみましたが、別にUnityだけじゃないけど、生成A.I標準の世界では、タイトル通りのことが言えると思う

VSも結局のところ、ブロック機能の種類が多いからそれらを覚えるよりも直接C#のコード書いた方が開発速度も速いと思うよ

あと気づいた点は、今のUnityのtutorialはTextMeshPro使っているけど、現在の最新はUI ToolKitだろうから、現状は併存なのだろうけどtutorialはちょっと古めかもしれない

いずれにしてもUnity6になってゲームエンジンとしてはコードを書くことはそれほど比重がないとも言える、ゲームオブジェクトのコンポーネントの多くは設定やエディタあるいはshader graph(見た目)やanimator(動き)のようなVSライクな記述方法で解決がつく割合が増えているから、コードはロジックの記述に限定とも言える

 

admin

ソーラーシステムの電圧ログを取ってみる

車のバッテリー上がり防止用のソーラー充電器のログ取るために多少の改造

① 電池電圧、バッテリー電圧、ソーラーパネル電圧の3チャネルのデートを取得するようにした

② 取り回し改善のために最低限の構造変更

・配線保護のために同サイズの基板をネジで浮かせて取り付ける、電池は浮かせた基板に両面テープで貼り付け

 

 

で、パワコンのところで接続したところ

これでしばらくデータ取ってみる

 

admin

Unity解説本も生成A.I前提で書籍が記述されてるよ

Unity6になって結構変更も多く、かつパッケージの従来互換もなくなったようですが、初めてのUnity本でUnity6の入門本を買ってみた

Unity6になって内部の構造も大幅に変更されて、そのために従来と互換は捨ててます

そもそもUnity Hubから開けるTutorialも従来と変わってるんだけども、この本自体の記述スタイルは、

・VSではなくてC#スクリプトの記述で作成するような形式、スクリプトの量は非常に少ないけどもC#の知識を前提にしないためにスクリプト生成には生成A.I使ってるし、またテクスチャーの生成には画像生成A.I使ってるよ

・実は生成A.I自体が本の執筆時点、おそらく2024秋頃と思うけど、その時点から画像生成A.I(ChatGPTでmaterialのtexture用に画像生成させる)も明らかに進化しているよ

ということで、この先こういう本も生成A.I前提で記述されていくような気がする、生成A.Iの進歩に追いつかない懸念はあるけどね

 

admin

lightsleep有効での電池電圧変化(ラズピコrp2040データロガー)

ようやくそれらしいデータが取れた、何しろ省電力有効にすると電池寿命長くなるから、時間かかると言えば当然と言えば当然ですが

<条件>

・電池:NiH電池の二直、容量1000mAH

・ラズピコ:rp2040のWi-Fi無しモデル

・サンプル周期:10分間隔で電池電圧をSDカードに記録

電池の放電電圧の開始電圧は比較のため合わせてあります(省電力有効は満充電から、省電力無効は放電途中からの測定だから)

SDカードのファイルの見え方、

10月7日の午後から今日の午後までの実行結果、大勢に影響ないけどファイルの日付がなぜこうなるかは理解できていない

青は省電力がほぼ効かない状態での測定、緑はlighsleepをデータサンプリング間隔(10分)で設定してとったデータ

電流測定では22mA vs 4mAだったけど、電池電圧の変化はそれ以上に見えてます、なぜだろう?

 

admin

Karel言語

Maker Faire Tokyo 2025でチェコの人たちが、四十年ぐらい前のマイコンボードを展示していましたが、そこのブラウン管ディスプレイに表示されていたのがKarel言語で記述されていると言っていました

じゃKarel言語って何なのと思ったのと、四十年前の言語が今も生き残っているのかというのは自然な疑問

実はちゃんと生き残っているようで、Pythonでも実装されていました

Pythonでの動かし方は、

% pip install stanfordkarel

でstanfordkarelをインストールする、なぜstanfordの名前がついているかというと、stanfordで学生の授業に使われたという経緯があるからのようです

以下のコードを見ればわかるように、forループはPythonのような形式、ロボットを動かすところは直感的なステートメントになっています

from stanfordkarel import *

def main():
    n = 4
    for i in range(n):
        while front_is_clear():
            move()
        turn_left()

if __name__ == "__main__":
    run_karel_program()

実行は、

% python karel.py

で起動しますが、ソースを見てわかるようにmain()が直接起動されるわけではなくて、run_karel_program()でプレイグラウンドが起動されて、起動されたプレイグラウンドからmain()を呼び出す形式を取ります

以下は実行させてみた動画

実はプレイグラウンドのカスタマイズもできるようです

KarelのキャラクタがGopherに似てる気がしますが、直接の関連は無いようで親しみやすいキャラクタを使うというところが共通点のようです

小中学生のテキストベースの学習言語としても面白いかなと思います

 

admin

そこにも落とし穴あったか、(ラズピコmicroPython)

ラズピコのmicroPythonで以下のようなコードではRTC割り込み受け付けられません

つまりlight sleep()で無限に待つ設定にして、RTC割り込みを受けようとしてもラズピコのmicroPython実装では、lightsleep中は他の割り込み受け付けは機能しません

    try:
        while True:
            if alarm_triggered:
                alarm_triggered = False
                clear_alarm_flag()
                time.sleep_ms(5)
                set_alarm()
                value1 = round((adc0.read_u16() >> 4) * 3.3 * 3 / 4096, 2)
                value2 = round((adc1.read_u16() >> 4) * 3.3 * 2 / 4096, 2)
                print(value1, value2)
                if value2 > 2.0:
                    logger.write(rtc, value1, value2)
                machine.lightsleep()
    except KeyboardInterrupt:
        print("terminated")

従って、やりたい機能を実装しようとすると、

machine.lightsleep()でRTC割り込みと同等の値(最大値)を設定してやらないとダメ、電池寿命計ろうと思って無限待ちにしたら最初のRTC割り込みしか実行されず、それ以降のRTC割り込みは発生しなくなってしまった

まあラズピコの実装レベルはその程度のようです

 

admin