ヤマレコなら、もっと自由に冒険できる
FAQ 使い方ガイド お問い合わせ

Yamareco

HOME > ヤマノート > EPSON GPSウォッチ ログ抽出ツール Version 1.04
更新日：2025年06月14日　訪問者数：928
ジャンル共通 IT
EPSON GPSウォッチ ログ抽出ツール Version 1.04
kfd01567
EPSON GPSウォッチ ログ抽出ツール Version 1.04
本アプリはEPSONのGPSウォッチ(WristableGPS)内のGPSログ(ワークアウトデータ)を
WindowsPCのダウンロードフォルダに抽出するツールです。
Windowsの「EpsonView」アプリのインストールフォルダに本アプリを置いて頂くことで
動作します。EPSONからのEpsonViewアプリの配布は終了している可能性がありますので、
過去にEpsonViewを利用されており、今も環境が残っている方のみが利用できると思います。

ウォッチのワークアウトをPCに転送すると以下のファイルが生成されます。

(1) GPXファイル
緯度、経度、高度、時間、心拍数を出力します。
※現在のバージョンではGPXファイルの出力は"SF Series"のみです。

(2) CSVファイル
以前、EpsonViewのサイトでサポートされていたBACKUP形式(CSVファイル)
です。ワークアウトの詳細な情報(ラップタイム、ストライド、ピッチ、
斜度など)が出力されています。BACKUP形式の読み込みに対応している
Webサイト(RUNALYZEなど)にアップロードすることでワークアウトの
詳細な内容を確認することができます。
※現在のバージョンでは"J-xxx"のウォッチの場合、ラップデータのみを
出力します。"SF Series"はほぼすべてのデータを出力します。

(3) 複数のBINファイル
ウォッチ内のワークアウトの内部形式(BINファイル)です。
通常は参照する必要はありません。本ツールはまだまだ開発途中でして、
もしウォッチのデータの解析に興味を持たれた方がおられましたら、
ぜひ解析にご協力頂きたいという思いで出力しています。

なお詳細なインストール方法や利用方法についてはダウンロードしたファイルの「お読みください」に記載しております。
画面イメージ
改版履歴
2025/04/25 Ver0.1 初版リリース
2025/04/26 Ver0.11 画面デザインの見直し
2025/05/03 Ver0.12 サイズが0のワークアウトがあった場合の処理追加
デバッグトレースの追加
2025/05/08 Ver0.13 ワークアウトのダウンロードの際に内部的に指定するClassIdの
値が一部のウオッチにしか対応できていませんでした。このため
例えば"SF Series"のウオッチの場合はダウンロードでエラーと
なっていました。本バージョンからウォッチの製品名に応じた
ClassIdを設定するよう改善しております。
2025/05/15 Ver0.14 ワークアウトの内部形式ファイルをCSVファイルに変換する機能
を追加しました。主に"SF Series"のウォッチのワークアウトフ
ァイルのヘッダ部分(ラップデータ等)の情報のみを変換出力しま
す。
2025/05/17 Ver0.15 CSVファイルに出力する情報の量と精度を改善しました。
CSVファイルを"RUNALYZE"にアップロードすることでワークアウト
の内容が確認できるようになりました。
2025/06/02 Ver0.16 CSVファイルを出力する際に同時にワークアウトの内部形式ファイ
ルを解析しやすいように3つのファイルに分割する機能を追加
しました。
2025/06/05 Ver0.17 CSVファイルを出力する際に同時にGPXファイルも生成するように
しました。まだ座標計算が正確ではないため、少し離れた位置で
生成されてしまいます。また今回よりCSVファイルにGPSの情報を
出力しましたが、そのためかRUNALYZEへのアップロードに失敗す
るようになりました。現在調査中です。(Ver1.0で解決済)
2025/06/07 Ver1.00 正式にGPXファイル、CSVファイルの出力に対応しました。
※"SF Series"のみです。
2025/06/08 Ver1.01 高度(Altitude)の出力に対応しました。
高度差のあるテストデータが不足しているため、テストが十分で
はありません。高度を求めるための係数がconfigファイルにあり
ますので、もし不満足な値でしたら係数の調整をお願いします。
海外の方からのご要望にお応えして、日本語以外のWindowsで
起動した場合は英語で表示するようにしました。
2025/06/08 Ver1.02 心拍数(HeartRate)の出力に対応しました。
現在の対応方法はSF-810の場合は心拍数データあり、SF-110
は心拍数データなしと判断して出力します。
SF-810で心拍数機能をオフで記録されたワークアウトの場合、
心拍数は0(ゼロ)で出力します。将来ヘッダの情報を特定し、
オフの場合は心拍に関する情報を出力しないように改善する
予定です。
2025/06/11 Ver1.03 心拍数(HeartRate)のデータを詳細に出力するようにしました。
出力したCSVファイルをRUNALYZEにインポートすることで、心拍
数グラフの表示などが行えます。その他、GPXファイルの時間の
出力方法を改善しました。
2025/06/13 Ver1.04 ウォッチのモデルが"J-xxx"のCSV出力に対応しました。主にラッ
プ系のデータのみです。
CSV/GPXの出力の際に「BODY部の抽出に失敗しました」のエラー
が時折発生する問題に対応しました。
開発の経緯
私以外にもEPSONのGPSウォッチで山行ログを取っていた方が、きっとおられるのではないかと思います。2025年3月末でEPSONでのサポートが終了したためと思いますが、4月からEpsonViewを用いたウォッチからのGPXファイル取り出しが出来なくなりました。
4月下旬、代替のツールを作って、なんとかウォッチの内部形式で取り出すことには成功しました。しかし内部形式の解析は思った以上に困難でした。そこでこのヤマノートに開発中のツールを公開してみましたところ、国内および海外から解析に協力して頂ける方が現れて、あれよあれよと言う間に解析が進み、2か月足らずで一応使い物になるツールが完成してしまいました。公開した私自身驚きです。(^^;
現在GPXファイルの出力は"SF Series"のみですが、今後も新たな協力者が現れることを期待しながら、少しづつアップデートを続けてゆこうと思います。
ツールのダウンロード
お気に入りした人
人
拍手で応援
拍手した人
拍手

kfd01567さんの記事一覧

もっと見る

※この記事はヤマレコの「ヤマノート」機能を利用して作られています。
どなたでも、山に関する知識や技術などのノウハウを簡単に残して共有できます。 ぜひご協力ください！

詳しくはこちら

コメント

katsushige
EpsonウォッチもEpsonViewもさわったことも見たこともないので、単なるあてずっぽうでしかないので申し訳ないですが、データの9byteめあたりにアスキー文字で「FIT」の文字が埋め込まれていれば、ガーミンで使用しているFIT形式(https://developer.garmin.com/fit/protocol/)の可能性があります。
バイナリデータはヘッダ部にアスキー文字でキーワードが埋め込まれている場合が多いのでそれをもとにデータ形式を探る方法もあるかと思います。
しかしアプリのサポートが終了するとOSのバージョンアップなどで使えなくなることもあるのでつらいところですね。
2025/4/28 19:56
kfd01567
katsushigeさん、コメントありがとうございます。残念ながらFIT形式ではなさそうな感じです。サンプルの内部形式ファイルを以下に置きました。見て頂けたら助かります。なお72バイト目からワークアウトの開始日時(6バイト)、終了日時(6バイト)が入ってることは確認しています。
https://github.com/kfd01567/EpsonViewSupportApp/raw/188f85acb253d2c7bd8da499b9fcfb0d99bfb3b4/workout_binary_28.zip
2025/4/28 21:48
katsushige
kfd01567さん
やはりはずれでしたか。自分の持っているGPSロガーがFIT形式だったので可能性もあるかと思いましたがそううまくはいかないものですね。
ファイルも見ましたが私のレベルでは簡単には解析できそうになさそうな感じです。
余計なコメントをいれてしまったようで申し訳ないです。
2025/4/29 7:49
kfd01567
さっそくサンプルのファイルにも目を通して頂いたようでありがとうございます。全然、余計なコメントじゃないですよ。私もまだ解析を始めたばかりの段階です。どんなコメントでも大歓迎です。「××の形式じゃないかな」といったコメントを頂ければ、しっかり調べてみます。よろしくお願いします。_(^^)_
2025/4/30 0:12
katsushige
kfd01567さん
データを眺めていたらちょっと解析に興味が出てきました。差し支えなければ比較用にデータを一つ追加して頂き変換結果のデータも追加して頂けないでしょうか。
変換後のデータからバイナリに逆変換して検索すれば解析がしやすいのでは思います。
いろいろと試せば解析のきっかけぐらいにはなるかもしれません。
2025/4/30 17:26
kfd01567
katsushigeさん、解析にご協力頂けるとのこと、ありがとうございます。しかし残念ながら、EPSONのサイトが4月から閉鎖されたため、変換結果のデータの入手は難しいです(過去の個人のGPXデータにもアクセスできなくなっているようです)。代替策として、GPSウォッチとスマホの両方を持って、幾つかのパターンでログを採取してみました。スマホはGPXファイルでログを採取してます。完全一致とはいかないですが、ほぼ変換結果に近いものと思って頂いて良いかと思います。以下に置いておりますので、もし良かったら見てやってください。中にファイルの説明も入れてます。
https://github.com/kfd01567/EpsonViewSupportApp/raw/7ee6d41e2ec3bc16e793846eab7a540f52ef7c97/workout44_46_47.zip
2025/5/1 16:50
katsushige
kfd01567さん
せっかくデータをとって頂いたのに確認するのが遅くなってしまい申し訳ないです。
まず複数のファイルを比較して共通データを洗い出そうとしたのですが差異がありすぎて共通データが見いだせない状況です。
想定していたのとデータ構造が違うようで解析は難しいそうです。
多分固定部も含めてGPSの位置情報以外のデータも多数入っているのではないかと思います。
そこでデータを整理し直してみました。
FileNo Start End Lap(s) Data size
No28 11:47:32 11:47:54 22 1,817
No44 13:41:28 13:54:09 761 30,973
No46 14:13:31 14:18:52 321 12,465
No47 14:51:31 14:52:40 69 1,967
複数のデータから1秒間に追加されるデータのサイズを計算してみました(必ずしもサンプリング間隔が1秒とは限らない)
No28と47から (1967-1817)/(69-22) = 3.19
No47と46 (12465-1967)/(321-69) = 41.65
No46と44 (30973-12465)/(761-321) = 42.06
No47と44 (30973-1967)/(761-69) = 41.91
多分No28は設定の違いなどで他と固定部のサイズが大きく違っているように思われます。
No28を除くと1秒に約42byte追加される計算になりまずが、逆算して固定部のサイズを出すとマイナスになるので必ずしも１回/秒でデータが追加されているわけでもなさそうです。
仮に緯度や経度などのデータが4byteだとする10種類程度のデータが記録できることになるのでGPS情報以外にも情報が入っているのではないでしょうか。
もしかしたらサンプリング間隔や内容も設定やモードによって異なっているかもしれませんので変換前後のデータが対でほしいところですが仕方ないですね。

できればEPSONがフォーマットを公開してもらえると一番いいのですが・・・

ちょっと無理っぽいですがもう少しデータを調べてみますので、追加の情報があればメッセージか何かで教えてもらえるとうれしいです。
2025/5/3 13:43
kfd01567
katsushigeさん、サンプルデータの解析、ありがとうございます！こちらもGW等で返信が遅くなってしまい、申し訳ありません。実はあれから色々とありまして、このヤマノートを見られた別の方からワークアウトのサンプルデータとそれに対応するCSVデータを頂くことができました。以前のEPSONのサイトではウォッチからアップロードしたワークアウトのファイルをCSVファイルに変換する機能がサポートされていたそうです(私はその機能に気づきませんでした)。中身を見ると、なんとなく対応付けができそうな感じです。katsushigeさんが言われていたように、GPSの位置情報以外のデータも多数入っているようです。もしお時間があるようでしたら、こちらのファイルもご確認頂けたら幸いです。以下に置いております。
https://github.com/kfd01567/EpsonViewSupportApp/raw/3ee5304fcc7c975c64374b5c227aebd0a567489f/20250114.zip
2025/5/8 11:09
katsushige
kfd01567さん
データを拝見しました。今回アップロードされたデータは先のデータとは異なり規則性が見られました。0x1D8(472) あたりから 0x39(57)バイトごとに同じデータがでてきます。ヘッダも若干異なることから出力方法が異なるようにも思えます。内容を把握するのはまだ難しいですが手掛かりになりそうです。
データの解析用にバイナリビューワを作成してみたのでもしよければ使ってみてください。
https://github.com/katsushigeyoshida/ToolApp?tab=readme-ov-file
ここからToolApp.zipをダウンロードしてもらい、解凍してToolApp.exeを起動しバイナリビューワをダブルクリックすればビューワが開きます。ファイルパスのコンボボックスをダブルクリックしてファイルを選択します。そこで行バイト数に5７と入力して「再表示」ボタンを押すとデータの周期性が分かる表示になると思います。
2025/5/8 21:11
kfd01567
katsushigeさん、データの規則性について、貴重な情報をありがとうございます。確かに今回入手したワークアウトファイルは1レコード57バイト固定長のようですね。この方のウォッチは(私とは異なる)"SF Series"というモデルでしたので、モデルまたは設定等によって変わってくるのかも知れません。その後、別の方から"SF Series"のワークアウトファイルを頂いたのですが、そちらの方は1レコード53バイト固定長になっていました。ご参考までに新たに入手したワークアウトのファイルを以下に置きますね(提供者からは公開の許可は得ています)。

＜SF Series 57バイト固定長の追加のデータ[CSVとBINと途中の解析情報]＞
https://github.com/kfd01567/EpsonViewSupportApp/raw/33f53db8f3f5e74ea79f1bb27d42e614e877cfb5/20250206.zip

＜SF Series 53バイト固定長のデータ[CSVはなし]＞
https://github.com/kfd01567/EpsonViewSupportApp/raw/33f53db8f3f5e74ea79f1bb27d42e614e877cfb5/workout_binary_1_jpn_sf.zip

バイナリビューワの提供もありがとうございました。さっそく利用させて頂きました。1行のバイト数を自由に設定できるバイナリエディタの必要性を強く感じましたので、その後lmhexというOSSを見つけて使っています。参考までに上記のデータを開いた画面を以下に置いています。
https://github.com/kfd01567/EpsonViewSupportApp/raw/33f53db8f3f5e74ea79f1bb27d42e614e877cfb5/lmhexScreenShot_jpn.png
2025/5/10 9:40
kfd01567
Version 0.13をリリースしました。以前のバージョンではワークアウトのダウンロードに失敗する、と複数の方からご指摘を頂き、確認しました所、ワークアウトのダウンロード時に内部で指定する値が固定値であったため、"J-350"等の一部のウォッチしかワークアウトのダウンロードができていませんでした。Version 0.13では"SF Series"でもダウンロードできることを確認しております。
※EPSONのGPSウォッチには様々なモデルがあるようですが、私もよく把握できておりません。もしかすると、Version0.13の各モデルの対応だけでは不十分かも知れません。(^^; もしダウンロードに失敗した場合は手作業で「内部で指定する固定値」を算出して、configファイルに定義する機能も今回追加しておりますのでご活用頂ければと思います(少々手間ですので技術者向けです)。
2025/5/8 11:41
piraru9
&h19 で開始される6byteは日付データです。
ex.19 05 0B 08 25 24

&h19=25 は2000が省略された西暦で
月・日・TOKYO時差9時間を加算して時・分・秒です。
(注：時差9時間で日付がズレる場合もあります)

ex.19 05 0B 08 25 24 = 2025-05-11 17:37'36
2025/5/13 9:33
piraru9
binの中身はおおまかに（SF110の場合）
----
データ概要
FFFF……FFFF
ラップ1概要
FFFF……FFFF
ラップ2概要
FFFF……FFFF
ラップ3概要
FFFF……FFFF
移動データ(大量)
----
こんな感じです。

GPS軌跡の解析は難しくても
ラップデータだけでも抽出できたら、
最低限の仕事はしてくれるソフトウェアになるのではないでしょうか。
眺めているとアドレス&h001Cがカロリーとか分かります。

またGPSデータの混じらないインドア計測すると
移動データ(大量)が比較的00で埋まるシンプルなデータが取れます。

同一ウォッチを２つ並べて持ち、
１つはインドア、１つはGPS計測で計測し
その差分を調べたらGPS計測の差分が絞り込めて
解析のヒントになるかもしれません。
2025/5/13 9:44
kfd01567
piraru9さん、ワークアウトファイルの解析、ありがとうございます。現在、何人かの方が解析にトライされており、少しづつフォーマットが見えてきている段階です。「&h19 で開始される6byteは日付」についてはワークアウトファイルのヘッダ部分に含まれている情報です。この上の投稿"CSVとBINと途中の解析情報"で資料化された方がおられますので参照頂ければと思います。ワークアウトファイルは先頭からヘッダ部、ボディ部、フッタ部の３部から成るようです。ヘッダ部に関しては結構解析が進んでいるようです。ただしデータの大半を占めるボディ部はまだまだよく分からない部分があり、核心の[GpsData]はこのボディ部に含まれているようです。
katsushigeさんの情報から、"SF Series"のボディ部は1レコードが53バイトまたは57バイトの固定長であることが分かりましたので、2種類のワークアウトファイル(1つはSF-110で、もう1つは別のSF-xxx)を並べて比較してみました。
少し大きな画像ですが、比較の画面を以下に置いていますので参照して頂ければ幸いです。
https://github.com/kfd01567/EpsonViewSupportApp/raw/e4c1112d7eb12ed37b6dd49e12960abbd0b27b41/compare2.png

解析に使用した2つのワークアウトファイルはいずれもこの上の投稿にあるものですが、解析しやすいようにヘッダ部を削除したり、レコードの途中に時折混ざるデータを削除して解析しやすくしたものを参考までに以下に置いています。
<2025/6/5編集>
上記で述べているレコードの途中に混ざるデータは8バイト、64バイトの2パターンがあり、これらのデータを別ファイルに抽出する機能をVer.016で追加しています。（以前は手作業で削除していました）
ですので、以前置いていたファイルは削除しています。

「ラップデータだけでも抽出できたら、最低限の仕事はしてくれるソフトウェアになるのではないでしょうか。」は嬉しいお言葉ですが、RUNNET等ランニング系の掲示板での話でしたらそれでもOKでしょう。ここはヤマレコの掲示板ですので、最低限の仕事がGPS軌跡の出力だと思っています(志は高く!?)。
2025/5/14 1:14
katsushige
データを見てくれる人が増えたのは心強いですね。
CSVデータのあるデータだけ確認しているのですが[LapData]は0x80から12８(0x80)byte単位で書き込まれているようです。
workout_binary_0.bin
LapData 128(0x80) byte
00080 - 00FF Value Offset
LapNo, 1, 0x01 00
EndPoint, 999999,
LapTime, 2456, 0x998
LapDistance, 6751, 0x1A5F 0C
LapCalorie, 567, 0x237 18
LapPaceAve, 363, 0x16B
LapSpeedAve, 9895, 0x26A7 1E
LapPitchAve, 162, 0xA2 2A
LapStrideAve, 98, 0x62 2E
LapKind, 1, 0X01 02
LapSteps, 6667, 0x1A0B 14
LapSplitTime, 245683, 0x3BFB3
LapSplitDistance, 6751, 0x1A5F 10
LapAscentAltitude, 86, 0x56 1A
LapDescentAltitude, 82, 0x52 1C
まだ一部のデータしか紐づけができていませんがこれの繰り返しで入っているようです。
GPSの緯度経度の値はCSVのデータがうまく解釈できれば先に進めるかもしれません。
2025/5/13 19:56
いいねいいね
1
piraru9
２キロコースを５周しました。
SF110's.binをみてGPS部には53バイトリズムがありました。
５回の同一的な周期があれば緯度経度だと推測できそうです。
一定に増加している値は時間か距離かと推測できそうです。
疲れてきてペースは周回ごとに落ちましたが、ラスト１周はあげました。
そういう増減を描いているのはペースかも。

53バイトが3620個並びました。
タイム59分なので１秒で１レコードぐらいですね。
2025/5/14 10:06
kfd01567
Version 0.14をリリースしました。コメント欄でkatsushigeさん、piraru9さんから頂いた解析情報を元にCSV形式で出力する機能を追加しております。バイナリとの対応がよく分からないフィールドが多々ありますので、分からない項目については"x"で出力しています。 引き続き、解析よろしくお願いします。_(^^)_
2025/5/15 19:04
katsushige
kfd01567さん
20250206のデータはパリでのデータだったのですね。経度より緯度の方が大きいのが謎だったのですが理解できました。
改めてデータを見直した結果、
起点を0x5F0とした場合
offset 0x0b 2byte Lap秒
offset 0x11 5byte 60 5E AA 00 71 => 485,342,469,728 Latitude ?
offset 0x19 5byte 00 00 01 10 31 => 210,721,898,496 Longitude ?
緯度の方はかなり近い値かと思いますが経度の方は変化がないのではずれだと思います。
2,4,8byte固定単位のデータでは なく1byte単位にデータサイズを変えて格納しいると考えるとデータがサーチできそうな気がします。
その辺の検証機能を先に紹介したツールに組み込んでみました(データ型でEpson57を選択)。
それと[LapData]の数は 0x006C に、LapKindはoffset 0x02,TimeCentiSecondは0x0Bと思われます。
2025/5/16 15:20
kfd01567
katsushigeさん、"Epson57"を確認しました。隣にそれらしいLatitudeとLongitudeが表示された時は、一瞬「ついに解析して下さった！」と喜びそうになりました。でもよく見たらCSVの値とは一致していないですね。。でもかなり近い値が導き出せているようですので、もうひとひねり？といった感じでしょうか。引き続きよろしくお願い致します。
2025/5/17 2:33
kfd01567
katsushigeさん、LapCount, LapKind, TimeCentiSecondに関する情報ありがとうございます。以前の私の投稿「途中の解析情報」はzipファイル内のodsファイルのことですが、フランスの協力者と私とでアップデートしており、最新は以下に置いています。参照して頂ければ幸いです。
https://docs.google.com/spreadsheets/d/147eHi_lfutTrW-ZgEbTW0bdjJnc8Vb_R9cqZKrz721w/edit?usp=sharing
ラップ系のデータは解析がほぼ完了した感じです。いよいよGPSDataの解析に本腰を入れなければならないようです。
2025/5/17 21:15
katsushige
kfd01567さん
表を拝見しました。シンプルでわかりやすいですね。LapDataはあとEndPointが残っていますが残りのデータと合致しないですね。LapTimeからGpsDataのレコードをサーチすればわかるかと思いますがそれだとあまり意味がないですよね。
Gpsデータの緯度経度ですが1度ずれると100kmぐらい離れるので度の部分は変化しないとみて上位2桁は固定と考え見た結果が前の結果です。この辺をもう一度考え直してツールでの検索機能を見直してみます。
2025/5/18 8:53
kfd01567
katsushigeさん、さっそく表を確認頂いたようで、ありがとうございます。EndPointは実は算出方法が見えています。表の「GPSData」のシートのA列をご覧ください。EndPointは各ラップデータがGPSDataのどの位置に相当するかを示す値のようです。ですのでGPSDataのレコード数、GPSTimeが分かれば、そこから算出できます。
引き続き、Gpsデータの緯度経度の方、よろしくお願いします。
2025/5/18 10:03
katsushige
kfd01567さん
GpsTimeは一定間隔ではないので結局、GpsTimeをサーチすることになるかと思います。
それとGPSDataのシートを見てて思ったのですが、このデータ数は約1000であるのに対し、バイナリデータのレコード数4700あまりで4倍以上になります。余計なことかもしれませんが複数レコードで1データの可能性も考えた方がいいような気もしました。
2025/5/18 12:58
kfd01567
katsushigeさん、レコード数4758は時分秒に直すと1:19:18で、ワークアウトの時間(TrainingTime)と一致します。他のいずれのワークアウトのサンプルも同様です。piraru9さんが書かれていたように、バイナリのレコード数はTrainingTime 1秒毎の出力のようです。
一方CSVのGPSDataのGpsTimeは1秒毎ではなく、バイナリのレコードから一部（精度の高いデータだけ？）を間引いてCSVに出力されているような感じです。
これまで私が入手したSF Seriesの全サンプルを以下に置きましたので参考にして頂ければと思います。
https://github.com/kfd01567/EpsonViewSupportApp/raw/21a5d934287d4eb6ba955823b026269689f2d1b9/workout_all_samples.zip
※BINとCSVのペアで置いています。ただしSF-110の方は私のツールでCSVを出力していますので、GPSDataはありません。
2025/5/18 23:34
katsushige
kfd01567さん
了解しました。CSVデータはバイナリデータと1対1のデータと思っていましたがそうではないということですね。いろいろと先入観が働いていたようです。
2025/5/19 7:34
kfd01567
Version 0.15をリリースしました。ラップタイム系のデータについて、さらに情報を頂きましたので、アプリに反映しました。情報量が増えたせいでしょうか、EPSON CSV形式の読み込みに対応しているサイト(Runalyze)にアップロードし、ワークアウト内容を表示できるようになりました。
以下はpiraru9さんから提供の「２キロコースを５周」のワークアウトをCSV形式に変換後、Runalyzeで表示したものです。
https://github.com/kfd01567/EpsonViewSupportApp/raw/bd0b6821ef7c704f75501135f2a98a34e2827de0/runalyze.png
いい感じでラップ情報が表示されています。近い将来(?)、CSV中のGpsDataが正しく出力できるようになれば、この画面の下にマップとGPS軌跡が表示されます。
2025/5/17 2:26
mkita2018
始めました。ログ抽出，興味をもって拝見しています。ログ抽出ツール素晴らしいですね。使用させていただきました。バイナリーの解析，だいぶ検討されているようなので，私の見解が誤っているかもしれませんが，compare.pngの32, 33, 34 GpsTimeとされていますが，距離ではないでしょうか。34 33 32 と並べて 16進数 -> 10進数 -> 64で割る とほぼ移動距離になるようですが。
2025/6/2 7:48
kfd01567
mkita2018さん、データ解析にご協力頂き、ありがとうございます。おっしゃる通り、64で割って剰余を切り捨てることで、CSVのDistanceと全レコード完全に一致することを確認しました。実はSlopeのデータもCSVと全レコード完全に一致することが確認できています。今回、提供して頂いた情報を反映した最新の解析シートを以下に置いております。ご確認頂ければ幸いです。
https://docs.google.com/spreadsheets/d/1R8xM91LUqC7HEZxapPxGILHQ645jjM2d7HFT0Ez-7ko/edit?usp=sharing
※複数のシートがありますが、GraphData0320とGraphData0206シートです。
※GpsStatusの16,48はbinファイルの2列目の10,20ではないかとの情報を別途頂いており検証中ですが、最初の500レコード分くらいは一致するのですが、それ以降は一致しない(1行ずれる等)があって、まだ不確定です。
2025/6/2 22:26
mkita2018
kfd01567さん 2列目の10,20も検討してみます。
2025/6/3 0:40
いいねいいね
1
mkita2018
続けてのコメントで恐縮ですが，Longitudeとされている，26, 27 も分かったような気がします。こちらがTimeかと想像しています。27 26としてみると単調に増加しているかと思います。ff ff まで増えると，繰り上がりは省略されているようです。そこは，自分でxx = 00, 01, 02のようにふって，xx 27 26を16進数->10進数->32で割るとほぼタイムになるようです。如何でしょうか。
2025/6/2 17:20
kfd01567
mkita2018さん、おっしゃる通り32で割ると1づつの増加になるようです。ただ1レコード目の最初のTimeの値は402であったり291であったりと、binファイルによって異なるようですが、これが何を意味しているのか分かりますでしょうか？
2025/6/2 22:32
mkita2018
kfd01567さん ご返信ありがとうございます。想像ですが，GPSを補足した時点を0:0:0として，startを押した，distance 0での時刻 ではと想像しています。DistanceとTimeはそれなりに自信があったのですが，まだ，感覚ですが，compare.pngの 28 29列がスピード，60の次の41列がストライド，42列がピッチのような気がしています。あと１レコード目の考え方ですが，データ概要の最後のFF FF ... FF のあとの少し何らかのデータがあって，その後の00 00 ... 00 の直後の50 が始まりのように見えるのですが。
2025/6/3 0:37
kfd01567
mkita2018さん、スピード、ストライド，ピッチについて、おそらく認識されている通りだと思います。GraphData0206シートの495行目付近を見て頂くと分かるかと思います。ランニング中に25秒程一時停止されているようです。Distanceの増加は停止し、スピード、ストライド，ピッチに該当するデータもその間は0になっています。なんとかBINからCSVへの計算式が見つかると良いのですが。引き続き、よろしくお願いします。

レコードの始まり位置は私も確信が持てていないのですが、0x30/0x31の列が先頭のような気がしています。Ver0.16では0x30/0x31を先頭にbodyファイルを生成するようにしています。0x30/0x31の列と0x40/0x41の列はそれぞれレコード長を決める値のようですので、レコードの前の方に合った方が解析しやすいと思っています。0x30の時は8バイト余分に増え、0x41の時は64バイト余分に増えるようです。30->40->50と並ぶ方が自然かな、という感じもしています。今後の解析次第では、もしかすると先頭位置は変わるかも知れませんが。
2025/6/3 14:19
kfd01567
Version 0.16をリリースしました。CVSファイルを出力すると同時にワークアウト内部形式(BINファイル)の解析をしやすくするため、1レコード57or53バイトの主要データと、一定規則で出現する付加データとに分ける機能を追加しました。詳細については「お読みください」の「5. データ解析用の利用方法」を参照頂ければと思います。※データ解析にご協力頂いている方向けの機能です。
2025/6/2 22:36
mkita2018
なんとなくですがバイナリからトレースが再現できました。下は大阪マラソンのデータです。
https://drive.google.com/file/d/1ITzroMUuojgHPp0MFsw3xx7YuvfKztjp/view?usp=drive_link
また，次は大阪ハーフマラソンのデータです。
https://drive.google.com/file/d/1J14WqUrP7GJyHswiy5TcmaSr5l_YTqHl/view?usp=sharing
少し横長になっていますが，どちらもコースを再現できているように思います。
具体的な数値との対応まではいたっていませんが，使ったデータは緯度，経度を表していると思われます。
具体的には次のようにデータを編集しました。
51, 52, 53, 54 列の4byteを使用しました。
52 51 の2byteで符号付16進数->10進数 iレコードの値 a_i について y_i = y_i-1 + a_i -> y_iが緯度
同様に
54 53 の2byte 符号付16進数->10進数 iレコードの値 b_i について x_i = x_i-1 + x_i -> x_iが経度
上のような手順ですので，スタート地点が 0,0です。
是非，ご検討ください。
2025/6/3 19:56
mkita2018
続きです。上の y_iとx_iを4063232 (3e0000)で割って，スタート地点の緯度，経度に加えると，ほぼトレースを再現できるようです。スタート地点の緯度，経度がバイナリのどこかに書かれていると思うのですが，今回は地図から読取りました。
大阪マラソンのトレース下のような感じです。ほぼコースの道路上に沿っているかと思います。
https://drive.google.com/file/d/1wrthtizG6FAboVyxwu8aThmxk-OtU0ve/view?usp=drive_link
2025/6/3 21:19
kfd01567
mkita2018さん、ついに緯度経度の解明に辿り着かれたのですね。素晴らしいです。でも私には高度過ぎて、少しついて行けていないようです。
51, 52の列が緯度、53, 54の列が経度ということは分かりました。
そしてそれらはバイナリファイルのどこかにあるスタート地点の緯度経度からの差分で表現されているのですよね。 よく分からなかったのが「 iレコードの値 a_i について y_i = y_i-1 + a_i -> y_iが緯度」の部分です。GraphData0206シートのN列O列にそれぞれ、BINからの2byteで符号付16進数->10進数にした値を表示するようにしました。この値にさらにどのような計算を加えるとGPSData0206シートの緯度経度を導き出せるのか、すみませんがもう一歩説明お願いできますでしょうか。
2025/6/4 0:10
mkita2018
kfd01567さん 失礼しました。（言葉と式とどちらの説明が良いかと迷ったのですが。）10進数にした値が，緯度 (or 経度) の変化量になっています。例えば，2, 3, 2, -10, -12, 5, ... などと得られたら，2, 5, 7, -3, -15, -10, ... と順次加えていきます。補足ですが，トレースがほぼ合ってそうなので，正しいのではと思っていますが，このやりかただと，前のレコードに値が依存することになります。つまり，(必要な)レコードをとばしたりできないことを意味します。私はSF-810のデータですが，レコードの取得として 00 71 00 (<-他でも良いかと)が出現したら新しいレコードとしてデータを処理しています。その後，57バイトのレコードのみを使っています。57バイトより長いレコードも出現しますが，それが何を意味するかは手付かずです。
2025/6/4 6:15
katsushige
mkita2018さん
素晴らしいですね。要は前回との差分を記録しているということですね。それで教えてほしいのですが0x3Eで割っている理由とデータの単位は何になるのでしょうか。初期値も同じ単位で格納されていれば検索できると思うのですが。
2025/6/4 9:12
mkita2018
katsushigeさん まず0x3Eで割った理由ですが，実際の緯度・経度と，和から得られた数値とを比較して縮尺を出しました。十進で4000000くらいだったのですが，16進数できりが良さそうなところで合わせ込みました。単位ですが，10進数表記の度という答えで宜しいでしょうか。今回のケースだと，スタートが(34.68610, 135.52062)で1点目は， (-21,41)でこれを0x3Eで割って(-5.1683E-06, 1.00905E-05)をスタートの緯度，経度に加えています。順次同様です。今回のスタートを逆に0x3E倍すると，(140937671, 550651720) -> (0x08 66 89 c7,0x20 d2 47 48)で，各4byteですが，この値はバイナリにはないようです。概要のff ff ... ff の後，レコードが始まる前に，16x6byteのデータがあるのですが，そのあたりに緯度，経度のデータあるのでしょうか。日時は先頭にあるようですが。
2025/6/4 19:31
katsushige
mkita2018さん
丁寧な説明して頂きありがとうございます。実は0x3Eでなく0x40だと他と係数が共通になりプログラム的にも6bitシフトで簡単に高速に処理できるので都合がいいと思った次第です。単位の件はデータの格納方法の問題で度で表す以外にも秒(秒/100)、度分秒、他に180°を１に換算して格納しているものもありました。いろいろパターンを考えて検索してみたのですが今のところ見つかっていません(単に見落としているだけかもしれませんが)
今回いろいろと参考になりました。
2025/6/4 20:42
kfd01567
以前の私の投稿で２つのワークアウトを並べた画像、compare.pngのリンクを書きましたが、その後の皆様の解析により、以前の認識が間違っていたことが分かりましたので、画像ファイルを更新しました。
https://github.com/kfd01567/EpsonViewSupportApp/raw/e4c1112d7eb12ed37b6dd49e12960abbd0b27b41/compare2.png
以前の投稿のURLも修正しています。
2025/6/4 22:13
kfd01567
SF-810では1レコード長さが57バイトではなく、もっと長いレコード長になる場合が約1分毎(60レコード毎)に出現します。0x30/0x31の列の値が0x30の場合は8バイトの追加、0x40/0x41の列の値が0x41の場合は64バイトの追加となります。おそらくこの追加データの中にベースの緯度，経度の情報が含まれているのではないかと想像しています。一般にGPSの値はある程度の誤差は生じますので、1分毎にベースの緯度，経度を生成することで誤差を最小限にしているのではないかと想像しています。
2025/6/4 22:25
mkita2018
kfd01567さん ありがとうございます。57バイトのレコードだけ抽出していたので，0x31, 0x40だけになっていました。0x30, 0x41のレコードを見て見ます。
2025/6/5 0:08
katsushige
mkita2018さん
データを再確認したところ0x31は相対座標で0x30は絶対座標が入っているようです。0x30の列からのオフセット4の4bytｅが緯度、オフセット8からの4byteが経度のようです。4bytｅのデータを4.2で割ると求められます。この4.2は逆算で出したので根拠はありません。20250206と20250505のデータでそれらしい値にはなっています。確認してもらえると幸いです。
2025/6/5 10:58
mkita2018
katsushigeさん ありがとうございます。私の方でも確認できました。4.2で割るとのことですが，0x400000(4194304)ということはないでしょうか。あと，kfd01567さんに下でご指摘いただいていますが，差分だけで計算すると0x3Eでの割り算が良かったものの，こちらも0x400000で割ると上手くいくのかもしれませんね。あとは，標高でしょうか。
2025/6/6 0:25
katsushige
mkita2018さん
すいません。CSVのデータ形式に合わせた係数にしていました。0x400000にした方がすっきりしますね。標高は緯度経度に続く2byteまたは4byteが該当すると思いますが平坦地を移動しているのでわかりにくいです。
2025/6/6 6:55
mkita2018
katsushigeさん 標高の件。たしかにそのようです。0x31の場合，すべて変化量で，緯度 2byte,経度 2byteに続いて，標高 2byte，0x30の場合，絶対値で，緯度 4byte, 経度 4byteに続いて，標高 3byte (4byte目は0のため？）のようです。両方とも64で割り算です。3000m級の山のデータで，緯度，経度から国土地理院のサイトで標高を出し，バイナリと比較して出したので，64はあってそうな気がしています。
2025/6/7 1:15
kfd01567
mkita2018さん、katsushigeさん、標高に関する情報、ありがとうございます。私のツールの場合は精度が異なるせいか、160で割ってみると、CSVの値に近いものが得れそうでしたので、Ver1.01は160で割っています。まだまだ調整の余地がありそうな感じです。あと0x30の場合の標高ですが、緯度経度同様にマイナス値があることを考慮するとやはり４バイトのような気がしています。(Ver1.01は4バイト符号付で処理しています)
2025/6/8 20:00
kfd01567
Version 0.17をリリースしました。とりあえずですが、katsushigeさん、mkita2018さんの情報を元にGPXファイルを出力するようにしました。CVSファイルへの出力する情報も増やしています。
0x30レコードへの係数、「4.2」と0x31レコードへの係数「0x3E」はそれぞれEpsonViewSupportApp.exe.configファイル内のGpsEffectAbsoluteとGpsEffectRelativeに持たせてますので調整可能です。テストしたところ、0x3Eで割るとかなりずれが大きいように感じましたので、現在は8000(10進数)で割るようにしています。なおGpsEffectRelativeに0を指定すると0x30レコードのみをGPXファイル出力するようにしています。このモードだと若干位置が南西方向にずれますが、形はかなり正確です。Ver0.17で出力したGPXファイルとオリジナルのCSVから取り出したGPXファイルの比較画像２つを参考まで以下に置いています。
https://github.com/kfd01567/EpsonViewSupportApp/raw/5412e56dc10dacfd4597b42c10b61f91861bde71/MapCompare1.png
https://github.com/kfd01567/EpsonViewSupportApp/raw/5412e56dc10dacfd4597b42c10b61f91861bde71/MapCompare2.png
2025/6/5 23:43
kfd01567
Version 1.0をリリースしました。正式にGPXファイル出力とCSVファイル出力に対応しました。最初のバージョンを公開してから２か月近くが経ち、皆様の協力のおかげでようやく、正式版と言えるものが出来上がりました。感謝感謝です。まだまだ解析しなければならない情報多々あります（高度や心拍数など）。今後も引き続きよろしくお願い致します。_(^^)_
※やはり相対値／絶対値共に4194304で割るとバッチリでした。
2025/6/7 0:38
mkita2018
kfd01567さん 標高については， 上の katsushigeさんへの返信に記入しました。心拍はONとOFFでログをとればすぐ分かると思います。週末にでも試しておきます。ver 1非常に感謝です。(p.s. 六甲登られているようで。私は毎週のように登っているのでいつかお山で）
2025/6/7 1:22
kfd01567
mkita2018さん、六甲山は毎年2回程度は登ってます。今後、六甲山を歩く時にSF-810を付けている方を見かけたら、お声をかけさせて頂くかも知れません。(^◇^)
2025/6/8 20:12
mkita2018
kfd01567さん 最近はほとんど coros と garminを使ています。両腕に付けていることが多いかもしれません。instagram と strava をやっています。insta でこちらの抽出ツールのこと照会させてもうらおうかと思っています。
2025/6/8 22:00
kfd01567
mkita2018さん、私もstravaはやってます。このツール、まだまだ完成度を上げる余地がありますが、色んな機会で紹介して頂けると嬉しいです。解析の協力者が現れることを期待しています（特に私のJ-350など)。
2025/6/8 22:53
kfd01567
Version 1.01をリリースしました。高度(Altitude)の出力に対応しました。高度差のあるテストデータが手元になく、テストが十分でない気がします。configファイルにAltitudeに対する係数を宣言していますので、必要に応じて調整して使用して頂ければと思います。
2025/6/8 19:53
mkita2018
心拍の測定を実施しました。SF-810を２つ持っているため，片方を心拍オン，もう片方を心拍オフで実施。明らかに異なる列が 71のあと3byteでした。
心拍オン 71 (10進に変換して) 72〜135 (22 or a0) 00
心拍オフ 71 00 00 01
71のつぎが心拍そのもののような気がしています。
2025/6/8 21:57
kfd01567
mkita2018さん、心拍の情報ありがとうございます。次のリリースで71直後の値を心拍数として出力するようにしてみます。想像ですが、1バイト目が心拍数、2バイト目はゾーン関係？、3バイト目は心拍採取のオンオフ(0=オン、1=オフ)かな、と思っています。
2025/6/8 22:50
kfd01567
mkita2018さん、心拍数の対応について可能であればヘッダ部(ファイル先頭128バイト)を見て、心拍オン、オフの判断をしたいと思っています。CSVによるとヘッダに「MaxHeartRate」「MinHeartRate」という項目があるようです。おそらくオンオフ２つのファイルの差分で現れているかと思います。さらに次の128バイトのラップデータの中にも「LapMaxHeartRate」「LapMinHeartRate」「LapAverageHeartRate」という項目があり、同様に差分が出ているのではないかと思っています。これらの差分を確認し場所を特定するのは大変かと思いますので、もし可能でしたら昨日採取されたオンオフの２つのBINをご提供頂けないでしょうか。もしご提供頂けるようでしたら、以下のサイトを私宛のアップロードに利用して頂ければと思います。よろしくお願いします。
https://script.google.com/macros/s/AKfycbxW-5idTNIrc_ll2QwVd0J4Wldzpja3kohBWXDOU8WrNPPddQMBjrJ-ba3SfDxpxOAXOg/exec
2025/6/9 16:32
mkita2018
kfd01567さん アップロードしました。ファイル名がそのままであれば，ON，OFFどちらのファイルか分かると思います。1キロ程度のウォーキングのデータです。ログには残らないかもしれませんが，心拍のオンオフ以外に計測中の表示画面は別の設定になっています。
2025/6/10 20:45
kfd01567
mkita2018さん、BINの提供、ありがとうございました。お陰様でVer1.03で詳細な心拍データを出力できるようになりました。
2025/6/11 1:02
mkita2018
kfd01567さん Ver 1.03 を使用させていただきました。出力されたgpxファイル，試しにstravaにアップしてみました。感動ものですね！ところで「CSVファイルを出力しましたが、BODY部の抽出に失敗しました。」と表示されてgpxファイルが出力されない場合があります。原因は分かりますでしょうか。
2025/6/13 0:37
kfd01567
mkita2018さん、「BODY部の抽出に失敗」の件、以前私が書いた「0x30の場合は8バイトの追加、0x41の場合は64バイトの追加」の規則に当てはまらない特殊なパターンが幾つか出てきています。「レコードの先頭が0x40だった場合は462バイト読み飛ばす」など。例外パターンのbinファイルは現在ソースの中で個別処理で対処しています。binファイルをご提供頂ければ、すぐに対応できます。先日のアップロードサイトにてお送り頂ければと思います。
※例外のデータが集まれば、いずれ何らかの法則性が見えてくると思っています。
2025/6/13 6:23
mkita2018
kfd01567さん なるほど。うる覚えですが，違いバイト数のものもあったかもしれません。お言葉に甘えて，ファイルアップロードさせていただきました。workout_binary_13.bin, workout_binary_19.bin, workout_binary_20.bin の３つです。（どれか同じものを２回アップしてしまったかもしれません）私の方でも時間があるときに見てみようと思います。
2025/6/13 20:37
kfd01567
mkita2018さん、BINファイルの提供、ありがとうございました。Ver1.04で3ファイル共に正常にGPX/CSVファイルを出力するように修正しました。またお時間ある時にでもご確認ください。
2025/6/13 23:24
プロフィール画像
ニッ にっこり シュン エッ!? ん？ フフッ げらげら むぅ べー はー しくしく カーッ ふんふん ウィンク これだっ！ 車 カメラ 鉛筆 消しゴム ビール 若葉マーク 音符 ハートマーク 電球／アイデア 星 パソコン メール 電話 晴れ 曇り時々晴れ 曇り 雨 雪 温泉 木 花 山 おにぎり 汗 電車 お酒 急ぐ 富士山 ピース／チョキ パンチ happy01 angry despair sad wobbly think confident coldsweats01 coldsweats02 pout gawk lovely bleah wink happy02 bearing catface crying weep delicious smile shock up down shine flair annoy sleepy sign01 sweat01 sweat02 dash note notes spa kissmark heart01 heart02 heart03 heart04 bomb punch good rock scissors paper ear eye sun cloud rain snow thunder typhoon sprinkle wave night dog cat chick penguin fish horse pig aries taurus gemini cancer leo virgo libra scorpius sagittarius capricornus aquarius pisces heart spade diamond club pc mobilephone mail phoneto mailto faxto telephone loveletter memo xmas clover tulip apple bud maple cherryblossom id key sharp one two three four five six seven eight nine zero copyright tm r-mark dollar yen free search new ok secret danger upwardright downwardleft downwardright upwardleft signaler toilet restaurant wheelchair house building postoffice hospital bank atm hotel school fuji 24hours gasstation parking empty full smoking nosmoking run baseball golf tennis soccer ski basketball motorsports cafe bar beer fastfood boutique hairsalon karaoke movie music art drama ticket camera bag book ribbon present birthday cake wine bread riceball japanesetea bottle noodle tv cd foot shoe t-shirt rouge ring crown bell slate clock newmoon moon1 moon2 moon3 train subway bullettrain car rvcar bus ship airplane bicycle yacht

コメントを書く

ヤマレコにユーザー登録いただき、ログインしていただくことによって、コメントが書けるようになります。
ヤマレコにユーザ登録する