automatic tabulation system for hamradio contests, parallel computing framework, programming language processors, machine learning, etc.
autodyne nextzloghttp://jarts.jp からATS-4を導入したいという依頼がありました 連絡先などの情報はXで添付した通りです
jucky154インストール時にDLLsに書く内容がフルパスになってしまう。 DLLsの内容をロードする際はDLLsの内容でロードしている。 そのため、プラグインフォルダを変更すると食い違いが出る。
##解決策 zLog側の方では ①DLLsはDLLの名前だけにして ②ロード時は絶対/相対のパス解決を行う様にする というものが検討されている
https://github.com/jr8ppg/zLog/issues/640 に上がっていたので転載
jucky154ATS-4がJARLサマリーシートの処理に依存し過ぎている。
CabrilloやJARLサマリーシートの処理をDSLに委譲する。また、サマリーシートの内容をJSONに変換する処理は、QxSLに移植する。
JG1VPPmsg : string型のZyLO側の変数
reiwa.RunDelphi('MainForm.WriteStatusLine("'+msg+' ", False)')
でzLogの下側のところ(invalid nuberの警告などを表示する部分)にmsgを表示できる
msg : string型のZyLO側の変数
reiwa.RunDelphi('op.Put(MainForm.CallsignEdit, "Text", "' + msg + '")')
でzLogのコールサインの欄にmsgをputできる
msg : string型のZyLO側の変数
reiwa.RunDelphi('op.Put(MainForm.NumberEdit, "Text", "' + msg + '")')
でzLogのナンバーの欄にmsgをputできる
リアルタイムコンテストDLLにおいて適切に得点計算が行われていないのではないかという問い合わせがあった 考えられる理由としては, https://github.com/nextzlog/zylo/blob/c1ea32be8642a0f878cf4328b3d4769643627c92/src/plugins/rules/rttest/rttest.cfg#L39 のようにリアルタイムコンテストのCFGにはDLLが計算をするという指定があるものの,
OnVerifyEvent
OnPointsEvent
がhttps://github.com/nextzlog/zylo/blob/c1ea32be8642a0f878cf4328b3d4769643627c92/src/plugins/rules/rttest/rttest.go#L87 の リアルタイムコンテストのプラグインのコードに含まれないため, 得点計算などが行われていない可能性がある
jucky154ATS4をよりアマチュア無線界隈に広めたいが, コンテスト主催者側から攻めるのは困難が一部存在するということがわかった そのため, 逆にコンテスト参加者側から主催者側に「なんで ATS4にしないの? あれ便利だからそっちにして欲しいんだけど」という方向の作戦もありだと思われる
それを踏まえると, コンテスターの利便性向上が求められる. 有名コンテスターはN1MMを使っていることが多いため, N1MMのログをadifにせずに, そのまま直接提出することができれば, 利便性向上につながると考えられ, 目的の一部達成につながる可能性がある.
また, 世界的にも進出させることを考えると, 世界的なロギングソフトへの対応は, 重要だと考えている
N1MMはSQLiteのs3dbなるものを使っているぽい?
jucky154CW4ISRの開発を活性化するため、非公式リリースのリンクをREADMEに記載する。例えば、jucky154/cw4iを記載する。
JG1VPP現状のCW4ISRでは、クリックノイズを拾うことにより、誤ったメッセージを解読する場合がある。これを言語モデルで防ぐ。
最も単純な方法として、単純ベイズ分類器により、誤ったメッセージを除去する方法はどうか。
JG1VPPPRに対してCIを実行し、マージをブロックする。
ZyLOとCW4ISRは、go fmt
の実行とgo test
の正常終了を条件とする。
ATS-4は、テストを実装したCIが未整備のため、引き続き運用を検討する。
個別にPRを受け付ける運用の場合は、テストの成功をマージの条件とする。
JG1VPPOBの方から、確定していない文字の表示に関して、「出てくる文字が確定していないところはコロコロ変わる。それも無線家の頭の中に浮かぶ文字ではないものが表示される。よって、混乱を招くので確定していない文字、つまりは文字間の空白が来る前の文字は表示しないようにするべき」という要望が出た。 (現状、コロコロ変わる文字はhttps://blog.goo.ne.jp/ykimata/e/b5dee1229c784c05b39ae74456260010 のように聞き取れた部分までの分岐点の場所で、結構混乱するかもしれない)
確定していない文字を表示しない手法が求められる
以前の確定していない文字を表示しない手法は前回と同じ文字のみ表示するというものだった (https://github.com/jucky154/cwListener/blob/b24f4925e8132212f0b2920dec0917762bb08aa8/cwListener.go#L218 ) がかなりコードが複雑化しているので、あまり採用するべき手法ではないと考えられる。
よって、OBの言うとおり、「文字間の空白が来る前の文字は表示しない」という対応が良いと思われる。 対応としては https://github.com/nextzlog/cw4i/blob/5dae69de1cc035755d3241c8c3db3a123de44e0a/core/symbols.go#L27C1-L36C2 の部分に関して、
func CodeToText(code string) (result string) {
for _, s := range strings.Split(code, " ") {
if val, ok := reverse[s]; ok {
result += string(val)
} else {
result += "?"
}
}
if code[len(code)-2:len(code)-1] != " " {
result = result[len(result)-2:len(result)-1]
}
return
}
のように対処すれば最後の部分が文字間の空白であれば確定なので表示し、そうでないならば最後の文字は確定していないので表示しないといった対応が可能であると考えられる。
jucky154CW解読機に関して、さらなる発展が求められている(ハムフェア)
そして、その中で、CW Skimmerはベイジアンを使っているという話があった
http://ag1le.blogspot.com/2013/01/towards-bayesian-morse-decoder.html 以前も上のブログは読んでいたものの、真面目に読んでいなかったが、いろんな段階でベイジアンを使っているようだ CW4ISRでも、ベイジアンを一部の段階で使ってみるのはありなのかもしれないので、調査や実験が必要だと思われる
jucky154使用したCW 動画 URL: https://www.youtube.com/watch?v=oJfdofz8O8A&t=380s https://www.youtube.com/watch?v=WPwnSe2v3Ts&t=241s 2つ試した。
特になし。急ぎません。
irukabandoCW4ISRとzLogを連携させるzLogプラグインを整備する。自動交信を支援する機能を備える。
CW4ISRとはプロセス間通信で連携する。例えば、go-winioを使用する?
cwListenerの位置付けが問題だが、不具合もあるので、コードを煩雑化させやすい解読・マイクデバイス選択・履歴表示等の機能はCW4ISRに委ね、自動交信機能に特化させる手もあり。
JG1VPPCW4ISRはJavaScript (ES5)でイベントハンドラを定義可能だが、現時点では、読み取ったメッセージの編集ができる程度。
decoder.Program = function(message) {
message.Text = message.Text.replace('5NN', '599');
message.Text = message.Text.replace('ENN', '599');
return message;
}
もっとCW4ISRの設定を細かく調節したり、デバッグ・可視化機能やRPCによる外部連携を強化したい。
Goの構造体・メソッドの形式で、JavaScriptから呼び出し可能なライブラリを充実させる。それらは、以下のように渡される。
vm := goja.New()
vm.Set("RPC", RPC{})
https://github.com/nextzlog/todo/issues/176 に関連するが…
おそらく、多くの人が求めていることはS/N比がよくない音声でもモールスを解読できることである。 求められていることを実施できるCW4ISRとしたい
現在、一般に使われているモールス信号解読機であるCW SkimmerとのS/N比の比較 および CW Skimmerと同程度の耐ノイズ性の取得 (STFTで耐ノイズ性が得られるかは微妙… 音声から波形へのアルゴリズムや波形からモールスのon/off検知アルゴリズムを真面目に考える必要がありそう) CW Skimmerも表示としてはSTFTみたいなものが出るが、どうやってそこからモールスの解読をしているのだろうか?
jucky154現在、CW4ISRは3局パイルアップ(実際の交信録音)を用いて広報を行い、好評を博している。 その中で、CW4ISRの能力に関する質問が数多くなされている。質問の回答になるような公称能力の確定する公試を行う必要がある。 そのテストデータの作成・公試の実施が必要。行う内容としては、
テストデータはzylo/encoderとかをうまく使ってwavを作ればよい?(どうencoderを使うかがわからない…) 公試は繰り返しやって何回正しく解析されるか、から判断する? 以上の観点で試験をして公表・動画化をしたい
jucky154既知の問題だが、送信が開始された瞬間には符号語として検出されず、バッファに蓄積された後に検出されると、バッファから溢れた分の符号語が消失し、例えば、JがOと解読される。
CW4ISRで何度か交信の音声を流してみれば再現する。
正しくJと解読する。
早めに。
JG1VPPGitHub Actionsではコミットがない状態で60日放置すると、cron実行が停止される。
以下が影響を受ける。特にマーケットプレイスが勝手に更新停止される可能性がある。
検討中。コミットがあれば停止しないが、安易な解決策に頼るのは…
JG1VPPZyLOで開発された中には、必ずしも常駐する必要のないプラグインもあり、不必要にzLogのパフォーマンスを低下させる。
プロセス間通信の仕組みを整備して、DLL以外の連携方法を開発する。ビルド時にDLLもしくはプロセス間通信を選択できるようにする。
JG1VPPエラーがあると出るだけでどこがエラーなのか不明。
タイトル通り
赤で示すなど一般的に行われているUIとすればよいのでは。
ATS-4の運用に必要なサーバと環境構築を行うサービスを提供するとして、採算性を検討したい。
まず、どの程度の需要があり、かつ、そのうち何割が実際に導入に漕ぎ着けるのかを把握する必要がある。コンテスト主催者でATS-4に興味のある方は、このIssueに追記していただけると助かります。
JG1VPP高校コンテストの規約が我々が作った時と変更になっているようです http://hstest.mg-sci.com/wp-content/uploads/2020/07/2020_31st_hstest_rule.pdf 2020年のルールだとHSマルチは消えないのですが、 http://hstest.mg-sci.com/wp-content/uploads/2022/06/2022_33rd_hstest_rule.pdf 2021年以降のルールだとHSマルチは削除されるようです
SSBとCWで交信した際にはHSマルチが消えるようにする
早めに
jucky154QSO.Insert,Delete,Update
メソッドを呼ぶとzLogが落ちる。
func onInsertEvent(qso *reiwa.QSO) {
qso.Insert()
}
QSOが追加・削除・更新される。
未定
JG1VPPhttps://github.com/nextzlog/todo/issues/124 で完成したモールス信号解読の技術とリグコントロールを積極的に活用し、周波数帯の監視及び自動応答の機能を有するプラグインを実現する。
GitHubの組織としての無線部開発班は、以下の開発に興味がある方を募集しています。主に無線従事者が対象ですが、大学社団等の所属は問いません。
可能であれば、公開メンバーとして活動いただければと思います。設定は各自でお願いします。
JG1VPP運用をなんとかすれば(ウィンドウを閉じない)問題なさそうな問題が解決されていませんが、ボチボチ見栄えのいいプラグインができましたので、広報を検討しないといけない
JA1ZLOというお約束のものだけでなく、パイルアップ・カスカスの局の解読もやらせた動画を撮ったのでそれをツイートする?
https://user-images.githubusercontent.com/58735989/197546870-6f7a6e87-83f0-4d80-8b5f-fccf498579d6.mp4
jucky154マーケットプレイスは、どれかひとつでも誤りがあると、全体の更新が停止するように構築している。その場合は、管理人は速やかに状況を修正する責任がある。ここでは、そのための連絡を行う。
JG1VPPzLogにおいてtelnetやリグコントロールの設定をするとプラグインが無効化されますがいいですかという警告が出る
zLog v2.8.3.2の日本語版(英語版は未確認)で各種設定->オプションからリグコントロールやパケットクラスターの設定( どちらか一方でも再現されました。 過去に一度、この警告を見ると見ないこともあるようです。 再現する場合は、zlog2.8.3.2をダウンロードしてすぐにプラグインをインストールして、その直後にここの設定の部分だけしてOKを押せばできると思います)をして、OKを押すと以下のような警告が出る。しかし、自分がやった限りではこの後にも普通にプラグイン(CW解析)は動いた
このような警告は表示されない
ALL JA
jucky154CW解析プラグインがエラーによって開なかったとの報告をZLO部員からもらった マルウェアとして検知されているらしい
以下がエラーコード errormessage.txt
ウイルスとして認識されないようにする
ACAG?
jucky154CTESTWINではコンテストの対応状況が明記されている。このあたりのドキュメント化が不足している。
/contests以下にテーブルを配置して、コンテスト毎の案内を掲載する。CFGファイルで対応可能なコンテストは、単にCFGファイルの頒布サイトにリンクを貼る。プラグインで対応しているコンテストの場合は、その導入方法を別のページで明記する。
JG1VPPSEOを意識して、CTESTWINとzLogの対立軸を明確化して、集客を目論む。
星取り表を作って公開する。例えば、
機能 | CTESTWIN | zLog |
---|---|---|
ほげ | ○ | ◎ |
ATS-4は電通大コンテストに機能面では対応しているが、ALLJA1とは異なり、コード品質の保証も含めたサポートではない。
最低限、電通大コンテストの得点計算のテストをALLJA1と同様に実装してはどうか。
JG1VPPこれはZyLOというよりもzLog令和editionの機能をより多くの人に知ってもらい、その結果利用者が増え、ZyLOの利用者も増えるみたいなことを考えたものです
zLogの機能や設定について説明(wiki)やググってもわからない際に、どうしようもなくなってしまう
https://forum.air-hamlog.com/c/support のような「機能の質問や説明を利用者同士(たまに開発者側)が行うサイト」を作る必要がある気がします。
そもそもの設置に関して どこでforumを開くのがいいのか… そのサーバの管理をどうするか… アカウントなどをどうするのがよいのか… githubのアカウント登録は英語ですし、携帯電話による認証など(その対応すら英語)が必要なので、zLogを使う人(年齢層高めが多い)にはハードルが高い気がしています
運用について 基本的にはCFD Online Forumsやyahoo知恵袋のように利用者同士が教え合う形にしておく必要がある。 上のAir Hamlog のForumは、利用者が開発者に問い合わせる形になっており、開発者が忙しく回答できない場合(メンテができなくなった場合, zLogの2002年以降のように)は使いにくいものとされてしまう
真面目な話、zLogプラグインは、クラウド連携や自作ハードウェアとの連携が中心になる。 で、これらの分野でキラーアプリが不足している。というわけで、アイディア出しをしよう。
JG1VPP問題意識 ZyLOにしてもzLog 令和editionにしても機能が十分に認知されていない(この辺はJR8PPGさんと共通の見解 (https://twitter.com/jr8ppg/status/1548997253658198016 )) そのため、なんらかの周知の工夫を行う必要がある。
解決方法
ATS-4で書類提出するコンテスト参加者が遭遇するトラブルの典型例(実例)をここに自由に記していく。
JG1VPP問題意識 自分が持っているATS-4オペレータ向けの知識を広く一般に公開し、ATS-4を利用しやすい形とする
解決方法
問題意識
音声読み上げ機能を利用して提出する参加者にとって、ATS-4が生成するHTMLは問題ありとの報告があった。
解決方法
HTMLにtitleタグを埋め込む等の対策を進める。
JG1VPP