最終更新: 2017-05-16T22:48+0900
NECKER V1 Plus アクションカム/バイク用ドライブレコーダー 日本正規版
DST
¥ 15,980
USB給電を受けると自動で録画を開始する
PCの USBポートに接続したときは、充電はされるけどマスストレージモードになるだけで録画は開始されなかった。アダプタを通してコンセントにつなぐと録画がスタートした。賢いね。
USB給電中でも防水状態が保たれる
防水キャップ一体型の USBケーブルが付属してくる
低画質長時間モードがない
とはいえメモリーカード容量は倍増する一方だし、60fpsは絶対にほしいし、今のところ一番画質とファイルサイズのバランスがとれてると考える 1280x720/60fpsモードはちゃんと用意されてるので、ないものねだりの感はある。32GBのメモリーカードに無限録画するとして、常時ラスト5時間分の動画が残っているか10時間20時間分の動画が残っているかという程度の違い(※目安は1分あたり100MB)。
コマ撮り動画(タイムラプス)モードの最短撮影間隔が8秒
あんまり搭載されていない機能なので用意されてること自体は嬉しいのだけど……。
時速60kmで移動することを考えたら1秒間隔がいいところ。8秒はおろか3秒間隔でもちょっと長い。
NECKER V1Pは SDXCに対応していないので、64GBの microSDXCカードを FAT32でフォーマットした、microSDHCカードもどきを使用する。
落とし穴があって、NECKER V1Pを PCにつないでカードリーダーとして使用した場合、Windows(Vista)はカードが読めないからフォーマットをしろと要求してくる。ここで言われるままフォーマットすると FAT32 32GBのメモリーカードになってしまう。
SDXCに対応したデジカメである DSC-HX30Vをカードリーダーに使って Windowsでフォーマットしようとすると、正当な SDXCカードである exFAT 64GBになってしまう。
DSC-HX30Vを通してカードを PCに接続し、以前(20130917p01)にも使った HP USB Disk Storage Format Toolを起動すると、FAT32 64GBでフォーマットできた。
この 64GBの microSDHCカードもどきに関して
撮影して保存 | USBケーブルで接続して Windowsから読み書き | |
---|---|---|
NECKER V1P | できる | できない |
DSC-HX30V | できる | できる |
カードリーダーとしての NECKER V1Pにはフォーマットや読み書きに際して 32GBより大きい FAT32を取り扱えない制限がある様子。
LEDインジケーターが電源・録画兼用ボタンの前後に1つずつ付いてる。前が青色で、後ろが赤(緑)色。
点灯は定常状態。青点灯で電源がオン。赤点灯で Wi-Fiがオン。緑点灯で充電中。点滅は異常状態。青点滅でバッテリー切れ。赤点滅でメモリーカード異常(不在・満杯)。点滅より間隔の長い間欠点灯は過渡・持続状態。青間欠は録画中。赤間欠は Wi-Fi有効化中。
ここまでは説明書に書かれた表の通り。では緑と
2つしかないインジケーターをフルに使ってながら、色や点灯パターンがだいたい慣例や感覚にそっていてわかりにくくなってない。
UPDATE:N WIFI=0 VCT=2 PDD=0 ;; ----------------------------------------------- ; ;(WIFI) WIFI Turn ON/OFF: 0~1 (0):ON (1):OFF ;(VCT) Video Clip Time: 0~3 (0):Off (1):1min (2):3min (3):5min ;(PDD) Power Down Delay: 0~6 (0):0 S (1):10S (2):30S (3):1min (4):2min (5):3min (6):Disable Power Down
現在のファームウェアは「幸滔數位科技有限公司 - タイムライン」から拾ってきた最新 V15715版(NECKERV1P_FW_0715_1839.zip)。他に 7月 3日の V15316版とか 3月 3日の V150203版を拾ってきた。
アップデート前にはあった Gセンサーだとかタイムラプスモードの設定がなくなってダウングレードしてるみたいな。V150203版に戻すとネットや説明書通りの内容の設定ファイル(SportDV.txt)がカードのルートに作成された。もう一度最新 V15715にアップデートして、ルートにある SportDV.txtを削除したり変更したりすると、上の状態に戻る。アプリで設定しろってことなのかな。以前の設定項目を勝手に SportDV.txtに書き戻すとだいたいは反映されてるんだけど、撮影したタイムラプス動画(TLP_*.MOV)が有効なファイルではない(5MBくらいの固定サイズで真っ暗の映像。撮影ボタンを押したときの反応は一度だけ振動して青色LEDが点灯したままだった)。
たぶん緊急保存ファイル(SOS_*.MOV)を記録してるあいだじゃないかなあ。画面右下の日時表示によると空白の時間帯がある。
もしかしたら本気でしばきすぎて一時的な録画エラーが発生してたということも? でも本当にこけたときよりは弱いだろう。
余計なことはせずに録画を継続してくれた方がちゃんと撮れてる期待が高そうだし、最長でも5分区切りの細切れ録画ファイル(といっても 500MBある。そして FAT32の 1ファイル上限は 4GB)の命名規則が乱れなくて管理がしやすい。
付属していた三脚用の 1/4インチネジと GoPro互換のマウントのネジの両方がコインで回せるようになっていた。
これねえ、苦労するんだよ。ささやかでもあるとないとで大違い。どうしてネジの頭をそのごついつまみに貫通させておかないんだって、以前買った GoPro互換ネジに対して思ったもん。その代わりに栓抜き(The Tool (Thumb Screw Wrench + Bottle Opener))を持ち歩けって?(揶揄するつもりで栓抜きって書いたのに、最初からそういう商品名だったよ。チッ)
USB給電がストップして NECKERがシャットダウンをしてる最中に再度給電を開始してしまうと、そのままでは NECKERが起きてこないとはネットの誰か(といっても日本語では全部で4、5人ぐらいしかブログで取り上げてないんだよね……)が報告していた。その逆に、NECKERが起動してる最中に(これが10秒20秒かかるんだ)給電が切れた場合には、NECKERが起きたままになる(たしか LEDが青点灯だったので録画はスタートしていない)とは今日(11日)確認した。メインスイッチをオンにするのもオフにするのもゆっくり時間をかけるようにしないと、期待通り動いてないことがあるってことだ。信号待ちでキルスイッチをパチパチしてエンジンを切って、結構待ちそうだなとメインスイッチをオフオンしてヘッドライトを切ることがよくあるんだけど、それをすると録画が終了したままになるってことだ。
<追記@2017-05-16>例えば給電停止から電源オフまでの待ち時間を10秒に設定しておいて、メインスイッチをパチパチと短時間でオフオンした場合は録画が継続する。</追記>
初期設定で Wi-Fiの自動起動が有効になっており、赤色LEDが点灯しているとき NECKERは無線LANのアクセスポイントになっている。初期SSIDは NECKER_V1_Plusで、暗号化方式は WPA2-PSK。キーの初期値はネットで下載できる產品說明書に書かれている通り。そうすると、Android/iOSアプリを通してカメラの設定を変更したり、記録されてる動画を再生したり、いままさにカメラが写してる映像を見たりができる。できた。
押しにくいけど一応 Wi-Fiのスイッチ(1-2mmのでっぱり)がカメラ後部に付いてるし実際のところ Wi-Fiを使う予定はないので、自動起動をオフにして
半日走り続けた場合、例えば3時間目4時間目以降の動画が全くなかったりする。そういう走り方を2回して、2回ともそうだった。シュラウドの前っていう走行風に恵まれた設置場所なんだけど、風が当たるのはレンズばかりで筒の後端に位置するメモリーカードや USB端子部分が熱くなりすぎるんだろうか。
===
を使ったりするのかもしれないけど、いざ自分で JavaScriptを書くと、===
の使い所がなくて困る。つまり、異なる型の変数を比較する場面というのが想定されていないから、それに対処する理由がない。型が同じなら(※null
は型ナシとする) ==
も ===
も同じなのだから、あえて ===
を使おうという動機がない。予定調和を乱すもの、外部入力は全部文字列だし、あるとしたら JSONくらい? だとしてもおかしな値の混入は水際で食い止めるべきで、比較演算子の出る幕(実際の利用場面)ではない。■あえてクソを探すなら、変数の型指定が(省略できるのではなく)できないことだろう。そこは JavaScript派生言語が補完しているところ。■ネタの方を拾おうにもマジレスしかできない。三位のひとつが "\t"
なんだけど、だったら " "
がどこからか現れて「俺が神だ」と主張し始めるだろう。最終更新: 2016-11-21T21:59+0900
try { var {y:lat, x:lng} = Map.getCenterLatLng(), mag = Map.getZoomLevel(); open(`https://www.google.co.jp/maps/@${lat},${lng},${mag}z`); } catch(e) {}
javascript:try{var{y:lat,x:lng}=Map.getCenterLatLng(),mag=Map.getZoomLevel();open(`https://www.google.co.jp/maps/@${lat},${lng},${mag}z`);}catch(e){}
以前に感じた通り、分割代入の構文は左辺の key と value が入れ違ってるとしか思えなくて(※)、案の定書き間違えたのだった。
※ keyは識別子(または文字列)で valueは expressionなのだから、keyで新しい名前を導入し、valueを特別な文脈で評価することで右辺のプロパティが参照できると考える(でも間違い)。これは JavaScriptの「平板」化ですよ>20091206p02.04。言語設計者は神だけど、現実世界の神がアドホックな物理法則を定めていたら、こちらは気が狂います。
マピオンはリンクをたどって特定の番地を表示できるのでメインで使用してる。検索ベースだと存在しない番地に対してテキトーな場所を表示されてもわからない一方、リンクをたどる方式ではそれを承知したうえで近くの番地から推測することができる。
とはいえ航空写真やストリートビューで実地の景色も確認したいので、マピオンからグーグルマップへ飛ぶ。