Select Your Language

免責事項

  • 本サイトの情報の利用、内容、サービスによって、利用者にいかなる損害、被害が生じても、著者は一切の責任を負いません。ユーザーご自身の責任においてご利用いただきますようお願いいたします。

    本サイトで頒布している基板およびキットは、技術者、またはそれに準ずる電気的知識をお持ちの電子工作ファンの方のためのものです。一般のオーディオファンの方のためのものではありません。
    また、頒布基板およびキットは、いかなる条件でも動作を保証するものではございませんので、あらかじめご了承ください。

    電子工作では、火傷、感電、火災などの可能性があります。十分に注意をして作業して下さい。

    営利目的のご使用は認めておりません。 記事の転載や、基板・キットの商用利用の方は、ご連絡ください。学生やサークルの学習目的でまとめてご購入する場合は特別価格でご提供させていただきます。
無料ブログはココログ

スポンサー

« ASCIIさんに禁断のヘッドホンアンプ S を取り上げて頂きました | トップページ | BM83モジュールの設定について »

2024年9月14日 (土)

トラ技10月号に載っていたONKYOの特許を調べてみました

今、ちょうど特許検索サイト「j-platpat.inpit.go.jp」がメンテナンス中で見えませんが、ONKYOの特許を調べてシミュレーションしたのをご紹介いたします。

特許は特開2019-110413(P2019-110413A)です。 メンテナンスが終わりましたら特許の書面に目を通してみるのも面白いかもしれません。興味のある方はどうぞ。
(特開2019-197944(P2019-197944A)の方がトラ技記事に近いようです。)

Onkyo_00_20240914092901

特許の文章を読み解くのはちょっと疲れるので、早速シミュレーションしてみましょう。

 

各所の定数は以下のようにしました。 OPAMPはLTspiceでは基本のLT1007にしています。

Onkyo_01_20240914093701

抵抗R50だけはシミュレーション上で動作を見やすくするために追加しています。

 

では早速、

オペアンプ出力電流(R50に流れる電流)とアンプ全体の出力電流(R3負荷に流れる電流)を見てみます。

Onkyo_02_20240914093701

青がR50電流、 緑がR3電流です。  オペアンプ出力がトランジスタバッファにより電流ブーストされているのがわかります。ざっくりオペアンプ出力が半分で済んでいるような感じですね。

 

この回路、見ためで引っかかったのは、ダイヤモンドバッファの入力と出力をそのまま接続しているところです。これで正しく動作するのか? という疑問が湧きました。

 

試したのがコレ。 ダイヤモンドバッファの入力と出力を接続していた線を切りました。

Onkyo_05
  < 検証(1) ダイヤモンドバッファの入出力間を切る >

こちらの方が、R50電流はほぼ流れず、トランジスタによる外付けバッファから100%の電流を供給していることが分ります。

 

次に生まれた疑問。 オペアンプ電源からカレントミラーで信号を拾う必要があるのか? 

ダイヤモンドバッファの入力と出力は再び接続して、オペアンプ電源は直電源。ダイヤモンドバッファの上下定電流は2.8mAくらいになるようにしました。 

Onkyo_03
  < 検証(2)オペアンプ電源から電流を拾わない >

結果は、このようになりました。 R50電流=出力電流。 つまりトランジスタによるバッファから殆ど供給されていません。役立たずです。

 

では、この状態でダイヤモンドバッファの入力と出力の接続を切るとどうなる?

Onkyo_04
  < 検証(3)普通の電流増幅バッファ >

予想どおりですね。R50電流はほぼ無くなり、ダイヤモンドバッファにより出力されています。

 

 

オペアンプの出力強化という意味でダイヤモンドバッファを追加するケースはこの回路に該当します。

LT1010やBUF634などのバッファICをオペアンプの出力に接続する回路がまさにコレです。

Lt1010_00
      < LT1010のデータシートより >

 

Buf634_00
      < BUF634のデータシートより >

これらバッファの入力と出力をショートしちゃったら台無しですよね。

 

トラ技版のように外付けバッファの電源端子からカレントミラーで終段バッファを駆動する回路をBUF634に置き換えるとこんな感じでしょうか。

Buf634_01
もし、上下のカレントミラーがなかったら入出力ショートした後段側のBUF634のは電流ブーストの役を果たしておりません。

ONKYOの特許のシミュレーションの結果からすると、カレントミラーで信号を持ってくることで前後段がお互いに電流を分担していることがわかりました。つまり前後段2つのバッファがどちらも電流供給しているということです。

※後段BUF634の出力SEPPはカレントミラーを通さないV+、V-が必要なので、この回路は正しくありません。あくまでもイメージです。

 

 

 

例えるなら、エンジンのシーケンシャル・ツインターボ(2ステージ・ツインターボ)のような回路ですね。

という訳でONKYO特許回路は思いつきそうで思いつかない面白い回路だと思いました。トラ技キットとして2025年の正月に発売されるっぽいのでちょっと聴いてみたいですね。

 

 


追記  電流帰還ループを設けてみます。

Onkyo_06

当初、電流帰還と電圧帰還の多重ループかと勘違いしたのは、ダイヤモンドバッファの前段のトランジスタのベース(回路図中のIN2)とオペアンプの出力が直結されていたからです。そこにβ回路を入れると立派な電流帰還ループになるかと思いました。

でも、実際にはIN2とOUT2が接続されているとカレントミラーでの電圧増幅がなくなってしまうため帰還するだけの電圧振幅が生まれなくなっていました。

上の図はIN2を切り離してβ回路による電流帰還を付けた時のR50電流とR3電流(負荷電流)です。

これまでの波形と比べて決定的な違いがお分かりいただけますか?

 

そう、R50電流の位相が逆になっています。

 

これはオペアンプから出力される電流ではなく、ダイヤモンドバッファからオペアンプ側に逆流している帰還電流です。 アレキサンダー型電流帰還アンプと同様になります。

電流帰還部でのゲイン Ka =(1k+220)/ 220 = 5.545倍  ですが、全体でみる

大外の反転増幅アンプとしてのゲイン Kb = 10k / 33k = 3.3倍  に制限されます。

 

R51削除してR50を0Ωにすると、電流帰還部で100%の帰還がかかって、Ka = 1倍 となります。

ONKYO回路との違いは IN2が OUT2(OUT1)に「接続されている」か「浮いているか」の差です。

 

カレントミラー部で電圧を増幅し、そのゲインを電流帰還としてフィードバックしているため、ONKYO特許とは別の回路構成とすることができるかと思います。

オープンループゲインが大きく多量の帰還を掛けるので、もしかしたらひずみ率が小さくなるかもしれませんし、発振して実用に耐えない可能性もあります。 位相補償はIN2-OUT1間に33p~100pF程度入れておく感じですかね。

もちろん通常の反転増幅回路の位相補償(R6へ並列に5p~33pFくらい入れる)も効くと思います。 

 

 

« ASCIIさんに禁断のヘッドホンアンプ S を取り上げて頂きました | トップページ | BM83モジュールの設定について »

電子回路」カテゴリの記事

コメント

記事の内容からはちょっと外れるのですが・・・。

トランジスタ技術のサイトで公開されているトーンコントロール回路のシミュレーションデータ。LTspiceを最新バージョンにアップしたら、結果が表示されるようになりました。

でも、増幅・減衰度がBASSとTREBLEで非対称、増幅・減衰度が過剰だと思えたので、パラメータを色々と変えてみて20Hzと20kHzの両方で約±10dBに抑え込むことに成功。
これで、TDA1552Qアンプに搭載するトーンコントロールの定数がやっと決まりました。

LTspiceを使うと、色んなパターンを実際に回路を組むことなく検証できるのはいいけれど、夢中になってやってると徹夜になってしまうのが困りもの。😹

記事を読んでいてふと、nabeさんのところで昔に似たような議論が行われていたことを思い出しました。
https://nabe.adiary.jp/loop-buf
今回の記事ですと、オペアンプ電源からカレントミラーで信号を拾わない場合はバッファとしての意味がないと書かれていますが、nabeさんのところでは意味があるという結論になっているようです。(もし私の読み方が間違っていたら大変申し訳ないです......)
うーん、どちらが正しいのでしょうか?

追記です。
今回の記事の回路では、オペアンプとダイヤモンドバッファ両方が負荷を分担しているような形になっていると思われるのですが、たかじんさんはどのようなメリットがあると考えられますでしょうか。innocent Key さんがバッファを通すとオペアンプの音が薄れるとおっしゃっていましたが、もしかしてこの回路はあえてオペアンプの音を残すためだったりして......!?

三毛にゃんジェロさん

LTspiceって便利ですよね。 時間がどんどん消費されていくの、分かります。 とにかく楽しい。

素子感度ってご存じでしょうか? イコライザ回路でQを高くすると一部の部品のパラツキに敏感な素子が出てきたりします。 シミュレーションではばっちりだったけど、実際に作ると特性が思っていたのと違う。 なんてことを引き起こします。

そういえばパラメトリックイコライザ基板、放置してた・・・
https://nw-electric.way-nifty.com/blog/2023/04/post-ab9082.html


naka さん

nabeさんの記事見てきました。 なるほど。 確かに、電流ブーストとして機能していなくても、音を聴いたら変化がでそうですね。 高出力バッファをぶら下げることで低インピーダンスにしているような感じですね。 色んな考え方があるなぁ・・・

ONKYO回路の特許文献がサーバーメンテナンス中で確認できないのですが、この回路の特徴としてひずみ率をOPAMP単体時より下げることを目標(発明の効果)にしていたような気がします。

なので、OPAMPの出力を活かしつつ、負荷が重くなった高電流出力時にうまい具合にブーストしてくれるようにしているのがウリ。 なのではないでしょうか。

ClassAAも前段アンプの出力が最終出力に繋がっていてるけど、後段アンプが電流を負担するということで、思想のベクトルは似ているようにも思います。

たかじんさん

素子感度って知りませんでした。
Qに影響が出るということは、コンデンサやコイルで特に顕著ということでしょうか。


話は変わりますが、特許所有者が倒産などで消え、その継承者もいない場合、その特許の法的な扱いはどうなるのかと素朴な疑問。
債権者の共同保有になるのかな〜?
もし特許が切れてるなら、たかじんさんが基板製作・・・などと妄想。😹

たかじんさん

特許の内容はこちらでも見られます。
https://patentimages.storage.googleapis.com/c5/c0/61/eeb1f8c69133ca/JP2019110413A.pdf

私も出願明細書を某商用DBからダウンロードしました。

>三毛にゃんじぇろさん
審査請求が未ですので、まだ特許権は存在しないです。
特許権が発明者に行かないのが日本の特許法(改正という改悪)だから、
請求権者が存在しなければ審査請求も出来ない(お金かかるし)。
発明者が自腹切って請求するかなぁ・・・・

オンキヨーの債権者がこの発明を評価出来て金銭価値ありと判断すれば
権利被譲渡者として審査請求費用を払って権利化する可能性はあるけど
時間と技術理解とお金がかかるから、やるかな?

特許権が成立しなければ(審査請求が無)この技術内容は公知になるので
他の誰も特許権を主張できません。
特許権が存在しない技術は営利・非営利に関わらず、使い放題です。
まあ、審査請求の期限内に営利企業が堂々と使う事はないと思いますが。
(トロールの手に渡ってウソみたいな使用料要求、とか怖いし)

三毛にゃんジェロさん

素子感度・・・ Qが高い回路ではちょっと気にした方が良いって程度です。 特にコンデンサは±5%くらいのバラつきがあるので注意した方がよいです。
LTspiceでもモンテカルロ解析ってのができたと思います。やったことないけど。。。

ONKYOの継続具合は気になりますね。 Wikipediaも追いついていない様子。
https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%B3%E3%82%AD%E3%83%A8%E3%83%BC


Nfm さん

ありがとうございます。 google パテントからの検索ですね。 思いつかなかったです。

読んでみるとエネルギー消費を増やさずに歪を悪化させない、でもオペアンプ単体より大電流出力が出来るってことを目的にしているようですね。
ちょっと勘違いしていました。

ダイヤモンドバッファの前段側ベースがオペアンプ出力に接続されていなければ、カレントミラーの出力側で電圧増幅が得られ(60~70dB)て、ダイヤモンドバッファの後段からオペアンプ出力へと100%の電流帰還が掛かっているようにも見えました。

でもQ1,Q2のベースがオペアンプ出力に接続することでカレントミラー部のゲインが低下し、殆ど電圧増幅しなくなっていますね。

今、気が付いたのですが出願者は吉田氏となっていて、今回のトラ技の筆者さんですね。


sawanoriichiさん

> 審査請求が未ですので、まだ特許権は存在しないです。
なんと・・・

たかじんさん、三毛にゃんジェロさん

失礼しました。
先の投稿前に私が見たドキュメントは公開広報の出願明細書でした。
改めてダウンロード資料から特許公報を確認しました。

当該発明は出願:平成29年12月19日、公開:令和元年7月4日で、
令和2年12月1日に審査請求がなされ、
令和4年7月6日に特許第7096478号(P7096478)の特許公報がなされています。
最新の権利者は「オンキヨー株式会社」になっています。

と言う事で、2037年12月18日まで特許権が存在します。

先ほどの私の投稿は全くの嘘八百となります。
お恥ずかしい限り。大変失礼いたしました。

補足です。

オンキヨー株式会社は複雑な会社分割経緯がありますが、
オンキヨーホームエンターテイメント社などの事業を引き継いで
研究開発とマーケティングを主にライセンスビジネスを展開する企業として存続しているようです。

当該特許の権利者は現在の「オンキヨー株式会社」なると思います。
現在はMBOでTK-FUND合同会社の中島健城氏が過半の株式を所有し
オーナーになっているようです。

ブランド権利は異なる別法人が所有しているので
「ONKYO」等の商標を「オンキヨー株式会社」が使用できないようです。

sawanoriichiさん

なるほど。特許が有効ということですね。
となると、個人の範囲で使用するのは可能としても、基板として販売するのはあと14年無理ということですね。でも、14年後にはスピーカー以外の自作オーディオは絶滅して久しそうな気配。😿

2037年といえば、例の32ビットクロック問題の年ではないですか。
大空騒ぎした2000年問題より遥かに深刻な問題。絶対に世界中で問題が噴出しそうな予感。🙀
でも、その頃には死んでるだろうから気にしないことにする。😹

sawanoriichi さん

調査ありがとうございます。 ほんと複雑ですね。
https://www.onkyo.net/brand

すでにブランドをライセンスしているようで、今後どうなるのか。 Nakamichiとかサンスイもブランドだけ生きているようではありますが。


三毛にゃんジェロさん

2037年問題なんてのがあるんですね。 テレビのB-CASカードが2038年までというのは聞いたことあります。

たかじんさん

現在、多くのプラットフォームでは64ビットのクロックを使っているのですが、以前の32ビットクロックのシステム(UNIXおよびPOSIX互換システム)では1970年1月1日0時0分0秒を起点に1秒単位でカウンターをカウントしているんですね。
C言語のtime_t型は実はlong型(32ビット整数)で、time関数が返すのもこのカウンター値で、1970年1月1日0時0分0秒からの経過秒数にほかなりません。
この32ビットカウンターが最大値に達した1秒後には0に戻るので、時刻が一気に1970年1月1日0時0分0秒に戻ることになります。これが2038年1月19日に起きるのです。2037年というのは誤りでした。

64ビットクロックを使うようにプログラム修正で回避できるんですが、C言語処理系やOSのAPIレベルの話になるので、アプリケーションレベルの問題だった2000年問題より遥かに深刻です。
問題はブラックボックスとして世界中の至る所でその存在を知られることもなく動作しているシステム。32ビットクロックで動作している機器なんて世界で何百億台あるいは何千億台もあるに違いないので、そのうち1%でも時計が過去に遡ったりしたら大問題という訳です。あと13年でそんなシステムが全て更新されるかどうか。

たかじんさん

32ビット整数の0h7FFFFFFFFが1つカウントアップされると0h8000000となり、2の補数体系ではマイナス21億・・・となるので、時計が1970年1月1日0時0分0秒ではなく、さらに68年前の1902年前後に戻る可能性もありそうです。
time()の戻り値を使って年月日時分秒に変換するgmtime()やlocaltime()がどんな時刻を返すものやら。もしかすると、その時点でクラッシュするかも。

いずれにしても、プログラミングに使用したCコンパイラと実際に稼働しているシステムのAPI次第ということになりますね。

なぜ、同じ32ビットでも符号付きではなく、符号なしで定義しなかったものか。32ビット符号なしなら2106年頃までは問題なかったはず。
UNIXやC言語が登場した1970年前後では、2038年なんて遠い未来だから気にしてなかったのかな。😹


なんてことを考えてたら、1969年ヒットの名曲"In the Year 2525" (邦題: 西暦2525年) by Zager & Evansのメロディが頭の中に流れて来ました。55年後の現在を鑑みると、示唆に富んだ考えさせられる内容の歌詞でした。

三毛にゃんジェロさん

お詳しいのですね。 PCやサーバのOSは64bit化が相当進んできていますが、アプリは後方互換で32bitのものがそのまま走るから引きずっているのかもしれませんね。

ラズパイのドライバでkernelバージョンが上がるたびにAPIが変更され、ソースコード書き換えを余儀なくされました。 とはいえソースは新しく用意されたAPIへ移行するだけの単純なものが殆どです。

そんな感じで、time() などの関数も新しく用意したAPIへ乗り換えしないとコンパイルErrorがでるようにすればいいんじゃないかと思ってしまいます。

組み込まれているハードウェアは、製造から20年あたりで寿命がくるので自然と入れ替わるような気もしないでもありません。

関係ないけど、ExcelのVBAでシリアル通信するモジュールが32bitと64bitとで互換性がないのはやめてほしい・・・

たかじんさん

測定器のファームウェアや無人観測システムのブログラムなどを設計・製作してましたから。

2038年までにきちんと更新がされるといいんですが、絶対に見落としがあると思うんですよね〜。特に、分野を問わず政府・自治体関係で。

三毛にゃんジェロさん

そうだったのですね。 組み込みシステムのプログラムは案外長生きすることもあるので、どこかで問題を起こすのは間違いないと思います。

銀行のシステムが落ちるとか、携帯やネットなど通信網が崩壊するとか、そういう大混乱が2000年問題で起きるかもって噂があったけど、そういう感じにはならないような気もするし。

コメントを書く

(ウェブ上には掲載しません)

« ASCIIさんに禁断のヘッドホンアンプ S を取り上げて頂きました | トップページ | BM83モジュールの設定について »

サイト内検索(new)

2025年2月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28