ZCR/bLOG


[Radio] eQSL.cc再び

2017年04月06日 21時 更新

2年前、「様子見」という結論に達した eQSL.ccだが、ADIF 3化(UTF-8サポート)については ぜんぜん進展がない。planはあるけど 実際にはまだ動けないということなのか。まったくもって Disappointedだ。

それは置いといて・・ LoTWの記事コメントで ヤル気でない・・と書いたものの、実は この手のデータ変換は 昔取った衣笠*1である (^^;)。

常置場所での運用データは 運用地情報=自宅なので、Remarks2に入れてある衛星情報を吐くだけ。1エリア時代は杉並→府中→市川と引っ越し、位置情報はこの3つのみで衛星QRVも無いので Remarks1の移動地情報を吐くだけ。


問題は やはり /7のLOGだ。やり方を いろいろと考え、最終的にはエクセルで読み込み、マクロは ほとんど使わない 力業 で ADIFファイルを作りあげることとなった。*2

衛星を使った移動運用では、Hamlogの Remarks1(移動地情報)とRemarks2(衛星情報)を合体*3させる必要があるが、長くなりすぎると InBoxのリストのコメント欄には問題なく表示できても、肝心のQSLカードの画像データからハミ出してしまい、例えば衛星名がQSLカード画像に表示されなくなってしまう。eQSLは印刷できてナンボ*4。ここらへん注意する必要がある。



常置場所ADIFファイルは約15,000レコードだったのだが Background Modeでの一括UPLOADですんなり通った*5ため、/7 のADIFファイル約27,000レコードも同様にBackground Modeでの一括UPLOADをおこなったのだが、全部送ったハズなのに最後の約6,000レコードがOutBoxに無い。

そこで、その足りない約6,000レコードを2分割し、今度は Foreground Modeで2回に分けてUPLOADしたのだが、まだ足りない。
調べてみると、ちょこちょことレコードの抜けがあり、さらに計1,000レコード程度がOutBoxに到達していないことが判明した。

仕方ないので後からUPした約6,000レコード以外を 7分割し 約3,000レコードにしてシコシコとForeground ModeでUPLOADしたら、ダーッとDUPEエラーが出たもののようやくOKとなった。

しかし・・こんなレコード落ちするシステムって信用できると思う? ちょっとマズイんじゃね?



さてさて、いちおうUPLOADはなんとか完了したのだが・・ 当方としては、またログをUPLOADすることはあると思うものの、この eQSLを使ってQSLをゲットしよう・・ なんて 気はさらさら無いのである。すくなくとも、現時点では・・ね。

というわけで、InBox内のeQSLの ConfirmやReject処理は 放置・・かな。Rejectしたいのに取り込まれてしまったのもあったりするし・・(T_T)*6



2017.04.06 追記:

さらに 1年が経過したが、ADIFファイルのアップロードについては 未だに 日本語が文字化けしてしまう不具合が解消されていない。

嘘つき !!

昨年12月中旬までのデータはアップロードしてあるが、今後も そうするかどうかは 現時点では言及できない。


*1 あ~る的には「むしり取った衣笠」が正しい。

*2 某テキスト・エディタの正規表現による置換も併用。

*3 やはり、Hamlog側で Remarks1とRemarks2それぞれを吐き出せるようにしていただけたら・・と思う。タグの名前はテキトーでもいいので・・ Hamlog側で合体していただいても・・

*4 印刷されないデータは InBoxのリストに表示されていたとしても存在しないのと一緒。JARL等のアワードには使えない。

*5 実際は、LoTWと同様に mode JTMSが引っかかり、このQSOレコードだけが無視される形になった。LoTWやeQSLというよりも、ADIFの規格自体に JTMSが存在していない。

*6 QSLカード画像にあるQTHやコールサインが違ってたり・・orz

Tada/JA7KPI : 2016年03月17日(木)

«LoTW 最新 ラジアル・アース»
編集