2022年12月7日

みちびき災危通報を受信するためにGNSS受信機を作った話

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

前回の記事から約4年3ヶ月ぶりの投稿です...

定期的に文章を書かないと書けなくなってしまうので何か書かなければ...と思っていたら、ちょうどタイミングよくアドベントカレンダーの季節だったので 防災アプリ Advent Calendar 2022の7日目として参加させていただきます。


現在、日本からオーストラリアにかけての上空に「みちびき(初号機〜4号機、初号機後継機)」と命名された準天頂衛星(quasi-zenith satellites)が4機(待機運用中の初号機も合わせると5機)飛んでいます。
この衛星を利用した準天頂衛星システムみちびき(QZSS)は既存のGPSやGLONASSといった衛星測位システムを補完し、常時1機は日本から高仰角で見通せる位置に滞空するように設計されています。

高層ビルの多い都市部や山間部において低仰角を飛んでいるGPSをうまく捕捉できない場合でも高仰角を飛ぶQZSSを合わせて利用することで測位精度を高めることができ、さらにサブメータ級(誤差1mレベル)やセンチメータ級(誤差数cm)での測位が可能になる補強情報の配信といった従来よりも更に高精度な測位を行うための仕組みも入っていたりします。

さて、そんな「みちびき」ですが、衛星測位以外のサービスとして、避難所の情報や状況を収集する衛星安否確認サービス「Q-ANPI」や、気象庁から発信された防災情報を配信する災害・危機管理通報サービス「災危通報」も提供されています。
Q-ANPIの送信には特殊な送信機(Q-ANPIターミナル)とソフトウェア、パソコン一式が必要なため一般人は利用できず、発災時の避難所や防災訓練、そしてNERV災対車の出動時などでしか実際の機材や使用している様子をお目にかかれませんが、災危通報は機材を揃えれば誰でも受信することができます。

災危通報では、緊急地震速報、震源、震度、南海トラフ地震、津波、北西太平洋津波、火山(噴火・噴火警戒レベル)、降灰予報(速報・詳細)、気象警報、土砂災害警戒情報、竜巻注意情報、洪水(河川氾濫警戒・発生)、台風、海上警報といった情報が配信されています。

例えば、緊急地震速報(12/6に配信された訓練/試験メッセージ)は以下のような感じ。

$QZQSM,58,9aaf8e1880000324000031000548c5e2c000000003dff8001c0000110a36474*78

これを読めるようにデコードすると...

防災気象情報(緊急地震速報)(発表)(訓練/試験)
*** これは訓練です ***
緊急地震速報
強い揺れに警戒してください。

発表時刻: 12月6日13時0分

震央地名: 日向灘
地震発生時刻: 6日13時0分
深さ: 10km
マグニチュード: 7.2
震度(下限): 震度6弱
震度(上限): 〜程度以上
島根、岡山、広島、山口、香川、愛媛、高知、福岡、佐賀、長崎、熊本、大分、宮崎、鹿児島、中国、四国、九州

以上のようになります。

ちなみに、過去に受信した配信データ試験データはGistで公開しているので、他の情報がどんな内容か気になる方や後述のデコーダを試したい方はご利用ください。

配信の頻度は4秒に1回のため緊急地震速報を早く受け取りたいといった用途には向かなかったり、地震の情報も都道府県単位かつ震度4以上の地域のみのため気象庁防災情報XML形式電文の受信を置き換えできたりする物ではありません。

しかし、空が見えればインターネットが繋がっていなくても防災情報を取得でき、情報を得るための契約や料金は不要です。
みちびきは国費で打ち上げられて運用されているプロジェクト、すなわち我々の払った税金が宇宙を飛び、防災情報を地上に降り注いでいる...と考えると受信してみたくなりませんか?


SPRESENSEによる災危通報の受信

災危通報の受信方法を検索するとよく出てくるのが、SONYが販売しているSPRESENSEというボードを利用した受信です。

みちびきから配信されている災危通報は、GPSやQZSSでの測位に利用しているL1C/A信号ではなく、サブメータ級測位補強に利用されるL1S信号で配信されており、このL1S信号に対応した受信機が必要です。
SPRESENSEはL1S信号の受信に対応していて、Arduino IDEでシリアルモニタにデータ(QZQSMセンテンス)を出力するサンプルスケッチも公式で提供されているため手っ取り早く災危通報の受信を試すことが可能です。

しかし、見晴らしの良い場所なら気にならないものの、オンボードのアンテナだと受信感度がイマイチだったり、USBケーブルで引き回して窓際や屋外に設置するのは面倒だったりするので外部アンテナを接続したくなります。
そんな人のために、外部アンテナの使用方法も公式で公開されているのですが... 使用するのは表面実装用のU.FLコネクタで、オンボードアンテナから外部アンテナに切り替えるために1005サイズのチップ抵抗を移設する必要があるという、ハンダづけに慣れている人でもかなり神経を使う作業。 

しかも、U.FLコネクタの嵌合サイクルは30回程度なので何度も着脱するのはお勧めされないため、ボードと付随するケーブルが入るようなケースを作って固定したり、ホットボンドで固定したりといった工夫が必要です。


他の受信機の検討

みちびき対応製品紹介(災害・危機管理通報サービス対応製品)のページに記載されているカーナビやウェアラブル機器以外の専用受信機(データをUSBやUARTなどで取得可能な物)で、個人が購入可能な物は安くても5万円程度、法人で購入可能な物の場合は10万円以上だったりします。

同じく対応製品として掲載されているu-blox社のGNSS受信モジュール「ZED-F9P」は、モジュールを採用したボードが各社から市販されていますが、RTK測位の基準局としても使用できる高機能なモジュールのため安くても4万円後半からとお高め。
昨年新たに対応製品として追加された、同じくu-blox社の「MAX-M10S」を採用しているボードは海外のSparkFunMIKROEGNSS OEMなどから販売されていますが、円安の影響もありいずれも7000円程度、アンテナはSMAコネクタで接続できますが、データ出力がUARTのためシリアル変換が別途必要でSPRESENSEと比較しても帯に短し襷に長し...

というわけで、理想のGNSS受信機を作ることにしました。


オリジナルのボード設計

手のひらサイズで、USB-C接続で、SMAコネクタを採用して外部アンテナを接続できる、そしてせっかくなら素のボード状態ではなくてケースに入っているもの、というのを目標に設計開始。

0からGNSS受信機を作るのは無理なので、先ほどの対応製品として掲載されていたu-blox社のGNSSモジュールMAX-M10Sを採用し、同社が公開しているMAX-M10S Integration Manualを参考にアンテナ周りの回路とバッテリーバックアップ用のコイン電池、USBシリアル変換ICのCH340、ステータス確認のためのインジケータLED、USB-Cコネクタ、SMAコネクタを追加。回路図をKiCadで書いていきます。

回路図ができたら、PCBエディターを開いて部品をざっくり配置し、全体のサイズ感とコネクタの大きさからケースを探し、今回はタカチ電機工業のポータブルプラスチックケースCS75Nを採用しました。あと、この時点で実装する部品も秋月電子通商とDigi-Keyで調達しておきます。

KiCadでケース図面の推奨基板形状の通りに外形をEdge.Cutsレイヤーに書いて、コネクタ、ジャック、部品を配置、配線していきます。

部品の3Dモデルを紐づけておくと3Dビューアーでボードの完成形が確認できるのでKiCad素晴らしい...

念の為、アートワークを等倍で印刷した紙に部品を載せてフットプリントがズレたりしていないか確認し、問題なさそうだったのでガーバーデータを出力して一式をzipにまとめて基板製造サービス、いつも使ってるElecrowに発注しました。


ケースの設計

基板が届くのを待っている間にケースの加工図面を書いていきます。

タカチのサイトから3D CAD用STPファイルをダウンロード(要会員登録)して、Fusion360に読み込み。
そして、KiCadからSTEPファイルを書き出して読み込みます。が、KiCadからエクスポートしたSTEPファイルをそのまま読み込んでも部品がほとんど載ってない状態になってしまうので、こちらの記事を参考にしてFreeCADとKiCadStepUpプラグインを使用して基板、配線、部品をひとまとめにしたSTEPファイルを作成します。

基板はver1.0の物(コネクタの位置が変わっていないので流用)

作成したSTEPファイルを改めてFusion360に読み込み、ケースの固定位置に基板を配置。
USB-CコネクタやSMAコネクタが通る穴をスケッチに起こし、押し出しでモデルに穴をあけます。

2D図面を作成して出力して、まずは図面を見ながらフライス盤で穴あけ(手作業)。

そんなこんなやってると基板が届いたので、1枚だけ手ハンダで部品を実装してケースに入れてみます。

この段階ではインジケーター用の穴は開けてませんが、USB-CもSMAコネクタも干渉せずにケースに収まることを確認。


動作テストと災危通報受信プログラム

アンテナを接続し、PCとも接続、u-blox社が提供しているu-center2を使用して動作確認と災危通報を受信できるように設定します。


CFG-MSGOUT-UBX_RXM_SFRBX_UART1を1(有効)に設定することで、UART1(シリアルポート)に衛星航法データが出力されるようになります。
これを有効にすると、みちびきから配信されている災危通報を取得できるようになります。

出力されるのはNMEAセンテンスではなくバイナリ形式のため、これを解析する必要があります。
災危通報のメッセージは、0xb5 0x62 から始まるUBXプロトコルのバイナリ形式で出力され、必ず以下のヘッダで始まります。

b5 -> UBX Preamble sync character 1
62 -> UBX Preamble sync character 2
02 -> Message Class (RBX)
13 -> Message ID (SFRBX)
2c 00 -> Payload Length (Little Endian, 44 bytes)
05 -> GNSS ID (5=QZSS)

NMEAセンテンスは \r\n の改行コードで終わりますが、UBXプロトコルのバイナリ形式メッセージはヘッダの Payload Length を読んでメッセージの終端を得る必要があります。

上記のヘッダに続き、メッセージごとのデータおよびチェックサムが入っています。

07 -> Satellite ID (7+182=189=QZS03)
01 -> Signal ID (1=L1S)
00 -> Frequency ID (Only used for GLONASS)
09 -> The number of data words contained in this message (8+9*4=44)
45 -> Tracking channel number
02 -> Message version (0x02)
00 -> Reserved 0
55f5ad9a170580110000008e00000000000000000000000010000000b1aa5aebff9483b2 -> QZQSM(災危通報データ)
e2 -> ck_a (Checksum)
cd -> ck_b (Checksum)

この仕様をもとに、シリアルポートを開き、みちびきのユーザインタフェース仕様書(災害・危機管理通報サービス, IS-QZSS-DCR-010) 4.3.1. Sentence format で示されている $QZQSM から始まるNMEA形式のセンテンスに変換して出力するプログラムをPythonで書きます。

import sys
import argparse
import operator
from functools import reduce
import serial

satellite_id = {
    184: '56',
    185: '57',
    189: '61',
    183: '55',
    186: '58',
}

def nmea_checksum(sentence):
    data = sentence.strip("$").split('*', 1)[0]
    cksum = reduce(operator.xor, (ord(s) for s in data), 0)
    return cksum

def ubx_checksum(message):
    ck_a = 0
    ck_b = 0
    i = 0
    while i < len(message):
        ck_a = (ck_a + message[i]) & 0xff
        ck_b = (ck_b + ck_a) & 0xff
        i += 1
    return ck_a, ck_b

def ubx2qzqsm(line):
    if line[:7] == b'\xB5\x62\x02\x13\x2C\x00\x05': # UBX-RXM-SFRBX, 44 bytes, QZSS
        satId = satellite_id[line[7] + 182] # PRN -> Satellite ID
        data = b''
        for i in range(9):
            data += bytes((line[14+3+i*4], line[14+2+i*4], line[14+1+i*4], line[14+0+i*4]))
        if data[1] >> 2 == 43 or data[1] >> 2 == 44: # Message Type 43=JMA-DC Report, 44=Other
            dcr_message = (data[:31] + bytes((data[31] & 0xC0,))).hex()[:-1] # 256-4=252 bit
            sentence = '$QZQSM,' + satId + ',' + dcr_message + '*'
            return sentence + format(nmea_checksum(sentence), 'x')


if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Print QZQSM NMEA format sentence')  
    parser.add_argument('port', help='serial port. ex: /dev/ttyUSB0')
    parser.add_argument('baudrate', help='baudrate. ex: 115200')
    parser.add_argument('-n', '--nmea', help='print other standard NMEA sentence', action='store_true')
    args = parser.parse_args()

    with serial.Serial(args.port, args.baudrate) as ser:
        while True:
            line = b''
            nmea_flag = False
            ubx_flag = False
            count = 0
            payload_length = 0
            while True:
                if ubx_flag:
                    if count > 4 and payload_length == 0:
                        payload_length = int.from_bytes(line[4:5], "little")
                    if payload_length > 0 and count == payload_length + 8: # header 6 bytes + checksum 2 bytes
                        break
                b = ser.read()
                if b == b'$' and not ubx_flag:
                    nmea_flag = True
                if b == b'\x62' and line == b'\xB5':
                    ubx_flag = True
                if b == b'\n':
                    if line.endswith(b'\r'):
                        line += b
                        break
                    else:
                        line += b
                else:
                    line += b
                count += 1

            if args.nmea and nmea_flag:
                sentence = line.decode().strip('\r\n')
                ck = nmea_checksum(sentence)
                if format(ck, 'x') == sentence.split('*', 1)[1]:
                    print(sentence)

            if ubx_flag:
                ck_a, ck_b = ubx_checksum(line[2:payload_length+6])
                if line[-2] == ck_a and line[-1] == ck_b:
                    sentence = ubx2qzqsm(line)
                    if sentence:
                        print(sentence)

pySerialをインストールして、シリアルポートとボーレートを指定して実行。

pip install pyserial
python read.py /dev/tty.usbserial1410 115200

以下のようにNMEA形式のセンテンスが得られます。

$QZQSM,57,9aadf5b1118002c3f2587f8b101962082c41a588acb1181623500012b979380*20

上記のセンテンスをデコーダにかけると災危通報の内容を人間が読める形で出力できます。

git clone https://github.com/9SQ/azarashi.git
cd azarashi
python setup.py install

import azarashi
sentence = '$QZQSM,57,9aadf5b1118002c3f2587f8b101962082c41a588acb1181623500012b979380*20'
report = azarashi.decode(sentence, msg_type='spresense')
print(report)
以下のような出力を得られます。

防災気象情報(海上)(発表)(通常)
海上警報が発表されました。

発表時刻: 11月12日17時35分

警報等情報要素: 海上濃霧警報
サハリン東方海上

警報等情報要素: 海上濃霧警報
サハリン西方海上

警報等情報要素: 海上濃霧警報
網走沖

警報等情報要素: 海上濃霧警報
宗谷海峡

警報等情報要素: 海上濃霧警報
北海道西方海上

警報等情報要素: 海上濃霧警報
北海道東方海上

警報等情報要素: 海上濃霧警報
釧路沖

警報等情報要素: 海上濃霧警報
日高沖

今回はデコードにオープンソースのライブラリを使いましたが、災危通報の仕様書は公開されているので自分で1から実装することも可能です。

いくつかの場所で受信テストをしてみると、どうやらロケーションとタイミングが良ければ運用中のみちびき4機すべてから受信できそうなことが分かったため、衛星が現在どこを飛んでいるのか確認できるトラッカーを作って確認しながら受信テストを実施したりしました。


ケースのデザインとマシニング加工発注

問題なく災危通報の受信と解析ができたので、GNSS受信機として売り物になるように仕上げていきます。

先ほどのFusion360のモデルにインジケーターLEDの穴を3つ追加であけて、2D図面を出力。
ついでにDXFファイルも出力してIllustratorに持っていき1:1で開き、ケース表面の窪みと3つの穴のアウトラインだけ残してお絵描きをします。

出力した2D図面とIllustratorファイルをマルツのプロトファクトリーに送って見積もりをしてもらいます。

詳細の費用は伏せますが、費用感としては千石電商で1個180円で買えるCS75N-Wが、インクジェット印刷とマシニング加工をすると90倍くらいの価格になります(白目
1個の場合なので、10個、100個と数が増えると単価は下がるため、今回はひとまず10個で発注しました。

並行して、チップLEDの表面からケース表面までの長さをFusion360で測って、インジケーターLED直上の穴にはめるための導光棒をAliexpressで発注しておきます。

届くのを待つ間に、基板に部品を実装します。
流石に何個も手ハンダでやるのはつらいので、基板と一緒に注文しておいたステンシルとペーストはんだを使い、ホットプレートリフローで一気に実装します。
一気にやると言ってもチップ部品はピンセットを使って1個ずつ乗せ、プレートの面積が10 x 10cmのET-10を使ったので同時に焼けるのは2枚ずつで、1時間で3〜4個できるかなといったところ。(実家に帰ればチップマウンターオーブンがあるので多少早いんだけれど...)

加工ケースとLED導光棒は2週間程度で届き、届いたケースに部品を実装した基板と導光棒を固定して...

加工精度も問題なく、Fusion360でシミュレーションした通りに完成です。


というわけで、自分の欲しいGNSS受信機を自分で作ってみた話でした。

ちなみに、この受信機を利用してNERV災対車に搭載する防災情報サイネージも作ったりしています。

表面に印刷のない零号機を使用中

ものづくりは様々な要素が組み合わさったパズルを作っていくような感じで面白いし、自分のこだわりを詰め込みながら形ある物を作っていくのは楽しいですね。

今回設計したGNSS受信機は近日発売予定です。
詳細はドキュメントも兼ねたサイトにて公開しますので、興味のある方は買ってもらえると嬉しいです。

2018年9月11日

続・気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

まず、北海道胆振東部地震で被災された方にお見舞い申し上げます。
今回の地震は熊本地震と同様の最大震度7が観測された為、自分自身が2年前に体験した熊本地震の時の様子を思い出しながら、今必要な情報は何か?を考えて仕事をしていました。

それにしても、まさか札幌にお天気カメラを設置しに行った3日後に大地震が発生するとは思ってませんでしたが...

設置の翌日、台風が北上してくる中、15時の便にフライトを振り替えて新千歳空港から飛び立ち、17時ごろに羽田についたら以降の便が全便欠航していた&翌日(5日)も台風による悪天候でダイヤが乱れていたので、振り替えていなければ人生で2度目の震度7クラス地震を体験するかもしれないところでした...

さて、今回は、気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話 の続きのお話です。
※これは防災情報デザインと配信に関する個人的な研究の一環として私費でやっている物の話です。

あれから半年程度運用を続けてきましたが、全体の運用に毎月1500円〜1700円の費用が掛かっていました。(それでも十分に安い)

この「全体」というのは、気象庁XML受信のためのサブスクライバ&閲覧のためのビューアをホストしているAppEngine、XMLやJSON、画像保存のためのStorage、QUAKE.ONEをホストしているFirebase、その他内部的な処理に使っているCloud Functions (15個の関数)、Pub/Sub (5個のトピック)、JMAXMLのメタデータや地震情報、気象警報・注意報のステートを保存しているDatastoreを含みます。

例えば、2018年6月に掛かった実際の費用はこんな感じ。


全体の費用として一番大きいのが、Compute Engine g1-smallインスタンスx1で毎月2000円から継続利用の割引で約1400円と実に全体の80%以上。
このインスタンスは、Twitterへの投稿やPushbulletでのプッシュ通知の際に添付される震源・震度マップ画像を、headless Chrome&PuppeteerでレンダリングしてCloud Storageに保存するためにだけに使用されているものです。
f1-microインスタンスでは、CPUバーストが効いた状態でレンダリング(960x540)に10秒以上掛かる上に、地震が頻発すると何度目かのレンダリングでCPUバーストが効かずに実行がタイムアウトしてしまうという残念なことが発生したため、g1-smallインスタンスで運用していました。

ところが、2018年8月のアップデートで、Cloud FunctionsにてNode.js 8系が利用できるようになると共にheadless Chromeが利用可能であることがアナウンスされました。

Introducing headless Chrome support in Cloud Functions and App Engine | Google Cloud Blog

これに伴って、構成を以下のように変更。


(クリックで拡大してご覧ください)

大きな変更点は以下の通りです。

1. 画像のレンダリングをCloud Functionsで実行
2. 画像レンダリング用のg1-smallインスタンスを廃止
3. WebSocket配信サーバをConoHaからf1-microインスタンスに変更

これにて、毎月の利用額がCloud Storageのオペレーションとデータの保管に掛かる費用のみとなり、200円以下となりました。
(f1-microインスタンス1台はAlways-freeなので0円)

Cloud Functionsでのレンダリングは、asia-northeast1のメモリ2GBで最短3900ミリ秒(ページの読み込みのために入れたwait 3000ミリ秒を含む)、最大でも7秒程度とブラウザを利用した画像の生成(かつ無料枠範囲内)の方法としては優秀。
もちろん、スピードが重視されるような防災情報配信用途としてはとてもとても遅い(ゲヒルンで製作・運用している描画エンジンはフルHD1枚200ミリ秒程度)ので、あくまで実験・実証としての利用、またはスピードが求められない場面での利用に限られるのですが...。

ひとまず、ConoHaに全てを載せていた時の価格(毎月1000円程度)と比較して1/5くらいになったので、クラウドは上手く使えば安くなりますよ事例として記しておきます。
ただし、これはアクセス数に大きく依存するので、今くらいの利用者数であれば200円で済むものが、利用者が数倍になればGCPに支払う費用も数倍、数十倍以上になり得るということです。
あくまで個人的な実験・試行というところでの運用を続けているので、流石にそういう状況になったら続けることはできませんが、こういった複数の要素を使ったサービスを数十円、数百円のレベルから始めることが出来るのがGCPやAWS、Azureといったクラウドのメリットということでしょう。

2018年7月14日

HDピコレーザープロジェクター 自作キットを組み立ててみた

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
つい先日、Twitterのタイムラインを眺めていたら、こんなものを発見。


これは試してみるしかない、と1台買ったので組み立ててみました。
ちなみに、お値段は購入時点で税込15,120円。限定数販売後は値上げするようです。


届いた中身はこんな感じ(写真には写ってませんが、レーザー出力部とHDMI信号を受ける基板を繋ぐフレキも入っています)


ひとまず、ベースとなるアルミプレートに基板とレーザー出力部を仮置きしてみる。
基板はそのまま「1」の番号が振ってあるネジで5箇所を固定。


レーザー出力部に付属のフレキを「TOP」の刻印がある向きで接続。
反対側を基板に繋ぎつつ、固定場所に位置合わせします。


レーザー出力部を「1」の番号が振ってあるネジで3箇所 固定。


トップのアクリルパネルを固定するためのシャフト(3番の部品)を、アルミプレートの裏側から「2」の番号が振ってあるネジで5箇所 固定。


最後に、アクリルパネルの保護紙を剥がして、「4」の番号が振ってあるネジで5箇所 固定。

なかなかコンパクトで、サイズはiPod Classicと同じくらい、重さは87gでした。


同じくレーザー走査型のプロジェクターで、SONYが海外にて販売しているMP-CL1Aとサイズ比較。
MP-CL1Aは個人輸入で1台5万円くらいだった記憶...


少し明るい環境だったので、はっきりとした比較にはなりませんが、レーザークラス3RのMP-CL1A(左)と比較して、HDピコレーザープロジェクター(右)はクラス1にしては健闘していると感じました。

ちなみに、MacとHDMIで接続したところ、YPbPrの信号には対応してないようで、画面全体がピンク色に...
手元にあるRaspberry PiやPINE64では問題なく表示されました。

次は真っ暗な環境で試してみようと思います。(続報はTwitterに書くかも

追記:真っ暗な部屋で映してみました。



投影先は天井、距離は2mくらいで、正確に測ってないけど50インチくらいはあるはず。
小さい文字はボケるけど、動画を見る分には悪くないかなというところです。

iPod Classicに大容量ストレージとバッテリーを搭載してみた

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク
というわけで、長年考えていた「最強のiPod Classicを作りたい」という目標を実行してみたお話です。

改造に必要なiPod Classic(最終世代)の調達
ヤフオクやメルカリ等で電池消耗はあるけど外観の状態が良さそうな物を4つ(シルバーとブラック2個ずつ)購入、うち2個はApple Storeにてバッテリー交換して保管用に、残り2つのうち1個を比較用に未改造状態、もう1個を改造用として用意しました。

iPod Classic ... 1個 約1万円

ストレージ用の変換基板
iPod 第5世代やiPod Classic(6世代以降)に対応した、microSDカードが4枚挿しできる基板を購入。
https://www.iflash.xyz/store/iflash-quad/

iFlash Quad ...  42ドル = 約5,000円

ストレージ用のSDカード
ここ1年くらい大容量MicroSDカードの値動きを追っていて、200GBが1枚6000円を切ったら実行しようと思っていて...
ついに、先日、テクノハウス東映でSanDisk Ultraの200GBが6000円を切ったため4枚まとめ買い。


SanDisk Ultra microSD 200GB ... 1枚5,880円 x4 =23,520円

256GBを4枚挿しで1TBというのも憧れるけど、200GBと比較して256GBはまだまだ高いので、次やる時の楽しみにとっておきます。

「800GB」刻印のバックパネル (スリム仕様)
せっかく大容量化するので、刻印も実際の容量と同じ 800GB の物を購入。
あと、フロントもバックパネルも金属製のClassicは開ける作業が非常に難しく、歪みや傷が入ること必至なので元のバックパネルは使わないという前提です。
Aliexpressにて購入。


バックパネル ... 950円 + 送料 200円くらい = 1,150円

1950mAhのバッテリー
iFlash QuadとmicroSDの組み合わせでは元のHDDと比較してかなりスリム化するので、空きスペースに大容量バッテリーが入ります。
eBayでフレキが互換の交換用バッテリーを購入。

バッテリー ... 14.99ドル + 送料 350円くらい = 2,050円

これでパーツは一通り揃ったので分解作業開始...


想定どおり非常に開けづらいので、開腹作業には1時間くらい要しました...
今回はフロント側に傷を入れないようにし、バックパネルはどうなっても良いというスタンスで作業をしたので、バックパネルは縁が歪んで再度の取り付けは厳しい状態に。
また、クリックホイール操作時にクリック音を鳴らすための圧電スピーカーがイヤホンジャック下部のフレキに付いていましたが脱落... 慌てて追加でこのフレキ部品を発注するも、結局使わないことに(後述)


HDDを取り外して、iFlash QuadにmicroSDカードを4枚セット、HDDと同じ部分に置いてみる。
この状態だと元のHDDと比べて非常に薄いので、スッカスカです。
一応、iFlashにはバッテリーを増量せずにデフォルトのバッテリーで筐体を閉じるために、スペーサーとなる黒いスポンジも付いています。


次にバッテリーの接続。
左は元々の550mAhバッテリー、右が1950mAhバッテリーです。


1950mAhバッテリーを入れるには少々フレームに加工が必要で、元のHDDを固定するために付いている突起を削る必要あり。


こうして完成したものを閉めようとすると...
クリック音用のスピーカーが絶妙にバッテリーと干渉して液晶画面側が僅かに浮いてしまいます。
ということで結局、分解時にスピーカーが脱落してしまったフレキを再利用することに...


iPodをMacと接続し、iTunesからファームウェアを復元、実際に使用できる容量は730GB程度のiPod Classicが完成。

試しに90GBくらいの音楽ライブラリを同期して、LossLess音源を連続再生することでバッテリー持続時間を計測中...
48時間程度経過した段階で、バッテリー表示上は7割くらい残っているようです。

掛かった費用は4万5000円くらいでしょうか。
最近流行りのハイレゾ対応プレイヤーだと物によるけど5万円以上したりするので、ハイレゾとまでは行かないものの48kHz/16bitまで再生できて大容量で長時間再生できるプレイヤーとしては割とお得なのでは?と思ったり...

iTunesで10年以上続く音楽ライブラリを管理しているので、これからもiPod Classicには活躍してもらうことにします。

追記:重さの比較してみました。


シルバーが今回改造したiPod Classicで123g、ブラックが未改造で135gでした。
体感としては、僅かに軽くなったかなというくらい。
バッテリーが550mAhのデフォルトの物だと凄く軽く感じるけど、逆にオモチャっぽさを感じたので、ある程度の重さがある方が質感アップに寄与する模様。

2018年3月26日

気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

そろそろ何かアウトプットしておかないとNo Activityマンになってしまうと思いつつも色々やることは山積みで筆の捗らない今日この頃、みなさんいかがお過ごしでしょうか。

さて、2015年12月にEVI 地震火山詳報を公開してから約2年と3ヶ月(その前身の桜島詳報から数えると3年7ヶ月)が経過しました。
実は、2017年10月頃のConoHaの障害によりサブスクライバが長時間止まってしまい、気象庁のPuSH配信から外されたため同月よりEVIのサービスが停止しておりました。
この際、本業(ゲヒルンUN_NERVへ作画提供)でも震源・震度地図の作画エンジンを作っているので完全にサービスを畳んでしまおうかとも思ったのですが...
振り返って周りを見てみれば、インタラクティブな震源・震度マップに挑戦している方が意外と少なく、作画方法も本業の仕組みとは全く異なるので 防災情報デザインに関する異なるアプローチの研究 ということで緩く継続してみようと思い立った訳です。

#防災情報デザイン、特に地震に関するものに関しては、様々な方が主にUN_NERVで提供されている地図デザインをパクって何度も何度も車輪の再発明をされていますが、みなさん少しは配色を変えてオリジナリティを出したり、「俺ならこうする!」といった伝え方の工夫を取り込んでみてはいかがでしょうか...? 芸が無さすぎて全くつまらんです。

EVI 地震火山詳報のサービスと後ろ側については、以前書いた記事をご覧ください。

地震とか火山噴火情報を閲覧できるWebサイトを作った (2015年12月)

上記の記事の通り、EVIは後ろ側がかなり複雑に絡み合っており、機能追加や改修をするにも面倒になっていました。
また、受信したXMLや生成したGeoJSON、画像の保管も同じインスタンス内に入っていたため、ある一定期間ごとに古いデータを削除する等のメンテナンスが必要でした。

...そこで、今回EVIを改修するにあたり以下の目標を立てて移行計画を実行することにしました。

1. 出来る限りマネージドなクラウドサービスに載る(俗にいうサーバレス)システムにする
2. 出来る限り最新の設計・構築方法、技術を用いる
3. デザインをなんかイケてる感じにする←重要

ということで、これらを念頭に置きつつ、隙間時間を使って3ヶ月ほどで作ったものがこちらになります。(冒頭のスクリーンショットのサービス)

QUAKE.ONE
https://quake.one/

#火山要素が消えたことには目をつぶってください

Twitterは以前のIDのまま Prioris_EVI を使っています。

Pushbulletも以前のままです。

日本国内で発生した全ての震源・震度情報
earthquake_jp

日本国内で発生した震度3以上の震源・震度情報
earthquake_int3over

さて、ここからは技術的なお話。

EVIからの進化ポイントは以下の通り。

1. 小さな画面を持つデバイスにおいて、操作可能な地図が非常に小さくなる問題を解決
→どの画面サイズのデバイスにおいても全画面で地図を表示し、情報をマップ上に配置する新しいデザインを採用

2. OpenLayersのバージョンアップ
→OL3から最新のOL4へ移行

3. ページを動的から静的生成に変更、SPA(single-page application)化
→地震発生をトリガーにしてレンダリング用のJSONをあらかじめ生成

4. Twitter、Pushbulletにて配信する画像形式の震源・震度地図のデザイン変更
→画像の生成方法もwkhtmltoimageからPuppeteer + Headless Chromeに刷新

また、これに伴ってサブスクライバから後ろも全て刷新しました。
構成図は以下の通り。(横に非常に長いので、拡大してご覧ください)


使用したサービスは以下の通り。

Google Cloud Platform
・App Engine
・Compute Engine
・Cloud Functions
・Cloud Datastore
・Cloud Storage
・Cloud Pub/Sub
・Firebase Hosting

地震が発生して「震源・震度に関する情報」が流れてきた時のパターンを簡単に説明すると...

1. 気象庁からPubSubHubbubでJMAXML publishing feedを受ける
2. atomを解析してEntryを取り出し、Task Queueに投げ入れ、Entryの内容をDatastoreに書き込む
3. WorkerはXMLを取得、XMLスキーマを適用してJSON形式に変換、XMLとJSONをStorageに保存し、JSONをPub/Subに流す
4. 3種のPub/Subトピックのうち地震に関係するトピックにぶら下がっているCloud Functionsが実行、Datastore内の地域コード対地域重心座標に基づいてGeoJSONを生成してStorageに保存、概要をPub/Sub(topic: quake-one)に流す
5. Pub/Sub(topic: quake-one)にぶら下がっているCloud Functionsが実行、Puppeteer(+Express)が待ち受けているGCEインスタンスに画像生成リクエストを送信
6. Headless Chromeで画像用ページを表示して撮影、Storageに保存
7. 画像生成リクエストが成功すると、当該eventIDの地震の概要と画像のURLをPub/Sub(topic: quake-one-with-image)に流す
8. Pub/Sub(topic: quake-one-with-image)にぶら下がっている各Cloud Functionsが実行、PushbulletやTwitterへ投稿
9. QUAKE.ONE はStorageを参照し、概要の入ったJSONとインタラクティブ地図描画用のGeoJSONを取得、JavaScriptでレンダリング

以前の複雑に絡み合った状態からすれば、随分とメンテナンスしやすいシステムへと変わりました。

AppEngine、Firebase Hostingは自動的にLet's EncryptでSSL証明書を更新してくれるし、しっかりキャッシュ、CDNが効いてくれます。
Storageは、ライフサイクルを設定することで、古いXMLやJSON、画像データを自動的にNear line→Cold lineと安価なストレージに移行、あるいは削除してくれます。
Cloud Functionsは実行時課金で、気象庁XMLをトリガーにして実行する程度の回数では全て無料範囲内に収まります。
唯一、画像を生成するためのPuppeteer + Headless Chromeが入っているGCEインスタンスだけは面倒を見てあげなければなりませんが、これも永続化が必要なデータやステートは持っていないので管理は楽々です。

さらに、副産物としてJMAXML JSON Viewerも出来ました。
こちらはデータ保存期間が浅い&検索が弱いので受信状況の確認程度用です。
商用利用は禁止ですので、お仕事で使いたい方はゲヒルンの気象庁XML Viewerをご契約ください。

というわけで、出来る限り新しめの手法でマネージドな感じのイケてるサービスが出来ました。

めでたし、めでたし。(終)

追記:その後の話を書きました。
続・気象庁防災情報XMLの受信と周辺サービスをGCPに移行した話