The Pacsat Groundstation is now working reasonably well. It is running at a couple of QTHs downloading and uploading files. I am using it exclusively. But is it not without bugs. The important ones are tracked on github and you can read up on them there. As of today there are 17 but only 5 are bugs, the rest are planned enhancements. And of the bugs only 1 is critical and I labeled it "File 14f4 can not be downloaded"
This is a curious issue. When I look at the directory It tells me that file 14f4 has 1176 bytes and 1 hole. In the log I see the ground station repeatedly requesting the file. It is filled with requests like this:
DL SENDING: From:AC2CZ to PFS3-11 Ctrl: 3 Type: UI Cmd PID: bb FLG: 12 FILE: 14f4 BLK_SIZE: f4 Hole 1: 3266 65535 ...
Waiting: Adding DOWN LINK Event: OK AC2CZ.
Adding DOWN LINK Event: From:PFS3-11 to PBLIST Ctrl: 3 Type: UI Res PID: f0 PB: AC2CZ.
Adding DOWN LINK Event: From:PFS3-11 to PBLIST Ctrl: 3 Type: UI Res PID: f0 PB: Empty..
But wait, the header says it only has 1176 bytes, why do we request a hole from byte 3266. What is going on?
Well, here is the actual pacsat header on disk for the part of the file we have downloaded.
Field number 4 is highlighted, or rather the data bytes are highlighted. If you have forgotten how to read the Pacsat header, then it starts with AA 55 and then marches through the fields with two bytes for the field number, 1 byte for the number of data bytes and then those bytes. So field 4 starts 3 bytes before those highlighted, with the field number 04 00. It is little endian, so that is just field 4. The next byte is 4 meaning we have 4 data bytes, which follow and are: C2 0C 00 00. Again its little endian so that is CC2, or 3266 in decimal. So on disk the pacsat header is telling us we have 3266 bytes, but the pacsat header we originally got in a directory broadcast said 1176.
3266 is right because inspection of the file shows that is how many bytes we have in addition to the fact that it states that value in the header. So there are no more holes, we are done. The "bug" is that we have an out of date pacsat header and it prevents us from realizing that the file is fully downloaded, so we keep requesting it. The algorithm checks if the number of bytes we have matches the start of the last hole, then it discards it.
The fix is easy. Look at the pacsat header in the downloaded file when we try to determine if we have all the holes. Don't rely on the header we have in the directory. It looks like it can change. I suspect system files can grow after they are written.
But that is not all. In addition to continually requesting this file I am continually requesting a set of directory holes that never seem to be filled. More on that in another post...
73 Chris g0kla/ac2Cz
Enter Comments Here:
Copyright 2001-2021 Chris Thompson
Send me an email