最近、WiFi接続のちょっとしたデバイスをESP8266で作る、という風潮があります（偏見）

ただ、この「ESP8266」という定義が２つある、というのがちょっとわかりにくい点だと思っています。

まず、本来の「ESP8266」というのはチップ(SoC)としての名称です。
これは「Espressif社(乐鑫信息科技)」が作っています。

これを使いやす基板に組み込んでモジュールとして販売しているものが一般的な「ESP8266」と呼ばれているものです。本来であれば「ESP8266モジュール」と呼ぶべきでしょうか？

この「ESP8266モジュール」には、オリジナルの「Espressif社(乐鑫信息科技)」が作成している「ESP-WROOM-02」が有名です。
このほかに、後発の「Ai-thinker社(安信可科技)」が作成しているものがあります。
どちらも上に乗っているチップ(SoC)は、Espressif社が製造したESP8266もしくはESP8266EXが使われています。

日本で販売しており、また、技適も取得されているのはEspressif社の「ESP-WROOM-02」です。
Kickstarter案件だとコスト面から、安いAi-thiker社のものを使っていることが多いようです。
技適はモジュール全体として取得されるものであるため、Ai-thinker社のものは技適外となります。

で・・・いろいろ見ていたら、さらに「WeMos Electronic」というところからもESP8266モジュールが出ているようです。

・「WEMOS D1 mini Pro」
　Flash 16MB
　WiFiアンテナは外付けのものを取り付ける必要あり
　シールド(電波遮蔽)が省略されているので薄い
　(電波遮蔽をしなくても使える、というわけではなく別途ケースで遮蔽して、ケースの外側にWiFiアンテナ取り付けろ、という意図)
　

・「WEMOS D1 mini V2」
　Flash 4MB
　WiFiアンテナは基板上にあり
　シールド(電波遮蔽)部分があるので、ちょっと厚い
　

価格は・・・$5と$4

↓な感じで普通の基板に取り付けやすい状態なのが利点ではあるものの・・・まぁ、技適がないというあたりが問題で・・・

iPhone7の日本版でFelicaに対応した、という話で注目されているのは「2017年4月移行に発売されるGSMAのGCF認定を受けたNFC対応スマートフォンは、NFC Type Fも搭載される」という話。

日本語の出典を調べると、一番わかり安かったのがマイナビの下記記事だった。
「iPhoneでモバイルSuicaが使えるようになる? – NFC対応スマートフォンにFeliCa搭載という流れ」

GSMAの規格書である「TS.26 NFC Handset Requirement」と「TS.27 NFC Handset Test Book」に記載されている。
そこではNFC Forumの規格書を参照している、とのこと。

確認してみた。

1. 「GSMA」の「CATEGORY ARCHIVES: TERMINAL STEERING GROUP」に行く
2. 「TS.26 V9.0 NFC HANDSET REQUIREMENTS(2016/04/12)」と「TS.27 V9.0 NFC HANDSET TEST BOOK(2016/06/24)」を発見

3. TS26では、NFCに関する詳しいことはNFC Forumの文章に丸投げてる

　NFCForum-TS-Type-1-Tag_1.2 (or later)
　NFCForum-TS-Type-2-Tag_1.2 (or later)
　NFCForum-TS-Type-3-Tag_1.2 (or later)
　NFCForum-TS-Type-4-Tag_2.0 (or later)

また、「SGP.03 NFC UICC REQUIREMENTS SPECIFICATION V6.1(2016/04/04)」では特に書いてないような感じ

4. 「NFC Forum」の「NFC Forum Specification Architecture」へ行く

5. 「NFC Forum Technical Specifications」でNFC Forum Tag Type Technical Specificationsに関して確認

NFC ForumのTag Type 3がFelicaということが判明

ということでいいんだろうか？

esp8266搭載の安いボードを買って、Windows7パソコンにつなげるとドライバが標準認識せず「USB2.0-Serial」となる。

VID 1A86, PID 7523 (VID_1A86&PID_7523) のドライバは何であるのかを調べると、江苏沁恒股份有限公司(WCH)のCH340らしい。

ドライバは下記のメーカページからダウンロードできる。
・CH341SER.EXE(実行形式のドライバインストーラ)
・CH341SER.ZIP(ZIP形式のドライバ)

どちらもバージョンは3.4(2015/10/30 or 2015/11/02)なので、好みに応じてどうぞ

インストールするとドライバのバージョンは 3.4.2014.8 (2014/08/08) でした。

Aliexpressの「FYD Open Source Hardware」というセラーから買う際にいろいろみていいたら「ESP8266 serial WIFI Witty cloud Development Board ESP-12F module」(送料込み$4.48)というものを発見。

いろいろ調べていくと「Shenzhen CAIZHIXING Electronic Co., Ltd」の「ESP8266 serial WIFI Witty cloud Development Board ESP-12F module MINI nodemcu」だと$3.20で販売している。

「Gizwits」という会社のプロダクトらしい。

(おまけ:esp8266コミュニティに「esp8266-module-family(ESP8266採用モジュール一覧)」発見)

で、作例を探してみると「Wifi Witty ESP-12F Board」を発見。

Arduino IDEでの設定も書かれている

ボードタイプ: NodeMCU v1.0 (ESP-12E Module)
CPU Frequency: 80 MHz
Flash Size: 4M (3M SPIFFS)
Upload Speed: 11520

下記のサンプルコードを書き込んでみる

const int LDR = A0;
const int BUTTON = 4;
const int RED = 15;
const int GREEN = 12;
const int BLUE = 13;
void setup()
{
    Serial.begin(11520);
    pinMode(LDR, INPUT);
    pinMode(BUTTON, INPUT);
    pinMode(RED, OUTPUT);
    pinMode(GREEN, OUTPUT);
    pinMode(BLUE, OUTPUT);
}
void loop()
{
    Serial.print("LDR: ");
    Serial.println(analogRead(LDR));
    Serial.print("BUTTON: ");
    Serial.println(digitalRead(BUTTON));
    analogWrite(RED, random(0,1023));
    analogWrite(GREEN, random(0,1023));
    analogWrite(BLUE, random(0,1023));
    delay(500);
}

問題無く動作した。

そういえばAmanekチャンネルアプリが出てからちゃんとi-dioチューナー使ってみた事無かったなぁ、と思って起動すると、全然使えない。
i-dioアプリだと問題無く使える。

ただ、受信状況が悪いせい、というのもあるかもしれない、と外付けアンテナを買ってみた。

前に、ヨドバシとAmazonで探した時は、FMアンテナ＋変換コネクタで２千円ぐらい、という感じだった。

それが、昨日探してみると、セットで1089円、という大変お手頃のものがあった。(eBayson FMフィーダーアンテナ 75Ω Antenna 3.5mm コネクタ 対応機種 Bose Wave & Acoustic Wave music system)

丁度よさそうなので買ってみた。

こんな中身で届いた。

i-dioチューナーの3.5φジャックにつなげて・・・

壁に仮置き

電波塔（関東では東京タワー）から遠い場合は、Ｔ字の部分を、もっとピーンと張りましょう。

うちの場合は、だらーんとしてても、全然問題無く受信できました。

先日の「USBコネクタサイズに収まるESP8285搭載ボード」に引き続き、esp8255搭載の超小型ボードに関する情報

ITEADという会社で、アンテナが外付けで2.25ドルの「PSF-A85」と、セラミック素子アンテナ搭載で2.25ドルの「PSF-B85」が販売開始になっている模様。

アンテナ外付けのPSF-A85はこんな感じ

セラミック素子アンテナのPSF-B85はこう。

どちらも基板サイズは13.5mm*13.7mm。
単純にアンテナ端子か、セラミック素子アンテナか、という違いですね

技適どころかFCCやCEも通ってないような怪しげデバイスですけど！！！

昔からの機械、例えばNEC PC-9801RAとか、Sun SPARC Stationとか、SGI Indy/Indigo2とかを今でも使おうとするとネックになってくるのがハードディスク。

50ピンのSCSI HDDを使用していると、壊れるともう換えが無い。

そんな時にはコレ、「codesrc SCSI2SD 」

上記の写真は2016年5月リリースのV6ボードらしい。
そしてV5は下記写真

V5,V6共通点
・ターミネータあり
・複数デバイスをエミュレート
・セクタサイズは64バイト～8Kバイト
・FirmwareアップデートやSCSI ID設定などの設定変更はUSB経由で実施

V6で変わった点
・V5はmicroSD、V6はフルサイズSD
・V5までは4デバイス、V6は7デバイスをエミュレート
・V6の方が高速アクセス(10MB/sの同期転送サポート)。V5までは2.3MB/sぐらい
・USB経由でPCとデータやりとりすることもできるが、遅い。1.2MB/s
・ノイズに強い
・内蔵ターミネータがソフトウェア設定でon/offできるようになった。
　(V5では物理的なターミネータを取り外してoffにする)
・電源コネクターが3.5インチフロッピーと同形状に変更

公式ショップでは下記の３種類が取扱中
→「SCSI2SD V6」 125オーストラリアドル
→「SCSI2SD Powerbook Edition」 100オーストラリアドルだけど品切れ？ V4.1基板で2.5インチSCSI HDDのPowerBookなど用
→「SCSI2SD 3.5″ 50-pin SCSI to SD card adaptor (revision 5.0)」 100オーストラリアドルだけど品切れ？

ebayのinertialcomputingではV5を現在6477円ぐらいで販売中？
→「ebayのinertialcomputing取扱品リスト」

ITEADではV5を70ドルにて販売中。
→「SCSI2SD 3.5″ 50-Pin SCSI To SD Card Adaptor」

昨日から始まったLinaro Connect Las Vegas 2016 (LAS16)のカンファレンスの冒頭「LAS16-100K1 Welcome Keynote」にて、新しいOrange Piシリーズの話が出た模様。

（ネタ元は、今回もcnxsoftware:Orange Pi Zero and Orange Pi i96 96Boards IoT Edition Boards Coming Soon)

問題のプレゼンは↓

96Boards IoT Editionとして「Orange Pi i96」が登場する模様。
今回は、Allwinnerではなく、RDA Micro社のCortex-A5搭載のSoCを使用
cnxsoftwareによれば「RDA8810PL」ではないかとのこと。
RAMを2GBつんで、ストレージは4GBと、Orange Pi Oneより拡充した内容。
おそらくHDMIは積んでないと想定される。
電源について「VBAT」とあるのでバッテリーへの充電制御部分も付いているのだとすると面白い感じで・・・

はたして、登場はいつになることやら？？？

なお、同じcnxsoftwareで取り上げられているAllwinner H2搭載のOrange Pi Zeroの方は、あんまり興味はないかなぁ・・・

2.5Gbps/5GbpsでCAT5eケーブルを使用するイーサネット規格がIEEE 802.3bzとして標準化された。

以前より「NBASE-T Alliance」にて「NBASE-T」という名称、またCisco社では「mGig(Multigigabit Ethernet)」という名称で製品化が進んでいたものではある。

１月に記事を書いた時は気がつかなかったのですが「玄人志向の10GBase-T NIC GbEX-PCIEはTehuti Networks TN9510相当品」って、NBASE-T対応製品だったんですね。

他にどんな製品があるのかな？と調べてみた
「NBASE-T Alliance加盟各社の製品一覧」
「Type of Product:System-level Product」で、「Availability:Shipping」となっているものが普通に購入できる製品、という意味になる。

スイッチ

NIC
・TEHUTI Network「TN9510: 5-speed 10GBase-T / NBASE-T」PCIeの10G/5G/2.5G/1Gネットワークインタフェース
・Promise「SANLINIK3 T1」40GbpsのThunderbolt3インタフェースを2.5Gに変換するアダプタ

Intelからは「Intel Ethernet Controller X550 family」というチップのみで、NICはまだリリースされていない模様

GIGABYTEからIntel X550-AT搭載の1ポートモデル「CLN4121 (rev. 1.0)」とIntel X550-AT2搭載の2ポートモデル「CLN4222 (rev. 1.0)」が出る模様。

GIGABYTEのNIC製品ページでは特に明記されていませんが、使用しているIntel X550-AT/X550-AT2についての詳細が記載されている「Intel Ethernet Controller X550 Specification Update」にはNBASE-T対応についての記述が・・・

2. NBASE-T Speed Advertisement

NBASE-T speed advertisement (2.5 GbE/5 GbE) is disabled by default in the X550 NVM. An NBASE-T
enabled driver should be used to link at NBASE-T speeds.
Linux driver version 4.3.9 is currently the only supported software solution for NBASE-T.
For future planned enhancements, contact your Intel representative.

おや・・・標準では無効にされているんですか・・・
今後に期待・・・なんですかね？

マイコンソフトの「CEATEC JAPAN 2016出展内容」に、HDMI入力をISDB-Tで送信し、地デジTVで受信できる「XHEAD-2(仮)」が紹介されていた。

で、今日。
cnx-softwareの「V-Bridge Muses Digital TV Modulator Boards Let You Broadcast Your Own TV Channel for $199 and Up (Crowdfunding)」という記事で似たようなものが紹介されていた。

この製品はkickstarterでクラウドファウンディング中の「MUSES: The First Open Source Modulator Development Board」で、台湾のVATekの「VATEK VMB820XD ENMODERを利用して、HDMIを各種デジタルTVとして再送信するプロダクトとのこと。

内部的には下記の５種類のパーツに別れている。
・MUSES-β(本体ボード、日本の地デジ対応)
・MUSES-α(廉価版本体ボード、日本の地デジ非対応)
・Video board(ビデオ入力ボード、必須)
・RF Board(TVに出力するためのボード、必須)
・STM32 Parts(単品で操作するためのボード)

MUSES-αとβの違いは下記となっており、日本の地デジ向けTVで使うにはβの方が必須となる。

組み合わせとして、「BASIC PACKAGE($199)」「STANDARD PACKAGE($399)」「TURNKY PACKAGE($599)」の３種類がある。
TURNKY PACKAGEに関しては１５台限定で$559となっている。

日本の地デジ向けTVで使うにはMUSES-βが必要となるので「STANDARD PACKAGE($399)」「TURNKY PACKAGE($599)」のどちらかが必要となる。

2017年1月予定、とのことですが、はたしてどうなることか？？？

５月に「中華ベンダGOLE社のGOLE1というタッチパネル付きミニPC」という記事でGOLE1のクラウドファウンディングを紹介しました。
これは無事出荷されました。

で・・・6月にはGOLE2を企画してるよ、との発言があり、どうなるかな？と思っていたところ
ついに、クラウドファウンディングが開始されました。

「GOLE2, The real Mini PC with FHD wide-angle camera」

・タッチパネルを廃止
・TVの横に置いて使うことを想定
・カメラを装備
・Intel Z8350搭載のWindows10モデルと、Allwinner A64搭載のAndroidモデルの２つを用意
・2.5インチHDD/SSD内蔵可能
・日本語マニュアル付き

Androidモデル・・・とはいっても、正確にはAOSPベースの「Phonenix OS」を採用(JideのRemixOSと似たようなもんです)

価格は
・Phoenix OSモデル(Orange): $69(100個限定),$79(200個限定),$89(300個限定),$99
・Windows10モデル(White or Black): $114(50個限定), $124(100個限定),$134(200個限定)

うーーーーん・・・・
それほど・・・コレといって・・・

Androidのバックアップソフト「Helium」はAndroid標準のバックアップ/リストア機能を流用する形で実現している。

ただ、Heliumの機能を使うためにはパソコンにHelium Desktopアプリをインストールし、そこから何かを行わせる必要がある。
「Helium Desktop Installer and Android App」を見ると、いまは、Chromeアプリ、Windowsアプリ、MacOSXアプリ、Linuxアプリ、がある模様。

で、Linuxの配布内容を見てみると、中身は、adbコマンドとシェルスクリプトのみ。
これなら、アプリを入れず、adbコマンドだけで実現できるのでは？と実験してみる

BASE=$(dirname $0)
pkg=$($BASE/adb shell pm path com.koushikdutta.backup)
# apparently pm path appends a carriage return which screws
# up the class name in dalvikvm invocation
pkg=$(echo $pkg | cut -d : -f 2 | sed s/\\r//g)
echo $pkg
$BASE/adb shell << EOF CLASSPATH=$pkg app_process /system/bin com.koushikdutta.shellproxy.ShellRunner2 $@ & exit EOF

(1)adbコマンドで、Heliumアプリ(com.koushikdutta.backup)がインストールされているパス名調査
(2)そのパス名をCLASSPATH環境変数に指定して、コマンド実行

という感じ。
私の環境では
(1) /data/app/com.koushikdutta.backup-1/base.apk
(2)「CLASSPATH=/data/app/com.koushikdutta.backup-1/base.apk app_process /system/bin com.koushikdutta.shellproxy.ShellRunner2」
ということなので、

「adb shell」でAndroid端末にshellで入り、「CLASSPATH=/data/app/com.koushikdutta.backup-1/base.apk app_process /system/bin com.koushikdutta.shellproxy.ShellRunner2」を実行することで、アプリインストールの代替とすることができた。

PowerShellを使ってメールを送信する方法を探すと２種類でてくる
・PowerShell cmdletの「Send-MailMessage」を使う
・Net.Mail.SmtpClient と Net.Mail.MailMessage を使う

UTF8で日本語メールを送る場合を考えると、Send-MailMessageを使用することで用が足りるようである。

ただ、Windows7で標準インストールとなるPowerShell v2.0だと、「Send-MailMessage -Encoding UTF8 ～」と指定すると、下記のエラーとなり、エンコーディングの指定がうまく行かない。そして、エンコーディングを指定せずに送ると日本語は文字化ける。

Send-MailMessage : パラメーター 'Encoding' をバインドできません。"eutf8" の値を "System.String" 型から "System.Text.Encoding" 型に変換できません。
発生場所 行:1 文字:28
+ Send-MailMessage -Encoding eutf8
+                            ~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Send-MailMessage]、ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,Microsoft.PowerShell.Commands.SendMailMessage

これは、「UTF8」の代わりに、System.Text.Encodingに変換したUTF8を指定「([System.Text.Encoding]::UTF8)」することで解決できる。

また、PowerShell v2.0のSend-MailMessageには、SMTPポートの番号指定が無い。
25番以外の場合は、「Net.Mail.SmtpClient と Net.Mail.MailMessage」の方を行う必要があるようだ。

そんなわけで、スクリプト例は下記の様になる。

$smtpserver= "サーバ名"
$port= 25
$mailfrom="ユーザ名@ドメイン名"
$mailtoArray=@(
   "ユーザ1@ドメイン名",
   "ユーザ2@ドメイン名",
   "ユーザ3@ドメイン名"
   )
$mailsubject="メール送信テスト"
$mailbody="これはメールの送信テストです。`n"+"正常に送信出来ていますか？"
if($PSVersionTable.PSVersion.Major -gt 2){
   Send-MailMessage -From $mailfrom -To $mailtoArray -SmtpServer $smtpserver -Port $port -Encoding utf8 -Subject $mailsubject -Body $mailbody
}else{
   # PowerShell v2.0用処理。ポート番号指定除去と、Encoding指定方法変更
   Send-MailMessage -From $mailfrom -To $mailtoArray -SmtpServer $smtpserver -Encoding ([System.Text.Encoding]::UTF8) -Subject $mailsubject -Body $mailbody
}

PowerShellのファイル出力先を、実行したユーザのデスクトップにする場合に、「$env:USERPROFILE + “\Desktop\”filename.txt”」と指定するのは間違い。

この場合、ローカルディスクでは無く、ファイルサーバ上にDesktopが置かれるような環境に対応できない。
「[Environment]::GetFolderPath(“Desktop”)」で取得するのが正しい。

実際に、どういう風になるのか見てみる・・・

PS C:\Users\osakanataro> $env:USERPROFILE + "\Desktop"
C:\Users\osakanataro\Desktop
PS C:\Users\osakanataro> [Environment]::GetFolderPath("Desktop")
\\fileserver1\Redirects$\osakanataro\Desktop

Desktop以外に指定できる内容については「Environment.SpecialFolder Enumeration」参照のこと。
「Added in the .NET Framework 4.」なっているものは、Windows7/WindowsServer2008などの古めのWindowsでは動かないので注意。

PowerShell/PowerCLIを使ってデータストアの空き容量チェックを行う過程で、ローカルディスクのVMFSは無視したい、というものがある。
ESXiホスト台数が増加することを考えると名前による除外などはやりたくない。
何らかの手法でローカルディスクかどうかを判定できないかを探した。

・Get-Datastoreで取得できる情報の範囲で確定できるものが無い
　　vSphere6であれば「ExtensionData.Summary.MultipleHostAccess」というデータストアが
　　複数のホストからアクセス可能か？というフラグ(true or false)があるが、
　　１台のホストだけ接続しているiSCSi,FCデータストアも対象になるのでは？（未確認）
・Get-ScsiLunには「IsLocal」というローカルディスク判定フラグがある
・Get-ScsiLunはデータストアを指定して実行することができる
・ESXiホストが停止しているデータストアに対するGet-ScsiLunはエラーとなる
・アクセス出来ないデータストアは「Accessible」フラグがfalseとなる

これらを元に作成した判定

$localdatastore=$false # フラグ
$datastore = Get-Datastore データストア名"
if($datastore.Type -eq "VMFS){
  # VMFSだとローカルディスクの可能性があり
  # それ以外の、NFS,vsanは対象外
  if($datastore.ExtensionData.Summary.MultipleHostAccess -eq $true){
    # MultipleHostAccessがTrueなら、ローカルディスクではないことが確定
    $localdatastore=$false
  }elseif($datastore.Accessible -eq $true){
    # アクセスできるならGet-ScsiLunがエラーにならない
    $diskinquire = Get-ScsiLun -Datastore $datastore
    if($diskinquire.IsLocal -eq $true){
      # IsLocalによるローカルディスク確定
      $localdatastore=$true
    }
  }else{
    # アクセスできないデータストア
  }
}

最近、Windows7で稼働してるDELL Latitude E6320(CPU Core i5-2520M)の起動が遅い。
メモリが4GB(2G*2)しか積まれてないのが問題なのかな？と

4桁番台のCore i5なら、8GB SO-DIMMがささるはず、と、先日、Amazonで買ったTeam ノートPC用メモリ SO-DIMM-DDR3 永久保証 ECOパッケージ (1333Mhz PC3-10600 1.5V 8GBx2)を取り付けてみた。

(ちなみに、元々ささっていたのはSamsung 2G 1Rx8 PC3-10600S-09-11-B2、というメモリでした)

裏面の１０箇所のネジを外して交換。

特に問題無く起動。
起動も若干速くなった。

ちなみに、手持ちで4GB SO-DIMMが１枚あったので、2G+4G=6GB構成で起動してみると、初期状態とそれほど変わらない感じだった。

Windowsエクスペリエンスインデックスのメモリの値
2GB+4GB : 7.2
8GB: 7.1
8GB+8GB : 7.5

PowerShellスクリプト(ps1)に対して、ファイルをドラッグ＆ドロップしてもファイルを認識して実行してくれない。

また、そもそもPowerShellスクリプトを実行しようとしても、下記のエラーで実行ができない。

PS C:\Users\osakanataro\Documents\powershell> .\powershelltest.ps1
スクリプトの実行がシステムで無効になっているため、ファイル C:\Users\osakanataro\Documents\powershell\powershelltest.ps1 を読み込めません。詳細については、「get-help about_signing」と入力してヘルプを参照してください。
発生場所 行:1 文字:25
+ .\powershelltest.ps1 <<<<
    + CategoryInfo          : NotSpecified: (:) &#91;&#93;、PSSecurityException
    + FullyQualifiedErrorId : RuntimeException
PS C:\Users\osakanataro\Documents\powershell> 

回避方法は下記の２つを行う、ということ
・バッチファイル経由でPowerShellを起動する
・うまく行かない場合は、管理者権限でバッチファイルを起動する

今回使用したバッチファイルは下記の内容とした

@echo off
rem PowerShellスクリプトの実行が禁止されている場合に
rem このバッチファイルを管理者権限で動作させると
rem PowerShellスクリプトが実行できます。
powershell -sta -ExecutionPolicy Unrestricted -File %0\..\powershelltest.ps1 %*

powershell起動時に「-sta」オプションをつけているのは、powershellからフォームダイアログを開こうとすると、下記のエラーがでてしまうことを回避するため。

なお、詳細を開くと下記の情報が出力されている

Just-In-Time (JIT) デバッグを呼び出すための詳細については、
ダイアログ ボックスではなく、このメッセージの最後を参照してください。
************** 例外テキスト **************
System.InvalidOperationException: DragDrop 登録は成功しませんでした。 ---> System.Threading.ThreadStateException: OLE が呼び出される前に、現在のスレッドが Single Thread Apartment (STA) モードに設定されていなければなりません。Main 関数に STAThreadAttribute が設定されていることを確認してください。
   場所 System.Windows.Forms.Control.SetAcceptDrops(Boolean accept)
   --- 内部例外スタック トレースの終わり ---
   場所 System.Windows.Forms.Control.SetAcceptDrops(Boolean accept)
   場所 System.Windows.Forms.Control.OnHandleCreated(EventArgs e)
   場所 System.Windows.Forms.ListBox.OnHandleCreated(EventArgs e)
   場所 System.Windows.Forms.Control.WmCreate(Message& m)
   場所 System.Windows.Forms.Control.WndProc(Message& m)
   場所 System.Windows.Forms.ListBox.WndProc(Message& m)
   場所 System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   場所 System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** 読み込まれたアセンブリ **************
mscorlib
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5485 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Microsoft.PowerShell.ConsoleHost
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7600.16385
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.ConsoleHost/1.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.ConsoleHost.dll
----------------------------------------
System
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.8686 (QFE.050727-8600)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Management.Automation
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Management.Automation/1.0.0.0__31bf3856ad364e35/System.Management.Automation.dll
----------------------------------------
Microsoft.PowerShell.Commands.Diagnostics
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.Commands.Diagnostics/1.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.Commands.Diagnostics.dll
----------------------------------------
System.Core
    アセンブリ バージョン: 3.5.0.0
    Win32 バージョン: 3.5.30729.5420 built by: Win7SP1
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Configuration.Install
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration.Install/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.Install.dll
----------------------------------------
Microsoft.WSMan.Management
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.WSMan.Management/1.0.0.0__31bf3856ad364e35/Microsoft.WSMan.Management.dll
----------------------------------------
System.Transactions
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_64/System.Transactions/2.0.0.0__b77a5c561934e089/System.Transactions.dll
----------------------------------------
Microsoft.PowerShell.Commands.Utility
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.Commands.Utility/1.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.Commands.Utility.dll
----------------------------------------
Microsoft.PowerShell.Commands.Management
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.Commands.Management/1.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.Commands.Management.dll
----------------------------------------
Microsoft.PowerShell.Security
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.Security/1.0.0.0__31bf3856ad364e35/Microsoft.PowerShell.Security.dll
----------------------------------------
Microsoft.PowerShell.ConsoleHost.resources
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7600.16385
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.ConsoleHost.resources/1.0.0.0_ja_31bf3856ad364e35/Microsoft.PowerShell.ConsoleHost.resources.dll
----------------------------------------
System.Xml
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5494 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Management
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Management/2.0.0.0__b03f5f7f11d50a3a/System.Management.dll
----------------------------------------
System.DirectoryServices
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.DirectoryServices/2.0.0.0__b03f5f7f11d50a3a/System.DirectoryServices.dll
----------------------------------------
System.Management.Automation.resources
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7600.16385
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Management.Automation.resources/1.0.0.0_ja_31bf3856ad364e35/System.Management.Automation.resources.dll
----------------------------------------
Microsoft.WSMan.Management.resources
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.WSMan.Management.resources/1.0.0.0_ja_31bf3856ad364e35/Microsoft.WSMan.Management.resources.dll
----------------------------------------
mscorlib.resources
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5485 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Microsoft.PowerShell.Security.resources
    アセンブリ バージョン: 1.0.0.0
    Win32 バージョン: 6.1.7601.17514
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.PowerShell.Security.resources/1.0.0.0_ja_31bf3856ad364e35/Microsoft.PowerShell.Security.resources.dll
----------------------------------------
System.Data
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.8692 (QFE.050727-8600)
    コードベース: file:///C:/Windows/assembly/GAC_64/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
System.Windows.Forms
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5491 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5495 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Accessibility
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5483 (Win7SP1GDR.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
System.Windows.Forms.resources
    アセンブリ バージョン: 2.0.0.0
    Win32 バージョン: 2.0.50727.5420 (Win7SP1.050727-5400)
    コードベース: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_ja_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
************** JIT デバッグ **************
Just-In-Time (JIT) デバッグを有効にするには、このアプリケーション、
またはコンピュータ (machine.config) の構成ファイルの jitDebugging
値を system.windows.forms セクションで設定しなければなりません。
アプリケーションはまた、デバッグを有効にしてコンパイルされなければ
なりません。
例:
<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>
JIT デバッグが有効なときは、このダイアログ ボックスで処理するよりも、
ハンドルされていない例外はすべてコンピュータに登録された
JIT デバッガに設定されなければなりません。

aliexpressとかで「In stock」的な表示になってるけど、「在庫数 9999」ってほんとかな？というものが結構あります。
製造メーカの直売セラーならほんとなのでしょうけど、いろんな商品を取り扱っているセラーでも、そんな表示を見かけることがあります。

いろんなセラーから買ってみて感じた印象としては・・・

Lv1 本当に手元に在庫を持っている
Lv2 別倉庫ではあるけれど、自社の倉庫に在庫を持っている
Lv3 在庫を持っている中卸業者と提携し、そこの在庫数を引っ張ってきている
Lv4 在庫を持っている中卸業者を知っている（ほんとに在庫があるか確認しているわけではない）
Lv5 発注があってから、発注があった価格で仕入れることができる場所を探す

という段階があるように思えます。
Lv5は、ちょっと相場より安すぎやしない？という値段の場合に遭遇するような気がします。
そして、調達できないと逃げます(aliexpressなら返金されます)

発送までにかかる日数

Lv1 手元に在庫がある場合は、早いと翌日には発送連絡がきます。遅くとも4営業日ぐらいには出てる漢字です。
Lv2～Lv3 は、4営業日ぐらいから発送連絡がきます。遅くても8営業日ぐらいです。
Lv4以降はまぁ運ですね。遅いとaliexpressの最終発送期限の14日目に送ってきたりします。

発送連絡があり荷物の追跡ができるようになるまでの日数

ここら辺は、使用する運送会社によって変わります

DHLなら、当日中にトラッキングできます。
夕方までに発送されていると、夜の間に上海/香港から飛び立ち日本にやってきてしまいます。

UPS取り扱いだと、3日ぐらいかかる場合があります。
ただ、ちょっと使った回数が少ないのでなんとも・・・

安く発送する場合で、バッテリーが含まれていない場合は、中国郵政扱いの国際書留(China Post Registered Mail)が使われます。
トラッキング番号だけを先に登録することもできるようで、発送連絡と同時に中国郵政の追跡調査ができるようになることが多いです。
しかし、実際に荷物が動き出すまでには5日～8日ぐらいかかります。

バッテリーが含まれる場合は、ここ1年の傾向ではオランダ郵政扱いの国際書留(NL Post Registered Mail)になる可能性が高いです。
中国のNL Postの集積拠点に対して送られたあと、まとめてオランダのアムステルダムにある郵便局に輸送され
アムステルダムから個別の荷物として改めて配送される形式のものです。
つまり、アムステルダムに到着するまでは、追跡調査ができません。
アムステルダム到着まではだいたい3週間といったところです。
そこから1週間～2週間で、日本に到着します。

中国通販で気をつけなればならないのは、10月1日の建国記念日と、2月の旧正月です。
ここの前後は輸送が混乱し、配送が特に遅れたり、紛失しやすくなったりします。
可能であれば、前後2週間は避けたほうが無難でしょう.

しばらく前まで、結構いい感じのAndroidスマホを作っていた「JIAYU(佳域手机)」。
JIAYU S3以降、新機種がでないなぁ・・・と思っていたら、「トップページ」が「Funsso(方烁科技)」に飛ばされるようになりました。
Funssoは、光ファイバー用のSFPモジュールを販売しているメーカのようです。

スマホに関するページはFunssoにはありません。
唯一、JIAYU時代からある公式掲示板へのリンクがトップページに残されているだけです。

FussoとJIAYUの関係について、特にニュースや会社案内などでも説明されておらず、謎です。

ただ、１年以上新製品の話が出てないところもあわせて考えるとJIAYUのスマホ事業は終了した、と考えていいのではないかと思います

「SIMにシールを貼るだけで電波の届かないところでも携帯で支払いできる技術」という記事があったけど、正直意味がわかんないので調べてみた。

公式ページ「DigiTally」
「概要紹介スライドpdf」

・SIMの上に貼り付けるoverlay SIMとは何をするものなのか？
・どういう場合につかう想定なのか？
・どういう決済の仕組みになっているのか？

で・・・よく読むと、overlay SIMが重要なのではなく、「SMAPs:Short Message Authentication Protocols」が重要なようです。

・どういう場合につかう想定なのか？
SMAPs(Short Message Authentication procotols)は、携帯電波が不安定でつながりにくく、また、データ通信量も増やせない環境で、如何にして信頼性を保ちつつ、決済を行うか、ということを考えて作られたプロトコルであるようです。

具体的には、SMS(ショートメッセージ)ベースでデータをやりとりすることで、ネットワークの不安定さを回避し、また、確実に相手に届ける、ということを実現するようです。
（GSMのみの途上国では、TCP/IPのデータ通信はパケット料が高額で、また不安定、ということ）

・どういう決済の仕組みになっているのか？
スライド記載の手順を元に日本語化してみました

(1) アリスはDigiTally口座(電子決済口座)に5ドルを入金する
(2) アリスと取引相手であるボブは、お互いの携帯電話を電話帳に登録する(?)
(3) アリスはボブから4ドルの品物を買いたいと伝えます
(4) ボブは自身の携帯の決済アプリに「4(ドル)」と入力し、「決済要求ボタン」を押します。
　（ボブ携帯からアプリがDigiTallyセンターにSMSで暗号化されている決済要求のメッセージを送る）
(5) ボブは、携帯の決済アプリに表示されている8桁の決済コード1をアリスに伝えます
(6) アリスは自身の携帯の決済アプリに「4(ドル)」と「8桁の決済コード1」を入力し、「決済承認ボタン」を押します。
　（アリス携帯からアプリがDigiTallyセンターにSMSで暗号化されている決済承認のメッセージを送る）
(7) アリスは、携帯の決済アプリに表示されている8桁の決済コード2をボブに伝えます
(8) ボブは自身の携帯の決済アプリに「8桁の決済コード2」を入力し、「決済完了ボタン」を押します。
　（ボブ携帯からアプリがDigiTallyセンターにSMSで暗号化されている決済完了のメッセージを送る）
(9) アリスのDigiTally口座から4ドルが引かれ1ドルになり、ボブのDigiTally口座に4ドルが足されます
(10) 決済完了ログが、アリスとボブの携帯に届きます。
　（DigiTallyセンターから、アリスとボブの携帯にSMSで決済完了ログを送る)

とても手動な感じで行うようです。
なお、上記のSMS送信ポイントは、想像が入ってます。

いろいろ文献を読むと、(4)と(6)と(8)のSMS送信に関しては遅延しても良いような実装、
つまりSMSの送信については携帯に搭載された決済アプリで再送制御を行うようです。

(4),(6),(8)のSMSがDigiTallyセンターに全部届いた時点で、決済が完了し(10)が行われるようなのですが
決済完了を確認する前に物品引き渡して、その後、決済不成立、ってことが発生しそうなんだけど
それをどうやって回避できるのかが読み取れなかった・・・