鉛蓄電池を充電

4年ほど放置していた鉛蓄電池があるのですが、「ダメになってるかなー」と思ったけど電圧を測ってみたら11.6Vくらいあったので、充電することにしました。(追記:後で知りましたが、テクニカルマニュアルによると、ほぼ完全放電状態。室温での4年放置は「Not Allowed」みたい・・・・)

鉛蓄電池なので、定電圧定電流充電ということで、AliExpressでDC入力のCVCC電源ボード(しかも、Stepup-Stepdown両方で動けるもの)が安く出ていたものを購入。ボードの説明をよく見ると、出力側からの電圧印加はダメと書いてあったので、出力側で対策をすることにしました。単純にダイオードを入れようかとも思ったのですが、3Aくらいで充電すると2W近い熱がでることと、以前秋月で見かけたPowerPathコントローラICが気になっていたので、これを買って理想ダイオードの構成としてみました。

回路はほぼLTC4412のデータシートの表紙の標準的応用例のままですが、あくまで充電器なので、左のバッテリーのマークのところにCVCC電源ボード、右側のLOADのところに鉛蓄電池を接続、WALL ADAPTER INPUTのパスは削除しています。なので、LTC4412とPchのPowerMOSFET(今回は60V36Aの2SJ673を使用)とパスコン、接続部品・ヒートシンクのみというシンプル構成です。

実際に充電している歳の様子です。

今回作った理想ダイオードの部分です。かなり余裕のあるFETを使っているので、もっと大きな電流を流す用途にも使えるはずです。

組み立てが終わったら、まず入力にDC12VのACアダプタを接続してDCDCコンバータ単体で電源投入。UV-SET(入力電圧低下時のカットオフ電圧)FAULTのLEDが点灯しない位置にセットします。出力電圧をモニタしながらVOUT-SETの半固定抵抗を13.8Vにセット。CC-SETの半固定抵抗は(確か)左へ一杯に回しておきます。
次に、理想ダイオード部分をつないで電源投入。出力電圧が13.8Vのままなのを確認します。
さらに、鉛蓄電池のGND側のみ接続、+側はテスタで電流を測定できるようにして一瞬つないで電流を読みます。値は30mAくらいでしたので、CC-SETの半固定抵抗を回して1Aになるところにセットしました。
+側も直結したあと、最後にACアダプタの電源を切った時に、理想ダイオードの出力側は電池の電圧のまま、入力側の電圧は徐々に下がっていくのを確認して、完成です。

今回は補充電として使っていますが、鉛蓄電池ごとケースに入れてもっと充電電流を増やしてやれば、車で移動中に充電しておいてエンジンOFFの電源として使えるかなーとか思っています。(データシートによると3.6Aまでは充電電流を増やせそうです)

ESP32-CAMをテスト

Aliexpressで見つけた格安カメラモジュールのESP32-CAMを入手したので試してみました。OV2640カメラモジュール付きで$7.5という激安っぷりです。

1.ESP-IDFのインストール

まずはファームウェアをビルドするために ESP-IDF をインストールします。
インストールは https://github.com/espressif/esp-idf に沿って行えば難しくありません。(初期のESP8266の頃に比べると随分簡単になったような気がします)

環境変数を設定するため、~/.profile に以下を書き足します。

書き足したら、一旦ログアウトしてログインし直して、作業環境に反映させます。

2.ハードウェアの準備

ハードウェアの情報については、githubに上がっている仕様書を参考にしました。(※ダウンロードできなくなると手も足も出なくなるので同じものを113990580 ESP32-CAM Product Specificationに上げておきます。)

今回は、USBシリアル変換にFT234X使用のこちらを使いました。Linuxだといろいろトラブルが起きるのですが、セルフパワーで動かす分には大丈夫そうなので使ってみます。

ブレッドボード上にこんな感じで組んでみました。
シリアルの接続と、電源の供給(電源は仕様書の記載ではVccではなく5V端子に供給するようです)、それからブートローダモードにするためのIO0端子をGNDに落とす線の5本です。

3.サンプルのビルド

サンプルをビルドしてみます。

で環境設定をします。環境設定が完了したら、IO0端子をGNDに落とした状態でリセットボタンを押してブートローダモードに入ります。
※ウラ面なので、ブレッドボードに設置した状態だと大変です。リセットを押した瞬間に白色LEDが一瞬つくので、リセットを押せたかどうかは確認できます。

このとき、

としてシリアルをモニタしておくと、以下の表示が出ますのでダウンロード待機状態であることが確認できます。

screen コマンドを終了してから、

でビルドと書き込みを行います。完了したら、IO0のプルダウンを外してリセットするとシリアルに115200bps N81で以下のように繰り返し出力されます。

ということで、Hello world!を出力後、再起動を繰り返します。

4.カメラにブラウザでアクセス

以下のサイトを参考にして行いました。(参考というか、Windows環境かLinux環境かの違い程度で概ねそのまんまですが)
https://robotzero.one/esp32-camera-module/

顔認識のサンプルをgitから引っ張ってきます。

この中のCamera Web Server Exampleを動かしてみます

以下の項目を設定して保存します。

保存したら、ビルド&書き込みです。

しかし、ここで

というエラーが発生してしまいました。
ぐぐると、esp-idfが古そうな感じです。しかし、

としても更新してもダメでした。でも、よくみるとesp-whoディレクトリの下に、esp-idfが丸ごと含まれているっぽいです。ですので、こちらを IDF_PATH に設定して試してみます。

ということで、python絡みで何か文句を言っています。結局は pip がないために依存関係が満たせていないようです。

としてpipと必要なものをインストールした後、

で無事にビルド&書き込みができました。

しかし、書き込んでIO0のプルダウンを外してリセットしてもSSIDが見えません。

で見てみると、

ということで、Wi-Fiの初期化のところでBrownout Detectでリブートを繰り返しています。

PCから長いUSBケーブルで給電とシリアルコンソール確認を兼ねているので、電源のインピーダンスが高いことは確かです。そこで、1000uFのコンデンサをVcc-GND間に追加したところ、Webサーバの起動まで進むようになりましたが、スマートフォンを帰属させるとやはりリブートしてしまいます。そこで、短いケーブルでACアダプタから直接給電したところ、192.168.4.1にブラウザでアクセスすると設定画面が表示され、Get stillでカメラ画像も取得できるところまで行きました。
しかし、それでも動作が不安定です。FT234Xのシリアル変換モジュールには100mAのポリスイッチが入っているので、こいつが悪さをしているのか、あるいはまだ電源のインピーダンスが高いのかわかりませんが、今日はここまでとします。今後、レスポンスがどのくらいなのか、確認はしてみたいと思います。

#どのくらいのパフォーマンスか見たいだけなので、もう少し試してみたら、積みボードになりそう。

TTGO T-Cameraを開封レビュー

Twitterで見かけたESP32 WROVERとセンサー色々搭載のTTGO T-Cameraを購入してみました。(⇒Aliexpressのページ

ESP32 WROVERにカメラ、人感センサ、温度・湿度・気圧センサなどのセンサ、0.96インチのOLEDディスプレイ、I2Cでの外部拡張端子がついて、魚眼レンズタイプで17.6ドル(今はさらに下がって16.5ドル)で入手できる上に、githubでArduino環境のソースコードまで手に入ります。

梱包は比較的簡易なものでしたが、このようなポリプロピレン製のケースに入っているので、潰れて送られてくる、ということはなさそうです。

ポリプロピレンケースの中に入っていた製品はこのように帯電防止の袋に入れられて密封されていました。

開封するとこんな感じで、電池を接続するためのケーブルも添付されていました。ここにLiPoをつないで充電ができるといいのですが、そこまではまだ調べていません。

裏面はこんな感じです。

MicroUSBの端子がついているので早速適当なUSBの電源アダプタにつないでみると、こんな画面で崩れて表示されてしまいました。

この状態でも無線APとして動作していて、スマートフォンで接続でき、ブラウザで 2.2.2.1 に接続するとカメラ画像の取得などができました。

電源をPCから取ると、このように正常に表示されました。ACアダプタやモバイルバッテリーは軽負荷時にノイズが大きいので、その影響だったのだと思います。
しかし、温度表示が39.61℃と異常な値が表示されています。カメラ右下についているのがBME280だと思いますが、ESP32の自己発熱でかなり温度が上がってしまうのでしょうか??
温度がおかしいと、気圧や湿度も補正できないはずなので、残念です。

・・・と思ったら、バージョンアップ(?)により役に立たないBME280は削除されているようです。

ま、とりあえずおもちゃ入手レポートでした。(なんかおもちゃばっかりですが・・)

追伸

IPS液晶搭載の後継モデルが出ていました。人感センサとスイッチがなくなっているようですが、カラー液晶、MicroSDカードスロット搭載、BME280復活となっています。スイッチが残っていればUIとかも付けられるかな?と思うのですが、スイッチ無しなので用途がいまいち思いつかないところです。(バッテリー駆動するなら不要なときは液晶をOFFにしたいですし)

MKRVIDOR4000_graphicsの中身を見てみる

Quartus Prime LiteでMKRVIDOR4000_graphicsの中身を見てみます。

projectディレクトリの中にMKRVIDOR4000_graphics_lite.qpfがあるので、これをQuartus Prime Liteで開いてみます。

左の方のProject Navigatorのところでソースツリーっぽいところ(Entity)が見えて、ここに MKRVIDOR4000_graphics_top があるので、これをクリックすると、そのソースコードが開きました。トップレベルモジュールの verilog ソースコードのようです。端子の定義と信号の定義、出力バッファ近傍のセレクタなどがあるようです。

Project NavigatorでIP Componentsを選択し、EntityのところでMKRVIDOR4000_graphics_lite_sysをダブルクリックすると、Platform Designerが開いてIPマクロ間の接続の全体像が少しわかります。nios CPUのメモリマップもここで確認することができて、niosの命令バスはオンチップメモリとQSPIフラッシュメモリからフェッチできるようになっているようです。(SDRAM ARBITERとsdramのところを編集するとSDRAMからのアクセスもできるように修正できるっぽい雰囲気です)

上の方の再生ボタンみたいな Start Compilation をクリックすると論理合成して、配置配線、タイミング解析をしてくれます。Task のパネルに進捗が表示されて、完了すると、Entityのところに各モジュールの構造がツリー状に表示されました。このあたりをもう少し見ていくといろいろわかりそうです。

一方で、VidorBitstream-releaseディレクトリの下にipというディレクトリがあり、ここにIPコアのコードが入っているようです。各モジュールの softcore というディレクトリの下にFPGA側のniosのコードが入っています。graphicsの描画処理は ip/GFX/softcore/src/gfx.c というソースの中の gfxRpc() の中で受け取ったリモートプロシージャコールのパラメータに応じて描画関数を呼び出していました。

また、VidorBitstream-release/project/MKDVIDOR4000_graphics/build/software/launcher_lite_bspの下にsummary.html というファイルがあり、これがnios側の諸情報のようです。この中にLinkerのSectionに関する情報があり、nios側のコードもデータもbssもheapもオンチップメモリ上に配置されているようです。また、mem_init.mk というファイルによるとリセットベクターも 0x00a00000 となっているようで、これはメモリマップによればやはりオンチップメモリのようです。nios上のコードはniosとは関係なくオンチップメモリ上に転送しているのかもしれません。(FPGAのコンフィギュレーション時に書き込まれるんでしょうかね??)

まだまだ弄るといろいろわかりそうですが、時間もかかりそうです。

VidorBitstreamがビルドできるようになりました

MKRVIDOR4000_graphicsのサンプルスケッチが中途半端に表示がされる原因についてもわかりました。

中途半端に表示がされるのは、サンプルスケッチ VidorDrawLogo の冒頭にある

のFPGA側での処理が遅いことと、初期化時にそもそも白で全面クリアされていること、ARM側の処理でFPGA側の処理完了を待っていてもタイムアウトするほど遅いことが原因です。初期化時にそもそも白で全面クリアされているので、その上に処理の遅いfillRect()が同色で描画されても、画面上は何も見えません。fillRect()の処理が終わった後に描画要求が飛んでくる部分だけが見える、というわけです。

その証拠に、

と色を変えてやると、ちょっとずつ青く塗っていく処理と、その後で一部の文字が描画されるのがわかります。

というわけで、fillRect()の部分をコメントアウトすることで無事に表示されるようになりました。

まとめ

Linux Mint 19.1 上の Quartus Prime Lite Edition 18.1で MKR Vidor 4000 のFPGAのコードをビルドする場合は以下の点に注意。

  1. apply_quartus_patches.shでパッチを当てる際には、arduino_generic_quad_spi_controller2_sw.tcl に対するパッチ適用は失敗するので、手動で適用すべし。
  2. スケッチサンプルの冒頭のfillRect()はコメントアウトすべし(もしくは、色を変えた上で、Arduinoライブラリの中の VidorMailbox.cpp の冒頭のMB_TIMEOUTを大きく伸ばすべし)

おまけ

Arduino側(ARM側)のライブラリを見ていてARM側からは以下のようにFPGA側にリクエストが伝わるようです。

Vidor_GFX.cpp ⇒ VidorMailbox.cpp ⇒ VidorJTAG.cpp ⇒ jtag_host.cpp ⇒ JTAG信号線

グラフックスの関数はリモートプロシージャコール(rpc)のパラメータの配列(uint32_tの配列)に変換されて、VidorMailbox.sendCommand() が呼び出されます。パラメータはVidorJTAG.writeBuffer()の引数として渡されますが、最終的には jtag_host.cpp で1ビットずつJTAG信号としてFPGA側へ転送されます。すべてソフトウェアでJTAG信号を生成しているようなので、コマンドの転送自体が遅そうです。Mailboxへのコマンド送信後の応答待ち時間は VidorMailbox.cpp の冒頭の MB_TIMEOUT で定義されていて、5000ms=5秒になっているようです。
FPGA側の処理については調べていないのでこれからです。

VidorBitstreamがビルドできない原因を探ってみました

気を取り直して、MKRVIDOR4000_graphicsがビルドできない原因を考えてみます。

まずは改めてビルドして気になるところを洗い出してみます。

途中で

というところがあって、arduino_generic_quad_spi_controller2が絡んで致命的にだめな感じです。

~/intelFPGA_lite/18.1/ip/altera/pgm/arduino_generic_qpsi_controller2 の下でリジェクトされたパッチが2つあったのですが、そのうちの対象の一つが arduino_generic_quad_spi_controller2_sw.tcl というファイル名なので、何か関連がありそうです。リジェクトされたパッチ arduino_generic_quad_spi_controller2_sw.tcl.rej を見てみます。

この中に、

というようなところがあるので、なんか関連はありそうです。arduino_generic_quad_spi_controller2_sw.tcl の中をみても、なぜリジェクトされたのかイマイチよくわかりません(適用されても良さそうな気がする)が、とにかく手動で適用してみます。(追記: 要は、arduino_generic_quad_spi_controller2_sw.tcl というファイルの中の16行目からの10行くらいと、50行目からの11行くらいのところにある「altera_generic_quad_spi_controller2」を「arduino_generic_quad_spi_controller2」に書き換える、ということです。)

もう一つのarduino_generic_qspi_controller2_hw.tclに対して1箇所失敗している方はかなり雰囲気が違うので、まずはこのまま再トライしてみることにしてみます。

ということで、当該箇所では特にエラーなく完了しました。

・・・ということで試してみると、

4:3サイズで全面白になった後、しばらく経ってからこんな表示に。
まあ、全く動いてないわけではないので、だいぶ進歩しました^^;

VidorBitstreamをビルドしてみる

Arduino MKR VIDOR 4000のFPGA部分については、githubのvidor-librariesにいくつかサンプルがあるようです。この中の、VidorBitstreamが詳しそうな感じなのでVidorBitstreamのReadmeを読みながら作業してみます。

冒頭の部分は要約すると、「対象はFPGA開発プロセスに慣れたユーザーである」「FPGAのネイティブ開発はサポートは難しいので限定的」ということみたいです。

ディレクトリ構成は以下の通りのようです。

  • IP IPブロックのソースコード。
  • projects 各ボード用のサンプルプロジェクト。
  • constraints 各ボード用の制約ファイル。ピン配置とタイミング制約を含む。
  • TOOLS FPGAイメージを生成するためのスクリプトとツール
  • distrib コンパイル中にツールチェーンによって作成されたディレクトリ。プロジェクトをコンパイルすることによって作成されたArduinoライブラリが含まれている。

リポジトリのダウンロードと展開

まずはリポジトリをダウンロードして展開します。まず、VidorBitstreamをZIPでダウンロード。ダウンロードしたVidorBitstream-release.zipを~/intelFPGA_liteディレクトリの下に移動し、ここに展開しました。

NIOS II Command Shellの起動

NIOS II Command Shellを開いてシェルスクリプトを起動する必要がある、ということなのですが、Windows版はStartメニュー内にあるようですが、Linux版はnios2edsディレクトリ内にあるようなので、

として起動します。プロンプトは一切変わらないようなので、要注意かもしれません。
(Windows版はCygwinが起動するようですが)

QuartusのIPにパッチ適用

次に、QuartusのIPにパッチをあてます。

うーん、~/interlFPGA_line/18.1/ip/altera/pgm の下のファイルでいくつかパッチ当てに失敗してしまったようですが、このまま進めてみます。

makeCompositeBinaryのコンパイル

make_composite_binary.goをコンパイルするためにはgoが必要ですのでインストールします。

引き続いて、コンパイルします。

TOOLS/scriptsディレクトリにパスを通す、ということなのですが、どうするか考えた挙句、NIOS II Command Shellの実体であるintelFPGA_lite/18.1/nios2eds/nios2_command_shell.sh を修正して、

を179行目付近(env_var_prepend が unset される前あたり)に1行追加して対応しました。

VidorGraphicsのリポジトリダウンロードと展開

VidorGraphicsのリポジトリをZIPでダウンロードして、ダウンロードしたVidorGraphics-release.zipを~/intelFPGA_liteディレクトリの下に移動し、ここに展開しました。

VidorGraphicsのビルド

展開した VidorGraphics-release をビルドしようとしたのですが、 projects ディレクトリがありません。実際には VidorBitstream-release/project の下に、MKRVIDOR4000_graphics ディレクトリがありました。なので、先のリポジトリダウンロードも意味がなかったことになります。

で、結局、別のシェルを起動して、ビルドにトライします。

ということで、11分くらいで一応正常終了したようです。ちなみに使用したPCのスペックは、

  • Intel(R) Core(TM) i3-3220T CPU @ 2.80GHz
    (CPUファンはCeleron G530のものの方が大型で冷えそうなのでそちらを使用。実際TDPもG530の方が大きい。)
  • マザーボード ASRock H61M-ITX
  • メモリ 8GB
  • SSD Crucial CT120M500SSD1(120GB)
  • OS LinuxMint19.1 MATE 64bit

といったところです。

生成したファイルをArduino IDEに取り込む

ビルドに成功すると、VidorBitstream-release ディレクトリの下に distrib というディレクトリができて、更にその下に MKRVIDOR4000_graphics ディレクトリができていました。このディレクトリをZIPで圧縮して、MKRVIDOR4000_graphics.zip を作成します。

Arduino IDEで「スケッチ」→「ライブラリをインクルード」→「ZIP形式のライブラリをインストール」で ~/intelFPGA_lite/VidorBitstream-release/distrib/MKRVIDOR4000_graphics.zip を指定してインストールします。すると、 ~/Arduino/libraries の下に展開して取り込まれました。スケッチ例にもカスタムライブラリのスケッチ例として取り込まれました。

同様に、MKRVIDOR4000_peripheralsでもビルドしてみました。

distribの下の MKRVIDOR4000_peripherals ディレクトリをそのまま~/Arduino/libraries の下にコピーしてもライブラリとして認識されるようです。

生成したものを動かしてみる

Arduino IDE上でカスタムライブラリのスケッチ例を動かしてみました。

  • そもそも書き込みにめったに成功しない・・・・
    ⇒ HDMIケーブルを刺していると、そもそもリセットがなかなか掛からない。
  • HDMIケーブルを抜いてから書き込んでみる
    ⇒ VidorDrawLogoは全く動いてない・・・。VidorEncoderも動いている気がしない・・・。うーん。パッチ当てに失敗しているあたりが関係しているのだろうか・・??

なんか、ARM側とFPGA側の通信が全くうまく行ってない気がする。とりあえず、また明日・・・orz

Quartus Prime Lite と ModelSim Starter をインストール

昨日ダウンロードした Quartus Prime Lite Edition と ModelSim Start Edition をインストールします。といっても、やり方がわからなかったので、適当です。^^;
OSはもちろんLinuxMint19.1 MATE edition 64bitです。

ホームディレクトリにダウンロードした以下のファイルをおいてあります。

  • ModelSimSetup-18.1.0.625-linux.run
  • Quartus-lite-18.1.0.625-linux.tar
  • QuartusLiteSetup-18.1.0.625-linux.run
  • cyclone10lp-18.1.0.625.qdz

この状態で実行属性をつけて、動かしてみました。

すると、ウィザードが立ち上がり、何も考えずに勧めていくと、途中でダウンロードしたファイルをすべて検出した状態でインストールするソフトウェアをすべて表示してくれました。

さらに進めていくと、

という表示が出て、勝手に起動する模様・・・・に見えましたが、

というエラーを出して止まっていまいました。

として、インストールしたディレクトリを削除して再度トライするも、やっぱりだめ。今度は、

を実行してから、再度インストールしたディレクトリを削除してトライ。今度は

という画面が出て、フル機能版のライセンスを買うか聞いてきます。趣味・勉強の範囲なので、そんな余裕もないので、真ん中を選んで実行してみます。

という感じで、Quartus Prime Lite Edition が無事に起動しました。

しかし、デスクトップにショートカットは生成されませんでしたので、デスクトップを右クリックして「ランチャの生成」で手動でランチャを作っておきます。

  • 名前は「Quartus Prime Lite Edition」
  • コマンドは「/home/(ユーザー名)/intelFPGA_lite/18.1/quartus/bin/quartus」
  • アイコンは「intelFPGA_lite/18.1/quartus/adm/quartusii.png」

として作成しておきます。作成したものをダブルクリックすると起動することを確認しておきます。

さらに、こちらの情報によるとModelSimを動かすには、32bit用のライブラリが要るらしいので以下の手順でインストールしておきます。

MicroHDMI-HDMIケーブルを入手

昨日ポチったHDMIケーブルは無事に届きました。

こちらの記事を参考に、ブートローダの更新、VidorGraphicsライブラリの追加、スケッチ例のVidorLogoDrawの書き込みを行ったところ、接続してあるHDMIディスプレイに無事に表示がされました。

インテルFPGAプログラムに登録して、インテル® Quartus® Prime 開発ソフトウェア・ライト・エディション(ライセンス不要、無償)をダウンロードします。自分は(相変わらず)Linux版をダウンロードしました。tarアーカイブで6.2GBという巨大なものです。4MB/s程度しか出ず、時間がかかります。

ここで待っている間にシミュレータについて調べます。昔からModelSimの規模と性能の限定版があるはずなので・・・と思ったら、「ModelSim* – Intel® FPGA Starter Edition ソフトウェア」というのがあって、無償で10000ラインまでというものがあるのですが、なんとWindows版しかありません。・・・と思ったら、いろいろリンクを辿っていたら、Linux版にたどり着きました。ダウンロードページの「個別ファイル」の中にあるようです。この中から、とりあえず

  • Quartus Prime (includes Nios II EDS)
  • ModelSim-Intel FPGA Edition (includes Starter Edition)
  • Cyclone 10 LP device support

のダウンロードも仕掛けて今日は寝ます。

Arduino MKR VIDOR 4000を入手

FPGAが載っているArduinoがあるのをTwitterで知って、ついポチってしまいました。アメリカからドイツ経由で2週間強、ようやく届きました。

届いたら、箱がやや潰れてました(泣)。中身は帯電防止袋なしで、帯電防止スポンジに刺さった状態のArduino MKR VIDOR 4000がゴロッと入ってました。幸い、外観上の異常はなさそうです。

で、使い方を調べていたら、HDMIケーブルはMini HDMIじゃなくて、Micro HDMIが必要なことが判明。早速アマゾンでポチりました。

搭載しているチップは、

  • CPU Atmel ATSAMD21
  • FPGA Intel Cyclone10 10CL016YU256C8G
  • DRAM Alliance Memory AS4C4M16SA-7BCN
  • FLASH Winbond 25Q16DVN1G

のようです。CycloneがALTERAのロゴでなくなっているのは時代を感じさせられるのと、Allianceのメモリは昔痛い目にあったので大丈夫なのか不安です(笑)。

しかし、もうチップの刻印が見えない見えない(涙)。ルーペで必死に見ました。

このルーペは40年ほど前に父がドイツに出張した際に買ってきてくれたお土産です。残念ながら、自分が小さい頃だったので、こんなものに頼らなくても小さな文字までバッチリ見えたので扱いを雑にしていたため、レンズの中央部分に細かい傷がたくさんできていて、かなり見辛くなってしまっています。

レンズをよく見ると、ESCHENBACH W-GERMANY という刻印が見えます。W-GERMANYは西ドイツ製ということだと思います。(当時はまだ西ドイツと東ドイツに分かれていて、ベルリンの壁もあった時代です)

で、ESCHENBACHって何かと調べたら、メーカーの名前(ブランド)のようで、実は同じ(に見える)モデルが今では国内でも買えるようです。