アンテナ調整するも… ― 2022/05/31 23:06
本日アンテナの調整を試してみた。
5°ほど北に振って調整、44レベルから52レベルまでは向上するも、以前のような60近くまでは届かず。
5°ほど北に振って調整、44レベルから52レベルまでは向上するも、以前のような60近くまでは届かず。
MXが映らない！その後 ― 2019/07/08 19:56
雨続きで屋根上に上がれない日が続き、なかなかアンテナの状況が見られなかったが、合間を縫って昇ってみた。
んー、なんか、前より30度くらい南側に回っているような?気のせいか?
でも、以前より宅地化が進んで周辺環境が大きく変わったこともあるので、方向確認サイトを頼りに合わせてみた。
結果、56位までアンテナレベルが劇的回復。
突発的なドロップはたまにあるものの、ボロクソになることは無くなりました。よかった。
参考サイト
地デジアンテナ設置方向調整確認 関東版（東京・千葉・神奈川・埼玉）東京タワー・スカイツリーの向き
https://www.maku-jyo.com/ant.shtml
んー、なんか、前より30度くらい南側に回っているような?気のせいか?
でも、以前より宅地化が進んで周辺環境が大きく変わったこともあるので、方向確認サイトを頼りに合わせてみた。
結果、56位までアンテナレベルが劇的回復。
突発的なドロップはたまにあるものの、ボロクソになることは無くなりました。よかった。
参考サイト
地デジアンテナ設置方向調整確認 関東版（東京・千葉・神奈川・埼玉）東京タワー・スカイツリーの向き
https://www.maku-jyo.com/ant.shtml
MXが映らない！ ― 2019/06/22 22:45
ここ一か月ほど、MXのシグナルレベルが極端に低い日が多く、ドロップどころか全く映らない日も出始め、非常に困っている。
今まで、アンテナレベル40前後で推移していたのが最近では36前後、最悪な時は30を割ってしまう。
おおよそ35を割るとドロップ過剰でフレームごとトび始め、33を割ると休止扱いになってしまう。
時間によって全く変わってしまうので、違法無線かなんかの影響受けている気がする。(番組Aパートはドロップ0だけどBパートはボロボロとかザラ)
なお、MX以外は75～90で推移しており、全く問題ない。
アンテナ本体のチェックもやってみようとは思うけど、期待薄かなぁ・・・。
今まで、アンテナレベル40前後で推移していたのが最近では36前後、最悪な時は30を割ってしまう。
おおよそ35を割るとドロップ過剰でフレームごとトび始め、33を割ると休止扱いになってしまう。
時間によって全く変わってしまうので、違法無線かなんかの影響受けている気がする。(番組Aパートはドロップ0だけどBパートはボロボロとかザラ)
なお、MX以外は75～90で推移しており、全く問題ない。
アンテナ本体のチェックもやってみようとは思うけど、期待薄かなぁ・・・。
ツインスティック備忘録 ― 2018/04/26 16:53
他サイトに無いデータ記録用
○ツインスティックDC
ネジ類
・ユニクロ B0タッピング M3 20mm バインド x8
→メインガイド＆マイクロSW基板固定用
・ユニクロ B0タッピング M3 11mm なべ ｘ8
→軸受架台筺体取り付け用(※ベース板に変更の際は皿へ変更)
・黒染 B0タッピング M3 9.5mm なべ
→筺体各部固定用
○ツインスティックDC
ネジ類
・ユニクロ B0タッピング M3 20mm バインド x8
→メインガイド＆マイクロSW基板固定用
・ユニクロ B0タッピング M3 11mm なべ ｘ8
→軸受架台筺体取り付け用(※ベース板に変更の際は皿へ変更)
・黒染 B0タッピング M3 9.5mm なべ
→筺体各部固定用
ラズパイマガジン2015年春号読んで ― 2015/01/26 07:18
ついでにもうひとつ液晶ネタ。
ラズパイマガジン2015年春号買いました。まぁ、基本的に日経Linuxに載ってたラズパイネタを再掲してるだけの雑誌ですが、普通のLinuxは全く使ってない自分には大変有難い（ｗ。
で、本題。元々2014年9月号掲載のaitendoの小型液晶 [M-TM022-SPI(http://www.aitendo.com/product/7277 )で遊ぶ、という記事。
この記事でppm2lcdっつー、ppm画像を表示させるサンプルプログラムがあるんですが、
このプログラム、確かに表示されますが、暫く放って置くと表示させた画像が崩れることがあります。っていうか崩れました。
原因は、main()関数の締めの
bcm2835_spi_end();
bcm2835_close();
のせい。SPIの使用終了を宣言して、通常のGPIOに戻る訳ですが、デフォルトが入力なおかげでMOSI、SCLK、CS、どれも電位的に浮いてしまい、ノイズの影響をもろに受けてしまうのです。
さらに、液晶のコマンド2Cは画面データを渡した後も、再び先頭から上書きされる形で入力を受け続けます。
なので、bcm2835_spi_end()でSPIを手放す前に液晶の画面データ入力受付を止めないと、ノイズで上書きされて崩れる場合が出ます。
特に、バックライトをPWMしてたりすると、バックライトピンのすぐ隣がSCLKなのでバリバリ崩れますｗ。
対策として一番手っ取り早いのは、bcm2835_spi_end();の前に
lcd_write_cmd(0x00);
を1行書き足すだけでNOPになり治まります。
本来なら、CSだけでもプルアップしておいた方が安全なんですが・・・
ラズパイマガジン2015年春号買いました。まぁ、基本的に日経Linuxに載ってたラズパイネタを再掲してるだけの雑誌ですが、普通のLinuxは全く使ってない自分には大変有難い（ｗ。
で、本題。元々2014年9月号掲載のaitendoの小型液晶 [M-TM022-SPI(http://www.aitendo.com/product/7277 )で遊ぶ、という記事。
この記事でppm2lcdっつー、ppm画像を表示させるサンプルプログラムがあるんですが、
このプログラム、確かに表示されますが、暫く放って置くと表示させた画像が崩れることがあります。っていうか崩れました。
原因は、main()関数の締めの
bcm2835_spi_end();
bcm2835_close();
のせい。SPIの使用終了を宣言して、通常のGPIOに戻る訳ですが、デフォルトが入力なおかげでMOSI、SCLK、CS、どれも電位的に浮いてしまい、ノイズの影響をもろに受けてしまうのです。
さらに、液晶のコマンド2Cは画面データを渡した後も、再び先頭から上書きされる形で入力を受け続けます。
なので、bcm2835_spi_end()でSPIを手放す前に液晶の画面データ入力受付を止めないと、ノイズで上書きされて崩れる場合が出ます。
特に、バックライトをPWMしてたりすると、バックライトピンのすぐ隣がSCLKなのでバリバリ崩れますｗ。
対策として一番手っ取り早いのは、bcm2835_spi_end();の前に
lcd_write_cmd(0x00);
を1行書き足すだけでNOPになり治まります。
本来なら、CSだけでもプルアップしておいた方が安全なんですが・・・
waveshare製Raspberry Pi用液晶について ― 2015/01/26 06:50
先日、aitendoでRaspberry Pi用3.5インチTFT液晶(http://www.aitendo.com/product/10814 )を購入しました。
ドライバ導入済みのOSイメージをSDに書き込んで、ブート&表示できることを確認。
・・・したまでは良いものの、シールドのデータシートが無く、液晶モジュール自体の素性がよくわからないので、実験等に使うには情報不足。
なのでちょいと調べてみることにしました。
まず、シルク印刷の単語でググってみると、WaveShareの製品のバルクであることがわかった。
http://www.wvshare.com/product/3.5inch-RPi-LCD-A.htm
ところが、メーカーサイトにも詳しい仕様は無く、空振り。
とりあえず、aitendoに回路図(http://aitendo3.sakura.ne.jp/aitendo_data/product_img/lcd/tft2/PRi_LCD/3.5/3.5inch%20RPI%20LCD%20(A).pdf )はあったので見てみたものの、かなり間違いが多く、あまり当てにはできません。
(例えば、74HC4094が74HC4049になってたり、74HC4040のQ3がQ5になってたり、3.5inchが3.2inchになってたり（ぉ、LEDバックライトのカソード本数6本が5本になってたり、etc...)
それでも、3.5インチで320x480かつ、タッチパネル付きで、フレキに37ピン出ている液晶となるとそこそこ絞れてくる。
ざっと出てきた感じだと、コントローラーは、
・ili9481
・ili9486
・HX8357B
・RM68042
辺りが使われていることが多いようです。
それぞれのデータシートをパパッと見た感じだと、どのコントローラーも、
1. コマンド2Aでカラムアドレス指定
2. コマンド2Bでページアドレス指定
3. コマンド2Cで指定範囲データ流し込み
という手順で共通しているみたいなので、描画用のプログラム自体は簡単に流用利きそう。
問題は、初期化の手順がわからないこと。
わからないなら、動いてる所から情報を引っ張ってくるしかないので、付属OSのログを漁る。
すると、以下のような項目が。抜粋すると、
[ 14.040140] fbtft_device: SPI devices registered:
[ 14.045289] fbtft_device: spidev spi0.0 500kHz 8 bits mode=0x00
[ 14.051724] fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
[ 14.058202] fbtft_device: 'fb' Platform devices registered:
[ 14.063958] fbtft_device: bcm2708_fb id=-1 pdata? no
[ 14.069475] fbtft_device: Deleting spi0.0
[ 14.076924] flexfb spi0.0: fbtft_request_gpios: 'reset' = GPIO25
[ 14.092207] flexfb spi0.0: fbtft_request_gpios: 'dc' = GPIO24
[ 14.098068] flexfb spi0.0: flexfb_verify_gpios_dc()
[ 14.113756] flexfb spi0.0: fbtft_init_display()
[ 14.118401] flexfb spi0.0: fbtft_reset()
[ 14.250931] flexfb spi0.0: init: write(0xB0) 0x00
[ 14.256797] flexfb spi0.0: init: write(0x11)
[ 14.268532] flexfb spi0.0: init: mdelay(250)
[ 14.539125] flexfb spi0.0: init: write(0x3A) 0x55
[ 14.544149] flexfb spi0.0: init: write(0xC2) 0x44
[ 14.549121] flexfb spi0.0: init: write(0xC5) 0x00 0x00 0x00 0x00
[ 14.555493] flexfb spi0.0: init: write(0xE0) 0x0F 0x1F 0x1C 0x0C 0x0F 0x08 0x48 0x98 0x37 0x0A 0x13 0x04 0x11 0x0D 0x00
[ 14.566659] flexfb spi0.0: init: write(0xE1) 0x0F 0x32 0x2E 0x0B 0x0D 0x05 0x47 0x75 0x37 0x06 0x10 0x03 0x24 0x20 0x00
[ 14.577823] flexfb spi0.0: init: write(0xE2) 0x0F 0x32 0x2E 0x0B 0x0D 0x05 0x47 0x75 0x37 0x06 0x10 0x03 0x24 0x20 0x00
[ 14.588966] flexfb spi0.0: init: write(0x36) 0x28
[ 14.593962] flexfb spi0.0: init: write(0x11)
[ 14.598434] flexfb spi0.0: init: write(0x29)
[ 14.773084] flexfb spi0.0: Display update: 1763 kB/s (170.096 ms), fps=0 (0.000 ms)
[ 14.780844] flexfb spi0.0: fbtft_register_backlight()
[ 14.785997] flexfb spi0.0: fbtft_register_backlight(): led pin not set, exiting.
[ 14.798708] Console: switching to colour frame buffer device 80x29
[ 14.813466] graphics fb1: flexfb frame buffer, 480x320, 300 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi0.0 at 16 MHz
[ 14.829078] fbtft_device: GPIOS used by 'flexfb':
[ 14.842578] fbtft_device: 'reset' = GPIO25
[ 14.853693] fbtft_device: 'dc' = GPIO24
[ 14.866900] fbtft_device: SPI devices registered:
[ 14.875148] fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
[ 14.884030] fbtft_device: flexfb spi0.0 16000kHz 8 bits mode=0x00
動かしてるドライバは有名所のfbtft(https://github.com/notro/fbtft )、デバイス登録名はflexfb、ということはfbtft登録済みの液晶ではない、と思ったら、 flexfb spi0.0: init: (初期化コマンド)に見覚えが…
はい、ili9486の初期化手順と同じものでした。
https://github.com/notro/fbtft/blob/master/fb_ili9486.c
つまり、WaveShare 3.5inch RPi LCD (A) はili9468搭載型液晶ということですね。
本当にそれで正しいかは、本来、液晶デバイスのIDが取れればいいんですが、いかんせん、片方向シフトレジスタしか付いてない上、液晶のRDXが結線されていないので事実上無理ですね。残念。
余談ですが、この液晶シールド、起動時白色なので個人的にちと微妙。
さらに、バックライトも電源ラインから直に引っ張っているのでオフにできません。超残念。
ドライバ導入済みのOSイメージをSDに書き込んで、ブート&表示できることを確認。
・・・したまでは良いものの、シールドのデータシートが無く、液晶モジュール自体の素性がよくわからないので、実験等に使うには情報不足。
なのでちょいと調べてみることにしました。
まず、シルク印刷の単語でググってみると、WaveShareの製品のバルクであることがわかった。
http://www.wvshare.com/product/3.5inch-RPi-LCD-A.htm
ところが、メーカーサイトにも詳しい仕様は無く、空振り。
とりあえず、aitendoに回路図(http://aitendo3.sakura.ne.jp/aitendo_data/product_img/lcd/tft2/PRi_LCD/3.5/3.5inch%20RPI%20LCD%20(A).pdf )はあったので見てみたものの、かなり間違いが多く、あまり当てにはできません。
(例えば、74HC4094が74HC4049になってたり、74HC4040のQ3がQ5になってたり、3.5inchが3.2inchになってたり（ぉ、LEDバックライトのカソード本数6本が5本になってたり、etc...)
それでも、3.5インチで320x480かつ、タッチパネル付きで、フレキに37ピン出ている液晶となるとそこそこ絞れてくる。
ざっと出てきた感じだと、コントローラーは、
・ili9481
・ili9486
・HX8357B
・RM68042
辺りが使われていることが多いようです。
それぞれのデータシートをパパッと見た感じだと、どのコントローラーも、
1. コマンド2Aでカラムアドレス指定
2. コマンド2Bでページアドレス指定
3. コマンド2Cで指定範囲データ流し込み
という手順で共通しているみたいなので、描画用のプログラム自体は簡単に流用利きそう。
問題は、初期化の手順がわからないこと。
わからないなら、動いてる所から情報を引っ張ってくるしかないので、付属OSのログを漁る。
すると、以下のような項目が。抜粋すると、
[ 14.040140] fbtft_device: SPI devices registered:
[ 14.045289] fbtft_device: spidev spi0.0 500kHz 8 bits mode=0x00
[ 14.051724] fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
[ 14.058202] fbtft_device: 'fb' Platform devices registered:
[ 14.063958] fbtft_device: bcm2708_fb id=-1 pdata? no
[ 14.069475] fbtft_device: Deleting spi0.0
[ 14.076924] flexfb spi0.0: fbtft_request_gpios: 'reset' = GPIO25
[ 14.092207] flexfb spi0.0: fbtft_request_gpios: 'dc' = GPIO24
[ 14.098068] flexfb spi0.0: flexfb_verify_gpios_dc()
[ 14.113756] flexfb spi0.0: fbtft_init_display()
[ 14.118401] flexfb spi0.0: fbtft_reset()
[ 14.250931] flexfb spi0.0: init: write(0xB0) 0x00
[ 14.256797] flexfb spi0.0: init: write(0x11)
[ 14.268532] flexfb spi0.0: init: mdelay(250)
[ 14.539125] flexfb spi0.0: init: write(0x3A) 0x55
[ 14.544149] flexfb spi0.0: init: write(0xC2) 0x44
[ 14.549121] flexfb spi0.0: init: write(0xC5) 0x00 0x00 0x00 0x00
[ 14.555493] flexfb spi0.0: init: write(0xE0) 0x0F 0x1F 0x1C 0x0C 0x0F 0x08 0x48 0x98 0x37 0x0A 0x13 0x04 0x11 0x0D 0x00
[ 14.566659] flexfb spi0.0: init: write(0xE1) 0x0F 0x32 0x2E 0x0B 0x0D 0x05 0x47 0x75 0x37 0x06 0x10 0x03 0x24 0x20 0x00
[ 14.577823] flexfb spi0.0: init: write(0xE2) 0x0F 0x32 0x2E 0x0B 0x0D 0x05 0x47 0x75 0x37 0x06 0x10 0x03 0x24 0x20 0x00
[ 14.588966] flexfb spi0.0: init: write(0x36) 0x28
[ 14.593962] flexfb spi0.0: init: write(0x11)
[ 14.598434] flexfb spi0.0: init: write(0x29)
[ 14.773084] flexfb spi0.0: Display update: 1763 kB/s (170.096 ms), fps=0 (0.000 ms)
[ 14.780844] flexfb spi0.0: fbtft_register_backlight()
[ 14.785997] flexfb spi0.0: fbtft_register_backlight(): led pin not set, exiting.
[ 14.798708] Console: switching to colour frame buffer device 80x29
[ 14.813466] graphics fb1: flexfb frame buffer, 480x320, 300 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi0.0 at 16 MHz
[ 14.829078] fbtft_device: GPIOS used by 'flexfb':
[ 14.842578] fbtft_device: 'reset' = GPIO25
[ 14.853693] fbtft_device: 'dc' = GPIO24
[ 14.866900] fbtft_device: SPI devices registered:
[ 14.875148] fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
[ 14.884030] fbtft_device: flexfb spi0.0 16000kHz 8 bits mode=0x00
動かしてるドライバは有名所のfbtft(https://github.com/notro/fbtft )、デバイス登録名はflexfb、ということはfbtft登録済みの液晶ではない、と思ったら、 flexfb spi0.0: init: (初期化コマンド)に見覚えが…
はい、ili9486の初期化手順と同じものでした。
https://github.com/notro/fbtft/blob/master/fb_ili9486.c
つまり、WaveShare 3.5inch RPi LCD (A) はili9468搭載型液晶ということですね。
本当にそれで正しいかは、本来、液晶デバイスのIDが取れればいいんですが、いかんせん、片方向シフトレジスタしか付いてない上、液晶のRDXが結線されていないので事実上無理ですね。残念。
余談ですが、この液晶シールド、起動時白色なので個人的にちと微妙。
さらに、バックライトも電源ラインから直に引っ張っているのでオフにできません。超残念。
千石のQIコネクタにご用心 ― 2014/09/18 03:48
QIコネクタ、と言われても、ああ、あれね、とすぐ判る人はあんまりいないと思います。
でも現物を見れば、あーあーあーあー、と思う人もそれなりにいるとも思います。
ピンヘッダにケーブル差す際、ケーブルの先に付いてるコネクタです。
自作PCやってる人ならLEDや電源スイッチに付いてるコネクタ、と言えば判ると思います。
このQIコネクタ(別名2550コネクタ、XLコネクタとも)、取り付けるには特殊な工具が要る為自分で取り付けてる人はあまり多くないですが、安いピンヘッダを汎用のコネクタとして利用できるため、かなり便利です。
ただ、取り扱ってるところは多くなく、千石やマルツなどでしかあまり売ってません(マルツはハウジングとコンタクトがセットなのでオスコネクタ作るときにちょっと不便)。秋月にないのはちと痛い。
で、私の場合はいつも千石で買ってるわけですが、1x1のQIコネクタハウジングでケーブル作って横並びにピンヘッダに差してみたときに違和感が。
1,2,と差していって、3本目辺りからなんかきつい。4本目となるとかなりハの字になり、5本目はもう差せない。
そう、サイズが微妙に規格よりでかいんです。1個当たり0.06mm位。
本来、2.54mmピッチなので、コネクタの幅はそれ以下になっていないといけない。
しかし、ノギスで実測してみると2.6mm超えている。これじゃ1～2本ならコンタクトの遊びで差さるけど、どんどんピッチが広がるから複数なんてとても差せない。
で、問題は、このサイズのやたらでかい1x1ハウジングが全部が全部じゃないところ。
サイズがでかいのと微妙にでかいけどまぁまぁなんとかギリギリ入るのが混じっているみたい。
サイズがでかいのと、ギリギリサイズのは成型時のゲート跡の位置が違い、
-------------------------------------------------------
ギリギリサイズ：
差し込み(下)側 [ ○ ］ ケーブル(上)側
上下のほぼ中央(若干ケーブル側寄り)に縦長に大きなゲート跡
-------------------------------------------------------
オーバーサイズ：
差し込み(下)側 [ ・ ] ケーブル(上)側
かなり下に寄った方にピンサイズのゲート跡
-------------------------------------------------------
となってるみたい。
なお、100個パックのはみんなでかいやつみたい orzｶｯﾁﾏｯﾀﾖ
さてどうしたもんか。勿体無いから紙やすりで削ろうか？メンドクサイことこの上ないけど。
※なお、圧着工具はエンジニアのPA-21がおすすめ。
小型コネクタ用のPA-09だとダイスの板厚が薄いので、QIコネクタに使うには圧着しづらいと思います。
でも現物を見れば、あーあーあーあー、と思う人もそれなりにいるとも思います。
ピンヘッダにケーブル差す際、ケーブルの先に付いてるコネクタです。
自作PCやってる人ならLEDや電源スイッチに付いてるコネクタ、と言えば判ると思います。
このQIコネクタ(別名2550コネクタ、XLコネクタとも)、取り付けるには特殊な工具が要る為自分で取り付けてる人はあまり多くないですが、安いピンヘッダを汎用のコネクタとして利用できるため、かなり便利です。
ただ、取り扱ってるところは多くなく、千石やマルツなどでしかあまり売ってません(マルツはハウジングとコンタクトがセットなのでオスコネクタ作るときにちょっと不便)。秋月にないのはちと痛い。
で、私の場合はいつも千石で買ってるわけですが、1x1のQIコネクタハウジングでケーブル作って横並びにピンヘッダに差してみたときに違和感が。
1,2,と差していって、3本目辺りからなんかきつい。4本目となるとかなりハの字になり、5本目はもう差せない。
そう、サイズが微妙に規格よりでかいんです。1個当たり0.06mm位。
本来、2.54mmピッチなので、コネクタの幅はそれ以下になっていないといけない。
しかし、ノギスで実測してみると2.6mm超えている。これじゃ1～2本ならコンタクトの遊びで差さるけど、どんどんピッチが広がるから複数なんてとても差せない。
で、問題は、このサイズのやたらでかい1x1ハウジングが全部が全部じゃないところ。
サイズがでかいのと微妙にでかいけどまぁまぁなんとかギリギリ入るのが混じっているみたい。
サイズがでかいのと、ギリギリサイズのは成型時のゲート跡の位置が違い、
-------------------------------------------------------
ギリギリサイズ：
差し込み(下)側 [ ○ ］ ケーブル(上)側
上下のほぼ中央(若干ケーブル側寄り)に縦長に大きなゲート跡
-------------------------------------------------------
オーバーサイズ：
差し込み(下)側 [ ・ ] ケーブル(上)側
かなり下に寄った方にピンサイズのゲート跡
-------------------------------------------------------
となってるみたい。
なお、100個パックのはみんなでかいやつみたい orzｶｯﾁﾏｯﾀﾖ
さてどうしたもんか。勿体無いから紙やすりで削ろうか？メンドクサイことこの上ないけど。
※なお、圧着工具はエンジニアのPA-21がおすすめ。
小型コネクタ用のPA-09だとダイスの板厚が薄いので、QIコネクタに使うには圧着しづらいと思います。
3mm白色LED特性(個人的＆主観的)レビュー ― 2014/09/12 07:40
何種類か白色LED買い置きしていたけど、後々使い所で迷わないように点灯試験してみた結果をメモ書き。
あらかじめ言っておきますが、主観入りまくりのレビューなので話半分、いや、話1/4ぐらいに思っていてください。
・OSWT3166B (OptoSupply)
[データシート]
Vf=3.4V If=20mA 1500～2180mcd
※定格使用で500時間程度で輝度半減、定格の1/10(2mA)での使用を推奨(寿命40000時間にUP)、との秋月コメント有
色的には若干青寄りの白色。
電流を下げても(当方では3mA)それほど大きく輝度が変わらない。
というか、電流上げても輝度の上昇がそれほど大きくない。
また、電流の大小による発光色の色変化も少ない。
秋月コメントを鑑みても、電流は下げ気味で使う方が寿命的にもよさげ。
510Ω(5V時、約3mA)あたりが適正か?
※19:00追記：
ちょっと素子にムラがあるみたい(発光色、輝度共に)
個体差がかなりあるみたい。
ものによっては255Ω(5V時、約6mA)のほうがいいかも。
どちらにしても、20mAなんて全然必要ない。
・UW3804X(スタンレー)
[データシート]
Vf=3.7V If=20mA 2800～5600mcd
(If=25mAまで)
色的には若干黄色寄りの白色。
輝度的にはOSWT3166Bよりは若干明るく見える、が、データシートの数値差ほどは変わらないようにも。
電流を下げると目に見えて輝度が下がる。
また、発光色も黄色にシフトしてしまう。(電球色っぽくなる)
よって、定格使用が望ましい。15～20mAは欲しい。
100～85Ω(5V時)あたりが適正か。
あらかじめ言っておきますが、主観入りまくりのレビューなので話半分、いや、話1/4ぐらいに思っていてください。
・OSWT3166B (OptoSupply)
[データシート]
Vf=3.4V If=20mA 1500～2180mcd
※定格使用で500時間程度で輝度半減、定格の1/10(2mA)での使用を推奨(寿命40000時間にUP)、との秋月コメント有
色的には若干青寄りの白色。
電流を下げても(当方では3mA)それほど大きく輝度が変わらない。
というか、電流上げても輝度の上昇がそれほど大きくない。
また、電流の大小による発光色の色変化も少ない。
秋月コメントを鑑みても、電流は下げ気味で使う方が寿命的にもよさげ。
510Ω(5V時、約3mA)あたりが適正か?
※19:00追記：
ちょっと素子にムラがあるみたい(発光色、輝度共に)
個体差がかなりあるみたい。
ものによっては255Ω(5V時、約6mA)のほうがいいかも。
どちらにしても、20mAなんて全然必要ない。
・UW3804X(スタンレー)
[データシート]
Vf=3.7V If=20mA 2800～5600mcd
(If=25mAまで)
色的には若干黄色寄りの白色。
輝度的にはOSWT3166Bよりは若干明るく見える、が、データシートの数値差ほどは変わらないようにも。
電流を下げると目に見えて輝度が下がる。
また、発光色も黄色にシフトしてしまう。(電球色っぽくなる)
よって、定格使用が望ましい。15～20mAは欲しい。
100～85Ω(5V時)あたりが適正か。
最近のコメント