ESUの旧版サウンドデコーダである、LokSoundV4シリーズ(microも含む)で、最近、複数の書込み不具合報告が出ています。
オープンサウンドデータを書き込んだときにでた症状とのことでしたが、データの方の不具合では無く、LokSoundV4自体の問題の可能性が高いので書かせて頂きます。なお、対策としては、LokProgrammer4(V4向け最終版)を使ってみるとか、症状がなくなるまでひたすら何度も書込みし直すという事しか無いようです。ただ、これもやってたら治ったという結果論であり、きちんと検証して得られたノウハウではございません・・・。
LokSound5では、今のところ、このような現象は聞いておりません。
なお何度も書きますが、ESUはコンペチターです。DesktopStationの競合会社です。LokSoundサウンドデコーダはESU社の商品であって、DesktopStationの商品ではございません。
昔からのお得意様や、開発を手伝ってくれている協力者からの問い合わせには柔軟に対応しておりますが、新規ユーザーさんから突然、LokSoundをマンツーマンでサポートしてくれと言われても、難しいものがあります。公開の場での相談は受け付けておりますので、デジタル鉄道模型フォーラムをご利用下さい。
■報告内容①
MT54近郊型、急行・特急型の救済版(LokSoundV4)をLokSoundV4 無印(HO向け) ファームウェア4.17.9249に書き込んだところ、書込みはできたものの、ファンクションの番号と実際の動きがグチャグチャになる症状が出た。CV8でリセットしてもダメだった。なお、LokSoundV4はずっと使っていなかったものであった。LokProgrammerは5.0.12。
■報告内容②
LokSound V4 micro(N向け)で、本来はF2のはずの警笛がF1に、警笛のはずのF2でブロワー起動など、ファンクション関係がぐちゃぐちゃになった。
データもロットも古い状態(最後の通電から2年弱経過)でファームウェアアップデート＆CV書き込みで発生、以降、CV書き込みやデコーダーリセットは何度やっても復旧せず、再度サウンドデータ書き込みしたところ、なぜか復旧した。
古いロットのV4、あるいは長期間通電していなかったV4と最新に近いLokProgrammer 5の組み合わせだとダメなのかもしれないが、詳細は不明。
———————————-
電機屋の視点から見ると、長期保管と言うことで、EEPROMかフラッシュメモリの長期間保存でのデータ化けの可能性が高いなあ～と思ってます。とはいえ、ちゃんとデータシート通りに使えば、１００年単位で記録が保持されるはずなのでありますが。
エラーチェックが貧弱なのか、ファームウェアでのメモリの使い方が悪くてデータが壊れやすいのか、そもそも品質の悪いメモリを使っているのか・・・。
ESU LokSound V4の長期保管していたものには要注意？
