●本日午前7時快晴
マイナス0.6℃
【FalconSAT-3】「PY4ZBZ FalconSAT-3」FalconSAT-3についてはこのサイトに尽きるでしょうか。ロランドさん、ブラジルには凄い人がいますねぇ。JAの各局が盛んにメッセージを交換している様子も分かります。喜ばしいことです。
【万両】千両もあるが、これは「万両」
【AO-73】09:01 昼間も使える（1月3日まで）■交信（SSB）JA3FWT JA3PXH JH4MGU ★6.91kHz～6.75kHz～6.40kHz ループが低い方へどんどん動いて行きました。
【Meteor-M N2】09:14 日本海側と太平洋側、天気が分かれているようです。
【ITF-2】デコーダー
【AO-91】12:09 ■交信（FM：Tone67.0Hz）JA6PL JA0CAW JA4GVA JA0KEK（0802：長岡市 加藤さん）◆Decoded：54
【FalconSAT-3】16:45 ■Digipeater交信 JA6PL JA5BLZ-6
【AO-85】17:30 ■交信（FM：Tone67.0Hz）JA6PL JA4GVA ◆Decoded：37
【Meteor-M N2】20:37
【HW-VSP3の設定】FalconSAT-3『重要』★★★☆
Last night I installed Windows 7 32-bits and WISP on a virtual machine and
to my surprise, the problem I have been having persisted. After a lot of
hair pulling (not much left anyway) and investigation, I found that the
culprit was neither Windows nor WISP. It was the serial to TCP bridge HW VSP
software. If the NVT option of HW VSP is enabled, it inserts some control
data in the data stream when it finds some pattern on the input data stream.
In the case of a dir fill, it was introducing three 0xFF bytes right in
middle of the KISS frame. This was being sent over AX.25 to
Falconsat-3 and was the cause of the "NO -5" error.
I've tested requesting a dir fill during the last pass here and Falconsat-3
replied with a nice "OK PY2SDR"! Now let's grab some headers and try to
upload a small file.
【翻訳：抜粋】WindowsとWISPのいずれも原因ではないことが判明しました。 それは、TCP ブリッジHW VSPソフトウェアへのシリアルでした。 HW VSPのNVTオプションが有効になっている場合、入力データストリームに何らかのパターンが見つかると、データストリームに制御データが挿入されます.DIRフィルの場合、KISSフレームの中央に3つの0xFFバイトが挿入されています。 これはAX.25を介してFalconsat-3に送信され、「NO -5」エラーの原因となっていました。
