DELL U2718Q の修理(その2)

電源が豪華

このモニターの電源はかなり豪華な創りでコストをかけているように思う。


モニターの要は、液晶よりも電源なんだと実感する。

こんなに豪華な創りの電源は久々に見たー
※AppleのACアダプターを分解した時にも、使っている部品や構成など、凄く感心したが、それと同等くらいの感動がある。

AppleのACアダプターの場合は、コンパクト化で、ありとあらゆる空間を有効に活用する為、3次元的に部品を配置して、全く隙間が無かった。
この電源はスペースには余裕があるので、一見、部品の配置はスカスカだが、裏面には、かなり表面実装の部品を配置してある。

使っている部品もグレードが基本的に高いように思う。

消費電流はそんなに多く無いけど、ちゃんとPFC対策電源になっている。

制御ICの型番は、削ってあり、消されている。

最終段は 18V で、そんなに電流は流れないけど、FETによる同期整流回路を採用しているようだ。

この電源なら、簡単に故障しないだろうと思われる。
※どこぞの中華電源とは、全く別次元のグレードw


コンデンサが到着

コンデンサが到着したので、部品をハンダ付けするものの、パターンが広く、熱が拡散して、思ったようにハンダ付け出来ない。
※秋月の送料は、1万円くらいじゃないと無料にならないが、500円くらいなので、他に欲しかった部品を少し加えて、通販した。
それでも、秋葉原に行って帰ってくるだけで、2500円くらいかかり、往復6時間は電車に乗る事を考えると、2、3日かかってもかなりマシだ・・・

鉛フリーのハンダも、このような場合にはハンデとなると思うが、それにしてもかなりヘタクソ・・・
でも、一応、ちゃんと付いている事を確認した。

うっかり外した電源コネクタ近くの電解コンデンサは、頑張っても、ハンダを吸引出来なかったので、ストックしてあった物を無理やり付けた。
※220uF、25V

一部のコネクタを壊していた

最初に分解する時、この部分のフレキコネクタを壊してしまった、よく見えなかったのが原因だが、かなり気を付けていたつもりなので、自分的にかなり精神的ショックが大きい。

コネクタを交換する事も考えたが、これは、液晶パネルの温度を計っているらしいので、まぁ、無くても問題無いと判断した。
一応、ケーブルを挿して、隙間に厚い紙(名刺)を挟んで、何とかなったと思う。

このフレキコネクタと同じ物を探すのも大変そうで、通販に日数がかかると思うし、交換の手間もスキルもかなり高い。

あすか修繕堂

と呼ばれるネットショップ(YouTubeに修理の動画が沢山ある)に、

あすかリムーバー

「低温ハンダ」が紹介されている、これを使えば、取り外しは可能と思うが、3cmで600円と高価だ・・

組み立て

いつも後悔するが、分解する前に写真を撮っておくべきなのだが、今回も忘れている。

分解の様子は、その時は覚えているが、数日たつと、どうなっていたか忘れている・・・
組み立ては、パズルのようだが、そこまで難解ではなかったので、何とか元に戻せた。


一応直ったようだー

電源を入れてみるー

電源ランプが点いて、画面にロゴが表示された、どうやら直ったようだー


一応、MacBook Pro 13 に接続してみた、問題無い。

直る事が判っていれば、モニターを注文しなかったのだが・・・

折角直ったのだから、メインモニターに戻すべきなのだが、買ったばかりのモニターなので、迷うところ、一番の問題は、間違って解像度が低いモニターを買ってしまった事だ、同じ解像度なら、新品モニターを迷わず使うのだが・・・

でもまぁ、やはり解像度が高い以前のモニターを使うべきなのだろうなぁー・・・

DELL U2718Q の修理(その1)

何の前触れもなく・・

土日は、もて耐で、家を空けていた、仕事部屋は、日中、かなりの高温になるので、この時期エアコンが欠かせない。

日曜の夜遅く、戻って、速攻でエアコンの電源を入れて、ビールを飲みながら扇風機を浴びていた。
夜遅かったので、それなりに温度は下がっていたものの、30度くらいはあったと思う。

PCの電源を入れて、ログインして、ブラウザを立ち上げメールをチェックする。

そして、荷物の整理をして、もう一度画面を観ると、真っ暗だった。
あれ、おかしいなぁーと思い、マウスを動かしたり、キーボードを触ったりしたが何も変化が無いー

PCを強制シャットダウンして、もう一度起動するが、やはりブラックアウトで変化無し・・・

モニターの電源ボタンを押すが、何も変化無し・・・

モニターの電源ケーブルを抜いて、挿し直すなど一連の手順をするも、変化無し・・・

このタイミングで壊れるのか!?

とりあえず、以前にPS4のモニターとして使っていた17インチの小型モニターに繋いでみた、画面は小さいがちゃんとPCは起動して画面が出る。

保障を確認、そして分解

自分は、オプションの長期保証プラン的な物には入らない主義なので、このモニターの保証期間は去年の8月に終了している。
※購入してから2年くらいしかたっていない・・・

YouTube の修理動画などを多く観ていたので、このモニターも、電源系のどこかが壊れているものと予想した。

そこで、とりあえず、分解してみたー。

まず、見えるネジを外す、シールで隠されているネジは無かった。

意外と重宝した、タイヤレバー(バイクのタイヤをホイールから外す工具)

パネルの分解が一番難解なのかもと思う、どのような構造なのか、想像するしかない。
しかし意外と簡単に、隙間を開くと、裏蓋が少しづつ開いていく、硬い部分は、タイヤレバーなどを使って、少しづつ開いていく、コーナーは、剛性が高く、頑丈だったが、爪が折れる事なく、綺麗に裏蓋を外す事が出来た。

フレキケーブルなどを外し、電磁波対策の金属ケースを外して、メインボードを出してみる。

このモニターは大まかに3つのボードに分かれている。

・電源ボード
・メインボード
・液晶ライト制御ボード(と思われる)

解析

とりあえず、ACコードを繋いで、電圧をチェックしてみる。

メインボードの主要な電圧を計るとやはり「0V」。

今度は、メインボードと電源を繋ぐコネクターを外して電圧を計る。

ACラインは、正常でPFC対策がしてあり、直近のコンデンサには380Vの電圧が出ている。
最終出力は、18Vくらいのようだ、電源だけだと正常のようだ。
それにしても豪華な創りの電源だー

メインボードの電源ラインの「抵抗」を計ってみる、「4オーム」くらい、やはり、電源ラインのどこかがショートしているようだ。

一番最初に疑ったのは、電解コンデンサ、ルーペを使いよーく観察してみるが、膨らんでいたり、液漏れしていたりする様子は無い。

とりあえず、今日は眠いので、明日にでも、再調査する事にした。

新たにモニターを注文

修理には、それなりに時間がかかりそうなので、とりあえず、直近の仕事もあるので、替えのモニターを注文した。

今度も同じように27インチモニター、U2718Q は既に廃盤のようで、U2719D を注文した。
ここで、大失敗、急いでいたので、良く確認せず、4Kモニターでは無く、解像度が低い物を注文してしまった、これは、後に気がついた・・・

まぁそれでも、17インチのモニターよりは随分マシなので、到着を待つ事にする。

4kだと、高精細過ぎて、小さい文字が見えにくい場合もあるとか、自分に言い聞かせた・・・


U2718Q のメインボードは、eBay などに出品されていて、4000円程度で購入可能な事が判った。
※送料を合わせると6000円程度となる。

注文したモニターは水曜には到着した。
今度のモニターは、解像度は以前の物より低いものの、IPS液晶で、コントラストが高いように感じる。
文字がシャープな感じ。

解析を続ける

解像度が低いモニターを注文した事もあって、かなり落胆、動揺していた。

それで、何とか「復帰」させようと必死になっていた、液晶と接続しているケーブルを外して、基板だけを詳細に観察していた。

電源ラインには、220uF、25Vの電解コンデンサがあり、最初それを疑い、外してみたが、問題無いようだった。

次に回路構成を眺めていた、18Vから、スイッチングレギュレータで、必要な電圧を生成しているようで、それが4系統ある。
1系統(多分、USBハブの5V生成)は、二段目にあり関係無さそうだ。

3系統では、入力側に積層セラミックコンデンサが2個並列に並んでいる。
これらコンデンサの両端の抵抗を計ると4オームで、電源ラインと接続している事が判る、これは、入力段のバイパスコンデンサであると思われる。

ルーペでこれらを中心に観察したが、問題無さそうだった。

とゆー事は、この3系統の、スイッチングレギュレータICのどれかが死んだのか?

しかし、どう見ても、パッケージは正常で、破壊している兆候は無い。
※問題なのは、QFP の場合、型番の判断が出来ない点だ、壊れていても交換する部品の番号が判らない、調べるにしても、非常に沢山の中から探すのは骨が折れる・・・
※TI 製のようだが、確信は持てない、2 系統は同じ 14 ピンの QFP だが、1 系統は、8 ピンのチップ部品のようだ、4.7uH のインダクタがある。


一般的に、意外と IC は頑丈で、設計に問題が無く、熱的に安全なら死ぬ事は少ないと思われる。
それに、過電流保護などがしっかりしているので、破壊する事は少ないものと思われる。

それより、コンデンサなどの、部品の劣化が多く、大抵の故障は、それが原因だと、修理動画で、学習していた。

原因見つかる

電源の抵抗は 4 オームなので、電源は過電流で、保護回路が働き、0V となる。

それなら、外部に実験用電源を接続して、徐々に電圧を上げて、ある程度電流を流せば、壊れている部品が発熱するのでは無いかと考えた。


その前にもう一度、基板を観察、今度はスイッチングレギュレーター部の周辺だけを集中して観察していた。

すると、斜めからルーペで観察していたら、積層セラミックのバイパスコンデンサの横が僅かに割れて、クラックが入っているように見えた。
※隣に同じコンデンサがあり、隙間が狭く、見えずらい。

早速、ハンダステーションの電源を入れ、温度を最大にして、ハンダを大量に溶かして、コンデンサを外してみた。
※電源ラインはパターンが広く、熱が逃げるので、容量の大きいハンダコテじゃないとハンダが溶けない。

外して、電源の抵抗を計ると、ショートが解消している事が判った。
やはり、このコンデンサの劣化が原因のようだ、コンデンサ単体で抵抗を計るとやはり4オーム。

部品を調査

問題は、このコンデンサの容量だ、幸い、2個並列にあるので、正常の方も外して、容量を計ってみる。

どうやら、10uF のようだ、ただ、ここの電圧は 18V なので、25V 程度の耐圧は必要と思われる。

部品が手元に無いので、秋月に部品を注文した。
※昨日、打ち合わせで秋葉原まで出かけたのに、タイミングが悪すぎる・・・


今回はここまで。

RX マイコン用 FatFS のバージョンを最新版へ(ff14)

exFAT を有効にする

最近 64GB(SDXC) の SD カードを購入したので、RX72N Envision Kit でも試してみた。

FAT32 では、1つのファイルは最大 4GB までしか対応出来ず、SD カードの場合、32GB を超えるサイズは、標準で exFAT になっている。
exFAT は、もはや FAT32 とは、根本的に異なる構造のようで、新たに設計からやり直したファイルシステムのようだ。

FatFS では、exFAT をかなり前からサポートしており、ffconf.h の「FF_FS_EXFAT」を「1」にするだけだ。
リソースの少ないマイコンでも扱えるように、細かい工夫が色々してある、素晴らしいとしか言いようが無い。
何の苦労もなく利用できる事に、ChaN さんには感謝しかない。

ファイルが 4GB を超えるサイズを扱える事から、seek などの位置指定は 64 ビット仕様になるので、その修正も行った。
※FatFS では、「FSIZE_t」が 64 ビットで定義されている、exFATを使わない場合は、32ビットとなる。

ファイルリストは普通に取れたので、他も動作すると思えたが、ディレクトリの移動が出来ない・・・

調べると、exFAT の場合「f_getcwd」がカレントディレクトリパスを返さない・・・

これは、バグだろうと思い、良い機会でもあるので、ff13c から ff14 へアップグレードした。

しかし・・・

状況は変わらない・・・
何で?
と思い、f_getcwd の説明を読んでみたー

Note: In this revision, this function cannot retrieve the current directory path on the exFAT volume. It always returns the root directory path.

これは、仕様のようだ・・・

さて、どうするか・・・


カレントパスを自分で管理するしか無い

以前の実装では、自分で管理していたが、FatFS にその機能がある事が判り、FatFS の API を使うように変更したのに・・・

先祖返りとは・・・

そもそも、カレントパスの管理が一つのコンテキストなのは多少問題でもある。
※ FAT ではファイル名の文字コードが拡張2バイトで、ロケールに左右される問題点があった。(たとえば、アラビア語とに日本語を同時に利用出来ない)

FreeRTOSなどを使うようになって、複数のタスクから、ファイルシステムにアクセスする場合、カレントパスを共有するのは「少しマズイ」。

そこで、それを見越して、ファイルのアクセス関係を少し整理してみた。

ただ、複雑な相対パスなどを認識する事は出来ない簡易的な解析機能しか無い。


Micron 64GB SDXC カードの速度

※参考速度

Write: 'test.bin'
Write Open:  23 [ms]
Write: 684 KBytes/Sec
Write Close: 4 [ms]
Read: 'test.bin'
Read Open:  1 [ms]
Read: 1622 KBytes/Sec
Read Close: 0 [ms]

読み込み速度は、1.6M バイトもあるー

FreeRTOS 対応

FreeRTOS などで、マルチスレッドでファイルシステムを動かす場合、排他制御を有効にする必要がある。

ffconf.h の主要部分を書き換える。

#include <FreeRTOS.h>
#include <semphr.h>
#define FF_FS_REENTRANT 1
#define FF_FS_TIMEOUT   1000
/// #define FF_SYNC_t       HANDLE
#define FF_SYNC_t       xSemaphoreHandle

※「FF_FS_LOCK」は、「FF_FS_REENTRANT」の制御を行う場合、「0」にしておく必要がある。

ffsystem.c の修正。
このソースには、排他制御の呼び出しが集約されている、標準では、WIN32 関係 API の呼び出しになっているので、それをコメントアウトする。
FreeRTOS 用は、既に実装されており、コメントアウトされているので、そのコメントアウトを外して有効にする。

int ff_cre_syncobj (    /* 1:Function succeeded, 0:Could not create the sync object */
    BYTE vol,           /* Corresponding volume (logical drive number) */
    FF_SYNC_t* sobj     /* Pointer to return the created sync object */
)
{
    /* Win32 */
//  *sobj = CreateMutex(NULL, FALSE, NULL);
//  return (int)(*sobj != INVALID_HANDLE_VALUE);

    /* FreeRTOS */
    *sobj = xSemaphoreCreateMutex();
    return (int)(*sobj != NULL);
}

int ff_del_syncobj (    /* 1:Function succeeded, 0:Could not delete due to an error */
    FF_SYNC_t sobj      /* Sync object tied to the logical drive to be deleted */
)
{
    /* Win32 */
//  return (int)CloseHandle(sobj);

    /* FreeRTOS */
    vSemaphoreDelete(sobj);
    return 1;
}

int ff_req_grant (  /* 1:Got a grant to access the volume, 0:Could not get a grant */
    FF_SYNC_t sobj  /* Sync object to wait */
)
{
    /* Win32 */
//  return (int)(WaitForSingleObject(sobj, FF_FS_TIMEOUT) == WAIT_OBJECT_0);

    /* FreeRTOS */
    return (int)(xSemaphoreTake(sobj, FF_FS_TIMEOUT) == pdTRUE);
}

void ff_rel_grant (
    FF_SYNC_t sobj  /* Sync object to be signaled */
)
{
    /* Win32 */
//  ReleaseMutex(sobj);

    /* FreeRTOS */
    xSemaphoreGive(sobj);
}

標準では、exFAT は無効にしておく・・

一応、動作するようだが、もう少し、全体をチェックしたいので、標準では「無効」にしてコミットしておく事にする。

gcc-8 系での、strncpy などの警告

gcc-7 系から、strcpy、strncpy などを使う場合に、コピー先の配列サイズが、コピー元サイズより少ない場合、「警告」が出るようになった。
※サイズ不足でコピーが出来ない場合、終端「0」が抜けてしまい、問題が起こる、これを抑止するものだ。
※どのように判断しているのか不明だが、警告が出る場合と出ない場合があり、対処するのが難しい場合がある。
std::string などを使って、動的に配列を作れば良いのだが、組み込み系ではそうもいかない。

警告を完全に抑止するようなオプションを付ける事も方法の一つではあるのだが、それも、少し違う。

「ここは、まず、大丈夫なハズ」でも警告が出る場合は、以下のように抑止するようにした。

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncation"
                strncpy(&dst[l], base, len - l - 1);
#pragma GCC diagnostic pop

また、strncpy の亜種を実装してある、名前空間「str」に置いてある。
「string_utils.hpp」
あらかじめ、コピーする最大サイズを -1 して、最後は「0」で埋める。

        static char* strncpy_(char* dst, const char* src, uint32_t len) noexcept
        {
            if(dst == nullptr || src == nullptr || len == 0) return dst;

            auto tmp = dst;
            --len;
            while(tmp < (dst + len)) {
                auto ch = *src++;
                *tmp++ = ch;
                if(ch == 0) {
                    return dst;
                }
            }
            *tmp = 0;
            return dst;
        }

文字列の扱いは、メモリが少ない場合システムの場合でも、少し考える必要がある。

std::string 専用のアロケーターを実装して、簡単なメモリ管理を実装するのも良さそうだが、RX24T 位のデバイスを考えると、有限のメモリで凌ぐのでも良いかと考えてしまう・・・

P-LAP III のセンサーを修理

今年の「もて耐」は3時間

今年は、縮小プログラムで、3時間耐久となりました。

自分が参加している「Blue Eyes」は、今年、超有名レジェンドライダー3人がゲストとして参戦します。

世界的都合で3時間耐久になってしまったものの、お手伝いで参加出来るのは非常に光栄でもあります。
※来年は、是非ライダーとして参加したいです。

「レジェンドライダー」は、「もて耐事務局」が、正式なエントリーリストを公開するまでお待ちください。

昨日は公開練習日でした

今まで、二回あった公式練習日は、両日、天気が悪かったのですが、昨日は、晴れて、ドライで走れたようです。
Blue Eyes のメインライダー(五十嵐さん)が一番時計の15秒9を出していました、流石ですーー

そして、恐るべきレジェンドライダー、実線を離れて30年、ほぼバイクに乗っていなかったのに、初めてのコース、初めてのマシンで、数十分乗っただけで・・・(69歳)
40秒くらいから始まり、周回毎に少しづつタイムを削っていきますー

ですがー、今回はフルグリッドで、台数が多く、クリアラップはほぼ取れない状況、そして、スキルの差が大きく、極端に遅いライダーもいます。
その中で、ほぼ毎周同じくらいの割合でタイムを削っていく・・・
確か、全体で8周くらいしたと思いますが、ベストを更新しなかったのは、2周くらいだったと思います。
そんな事が出来るものなのか、魔法のようで、非常に感銘を受けました。
車載カメラの映像を見ると、レコードラインにレールがあるかのように、綺麗にトレースしています。

1、2コーナーで観ていた人が、あまりにリラックスしていて、全く無理をしている感じがしないと言ってました。

流石、世界戦で優勝した実績は伊達ではありません・・


他のレジェンドライダーも凄くて、ここでは書ききれません、別の機会に・・・(濃いライダー三人もーー)



CBR-250RR レースベース車は、モノブロックと、JB-MAGTAN で武装!
そして、多分、「初」のヨシムラマフラー

P-LAP のセンサーが壊れてる

ライダーには気の毒でしたが、P-LAPのセンサーが壊れていて、走行タイムは、サインボードでした・・・

直るかどうか判らなかったけど、預かってきました。

センサー基板が腐食している

サーキットには、マグネットバーが埋設してあり、それを通過する事で、ラップタイムを計測する仕組みがあります。
※これは、レースで使うトランスポンダー(ループコイルゲート式)とは異なるもので、どこのサーキットでも大抵はあるようです。

センサーは、磁気を感知して、ラップタイムを計測します。


センサー部はシリコンが充填されており防水加工されていますが、不完全で、水が浸入して、腐食したようです。

よくよく観察しましたが、基板のパーターンは生きていたので、クリーニングして、「追いハンダ」してみました。

直ったようです。

センサー部にマグネットを通過させると、ラップタイムを計測します。

P-LAP III は区間タイムを計測可能

昨日知ったのですが、このラップタイマーは区間タイムを計測できるとの事。

えーーー、どのような原理なのか?

聞いた話では、
「区間タイム計測モードでは、4回計測で、1周とする」
と聞いたのですが、そんなハズはありません。
自分は、P-LAP I の壊れたセンサーをもらい、直して、自作の計測器で使っていますが、普通に1周で1カウントでした。

そこで考えられる事は、P-LAP III のセンサーはアナログ式で、センスした、磁気の強さを観ているものと思います。
区間タイム計測用のマグネットバーは、ラップタイム用より、磁力を下げているのだろうと思いました。
それなら、ラップタイムと区間タイムを分離計測できるものと思います、そして古いラップタイマーでも今まで通り計測できるものと思います。