2023.06.30
2023.06.29
2022年度決算
2022年度決算の決算を提出しました。
結果は大赤字!!!
半導体不足でCosmo-ZやArtix基板が作れなかったし、Trenz製品も全然入ってこない。
事業再構築補助金に採択されて半導体真贋検査装置を作ったら、なぜか4月ごろから半導体の在庫が復活している!?
まぁ、仕方ないですね・・・
スーパー大赤字なのに生き延びていられるのは信金さんの融資があるからです。
これで決算が終わったわけではなく、いろいろ精査して来週中には正確な決算を出したいと思います。大赤字なのは変わらないと思います。
来年度は気を引き締めていきますよ。
2023.06.28
決算とか事業再構築補助金の交付申請とか
決算のための帳票を整理したりとか、事業再構築補助金の交付申請とかをしていました。
第六回の事業再構築補助金なので、そろそろ交付申請をしないとマジでヤバい(2カ月かかるとして9月に結果が出る=2カ月で実行しなければならない)のですが、全然進んでいません。
なぜ、事業再構築補助金の交付申請にこんなに時間がかかっているかというと、自社で研究開発して新しい機械を作って新規事業を行うということをするからなんですね。
新装置が完成させて、その新装置を自社に販売して機械設備の資産としなければならないので、完成させないと見積ができないんです。
事業再構築補助金って、基本的にはいろんな機械や設備を買って宣伝して新しい事業に転換するという補助金なので、私のように研究開発してということには向きません。
2023.06.27
2023.06.24
RTLを語る会に参加してきました
今日はRTLを語る会というのに参加して、EfinixのJTAG書き込みについて発表してきました。
興味があったのは、他社のPCI ExpressボードなどでXILNIXのGTXを使うやつが、話を総合すると10GbpsのIBERTどころか数GBpsでも通らないそうだということです。
なぜでしょうね。そんなに品質が悪いのでしょうか。
Cosmo-Kはいままで一度も10GbpsのIBERTが通らなかったことはありません。それどころか、10GbpsとSFP+でやっても50%くらいアイが開いていますから、数Gbpsでダメになる基板というのが信じられません。
2023.06.23
1000BASE-Tがノイズの原因となっていた
ZYNQのADC/DACボードを2台作ったのですが、そのうちの1台で、正弦波発生器につなぐと、広帯域のノイズが出るので悩んできました。
どうやらLANケーブルを挿したときにノイズが乗って、無線LANで接続すればノイズが乗らないということに気が付きました。
さらに検証していくと、1000BASE-Tでつなぐとノイズが乗って100BASE-TxのHUBにつなぐとノイズがでないようです。
原因は、1000BASE-Tのコネクタの向きを間違えてジャンパで修正したところの配線が数本切れていたことでした。
原因を取り除いたら謎のノイズはすべて消えました。
ギガビットイーサは差動だから配線の1本や2本が切れても通信できてしまうようで、切れた配線がノイズ源になってADCにノイズとして混入したようです。
2023.06.22
Cosmo-Z Mini2のDACの歪率は!?
開発中のZYNQ+ADC/DACボード「Cosmo-Z Mini2」には14bit 125MHzのDACも乗っています。
かなり工夫した回路なのでどのくらいの歪率が達成できるか楽しみにしていたのですが、まさかの-67dB。こんなはずはない・・・最低でも-80近くはいくはずなのに・・・
旧Cosmo-Z MiniやDAC8といったボードを出してきて測定してみると、以前のボードは-80dB行っている。どうして新開発のこのボードは-67なのだろうか。。。
徹底的に回路を見比べてみても間違ったことはない。部品表をみると・・アッー!
回路図と部品表のコンデンサの容量が違っていて、間違いのある回路図からコピペしてきたから間違いのある回路ができていたのか。
早速部品を取り換えてみると、歪率-85dB達成。つるっつるの正弦波が出ました。
ああよかった。
2台作ったうちのもう1台では-92dB達成です。
ああよかった。
2023.06.17
新しいZYNQボードでLinuxが起動するまでに苦労したこと
新しく作ったZYNQのボードでLinuxを起動させて、GigabitEtherと、USBまで認識するようになりました。
オリジナルボード向けのLinux構築のための基本的な手順はこの同人誌「ZYNQで実用的なシステムを構築するための本」に書いたとおりなのですが、今回は最新版のU-boot 2023.1を使ってみることにしたので、結構ハマりました。
まず、この基板ではUART0ではなくUART1を使っています。そのため、過去に作ったFSBLやU-Bootをそのまま動かそうとしてもコンソールに文字が出てきません。コンソールから文字を出すだけのために全部作り直すことになったのですが、ダウンロードしたU-Boot 2023.1はいろいろ変わっていて、findしたりfgrepしたりでカーネルのソースを大冒険でした。
新U-BOOTではGigabitEther PHYを認識するためのデバイスツリーの書き方が変わっていて後方互換性がありません。
&gem0 {
status = "okay";
phy-mode = "rgmii-id";
phy-handle = <ðernet_phy>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gem0_default>;
ethernet_phy: ethernet-phy@7 {
reg = <7>;
compatible = "ethernet-phy-id0022.1641";
};
};
使用しているGbEのPHYはMicrelのKSZ9131RNXなのですが、以前と違って、compatible = "ethernet-phy-id0022.1641";のようにcompatibleにベンダIDとデバイスIDまで書かなければならなくなりました。
ぶっちゃけU-BootがGbEを認識しなくてもLinuxで認識すればよいので、ここにこだわらなくてもよいのですが、U-Bootの起動時にGigabitEtherがnot foundとか言われると嫌じゃないですか?pinctrlを書く必要があるのかどうかはわかりません。
USBにはUSB3317とLAN9514を使っていますが、これはRESETを一瞬Lにするパルスを与えないとだめなようです。USBのRESET端子をPLから操作できるようにしておいて命拾いをしました。
あと、U-BOOT 2023.1ではuEnv.txtではなくboot.scrになりました。このboot.scrの作り方が毎回毎回謎なんですよね。
fatload mmc 0 0x03000000 uImage && fatload mmc 0 0x02A00000 devicetree.dtb && bootm 0x03000000 - 0x02A00000
というテキストファイルを作ってboot.txtという名前で保存しておいて、
mkimage -A arm -O linux -T script -C none -a 0 -e 0 -d boot.txt boot.scr
で生成できるはずです。従来、uEnv.txtを書けばZYNQ Linuxは起動したのですが、U-Boot 2023.1ではboot.scrが必須になっていました。(おそらくもっと前から必須になっていた)
uEnv.txtは環境変数を定義するだけのファイルであったのに対し、boot.scrはコマンドを実行するので、例えばNANDフラッシュからブートしてだめだったらSDカードを読み入って、それでも最後にネットワークブートする、というようなコマンドが書けます。そんな機能私はいらないんですけどね。
ZYNQのPSの設定を変えたとき、その設定を反映させるのは論理合成して.bitを作ることではありません。PSを変えたら、export hardwareしてxsaファイルを作り、Vitisでハードウェア情報をアップデートしてFSBLを作り直さなければなりません。
そのやり方ですが、VivadoでFile→Export Hardwareをしたら、Vitisでプラットフォームプロジェクト(緑のアイコン)を右クリックし、Update Hardware Specificationを実行します。
XSAファイルを開くダイアログが出るので、Vitisで生成したXSAを指定します。
これでアップデートがされるので、最後にFSBLのビルドボタンを忘れずに押します。
そうしてfsbl.elfが出来たら再びboot.binに固めて完成です。
最も苦労したのは、Linuxが起動したときにmmc0blkp2をマウントできなくてカーネルパニックする件です。
[ 1.779581] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -30
このようなエラーが最初に出て、最後には
[ 1.779581] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -30
[ 1.787646] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[ 1.790999] Please append a correct "root=" boot option; here are the available partitions:
[ 1.802611] 0100 16384 ram0
[ 1.802625] (driver?)
[ 1.808715] 0101 16384 ram1
[ 1.808725] (driver?)
[ 1.814862] 0102 16384 ram2
[ 1.814873] (driver?)
[ 1.821003] 0103 16384 ram3
[ 1.821014] (driver?)
[ 1.827108] 0104 16384 ram4
[ 1.827118] (driver?)
[ 1.833271] 0105 16384 ram5
[ 1.833282] (driver?)
[ 1.839372] 0106 16384 ram6
[ 1.839381] (driver?)
[ 1.845502] 0107 16384 ram7
[ 1.845512] (driver?)
[ 1.851628] 0108 16384 ram8
[ 1.851639] (driver?)
[ 1.857748] 0109 16384 ram9
[ 1.857758] (driver?)
[ 1.863869] 010a 16384 ram10
[ 1.863879] (driver?)
[ 1.870056] 010b 16384 ram11
[ 1.870065] (driver?)
[ 1.876254] 010c 16384 ram12
[ 1.876264] (driver?)
[ 1.882465] 010d 16384 ram13
[ 1.882475] (driver?)
[ 1.888648] 010e 16384 ram14
[ 1.888657] (driver?)
[ 1.894847] 010f 16384 ram15
[ 1.894857] (driver?)
[ 1.901059] 1f00 1024 mtdblock0
[ 1.901069] (driver?)
[ 1.907588] 1f01 5120 mtdblock1
[ 1.907597] (driver?)
[ 1.914134] 1f02 128 mtdblock2
[ 1.914145] (driver?)
[ 1.920669] 1f03 6016 mtdblock3
[ 1.920679] (driver?)
[ 1.927215] 1f04 4096 mtdblock4
[ 1.927224] (driver?)
[ 1.933760] b300 30253056 mmcblk0
[ 1.933770] driver: mmcblk
[ 1.940553] b301 307200 mmcblk0p1 58f06737-01
[ 1.940563]
[ 1.947368] b302 29944832 mmcblk0p2 58f06737-02
[ 1.947379]
[ 1.954188] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
[ 1.962628] CPU1: stopping
[ 1.965335] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-xilinx-00211-g528b5fb42f76-dirty #1
[ 1.974125] Hardware name: Xilinx Zynq Platform
[ 1.978656] [<c010cb38>] (unwind_backtrace) from [<c0109060>] (show_stack+0x10/0x14)
[ 1.986426] [<c0109060>] (show_stack) from [<c0ba2ba4>] (dump_stack_lvl+0x40/0x4c)
[ 1.994013] [<c0ba2ba4>] (dump_stack_lvl) from [<c010b1f0>] (do_handle_IPI+0x80/0x140)
[ 2.001945] [<c010b1f0>] (do_handle_IPI) from [<c010b2c4>] (ipi_handler+0x14/0x20)
[ 2.009522] [<c010b2c4>] (ipi_handler) from [<c015be20>] (handle_percpu_devid_irq+0x4c/0xe8)
[ 2.017986] [<c015be20>] (handle_percpu_devid_irq) from [<c0156d04>] (handle_irq_desc+0x24/0x34)
[ 2.026788] [<c0156d04>] (handle_irq_desc) from [<c0157388>] (handle_domain_irq+0x40/0x54)
[ 2.035059] [<c0157388>] (handle_domain_irq) from [<c0390e24>] (gic_handle_irq+0x70/0x80)
[ 2.043254] [<c0390e24>] (gic_handle_irq) from [<c0100afc>] (__irq_svc+0x5c/0x90)
[ 2.050743] Exception stack(0xc1481f08 to 0xc1481f50)
[ 2.055793] 1f00: 00000000 00000000 1da99000 debdd540 c1288be0 00000000
[ 2.063970] 1f20: 74e253fa 74fb46dc 00000000 00000000 debdc878 00000000 fffffff5 c1481f58
[ 2.072143] 1f40: c098c320 c098c344 60000113 ffffffff
[ 2.077184] [<c0100afc>] (__irq_svc) from [<c098c344>] (cpuidle_enter_state+0x17c/0x304)
[ 2.085292] [<c098c344>] (cpuidle_enter_state) from [<c098c508>] (cpuidle_enter+0x28/0x38)
[ 2.093571] [<c098c508>] (cpuidle_enter) from [<c013edb8>] (do_idle+0x248/0x270)
[ 2.100985] [<c013edb8>] (do_idle) from [<c013ef44>] (cpu_startup_entry+0x18/0x1c)
[ 2.108570] [<c013ef44>] (cpu_startup_entry) from [<00101450>] (0x101450)
[ 2.115375] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) ]---
でカーネルクラッシュします。
この原因ですが、PSのSDIOのWPにHを入れっぱなしだったことが原因でした。WPはLにしなければなりません。
他にも、LinuxでUSBを認識させるには、dr_mode = "host";が必要です。
usb@e0002000 {
compatible = "xlnx,zynq-usb-2.20a\0chipidea,usb2";
status = "okay";
clocks = <0x01 0x1c>;
interrupt-parent = <0x04>;
interrupts = <0x00 0x15 0x04>;
reg = <0xe0002000 0x1000>;
phy_type = "ulpi";
dr_mode = "host";
usb-phy = <0x06>;
};
これがないとUSBを認識せず、lsusbで何も出てこなくなります。
最終的にLinuxは起動して、USBもGbEも認識するようになりました。
なんだか他にもいっぱいあった気がしますが、大きなハマりポイントは以上のとおりでした。
2023.06.16
ZYNQのADC/DACボードの火入れ式
ZYNQのADC/DACボードが実装から上がってきました。
早速、おそるおそる電源を投入します。こういうときは、安定化電源を定電流モードにして、徐々に電流を増やしていくといいのです。
とりあえずMITOUJTAGでバウンダリスキャンしてみたらFPGAが見えました!
これが見えるだけですごく安心できます。少なくとも電源のピンの間違いや、火を噴くような大きな間違いはなく、FPGAが活きているという証拠となります。
しかし、起動しない。。。
数時間のデバッグの末、原因がわかりました。
なんと、MIOの設定が間違っていたのです。
以前、特注用に作ったZYNQボードの違った基板の回路図をコピペしてきたので、この基板でも間違ってしまったのです。
↑どこが違うかわかりますか?これだとNANDブートモードになってしまいます。
とりあえずHでなければならない信号をHにするために隣のコンデンサにくっつけました。
これで、適当なSDカードを挿入すると・・・
やった!起動した!
UARTのコンソールはまだ使えないけど、BGAの端子がチカチカと動いて起動したのが見えました。
間違っていた箇所はMIO5をプルダウンしてしまっていたことです。
MIO5がLだとNANDモードになってしまいます。プルダウン抵抗を外しただけだとバウンダリスキャンではHレベルとして認識されるのですが、どうやらそれでは足りないみたいで、ちゃんとプルアップしなければPSはプルアップとして認識してくれないようでした。
おそらく、バウンダリスキャンはPLの機能で、実際に見ているのはPSだから、PSとPLで閾値とか違うんでしょうね。
それから、ZYNQにリセットをかけたとき、ZYNQは起動しようとしてMIO40とかMIO36とかにパルス的なのが出ます。MIO5が中途半端だとMIO40つまり、SDカードのところの信号が出ないのです。これで間違いに気が付くことができました。
MITOUJTAGを使っていなかったらこの間違いを見つけるのに1日以上かかっていたでしょう。
とりあえず、基板が届いた日に基本的な動作確認まで完了です。
動いて本当によかった。
ボードの開発って本当に緊張します。
2023.06.15
2023.06.14
MPSSEなJTAGケーブルを作りました
FTDI社のUSBインタフェースチップにはMPSSEというモードがあり、このモードを使うとJTAGの信号を出すアダプタが簡単に作れます。
ただし、おそらくFTDI社のチップは中で何かのマイコンが動いているのか、電源投入時に端子に変な信号が出たりすることもあります。
そこで、FT2232Hの先にLatticeのCPLDを付けて、電源投入から一定時間は信号を出さないようにブロックしました。またLatticeのCPLDは電圧変換バッファとしては極めて優秀なので、1.2~3.3Vまでの様々な電圧に対応できるJTAGケーブルとなりました。
こういうJTAGケーブルを3台ほど作り、タカチのケースに収めてみました。
なお、これは非売品です。
受託開発でJTAGのソフトウェアを作ったのでその付属品として納品するためのものです。
2023.06.13
2023.06.12
2023.06.11
Cosmo-Z Mini2の基板が届いた
Cosmo-Z Mini2の基板が出来上がりました。
おおー、密度高くてイイ感じ。
と思ったのですが、なんかレジストが薄いような・・・このBGAの部分、大丈夫かな。
顕微鏡で見てみると、レジストはくっきりはっきりしていて非常に立体的です。
シルクが、レジストの凹みにたまってミルクをこぼしたような感じになっています。
パッドの上をシルクが邪魔しているわけではなさそうなのでパッドが狭くなっているわけではないので良いのですが、BGAの下の部分がなんだか不安・・
NSMDといってパッドの周りのレジストをかけないようにして製造する技法なのですが・・
パッド中央にあるビアの端がレジストの端からすこしはみ出ているような気がします。
いままでと同じレジスト開口で作ったはずなのになぁ。
ああ、かなり不安だ
2023.06.10
Cosmo-Z Miniの部品を集める
ここ数日間、3時間睡眠の日々が続いていたので昼過ぎまでぐっすり寝て、会社に行きました。
あ、土日とかそういうの関係ないです。
そして、大量に届いていたDigikeyの箱を開けて部品表どおりに揃っているかチェックしつつ、自社でストックしていた部品を加えていって実装用部品セットを作ります。
Cosmo-Zの不具合調査依頼が来ていたので、調査し、修理。
大量にたまっていたメールに返信したり。
そんなこんなしているうちに1日が終わりました。
ああ、仕事しているときって幸せ。
2023.06.09
2023.06.08
2023.06.07
Cosmo-Z Mini2の製造やらRECONF研の準備で大忙し
今日は忙しい一日でした。
まず未明にCosmo-Z Mini2の部品表を作り、不足している部品をリストアップしてDigikeyに発注。
朝起きたら会社に行って、いろいろメール返信。
昼に大学に行って、今日のミーティングで喋るパワポを作成。
ミーティングが終わったら、実験室に籠って明日のRECONF研の発表で使うためのデータ収集etc.
・・どうしよう、発表原稿がまだ1ページもできていない。
ストーリーを頭で考えるだけにしておいて、前日の夜にホテルで作るかな。
2023.06.06
Cosmo-Z Mini2基板出図後の微修正
基板屋さんからいろいろ確認事項が来ました。
特に多かったのが、USB Type-Cコネクタ、「CX90B1-24P」のL字状の穴の部分です。
このコネクタの寸法図がとにかく鬼畜なのです。
何度読んでもわからない。
そんで、過去にうまくいった基板からコピペしてきたのですが、そのときの基板とFGの扱いが異なっていて、FGの部分のサーマルが今回の基板ではこうなってしまいました。
Type-Cのコネクタは長穴がL字状のなっているのですが、GNDで打ってしまうとサーマルがぐちゃぐちゃに入ってしまう。
問題はないのだけれど気持ち悪い。
そこで、いっそのこと、この部分の内層のGNDを全部抜くことにしました。
USBのコネクタのFGは半田面と部品面だけでつながっていればいいだろうということです。
あと、アルミパネルから鼻先を出すためにコネクタを基板のエッジぎりぎりに移動させたら「欠けるかも」という確認が来ましたが、欠けてもいいと返答しました。
とにかく、この穴はトラブルが多い。
2023.06.05
結局のところ日本のプリント基板屋さんで製造することにしました
新規の基板ですが、結局、大阪にあるプリント基板屋さんで製造することにしました。
とりあえず今出図すれば日曜日には届くので、月曜日から実装開始できそうです。
基板は時間があればいくらでも修正したくなるので、「ビアにシルクが被ってから移動させよう」とか、そういう細かいことを始めると無限に時間を溶かしてしまいます。
今日の主な変更点はディジタル部分にベタパターンをひいたところと、JTAGとEtherの拡張基板を作ったこと。この装置は本体基板上にはXILINX配置のJTAGコネクタを置く余裕はないので、拡張基板から引き出すようになっています。
また、LAN9514といってUSB2.0からUSBホスト4つと100M Etherを出すUSB HUBのICがあるのですが、そのICのLANも使えるようにコネクタ基板を作りました。(メインはGigabitEtherなので、サブLANという位置づけ。2つあればZYNQがルータにもなる。)
ベタパターンを作るとGNDの半島や島ができたりしてアンテナになってしまうので、KEEPOUT属性を付けたパターンの欠片でベタが侵入しないようにして調整していきます。
チェックすればするほど直したい事が増えていくので、どこかで打ち切らなければなりません。
2023.06.04
PCBGOGOへ発注してみたら納期がグダグダだったので注文をキャンセルした
新しい基板をPCBGOGOに発注しました。
金曜日の夜に48時間コースで注文すれば、土曜日・日曜日で製造されて月曜日に出荷されると思っていたのですが、まず勝手に48時間コースから72時間コースに変更されました。
確認のメールが来たのが土曜日ですぐにPaypal経由で入金したのですが、土曜日の朝から72時間ということは火曜日に発送だから水曜日到着でギリギリ届くかなと思っていたのですが、パタリと動く気配がありません。
いつもの担当者がJPCA Showに出展しているからメールの返信が遅れますということらしいのですが、メールの返信だけではなくすべての仕事が遅れているようです。メールが来て10分で返信をしても「不在にしています」の自動メールが返ってきます。
そのメールには6日(火)まで出張と書かれているので、観光でもしているのかもしれません。
PCBGOGOは一度製造が始まってしまえば機械的に進みます。土日も製造は進んでくれるので、営業担当から製造に引き渡すまでの過程がボトルネックです。ここが止まってしまうと、せっかく良い製造設備があっても動きません。如何にここを乗り切るかというのがPCBGOGOに発注する際のテクニックとなります。
今まで何度かPCBGOGOに発注してみたことはあるのですが、納期が守られる確率は50%くらいかなという体感です。
一応、ホームページ上は土日祝日も営業ということになっているのですが、
いろいろな理由で土日の対応は非常に遅いです。営業、つまり製造が始まるまでのやりとりは、本当に気まぐれにしかやっていないという感じです。
で、何度か催促したら昼に確認メールが来ました。
GND層に配線パターンがあるからおかしいというメールでした。
「これは高周波の基板で浮遊容量を減らすために敏感な信号の下のベタを抜いているのだから問題ない。そのまま進めてくれ」という返信をしたのですが、「出張で不在にしています」の自動メール返信が送られてきます。他にも問題のなさそうな軽微な箇所を何個も質問してきます。
あーあ、いらない確認でまた遅れてしまった・・
さて、夜の23時ごろに担当者から返事がありました。
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
いやいやいやいや・・・・・。今まで、営業がGO出したらすぐにスタートしていたでしょう。なんで今日に限って製造データの作成とかいって時間がかかるのよ。
でも、大目に見てあげて製造進捗を確認してみると、やはり0%
そうしているうちに、日曜日の昼になりました。
なんと、24時間も放置されていたのです。
service05@にメールしても、service@にメールしても同じ担当者にしかつながらないので、英語版のservice@pcbgogo.comにメールしたのですが、それでも返事がない。深圳に残っているほかのスタッフが代わりに進めるということはないようです。担当が付いたら変更できないって、ホストクラブか?
スピードが売りの中華基板なのに担当者が返事をできない状態だと待たされてしまうし、それを別のスタッフがカバーするという仕組みにはなっていないようです。
「代わりのスタッフが進めてください」と英語でservice@pcbgogo.comにメールしても、同じ担当者が返事をくれます。
代わりのスタッフが進めるかどうかについては返答なしです。
さて、日曜日の昼というのが72時間だとしてもデッドラインになります。
つまり、48→72時間に変更されたわけですが、土曜日の昼から起算して72時間だと思うのですが、日曜日の昼から起算して72時間だと水曜日発送になってしまいます。「観光していて昼間は返事をしたくないから夜するけど日曜日から急いで48時間で製造すれば72時間なら満たせるんじゃないという意味なのかな・・」と優しく見守っていたのですが、日曜日の昼になっても製造が開始しません。
今までの経験から、製造には48時間かかるので、これだと納期が延びた72時間コースでも間に合わないことになりました。
私は今週の木曜日と金曜日は出社できないので木曜日とかに届いてもどうにもなりません。それなら日本の基板メーカーに出したほうがいいので、キャンセルしたいと思ったのですが、キャンセルのポリシーについてはここに書かれています。
製造前ならキャンセルができるぞ!やった!
しかし、キャンセルを申し出たら製造を始めて、しれっと「出張中につきメールの返信ができませんでした。製造が開始してしまったのでキャンセルできません」とか言われるかもしれません。そして、金曜日ごろに届くという最悪のパターンを想定しています。また、今までは「次回以降使用できるクーポンで返金する」というパターンだったので、クーポンをもらっても仕方がありません。
そこで、支払いに使ったPaypalで「問題の報告」を押して返金を申し込み、それと同時にPCBGOGOにメールでキャンセルの旨を伝えました。掲示板とメールとで
そうしたら、
と、キャンセルを引き受けてくれたようです。
いろいろやり取りしていて、不信感を払拭できないのは、ひとつ一つの理由がどれも嘘っぽいからなのです。
出張で不在にしていますとか、夜分に対応しますとか、製造の手配をしていますとか・・。
まとめると、
- 製造工場は24時間365日動いているはずだが、営業からの製造データがこないと動けない
- 年中無休10:00-19:00と書かれているが、週末はきまぐれ
- 納期が守られないとクーポンで返金する
- 担当者が対応できないときに他のスタッフが担当することはない
- 規約によれば製造前ならキャンセル可能
- キャンセルするならPaypalへ
となります。
この特質をうまく使いこなせればPCBGOGOは良いかもしれません。
次回からはJLCPCBを開拓することにします。
2023.06.02
Cosmo-Z Miniの基板を本出図
昨日の出図後にデータを念入りにチェックしました。
その結果、致命的な間違いがいくつも見つかったので修正しました。
例えば、GigabitEtherのPHY_MDCなどがつながっていないなどです。
そういった接続されていない配線をつないだほかに、違いがわかるでしょうか?
まず、USB Type-Cのコネクタから給電される部分で、MOSFETのスイッチを採用しました。理由はDC5VのACアダプタを使用した場合にUSBをつないでパソコンの電源を落とした場合に電流が漏れるのを防ぐためです。
それから、基板の端に出っ張っていた部品をできるだけ中に押し込めたり、FAN用の電源コネクタを付けたりしました。ZYNQのシステムは基本的に熱いのでFANかヒートシンクが必要ですが、Cosmo-Z Miniの旧来のバージョンではホッカイロ以上に熱くなるので今回はFANを使ってみることにしました。FANはただ電源から5Vを供給するのではなく、MOS FETのスイッチを入れてFPGAからコントロールできるようにしています。
他にも細かい修正をいっぱい行って、ようやく本出図です。
48時間コースなので日曜日か月曜の朝には出来上がるはずです。
月曜日に発送してくれるでしょうか。
2023.06.01
Cosmo-Z Miniの基板設計が完成しました
長い間設計をしてきた基板がようやく完成しました。
ZYNQ搭載の125MHz ADC/DACボードです。
表面はこんな感じ。
裏面はこんな感じです。
とりあえずPCBGOGOに出図してみたところ、以下のような返事が。
--------------------------------------------------------------------------------------
48時間特急:B〇〇〇〇〇について、「加工データ確認」を選択いただいておりますが、
弊社はただ今、JPCAに出展していますので、「加工データ確認」のご送付は夜分に対応し、
納期に影響があると思いますが、大丈夫でしょうか。また、週末の集荷について、
土曜日は1回のみ集荷サービスがあり、日曜日は集荷サービスがありませんので、
製造完了後の基板はもし土曜日の集荷に間に合わないの場合、一旦こちらに預かり、
月曜日に集荷になりますが、予めご了承ください。
--------------------------------------------------------------------------------------
なるほど。日曜日は集荷がないのか。
つまり、日曜日に仕上がる基板も月曜日に仕上がる基板も同じ日に発送されるというわけですね。
納期が遅れる可能性もあるから早くするに越したことはないですね。
最近のコメント