先日仕入れてきた2SK2880ですが、ストレートラジオに使うには今ひとつ使いにくい石でした。まあ、元々利得を稼ぐ用途に向けられた石ではないようなので、使いにくいのではなく、使い方が悪い、というべきでしょう。

 

ということでこの石の使い道を考えていたのですが低周波アンプとかはやらないので、やはりラジオ・通信機分野(いわゆるRF)から探さなくてはなりません。

 

ストレートラジオがダメなら必然的にスーパーヘテロダイン一択です。

 

問題はスーパーを作るにあたって充分な測定器類が手元にないことです。最低限SSGは欲しいところなのですが、周波数カウンタとテスターしかありません。

 

回路について

 

試作1号機の回路を示します(図1)。取り敢えず動作するレベルで、定数の追い込みはこれからです。とはいえ、触るところはいくらも有りませんが。

 

図1 試作機の回路

 

構成はソース接地・ソース注入の他励式ミキサー、IFアンプは1段のみ、復調はFETによるアクティブ検波です。

 

ミキサー

他励式にしたのは使い慣れているのと、FETで自励式を構成しようとして既成品のOSCコイルやIFTが使えなかった場合、それらをイチから作らなくてはならないからです。要するに楽をしたかったから、に他なりません。

ゲートのCRは無くても動作しますが、FETの入力容量がそのまま同調回路の負荷になると思います。

 

中間周波増幅

とりあえず1段のみにしました。多段にして発振等のトラブルが生じた場合、その対策が大変なためです。今まで多段アンプはMOSFETばかり使っていて、そちらは流石に高周波デバイスなのでトラブったことはありませんが、接合型FETは個人的に未知数です。
AGCはかけていません。以前、Sメーター付きのラジオで各局のSを見た時、私の部屋ではTBSとニッポン放送とで実に37dBもの差がありました。この差を増幅度の変更で何とかするにはどう考えても2段以上に掛けなくてはなりません。

また、当初図2のようにIFTの同調側はドレインに接続していました。何故か音が出なかったのでゲート側に変更したのですが、ひょっとしたら配線不良があったのかも知れません。どちらでも何とかなりそうな気はします。

 

検波

先日作ったストレートラジオ(再生検波)で回路定数(といっても負荷及びバイアス用の抵抗だけ)を得ていますので、そのまま流用しました。なので、ここだけFETは2SK2881Dを使っています。なお、今回は前述の理由でAGCを見送りましたが、必要であればここのソース電圧が使えると思います。

 

図2 回路(初期段階)

 

 

組み立て及び調整方法

 

1)
まず、局発のみを組み立てて実際に発振するかどうか確認しました。FETとトランジスタでは動作に違いがありますし、FETの入力容量の影響で必要なスパンが得られない可能性もありました。
案の定、中波全域をカバーするだけのスパンは得られませんでしたがNHK第一(JOAK)からRFラジオ日本は収まりましたので、私のQTHなら実用範囲内です。
取り出しはOSCコイルの2次側を使いました。当初ゲートやソースから出そうとしたのですが、周波数ずれが大きくて断念しました。出力レベルが気になりますが、ミキサーがソース入力なのでそれほど振幅は要求されないはずです。

 

写真1 局発の単体テストの様子

 

2)
全体の回路を組み立てて、動作電流をチェックします。大体7〜8mAに収まるはずです。IDSSのランクが同じでこの数値から大きく外れる場合は、配線ミスか異常発振の可能性があります。

 

3)
ミキサーのソースに周波数カウンタを接続し、発振周波数をモニタします。VCを回して必要なスパンが得られるようにOSCコイルとVCのトリマーを調整します。一度調整したら動かさないようにします。

 

4)
SSGが無いので、とりあえずNHK第1(JOAK,594kHz)を受信し、局発を1049kHz(594+455kHz)になるようにVCをセットし、IFTを回して音量が最大になるように調整します。

 

5)次にトラッキング調整ですが、SSGがないので放送を受けながら低い方はアンテナコイルをずらして、高い方はバリコンのトリマーを回してそれぞれうまく受信できるまで調整していきます。が、バーアンテナとVCがミスマッチなのと、このようなバラック実験では浮遊容量が大きく、まったく調整できませんでした。後日、アンテナコイルを変更して、ちゃんとした基板に組み直してやり直しです。

 

 

どうなるかちょっと不安だったのですが、簡易型とはいえ選択度はスーパーのそれであり、感度についても聴感上アンプ1段分音が大きくなったのは実感できました(つくづくSSGが無いのが悔やまれる)から、実用性はあると思います。ブレッドボードによるバラック実験にも関わらず異常発振がなかったのは意外でした。

 

写真2 実験の様子。実に危うい。ブレボで調整しやすいようにシャーシをひっくり返したのだが、VCが裏に回ったのでトラッキング調整で泣く。

自分宛てメモ

 

LPC11U35_401 はサポート外 Orz

自分宛てメモ

 

LinuxMint17のリポにあるmercurialは旧いので、新しいものを貰ってきて手動でインストールする。

 

しかし。

 

python-docutilsが旧いせいか、make all の最後の方(ドキュメント生成時)にエラーとなる。
で、docutilsも貰ってきてLinuxMint17で用意されている方をアンインストールしてから入れなおす。

 

結果は変わらない。

 

base_path=os.getcwdu() で、どうも文字コードの解釈からみでエラーになっているようだ。これを base_path=os.getcwd() に変えてみると、この箇所でのエラーは消えるがさらに後段でエラーになってしまう。

 

mercurialそのものはできているようで、make install もドキュメントインストール直前までは動作する。

 

取り敢えず、この状態で使ってみる。まあ、mercurialなんざ使うことないとは思うのだが。

 

手順はこちら。
https://os.mbed.com/users/MACRUM/notebook/mbed-offline-development/

 

pipが旧くて先に進まない!
pipの更新方法
https://pip.pypa.io/en/stable/installing/

 

gcc-arm-non-eabiの入手先
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update
LinuxMint17(Ubuntu trasty)にも用意されているが4.8なので。バイナリを貰ってきて適当なディレクトリに設置してパスを通しておく。

 

とりあえずコンパイルドライバ
mbed compile -m K64F -t GCC_ARM

バイナリは project_dir/BUILD/K64F/GCC_ARM/ に得られる。

まだボードに転送していないので、作成されたバイナリが実際に動作するかどうかは未確認。

 

寝る。

 

自分宛てメモ

 

feedをチェックし忘れていて、さっき見つけた。

 

引用元

http://mag.switch-science.com/2017/09/26/esp-wroom-02-flash-rom/

 

気がついたらROMが2MBだった、形式変更とか変更が判るような表示もなかった、とか。

本来2MBで設計されていて4MB版は2MBのオマケ付、だったのだろうか。

 

 

酒の肴、ではなくて。

 

ラジオを作っていて一番最後に問題になるのがツマミ(ダイヤルノブ)をどうするか、ということ。

 

昔(30年以上前)は種類が多く、パーツ店で選ぶのに目移りして困るくらいでしたが最近はそうでもないようです。

昔からあるのが、写真1のようなつや消しブラックのツマミ。径の大きいもの(30Φ以上)は余り見かけなくなりました。あるところにはあるのでしょうが。

写真1 左から24Φ,20Φ,15Φ (ツバの部分を定規で実測)

 

写真2はそれを裏返したところ。6Φ軸のシャフトにイモネジで固定するようになっているものが多いのですが、中には真ん中の製品のようにローレット仕上軸用のものもあります。これが非常に固くて、どのくらい固いかというと、深く差し込んだら再び取り外すことは困難ではなかろうかと思える、そのくらいです。

写真2

 

 

さて。


問題の根本はツマミよりも、それを取り付けるシャフトにあります。

 

写真3は手持ちのVRです。左端はアルプスの16Φの標準品。真ん中と右は秋葉原のパーツ店でよく見かけるタイプです。どこの店でも置いてあるので、大量に(そしておそらくは安価に)出回っているものと思います。

写真3 VR各種。右端はS付。

 

 

VRとしての使い勝手は問題ないのですが(但し耐久性は不明)、惜しむらくはそのシャフト。絶望的に短いのですね。

 

ケースに直接取り付けてそのまま操作パネルとする方法であれば、この長さでも上述のツマミを取り付けるには何ら困ることはありません。しかし、セットにシャーシ構造を取り入れてケースと別々にする場合、すなわち昔のテレビやラジオでよく見られた構造ですが、シャーシとツマミの間にケースの正面パネルが1枚以上挟まる形になります。この分だけシャフトの長さが食われてしまうのですね。写真3のVRでは24Φのツマミはぐらついて使えません。20φはイモネジの位置が僅かにツバ側に寄っているので、ギリギリ使えます。S付VRのシャフトは短すぎ、どのツマミもダメです。とはいえ、ツマミなしではいられないので無理やり付けていますが、雑に扱うと簡単に脱落してうまくありません。

 

ということで、21世紀の今日、実用的なセットに仕上げようとするとVRを特注しなくてはならない(果たして受けてくれる工場が国内にあるのか?)のですが、そんな贅沢はなかなか出来ません。

 

困ったもんですが、意外なところに解決策がありました。

 

それは、前述のローレット仕上軸用のツマミの存在です。最後まできっちり差し込むと抜けなくなりそう、と書きましたが、逆にいうと僅かに押し込んだ位置で充分に固定されて実用になるのですね。まさかこれが本来の使用方法という訳ではないでしょうが、新たな発見ではありました。


もっとも、径のバリエーションが余り無さそうなのと、大きい径のものは差し込み口が奥へ後退している可能性があるので、状況を選ぶのは変わらないでしょう。

 

 

この夏、調子に乗って3台も製作したwifi接続の温度計のその後。

 

消費電力について

連続使用はEneloopを使って1週間弱で相変わらず。流石に電池交換が煩わしくなってきたので、計測間隔を毎分から3分毎に変更しました。これで半月以上は持つはずです。

 

 

1号機のバグ

先行試作機ということもあってプログラムが微妙に異なっていた(初期プログラムに2号機・3号機での成果をバックポートした)のですが、これが原因で報告漏れが多発するバグが生じていました。

 

改修前
wifi.eventmon.register(wifi.eventmon.STA_GOT_IP, function(t)
    sntp.sync( sntp_server, function(sec, usec, server, info)
            sntp_flag=true
        end,
        nil,
        1 )
    tm:start()
    conn = net.createConnection()
end)

 

改修後
wifi.eventmon.register(wifi.eventmon.STA_GOT_IP, function(t)
    sntp.sync( sntp_server, function(sec, usec, server, info)
            sntp_flag=true
        end,
        nil,
        1 )
    conn = net.createConnection()
    tm:start()
end)

 

tm は報告時刻合わせ用のタイマーで、励起後最初の「00秒」で自身を止めてサーバー報告ルーチンを起動します。
connはその報告ルーチンで使うものです。

 

tm:start()でタイマーを先にスタートしてしまうと、connの取得が間に合わないことがあり送信に失敗していたようです。毎度、間に合わなければこれが原因とすぐに判明したのですが、ほとんどランダムに発生するので気づくのが遅れました。
tm 側では数秒間「00秒」を待っているのですが、

 

  1. wifiへの接続に手間取って上記コードが励起されるのが遅れてしまい、
  2. tmでの「00秒」への到達待ち時間が短くなり、
  3. connの取得がなされないままサーバー報告ルーチンが起動してしまう

 

大体こんな感じだと思います。

wifiルーターの処理能力にもよりますが、計測ノードが多数の場合、報告タイミングをグループ分けしてずらす等してルーターの負荷を分散する工夫が必要かも知れません。

 

 

計測の様子

グラフは点描のままです。

 

湿度

窓を開閉した際の変動が記録されている。

 

 

気温

 

 

気圧


Search

Calendar

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
293031    
<< October 2017 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

無料ブログ作成サービス JUGEM