今までのローテーターの停止の方法を再度考え直してみました。なぜかと言うと、収束する方法で静止させる方法はローテーターに対しては回転機構のギヤの破壊行為となる危険性があるということが気になっていたからです。基本に忠実にローテーターの現在のコントロール方法で静止するまでのステップを全部まとめると、収束動作無しで止まる様な問題とならないケースもなかにはありますが、設定ポイントの角度を超えてしまったケースでは反対方向へと必ず収束動作をしてしまいます。コレは設計仕様です。改善するとしたら、きちんと停止させてからの反対方向への回転をさせるのがギヤを破壊しない良い方法であると分っています。ただし、スケッチ的には出来ますが、静止するまではまた、戻り角度オーバーしたりとかの動作も予想されるので、静止まで時間がかかる事が当然想定されます。停止をいれた方法では、少し検討と確認が必要となりそうです。現在の収束仕様ではCW方向も、CCW方向もポートに繫いだスィッチングトランジスタでON/OFF制御のDC電圧で動作回転させています。回転している時は、同じ電圧ですので静止直前も回転しているときも同じ回転スピードです。目的の角度の±７°ぐらい手前で回転信号の長さを変えて０°になるまでの差分でだんだんと短い電圧を掛けて制御するようにしていましたがやはり同じ電圧なので多少の長さ調整では、モーターがフル回転なのでオーバーランしてしまう事が多い様です。

例の如くハードウェアは既に基板化して出来ていますので、やるとするならばソフトウェアでの対応になります。ということで、ソフトウエアでスケッチを考える必要が出来てきました。言葉でやりたい事をまとめるとすると、目的の設定角度を超えないで止める別の方法を考えれば良いと言うことです。とても簡単明瞭です。文字にした形も無い方法は紛れも無くやりたい事そのものですが何をどうするという具体的な事がまだありません。コレを実現したいので、先ずは使っているESP32DevKitCの機能で対応使用出来るフィチャーがないかを調べてみました。ネットでも調べている内にLEDの明るさを制御する方法の解説がありました。いわゆるＰＷＭでパワーコントロールする方法です。モーターへかける電圧をONしている時間とOFFしている時間のＤuty比（比率）を変えて回転を早くしたり、遅くしたりが出来る方法として応用出来そうです。コレを使って見ることにしました。うってつけの方法になりそうです。早速自作の試験ボードとブレッドボードで現在のローテーター回転制御している同じポートで配線して確認です。その前にESP32DevKitCのどのポートがPWM制御出来るかを仕様から確認しました。いま使っている回転制御のポート04と22はPWM可能でした。因みに、全部ではありませんが、殆どのポートはPWM制御出来るようです。（自分が使いたい、または、使っているポートのPWM対応は必ず確認は必要です。）

■試験中の04 と22のポートにLEDを繫いで光り具合を確認しました。

■テスト様にスケッチした簡単なDUTY比での明るさ確認用スケッチです。

//PMW TEST for IMPULUVING NO CONVERGENCE BEHAVIOR OF CCW & CW ROTATION
// 1200FX EMOTATOR UDP CONTROL
//
const int ccwPin = 22;
const int cwPin = 04;

void setup() {
  // put your setup code here, to run once:

  //      (ch,freq ,bit)
  ledcSetup(0,12800,8);// 0channel setting
  ledcSetup(1,12800,8);// 1channel setting

  //           (PortNo,ch)
  ledcAttachPin(ccwPin,0);// 22 attach 0channel
  ledcAttachPin(cwPin,1); //  4 attach 1channel
}

void loop() {
  // put your main code here, to run repeatedly:
  //ledcWrite(0,64);// ON    64:256 -> 1:4
 
  //       (ch,Dutyratio)
  ledcWrite(0,128); // ON   128:256 -> 1:2
  delay(100);
  ledcWrite(0,0);   // OFF
 
  ledcWrite(1,128); // always ON 1:2

  delay(100);
}

上記の簡単なスケッチでDUTYの確認です。

詳細な設定はしらべてもらうとして、まとめると下記になります。

１．使うポートを定義します。

２．void setup()ルーチンにチャンネルと周波数と制御するbitを設定します。

３．同じルーチン内に使用するポートとチャンネルをアタッチします。

４．void loop()ルーチンにはledcWrite(チャンネル,＊）で＊に０から２５６最大のうちから設定

＊が０だと出力OFF、２５６だとフル出力、１２８だと５０％DUTY比で出力

（設定最大は２５６なので１２８では５０％のDUTY比率の出力です。）

■テスト中の波形５０％DUTY

上の矩形波形は常時出力している様に見えますが、出力矩形波はON/OFFしています。

下の矩形波は連続出力です。

このスケッチを応用して組み入れてます。

考えている動作は以下になります。

他の位置から目的の設定角度へスタート開始時は次のコマンドでDC電圧でフルにローテーターモーター回転動作します。

ledcWrite(0,256);

CW方向、及びCCW方向回転時どちらも、現状の角度と目的設定角度の差分角度が±１０°手前になったらスピードが遅くなるようにDC電圧をフルから比率12：256のDUTY比でパワーを下げるようにパワーコントロール開始します。スピードが遅くなったことでオーバーラーンはしないで停止する様にこのコマンドスケッチを入れました。

ledcWrite(0,12);

幾つかのDUTY比（128、64、32、16）のコマンドスケッチを入れたサブルーチンを作りパワーを減少する方向で試しましたが、あまりローテーターの回転スピードの下降変化は感じられませんでした。上記のコマンドスケッチ12の比率だと遅くなったと十分感じられましたので、上記のledcWrite(0,12)にしています。停止確認も期待通りでした。オーバーランはせずに停止してくれました。

上記のコマンドを入れた実際のサブルーチンは下記になります。

//************************************************

//■CW方向フル回転時

void RotCWHS(){ // port04 ch1,　HS : High - Speed  CW
　　//PWM out
　　ledcWrite(1,256);// CW ON
　　ledcWrite(0,0);  // CCW OFF
}

//■CW方向スロー回転時
void RotCWSS(){ // port04 ch1      SS : Slow - Speed CW
　　//PWM out

　　ledcWrite(1,12);// CW ON
　　ledcWrite(0,0);  // CCW OFF
}

//*************************************************

//■CCW方向フル回転時

void RotCCWHS(){ // port22 ch0    HS : High - Speed  CCW
   　//PWM out
    　ledcWrite(0,256);// CCW ON
　　ledcWrite(1,0);  // CW OFF
}

//■CCW方向スロー回転時

void RotCCWSS(){ // port22 ch0     SS : Slow - Speed CCW
　　 //PWM out
　　ledcWrite(0,12);// CCW ON
　　ledcWrite(1,0);  // CW OFF
}

//*************************************************

上記のサブルーチンを角度差分のSelect case で±10前から±1°までにスピードスローとなるサブルーチンを入れます。勢い良く回転してきたHS回転を１０°手前にてSS回転でスローにするとゆっくりブレーキがかかった様に丁度いいタイミングで勢いが弱まってcase０:のルーチンの停止コマンドスケッチ下記で停止します。

Select case の0°では停止のルーチン下記ルーチンの　 RotSTOP()； を入れます。

//■停止ルーチン

void RotSTOP(){
　　//PWM out
　　ledcWrite(1,0);  // OFF port 04
　　ledcWrite(0,0);  // OFF port 22 
　　delta=0;
　　delta2=0;
}

上記の電圧ＰＷＭ制御方式を採用しDUTY比率を下げる事によりローテータ制御SWのON時間の平均が下がります。ON/OFF制御の平均値ON時間コントロールにて結果、モータースピードが遅くなります。遅くなった回転ではオーバーラーンセずに停止する事が出来るようになります。

電圧のPWMのDUTY比率を変える（下げる）事で解決です。モーター回転数はCWスイッチ、CCWスイッチをPWM制御にて制御する事で、間違いなく下げる事ができました。止まる時は目的の設定角度に近づいて、ゆっくりスーッと止まる感じになりました。とにかくハードウェアの変更対応をしなくて済み、ソフトウエアのみの対策で上手く行きましたので、ひとまずギヤを壊す制御ではなくなり安心する事が出来ました。結果としては、まずまず、大成功と言えると思います。Hi !

厳密に言うと停止してても現状の停止した角度と目的設定角度と差分値がある場合では、極小の電圧パルスがでています。回転出来ない様な微小パワーレベルなので０に等しいと言えます。オシロスコープでは確認出来ます。LEDも少しチカッと光っているかな程度です。この程度のパルス電圧だけではローテーターは回転しないので良しとしています。

UDP通信のデバッグは継続しています。

つづく？

ふとESP32DevKitCのサーバー化を検討中に、ローテーターの停止ルーチンで大切なポイント（確認項）の不足があることに気づきました。大切なポイントとは、ローテーターの停止設定値に対してある位置からローテーターを回転させて、角度の差分が近づいてきた時にブレキー的なルーチンを入れて停止させてゆくのですが、肝心の差分が０となった時の停止設定を入れてませんでした。（一番重要なルーチン）ファンクション化して動作確認中はスケッチはあったのですが、いつの間にか削除してしまってました。時折でしたがローテーターがいったりきたりが多かったりする原因になっていました。（設定値と同じ角度になった時も動いてしまう原因）不足スケッチの追加でのデバッグ修正になります。case 1: case:-1の処理時に差分値をdelta2 = 0とするスケッチも追加。

■定義域のRotSTOP()ファンクション

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

■Void loop(){ルーチン内の修正箇所

〜略

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();

              delta2=0;

              delay(10);

              break;
      case 0 :RotSTOP();

              delay(10);

              break;
      case -1:RotCCW();

               delta2=0;

              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;
      case -5:RotCCW();
              delay(10);
              break;
      case -6:RotCCW();
              delay(10);
              break;
      default:
              break;      
    }

略〜

上記の停止項（case 0)の追加で完全に、動いてゆき回転停止する時の設定角度近辺でのいったりきたりする動作は、ほぼ皆無となりました。

ローテーターを停止しない状態で、いったりきたりさせるボタン操作はローテーターのギヤを壊す原因となることがあるらしく、回転方向を変える場合は必ず停止状態を作り、それから元と逆の回転動作を行う様にする事でギヤの破損を防ぐ事が出来ると、ある社長さんからエモトの社長さんとの話した時の情報ということで教えて頂いていました。DXを追いかける時のSメータを見てのCW、CCWのSW操作は、回転が停止しない状態の時に逆方向のＳＷを押さない様にとの事です。ＤＸ局はすぐには逃げませんからね。ローテーターを長く使用するためには、慌てた回転動作は禁物という事です。（アンテナ自体の指向性はHF帯のアンテナではブロードですから少しぐらい方向が違っても送受信での影響はないと思っていいかと思います。（UHF/SHF帯では違いますが Hi!）)

ローテーターには重いアンテナがのっていますから、急には止まれなないし、この時の逆回転ではギヤが壊れるというのは納得出来ますね。手動操作時でも注意は必要ですね。Hi!

部屋の中でのテストで、ローテーターには何もついていない無負荷で、気づいてよかった修正でした。

つづく？

1200FXローテーター側のESP32DevKitCのサーバー化を行ないました。忘備録です。

（1200FXのローテーターのコントロールで使っていた家のWiFiのルーターは、はっきり言うと、不要になります。ローテータ制御では使わないだけで、他のパソコンでのネットサーフィンなどでは勿論使います。Hi !　）

どのような設定をするかと言うと、いままでのスケッチの定義設定の変更とサーバー用スケッチの追加です。簡単なスケッチセンテンス追加なので簡単です。Hi!

いままで、Linuxでのサーバー化特集の記事を見てもよく分からなかった事が、今回のESP32でのサーバー化をやってみて、サーバー化とは、どういう事なのかの大枠がおぼろげですが見えてきた様に思います。パソコンよりとても理解しやすいと思います。サーバー化は実際に設定して動かしてみることが間違いなく、最も早く理解できる方法だと思います。

早速ＷiFiを使ったUDP通信のサーバー化設定を行ないます。

以下のようにサーバーにするESP32の定義を修正します。

■ IPアドレスをサーバー用に設定

設定出来るIPアドレスは割り当て済みがあるようなので使用できるIPは詳しくは調査が必要です。

（今回はサンプル例題にあわせて設定してます）

//const IPAddress ip(192, 168, 4, 3);       // IPアドレス(ゲートウェイも兼ねる)
const IPAddress ip(192, 168, 30, 3);  // AP IPアドレス(ゲートウェイも兼ねる)自分で適宜設定
const IPAddress subnet(255, 255, 255, 0); // サブネットマスク
const IPAddress client_address(192,168,30,4);

■いままでの家庭用のルーターのSSIDとパスワードを自分で決めて書き換えます。

//const char ssid[] = "**************"; //ご自分の家のルーターのSSIDに書き換えてください
//const char pass[] = "*************"; //ご自分の家のルーターのパスワードに書き換えてください

設定の例）

const char ssid[] = "ESP32_MYHOMEwifi" ; // SSID change to original  server name
const char pass[] = "**********";                    // password 任意

■サーバー用の定義を追加します。

WiFiServer server(80); //add for server setting 2022/oct/22

■void setup()ルーチンにサーバー開始センテンスを追加します。

server.begin(); //add for server bigining 2022.oct.22

■void loop()ルーチンにはクライアントにサーバー利用可のスケッチを追記します。

  WiFiClient client = server.available();   //add for server setting 2022oct22

以上の設定だけで、ESP32DevKitCに自分のＷiFiによるサーバーが出来上がります。家のルーターは使わなくても良くなります。（ESP32サーバーとESP32クライアントでのＷiFiを使ったローテーター制御UDP通信となったので、家のＷiFiルーターを使う通信が必要なくなりました。）

■クライアント側へは、サーバー化のスケッチ追加設定等は何もありません。

クライアン後側は接続IPアドレスをサーバー側に合わせ書き換えるだけです。

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

スマフォのWiFi設定で上記の ESP32_MYHOMEwifi が確認できます。自分の設定したサーバー名が表示されると,とても嬉しくなります。

TFT液晶表示では、次の画面の表示のためにドットを消すルーチンも追加してます。

〜

省略

WiFi.begin(ssid, pass);
  delay(100);
  int ii = 0 ;
  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");

    //****************************************
    // Connecting Message display
    tft.setTextColor(TFT_WHITE,TFT_BLACK);
    tft.setTextSize(2);
    tft.setCursor(0,0);
    tft.print("Connecting!");
    // Connecting display dot data
    tft.setTextSize(3);
    ii=ii+2;
    tft.setCursor(ii,36); //22oct23
    tft.print(".");
    //****************************************
    delay(100);
  }

　 //****************************************
    //  Erase "Connecting!"
    tft.setTextColor(TFT_WHITE,TFT_BLACK);
    tft.setTextSize(3);
    tft.setCursor(0,0);
    tft.print("           ");
    //  Erase "." area
    tft.setCursor(0,36); //22oct23
    tft.print("                      "); //erase "."
    //****************************************

上記にてクライアントのESP32DevKitCに電源を入れONにして、サーバーに繋がるまで、Connecting!表示の次の行でドット".” が右に動いてゆきます。サーバーに繋がるとこの画面は終了し、サーバーから送られてくるNow：に現在のローテーター角度が表示されます。

つづく？

ローテーターから常時角度表示をしているESP32DevKitCの親ステーションから、スマフォから角度アスキーコマンドのUDP送信と同じ機能をもたせたるようにしたESP32DevKitCクライアントのスケッチも検討してみました。問題が１つだけあリました。スマフォでPresetGO設定の”M”コマンドのみのアスキー送出動作に関してです。角度の"M090"などは問題なく動作してくれています。PresetGOはスマフォだと動作してくれるのですが、ESP32のUDP送信では動作してくれません。受信データをシリアルモニタでみても同じ受信データなのですが、ESP32クライアントからの"M"コマンドだけは動作してくれません。原因はデータのデリミタが無いためかもと思い”/￥”コードを追加してみたところ動作するようになりました。受信シリアルモニタ上ではスマフォと異なる表示データとなっていますが、動作したので現状OKとします。やっつけ仕事です。Hi !

UDP送信でのアスキーコマンド送信がスマフォと同じように動作してからは、親ステーションと同じ角度表示をするための親ステーションからのUDP送信のスケッチ追加と、それのクライアント側でのUDP受信スケッチの追加を検討してみました。

先ずは、親ステーション（1200FXをコントロールする側）への角度情報表示しているデータをクライアントへ送出する部分です。内容は簡単で角度情報をクライアントへUDP送信するルーチンの追加だけなのですが、実際にスケッチを考えてゆくと0から255文字までのデータしかアスキーデータは送れない壁に突き当たりました。Webでも上記と同じ問題についての情報が結構ありました。

この壁の内容詳細は、角度で言うと255°を超えた256°は0°となってしまう現象です。これの対策としてはパケットにしてデータを分割送出する手法を取る必要がありました。対策は下記のWebページの方法３を応用して解決しました。（”通信処理では1byteしか送れない”という決まりがあるということです。）

３．0-255より大きい整数や少数を送りたい

Arduinoでバイナリ送受信のシリアル通信をするときのパケットの構造

1200FXをコントロールしているESP32DevKitC親ステーションでのローテーター角度表示部の角度情報の変数 Ｒeadkakudo を2byteで分割送出するようにしました。例では4byteですが角度では2byte分割送出で済みます。（上位ビット下位ビットをそれぞれの1byteデータを2回送出するという事）TFT液晶に角度表示している箇所で使用している角度情報変数を使います。

〜略

 //*********************************************
  tft.setTextColor(TFT_WHITE,TFT_BLACK);
  tft.setTextSize(3);
  tft.setCursor(0,0);
  tft.print("Now :");   
  char ce[4];
  sprintf(ce,"%3d",Readkakudo);
  tft.print(ce);
  //******************************************************************************
  //  UDP data Send to client (STA mode)  add 2022oct24
  //******************************************************************************
  //udp.beginPacket(ip,localPort);
  udp.beginPacket(client_address,localPort);

  //Sending Readkakudo to Client Devided data byte High and byte Low add 2022oct25
  // int32_t Readkakudo;
  uint8_t ReadkakudoLH = (uint8_t)((Readkakudo & 0x0000FF00) >> 8);
  uint8_t ReadkakudoLL = (uint8_t)((Readkakudo & 0x000000FF) >> 0);

  udp.write(ReadkakudoLH);  //send byte Hight data by UDP
  udp.write(ReadkakudoLL);  //send byte Low data by UDP

  udp.endPacket();
    //*******************************************************************************   
  tft.setTextColor(TFT_WHITE,TFT_BLACK);
  tft.setTextSize(3);
  tft.setCursor(0,44);
  tft.print("SET :");   
  char cc[6];
  sprintf(cc,"%3d",kakudo);
  //sprintf(cc,"%3d",dd);
  tft.print(cc);  
  //********************************************

少しかかりましたが、単に角度表示している値をUDP送信するという上記ルーチンの追加で済みました。

クライアント側では、送られてきたUDPデータを受信デコードしてTFT液晶に送出したコマンドと同じように現在の角度を表示させます。loopルーチンの頭にUDP受信のスケッチを追加します。

TFT液晶への表示では、角度数字の桁の位置表示調整をしないと見栄えが悪いので、10以下の場合スペース2文字分、100より下の場合スペース1文字分を入れて右詰め表示で揃う様にしてあります。

void loop() {
  uint8_t dataLH;
  uint8_t dataLL;
 
  int32_t rv_data;
 
  int rec_size; //recieve data number
  // データ受信

  if (rec_size = udp.parsePacket()) {
      Serial.print("rec_size = ");
      Serial.println(rec_size);
      
      counter_100msec = RE_CONNECT; // re connect counter resets.
 
      uint8_t dataLH = (uint8_t)udp.read();
      uint8_t dataLL = (uint8_t)udp.read();
   
      int32_t rv_data = (int32_t)(
           (((uint8_t)dataLH << 8) & 0x0000FF00)
         | (((uint8_t)dataLL << 0) & 0x000000FF)
      );
      Serial.println(rv_data);

      tft.setTextColor(TFT_WHITE,TFT_BLACK);
      tft.setTextSize(3);
      tft.setCursor(0,0);
      tft.print("Now :");
   
     // rv_data value change add blunk for set digit right location
     if(rv_data < 10){
          tft.print("  ");
          tft.print(rv_data);
      }
      else
      if(rv_data < 100){
         tft.print(" ");
         tft.print(rv_data);
      }
      else
      if(rv_data >= 100){   
         tft.print(rv_data);
      }  
  }

省略〜

上記のスケッチ追加で親ステーション側での1200FXの現在の角度情報のUDP送信、そしてクライアント側でのUDP角度情報の受信がリアルタイムで出来るようになります。

これでクライアントではスマフォの角度情報送信だけでなく、送った角度情報でローテーターが回転している間もリアルタイムの角度情報を受信することが出来る様になりました。現在のローテーターの位置がクライアントで常時見れます。とても便利になりました。この状態でデバッグをもう少し続けます。

■親ステーション側の1200FX現在のローテーター角度表示

Readkakudoの270の角度情報を常時UDP送信しています。

■クライアント側の常時親ステーションからの角度表示（電源ON後）

Now ：270 と親ステーションと同じ位置にTFT液晶表示されています。

なお、使う際の電源ONの手順ですが、起動する順番はローテーター電源を一番最初にONします。次にローテーター側の親ステーションESP32に電源ONします。次にクライアント側のESP32に電源をONにする順番で起動してゆきます。

現在は家庭のメーカーターミナルでＷiFiを利用していますが、ESP32のフィチャーでWiFiサーバーが作れる様でなので、ローテーター1200FXのコントロールで試してみたいと思います。ESP32のサーバー機能を使いＷiFi-UDP通信へとバージョンアップです。親ステーションから親サーバー化へステップアップします。スマフォにて接続表示されてるＷiFiにESP32で設定する自分のサーバーが表示できるようになるということです。こんなことも出来るESP32はやはり凄いですね。最高です。

いまＷiFiサーバー化へトライしている最中です。

ほかに、DDS-VFOで使ったシリアルデータ送出でのデュアルコア導入と同じようにUDP通信の受信と送信をデュアルコアで別々に動作させる応用もできそうです。時間があればこれもトライしてみたいと思います。現状特に表示上のレイテンシもなく、リアルタイム動作してくれてますので、気がむけばですが。Ｈi！

つづく？

現在、前の７ＭＨzのアンテナではなかったのですが、アンテナを変えてからアマチュア無線バンドの７MHｚで、200W出力でのパソコンへのインタフェアーがあります。1/4ラムダの自作バーチカルアンテナでは問題無いです。また、100W運用では問題ありませんが、200W運用では使っているアプリケーションのシリアル通信がフリーズする現象が出るため、色々とパッチンコア等の対策も行なってみましたが、完全にはインターフェアーはなくなっていません。音声のピークでシリアル通信が止まる現象がでます。PCの方からピッと音が出る様な状況なので、先ず考えられるのはPCの電源への高周波の回り込みが強いんだと思われます。ACコードへの5〜6個でのパッチンコアでの高周波の減衰は少ししか望めないとの情報もあり、-30dB減衰効果を期待するには数十個も直列に入れないといけない様です。パッチンコアでは限界があるため（−30dB減衰が取れない）電源ライン用のフィルターを2個購入することにしました。

メーカーは　TDKーLambda です。電流により選べるので、パソコン系用としては十分すぎる容量ですが、RSHN-2016 にしました。

訂正：アマゾン通販では価格は安かったのですが、在庫がなくカタログのみ閲覧でした。

注文は一番安いと思われるアマゾンにしました。

最終的にはモノタロウで2ケ注文しました。

資料上見ると、7MHz帯でのコモンモードとディフェレンシャモードそれぞれの減衰特性では−70dBと結構期待できそうな感じです。電源ラインからの高周波の回り込みが予想したとおりの原因で、コレが効いてくれれば良いのですが…。電源からでなければ、コモンモードの同軸ようのフィルターを考えます。

アンテナのＳＷＲが高いのも問題となることなので、アンテナも調整しSWRを下げる事も必要ですね。

下のグラフの右上のRSHN-2016が購入注文中のコモンモードとデイフェレンシャルモードの特性です。

届いたら配線して取り付けて7MHzのインターフェアーの確認をします。

電源での7MHzでの効果がなかったとしても、入れたままにしておこうかと思っています。必要なものという考えからです。

つづく？

私がAliexpress通販で注文したものと違うものが届き、紛争処理セずに、最初にショップとの交渉で不足の2.4GHzのＷiFiアンテナをこちらで注文し、ほぼ、ただで送ってくれることでおりがつき、交渉成立したのですが、なにせＷiFiアンテナ価格自体が安いものなので、配達時期は12月となっていたので、気長に待つことにしていました。ところが、今日、届いたんです。コレにはおそらく、何かしらの条件があるように思えます。注文がこの安い2.4GHzのＷiFiアンテナだけであればやはり、12月の配達になっていたと思うんです。ということで、明かすと、他のショップに別に注文したもの2つと合わせて3つが同包されて送られてきました。

■送られてきた商品の梱包袋

■袋の中身（別々の注文した製品の包、３つ）

■交渉成立分で送付されてきたのは黄色の一番小さな袋です。

■少し大きな黄色の包は別のショップに注文したブレッドボードと配線線材

専用電源（＋5V,＋3.3V）です。

デビットカード支払いの方法確認した時に、確認上やむなく購入することに

なった必要と思っていた安い部品たちです。（やむなくとは書きましたが

いずれ購入するつもりでいた部品です。Hi !）

■リミットSWです。クランクアップタワー用の保守パーツです。

日本では高くて購入する気が起きないです。やはりAliexpressの価格の安さ

は魅力です。中国製かと思っていましたが、しっかりとOMRONのロゴが

ありました。本物かどうかはわかりませんが、生産国はインドネシアで

した。中国製ではない様です。＠￥864

（調べたら上海にOMROM工場がありました。インドネシアは販売拠点は

ありました。）

不思議なのが、注文したところのカタログでは＠￥1,674でした。バーゲン

セールだったのかもしれません。

ということで３つの注文があらたに袋につめられて送付されてきたということです。同包もなにもこちらからは言ってませんので、送付宛先が同じものが纏められた可能性もあります。いずれにしても2.4GHzのＷiFiのアンテナの納期は10月15日注文しましたので26日の今日ですから11日と予定の12月の納期より、かなり早く届いたことになります。同包することにより合計金額が増え、短納期化対象への変更がなされたのかもしれません。いずれにしても全部が早く届いたので、まずは、ＷiFiアンテナなしのESP32に早速2.4GHzWiFiアンテナを付けてコンパイルかけて動作確認したいと思います。

実は既にコンパイルしてあります。ESP32どうしが50cmの距離では、アンテナがなくても動作しましたが、付けると通信範囲がのびるのでしょう！

つづく？

エモトの1200FXローテーター側のESP32DevKitCとのUDP通信で角度のアスキーデータを送信するUDP TCP Serverで、目的のスマフォからの角度設定が出来るようになりましたが、設定したキーの固定角度のみでした。任意に角度を設定出来るアプリがないかと少し探してみた所、ありました。UDP Monitor なるアプリです。

■スマフォでの最初のUDP通信コントロールアプリ

■UDP Monitor　任意角度設定送出対応可能なアプリ

■UDP Monitor 操作パネル

ターゲットとなる親のESP32DevKitCで設定したポートとIPをスマフォアプリUDP MonitorのRemote PORTとRemote IPに設定です。スマフォのローカルIPは自動で設定されます。少し紛らわしいのですが、ローカルポートも同じに設定してます。（別にスマフォ側の受け側のポートということで任意設定可能のようです。サーバー側とは異なって構わないということです。）

■任意角度の設定入力箇所　下側のＭessageに送出角度のコマンド仕様設定値を手入力で対応します。

■Ｍessage入力時のスマフォ

■Ｍessage欄への入力例（角度123°を設定）

コマンド ”M123” を入力後右の▷をタッチしてESP32へUDPデータ送信です。

このアプリはWebのQRZ.COMなどでの局検索での角度情報やハムログでアマチュア無線局のコール登録者検索時に表示される角度を入力すると、そのアマチュア無線局の方位へピンポイントでローテーター（1200FX)が回転して合わせてくれるというわけです。前のアプリの固定設定の角度以外の角度を任意に設定し、UDPデータ化して送信することが出来るということです。

（勿論、利用するＷiFiのネットワークは利用可能なネットワークでESP32側もスマフォ側も同じ設定に予め設定しておきます。）

方位角度設定が自由になったのでローテーターコントロール用として、ある程度の利用価値があるアプリかと思います。

ただし、アプリの機能では角度を設定送付するだけなので、少し物足りないです。この点は、アプリにない機能として、クライアント側での設定角度のUDPデータ送出後に親側のESP32から現在の角度情報をUDPデータで常時送出し、クライアント側でこれをUDP受信し設定するまでの角度情報が逐次受取表示出来る様な双方向のUDP通信が必要かと思います。検討し双方向UDP通信で出来る様にしたいと思います。ない機能は考えて製作するしかありません。これが出来ると、基本機能が充実した事になり、一段と利用価値が上がると思っています。

つづく？

手持ちのESP32DivKitCが少なくなってきたので、いつも部品購入で利用している中華のAliExpressで購入をすることにしました。実は、USB以外のESPの別電源の動作を確認している時に端子接続を間違えて２個程壊してしまったためです。端子接続は注意をしないといけませんね。

9月24日にESP32DivKitC(ESP-WROOM-32D)を４個注文しました。注文は種類が多く掲載されてるので、目的の物をしっかりと見極めて、間違えないように注文しました。

上記の中から色とあるので、購入対象の雄一WiFiアンテナ付きのESP-WROOM-32Dを４個程注文です。

単価は為替で刻々とかわります。上の＠￥524は購入時の画像です。今現在は　＠￥531で

若干価格が上がっでいました。

10月も過ぎて3日に小さな袋に4個入った注文した商品が届きました。注文した商品か確認の為に早速袋をあけてみました。ガビーンでした。4個とも別のタイプの型の商品が入っていました。さてどうしたものか、です。

ということで、初めて、商品が違うものが届いた場合の処理をすることになってしまいました。実際のやり取りを記録に残し、今後に活かしたいと思います。

先ずは何と間違えて送られてきたかの型番の確認をしました。

注文したESP32-WROOM-32Dに対し、届いたのはWiFiのアンテナが外付仕様だけ異なるESP32-WROOM-32Uでした。４個ともWiFiアンテナが付いていない仕様です。

アンテナがないだけなのでスケッチは全く同じで使えますが、わたしの注文品とは異なります。なので早速連絡です。注文したストアへは メッセージ で、連絡することが出来るので先ずは下記の様な連絡をしました。

こちらからは英語で対応です。ネットのWeblioを使い和英変換です。変換された英文は少し変えたり調整してのメッセージ送付です。

先ずは、届いた商品が自分の注文品と異なる事を第一に連絡しました。また、WiFiアンテナが内蔵されていないタイプの32Uが届いたことも連絡です。そして、先ずは４個とも全交換でメッセージ送付です。

次に証拠の写真を数枚送りました。

すると中国語で、よくわからないので空けてみてと要求がきました。Weblio中国語日本語変換を使いました。（ここからずっとストア側は中国語で連絡してきます。）できれば英語がいいのですが！！

なので、１個だけ開封して、写真で商品が32Uである事
が分かるように送りました。

すると次の日、 商品は使ったか？ の質問？？また、 ストアの従業の粗忽（そこつ：軽率で不注意なこと）で申し訳ない云々 の良心的な回答がきました。

こちらとしては、まずは、 写真を取るために空けたけど、使ってない との回答です。それと、あくまでも 全交換の意思 ですが、 4台分のＷiFiアンテナを送ってくれるならと譲歩 の連絡付きでメッセージしました。誠意ある回答を待ちます。です。

すると次の様な回答がきました。

注文書発注があれば、ストアはアンテナを添えて与える事ができます。

誠意ある回答ですが、わたしからは次の様に回答しました。

第1の方法は交換です。第2は無償で4台分の2.4GHzのアンテナを無償で送ることです。なぜなら全てそちらのストアの過失（間違い）だからです。

すると次の回答がきました。

こちらは何とか発送します。

　

おそらく、第2のアンテナ送付の意味のような感じかと！

私からは、まず、交換を優先に、メッセージを返しました。

どのようにストアが送るかとか考えるのは責任です。手元の32Uを32Dの送付を考慮するのも責任でしょう。

すると次の様な回答がきました。

次の様な回答がきました。

こちら（ストア側）の言っている意味は、あなたが発注書を提供できれば、こちらはアンテナを与えます。

私としては支払いの点でわからない状態なので、次の様に質問をしました。

私が2.4GHzの無線アンテナをSAMIORE Storeにした場合の価格の支払は必要ないですか？

ついでに、間違いのないように

支払いはしません。

と送りました。

少し日にちが過ぎたので、こちらから意思表示をストアへ再度メッセージしました。

親愛なるSAMIORE Store商店さん２つの内のどちらかに決めて下さい。１つは32Uとこちらの注文32Dとの全(4pcs)交換、他は32Uに接続する2.4GHzのＷiFiアンテナを私に送ることです。

するとストアから次の回答がきました。

どちらがお望み（必要）ですか？

単一のそれを注文して下さい。発注書発行処理が必要で、こちらは価格を修正することができます。

ＷiFiアンテナの画像を2枚送ったので、どちらが必要かを聞かれた様です。

注文をすれば良いような回答です。

まずは対応するWiFiアンテナを同じストア内で検索で探しました。３種類程見つかりましたので、そのうちの１つを購入処理での発注のみが出来るか確認してみています。この確認のため、事前に安いブレッドボードと電源とワイヤーのセットを試しに購入処理で確認してみていました。

私のはクレジットカードですが、購入のシステムでは、発注書のみの処理はできない様です。必ず支払い処理が入りました。

上記の内容をメセージでストアへ連絡です。発注のみの対応ができないので、 イメージ写真では注文だめか も質問しました。数枚のストアの商品のアンテナの写真も送付しています。

すると次の回答がストアからきました。

まず、こちらの順序を知って下さい。発注書の必要な商品の支払いのページでいずれの支払い方法も支払わない発注書の記録を残してウェブサイトをとじて下さい。

のような意味かと思います。

Ｗeblio訳ではよくわかりませんでした。（機械翻訳では次の様に全くわからない訳でした。）

「まず、私の順序を知ってください、発注書のこの製品は、それに支払いのページを弾き出して、ウェブサイトを閉じて、いずれの暗号支払わない発注書を残してこのようなかを入れてはいけなく」

こちらでも試した事と質問と一緒に連絡しました。

私の支払いはデビットカードです。

なので、そちらの方法は使えません。ボタンを押して注文ボタンで購入するとお金が支払われます。

他の方法はありませんか？

この支払われる方法を使う場合、支払ったお金は戻すことができますか？

ストアからは次の回答です。

カードを削除してみて下さい。

私からは実際にカードを一端情報全部削除して注文ボタン（購入）を押してどうなるか試してみた事を連絡です。

新しいカード追加か、PAYPALかの要求があります。

支払いなしには注文はできません。

ここで、ウェブ検索をして注文だけする方法の情報を探してみました。 ネットで支払いをせずに注文する方法 というウェブページが、とてもヒントになりました。

AliExpress『支払いせずに注文する方法』未払い状態を作る価格調整のやり方

この中の方法の一つを行なってみました。クレジットカードの情報を間違えて行う方法です。

クレジットカード番号は間違えても、必ず聞かれるので、ここは正しく入力しないといけませんでした。

期限の月情報を間違えて入力処理することで、注文（購入処理）ができました。何回か間違えると使えなくなる情報もありましたので、注意して行ないました。

わたしが調べた方法で注文できたので、その連絡をしました。

支払い待ちの注文ができました。カードへの入力で間違えた期間情報を入力しただけです。

ID番号のオーダー品を支払い金無しで送ることができますか？

支払いを行なって下さいのメッセージがでますが、ショップで金額修正処理を行なうまでは、そのままです。

上記でのUS４.22＄の価格がストアの金額修正されるのを待ちます。

ストアからの連絡が来ました。

機械翻訳だと次のとおりです。なんとなくわかるかな程度ですね。

$の0.01すでに金額を修正して発注書を支払ってやっと私を発送することができてなることがただある

こちらで金額を＄0.01に修正したので、支払いがあれば発送します。

の意味だと思います。

即、クレジットを正しく入力し直して、支払いを行ないました。

このストアはとても対応が良いと思います。

2013年11月にネットショップを始めているので、ネット商売の実績もあるのでしょうね。対応が誠実です。ただ、実際に物を扱って働いている人の質に問題があるのではないかと思います。オーダー品を間違えて梱包するんですからね。ただ形状が似ている商品であったことも確かにありますが！

9月24日注文で10月3日商品到着なので、今の時期にしては9日で届いたのでとても早い方と思います。

後は10月14日に支払ったので、同じ9日で届くとすると10月23日頃かと思いたいところですが、お買い上げ金額が￥750以上の場合で明日15日発送です。￥750以下の商品では12月16日に発送予定の様です。少し掛かりそうです。例の送付コンテナが満杯になるまで、待たされるわけです。

アンテナが届くまで32UはWiFiで使えません。手持ちのESP32DivKitCが少しあるので、気長に待ちます。

つづく？

一連のスマフォUDP通信でのリモコンもどき制御と、Logger32モード時の動作確認も上手くいき、今まで動作確認を続けてきていますが、特に問題となるような動作も無く、ほぼケースに組んでも良いレベルになった気がします。ここまでたどり着くまでは、単に今までは動作させるために、新たにインターフェースを追加したりといった気の赴くままの対策を講じていった結果、うまく動作しているので良いと考える節もありますが、よくよくあらためて考えてみると少しパーツが増えている、いわゆる冗長な状態のインターフェースになってしまっています。一番最初の頃のRS232Ｃインターフェース構成はArvelの232Cインタフェース＋レベル変換IC回路追加でESP32DevKitCのシリアルポートRX，TXに接続していました。専用ICなので使用するコンデンサの数が少し多く、追加回路として実際に使用を考えるとテストでは良いのですが、実装（パターンにいれる）するには不向きでした。その後は、Arvelの232Cインタフェースとレベル変換回路とを1つのインタフェースで対応できるという秋月電子の超安いAE-FT234XDを使いました。

（このAE-FT234XDをTS820SのDDS+VFOからのシリアル通信用インタフェースとしてPCに繋ぎＷindow10でのハムログでの周波数読み取りで問題なく使用しています。）

わたしのテストする環境が古いＷindows（ＸＰ）を使うという確認方法が悪いのが原因なのですが、古いPCでは、これが曲者で、デバイスドライバーが機能したりしなかったりと言うことがあり古いWindowsPCでも新しいWindowsPCでも安定に動作する様に新たに、Arvelの232Cインターフェースと9pのソケット付きのレベル変換回路での構成に変えました。コレはPCとの接続はArvel+レベル変換回路を通してESP32DevKitCのシリアルRX、ＴＸポートに繋がるのですがPCとESP32DevKitC間には2つのデバイスが存在している状態です。

なのでシンプルなAE-FT234XDより安定に動作してくれるレベル変換機能のあるRS232Cインタフェースがないかと（安いのが条件です。Hi！）ヤフオクを見ていたら、目的に対応する232Cインタフェースが安い価格で出品されていました。使用方法は、無線機FT-857のシリアル通信用関連で使用していたようです。早速オークション参戦です。このようなインタフェースを使う人は限られているせいかあまり参戦者が多くなく、超破格値で落札出来ました。新品で今も販売はありますが1K以上はする様です。

ESP32DevKitCに接続で使用する線種はFTDI232のピンは6本ありますがその内の

2：RX、3：TX、4：VCC、6：GND　の4本を使います。

ピンを手前にして上から見てのピンの割り当て名（設定ピン）

1：DTR

2：RX

3：TX

4：VCC

5：CTS

6：GND

今までの変換回路に繫いだESP側よりの４本の線はそのままFTDI232の

上記4本に接続して使用します。レベル電圧も5Ｖと3.3VがPINコネクタで

選択設定出来るので、ESP32DevKitCのI/Oレベルに合わせ3.3Vに設定して

使います。

早速、実際に今までのインタフェースと交換して動作も確認してみました。

プラグアンドプレイ的に動作してくれました。FTDIのデバイスドライバーは以前のAE-FT234XDを使用の際にデバイスドライバーをFTDIのデバイスドライバのWEBページよりインストールして使用していましたので、その時に関連するデバイスドライバーがインストールされていたんだと思います。Hi！

今後は、テストで使うWindowsは、セキュリティの関係上,Wndows10でのテストにてしていこうと思います。(あまりにも古いＷindowsで確認しても実際に使われる環境ではないし、また実際的でない事より）

仕上げのケースはWiFiのUDP通信を使うのでシールド効果のないプラスチック製にしよう！と決めてはいます。他組込用パーツの設置方法を考えたりするのですが、SW類はどのタイプのSWを使ったら良いかとか、TFT液晶の窓はどのようにしたら良いのかとか、少し迷っていいます。

いま、１つ大事な事を確認していない事があるのに気づきました。基板上の電源回路です。今はESP32DevKitCへの電源供給はUSB端子からコンパイル書き込み含めPCから供給なっていますが、実際はコンパイルして書き込み後はこのESP32DevKitCのUSBは外して使うことになります。なのでUSB以外の５Vの電源を供給する必要があります。この外部供給用の５V用のレギュレータ回路はパターンに組んであるので、その入力側の8Vから12Vぐらいの電圧のDCアダプターを繫いで,動作確認をしなければなりません。

明日は、朝から忙しいので、午後にDCアダプターを探して繫いで確認してみたいと思います。

つづく？

エモトのローテーター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の動作説明 ----------------------------------------------------------------------------------------------

”Ｌ”時（スマフォ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の動作は、この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の動作がかなり遅い状態なので、これも少し原因を確認したいと思っています。

つづく？