新しい機能を追加頂き有り難うございます、早速試しています。

一度試し印刷を行い、スマホカメラで内容を確認し大丈夫だったので本番で一気に45枚印刷しました。
これは内容を確認していません。

ところで本日一枚のみ印刷した所、不思議な結果があったので報告させて頂きます。

正しい内容
9月17日 08:08 7.084 7*1*** 局との交信

おかしな内容
従来のデータ欄の交信内容は正しく上記のデータで、QRコードのみ 8月27日 07:34 7.053 J*2*** 局の物でした。
このデータ間のログは105データ分離れた物です。

？と思い、改めてQSLカードのイメージ表示を行い確認したらこれは正常でした。
そこでこれを紙に印刷し、間違ったQSLカードのQRコード上に貼り付け処理しました。
（丸ごと再印刷しなかったのは、紙ログとの割り印捺印後のため）

何故発生したのかはさっぱり不明で、一応こんな事が有ったという報告です。
二次元BCRは発注中で、まだ届いていないのでスマホで確認しています。

Windows11 Pro 21H2
Brother HL-L2730DN
UTP 有線接続

以上参考まで…

【2023/09/17(Sun) 10:13:25 投稿者により修正されました。】

ビューロー発送待機中のQSLカード80枚(2023/07/17〜09/17)にQRコードのみをインクジェットプリンタで印刷したところ以下のようなデータ不整合が発生しました。御連絡まで。
なお、当局、QSLカードのデータ記入は手書きで行っています。今回印刷後のQRコードはガラホ(docomo F-02J)のカメラで読み込みました。

○事例1
[ログデータ]：JQ2○○○ 230717 1807 430 FM
[QRコード読み込み結果]：!!JE1OTN 230730 1320 430 FM 8N1○○○
8N1○○○のQSOデータは読み込み結果のとおり存在します。
事象は1枚のみ

○事例2
[ログデータ]：JA1Y○○ 230827 1323 430 FM
[QRコード読み込み結果]：!!JE1OTN 230827 1323 430 FM JO7○○○
交信年月日、時刻、バンド、モードは正しいですが、相手局のコールサインがJO7○○○になっています。JO7○○○とは2023/09/16にQSO
同様の事象が計7枚

○事例3
[ログデータ]：7K3○○○ 230811 1603 430 FM
[QRコード読み込み結果]：!!JE1OTN 230811 1603 430 FM JJ1□□□
交信年月日、時刻、バンド、モードは正しいですが、相手局のコールサインがJJ1□□□になっています。JJ1□□□とは2023/08/13にQSO
同様の事象が計15枚

○事例4
[ログデータ]：JA1Z○○ 230806 0838 430 FM
[QRコード読み込み結果]：!!JE1OTN 230806 0838 430 FM JJ1△△△
交信年月日、時刻、バンド、モードは正しいですが、相手局のコールサインがJJ1△△△になっています。JJ1△△△とは2023/08/06にQSO
事象は1枚のみ

【参考事項】
HAMLOG：Ver5.40(2023/09/13)
QSL印刷定義ファイル
****************************
; QRコードだけを印刷する
#QRCode 765,0,0,180,"JE1OTN"
****************************
Windows10 Home 22H2
プリンタ:CANON TS7530 USBケーブル接続
QSLカードは業者による両面印刷済みのもので、QRコードの印刷のための余白部分が狭いので、QRコード外側の赤色枠のうち1辺は印刷できない状態です。3つの角にある四角のマークは確実に印刷できています。
正常にQRコードを読み込めているカードも同じ印刷状態です。

P.S.【妄想】
このQRコード機能、JARLビューローで採用したら滞留解消にならないかな。

【2023/09/17(Sun) 14:11:40 投稿者により修正されました。】

藤井OM
検証有り難うございました。

24/80で再現したとの事…
当方は45枚印刷し、発送してしまっていますので確認は出来ないのですが同じくらいの確率で違うデータが印刷されてたかもしれないですね。
当方の例だと”何故再表示して結果が違う”のか？って言うのが気になります。
読み込む先が毎回違ってる(？)というデジタルな世界では不思議な事が起きてるような

多分来年の今頃に相手の手元に届くとは思うのですが、おそらくBCRで処理する方はまだ少ない頃だと信じたいです。
普通は修正ウィンドウで気がつくとは思いますが…


なお定義は

#QRCode 40,1200,0,150,"JN1EOT" ;QRコード
#FontSize=7
#Print 28, 1370, "Hamlog用QRコード "

３行目は45枚印刷時には無くて、今回付加した物です。
それの実験中に本事象を確認した次第です。

「妄想」の件、手書きの方も多いでしょうけど、印刷版QSLだけでも負担は減りそうですね。

ただ今二枚印刷しました。
一枚は藤井OMの事象2と同じで、コールサインは交信実績が20年前に一回だけ（50MHz）の方で、その他データは目的の物（7MHz）です。
QSLの発行番号で言うと36605枚の差が有るコールサインでした。

※ 印刷イメージで確認したら正常で、何枚か前後表示させて再々表示しても正常でした。

もう一枚は正常（430MHz）でした。

150枚ほどプリンタに出力してしてみました。
実際には印刷せず、プリンタの機能による印刷イメージで確認してみました。
プリンタに印刷データはすべて送ってあるので、HAMLOG側から見ると印刷です。

結果、１５枚ほど確認しましたが、まったく異常ありませんでした。
#QRCode命令はどの辺に記述しましたか？　なるべく上の方が良いと思います。
私の場合は３行目でした。

; 既成の白紙カードに印刷する by JG1MOU
#SetXY 10, -30
#QRCode 6,1220,0,220 ;省略可能(自局コールサイン)

#Read命令があると、次のデータを読み込んでしまいます。

> 結果、１５枚ほど確認しましたが、まったく異常ありませんでした。

御確認ありがとうございました。お手数お掛けいたしました。

> #QRCode命令はどの辺に記述しましたか？　なるべく上の方が良いと思います。
> 私の場合は３行目でした。

当局のQSL印刷定義ファイルは

; QRコードだけを印刷する
#QRCode 765,0,0,180,"JE1OTN"

この2行だけです。

> > #QRCode命令はどの辺に記述しましたか？　なるべく上の方が良いと思います。
> > 私の場合は３行目でした。

浜田OMお手間をお掛けしました
そして遅くなりました

当方はOMの定義ファイル、上から16行目(空白行含む)からです。
READ命令は入っていません(QSLカード毎の識別印刷設定が上に入っていました)
とりあえず3行目に移設してみました。

> ただ今二枚印刷しました。
> 一枚は藤井OMの事象2と同じで、コールサインは交信実績が20年前に一回だけ（50MHz）の方で、その他データは目的の物（7MHz）です。
> QSLの発行番号で言うと36605枚の差が有るコールサインでした。
>
> ※ 印刷イメージで確認したら正常で、何枚か前後表示させて再々表示しても正常でした。
>
> もう一枚は正常（430MHz）でした。


JN1EOT 池田さん

>検証有り難うございました。
いえいえ、検証などという大層なことではないです。(^_^)
昨日、最初に1枚だけQRコードを印刷してコードを読み込んだところ事例1の不整合がありました。その時は印刷時の設定操作誤りと思っていました。すぐに再印刷をしたところ正常でした。その後計80枚分のQRコードを印刷しました。
本日、池田さんの書き込みを見てカード80枚について念のためガラホで読み込んだところ、あのような結果になった次第でした。再チェックのきっかけを与えていただき、こちらこそありがとうございました。また、定義ファイルで"Hamlog用QRコード"と注釈をコードの上に?印刷するアイデアも参考になりました。

当局の事例の特徴としては、QRコード読み込み結果で間違って飛び込んでくるコールサインは本来のコールサインの交信年月日、時刻より新しい年月日、時刻(期間で約2ヵ月、Noで125程度)のものでした。

ベータ版ですので検証作業に協力できたということで・・(^_^)

P.S.
妄想(QRコードのビューローでの採用)ですが、QRコードの採用だけで済む話ではなく、カードを仕分ける機械や多くの局のカードを格納する棚など多額の整備投資が必要であること、QRコードを印刷しない局の方が多数と予想されることから、まだまだ道遠し(永遠に無理？)という感じですね。
QRコード印刷のカードは3か月で転送、QRコードがないカードは半年以上とメリットを強調すれば普及に拍車が掛かるのではないかとまたまた妄想しています。

当方はポスト投函してから気がついたので万事休すでした。 ＜ ベータ版で確認しなかった自己責任です

「Hamlog用QRコード」の文字列は、結構ご自身のブログページをQRコード紹介されてる方も多いので記載してみました。
ドイツのビューロの話もあるようなので、プリフィクスで判断してドイツ語等の文字列に出来れば良いんですが！

ベータ版の検証に参加できたのは有意義だったと思います。

妄想の件ですが、据え置き型連続読み取りリーダーと相手のコールサインのみディスプレイに大きく抽出表示できるアプリとか有れば、現行のビューロでも活躍できそうですね。
当方にはアプリ制作できませんので妄想です！

> 妄想の件ですが、据え置き型連続読み取りリーダーと相手のコールサインのみディスプレイに大きく抽出表示できるアプリとか有れば、現行のビューロでも活躍できそうですね。
> 当方にはアプリ制作できませんので妄想です！

私の妄想です。(笑)
QSLビューロでは、FromとToのコールサインについて、JARL会員／非会員のチェックを
しているようなことをどこかで読んだ覚えがあります。
ということは、専用アプリがあればピッ！とやるだけでチェックが可能です。
データさえあれば、私でもそんなアプリ作れます。Hi

> QSLビューロでは、FromとToのコールサインについて、JARL会員／非会員のチェックを

そうですよね！
それを手作業でやってるとは思えない…
ぜひ採用していただきたいですね。
転送処理も早くて労力も減りますから良いと思います！

事例1はどうも考えにくいです。

他の事例はコールサインだけの違いということですので、コールサインを記憶している
内部的なグローバル変数を変えてみました。

修正版です。
https://hamlog.sakura.ne.jp/mou/index.html

JG1MOU 浜田さん

> 事例1はどうも考えにくいです。

了解いたしました。印刷時の設定操作誤りの可能性もある気がしてきました。

> 他の事例はコールサインだけの違いということですので、コールサインを記憶している
> 内部的なグローバル変数を変えてみました。
> 修正版です。
> https://hamlog.sakura.ne.jp/mou/index.html

修正版の御対応ありがとうございます。さっそく使ってみます。

修正版(2023/09/17 16:50)により再度QRコードを印刷しました。コールサインが不整合な事象は発生しませんでした。全て解決しました。御対応ありがとうございました。m(__)m

> 修正版(2023/09/17 16:50)により再度QRコードを印刷しました。コールサインが不整合な事象は発生しませんでした。全て解決しました。御対応ありがとうございました。m(__)m

確認ありがとうございました。
右端のコールサインとモードは照合するのに使っていませんので、間違っていても
影響はありません。
違うコールサインが出たのがなぜなのかわからないのですが、間違いのないはずの
手法に変更しました。

> 右端のコールサインとモードは照合するのに使っていませんので、間違っていても
> 影響はありません。

当局の事例2〜4(No.25759、右端のコールサインのみ不一致)のカードを送っても、相手局では正常に受領チェックができ、なおかつ、QRコードリーダーでピッとした後は「データの表示&修正」画面になるので、関係のないコールサインを目にすることもないすばらしい仕様だと理解しました。

> > 修正版(2023/09/17 16:50)により再度QRコードを印刷しました。コールサインが不整合な事象は発生しませんでした。全て解決しました。御対応ありがとうございました。m(__)m
>
> 確認ありがとうございました。
最初は印刷だけでもと思っていましたが、Win11のカメラで比較的簡単に受け入れ出来そうなのでこれで試していきます。量が多く成ればリーダーも良いかなと思っています。何しろ封筒で来る程度ですから。

途中まで読んで先の返信（25770）をしてしまいました。

早速の対応有り難うございます。
当方も藤井OMの例で言うと”事例1”のパターンでした。
二度目の発生分は”事例2”のパターンでした。

いきなり印刷すると発生してるようにも見えましたが、検証しきれていません。
イメージ表示ではおかしくなった事は無いみたいですが、検証数が少ないため当てにならないと思います。

しかしただ今新版V5.40に入れ替えました。
様子を見たいと思います。
お手間をお掛けしました。

【2023/09/17(Sun) 21:31:52 投稿者により修正されました。】