• Netvox社(台南市)を訪問してきました

     

    コロナが落ち着きやっと海外に出張できるようになりました。今回はLoRa製品で取引きの多い、台湾のメーカー数社を訪問してきました。札幌から台北行きのLCCタイガーエアーはこの時期往復39,000円弱と、東京出張と変わらない値ごろ感です。

     

    訪問したのは、LoRa対応センサーで200以上もの製品をリリースしているNetvox社です。Netvox社はエリア人口180万超の台南市にあります。1995年設立ですが、6年ほど前からLoRa製品にほぼ完全シフトし売上げを伸ばしている会社で、工場は厦門にあります。業務分けは厦門で製造、ファームウェア・ソフトウェア開発、台南はAIを利用した開発行っているとの事。

    特筆するはNetvoxのビジネスモデルです。多品種少量販売で、コアユーザー数社が特定モデルを大量購入しているようです。そう聞くと多品種開発に大きな投資が必要かと考えますが、実際少ない種類の通信ジュール、アンテナ、筐体で、センサーの種類だけ変え、効率的に開発を行っているようです。

    今年に入り複数のセンサーをつなぎ、LoRa通信でデータ送信できる端末をリリースしました。Netvox社の製品は屋内用途のセンサーが多く、弊社で取り扱う水質センサーや農業用センサーなど、本格的な屋外用センサーをLoRa通信で送ることができるような製品はありません。スマートビルディング向けの製品が多いです。モデル数が多いので、メーカーも売れ筋の数モデルしか在庫しておらず、納期が2週間から6週間かかります。6週間かかるようなケースは、大量注文があり工場が忙しい時期となります。どういう時期に大量注文発生するかわからないので、正確な納期がなかなか答えにくいメーカーではあります。

     

    今回の海外出張でうかつだったのは、「日本に帰る際に航空会社で、ワクチン接種証明の提示を求められる」ということを知らなかったことでした。台湾も旅行緩和したため、事前調査をさぼっていました。「接種証明アプリ⇒マイナンバーカード読み取りで証明書発行」で何とか事なきを得ました。

     

    電子マネーマニアとして、以下の情報を共有しておきます。

     

    セブンイレブン・・・Appl Pay利用可

    ファミリーマート・・・Apple Pay不可

    台北駅コインロッカー・・・Line Pay利用可 ただしクレジットカードとの紐づけ要

    台鉄台南駅・・・Apple Pay利用可

    台北市内MRT・・・悠遊カード(Suicaのようなカードで発行費がかかる)は使えるが

    クレジットカード、Apple Payなどは見つけられず、ちょっとした高額紙幣も使用不可。

    悠遊カードがないと不便。

    桃園空港線・・・悠遊カード(Suicaのようなカードで発行費がかかる)は使えるが

    クレジットカード、Apple Payなどは見つけられず、ちょっとした高額紙幣も使用不可。

    悠遊カードがないと不便。

    桃園空港内自販機・・・Line Pay利用可

     

    ちなみに私は国内ではLine Payはまったく使ったことがなく、今回の出張のためにわざわざクレジットカードとの紐づけを行いました。

     

    弊社では中国のメーカーとの取引きが多く、次回出張に電子マネーをどうするか悩み中です。銀聯クレジットカードを作ってみましたが、現地でクレジットカードを使っている人少なく、ほぼ支付宝と微信支付というスマホ決済が主流らしいです。日本でもダウンロード、登録できるようですが、抵抗感のある人も多いのか、中国出張者むけに決済用のスマホを貸出すサービスもあるようです。銀聯デビットカードは口座からの直接引き落としで、使い勝手が良いとの話を聞きました。そこで国内で発行可能ということで、中国K銀行の東京支店に行きました。受付の女性に発行してもらいたい旨伝えましたが、あからさまに「いやそうな」対応でした。まず口座を中国K銀行にもっていなければいけないということと、審査もあるという話でした。受付の人の対応では、申請しても相当時間と手間がかかると判断した次第です。引き続き調査し実際に中国出張した時にまた報告いたします。

     


  • 「北海道公共牧場職員春季研修会」で発表してきました

    北海道公共牧場職員春季研修会

     

    北海道公共牧場会 の研修会(札幌)で、弊社の放牧牛管理システム「うしみる」について発表を行いました。

    北海道公共牧場会は北海道での酪農振興を主な目的とし、肉牛、乳牛に関わる公共牧場間の情報交換等を目的としています。公共牧場は以前全国に1,200ほどありましたが、現在は700程度でかなり減少したようです。飼料価格高騰などで公共牧場の運営も大変ご苦労されているようです。

    今回の研修会における講師の方のお話の中で、牧草の話は特に興味深いものでした。長く伸びすぎた牧草は栄養がなくなり、短草になれるということが重要であるということを再認識しました。「ちょうどよい伸び具合」ではダメで、早めに採食させることが重要と講師の方は強調されていました。また講習の中で再度放牧の意義についても説明を聞くことができました。

     

    ―放牧のメリット

    ・強靭な身体を作る

    ・糞尿を肥料化させることができる

    ・衛生環境を高めることができる

    ・土壌の改善

    ・低コスト

     

    ―デメリット

    ・牛の怪我の可能性

    ・馴致が必要となる

    ・気象条件などよみきれない変動要素がある

    ・移動にお金がかかる

     

    またニュージーランドの事例でha当たりの適正な頭数についてもお話がありました。弊社「うしみる」では、任意に作成したエリアに牛が現在何頭いるか確認できる機能はあります。データを再利用することにより、ヒートマップを作製することもできます。「うしみる」の中に、それが標準機能として組込むことができればよいなと考えています。

     


  • 日本草地学会札幌大会で発表してきました

    3月28日(火)札幌で開催された日本草地学会で弊社の放牧牛管理システム「うしみる」についての発表を行いました。日本草地学会は草地農業の発展に寄与するため、草地および飼料作物に関する学術の進歩と知識の普及をはかるための学会です。

    https://grasslandscience.jpn.org/ (日本草地学会サイト)

     

    本年は札幌で大会が行われ、「スマート放牧監視の現状と課題」について企画集会が開かれました。弊社も「うしみる」についての発表をいたしました。すでに昨年度「うしみる」をご使用いただいた、熊本県草地畜産研究所、島根県畜産技術センター、農研機構西日本農研のご担当から実証例、活用例について発表がありました。発表の中に製造側としての「気づき」がたくさんありました。

     

    ・霧だけではなく、草の中で牛が見えないような環境で特定の牛をさがすのに有効

    ・放牧地が大きい方が「うしみる」使用で時間削減が期待できそう

    ・泥沼などにはまって動けない牛の救出に有効

    ・離島での放牧での事故率は弊社思うより高かった

    ・若い牛ほど予期せぬ事故に気をつける必要ある

     

    「うしみる」アプリで改修した方がよいポイントについても、意見をお聞きすることができました。これまで放牧牛用端末の毎年の電池交換が、酪農家様の大きな負担となっていました。弊社では20分間隔、夏季放牧で5年間利用可能な省電力「うしみる首輪」を開発いたしました。

     

    【うしみるプレゼンテーションファイル】


  • 斉藤牧場で放牧期間が終了しました

     

    雪虫も飛び始め、こちら旭川近郊も朝の寒さが厳しくなってきました。他の公共牧場様同様、弊社が実験で利用させていただいている 斉藤牧場 でも、牛の放牧期間が終了し機器の撤収に行ってまいりました。

    斉藤牧場ではできるだけ自然を残した山地で、牛たちにとり自由度の高い形で放牧を行っています。牛たちは早朝に自ら牛舎に戻り搾乳を受け、また自ら草地に戻り草を食み、横臥しまた夕方には牛舎に戻りす。旭川市も雪がちらつくようになり、牛たちは4月上旬まで、長い冬を牛舎で過ごすようになります。

     

    弊社では斉藤牧場の約25頭の牛に「うしみる」首輪を装着し実験に協力いただいています。本年度は牛舎にビーコンを取付け、牛たちが牛舎に戻りビーコンと紐づいた時に牛が戻ってきたことがわかるような機能の実験をしました。九州南部の島々などで自由放牧をされているような農家さんには役に立つ機能と思います。また加速度センサーによる発情検知の実験を行い、3軸加速度センサーで行動量が著しく上昇した際にアラートが来るよう仕組みを実験しています。牛舎飼いの牛と異なり、放牧牛では携帯電波の無いような3-4km離れた場所においても、牛のデータがゲートウェイに届かなければなりません。離れた場所から3軸加速度データ10Hzなどの生データをそのまま送信し、6カ月間以上電池が持つような、牛に装着できるような端末を開発することはできません。実際の牧場で使えるようにするためにはさまざまな「工夫」が必要となってきます。

     

     牛たちの退牧シーズンを迎え、弊社では現在「うしみる」をご利用いただいている農家さん、JA様、研究機関の方々にアドバイスをいただくために聞き取りをさせていただいております。来年度さらに「うしみる」を使いやすくすることができ、放牧業にいくばくかの貢献ができれば幸甚です。

     

     

     


  • TBSL1/LTE-Mをリリースします!

     

     

    マルチセンサーRTU「TBSL1」がLTE-Mに対応します。これまではセンサー測定値をLoRaWANにて送信していましたが、国内での導入実績ではそもそもLTE圏内であったりLoRaWANゲートウェイに対してTBSL1が1台であったりとLoRaWANであるメリットがありませんでした。そこで同じLPWAのLTE-M版をメーカと共同で開発いたしました。

    ※ LTE-Mとは、LTEの一部周波数帯域を利用したLPWA無線通信規格の一つです。
    ※ LoRaとは、免許不要920MHz帯を利用したLPWA無線通信規格の一つです。
    ※ LPWAはLow Power Wide Areaの略で、省電力で広いエリアをカバーする無線通信技術です。

     

    LoRaWANとLTE-Mの通信方式の違いについてのイメージ図です。

     

    LoRaWAN方式ではゲートウェイ毎にSIM契約が必要となり、LTE-Mではデバイス毎にSIM契約が必要となります。現場の通信環境、TBSL1の数によって2つの通信方式からお選びください。

    また、TBSL1/LTE-Mもソーラーバージョン、AC電源バージョンの両方をご用意しております。

    【TBSL1 製品ページはこちら】

     


  • 「うしみる」レンタル受付中!

     

    冬の長い北海道でもやっと春を迎え、公共牧場などへの入牧時期が迫っています。本日は「購入」ではなくレンタル方式のメリットについて書いてみることにします。

    レンタルやリースのメリットというと、まず頭に浮かぶのは、

    ・一度に多額の購入資金を用意する必要がない

    ・減価償却など煩雑な事務手続きがいらない

     という点です。しかし我々が全国の牧場とやりとりさせていただいて、見えてきたレンタルならではのメリットがあります。

     

    1. 最新のシステムをお貸出しできる

    弊社が2019年に「うしみる」開発を始めてから現在まで、今まで3種類の首輪(端末)の開発にたずさわってきました。防水性、頑丈さ、端末の挙動(ファームウェア)について数か月実験して初めてわかることも多いものです。放牧牛管理の難しさは製品を改良したからと言って、牛にすぐ取付けられるものでもないという点です。広大な草地に放たれた数百頭の牛の中から、弊社の都合で任意のタイミングで牛の首輪を交換できるものでもありません。

    レンタル方式のメリットは、レンタル時に最新のシステムを受け取ることができるという点です(レンタルですので「新品」ということではありません)。弊社が日々経験した課題により、改良を施した「その時点で最良であろう」システムをお渡しすることができます。過去には酪農家の方からのアドバイスで首輪の素材自体を変えたということもあり、レンタル品はそういったアドバイスも反映した最新のシステムと言えます。

     

    2. メンテナンス不良によるトラブルを回避できる

    電池式の端末では(上図右)では、経費削減の観点からお客様ご自身電池を交換される場合があります。ネジ締めトルクの問題で浸水が発生したり、逆に締め付けが強すぎてネジ部を破損してしまったケースがありました。弊社ではネジ締め時の注意事項などもご案内していますが、頭数が多い場合には複数名で作業を行うことにより、ネジ締め手順が一律でなくなる可能性もあります。レンタル方式では弊社で電池交換、首輪のメンテナンスを行います。お客様は不安なく、新年度の入牧時期をむかえることができます。レンタル方式は夏季放牧、周年放牧対応ですが電池式は20分毎の送信間隔で、6-7カ月間の動作期間となります。周年放牧においては7カ月目を目途に電池挿入済みの代替首輪をお送りいたします。

     

    3.初期設定済み、通信費込

    レンタル方式では初期設定済みで、毎月の通信費も含まれたシステムをお貸出しいたします。お客様がゲートウェイ用にSIMカードの契約、支払いを行う必要はありません。ゲートウェイを設置し、首輪を牛に取り付けるとすぐに「うしみる」アプリで牛を監視できる状態でシステムお貸出しをいたします。ゲートウェイの設置場所が充分に首輪と通信ができそうな見通しと距離にあるかどうかという点と、ソーラーパネルでの給電が必要かなどはレンタル申込時に打合せが必要となります。


  • 「NW-360HR」ウェアラブルLTE-Mトラッカー販売開始

     

     

    作業員の安全管理など幅広い用途に利用いただける
    ウェアラブルLTE-Mトラッカー「NW-360HR」を
    2022年1月5日にリリースしました。


    【NW-360HR特徴】

    ・LTE-M対応
    ・GPSによる屋外位置情報の送信
    ・BLEビーコンの受信に対応。ビーコンIDと位置情報をアプリで紐付けることにより、屋内で大まかな位置情報を取得
    ・心拍数、皮膚温度、歩数、歩行距離、消費カロリー及び電池残量の表示と送信
    ・ヘルプボタン長押しによる緊急アラートの送信
    ・転倒時に特定の条件(※1)を満たすと「転倒検知アラート」を送信
    ・定期送信、デバイス上で選択可能(1分、2分、3分、5分、10分、30分、60分、120分)
    ・動作時間:48時間(60分の通信間隔の場合)

    (※1)転倒検知には独自の判断基準を採用しております。転倒時でも条件によっては検知されない場合がございますのでご注意ください。


    【利用イメージ】

    ※ LTE-Mとは、LTEの一部周波数帯域を利用したLPWA無線通信規格の一つです。(LPWAはLow Power Wide Areaの略で、省電力で広いエリアをカバーする無線通信技術です)


     

    「NW-360HR」は GPS、BLE、LTE-Mを組み合わせることで、人員の位置情報や心拍、皮膚温度等のモニタリングが可能なウェアラブルデバイスです。
    ヘルプボタンを使用すると緊急アラートを送信できます。作業員の安全管理など幅広い用途にご利用いただけます。

     

    「NW-360HR」の製品詳細はこちらから
    https://www.trackers.jp/products_nw-360hr.html


  • Wanesy Wave で Beacon情報を取得する

     

    Wanesy Wave には、Beacon情報を取得する機能があります。
    この機能を使うことで、工場や倉庫の見える化(モノや人にビーコンを装着し、位置情報をリアルタイムで把握)が実現できるのではないでしょうか。

    実際にどのようなデータを取得することができるのか説明していきます。

    LoRaWANゲートウェイは Kerlink Wirenet iStation(以降iStation)、ネットワークサーバーは Kerlink WANESY MANAGEMENT CENTER(以降WMC) を使っています。
    Wanesy Wave と iStation は弊社内に設置、WMC はクラウド上のサービスです。

    Wanesy Wave からのデータ

    ネットワークサーバー(WMC)から送信されるJSON内にある、payload に値が格納されています。
    payloadを変換することで、

    • 新しくスキャンされたBeacon
    • 前回から引き続きスキャンされたBeacon
    • スキャンされなくなったBeacon

    の情報を MAJOR+MINOR(若しくはMAC Address), RSSI 値として得られます。

    payload は次のようになっています(WMCからBase 64で送信)。

    o2FugoMaB/8AAyMBgxoAAWHbAwBhcoIaCABGlRm5mGFjgoMaCAAL8CAAgwEvAA==

    Base 64 デコードし、HEX値に変換します。

    A3616E82831A07FF00032301831A000161DB03006172821A0800469519B998616382831A08000BF0200083012F00

    CBORでデコードします。

    {
     "n": [[0x7FF0003, -4,1], [0x161DB, 3,0]], 
    "r": [0x8004695, 0xB998],
     "c": [[0x8000BF0, -1,0], [0x1, -16,0]] 
    }

    得られたJSONには
    n: 新しくスキャンされたBeacon([MAJOR+MINOR iBeacon, RSSI, Moving Status])
    r: スキャンされなくなったBeacon(MAJOR+MINOR identifier)
    c: 前回から引き続きスキャンされたBeacon([MAJOR+MINOR iBeacon, RSSI, Moving Status])
    が格納されています。

    新しくスキャンされたBeacon情報を見てみます。

    [[0x7FF0003, -4,1], [0x161DB, 3,0]]

    2つの Beacon の情報が得られました。
    1つ目の MAJOR+MINOR 0x07FF0003 はそのまま記載されています。
    2つ目以降は配列の1項目目の和を求めることで取得します。
    この場合だと、0x7FF0003 + 0x161DB = 0x080061de となります。

     

    RSSI値も計算が必要です。

    RSSI=JSONのRSSI×2−47

    1つ目は、-4 × 2 – 47 = -55 となります。

    弊社では、WaveのPayloadを変換できるツールを公開しています(こちら)。
    (サイトの利用には認証が必要です。Waveを購入されたお客様へは認証情報をお伝えいたします。)

     

    例で使ったPayloadを次のJSON形式に変換し出力します。
    データの確認等にご利用ください。

    [ 
    { "tag_key": "n", "beacon": "0x07ff0003", "rssi": -55, "move": 1 }, 
    { "tag_key": "n", "beacon": "0x080061de", "rssi": -41, "move": 0 }, 
    { "tag_key": "r", "beacon": "0x08004695" }, 
    { "tag_key": "r", "beacon": "0x0801002d" }, 
    { "tag_key": "c", "beacon": "0x08000bf0", "rssi": -49, "move": 0 }, 
    { "tag_key": "c", "beacon": "0x08000bf1", "rssi": -79, "move": 0 } 
    ]
    

     

     


    Wanesy Wave詳細はこちら


  • Wanesy Wave で Wi-Fi 数をカウントする

     

    Wanesy Wave には、Wi-Fi の数をカウントする機能があります。
    実際にどのようなデータを取得することができるのか説明していきます。

    次のような構成を組みました。

    LoRaWANゲートウェイは Kerlink Wirenet iStation (以降iStation)、ネットワークサーバーは Kerlink WANESY MANAGEMENT CENTER (以降WMC) を使っています。
    Wanesy Wave と iStation は弊社内に設置、WMC はクラウド上のサービスです。
    AWS には、WMC と連携し、データを保管できる API を作成しました。
    さらに、Metabaseを使ってデータの可視化をしています。

    Wanesy Wave からのデータ

    ネットワークサーバー(WMC)から送信されるJSON内にある、payload に値が格納されています。
    payloadを変換することで、

    • 送信間隔
    • Wi-Fi カウント数
    • RSSI値別カウント数(下記表の範囲別)
    • 前回から新しく取得したMACアドレス数
    • 前回から取得できなくなったMACアドレス数

    を得られます。

    payload は次のようになっています(WMCからBase 64で送信)。

    KwEAABEAAAAAAAAAAAAAAAIABgAGAAAAAgABAAwADgA=

    Base 64 デコードし、HEX値に変換します。

    2B0100001100000000000000000000000200060006000000020001000C000E00

    定められた文字数ごとに区切り、値を得ます。

    クリックで拡大

    時系列のデータとしてデータベースへ保管していきます。

    データ可視化

    データベースに保管されたデータから、Metabase で可視化したものが次の図です。
    RSSI 範囲ごとに積み上げたグラフになっています。

    このように、RSSI 範囲ごとに現在の Wi-Fi 数を得られるので、特定のエリア内に何人の人がいるのかという用途に使えるのではないでしょうか。

     


    Wanesy Waveの詳細はこちらから


  • 斉藤牧場で感じるアニマルウェルフェア

     

    弊社は旭川市の斉藤牧場 で放牧牛システム「うしみる」に関わる実験をさせていただいています。ここは「人と牛が協力し、山々を守るための牧場」ということで、様々な牛の自然な行動を観察することが可能です。今回は斉藤牧場における放牧とアニマルウェルフェアとの関係について考察してみました。

     

    日本も加盟する国際獣疫事務局(OIE)においてアニマルウェルフェアは以下のように定義されています。

    ①飢え、渇き及び栄養不良からの自由

    ②恐怖及び苦悩からの自由

    ③物理的、熱の不快さからの自由

    ④苦痛、傷害及び疾病からの自由

    ⑤通常の行動様式を発現する自由

     

     1.運動

    (クリックで拡大)

    斉藤牧場で放牧牛にGPSロガーを装着し、1.5日の移動距離(10分間隔)を調べたところ、かなり険しい山を9.2kmも移動していました。ここで初めて牛の行動観察を行った時に、まず牛の足腰の強さに驚かされました。険しい笹薮の中をどんどん突き進んでいく牛たちに、こちらもついていくのがやっとの状態です。ここの牛たちは自分の行きたい場所に行き、食べたいものを選び口にするという自然な行動様式を発現しています。これだけ毎日歩いているのですから、屋内飼育牛とは、蹄の状態などもちがっているのではと容易に想像がつきます。肥育牛にとって運動は生産性の観点からデメリットになるかもしれません。しかし歩き回ることにより牛が健康を維持できるということは酪農家にとっても大きなメリットです。

     

    2.採食

    加速度センサーを牛の首に装着すると、牛が強い力で草を舌で巻き取っている様子がわかります。牛は本来、舌で強烈に草を巻き取って草地を食べすすんでいく動物です。牛の成長には濃厚飼料も必要ですが、斉藤牧場では牛が自分のカラダと相談しながら食べたいものを選択してるようです。険しく細い沢に水を求めて牛が分け入っていく光景もよく見かけます。こちら旭川も今年は高温で草があまり育たず、代わりに牛が笹を食べることになり、そのため乳量が落ちることがあるようです。

     

    3.自然な行動

    広大な牧草地では虫なども牛によってきますが、背中にとまった虫を顔や尻尾で追い払うのも、ある意味「刺激」で牛にとって自然な行動発現なのかもしれません。

    斉藤牧場では牧場内に木々や岩などがあり、牛は木に首や背中を擦り付けてかゆいところをかいています。時には細い木の枝に眼の周りを擦り付けかいています。「眼にささるのでは?」と見ているこちらも気が気でありません。しかし牛の方は慣れたもので顎の部分を岩にすりつけたりするなど、自由に身づくろいをしています。牛舎にもカウブラシなどを設置しているのをよく見かけますが、斉藤牧場の牛たちは自然にあるものを利用して体調を整えているようです。

     

    斉藤牧場ではある牛が別の牛に顔の周りをなめてもらっているのをよく見かけます。ソーシャルグルーミングともよばれる親愛行動ですが、複雑な牛群ネットワークを維持するための行動であるとする文献も見かけます。

     

    牛たちは猛暑日には日陰に入り休息し、大雨の時には木の下で雨をしのいでいます。

    こちらの斉藤牧場では牛たちが場所、食べ物などを自分たちで選択しながら日々を過ごしています。ヒトにとってアニマルウェルフェアと生産性を両立するのは大変難しい課題かもしれません。しかしこちらの牧場で、子牛が人になでられながら山を下りてくる姿を見ると、斉藤牧場の牛たちの「幸福度」はかなり高いのではないかと想像しています。

     


  • 放牧牛管理システム「うしみる」にソーラー給電機が便利すぎる!

     

    今年から手軽に始められる月額制も始め、お問い合わせを多数いただいております放牧牛管理システム「うしみる」にソーラー給電機が登場しました。

     

    「うしみる」はうしみる首輪を装着した牛からLoRa※でゲートウェイ(中継機)にデータを送信します。そのデータはゲートウェイから4G等のインターネット回線を通して送られ、「うしみる」アプリ画面に表示されます。スマホでも見れます。

    ※LoRaはLPWA(Low Power Wide Area)という、省電力で広いエリアをカバーするコンセプトの無線通信規格の一つです。

     

    放牧地は携帯電波圏外エリアの場合があります。LoRaなので牛さん自体は圏外をウロウロしていても全然問題はないです。

    しかしゲートウェイはそうではありません。しかも首輪からより受信しやすいように、できれば高い場所に設置したいです。事務所が高台にありインターネット完備!なんてことはなかなかありません。折角なのでベストな場所に設置したいですよね。

     

    そこで登場したのがソーラー給電機です。

    これさえあればゲートウェイ設置問題は大体解決します。

    「事務所の屋根にゲートウェイを付けても見通しがイマイチ…」

    「ここに設置できればいいんだけど、電源がない…」

    「電源あって見通しも良さそうだけど、この場所は圏外だ…」

    なんて嘆きを解決します。

    ゲートウェイにとって最適な「見通しが良く高い場所」は、日当たりが良いことが多いので、電源の心配は無用です。また、山の中腹では携帯圏外でも頂上付近は電波がある!?なんてこともあるのです。

     

    ゲートウェイ設置場所に悩んだり、このエリアは一部データが届かなくても仕方がないか、と諦める必要はありません。お値段も手頃だと思います。ご検討してみてはいかがでしょうか。

     

     

    → 放牧牛管理システム「うしみる」詳細ページはこちら

     


  • GTR-388LTE-M HTTPでのデータ受信確認

    【2023年11月24日追記】
    ・GTR-388LTE-M(Type-K)はHTTP/HTTPSの通信に対応していません。
    ・GTR-388LTE-M(Type-D)はシリアルナンバーがJ00463以降のモデルは
     HTTP/HTTPSの通信に対応しています。(2021年9月頃以降に販売)

    1. 受信用サーバーの準備

    AWS EC2 に作成した Linux サーバーインスタンス上で待ち受けプログラムを動作させます。
    今回は apache や nginx のようなサーバーは使わず、Python3 で作成した簡易なWEBサーバーを使います。
    web_server.py というファイル名にしています。

    
    import sys
    
    from http.server import BaseHTTPRequestHandler
    from http.server import HTTPServer
    from http import HTTPStatus
    
    PORT = 80
    
    
    class StubHttpRequestHandler(BaseHTTPRequestHandler):
        server_version = "HTTP Stub/0.1"
    
        def __init__(self, *args, **kwargs):
            super().__init__(*args, **kwargs)
    
        def do_POST(self):
            enc = sys.getfilesystemencoding()
    
            length = self.headers.get('content-length')
            nbytes = int(length)
            rawPostData = self.rfile.read(nbytes)
            decodedPostData = rawPostData.decode(enc)
            print("Request Data:\n", decodedPostData)
    
            response = "OK"
            encoded = response.encode(enc)
            self.send_response(HTTPStatus.OK)
            self.send_header("Content-type", "text/plain; charset=%s" % enc)
            self.send_header("Content-Length", str(len(encoded)))
            self.end_headers()
    
            self.wfile.write(encoded)
    
    handler = StubHttpRequestHandler
    httpd = HTTPServer(('', PORT), handler)
    httpd.serve_forever()
    

    2. GTR-388LTE-M 宛先の設定

    Config Tool にて宛先を設定します。

    起動後、[Communication]タブにて

    項目 設定
    (E0)Host IP 1 サーバーのIPアドレス(若しくはホスト名)
    (E1)Host Port number1 80

    を設定します。

    [Motion Sensor]タブにて、(Rb)Report Media in static のテキストボックスをクリックします。

    「Report Media Coise」ダイアログが表示されるので、HTTPを選択し、[Apply]をクリックします。

    設定後、デバイスに設定を書き込んでください。

    3. データの受信

    3-1. サーバープログラムの起動

    1で作成したプログラムを起動します。

    sudo python3 web_server.py

    3-2. デバイスの起動

    GTR-388LTE-M を起動します。
    端末を振る(5秒以上)などし、内蔵のGセンサーで動きを検知させ、データを送信します。

    3-3. データの確認

    データ受信に成功すると、画面に表示されます。

    パケットキャプチャ結果です。

     


    (参考)テスト用データの送信

    Windowsのコマンドプロントで curl コマンドを使って同じデータを送信することが可能です。 まず、リクエストの文字列を格納するテキストを作成します(ここでは dummy_data.txt という名前にしています)。

    GSr,GTR-388,XXXXXXXXXXXXXXX,0000,5,a080,3,190321,052853,E14230.8277,N4341.5387,223,0.00,246,11,0.8,12410mV,3082mV,0,37,26,00,00,00,00*52!
    

    WEBサーバーに対し、リクエストを送信するコマンドは次になります。
    注意) 「XXX.XXX.XXX.XXX」はサーバーのホスト名かIPアドレスにしてください。

    curl --request POST --data-binary @dummy_data.txt http://XXX.XXX.XXX.XXX
    

  • GTR-388LTE-M TCPでのデータ受信確認

     

    【2023年11月24日追記】
    ・GTR-388LTE-M(Type-K)はHTTP/HTTPSの通信に対応していません。
    ・GTR-388LTE-M(Type-D)はシリアルナンバーがJ00463以降のモデルは
     HTTP/HTTPSの通信に対応しています。(2021年9月頃以降に販売)

    GTR-388LTE-M は取得データを

        • HTTP
        • TCP Socket

    で設定した宛先に送信することができます。
    今回は、TCP Socketでデータを受信するための、サンプルプログラムを紹介します。

    1. 受信用サーバーの準備

    AWS の EC2 上に作成した Linux サーバーインスタンス上で待ち受けプログラムを動作させます。
    サンプルのプログラムは Python3 で作成します。 server.py というファイル名にしています。

    
    import socket
    
    HOST    = "XXX.XXX.XXX.XXX"  # サーバーのIPアドレス
    PORT    = 5000  # ポート番号(5000にしています)
    BUFSIZE = 4096
    
    tcp_server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    tcp_server.bind((HOST, PORT))
    tcp_server.listen()
    
    while True:
        client, address = tcp_server.accept()
        print("Connected!! [ Source : {}]".format(address))
    
        data = client.recv(BUFSIZE)
        print("Received Data : {}".format(data))
    
        client.send(b"OK")
    
        client.close()
    

    2. GTR-388LTE-M 宛先の設定

    Config Tool にて宛先を設定します。

    起動後、[Communication]タブにて

     

    項目 設定
    (E0)Host IP 1 サーバーのIPアドレス
    (E1)Host Port number1 サーバープログラムで指定したポート番号
    上記例だと5000

     

    を設定します。また、(A1)のチェックを外してください。

    [Motion Sensor]タブにて、(Rb)Report Media in static のテキストボックスをクリックします。

    「Report Media Coise」ダイアログが表示されるので、TCPを選択し、[Apply]をクリックします。

    設定後、デバイスに設定を書き込んでください。

     

    3. データの受信

    3-1. サーバープログラムの起動

    1で作成したプログラムを起動します。

     

    python3 server.py

    3-2. デバイスの起動

    GTR-388LTE-M を起動します。
    端末を振る(5秒以上)などし、内蔵のGセンサーで動きを検知させ、データを送信します。

    3-3. データの確認

    データ受信に成功すると、画面に表示されます。

    パケットキャプチャ結果です(黄色: サーバー, 緑色: クライアント)。

    (参考)テスト用データの送信

    クライアント用プログラムを作成することで、デバイスがなくてもテスト用データを送信することができます。

    
    import socket
    
    HOST    = "XXX.XXX.XXX.XXX"  # サーバーのIPアドレス
    PORT    = 5000  # ポート番号
    BUFSIZE = 4096
    
    tcp_client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    
    tcp_client.connect((HOST, PORT))
    
    tcp_client.send(b"GSr,GTR-388,XXXXXXXXXXXXXXX,0000,5,a080,3,>180321,081602,E14230.8271,N4341.5351,236,0.01,346,10,0.7,12400mV,>3114mV,0,6,23,00,00,00,00*68!")
    
    response = tcp_client.recv(BUFSIZE)
    print("[*]Received a response : {}".format(response))
    
    tcp_client.close()
    

  • ThingsBoard でトラッカーの位置情報を表示する

    前回のMetabaseによるデータ可視化に続いて、今回はTnigsBoardを紹介します。

    ThingsBoardとは、オープンソースのIoTプラットフォームで、データを収集し、可視化できます。
    一般的な可視化ツールと違い、データベースをシステム内に持ち、そこにデータが保管されるため、データベース設計が不要となります。

    サンプルとして位置情報を取得し、OpenStreetMap上へプロットされるダッシュボードを作成してみます。

    Amazon EC2 上に構築したThingsBoard Community Edition を使用しています。

     


    1. ログイン

    ブラウザでThingsBoardのURLにアクセスし、ログインします。

     

    2. デバイスの追加

    左側メニューから[デバイス]を選択します。
    「デバイス」の画面が表示されます。
    [+]をクリックし、表示されるリストから[新しいデバイスを追加する]を選択します。

    「新しいデバイスを追加する」ダイアログが表示されます。
    デバイスの名称を入力し、[追加]をクリックします。

    デバイスが登録されます。

    をクリックします。

    「デバイス資格情報」ダイアログが表示されます。
    アクセストークンをメモし、[キャンセル]でダイアログを閉じます。

    3. データの送信

    ThingsBoard の REST API を使用してデータを送信します。
    今回は実際のデバイスではなく、Windows PCからの curl コマンドでデータを送信してみます。

    緯度・経度と温度を送ってみます。
    送信するデータは次のJSONです。

    
    {
    "latitude": 43.692332,
    "longitude": 142.513703,
    "temperature": 35
    }
    

    送信する curl コマンドは次になります。

    「XXX.XXX.XXX.XXX」はIPアドレス、「PPPP」はポート番号、「AAAAAAAAAAAAAAAAAAA」はデバイスのアクセストークンに置き換えてください。

    
    curl --request POST --header "Content-Type:application/json"  --data "{\"latitude\": 43.692332, \"longitude\": 142.513703, \"temperature\": 35}" http://XXX.XXX.XXX.XXX:PPPP/api/v1/AAAAAAAAAAAAAAAAAAA/telemetry
    

    ThingsBoard の「デバイス」画面で、追加したデバイスをクリックします。
    表示される「デバイスの詳細」画面で、[最新テレメトリ]をクリックします。

    上記 curl コマンドを実行すると、最新テレメトリにデータが表示されます。

    4. ダッシュボードの作成

    左側メニューから[ダッシュボード]を選択します。
    「ダッシュボード」の画面が表示されます。
    [+]をクリックし、表示されるリストから[新しいダッシュボードを作成…]を選択します。

    「ダッシュボードを追加」ダイアログが表示されます。
    タイトルを入力し、[追加]をクリックします。

    ダッシュボードが登録されます。

    をクリックします。

    空のダッシュボードが表示されます。
    右下の編集アイコンをクリックします。

    エンティティエイリアスアイコンをクリックします。

    「エンティティエイリアス」ダイアログが表示されます。
    [エイリアスを追加する]をクリックします。

    「エイリアスを追加する」ダイアログが表示されます。
    下記のように設定します。

    設定したら、[追加]をクリックします。

    「エンティティエイリアス」ダイアログに戻ります。
    [セーブ]をクリックします。

     

    [+ 新しいウィジェットを追加]をクリックします。

    「ウィジェットを選択」画面が表示されます。
    現在のバンドルで Maps を選択し、
    時系列から Route Map – OpenStreetMap を選択します。

    「ウィジェットを追加」ダイアログが表示されます。
    [データ]でデータソースを追加し、[追加]をクリックします。

    ダッシュボードの編集画面に戻ります。
    作成したMapのウィジェットが表示されるので、curl コマンドでデータを送信してみます。
    マーカーがプロットされることを確認し、保存アイコンをクリックします。

    以上でサンプル作成については終了です。

    今回はMap上にマーカーをプロットしましたが、他にもいろいろな可視化用ウィジェットが用意されています。 リアルタイムにデータを確認する用途ではなかなか使えるのではないでしょうか。

     


  • Metabaseによるデータ可視化

     

    センサーからのデータは、WEBサイトにグラフなどを用い見やすいレイアウトで表示したいのではないでしょうか。
    スクラッチ開発や、市販のBIツール等のパッケージ導入だと費用対効果が悪いというケースもあると思います。
    そこで今回、Metabase という、OSSのデータ可視化ツールをご紹介します。
    なお、この記事ではMetabaseのバージョン0.38.1を元に作成しています。

    Metabaseは、下記の記載する様々なデータソースに保存されたデータを可視化(グラフや表)できます。

    • Amazon Redshift
    • BigQuery
    • Druid
    • Google Analytics
    • H2
    • MongoDB
    • MySQL
    • PostgreSQL
    • Presto
    • Snowflake
    • Spark SQL
    • SQL Server
    • SQLite

    では、実際にサンプルをご紹介します。

    構成

    デモ用に構築したシステムの構成図は下記になります。

     

    TBSL1からpHセンサー、溶存酸素センサーのデータをKerlink iStation 923 SPNが受信、HTTPSでサーバーへ転送する構成になっています。この構成を模倣したプログラムを作成し、ランダムな値をクラウド側システムに送信しています。
    API Gatewayにて受信したJSONデータをLambdaへ渡し、センサー値を取り出したのち、EC2上に構築したデータベースへ保存するようになっています。

    Metabaseでの設定

    Metabase(こちらもEC2上に構築)からデータベースに接続することで、テーブルを参照できます。

     

    【ビジュアライゼーション】から、グラフやゲージ等の表現方法を選ぶことができます。

     

     

    作成したパーツ(グラフ、表、ゲージ)を組み合わせてダッシュボードを作成することができます。ダッシュボードは特定の間隔でリロードできるようになっています。

     

    以上、簡単にMetabaseを紹介させていただきました。
    弊社では、このようなOSSを使ったシステム構築も行っておりますので、ご要望がありましたらご連絡ください。

     


  • 屋内用ゲートウェイのセルラー対応モデルをリリースしました!

     

    屋内用ゲートウェイ「Wirnet iFemtoCell-evolution 923」をリリースいたしました。

    従来機種の「Wirnet iFemtoCell 923」はバックホールとしてEthernetとWi-Fiに対応していました。新機種の「Wirnet iFemtoCell-evolution 923」はEthernetとセルラー対応となっています。見た目はほぼ同じで、SIMカードのスロットがあります。

    ご使用される環境にあわせて「Wirnet iFemtoCell-evolution 923」も是非ご検討ください。

     

    製品ページはこちら


  • 夏季放牧期間が終了しました その4

    >>その1記事はこちら
    >>その2記事はこちら
    >>その3記事はこちら

     

    夏季放牧は雪が遅い地域では11月下旬まで行われます。「うしみる」納品や実証実験を重ねるうちに、課題や追加すべき機能も徐々に見えてきました。

    まず脱柵検知機能ですが、上空が遮蔽された場所での「位置情報データの飛び」の問題があります。牛たちは雷雨の時など木の下などで雨風をしのぎます。「うしみる首輪」はGPS/GLONASSなど、さまざまな仰角/方位角から十分な個数の衛星からのデータを取得することにより安定した精度の位置情報を取得することができます。極端に上空が遮蔽された場所にいる牛の位置情報が瞬間的に飛んでしまい、ジオフェンスを超え誤アラートにつながったことがありました。衛星の幾何学的配置により不良データを採用しない方法もありますが十分とは言えません。送信間隔内に牛の速度で到達できないような位置情報はソフトで採用しないようにするという方法もありますが、今冬の課題としています。

    ひと夏、GPS発信機のバッテリーを持続させるために、「うしみる首輪」は20分毎にデータを送信していますが、データ送信直後に牛が脱柵すると、次のデータが送信されるまでアラートは送信されません。これについてはソーラー方式首輪で送信間隔を短くする方法がありますが、その地域の日射量により送信間隔は慎重に決定する必要があります。またタブレットと携行できるようなゲートウェイを背負い、牛を追跡するというのも有効だと考えています。

    放牧牛で発情を検知するシステムは国内ではあまり見かけません。やはり広い牧場では通信の問題大きいようです。現状「うしみる」には発情検知の機能はありませんが、徐々に機能を充実させようと考えています。

     

    牛は発情期がちかくなると反芻や行動に変化が現れます。たとえば発情直前には活動量が大きくなるなどです。牛のデータを分析するために、首などに加速度センサーを付け、牛の行動をビデオ撮りして立つ、座る、横臥などのアクションを定義しようと考えました。牧場でこれをやると牛が人間に興味をもち次々に集まってきます。継続してターゲットの牛を、寄ってくる牛群を避けながらカメラで追い続けるのも容易ではありません。現在はある程度の広さがある牛舎内やパドックで加速度センサーを牛につけ、複数のビデオカメラで牛の動きを追い、加速度センサーの値と比較して分析を行っています。機能を実装するにあたっては、個々の牛の平均活動量、もしくは同じ牛群の平均活動量との乖離から発情判定行うような製品が欧米では普及しているようです。弊社では引き続き牛の動きを分析し、発情検知機能を「うしみる」に実装したいと考えています。

    様々な牧場での実証実験、納品から多くのことを学ばせていただいた夏季放牧期間でした。2021年度に入りましたら、弊社は入牧時より実証実験に参加される公共牧場を募集開始いたします。

     

     

     

     

    ▼「うしみる」詳細ページはこちら


  • 夏季放牧期間が終了しました その3

     

    >>その1記事はこちら
    >>その2記事はこちら

    「うしみる」採用のお客様が導入にあたり最も期待されるのは脱柵検知機能です。放牧牛が脱柵する理由はさまざまで、以下のような原因をお聞きします。

     

    ・放牧地に慣れていない入牧直後の不安定な時期
    ・牧草が不足し牧柵外へ餌を求める時期
    ・雷など突発的な事由による瞬間的な行動
    ・牛が牧柵付近で密集し牧柵外へ押し出された

     

    「うしみる」運用前に「このエリアから出たらアラートを送る」という設定を有効にするために、地図上にジオフェンスを設定します。これにより脱柵アラートを受信することができます。
    しかしここでも電池の問題があります。夏季放牧期間中6カ月間連続動作するために、データ送信間隔は20分と設定しています。万が一、位置情報送信の1分後に牛が脱柵した場合は、19分後にしかアラートは送信しません。牛の速度X19分間で牛が到達するような範囲を捜索することになります。もちろん柵外でも「うしみる首輪」がゲートウェイに位置情報を送信するようなLoRa通信圏内に牛がとどまっている場合は、牛の現在地をほぼ正確に把握することができます。

    脱柵は近隣の住民に不安を抱かせたり、車両を止めてしまったりといった実際に迷惑をかけてしまうようなケースにもつながりかねません。牧場作業員の方たちは毎日柵の破損がないかチェックされています。それでも嵐や大雨、雷がなる夜などは「牛たちはどうしているのか・・・」と気にされているようです。「うしみる」を導入された牧場、実証実験に参加された牧場からは、「悪天候時でも牛群の場所などを自宅からでも確認することができ安心できるようになった」というお言葉をいただくことが多いです。

     

    その4に続く

     


  • 夏季放牧期間が終了しました その2

      >>その1記事はこちら

     

    ゲートウェイ設置場所は3G/4G圏内、もしくは固定回線が敷設されている電源の取れる場所に設置します。できるだけ高い、牛までの視通線が可能な限り確保できるような場所を選びます。山間部の起伏の激しい環境では通信が確保できないことが多々あります。

    ゲートウェイ設置計画にあたっては通信距離の他にゲートウェイのチャンネル数、うしみる首輪をつけた牛の頭数、データ送信間隔とデータ欠損率の関係を考慮します。「ゲートウェイなど設置せずに3G/4G回線で直接うしみる首輪からデータを送ったらよいのでは?」とよく言われますが、バッテリー持続時間とカバーエリアの関係から難しいと言わざるを得ません。現状3G/4Gトラッカーで再充電することなく半年間夏季放牧を行えるようなトラッカーを製造するとなると、バッテリーが大きくなり過ぎて、牛の行動に支障をきたします。また北海道の放牧地の多くが3G/4Gで牧区のすべてをカバーしてはおりません。それどころかゲートウェイでさえも、広大な牧場の中で何とか3G/4G通信が可能な「スポット」を見つけ出した・・・というようなこともよくあります。そのような場所は電源が取れない場所がほとんどです。通信のみ確保でき電源が取れないようなゲートウェイ設置場所のために、ソーラーパネル給電装置を開発し、この夏実験を続けました。良好な実証実験結果を得ることができました。

     

     

    データ欠損率を考慮する以外に、夏季放牧期間中(6カ月間)うしみる首輪が動作し続けるかという点も考えなければなりません。うしみる首輪は現状電池式もソーラーパネル式も20分間隔でデータを送信する設定にしています。(加速度センサーをトリガーとして通信を行う)モーションモード採用で牛が静止している間はデータを送信しないような設定も可能です。

    ソーラーパネル式ではいちじるしい天候不順が続いた場合、ソーラーパネルからの給電が徐々に追いつかなくなり電源が切れる可能性があります。ソフトウェア上でうしみる首輪のバッテリー残量を確認することが可能ですが、先述の通り牛は広大な草地に放牧されています。バッテリー残量が低下したからと言ってすぐに対処できるわけではありません。ソーラーパネル式では電源が切れた場合にも、日射量が徐々に回復しバッテリー残量を確保次第再起動します。しかし悪天候が続き完全に放電してしまった場合においては、首輪を取り外してチャージャーを使用して再充電するというような作業が発生する可能性もあります。その点電池式はサイズが大きいですが、天候にあまり影響を受けないハードウェアであると言えます。

     

    フィット感確認のためにソーラー式首輪を試着した牛

     

    放牧牛監視システムでは様々な下調べを行って、「もれ」や「見過ごしている点」がないかを細かくチェックして、その牧場に合致したシステムとなるようにデザインしていくことが最重要です。

     

    >>その3に続く

     


  • 夏季放牧期間が終了しました その1

     

    北海道では毎年5月中旬から10月中旬くらいまで市町村公共牧場で夏季放牧がおこなわれます。弊社は本年、「うしみる」の納品以外に北海道東部3か所、北海道北部1か所の牧場で実証実験を行いました。

     

    放牧牛関係のビジネスに本格的に関わり2年になりますが、改めてこのマーケットにおいて勉強しなければならないことが多々あると感じています。まず首輪の取付けですが、納品の場合にはそれぞれの畜産農家から牛が預託される入牧時に首輪を取付けます。牛は一頭ずつシュートに入ってもらい、慣れている作業員の方がシュートに誘導するのですが、それも簡単ではありません。シュートに入った後、牛の可動範囲を制限しつつ首輪を取付けるわけですが、それでも抵抗する牛のパワーは強力で、取付作業にもかなりの時間を要します。入牧した牛が広大な牧草地に放たれ、万一首輪の不具合で再回収/再取付けが必要になった場合は、作業員の方々に大変な迷惑をかけることになってしまいます。取付作業をお手伝いしてみて、机上ではわからない多くの課題に気づくことができました。

    うしみる首輪のマテリアルにも牧場の方たちからアドバイスをいただき改善をはかってきました。とっさに頭に浮かぶのは耐久性ということですが、作業の方から思わぬことを指摘されました。牛は大変臆病なので、取付時に牛が驚くような音をたてない首輪である必要があるということでした。面ファスナー、ピンバックル、リングバックルなどを試しました。

     

    首輪には電池式とソーラー式があり、ソーラー式は来年度リリースではありますが、牛に取り付け装着感の実験(それも容易ではない)を行いました。ソーラーですので端末部が首の下に降りてくるようでは十分な日射が得られません。電池式は仮に牛の首下に端末が来ても、GPS信号受信、LoRa通信に大きな支障がないことを実証実験で確認しました。

     

     

    放牧牛トラッキングシステムの難しさは、システム自体がセンサーによるデータの取得、データの送信、データの表示から成り立っている点にあります。牛舎飼いのように牛がかたまって飼育されているようなケースにおいては、通信の問題はあまり発生しないと思います。北海道の牧場においては比較的面積が広く、LoRaゲートウェイをどの辺に何台設置し、各牛との通信を確保するかが大きなポイントとなります。公共牧場専用のネットワークを構築することになりますが、信号調査が欠かせません。通常は人海戦術で行いますが、牛に首輪をつけてしまって、牛に調査させるという手もあります。ただし先述の通り、「一度取付けた首輪は簡単には回収できない」という原則があります。

    GPS/GLONASSによる位置情報取得状況についても現地調査がかかせません。天空が開けておらず、木々に覆われているような状況で位置情報が飛んでしまわないか確認する必要があります。「うしみる」を脱柵対策に購入・購入検討される方も多いのですが、位置情報が大きく飛んでしまうと脱柵アラートを間違えて送信してしまう可能性があります。「うしみる」運用前に「ここから出たらアラートを送る」という設定を有効にするために、地図上にジオフェンスを設定します。通常は牧区の柵に沿って少し余裕をもって多角形を描くことになります。位置情報が大きく飛んでしまうような遮閉地があるかなども調査が必要です。

     

    >>その2に続く

     


カテゴリー

最近の投稿