分類: 未分類

電池電容量測試

2021 年 8 月 25 日2021 年 8 月 25 日日落尚無留言

朋友認為 3 號、4 號鋰電池應該會因為內建電力管理電路，而使得電容量比一般電池小。雖然還記得一點高中基礎電學，手邊沒有工具也是白忙，好在星夜如雨推薦了現有的電容量測試模組 ZB2L3，可以同時偵測電流並觀察電壓來計算電容量。

因為要持續放電至電壓低於工作電壓才能視為一次完整的放電，測試很花時間，我這邊只針對之前買的 OXOPO 1.5V 充電鋰電池進行測試。

OXOPO – 3 號充電鋰電池

額定電容 1500 mAh
測試環境
- 使用 ZB2L3 模組
- 電阻 5 Ω (放電時電流約為 0.2 A)
- 測試模組的最低工作電壓設定為 1.4V (第一次設定 1.0V 不曉得為什麼噴了 Orz)

圖 1：執行測試當下，點此放大 (快門開太快，沒抓到顯示的是電壓、電流還是 Ah)

測試過程蠻有趣的：

電壓在前半小時都非常穩定的維持在 1.5V (± 0.02V)，只有在最後似乎由保護電路直接切斷供電 (沒有每秒都盯著看，沒看到最後的供電電壓)
電壓在開始供電後大概僅下降了約 0.03V，然後電壓就維持不再變動
最後一眼看到的電容量約 1700 mAh

個人對結果覺得很滿意，因為需要得特性就是電壓可以在 1.5V – 1.4V 穩定供電。

這邊補一張對傳統鎳氫充電電池的測試過程。

被我拿出來比較的，是平常裝在相機外接閃光燈充電的 eneloop 電池，算是相同產品中相對耐操的一款品牌，但電池充滿電後，最高的工作電壓就是 1.2V，這對部分供電穩定度較高的電子產品會有影響，甚至有些產品乾脆自己內建鋰電池。

這次發現 OXOPO 家的鋰電池，算我運氣不錯，接下來就看之後會不會被我玩到爆炸了 XD

分享, 生活雜記

SQL Server 行行好

2021 年 8 月 19 日2021 年 8 月 19 日日落尚無留言

拜託跟我說一下這樣是正確還是錯誤，難不成要我通靈嗎？？？

MSSQL

MySQL 透過 LOAD DATA 塞資料

2021 年 8 月 16 日2021 年 8 月 16 日日落尚無留言

若有文字檔等大檔案，寫 parser 再建立 insert into 的語法來塞資料速度不算快。簡單格式的檔案 (如一行一筆資料或 comma 分隔等) 可以透過 LOAD DATA 來將資料塞進 table 中。

LOAD DATA 需要特殊權限，請先檢查 my.cnf 檔案中是否已允許該語法：

[mysql]

# enable LOAD FILE syntax
local-infile = 1

再來是檔案內容，這邊的範例是一行一筆資料：

alice
bob
cell
......

確定資料格式以後，建立一個暫時的 table 供匯入使用：

CREATE TABLE tmp (
  str varchar(50)
);

注意，匯入速度要快的話，臨時的 table 不要設定任何 trigger、primary key、index 等，不然會有大量的 disk I/O 拖慢速度。

最後就是下指令來將檔案中的內容匯入資料庫中：

LOAD DATA LOCAL INFILE '/path/to/file/simple-data.txt' into table tmp;

資料都匯入臨時的 table，就可以使用 INSERT INTO … SELECT 語法來將資料拉進正式環境了：

INSERT INTO words (`word`) 
  SELECT (`str`) FROM tmp

MySQL

OXOPO 1.5v 充電鋰電池

2021 年 8 月 9 日2021 年 8 月 9 日日落尚無留言

因為身邊有不少電子產品、遙控器等器材，所以在 10 年前就開始使用鎳氫充電電池。但使用充電電池比較頭大的，應該就是鎳氫電池的供電電壓在 1.2V 而已，因此充滿電的電池相較於鹼性電池的 1.5V 電壓算是偏低，甚至部份器材會直接說電池電量偏低。

這幾天在找東西的時候，無意間發現台灣廠商做出了 1.5V 的 3 號、4 號鋰電池，可以讓電壓維持在 1.5V 左右，並且有過度放電保護，會在電池用盡之前自動斷電。而 OXOPO 家則是使用鋰電池的一些特性，取代原有 3 號、4 號電池的電池。

More “OXOPO 1.5v 充電鋰電池” »

生活雜記

產生短網址的 string ID

2021 年 8 月 6 日2021 年 8 月 13 日日落尚無留言

在約 15 年前有嘗試想要自己做一個縮網址服務 (現在我做加長網址服務 XD)，當時用來產生 string ID 的方法有弱點，被學弟抓出來打爆 (可以被預測下一個產生出來的 ID，然後建立 unliminted redirection)。最近摸到 crunch 這個工具，在重新思考以後，終於搞清楚向 ppt.cc 請教時得到的說明是什麼意思。

先說明有問題的作法，先建立 valid characters list，URL 有部份特出字元是 reserve character (RFC3986)，所以像是 ?、=、@ 等字元有特殊用途不能被拿來當作參數傳遞，然後做「N 進位」轉成 string ID：

<?php

$char = ['a', 'b', 'c', '.....', '7', '8', '9', '0'];

例如：數字是 1 時，產生出來的 ID 是 a、數字是 116 時產生出來的 ID 是 a1。當時我是依照流水號，所以 ID 是可以被預測的，導致弱點被利用。

當時得到 ptt.cc 的回覆是「先產生完 key 再隨機選取可用的 key」。

這陣子才搞懂這個說明，先用 crunch 之類的工具把所有可用的 string 都先產生出來，然後需要時再隨機選取一個 string 來當作 key/ID 使用。這個作法有些優點：

不需要先產生所有的 key，因為大概可以推算出大概可用的 ID 數量
隨機挑選 key 就無法被猜到未來會被用到的 key，不容易被攻擊

接下來要傷腦筋的，大概就是怎麼樣有效率的從 DB 隨機取 key 了。

ps. 目前使用 3 個 digits，大概就有 20 多萬個 unique string 可用了，爽。

資訊學習