mchf スプリアス測定

変更申請を行うために、新スプリアスの規定を満たすようにする必要があり、近接スプリアスの測定と高調波の測定を試しにしてみました。近接のスプリアスとしては、IQ合成のバランスとりが悪いと24kHz離れたところに出てくるピークと、キャリア漏れの12kHzのところのが問題になりえると思います。IQ合成についてはmchfのメニューで調整できますので、それを一通り行い、キャリア漏れはミキサーのグラウンドインピーダンスを下げるとか、バランス改善のメニューだとかいろいろな方が提案されている方法をこれから試そうとしているのですが、まず現状を把握する意味で、現状を練習兼ねて測ってみました。

測定は、RIGOL DSA815に40dBのアッテネーターを通して行いました。記録はPCにLANでスペアナを接続し、RigolBildschirmkopieというキャプチャソフトで取りました。免許は最終的には3.5, 3.8, 7, 14, 21, 28が出られるようにしたいと思っているので、これらのバンドで測定します。SSBモードでキャリアをフルパワーで出して計測を行いました。

キャリア漏れなどのピークについては、RBWを1kHzの設定で、基本波の高調波に関してはRBWを100kHzにして100MHzまで測定してみましたが、測定方法が正しいか自信なし。1GHzまで測らないといけないと思いますし、CWその他のモードでも測らないといけないのかな。わーめんどくさい(保証認定を取るのであれば、一応全部測ったうえで、資料の提出は一部?でしょうかね。)

まず3.5MHz

スプリアス規定は、アマチュアについては、5W以上の送信機については、基本波30MHz以下 はスプリアス領域で50mW以下かつPEP-50dBですが、微妙にクリアしていません。(SSB帯域が3kHzとすると、2.5倍で7.5kHzなので、これらのピークはスプリアス領域ということになるのかな)

7MHz

14MHzも同様

21MHzは厳しそう。

28MHzは惜しくもNG?こちらはIQのバランスがちょっといまいち。

次に高調波を見ます。

3.5MHz OK

7MHzもOK.

14MHzではなぜか83.84MHzに謎のピークが出てきた。CPUのクロックが漏れてる?

21MHzはLPFを別にしないと全然だめですね。謎83.85MHzはレベルがかなり高くなってるし。高調波は-50dBcを満たせばよいのか-60dBcなのか、規定をいまいちよく理解できてない。

28MHzでは、また例の83.85MHzがLPFのカットオフが高いせいでさらに目立つ内容。これはちょっと対策しないと不要輻射-60dBの基準は満たせない。高調波は大丈夫なのに。。。

ということで、いろいろと気が付いたのはよかったですが、道は遠そう。。。

mchf 四苦八苦(mixer, PA周り)

相変わらず作っていますが、一進一退という感じです。

まず、ケースに収めてみたところ、LCDは収まっているものの、ボタンの高さが高すぎて、ケースについてきたゴムボタンだと蓋を締めたら全部ボタンを押されちゃう、みたいな感じで、先達に従って、5mm高のタクトスイッチに取り換えることにして調達中。

で、その間、近接スプリアスを見直そうということで、キャリアから約12kHz離れたところのピークを下げたい、で、mixer の出力をスペアナで見てみたら、mixerの出力ですでにスプリアスが乗っていることがわかりましたので、これまた先達のを拝見しまして、mixer のDCバランスを変えて様子を見てみました。具体的には、

こちらの、R70を1kohm 程度まで小さくして、直列に1k程度の半固定抵抗を入れて様子を見てみました。そうすると、あまりここを変えても改善しませんので、何を変えると、ミキサーのバランスを変えられるのかな、と悩んでいるところです。また、バランス点(トランスの中点電位)は、回路上で設定されている2.5Vあたりではなく、3V程度のところが最良(でも数dB程度もよくなりません)でした。これはミキサーICのデータシートを読んでみたりもしたのですが、ここは、デジタルICの出力とのマッチングでもあるので、なぜかまではよくわかっていません。ここは、AC的には半端な状況でもあるので、小さな容量のコンデンサをGNDとの間に入れたりもして一定効果はあったんですが、理屈がしっかりわかっていませんので、もう少し考えてみようと思っています。最初はI2CのDACでDCレベルをバンド毎調整できるようにしようと思って、DACも調達してあるんですが、無理やりセットするのは、改善も乏しくあまり本質的でないなという感じです。

そんなこんなで、いじくっていたら、PAの出力が半分ぐらいしか出なくなってしまい、「ファイナル飛んだ?」と思ってファイナルを取り換えてみようと、ファイナルを基板から外したところ、基板のランドが剥がれたりして、やべー、という感じになってしまいました。

無理やりジャンパーを張ったりして、ファイナルを無事?取り付けてテストすると、さらに出力が出なくなってしまい、さらにやべーという感じ。そんな感じでこれは地獄の入口かな?と思ったので、少し落ち着いて、回路がちゃんとできていないんじゃないかな?と調べてみると、まず、PAのファイナルのグリッドへのDCバイアス(R81,R82)とRF入力(C99,C100経由)が基板の表・裏から別々につながるように基板がなっているということに気が付き、一方ジャンパーではRFの方を繋げていなかったため、こちらは、修正しました。

無理やりなおして、バラックテストのために、3mm厚アルミ板を使って組んだところ。

ところが、テストしてみると相変わらず、パワーが十分に出ない。ということで、やっぱりこれは信号をたどっていかないといけないね。と、まず、ファイナル2個それぞれのグリッド電圧を観測すると、両方ともバイアス電圧はかかっていますが、片方だけRFが乗っていない。というわけで、その上流を見ると、片方のドライバー(Q4)のコレクターにVCCがかかっていない、あれれということで、調べると、RFC6が断線しているようでした。こちらは、メガネコアを使ったものに取り換えている方がおられるので、それを真似しようと思ったけど、手持ちがないので、手持ちのRFCでとりあえず、まだ断線していないRFC5を含めて取り換えておこう、と思っているところです。

around faulty RFC6

なかなか完成まで行きませんねー。でもゆっくりでも完成させたいと思って進めています。

今晩、ジャンク箱漁って、手持ちの47uH(間違い、測りなおしたら0.47uHでした)のRFCをつけてみたんですが、14MHz以上はよくなってパワーが出まくりましたが、3.5MHz, 7MHz が正しくチョークとして働いてないようで、NG(オシロ見るとコレクタ電圧の波形がめちゃめちゃ)。

2/6 このあと、12V電源を繋いだら、送信もしていないのに、大電流がFETに流れちゃうという謎なことが起こり、RFCを変えたタイミングでそれが起こったこともあり、原因がわからず困っていたんですが、ファイナルのグリッドに入っている抵抗のリード(というかSMDのメッキ)が断線していたために、グリッドにバイアスがかかっていなかったためと判明。これを直し、RFCもサトー電気で買ったメガネコアに6T程度巻いたものに置き換えてテストして良好となりました。メガネコアに6Tは多分巻きすぎだと思いますが。。。

RFCを変えた後はファイナルのドライブ条件が改善したのか、スプリアスも減った感じです。

これでようやっとミキサーのキャリア漏れの対策にかかれます。。。

mchf RX/TX 切替回路改造

相変わらず、ゆっくりとではありますがmchfを作っているところです。

今日は、mchfの送受信切り替えの改造を行いました。original の回路ではPINダイオードでスイッチングしているのですが、送信波でダイオードがスイッチングしてしまい、スプリアスの原因になっているとのことで、実際スペアナで見てみると(最近安い中華のスペアナRIGOL DSA815-TGを買いました)近接スプリアスが見えているため、そこを何とかする必要があります。先達は、リレーでの切り替えに改造するということをやっておられるようで、official UHSDRのページでもその改造(RF-04/05/06-H-029)について書かれていますが、別の改造法が、別のところで述べられており、私はこちらを実装することにしました。

部品は、手持ちの関係で、リレーは、OMRON G6K-2F (高周波用ではありません)を、トランジスタは、2SA1015GR, ベースに入れる抵抗は9.1k、coaxはRG178B/Uと異なっていますが、それ以外はほぼ同じ内容を実装してみました。

こんな感じで小汚く実装しました。あと裏側のPAのトランスの近所で、LPF入力とPA出力を切り離すパターンカットがあります。

これをやると、UIボードとRFボードの間に入れている鉄板と干渉するので、鉄板に穴あけをしないといけないのですが、それやるとシールドが甘くなりそうでどうしたものか(穴あけしちゃいますが)と思っているところ。

改造後、送信スペクトラムを見ると、近接スペクトルがクリーンになっているような気がしますが、まだちゃんと記録を取っていませんので、LPFのまき直しもやった後でスペクトルデータどりをやろうと思います(保証認定取る作業のため)。

保証認定はといえば、mchfのファームウェアも改造して、JAのバンド(1.8~28M)全部定義してみたんですが、考えたら、LPFが4つしかないので、今の回路構成では4バンド+αぐらいしかスプリアスを満足できないと思われますので、スプリアスを満足するバンドだけ送信できるファームを作成(3.5, 7, 14, 21?, 28)するようにすると思います。ハイバンドのLPFを作り直して21MHz帯をOKにして、28MHz バンドは50MHzのトランスバーター用にPAをバイパスする設定にしようかなとか思っているところです。

mchf LPFの調整(2)

この間LPFのコイルの定数をNanoVNAで測ったら全くあってなかったという件で、トロイダルコアの巻き数に対するインダクタンスがかなり違っていて意味がわからず困っていたんですが、トロイダルコアって、巻き方でかなりインダクタンス変わるんですね。トロイダルコアってトロイドにほとんどの磁束が集まっているから巻き数でインダクタンスが完全に決まっちゃうんだと思ってたけど、気のせいらしい。

なので、設計通りとするには、トロイドに均等に巻き線をする必要があるようで、均等に直して定数を測ると1T程度巻き戻す程度でよいようでした。

ということで、ハイバンド用のはめんどくさいのでとりあえずそのまま、ですが、4つあるうちの14MHzバンドに関係したLPFは、均等巻きにしたうえで、定数を測って設計値に近い内容(L19 13T 0.78uH L23,L15 11T 0.6uH) にして組みなおしてみました。

で、他のLPFも含め一度特性を計測してみた。

LPF #1 (80m) cutoff 4.24M -6dB 5.08M roll off 52.7dB/oct

LPF #2 (40m) cutoff 7.04M -6dB 8.72M roll off 60dB/oct

微妙に通過帯域が荒れてる。

LPF #3 (20/30m) cutoff 17.8M -6dB 19.0M roll off 62.2dB/oct

LPF #4 (15/17/12/10m) cutoff 34M -6dB 36.4M roll off 56.3dB/oct

roll off 特性にはやはりトロイダルコイルの巻き方が関係しているっぽい。あとでまたやり直すかも。

tinySAつかって高調波の強度を見てみました。

3.5MHzはぎりぎり?

7MHzはまあOKかな。

14MHzもOK

21MHzは全然ダメ。

28MHzはまあ、OKそう。

ということで、方針としては、4つLPFバンクがあるので、欲張らず、3.5, 7, 14, 21でスプリアスを満たすようにする、かな。21がなあ。。。もう少しhigh band のLPFは28MHzぎりぎりぐらいに持ってくるのかな。。。その他のバンドはとりあえずあきらめよう。

あとは近接スプリアス。これがあまり良くなかった。tinySAはまだ慣れていないので、もう少しよく見てみようと思っているところ。

mchf firmware compilation

今mchfのボードに書き込まれているバイナリのファームウェアは5MHzバンドが送信出来たり当然免許おろせませんので、こちらの方も対策を、というか日本版のファームウェアをコンパイルできるように準備を始めました。前に作ったような気がしたコンパイル環境は3年も経って当然のように見つからないのでgitのUHSDRのページを見て、試行錯誤。最初、STM32の開発をWindows上のsystem workbench for stm32でやっている関係で、こちらのEclipseにprojectをimport すればOK?と思って、やってみたんですが、コンパイル環境が正しくセットされず、うまくいかなかったため、Ubuntu 20.04 の環境にmake でコンパイルする環境をセットすることにしました。ので、備忘録。

arm のコンパイラー等はこちらには入っていなかったので、

sudo apt-get install gcc-arm-linux-gnueabihf
sudo apt-get install gcc-arm-none-eabi
sudo apt-get install git
git clone https://github.com/df8oe/UHSDR.git
cd UHSDR/mchf-eclipse
make all

したところ、一応コンパイル通ったので良いかと思います。fw-mchf.binというのがなんかできているから、これを書けば多分動くんだと思う(default でmchfの設定になっているはず)。

あとは、こちらに従って、ソース書き換えてビルドすればいいや。ぐらいに思っていますが、一応対応個所をソースで確認。

drivers/ui/ui_driver.c

src/uhsdr_version.h

hardware/uhsdr_board.h こちらはだいぶ変わってしまってる。ので、for i in find . -name '*.h'; do echo $i; grep BAND $i; done|less などでしらみつぶしに調べる。

drivers/ui/ui_configuration.hとか、drivers/ui/radio_management.hとか,drivers/ui/radio_management.c, drivers/ui/menu/ui_menu.c を調べると、BAND_MODE_60 とかあるので、この辺をいじくればいいのかな。

多分、radio_management.cで60m など、BandInfoを定義していてそこでは、receive only やバンドの周波数を書くようになっていて、また、そのあと、bandInfo_combined[]に定義するバンドのまとめを作るようになっているので、この辺で変更すれば、きっとregion3 のバンド構成にできるんでしょう。多分。60m バンドに関しては、bi_60m_rxというのがあるからこれを使えばいいに違いない。bandInfo_regions3_thaiというのが定義されていて、なぜタイだけ?と思う。

… あたりまで、ソースを眺めて、OKということに。

あとは、EEPROMやっぱりつけとこうかな、などと思う。