M5Stack 3GモジュールでUDP通信 〜ATを呼ぶもの〜

　m5stack + 3Gモジュール、とても良い。マイコン一つでデータをクラウドへ送信できるので非常に便利。でもさ、ちょっと通信量多すぎないか？

　12月は100回程度通信した時点ですでに500kiBほど使用していた。（写真は最近のデータも含む）　1回の送信で5KiB！？　多すぎ！！これはどういうことか。サポートへ問い合わせてみた。

当社では通信の秘密よりお客様の通信内容は確認できないのですが、500 KiB であれば極端に多いとは言えないかと存じます。（一部抜粋）

　毎度のことながら返答が早い。ありがとうございます。

　やはり通信プロトコルの影響が大きいのかもしれない。利用しているのはHTTPというもの。これはよくわかんないけど、送信するデータが多くなってしまうらしい。

　対してUDPというものがある。これはデータを送信しっぱなしなので、応答の確認はしないので信頼性は低い。しかし送るデータが軽量なので通信量が低く抑えられる。なるほど。追跡機能がついた宅急便か、ゆうメールかの違いというところか。

　あれ、でも今使っているTinyGSm　はUDPには対応していないぞ。

　お問い合わせいただきありがとうございます。

　M5Stack 用 3G 拡張ボードが搭載する通信モジュール u-blox 社 SARA-U201 は UDP 通信に対応しておりますので、直接 AT コマンドを実行いただければ UDP もご利用いただけます。(おそらくご利用になっていると拝察する TinyGSM が UDP に対応しておりません。)

　詳細は AT コマンドのマニュアルをご参照くださいませ。具体的な実装方法などは当窓口からはご案内できませんが TinyGSM ライブラリの sendAT 関数を利用すると AT コマンドを実行いただけるようですのでご検討いただければと存じます。

u-blox cellular modules AT commands manual

https://www.u-blox.com/en/docs/UBX-13002752

ないならつくればいいじゃない！！

　そこでATコマンドの出番である。これはむかーしのモデムにも使われていた命令であり、送信などができる。じつは3Gモジュールの中に入っている　sala u-bloxはこのATコマンドが実行できる。
　tinyGsmのコードをgithubから眺めるとそれらしいところがいくつかあった。

GitHub - vshymanskyy/TinyGSM: A small Arduino library for GSM modules, that just works

いでよATコマンド

プロトタイプ向けマイコンモジュール M5Stack と 3G 拡張ボードをセットアップする | Getting Started | SORACOM Users
まずはこのコードを実行する。m5stack 3gモジュールからsoracomハーベストへデータを送信する。10秒おきに。結構頻度が多いね。

ここでシリアルポートをのぞいてみよう。
....

ちょっとよくわからない。

というわけで、まずはATコマンドを見てみよう。いいのがあった。

C:\Users\ユーザ名\Documents\Arduino\libraries\TinyGSM\src\TinyGsmCommon.h

ここに入っているヘッダファイルを修正するらしい。

    void sendAT(Args... cmd) { \
    streamWrite("AT", cmd..., GSM_NL); \
    stream.flush(); \
    TINY_GSM_YIELD(); \
    /* DBG("### AT:", cmd...); */ \
  } \

　このコメントになっているのを表に出すらしい。

うわ、なんか出てきた！！！　なんだこいつは。

貼り付けながら見てみよう

[751] ### AT: 
(中略)
[4044] ### AT: +CFUN=16
[7404] ### TinyGSM Version: 0.7.9
[7404] ### AT: 
(中略)
[9800] ### AT: E0
[9804] ### AT: +CMEE=2
[9811] ### AT: +CGMI
[9816] ### AT: +GMM
[9821] ### Modem: u-blox SARA-U201
[9822] ### AT: +CPIN?
[10829] ### AT: +CPIN?
[10836] ### AT: I
[15854] ### AT: +CGREG?
(中略)
[18405] ### AT: +CGREG?
[18413] ### AT: +UPSDA=0,4
[18422] ### AT: +CGATT=1
[18428] ### AT: +UPSD=0,1," soracom.io "
[18434] ### AT: +UPSD=0,2," sora "
[18439] ### AT: +UPSD=0,3," sora "
[18445] ### AT: +UPSD=0,7,"0.0.0.0"
[18449] ### AT: +UPSDA=0,3
[52031] ### AT: +UPSND=0,8
[52038] ### AT: +CGREG?
[52044] ### AT: +UPSND=0,0
[54088] ### AT: +USOCTL= 0 ,10
[54095] ### AT: +USOCR=6
[54101] ### AT: +USOSO= 0 ,6,1,1
[54106] ### AT: +USOCO= 0 ," beam.soracom.io ", 8888
connected.

なるほど。どうやら、

[起動後の時間] AT  

という流れらしい。

これとu-bloxのatコマンド一覧を眺めてみよう。

https://www.u-blox.com/sites/default/files/u-blox-CEL_ATCommands_%28UBX-13002752%29.pdf
呪文か。

以下のブログで紹介されているやりかたで、ATコマンドを打ちながら試していこう。
デバッグモードを使いながらやっていく

ATコマンドの紹介

AT: +CFUN=16

> Selects the level of functionality fun in the MT.
p45

なるほど。わからん。なにかのスイッチをリセットしているらしい。

AT: E0

全くの不明。

AT: +CGMI
AT: +GMM

製造社とモデルを表示してくれる。 p35

AT: +CMEE=2

これはエラーモードの設定。

 AT: +CPIN?
 AT: +CGREG?
 AT: I

　SIMにデバイスの保護がなされているかを確認。CGREGはGPRSネットワークの確認らしい。AT Iは製品情報が表示される。

よしよし。

AT: +UPSDA=0,4

指定されたPSDアクションを返すらしい。なんとことかわからない。

AT: +CGATT=1

GPRSへの接続をON-OFFしている。

AT: +UPSD=0,1," soracom.io "
AT: +UPSD=0,2," sora "
AT: +UPSD=0,3," sora "
AT: +UPSD=0,7,"0.0.0.0"

　パケットスイッチをなんか切り替えるらしい。パケット通信のなにかを設定しているのかな。

AT: +UPSDA=0,3

　パケットスイッチに関するアクションをしかけている。なんぞ。

AT: +UPSND=0,8
AT: +UPSND=0,0

　パケットスイッチに関する何かを確認している模様。

AT: +USOCTL= 0 ,10

通信を許可している。10はTCP通信の許可らしい。

AT: +USOCR=6

ソケットを作っている。6はTCP通信のソケット。

AT: +USOSO= 0 ,6,1,1

ソケットのオプションを設定している。

AT: +USOCO= 0 ," beam.soracom.io ", 8888

ソケットへ接続している。

UDP通信をするにはどうすればいいか

　というわけで、上のコマンドを行った後にpayloadをpostしてやればHTTPはできる。では、UDPはどうすればできるか。以下の通りだ。

AT +USOCR=17

AT +USOCO=1,"uni.soracom.io",23080

AT +USOST = 1,"uni.soracom.io",23080,1,"1"

UDPソケットをつくり、ポートを指定。そうしてバイトを送信する！！
こんなかんじ。そして、TinyGSMを使用しているなら、harvestへ送信したプログラムに以下のコードを追記すればATコマンドが送信できる。

modem.sendAT(GF("+USOCR=17"));
  delay(1000);
  modem.sendAT(GF("+USOCO="), 1, ",\"", host, "\",", port);
  delay(1000);
  modem.sendAT(GF("+USOST="), 1, ",\"", host, "\",", port, ",", 1);
  delay(1000);
  
  modem.stream.print("0");

やったね！

通信量の比較

　かなり下がった！　2月は800回ほどデータ送信をしたが、全体の通信量は130KiBくらい。一回あたり160Biくらいか。前の5KiBに比べたら約1/30になった。うれしいなぁ。

次回予告

　さて、なんとかUDP通信はできたのだが、バイナリの様子がどうもおかしい。バイナリパーサーを通じて観測すると、0だと思って送信したものが0じゃなかったのだ。

次回、「疑惑のバイナリ〜アスキーコードの行方〜」

お楽しみに！！

Photo by eberhard grossgasteiger on Unsplash

分かっちゃいるけど、やるのは難しい /「エッセンシャル思考」

　書き始めが冬のことばかりになっている気がして、私自身が寒さを求めているのだなと感じた。それくらい今年の冬は暖かい。始発の電車で会社に向かう時、冷えた手を缶コーヒーで温めたりもしたいが、そういうほどでもない。だから私はセブンカフェのコーヒーを買うのか。あれおいしいよね。関係ないね。

　エッセンシャル思考を読んだ。目標を明確に！余分なことはしない！そうすればOK！そういう本だ。「そんなのわかっているよ」という声も聞こえるが、これはただわかっているだけではダメだ。実践を伴って初めて価値が生まれる。本を読んで、少しずつエッセンシャルな形が身についてきたので、記録しておく。

　まずは本質的な目標を定める必要があった。これはワクワクして、具体的なものがいいらしい。私はひとまず「IoTで10万円稼ぎたい！」とした。次に不要なものを捨てることにした。この捨てるというのは難しいのだが、なにか新しいことを始めるなら、なにかを捨てなければならない。私は自分に降りかかる仕事のうち、後輩に任せられることは任せることにした。これで自分のやりたい本質的な仕事（社内IoT化）に集中することができた。

　なにも後輩に全部投げるわけではない。目標と期日は明確に伝えた。具体的な方法は後輩も知っていたので、あまり細かく注文するのはやめた。重要だったり、期日が短い仕事は進捗を細かく追う必要があるが、それも最低限にした。時々フォローはするが、いまのところ案外うまく回ってきている。彼も着実に成長しているのだ。すばらしい。私はIoTをやるぞ。

　仕事で身につけたIoTスキルを個人活動でも生かせるようにしたい。そのために職場の仕事はIoTだけになるように努力している。

　捨てることができてきたら、自分のパフォーマンスを高めることを考える。エッセンシャル思考では睡眠時間の確保をうたっている。私は少し睡眠時間が少なかったので、会社の昼休みに10分ほど寝るようにした。これはどう変わっているかよくわからない。ただ、健康に対する意識は変わった。今までは風邪をひいいたら治すくらいにしか考えていなかったが、今は風邪を引く前に体をコントロールするようにしていている。睡眠、運動、野菜、瞑想。瞑想はいらないか。

　あとはバッファをとる。ひたすらバッファをとる。予想してた時間の1.5倍をとるといい、と本に書いてあった。そういうわけで2,3日で終わりそうなことを1週間で行うような計画を立てた。やってみると、突発的な別のことがらや不具合がおこって、ほんとうに1.5倍の時間で収束することもあった。すごい。バッッファすごい。

　エッセンシャル思考は楽しい。楽しいことだけに集中して日々を過ごしていたい。

（Photo by Dan Meyers on Unsplash）

エッセンシャル思考 最少の時間で成果を最大にする

kintoneの勉強会でLTをした話

　文章の淀みのようなものをすくってどこかに投げている、そんなことができているか。以前の文章のほうがどこかとげとげしさがあって、ずっとシャープでいた。それが良いか悪いかは別の話として、今は決して書けないのだろうなと気がついた。

　kintoneというグループウェアの勉強会があって、わたしはそこでLTをした。オフラインのイベントに参加するのは初めてだったが、わりとどうにかなった。
　題目はこれ。

kintone でわくわくIoT~広がる無限の可能性~ from Kkondo2

www.slideshare.net
kintone Café 広島 Vol.17@広島 - connpass

　IoTをやっていく上で、データの表示はkintoneにまかせるといいよ！という話をした。多くの準備はできなかったが、反応はよかった。嬉しかった。その日のためにつくった名刺を、何人かの人と交換した。嬉しかった。けっこう経験値を得た気がした。そういうことだった。まずは手を上げないとはじまらなかった。「今年はオフラインのイベントに参加したいな」と考えていたところに、勉強会が開催されるという通知が来た。LT枠が空いていたので思い切って申し込んだ。「どうやるか」はそのあと考えることにした。

　手を上げまくる日々が続いている。先月は毎週がチャレンジングなものだった。けど、それをあまり自分で意識しなくなってきた。わりといい兆候だと思う。

　今年中にIoTの勉強会を開きたい。みんなでくだらないものを作ってわっしょいやっていきたい。

Photo by John Fowler on Unsplash

広く深く楽しいIoTの本 /IoTエンジニア養成読本 設計編

　難しく考え過ぎていた。雪は降らなかった。当たり前と思っていたことがそうではなかったりした。日々の暮らしにいくつかの句読点をうち、私はそれを読み進めていく。IoTが熟成していく。日本語もままならない。
　「IoTエンジニア養成読本　設計編」を読んだ。非常に養成された。ここまで広く深くIoTに言及している本はないのではないか。どこか皆IoTを未来っぽい技術だと思って、距離を置いて発言してるがこれはそうではなかった。IoT使われるデバイス、通信、クラウド、セキュリティ、それらが散りばめられている。自分の中でなんとなく頭に入っていた言葉たちが体系化されてきた。この感覚は久しぶりで興奮する。

　前にも書いたが、IoTは全ての知識を頭に入れておく必要はない。そして全ての技術を自分で開発する必要もない。大切なのは生産性の向上である。IoTをやって、自分や周りが豊かになればそれでいいのだ。お金をかけてもいいなら、既存の良いサービスを使ってしまおう。クラウドやデバイス、良いものはたくさんある。私がおすすめするのはM5Stack + soracom である。これでだいたいのデータは可視化できてしまう。機械学習やエッジコンピューティングとかをやろうと思ったらAWSやラズパイが入ってくるだろうが、それはまたそれの話。

　この本に書いてあることもやりながら学んでいけばいい。

　つまり、自分の得意な領域だけでなく、センサーからの情報取得方法、組み込みコンピューティング、ネットワークの設定、クラウド、判断のためのアルゴリズムや機械学習など、多岐にわたる知識と技術を一定レベルで習得しておけば、自らの手で新しい価値を生み出すことができる可能性ができるのです。

「IoTエンジニア養成読本　設計編」p150

　そうだね、そのとおり。

IoTとセキュリティ

　本書にも書かれていたが、IoTにはIoTならではのセキュリティ上のリスクがある。デバイスが小さく、マシンパワーが小さい。そして保守が困難な場合が多い。誰かがさーと持ち帰ってしまうかもしれないし、デバイスに複雑な暗号処理をさせるようなことは難しい。どうするか。

　経済産業省がIoTセキュリティガイドラインを発表している。
IoTセキュリティガイドラインを策定しました（METI/経済産業省）

　これをふまえて、セキュリティを色々考えていくといい。社内の啓蒙や、ロギング、リリース後の保守などさまざまなことが書かれている。

　ざっくりと本を紹介した。楽しい本だった。今後もざっくり本の感想を書いていくぞ。

Photo by brandon siu on Unsplash

IoTエンジニア養成読本 設計編 (Software Design plusシリーズ)

機械設計とプログラミングはちょっと似てる/「リーダーブルコード」

　加工機の切削音が私の体を揺らしていた。六軸のロボットたちは今日もげんきに部品を振り回して、それぞれにセットしている。ブロワとときどきのアラーム音。私はここで生きている。あるいは文章を補給しなければならなかった。自身の中の言葉はとうの昔に枯渇していて、私はだれかのセリフをそのまま伝えるだけのテープになった。ここでメモを書こう。

　リーダブルコードを読んだ。より良いコードを書くためのテクニック、とうたっているだけあって、いろいろと優れていた。共感したのは「優れたコードは理解しやすいコードである」ということだ。たしかにそうだった。コードは機械だけではなく、人も読むものである。なにかを共同でつくるとき、保守するとき、コードは自分以外の人に読まれる。そのときに理解に時間がかかってしまうものではダメなのだ。自分以外の人とは数ヶ月後の自分も含まれる。

　後半の章は、わたしのレベルではまだまだ活用できそうにないが、前半のものはすぐに適用できそうだ。変数名や関数名をもっとわかりやすいものにしたり、コメントをつけることだ。類語辞典を使って、もっと明確な意味がないか探すというのは「なるほど！」と思った。

　本書が述べている「優れたコード」の価値観は、機械設計でも適用できる。図面をかくときも、わかりやすいものでなければダメだ。寸法の抜けがあったり、基準面が一致していなかったり、加工の実現性のないものをかいてはダメだ。

　ただ、もっとも優れた機械設計というのは設計しないことだ。わたしたち技術者はの仕事は、技術的な問題を解決することだ。図面をかくのが仕事ではない。設計せずに問題が解決できるならこんなに素晴らしいことはない。購入品で済ませる、ありもので済ませる。これらのことを考え抜いて、それでもだめなら設計する。きっと、コードをかくときも、こんなイメージでいいのではないか。

　リーダブルコードの全てを理解してつかいこなすのはまだまだ時間がかかりそうだ。けれども、手元にはあったほうがいい。わからないことがあったら、少しずつこれで調べていこう。

Photo by Tedward Quinn on Unsplash

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)