作者別: wpmaster

LoRa評価キットについて質問がありましたので、オンラインショップの方に若干説明を補足しておきました。

簡単に申せば、本製品は”LoRaWAN”プロトコルは搭載しておらず、ターミナルソフトウェアでLoRa変調の送受信の実力を確認するためのキットです。

同梱の無線モジュール内のソフトウェアを開発すればLoRaWANプロトコルに対応できますが、それを開発しようと思う方、できる方は既に相当なエキスパートですのでここで詳しくは述べません。

LoRaWANに代表される、LoRa変調を使ったプロトコルを独自開発したいと言う方はお問い合わせください。できるだけの対応はさせて頂きます。

「国内928MHz版のEnOcean Piは出ないのですか？」と言う質問がありました。”EnOcean Pi”とは、Element14社が、Raspberry PiでEnOcean無線が受信できるように開発した小型基板です。2017/3/27現在国内向けに発売されるとの情報はありません。通常はUSB400Jで用が足りるのですが、EnOcean Piだと小型でケースの中に納まるメリットがあります。

そこで、万が一TCM410Jを使った国内版EnOcean Piを起こしたい方のための情報をここに示しておきます。因みに当社では以下の動作は確認済みです。

１）Raspberry PiのGPIOとTCM410Jの間で最低限必要な接続は、3.3V, GND, TXD, RXDの４本です。

Raspberry Pi
GPIO(1)=3.3V
GPIO(6)=GND
GPIO(8)=TXD(Raspberry Pi -> TCM410J)
GPIO(10)=RXD(Raspberry Pi <- TCM410J)

TCM410J
VDD(2)
GND(1)
ADIO6(15)=RXD(TCM410J <- Raspberry Pi)
ADIO7(16)=TXD(TCM410J -> Raspberry Pi)

２）Raspberry Piから動作を確認します。
このサイトからRaspberry Pi talks EnOceanというWhite Paperをダウンロードしてきてください。

2.4.2 Connecting with Element14 EnOcean Pi HATの項にて、GPIOのシリアルポートを無効にしてください。

2.4.3 この項の前半はRaspberry Pi3の場合に実行を要します。Pi2以前の場合は、後半の
stty -F /dev/ttyAMA0 57600
hexdump -C < /dev/ttyAMA0
を実行後、ロッカースイッチを押すなどして無線を受信させ、コンソールに表示が現れれば正しく動作していることを確認できます。

ここまで

標記の件です。

１）Channel settingsをpublicにします
２）WordPressの設定はここに記載の通りです

以上のようにThingSpeakに送ったデータがWordPress上に表示できるようになりました。因みに上に表示しているのはBME280というセンサーで測った当社事務所の気温、湿度、気圧です。

ここまで

弊社は所謂IoTシステムの中で一番下流の、センサー値をクラウドに送るまで、を手掛けています。

センサー値を拾ってクラウドに送るまでの主にハード、無線等の技術を評価し確立しておきたいのですが、そのためにクラウドにセンサー値を貯めて、表示して、スマホアプリに送って、等々のシステムを構築するのは大仕事で完成するのを待っていられません。

そこで、可能な限り安価もしくは無料で簡単に使えるクラウドサービスが欲しくなるのですが、適当なものを見つけました。ThingSpeakです。

まずはゲートウェイもどきを作ってThingSpeakに表示させるところまで確認して、その次にセンサー値をゲートウェイ経由でThingSpeakに表示させるところまで実現してみたいと思います。

今日はここまで

最近、無線が飛ばない、繋がらない、時々切れる、等々の相談を受けるケースが多々あります。最近特に多いのがBluetooth Low Energy（以下、BLE）のトラブルで、スマホがBLEを受信できて、そのアプリを作るのも以前に比べると容易で、チップやモジュールが手に入りやすく電子工作レベルでも扱えるようになった、等の理由によるものでしょう。

ところが、プロとして製品に組込んで販売する場合、安定した通信を保証したい場合には注意してほしいことがあります。

それは送受信の両方に責任を持てる人を（自社他社に限らず）アサインするべきと言うことです。対スマホだと割り切らないといけないケースが出てきますが。より具体的に言えば、同一人物（同一組織）が送受信に責任を持てるような体制を作ってから開発・設計をスタートすべきと言うことです。それには同じメーカ・代理店から送受信モジュールを購入し、同一人物がＦＡＥとして面倒を見ることができる体制にするのが基本でしょう。ときどき「BLEが分かる技術者を付ければ大丈夫だろう」みたいなことを言う人がいますが、送受信それぞれのチップ・モジュールのハード・ファームの詳細を把握してなおかつ異なるベンダー間の課題を解決できるような人がいるわけがありません。偶然、その問題が解決することはあるでしょうが、どんな問題が起きてもいつでも解決可能かどうかは分からない。技術確立をする前に、もしくは技術確立をするのと並行して商品企画を進めるのは否定はしませんが、コスト優先で扱いにくいチップもしくは送受信のメーカが異なって両方面倒を見ることができない体制で進めるのは危険だと言うこと。

無線に関する仕事のクオリティを上げ、自分たちは他の仕事に専念できるような体制を取るべきです。

ここまで

当社は所謂「無線センサー」のベンダーを自称しているので、「無線インターフェース」の市場動向・開発動向を気にしながら仕事をしています。

もう一つ気にしている規格がセンサー・デバイス、例えば温度、湿度、照度、気圧、人感、ドア開閉、等々を検知するデバイスと、コントローラボードとの間のインターフェースです。ここでは「センサー・デバイス・インターフェース」としておきましょうか。

「センサー・デバイス・インターフェース」の電気仕様には主なものに、SPI, I2C, UART, GPIO、等々があるのですが、プロトタイピングをする際に気にしなければいけないのがコネクタの物理仕様です（そのデバイスを使うことが決まっている基板を起こす場合、以下の議論は不要です）。なぜならコネクタで取り外しが簡単にできないと、ブレッドボードを使ったりはんだ付けしたり、制御のためのソフトウェア・ファームウェアを書く以外に余計な仕事が増えるからです。設計が一通り終わった後、思った通りに動かないときいちいち自分が工作した部分を疑わないといけないのは辛いでしょ。

今までSeeed Studio社の４ピンのGroveコネクタに注目していましたが、最近Digilent社の策定したPmodという規格を知って、汎用性・拡張性に優れ、基板に固定できる（Groveはケーブルで繋ぐ）、などから、IoTのプロトタイピングに向いているな、と感じました。

まだ流動的ですが、今日はこんなところです。

無線通信が時々切れるときには・・・