無線ブログ集

ホーム >> 無線ブログ集 >> jl7gmnのblog

メイン | 簡易ヘッドライン

リンク単体表示

jl7gmnのblog (2024/3/11 19:35:35)

現在データベースには 147 件のデータが登録されています。

MODEL 1200FXローテーターその２２ (2022/8/22 4:14:56)

エモトのローテーター1200FXをスマフォのUDP通信を使いリモートコントロールするための基板作製も完了し動作上のスケッチ修正もほぼ終わり仕上がりが近くなってきていますが、基板完成後まだ一度も確認していないスマフォ操作時に使うESP32DivKitCの各ポートに繋がる下記のSW類の動作確認が残っています。

IO32 （Ｐin7)：Logger32とスマフォUDP切り替えSW

IO33 （Ｐin8)：角度プリセット（90°）

IO26 （Ｐin10)：DOWN(-1°）SW

IO27 （Ｐin11)：UP(+1°）SW

IO14 （Ｐin12)：15°UPorDOWN SW

IO12 （Ｐin13)：設置角度停止時のＣＷまたはCCW回転用リセットSW

IO13 （Ｐin15)：15°UPorDOWN SW

タクトSW位置は操作しやすい様に並べて入れ替えてあります。

左から順番に

−1°SW、＋1°SW、プリセット90°SW、リセットSW、±15°SW、±15°SW

☆ポートIOに繋がるSWの動作説明 ----------------------------------------------------------------------------------------------

IO32 ：Logger32とスマフォUDPリモコンのモード切り替え（タクトSWでなく切り替え式SW）

”Ｈ”時（Logger32モード）

”Ｌ”時（スマフォUDPリモコンモード）

上記IO32以外は全部タクトSW（プッシュSW）を使用します。

IO33 ：プリセットタクトＳＷはローテーターをいつも決めた方角に止める為に設定する（任意）角度を設定するSWです。私タワーのアンテナでは西方向または東方向を定位置方向としているのでプリセットは90°または270°のどちらかにしますが、現在は90°にしてあります。このSWを押すと設定角度に90°と表示されるので、スマフォのUDP設定ボタンPreset-GOボタンを押すと　”Ｍ”コマンドが送出されて90°の設定角度へ回転してゆきます。（風が強く吹く方向にフロントもしくはバックを向けておく風対策の一つにしています。）

IO26 のSWの1プッシュでー1°角度を減らします。

IO27 のSWの1プッシュで＋1°角度を増やします。

IO14 のSWの1プッシュ毎の動作

０°→15°→30°→45°→60°→75°→90°→105°→120°→135°→150°→165°→180°→

195°→210°→225°→240°→255°→270°→285°→300°→315°→330°→345°→360°

→345°→330°→315°→300°→285°→270°→255°→240°→225°→210°→195°→180°→

165°→150°→135°→120°→105°→90°→75°→60°→45°→30°→15°→0°

IO14とIO13 は回転の抜きが360°の折り返し時に反転してしまうので方向極性はあえて付けていません。この2つのSWは相反する動作をします。

IO14の動作は、このSWを1プッシュする毎に0°からは360°までは下記の様に＋15°ずつ増やしてゆきます。角度が360°になると逆方向へーで15°ずつ減らしていきます。

IO13 のSWはIO14が＋の動作時には逆のーの方向に動作します。逆にIO14がーの動作時にはIO13は＋の方向に動作します。

IO12 のSWは角度設定動作完了後にCW,CCW方向へ動かせるようにするための設定後の角度を強制で変更するSWです。スマフォUDP通信で設定角度に設定後は設定角度と現在の角度が同じなのでスマフォのCW,CCWのコマンドは動作しない状態です。このSWで現在の位置角度により360°または0°に自動判断で設定角度を設定しUDPのCW,CCWが動作出来る様にします。単独で設定角度に関係なくローテーター角度をスマフォUDPコマンドのCW,CCWで方向を合わせたりしたい時用のリセットSWです。

---------------------------------------------------------------------------------------------------------------------------------------------

先ずはSW類の接続です。タクトSWがたくさんあるので、ブレッドボード上に取り付け、ボード用線材で配線を行ないました。

肝心の各タクトSWの動作確認ですが、TFT液晶での表示も全く変な表示はありませんでした。意外とすんなり各タクトSWの動作チェックが完了しました。

スマフォでの各操作の確認は、もう少し続けたいと思います。

別途、Logger32の動作するＷindows10の動作がかなり遅い状態なので、これも少し原因を確認したいと思っています。

つづく？

HAMLOG H-QSL対応トライしました。 (2022/8/22 4:13:54)

最近のQSOでコロナ禍も相まって、電子H-QSLカードを送るので、紙のカードは不要です。というような事をQSOで聞く機会が増えてきたので自分も対応してみることにしました。紙のQSLカードはそれはそれで完成感がありしかも皆さん絵柄を選びトータル的に個性が出るQSLカードを作られていますので紙QSLカードは、出来栄えを含め素晴らしいことは間違いありません。手書きなどもそれはそれで、味があります。ただ、今回送られてきたH-QSLカードを見る限り、紙のQSLカードに引け劣らない完成度の高い電子QSLカードをいただいたので、本当に驚いています。印刷すれば、出来のいいQSLカードそのものに思える感じです。電子式でのQSLのやり取りもまんざらではないような感じです。それで、対応してみようという気になったわけです。肝心なのは、メールの設定だけですが、各プロバイダーの例が数多くありその中の同じプロバイダーがあればその参考例をそのまま応用できるので、問題はないかと思います。自分の頭だけでメール設定を行うと、うまくいきません。ちょっとした設定箇所が違ったりする感じでしたのでプロバイダーの動作した設定をそのまま使うのが正解かと思います。私の設定で思っていたのと違ったのは、SMTP設定（送信）のポート番号です。プロバイダーの情報でメール設定動作していたメール設定では（送信）ポート番号が993なのですが、動作例の設定ではポート番号が465で動作するといったような違いがあったことで最初自分一人でやってどうしても送信がうまくできない状態でした。同じプロバイダーの参考例通りポートを465にしたとたんメール送信がOKとなったという塩梅です。動作例を参考にするべきですね。ということで、設定は参考例があるのでそれをまねるのが最短でメール接続OKとなります。
あとはHAMLOG E-MailQSLのアプリをダウンロードして起動です。E-MailQSLのアプリはHAMLOGと同じフォルダ内にインストールです。

起動するとこんな感じです。
私の選んだ写真題材としてTS820SのDDS-VFOの写真を使うことにしました。
画像を選ぶとQSLカードのサイズに変換がされます。

QSL定義でのサンプルH-QSLカードがいくつかありますが、私は３
のサンプルを元に修正作成しました。

新規に作成したカード定義ファイル名は‟JL7GMN-1ST-HQSL.mQSL"です。
QSL定義ファイルを編集で開き命令を見ていると、何をどうすれば
文字サイズや位置や、色設定を変更できるのかがわかってきます。
ということで、サンプルの画像を入れ替えた形にしてからH-QSLの
デザインを修正してゆきました。元にする画像の色とか明るさでの
修正が必要です。（文字がバックの色に近かったりすると見えなかったり
というような不具合を確認しながら修正してゆきます。）

下記のように修正してゆきました。
一番上がサンプル画像を変更し取り込んだH-QSL画像になります。
QSL印が見えなかったり、文字が見えないといった箇所があります。
これをわかるような文字色み修正しました。
一番下が最終調整完了ということにしたH-QSLになります。
H-QSL作成中

初めてのH-QSL作成で他の作成情報を何も見てないので
これぐらいしかできません。あくまでもサンプルの修正
のみでの作成です。

H-QSLは上記の通りまあまあではないでしょうか？

実際のQSLをいただいた方のQSO番号を取り込みして表示
させたところ、バンドのアンテナが別のもので取り込みされて
いるようです。ハムログのようにクリックしてアンテナを設定
するような仕組みではないみたいです。取り込み用の情報として
Ｒig/Antがありますが、これは新たに作成し直しが必要でした。
情報ファイルを最初から読み込みしてゆき、最初の該当バンド
アンテナを読み込みする仕様のようです。過去の違ったバンド
のアンテナもファイルに記載されていると最初のバンドで今の
アンテナでないデータが先に取り込まれてしまいます。なので
最新のバンドで使用しているアンテナのみの情報でRig/Antファイル
を作成し直しました。ハムログのデータとは別のデータになるようです。

また、画像を取り込みするとき、最初他のパスからの画像で取り込み
アドレス付きで編集したのですが、HAMLOG E-mail QSLアプリを再起動
してイメージ表示させようとしましたが、エラーとなりました。作成時は
パス付で問題なくイメージ表示されていましたので、ちょっと戸惑いました。
サンプルの画像の場合はハムログのフォルダ内にパスなしで定義例でした
ので、ハムログのフォルダに元画像を移動し、編集でパスを削除し再度確認し
たらエラーなくH-QSLイメージ表示されました。最初からH-QSLでサイズ調整
済んだ画像はハムログフォルダに入れればいいということです。仕様で画像取り
込みはハムログアプリと同じフォルダ内のファイルのみ読み込みです。
でも、作成時のパス付定義でイメージ表示されてたのは不思議で他なりません。！

今後のQSOで対応している局長さんへのQSLはH-QSLを使っていきたいと思います。

今回2人からのH-QSLカードが届いていましたので、上記の絵柄での
H-QSLカードを番号を指定してQSL送信ボタンを押し送付処理しました。
届いたH-QSLカードの交信データとの照合もきちんとできるようです。
後からわかったのですが、下記のテキストボックスに送信する際のコメント
を記載できるようです。今後はいろいろとお礼とかの文章を記載して
H-QSL送付したいと思います。
まだ他の隠れた機能があると思いますが、少しずつ理解して行けたら
よいと思っています。とりあえずは、H-QSLデザインができ、送付が
できれば良しといったところです。

時代にはあっている形QSL交換方法の一つの電子H-QSLカード交換方法です
対応できる方が増えて来て、標準になってくれるとまたカード作成もいろいろ
とアイデアが出てきて、面白くなるかと思います。

つづく？

MODEL 1200FXローテーターその２１ (2022/8/20 17:51:32)

色々と操作の確認をしていて、とても重要な問題に気づきました。前回に行なったスケッチでTFT液晶表示のフォントサイズの変更を行なった事による問題です。TFT液晶表示の為、スマフォとLogger32の切り替えを明確化するためにモード選択SWの判定ルーチンを新たに追加しました。（追加前もモード選択SWのルーチンは既にあったのですが、別のルーチンとして動作で使いませんでした。）このスケッチによる変更修正による表示動作に関しては特に問題ありません。

問題の内容を説明します。この変更修正前のルーチンでの動作では、スマフォのUDP通信モードに於いてもLogger32のDX Spots map上のインジケータが連動動作していました。いわるるノイマン型でスケッチしていましたので、シリアル通信でのLogger32へのローテーターの現状角度データ送出もスマフォ選択時にも行われるスケッチでした。しかし、TFT液晶スケッチ変更修正（新たにTFT液晶表示の為のSWの検出分岐）によりスマフォモード選択時はスマフォモードの処理のみ、Logger32の選択モードではLogger32の処理のみとして動作する状態に変えてしまいました。ついついTFT液晶表示のみを考えてしまったスケッチにしたことにより、新たに問題を自ら作りだしていました。スマフォモード選択時のLogger32へのデータ送出がされない状態にした事です。スケッチ変更修正後でのスマフォ選択時動作はLogger32のDX Spots mapの現在インジケータ指示は動かず停止したままの状態となってしまったのです。この状態で発生する問題があります。スマフォ選択モードとLogger32のモードを切り替えた時の角度の違いによる問題です。簡単に説明すると、Logger32からスマフォ選択に切り替えた時に、スマフォの最終UDPコマンドとLogger32の最終設定角度（マウスによる角度設定赤のライン）が違っていると切り替えた瞬間にローテーターがスマフォ設定角度に動いてしまう現象が起きてしまいます。この現象を避ける為にもスマフォ選択時もLogger32のDX Spots mapも連動していることが必要です。つまり最終のLogger32の現在位置（マウスで赤ラインでクリック設定した角度）をモード切り替えSWでスマフォ選択する前に、予めLogger32の角度と同じ角度をスマフォのUDPコマンドボタンで押して設定角度を同じにすることができれば問題は発生しません。

Logger32の最終設定角度（マウスによる赤ラインでのクリック設定）

予めLogger32のDX Spots mapのマウスでの赤ラインの角度にスマフォ

設定に切り替える前にUDP通信でM180のコマンドを送付設定したあと

で切り替えた時のTFT液晶表示。

切り替え時の設定角度差が２°、３°度位の時の即収束動作するケース以外は、同じ設定角度（０°、±１°以内）になるので、全く動くことはありません。

切り替えをスマフォ選択時からLogger32選択時への切り替え時も全く同じです。スマフォの設定角度表示されている値に、Logger32のDX Spots map上の同じ角度を赤ラインで合わせマウスでクリックすることで、同様に設定角度を同じにする事が出来ます。ラフにクリックでも問題ありません。（同じ角度になる操作を実際に確認してみると、±１°より大きな数°の角度違いは、即収束動作してくれるので、問題はないようです。）

スマフォ設定時にUDPで180°設定にしておきLogger32のDX Spots map

上でマウスで赤ライン180°クリックしてからモードSWを切り替えた時

の値です。

（クリック誤差による±１°差は問題無く動きません。仕様です。）

1200FXの指示によりリモート端子から出ている電圧が元の角度情報

源です。

この問題に対してのスケッチで行う対策としては、モード切り替えSWの新たに追加した判断ルーチンは削除し、スマフォのUDPモード選択時もLogger32からの周期的に送られるタイマーコマンド”C”に対して現在のローテーター角度データを返送するスケッチに戻します。TFTの表示だけは既存のモードSWスケッチルーチンがあるので、表示が問題時と同じになるようにスケッチを再検討し修正します。

既に修正実施して、表示も前と同じ表示をするようになりました。今の所は問題なく動作してくれています。その他、外部SW（プリセット、+15°UP、-15°DOWN、+1°UP、-1°DOWN、がたくさんあるので、これらのSW操作でのTFT表示についてのデバッグも行う予定でいます。

実際に使って動かし、デバッグ確認しながら改善修正のコーディングする事は毎回必要な状態が起きていますが、1回で上手くいった時のコーディングより、スケッチのルーチンの構成の勉強にはなります。

つづく？

MODEL 1200FXローテーターその１８ (2022/8/17 0:14:28)

スマフォのUDPアプリを使ったエモトローテーター1200FXのリモート制御及びHAMのロギングソフトウェア（Logger32)によるローテータ自動制御機能をもたせた回路の基板が出来上がりました。早速部品を取り付けして、動作確認を行ないます。ノートパソコンに繋ぐシリアルインターフェース用として、オークションでArvelのSRC06USBが格安でほぼ新品で出ていましたので、新たに1本落札しました。Ｗindow10と１１での動作も問題ない事は確認済みです。

【NA】新古品及び未使用品に近い商品（数回使用あるかもしれない商品）

と新古品とありました。

価格は税込￥121ですが、送料が￥1,480の合計￥1,601での落札です。まあまあ、お買い得かと！

届いて空けてみたら全くの新品でした。発売からはかなり経っています。WindowXP,VISTAの時代のシリアルインターフェースですが、Windows10,11で問題なく動作します。Window11で手持ちの同じ2本のシリアルインターフェースは無線機とハムログ、アプリのHAMRADIODELUXEで現役動作してくれています。

このUSBシリアルインターフェースをLogger32をインストールしたノートPCに繋ぎ今回のESP32DivKitCのローテータ制御回路のシリアルポートとレベル変換ボードを通して繋ぎ使用します。

回路基板に戻りますが、使用しているパーツはボード回路で使用した物と同じ値を選別して用意しました。（FULL SCALE1.5V の2.5dB ATTのADC1の入力ポート25に繋がる分圧抵抗です。）

R3：120.015kΩ （120kΩ抵抗より選別）

R4：20.156kΩ　（20kΩ抵抗より選別）

R5：2本シリアル接続（215.76kΩ＋266.23kΩ＝481.99kΩ）それぞれ220kΩ、270kΩより選別

500kΩを得るために3本の合計で調整しています。一番抵抗値の小さいＲ4を半固定にして調整する事で

選別なしとすることも出来ますが、半固定は変化する要素があるので、今回は固定抵抗のみ使用です。

目的はR4とR5の合計抵抗値 502.146kΩとR3の120.015kΩとでフルスケールに対応する電圧に分圧する為です。

選別することで実験ボートの回路と全く同じ電圧関係で動作させる事が出来ます。

勿論、ESP32DivKitCも同じものを使います。別のを使うとポート出力にバラツキがあるので再度の下記のポート出力の調整出力値の設定調整（９）が必要となる為です。

void hiZ(int n){
pinMode(n,INPUT);
digitalWrite(n,LOW);
}

//-----------------------------------

void setup関数にて　ポートに出力しレベルをオフセットを調整

void setup(){

......

hiZ(25);
dacWrite(25,9);//9

.....

ESP32DivKitCはソケットを使い挿します。今の所USBから電源を得て動作させていますが、実際使用時は先の回路図にも記載した様にレギュレータICで9Vを5Vに変換して使用します。

部品も抵抗、インダクタ、電解コンデンサ、パスコン、ソケット、ターミナルピン、ジャンパー線と少ないパーツ数なので、簡単に基板に取り付け半田付けも直ぐに完了しました。

SW類のソケットは使わず、パターンにSWからのワイヤー直付けで

スマフォとLogger32の切り替えSW用のみ出しました。

早速スケッチをコンパイルして書き込みを行ないます。同じESP32

なので、そのままUSB接続でも動作はするのですが、基板上に取り付け

してのコンパイルを確認しておく必要があります。（スケッチも改良

予定がある為です。）

コンパイルも問題なく、液晶も問題なく動作しましたが、スマフォから

のMコマンドを受け付けてくれません。元のボードにESP32DivKitCを

挿して確認すると、問題なく動作しています。なので基板側の問題です。

原因をさぐっていくと、SW入力のプリセット90°の入力パターンとモード

切り替えパターンとの半田ブリッジでした。丁度隣どうしでした。SW

ワイヤ−をパターンに半田付した時にブリッジしたようです。プリセット

端子がＬの為90°の動作モードに入り放しでした。

（スマフォ時のＳＷのＬがブリッジでそのままプリセット端子のＬレベル

になった為）

ブリッジをカッターでカットして、スマフォからの動作確認OKとなりました。

エモトFX1200のREMOTE端子とESP32DivKitCへの接続ケーブル

本来はこのターミナルを基板上に付けるつもりでパターンを作製して

いましたが、私の思い込み寸法間違いで取り付け出来ないパターンを

製作してしまいましたのでターミナルは線材で中継接続です。

TFT液晶もそのままの配列での接続です。

簡単なスマフォとのWIFIのUDP通信が出来ましたので、おさらいでESP32

DivKitCのUDP通信の仕様をスマフォで手持ちの無線ルーターを確認しました。

結果をまとめると下記になりました。

周波数は2.4GHzのみ対応

プライマリーSSIDのみ対応

セキュリティ：WPA/WPA2-Personal

IP設定：DHCP

プロキシ：なし

ネットワークの期限：自動検出

MACアドレスタイプ：ランダム化されたMAC

MACアドレス：**:**:**:**:**:**:**

IPアドレス：***.***.***.***　（後省略）

ESP32DivKitCのWIFIのUDP通信では5GHz帯は使えません。

セカンダリーSSID設定では接続しませんでした。

プライマリーのSSIDのみ使えました。

Logger32との接続モードでも問題なく動作してくれました。

今回、基板化出来ましたので、接続コンタクト等の不安定要素は全くなくなりましたので、スケッチへの改良もスムーズに出来る状態となりました。

早速TFT表示のフォントサイズを一回り小さくして、モードの表示とＭコマンドの表示追加を行ないます。（今までのTFT表示だと数値のみ表示されるのでどちらが何の数値かが、わかりにくい状態でした。）

最初の実験時のTFT液晶表示

今回の改良のTFT液晶表示：スマフォWIFI UDP通信モード

スマフォからのUDPコマンド値とMコマンドを表示させました。

FX1200の現在の方向角度表示は”Now"の後に表示されます。また

設定時の方向角度は"SET"の後に表示されます。

今回の改良のTFT液晶表示：Logger32シリアル通信モードLogger32

Logger32モード時には”LOG"と表示させる事にしました。

Logger32上でのDX Spot上の任意角度クリック時、及びWEBのTelnet

接続時（GB7UJS)ログインでのモニター表示局をクリック時の方向角度

（実際のＭコマンド）を表示させる事にしました。

TFT液晶表示文字は下記スケッチ例にて、簡単に変更対応可能です。

//****************************************
// tft display M***command

tft.setTextColor(TFT_WHITE,TFT_BLACK);
tft.setTextSize(3);
tft.setCursor(0,85);
tft.print(" ");
tft.setCursor(18,85);
char cf[6]; //UDP Command
sprintf(cf,"%d",i[0]);
tft.print(cf);
//****************************************

基板版になってから収束のスケッチ部も若干変更をしてあります。

差分値角度が３°の場合と２°の場合の収束に時間がかかる状態があった為（いったり、きたりの繰り返しが多くなる症状）緑のスケッチ追加して収束最短となる用に改善してあります。この改良？でかなり早く収束してくれます。

delta値は収束時の差分が大きくなってしまった時の停止用として使っています。近傍の±６の場合の収束はコピー値のdelta2値をわざと用意して判断する様にしました。使った後の変数値が消える現象が過去ありました。予防的な処置でコピー値として別途の変数で使用すると使った変数は値が消えても、別の変数の為、使う時点で値が消えることはありません。

同じ値をとる差分定義をdelta2として収束させる動作のdelta2値の範囲は６から−６までとしています。収束動作時に差分が突飛に−８または＋８となった時は強制的に停止させます。

変更したスケッチのルーチンは＋か−のどちらかがあれば良いのですが面倒なので、caseでは＋６から−６まで書いたままです。使わない範囲も含んでいます。下記のでdelta<0だと＋側のcaseがdelta2値の取りうる範囲からは不要です。冗長部として認識していますが問題ないのでそのままにしてあります。

変更の一部分のスケッチを下記します。

delta = Readkakudo-kakudo;

if(delta < 0){
        if(delta == -8){
            RotSTOP();
        }
        //:::::::::::::::::::::::::::::::::::::::::::::::::::::::::
        delta2 = Readkakudo-kakudo;
        //------------------------------------
      switch(delta2){
          case 6: RotCW();
                      delay(10);
                      break;
          case 5: RotCW();
                      delay(10);
                      break;
          case 4: RotCW();
                      delay(10);
                      break; 　　

          case 3: RotCW();
                     RotCW();
                      RotCCW();
                    delay(10);
                      break;
         case 2: RotCW();
                      RotCW();
                      RotCCW();
                      delay(10);
                      break;
          case 1: RotCW();
                      delay(10);
                      break;
          case -1:RotCCW();
                      delay(10);
                      break;
          case -2:RotCCW();
                       RotCCW();
                       RotCW();
                       delay(10);
                       break;
          case -3:RotCCW();
                        RotCCW();
                       RotCW();
                       delay(10);
                 break;

　　 case -4:RotCCW();

delay(10);

break;

〜以下省略

if(delta > 0) も同様に緑の箇所の変更を行ないます。この場合でも−側のcaseがdelta2値の取り得る範囲からは不要です。

特に問題ないので＋６から−６の表記はそのままとしてあります。

上記スケッチ緑部変更追加でのモーター制御でかなり収束が早くなりました。

※補足

ESP32DivKitCのledcw（IO 04）,ledccw（IO 22）ポートに繋がった２つのSWトランジスタのON/OFF設定で、各コレクタ出力がグランドレベルになりリモート端子より1200FXのローテータモーターの回転方向を制御します。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

RotCW(); は ClockWise で時計方向まわりの出力ルーチンです。

void RotCW(){
    //CLOCK WISE
    digitalWrite(ledcw,1);
    digitalWrite(ledccw,0);
    Houkou = 1;
}

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

RotCCW(); は CounterClockWise で半時計方向まわりの出力ルーチンです。

void RotCCW(){
    //COUNTER CLOCK WISE
    digitalWrite(ledcw,0);
    digitalWrite(ledccw,1);
    Houkou = 2;
}

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

RotSTOP(); は停止処理の出力ルーチンです。

void RotSTOP(){
    // STOP
    digitalWrite(ledcw,0);
    digitalWrite(ledccw,0);
    Houkou = 0;
    delta=0;
    delta2=0;
}

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

今の動作状態で申し分ありませんが、以前も完成したと思っても新たな問題が潜んでいたりがありました。なので、もう少し動作確認を続けたいと思います。スマフォ時の各スイッチの動作も確認していませんので時間をみてＳＷを配線して確認を行ないたいと思います。

つづく？

MODEL 1200FXローテーターその２０ (2022/8/16 23:51:18)

基板が出来てLogger32でのローテーター動作を確認していて、ふとLogger32のDX Spotsで現状のローテーター角度から任意に近傍の角度設定していた時のことです。別の角度設定したのに回転動作してくれない事がありました。スケッチ上の仕様といえば仕様なのですが、やはり現状の角度と違う時は、設定角度まで回転しないと何か不自然な感じがしました。この動いてくれない角度現状の角度に対して±８°ですアンテナ使用上考えるとHF帯ではビームの半値幅に対しては十分に狭く中心値に近く受信感度上もなんら差がなく受信は出来る角度範囲ではあります。VHFまたはSHF帯でエレメントの多い八木またはパラボラなら影響はありますが！しかし、気になったので、±８°で回転停止制限を外すことにしました。

スケッチ上での設定角度とローテーター角度差がマイナスの時の停止、及びプラスの時のローテータ停止の両方をコメント化するだけです。

マイナス側のコメント化箇所

if(delta == -8){//CHANGE 2022AUG16 NOTHING TODO
// RotSTOP();
}

プラス側のコメント化箇所

if(delta == 8){// NOTHING TODO 2022AUG16
// RotSTOP();
}

上記にて近傍の何処を設定しても動作しない箇所はなくなります。

上記の変更での動作確認をスマフォでのWIFI UDP制御とLogger32でも、もう少しやる必要がでてきました。WIFI UDPではSＷをまだ配線してないので、SW配線を追加してからの確認になります。

つづく？

MODEL 1200FXローテーターその１９ (2022/8/16 23:20:04)

スマフォとLogger32用のエモトの1200FXローテーター制御基板が完成しある程度の動作確認が終わりました。Logger32とのシリアル通信制御時の確認をしていて、2つ分かった事がありました。１つ目は古いバージョンと新しいバージョンでのアプリ上でのローテータ制御方法の違いがある事です。2つ目はTelnetの設定が古いバージョンのオリジナルでは動作しない事の2つです。既に使いこなしている方には、当り前の事かもしれませんが、操作に関しては全くの初心者です。新しいバージョンを使えば気にしなくていいことですが、意味のない事である点も十分承知の上です。私用の忘備録として順に記します。

1つ目ですが、WindowsXp対応の古いバージョン（Ver3.50.0)ではローテーター制御動作の確認を中心に最初行なっていました。最近はＷindow10 で確認を行なっていたので、たまたま古いバージョンで確認をしていて気づきました。その内容（違い）は、次の通りです。Windows10ではTelnetの指定バンドの周波数モニターに表示された局をクリックするとその局のSP/LPのSP（ショートパス）方角へローテーターが自動回転してくれます。古いVer3.50.0では、局の別のフォームが立ち上がるだけでローテーターは自動で局の方角へ動いてくれません。DXSPOTの地図の円盤上のポイントクリックでは問題なくクリックポイントへローテーターは向かって動作し停止してくれます。古いバージョンでは、仕様上、ローテーターのバンドマップとの連動がない事が分かりました。表示された局の情報にはSP/LPの表示はあります。調べてゆくと、別の方法で情報表示された局の方角のSP:ショートパスまたは、LP:ロングパスへローテーターを制御できる事が分かりました。下側に表示されるメニューのRotatorを右クリックした時に表示されるオプションのサブメニュー上でSPまたはLPのどちらかをクリックすることで局の方角へのローテーター自動回転動作が可能となります。多少のメニュークリックの手間はありますが、基本SPを選ぶ事でその局の方角へローテーターが自動回転し停止してくれます。

この点、新しいバージョンは改善されている事がわかります。またこの動作もオプションのメニューで設定できる様になっています。Rotator右クリックメニュー上のTurn rotor on DX Spot click をチェックすれば、バンドマップの局をクリックするだけで局の方角へＳＰで自動回転し停止してくれる動作になります。残念ながら古いバージョンにはこのオプションがありません。この内容は、Logger32のヘルプマニュアル上に記載されていました。やはりマニュアルは見るべきですね！

2つ目は後先になりましたが、Telnetの接続先設定が古いバージョンの情報ではTelnet接続出来ないということです。だいぶ前の時点でサービス終了となっているK4UGAのデフォルト設定が既に廃止ということの様です。K4UGA廃止後の新しいバージョンではGB7UJSを新たなデフォルト設定にしているいる状態の様です。つまり古いバージョンでは新たにTelnet接続先を手動で入れ直す必要があると言うことになります。テキスト形式の接続先リストも下記のWEBページにありましたが、接続先情報が古く既に使われていない情報の様で２，３入れて確認してみましたが接続はできませんでした。今回の手動設定するGB7UJSの情報も下記とは違い古い情報のようでした。

下記の情報で問題なく接続できる様になりました。

Telnet　connection setup...メニュー上に下記を設定すると古いバージョンでもTelnet接続出来る様になりました。

ショートカット： GB7UJS

Remote host： gb7ujs.ham-radio-op.net

Port： 7373

HAM Radio by JA1NLX

上記のHAM Radio by JA1NLX局のWEBページに詳しい情報が盛りだくさんありましたので参考にさせていただきました。大変助かりました。氏のプロフィールからLogger32 Team since 2001ということで、Logger32に精通している方です。

他の情報を見る限り、既にLogger32はかなり進化しているようで、新しい事が多くビックリするようなことばかりです。少しでも身につけたい思いが湧いてきました。

最後にWindow10ならまだしも、ネットを繫いだWindowsXpの化石での動作確認はセキュリティ上でも大変危険極まりありませんね！Windos10を入れてるノートPCも動作が遅く若干ストレスがあります。返ってXpの方がシリアル通信のローテーター動作は機敏だったりしています。ただしプログラミング上、アプリもサクサク動作する様な状態でやっていかないと、チェックどころでは無い面も多々あります。先ずはPCを新しくする事が必要だと強く感じた次第です。

つづく？

MODEL 1200FXローテーターその１７ (2022/8/16 1:15:09)

事後になりますが、CNC切削マシーンの設置後、EAGLE CAD での基板切削用の準備が出来て、CANDLE切削専用アプリ（LINUX版）にて切削開始した記録です。

以前のPCB-GCODEのガーバーデータ作製設定の資料を残してありましたので、ガーバーデータもPCB切削用、ドリル用、基板外形切削ミル用と３つ準備出来ています。久々のＣＮC基板切削で、たった１つだけ失敗がありました。HEIGHTMAP使用の設定を忘れて、切削開始してしまいました。

HEIGHTMAPデータ作製はしたのですが、（☑チェック）チェックを入れ忘れてしまい、設定面の均一切削は出来ませんでしたが、幸い、切削深さは、各面の若干のミル深さの違いはありましたが、特に問題ありませんでした。HEIGHTMAPデータを使用であれば基板のどの位置も均一なミル深さに補正されて切削することが出来ます。

調子をつかむまで時間がかかるかと思っていましたが、一端切削開始後は、時々削りカスを掃除機で吸い取る程度です。基板切削時間は６パスありましたので、６時間はかかりました。ドリルは25分程、外形切削は7分程で終了でした。

CANDLE上のBOTTOM切削パターンのガーバーデータを読み込み

設定したCANDLEアプリ

切削開始後、16分経過時のガーバーデータの切削進行状態

2時間37分経過時の切削進行状態

（数回パス後でパス線が所どころ薄くなっています。）

PCB-GCODEの設定で、基板切削データ＋ドリルデータ、またはそれぞれ

のデータを設定にて別途に作製する事が出来ます。今回は2回に分けて

基板切削データ＋ドリルデータ（ドリルはガイド穴で0.2475mmの深さ)と

その後にドリル専用のガーバーデータで1.75mmの深さでの切削としています。

2時間37分経過時のBOTTOMパターン切削の様子

（刃は3.175平底尖刀10°*0.1を使いました。）

基板切削、ドリル穴あけ完了後、基板外形切り抜きし、ヤスリがけ

し、完成した基板

完成PCBトップビュー写真（部品面）

BOTTOM面の写真（クレンザでの研磨後（砥石使用））

BOTTOM基板の不要銅パターンを削った後,フラックス（HAKKO001)を

キャップの刷毛で塗り完成です。

次回は基板に各パーツ取り付けし、動作確認までの予定です。

つづく？

MODEL 1200FXローテーターその１６ (2022/8/13 10:09:12)

だいぶ間が空きましたが、スマフォのUDP通信でのエモトのFx1200のコントロール用のパターンをCADのEAGLEにて作製することにしました。最初は回路図の纏めからです。頭の中には回路図の変更した点が幾つか覚えてはいるのですが、前の回路図には全然反映されていません。（シリアルポートレベル変換ユニットインターフェース導入など）各入出力端子にも記載をしていなかったので、後から見た時に再度確認しなければならない状態でした。最終の回路図として纏めました。

回路図の端子名に誤記ありましたので訂正差替（2022/8/13)

修正済み回路図

パターン作製はサイズ100X80mmのEAGLEのフリー版の最大のサイズを

使用しています。このサイズで自作は十分間に合ってます。

（中華のガラエポ（片面FR４PCB）をこのサイズで数多く注文してあります。Ｈi！）

片面のPCBですので、パターンに入り組んでいる箇所はジャンパー線での対応

です。もう慣れたもので、パターン作製もさほど時間はかかりません。慣れた

CADを使うのがベストです。

ガーバーデータも作製しておきました。

ガーバーデータ上のドリルの交換コマンドを削除する必要があります。そのまま

動かすと必ずエラーで止まるので、忘れてても、いずれきちんと削除することを

思い出させてくれます。

ここ数ヶ月CNC切削マシーンも片付けてあったので、セットして、軽く動作を

確認してから基板を切削する必要があります。使っていないと何かとトラブル

が起きる可能性があります。（各端子の酸化による接触不良など）

EAGLEでの基板パターン作製は久しぶりでしたが、楽しくパターン作製出来

ました。CADはつかってて、とても面白いアプリケーションですね。

つづく？

Windows11プリンタードライバー設定 (2022/8/9 12:35:30)

Windows11とWindows10のデュアルブートインストールができましたが、Windows11に関してはいろいろと設定が必要な状態です。ハムログでのカード印刷では古いプリンター（PM-A900)をWindows10で使用できていましたので、Windows11も大丈夫と思っていましたが、インストール後何もしなくてもプリンターは使えるには使える状態でしたが、A4とレターサイズのみの設定が可能な状態で、はがき設定ができない状態でした。かなり古いので、対応のプリンターデバイスドライバーがフルでは対応していないような感じです。思い切って新たにドライバーを用意して、用意したドライバーを組み入れることにしました。ただし、国内のドライバーではなく、海外バージョンのプリンタードライバーをインストールです。EPSONのPM-A900の海外バージョンの型式はRX700です。この型式でドライバーをネットからダウンロードします。今だと、OPERAのブラウザ関連と一緒にダウンロードできるようでした。

下記のWEBからダウンロードしました。

真ん中の64bit,Windows10,Windows11 Epson 6.52.00.00(2012-12-11) Printer
のPrinter　Driver　v6.52　の約8.2MBです。

ダウンロード後展開すると2つのセットアップとドライバーがありました。

セットアップ(setup)は統合メニューのようなフォームのインストールになります。今回はdriverのみのアプリケーションインストールでPM-A900(RX700)プリンタードライバーをインストールです。

Printerの設定からすべて英語ですが、問題なくインストールできて、ハムログのQSLカード印刷も今まで通りできました。
デバイスとプリンターには、EPSON Stylus Photo RX700　Seriesとして登録されるようです。

rx700-2022-08-09 121922

プリンターはUSBポートの仮想プリンターとして設定されるようです。

仮想プリンター2022-08-09 122230

Window11でもWindowsXp,Vistaでメインで使用していたPM-A900がまだまだ使用できるのがうれしいです。
ハムログでのQSL印刷も今まで通り、問題ありませんでした。

つづく？

Hamlogと無線機のコントロールfor Windows11その２ (2022/8/4 21:15:00)

無線機2台とハムログをシンクロ動作させるのに仮想シリアルポートの作成アプリを使いましたが、フリーアプリと思っていましたが、限定期間のアプリでしたので、完全なフリーのアプリの候補を別途１つ試してみました。うまくいきましたので、忘備録として設定を残したいと思います。案外とすんなり仮想ポートを作成できたのはいいのですが、いまひとつ元のCOMポート設定をしていないので、若干これでいいのか？と不安なところもありますが、動作上はOKなので、まずそのままの設定を残したいと思います。
使用したアプリはWeb名　NonSoft からダウンロードしました。設定は他のWebページを参考にしています。

NonSoftでの設定対応OSはWindows8が例ですが、問題なくWindows11でも動作問題ありませんでした。

このアプリはフリーでは定番のようです。

NonSoft

【設定】
①Virtual Port Pair 1のCOM1設定
VirtualPortPair1-COM1-2022-08-04 180613

②Virtual Port Pair 2にCOM2を設定
VirtualPortPair2-COM2-2022-08-04 180613

■設定完了後のVirtural Port Pair 1とVirtual Port Pair 2（これで仮想ポートCOM1とCOM2 が作成されます。）
com0com-3-0-0-0-x64 2022-08-04 180432

以上でCOM1,COM2の仮想シリアルポートが作成できたことになります。仮想シリアルポートの各設定は何もしていませんので、接続先のシリアルポート動作情報から自動で読み取りして設定されているとしか思われません。ある意味すごいアプリだと思います。
これでポートの設定は行い、HamRadioDeluxeアプリを２つ無線機毎に起動し、問題なく無線機のFT-2000D（COM2),FT-1000MP(単独シリアルインタフェースCOM3),ハムログ(COM1)がシンクロ動作してくれました。
HamRadioDeluxe(FT-1000MP:COM3: 4800bps)
HamRadioDeluxe(FT-2000D :COM2:38400bps)仮想ポート動作
HamLog(COM1:38400bps)仮想ポート動作

つづく？

続きを読む

« [1] 4 5 6 7 8 (9) 10 11 12 13 14 [15] »

execution time : 0.060 sec

無線ブログ集

リンク 単体表示

リンク単体表示