[amsat-bb] WISP on 64-bits WIndows

[Edson W. R. Pereira]

Thank you to everyone that has contacted me privately.

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.

73, Edson PY2SDR



On Thu, Oct 19, 2017 at 4:26 PM, Edson W. R. Pereira <ewpereira at gmail.com>
wrote:

>
> Has anyone successfully requested directory fill from Falconsat-3 using
> Windows 64-bits? It seems that WISP sends a corrupt request to the
> satellite on Windows 64-bits. I have tried running WISP on two different
> machines. Both with Windows 64-bits -- one running Windows 7 64-bits and
> the other running  Windows 10 64-bits. On both, every time MSPE requests a
> directory fill, I get a "NO -5 PY2SDR" response from the satellite. Roland
> PY4ZBZ tried on his 32-bits Windows 10 system and the satellite replies
> with a OK.
>
> Comparing the directory fill request packet sent to the satellite by my
> station and Roland's, it seems that, on my station, WISP is corrupting the
> directory hole pair data and also introducing one more byte to the request.
>
> This is PY4ZBZ (good) request:
>
> 10 F4 00 42 8F E5 59 FF FF FF 7F 0D 0A
>
> This is PY2SDR (bad) request:
>
> 10 F4 00 BF 12 E0 59 FF FF FF FF FF FF 7F
>
> 73, Edson PY2SDR
>
>
>
>