新千葉 ガーベージ・コレクション

FPGA マガジンやインターフェースで書けなかったこと等をちょぼちょぼ書いてます。@ryos36

ついでに LMIC

も～

arduino の LMIC のライブラリは初期値が EU868_F1 とかになっていて日本では当然使えない。これ、この部分の lorabase.h を変更している人がいて、ん？と思って調べてみる。 lmic.c のソースでは initDefaultChannels でこの初期値を変更可能なテーブルに入れている。で以後、必要なら LMIC_setupChannel という関数で変更可能なようだ。これでいけるんじゃね？で、無理やり、全部おなじ freq のにしてたりするけど、それでいいのかね？どうも GW を作るときはちゃんとそのバンド設計をしないといけないみたいね。この辺はきっと LoRaWAN の仕様書見ないといけなさそう（確信はないけど）。

そして、lmic の LMIC_setupChannel をみると自動的に enable になるみたいだ。ってことは disable もあるのか？あるね、LMIC_disableChannel 。これで必要のないものを Disable すればよいと。送信はどうなっているんだろうね？

LMIC はなんか、RICH な OS を期待しているみたいで、コールバックというかイベントベースのプログラムになっている。う～ん。こういう中初夏が入った C のソースって読みにくいんだよね。ポインターで分断されちゃうから。まぁ C++ もそうか。osjob というのをどっかでコールバックする仕組みがあるはずなのだが、、、、ん？コールバックは１っ個？あー job が queueing されるみたいね。

なにおっているのかわからなくなった。なんで、fork しないのかな、、、バージョンがわからなくなるぜ。

どうも作者の Matthijs さんはソース読まずになかのソースを改変する(API があるのにつかわない)のでコメントにそう書くようしてありますね。

あ、selectSubBand で使わないのは disable されているじゃないか。も～。だから、ちゃんと LMIC_setupChannel で GW の設定をここにかいて、selectSubBand でそのうちの１つをセレクトするという設計になっている。

なんかよくわからんが最終的に starttx を呼ぶみたい。パッと見た感じ、LBT の処理はしてなさそうだけど。

ただ、LORARegRssiWideband を読むと rssi よめるみたいね。これでチェック可能かな？

LBT と SX130x

どうやら、最近(2021 1月) に出回り始めた SX1302 のボードは LBT に対応したボードがあるらしい。いやもともと SX1301 でもあるみたいだが、LBT 対応の為には FPGA がついていることが前提のようだ。どうやら Semtech の GW のリファレンス・デザインというのがあって v1.5 以降は FPGA がついているようだ。Semtech の github の loragateway のソースを見ると FPGA のファームとして hex ファイルがあって、その ReadMe にはボード上の ROM に焼く？ためにあるようなことがかいてある。

ソースを読むと SPI のある領域が FPGA にアクセスするためにあるみたいなので、一旦、MCU の SPI で受けて、それを SX1301 と FPGA に振り分けているのだろう（確信はない）。

で、最新の SX1302 のボードには FPGA が見当たらないように見える。ので SX1302 には FPGA の機能が入ったか、あるいはやっぱりボードの上に FPGA がある？ということらしい。真偽は定かでない。

Semtech のリファレンスデザインを見て GW を作っている人がいる。SX1301 をつかっているようだ。

Can this module do LBT ? Listen before talk ? · Issue #16 · will127534/LoRa-concentrator · GitHub

LBT をサポートするには FPGA と SX1278 がいるみたい。と書いているが SX1278 はおかしいな。まぁいずれにせよ、SX1301 には FPGA が必要だろう。したがって、なんちゃって GW を SX1301 + ラズパイで組み立てようと思っていると、日本ではかなり厳しい(LBT が必要だから)。SX1302 を待つというのが正解か？

手元にある HAT は SX1301 すらはいってない SX127x が２つというものなので、自分で LBT 組まないといけない。こちらはほぼ Device なので、GW ではない。

GW では複数の受信をするために SX130x が必要で、さらに LBT には SX1301 + FPGA or SX1302 が必要という事。Device は複数受信の必要がないせいか、単純にFPGA なくても LBT は出来そうだ。

www.murata.com

"Listen before talk" can be supported. LBT means that device will enter Rx mode and check the interference signal level before starting the transmission.

と murata さんが言っているのだから大丈夫だろう。

とりあえず device 側は単純に Rx mode にして "check the interference signal level " ということをすればよいということが分かったのが収穫。

LoRa と LBT

LBT(Listen Before Talk)

Transmit じゃないのか、、、というのはともかく、日本の法律では LBT しないと送信できなかったらしい。

https://qiita.com/tanupoo/items/18803245cb6130095729

この qiita の記事によると法改正があって条件付きで LBT しなくてもパケット送信が出来るようになったらしい。 裏を返せば、法改正前は LBT なしで送信するのは法律違反ということになる。 もしそうなら、これ、事実上今まで LoRa は扱えなかったはずだ（私も含めて）。

むかしの Ether のコリジョン判定と同じで恐らく送信しながら観測して、コリジョンを発見するとランダムな時間休んでから再送信ということをしないといけないはず（たぶんね。根拠なし）。そうすると通常の送信は使えず、どうやら FPGA つかって判定するみたいだぞ。そういうレベルで判定してもらわないとできないはずだ。チップにその機能があるとかが必要という事。

LoRaWAN 的には（法律の外）送信側は特に最初に送出するタイミングの規定はないみたい。もちろん、送出後のおくってはいけない時間というのはあるだろうが。

"3GPP では，チャネルアクセス方法として，以下の四つのカテゴリーを定義"という記述をみつけた。このカテゴリ4といのが LBT らしいぞ。「送信前に所定の範囲内からランダムに値（ランダムバックオフ）を生成し，固定のセンシングスロット時間でのキャリヤセンスを繰り返し行い，生成された値の分だけチャネルが空いていることが確認できた場合に送信．ランダムバック オ フ 値 の 生 成 範 囲（Contention window size）は他システムの通信との衝突による通信失敗状況に応じて可変」(https://www.jstage.jst.go.jp/article/bplus/10/2/10_80/_pdf) う～ん。なにいっているかわからない。

しらべるとこんな資料も出てくる。 https://www.soumu.go.jp/main_content/000627919.pdf

「日本は、キャリアセンスが必須（2019/6/18 の資料）」ということで キャリアセンス = LBT は必須ですね。(過去形にしていいのかどうか)。

単純に今送信していたら送信を邪魔しないとすれば FPGA いらないな。これでいいのか。LBT は。ということはどっかにソースがあるというはなしだよね。むむむむ。（続く）

LoRa と TTN

LoRa をつかって thethings network(TTN) につないでみた。いろんな情報が錯綜しているので、技術的に地に足がついた情報をそろえたい。LoRa と LoRaWAN がごっちゃになりそうだが、LoRa デバイスをつかって LoRaWAN のパケットをやり取りするのが目標。

まず、TTN 。Console に login して Gateway を作るのは簡単。で Gateway(GW) というのが曲者。LoRaWAN で規定されている GW は 8ch だっけを受けることができるもの、、、という規約があった気がする（要確認）。この GW は誰に対して何の GW なのだろうか？という疑問も生まれる。

TTN の GW を作ったあとにはちゃんと connected なってほしい。TTN の規約（というより元は Semtech の UDP Packet forwader かな？)では stat パケットを UDP で送ることになっているらしい。指定されたドメインである .thethings.network で終わるホストに stat パケットを送る。日本では asia-se.thethings.network のようだ。ところが、この asia-se.thethins.network の 1700 へ UDP パケットを送っても一向に connected にならない。ここでまず躓いた。UDP の問題なので LoRa の話以前の問題だ。いろいろ試した挙句、 router.eu.staging.thethings.network (う～ん staging だ)なら connected になることがわかった。router.eu.thethings.network でも NG。そのうち、解消されるか、整理されるかしてちゃんと動くようになるのだろうが、現時点では注意が必要。もしかしたら、connected にならなくても packet のやり取りのログは見れるのかもしれない。

なお、使ったソフトは dragino 社が github で公開している gwstat.py である。

stat は定期的に送る必要があるらしく、しばらくほっておくと not connected になる。

話は前後するが、GW の ID というのものを作らないといけない。あ～ここで、Legacy の packet forwarder にチェック入れたからか、、、たぶん、新しいサイトには新しいプロトコルで connected しないといけなんだ、、、（たぶん。根拠はない）。つまり、Legacy なのは(今後は)だめと。thethings network 側もちゃんとした GW じゃないと受け付けないよ。staging なサーバはやがて消えるのでしょう。

で、自分の持っている dragino の製品は Legacy なので、GW の ID を mac address から生成している。EUI-48 の mac address を EUI-64 に拡張解釈するときにまんなかの 16 ビットを 0xff 0xff あるいは 0xff 0xfe にするという規約。この規約がどこにあるのかみつけられなかった。いま ieee.org をさがすとそれっぽいのはみつかる。どうも、ローカルな時にだけ使えるぽい。つまり、バッティングする可能性はある。今後はちゃんとした GW が普及すれば、こういうのは非推奨になるのでしょう。今は過渡期か。

で、なんちゃって GW を使い続けているのが悪いという結論に向かいつつあるが、話は続ける。

Rpi + Dragino の HAT で(これはどうやら Dragino 社が大好きな SPI 接続の LoRa ボードを２枚載せているもの、＜うそでし。１枚。いろんな情報が錯綜している。なんで dual_chan_pkt_fwd を使うんだよ!!>、、、みたい)テストを続ける。そのまえにいろいろ調べないとダメじゃん、、、

 

ということで、Dragino のマニュアルにある dual_chan_pkg_fwd.cpp を眺めてみる。このソフト、なにをしているかというと、２つの frq から read して TTN のサーバに投げている”だけ”。つまり、GW の中継はしていない。最初の、GW の役目（かも）というところでの疑問がこれ。まぁこのソフトは GW じゃないのでしょう。でも有益ぽい？

これで LG01 用の single_pkg_fwd も意味が分かってくる。こいつはちゃんと GW ぽいことしている。packet read して /var/iot/data へ保存。message[0] == 0 なら /var/iot/dldata があるはず？なので、それを読んで LoRa パケットとして送信する。で、あとは txfreq に 5回送信している。う～ん。なんかおかしい。本当は各 freq にばらまくんだろうね。これをみていると、UDP で来たものをばらまくのは当然として、他のデバイスの物も LoRa としてばらまいているように見える。まぁ確かにそうしないと、ことなる freq にいる人は気が付かないからね。ただ、ソースが間違っているか見落としがあるのか、、、、

そうか、これはおそらくクラスAの実装をしているのだ。uplink に送信した時のみ dwlink できると。

 

たぶん、これをみると GW の責任は、UDP でネット(internetね)にも通知する。ネットから来たものも LoRa としてばらまく。ってところかな。これからちゃんと理解していこうと思う。

今日のところはこんなところか。

KiCad Again

KiCad あまりつかわないうちに V5 になってしまいました。で V4 を削って、V5 にしました。どっかの情報に、そのまま V4 をアンインストールせずに V5 にせよと書いてありました。 それとは別に V4 の情報が残っていると、どうやら V5 で混乱するみたいです。特にフットプリント。うまく、新しい V5 のフットプリントを参照してくれません。いろいろ調べると、KiCad はいろんな情報をユーザの領域に残しているようです。まぁそうですよね。立ち上げた瞬間に直前の回路図出るし。（ここで気がつけばよかったのだ、、、） で、その情報が V5 のフットプリントの読み込みを邪魔しているようなので、思い切って削除してみました。V4 の資産がある場合はなかなかできないでしょう。私はV4 の資産がゼロだったので、削除してみました。 https://make.kosakalab.com/eda/kicad5_fp-lib-table/ ここの情報が役に立ちました。

いろいろ書きました。

CUDA + meson

そういえば CUDA でいまや meson 使うようにしたんだっけ。

cuda_comp = meson.get_compiler('cuda')
cuda = import('unstable-cuda')
cuda.nvcc_arch_flags(cuda_comp, 'All')
nvcc_flags = cuda.nvcc_arch_flags(cuda_comp, 'Common')

src_gpu = ['src/gpu/render_engine.cpp', 'src/gpu/render_engine.cu']

あと、いろいろまとめてみたよ。

www.sinby.com