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

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

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 ボードを2枚載せているもの、<うそでし。1枚。いろんな情報が錯綜している。なんで dual_chan_pkt_fwd を使うんだよ!!>、、、みたい)テストを続ける。そのまえにいろいろ調べないとダメじゃん、、、

 

ということで、Dragino のマニュアルにある dual_chan_pkg_fwd.cpp を眺めてみる。このソフト、なにをしているかというと、2つの 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 としてばらまく。ってところかな。これからちゃんと理解していこうと思う。

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