luaの実行環境でcairoグラフィックスを実行する際の自分宛てメモ

 

バックグラウンドで更新ルーチンを走らせておいて、メインのluaからは実際のウィジェット(グラフィクスが表示されるトップレベルウィンドウ)更新は管理しない、という仕掛けを作る。

 

ウィジェットのコンストラクタで次のように更新ルーチンをセットする。
g_timeout_add(33, (GSourceFunc)timer_test, cv);


一応(不確実ではあるが)33ミリ秒毎にtimer_testが呼び出される。
ここでタイミングを1000ミリ秒とかにすると、空き時間にluaが全力疾走するのでCPU負荷は上がる(※)。1ミリ秒とかにするとバックグラウンド側の処理が頻発するのでluaの実行は適当に間引かれる(はず)。いっぽう、バックグラウンド側の処理そのものは軽いせいか、全体でのCPU負荷は軽くなる。プログラム全体の動作としては当然遅くなる。
33ミリ秒というのは意外と長いようで、lua側の表示ルーチンだと更新される前に描画が複数回実行されてしまいチラつきが生じる場合が多い。(特にcls()を実行してから全域を書き直している場合)
 

以下はウィジェット更新をセットする関数。なお、ウィジェットが破壊(実行中、手動で閉じた。あるいは実行後luaのガベコレに回収された)される際、cv->windowはNULLされるようにしてある。
static gboolean timer_test(Luacanvas *cv)
{
    gint x, y;
    if (cv->window == NULL ) {
        return FALSE;
    }
    gtk_widget_get_size_request(cv->window, &x, &y);
    gtk_widget_queue_draw_area(cv->window, 0, 0, x, y);
    return TRUE;
}

 

 

次の関数はexpose_eventのコールバック関数から呼び出される。コールバック関数に直接書かなかったのは、当初更新を手動で行っていた時の名残り。
timer_testが動いている限り、ウィンドウが隠れていても呼び出される。
static void _show_update(Luacanvas *cv)
{
    cairo_t     *cr;
    //
    // このルーチンはウィンドウが生きている限り、timerで間接的に呼び出される
    //
    cr = gdk_cairo_create(cv->drawing_area->window);
    cairo_set_source_surface(cr, cv->surface, 0.0, 0.0);
    cairo_paint(cr);
    cairo_destroy(cr);
}

 

 

---

更新間隔内に描画処理を完結させ(終わらない場合は一旦止めて)更新完了を待って再開すべきと思うが、lua側とのタイミングのやりとりをどうするか。

 

 

※luaそのものは1スレッド分(core2duoだと1コア分)しか消費しないようだが、cairoのstorkeを繰り返し実行するとCPU負荷が跳ね上がる。負荷が上がるだけでOS上の他のタスクの切り替えは正常なので、デスクトップが重くなるような事はほとんど感じない。

 

40mBダイレクトコンバージョン受信機の続き。

 

復調ミキサの動作が適切でない(局発のレベル不足)ためか、あるいはアンテナが非平衡タイプだからなのか、復調音にかなり大きめな「ザー」という雑音が入ります。
アンテナを外せば全くと行っていい程音は出ませんのでアンテナが拾ってくる雑音だとは思うのですが、何にせよバンドをワッチしていて邪魔なことには変わりありません。

 

そこで対策としてAFフィルタを入れてみることにしました。これも凝りだすとキリがないので、取り敢えず高域の「ザー」を取り除くことのみを目標にします。

 

当たり前にLPFを組んだのでは取り除けないと思い、BEF(バンドエリミネーションフィルタ、ノッチフィルタとも)を加味したものを組んでみることにしました。

とはいえ、オペアンプ回路については子供の頃2,3回やった覚えがある位でほとんど全くと言っていい程やってこなかったので、今回は安直に参考文献1,2,3にある回路をコピペして実験することにします。

 

使うICは電源電圧の都合でLM324です。この石は音の悪さで定評があるらしいのですが、短波帯の音声受信はそもそも雑音だらけなので無視します。


なお、回路図上は省略しています(回路図CADではなくシュミレータのスクリーンショットなので)が終段にはイヤホン駆動用にエミッタフォロワ回路を付けました(参考文献3)。

 

図1 ACTIVE RC NOTCH FILTER

 

図2 ノッチ周波数可変の様子。設計周波数を外れると減衰量が極端に小さくなってしまう。

 

図3 ブレッドボードでの実験の様子

 

最初に試したのはその名もズバリ「ACTIVE RC NOTCH FILTER」というものです(参考文献1)。この回路のいいところは、ノッチ周波数を可変するのが容易な点です。代わりに減衰量や帯域幅が大きく変化してしまいますが。

早速LTSpiceで設計値を確認して、ブレッドボードに仮組みして動かしてみました。
しかし実際に音を聞いてみると、ノッチの効果は然程感じられません。この回路だけではなく、前段にBPFとか設置してメリハリを付けないとダメなのかも知れません。(掛かりの浅いフェイズシフターの前にディストーションを繋ぐ、みたいな(違))

 

 

図4 伝送零点を含むLPF回路。なお、取り敢えず周波数特性を確認するだけなので、シュミレーションにおける電源電圧やOPアンプの銘柄は適当です。

 

図5

 

図6 ブレッドボードにおける配線の様子

 

次に、ステートバリアブル回路で伝送零点を含む回路を試してみました(参考文献2)。カットオフを3kHz,ノッチを6kHzとして設計しましたが、部品の都合で少し低い方に動いてしまっています。

今度は効果が実感できました。煩わしい「ザー」が減って聴きやすくなりました。音的にも無線機っぽい感じがします。もう少し高域を削って欲しい気もしますが、各周波数を少し高めに設計しなおせば可能かも知れません。

 

参考文献1
CMOS APPLICATION-SPECIFIC STANDARD ICs(DL130 REV1) MOTOROLA INC,1991
発行所 日本モトローラ株式会社 発売元 CQ出版株式会社


参考文献2
実用アナログフィルタ設計法 今田悟/深谷武彦 1989 初版 CQ出版株式会社


参考文献3
OPアンプによる実用回路設計 馬場清太郎 2004年初版 2015年第9版 CQ出版株式会社

 

実験の様子。いつも思うのだが「よくこれで動くよねえ」

 

 

禁断症状回避の為に何か作る話の続き。

 

問題のある局発ですが取り敢えず動作確認は出来たので一気に受信機としてまとめてみることにしました。

 

復調用のミキサーに何を使おうか悩んだのですが、聞こえない受信機を作っても仕方ないので利得優先でアクティブタイプにしました。また、ここでバラモジICとか使うと入手に手間がかかりますので秋葉原の店頭で買えそうな個別部品で行くことにしました。

回路はJFETをソース接地で使っています。但し、カスコード接続にして受信信号と局発信号を各々のゲートに入れています。昔々、自作受信機で多用されたデュアルゲートMOSFETのJFET版です。
当初、1石のみで局発はソース注入にしようと思ったのですが、面白みがないので止めました。

 

出力にはエミッタフォロワを入れていますが、これはAFアンプ無しでもオーディオ用イヤフォンを繋げるようにする為です。昔は試作段階での音出しはクリスタルイヤフォン(あるいはセラミックイヤフォン)を使っていたのですが、個人的に使うのを止めているので。

 

RFアンプは以前使って結果が良かった非同調ゲート接地タイプです。単なるバッファとして動作させています。

 

AFアンプはNJM2073を使ったありふれたものです。動作電源電圧が広いので採用しました。今回は電源にエネループ4本で4.8Vを想定していますが、誤ってフォルダーに単三乾電池をセットすると6Vになります。定格が5V近辺のICにも良いものがあるのですが、安全性を考慮すると使えないことになります。

電源電圧の点ではFET側は9V位まで大丈夫のはずです(実験用電源が8V弱止まりなので試していない)。ちなみに、復調用ミキサに使ったカスコード回路は3.3Vでは動きませんでした。

 

局発回路は大きな変更は有りませんが、初出の時と定数を変えたところがあります。ゲートに接続していた100pFを10pFに替え、その影響で共振回路のCも変わっています。少しでも安定度が良くならないだろうか、という根拠に乏しい気休めに他なりません。

 

全てブレッドボードに仮組みして動作確認したところ、入力DC4.8V 20mA(待機時)となりました。やや大きい気もしますが、ノイズを拾ってNJM2073が動いているのでこんなものかも知れません。FET及び局発のレギュレータで12mA位流れています。なお、NJM2073のカタログ値は6〜9mAです(但しRLはinf)

 

 

主な問題点

 

ハム音
例によってアンテナとのマッチングに難があり、ハム音に悩まされました。RFアンプ無しだと、入力同調回路の同調点ではかなり小さくなるのですが、少し外れるとダメです。RFアンプを入れて何とか実用レベルになりました。
また、局発回路に3.3Vのレギュレータを入れたところ効果がありましたので、電源ノイズでかなり変調されていたようです。このタイプのレギュレータは初めて使うのですが、今のところ発振等のトラブルはありません。

 

放送波の通りぬけ
ミキサが平衡型でないこともあり、放送波が抜けます。それも41mBの国際放送とかではなく、中波のTBSです。ケースに納めれば改善されるかも知れませんが、根本的な解決にはならないでしょう。

 

低感度
電源電圧が低いので当然なのですが、感度がありません。アンテナがBFなことや、電離層のコンデション及びオンエアしている局数にもよるのでしばらく使ってみないと何ともですが、今のところ「夕方専用」になっています。

 

局発の安定度
周波数カウンタで見るドリフトの割には、復調音は安定して聞こえます。まあ、アマチュア局のワッチでは同一周波数で30分や1時間も粘るということは少なく(コンテストの時とかは別だが)ちょくちょく周波数を変えるので実用上問題は少ないのかも知れません。

 

うーん、もう少し聞こえるといいんだけどねえ。RFアンプ追加しようかしらん。

 

局発

 

高周波増幅・復調・低周波増幅

試作実験中の局発。これでうまくいくなら苦労はしない。

 

 

しばらく何も作っていませんが、そろそろ禁断症状が出そうです。こんな時、大掛かりなものに手をつけると計画倒れに終わるので簡単なものが良いのですが、そういったものは大体手がけていて部屋中に「シェルフウェア」として埃をかぶっています。

 

自分自身で使い古したテーマでも「縛り」をかけることで別の面白みが出てくるかも知れません。今回はその方向で進めてみることにしました。

 

概略
7MHz DC受信機
ケース YM-130
電源 4.8V

 

当初電源は3.6Vでいこうと思ったのですが、局発用に定電圧を用意しなくてはならないので4.8Vにしました。ロードロップタイプのレギュレータで3.3V位を得る予定です。

 

局発のテスト
DC受信機では局発が必要ですが、厳密に考えるとこれだけで1テーマになる(そしてそれだけでは何の役にも立たない)ので、肩の凝らない範囲で適当に作ることにしました。

 

図1 局発回路の試作(1)

書き忘れたがIdは2mAです。但し、これで適切かどうかは分かりません。

 

 

取り敢えず手持ちの部品をかき集めて作ったのが図1に示すものです。以前作った再生式短波ラジオ(セパレートダイン)の帰還部分を抜き出したような回路ですが、これは部品箱にあった試作済のコイルをそのまま流用したためです。
見るからに安定度が悪そうな回路ですが、実際その通りで電源投入後から落ち着くまで30分位かかります。その後も300〜500Hz程度でドリフトします。また、温度補償型コンデンサの手持ちがなく高誘電率品を使いましたので僅かでも室温が動く(その範囲は1℃前後)と、kHzオーダーで動いてしまいます。

 

さて、どうしたものか。

 

マウスやキーボードを長時間・長期間使っていると腱鞘炎を誘発しますが、それを少しでも緩和することを目的にした製品がいくつか市販されています。

で、今日、ヨドバシカメラ秋葉原まで行って観てきたのですね。秋葉原まで出たのは単なる気まぐれです。まあ、仮にヨドになくても秋葉原ならどこかしらで見つかるだろう、と。

 

手首や肘に負担がかかるのは、本来縦に構えるべき手のひらをマウスを握る際に横にひねるから、とかで、マウスの上に握りを付けて、ちょうどコップを持つような格好で保持できる製品を実際に弄ってみました。

ノートPCに接続されており実際の使い勝手も確認できたのですが、気づいた点が一つ。

「腕が辛くなりそう」

私の場合、マウスの移動操作はほとんど指先でやります。ノートPCに外部ディスプレイを繋いで2画面で使っていますが、それでも腕を大きく動かすことはまれです。間に合わない時は一旦マウスを持ち上げるし。

上記製品の場合、確かに握りやすいのですが、握ってしまうと当然グリップに指が全部取られてしまう(指先の近くにボタンがあるので、ボタン操作は支障ない)ので、指先でマウスを移動するということが出来ません。動かすには腕、少なくとも肘から下全体を動かさなくてはなりません。前後に動かすとなると肩から下の腕全体を動かすことになると思います。

うーむ、これは何ともですね。指先で動かすのが間違っていて、本来腕全体で動かすものなのかも知れません。正しいマウスの持ち方、というのを習ったことがないので判りかねますが。

 

話は逸れますが、電信術で使う縦振電鍵には正しい持ち方(というか操作方法)というのがありました。確か、短点は指先で、長点は腕(手首)を下げる、というものだったと思います。
これを字面通りにやろうとすると、ものすごくギクシャクしたおかしな動きになって、酷く腕が疲れるのでした。
実際は正しく符号を送り出そうとすると自然とこの格好になります。但し、実用速度で操作するとかなり高速に動きますので、素人目にはよく分かりません。
昔は映画や何かで無線通信の場面、というと決まって縦振電鍵が出てきたものですが実際は横振電鍵も多く使われていたはずです。横振なら手のひらが縦になりますので「エルゴノミクスデザイン」ということになります。
設計の自由度が高いと思われるエレキーのマニピュレータも一様に横振でした。私が見知った限りですが。

 

さて、件のマウスは結局買わずに帰りました。まあ、モノは悪くなかったし値段も高くて買えないという程のものでもありませんでしたので結構迷ったのですが。手持ちが故障していたら買っていたかも知れません。

 

暦の上では春ですが、寒い日が続いています。

 

今朝は特に冷えました。水道の出が悪かったので半ば凍結したようです。昨晩、給湯器側の水を出して寝て正解でした。壊したらダメージが大きいので。

 

まあ、寒い寒いと言ってもきついのは朝だけです。屋外でも日中の日向はかなり温かく、季節は確実に巡っているのが実感できます。

 

 

玄関の気温変化。氷点下を記録しています。

 

居室の三角出窓は思ったほど冷えていません。

 

居室内。日中は10度を軽く超えるでしょうね。

以前、このように  gtk の国際化対応をディスりましたが、gtkはちゃんと対応していました。

 

ここにお詫び申し上げます。


メニュー構築部分を書き直さなくては、と思って関数を確認しようとgtkのリファレンスマニュアルを再読していて見つけました。
日頃の斜め読みのツケがこんなところに出てきました。


さて、その対応ですが。

 

gettextを使っている時は、次の関数を使います。

void
gtk_action_group_set_translation_domain
                               (GtkActionGroup *action_group,
                                const gchar *domain);

                               
例えばこんな感じ。

actions = gtk_action_group_new("Actions");
gtk_action_group_set_translation_domain(actions, GETTEXT_PACKAGE);

GETTEXT_PACKAGEはconfigure.ac内での定義(多分)。普通はGETTEXT_PACKAGEになっているはず。

 

 


gettextによらない場合、次の関数で定義できる。

void
gtk_action_group_set_translate_func (GtkActionGroup *action_group,
                                     GtkTranslateFunc func,
                                     gpointer data,
                                     GDestroyNotify notify);                                   

 

無事、メニューも日本語で表示されるようになりました。

 


Search

Calendar

S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728   
<< February 2018 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

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