Re: [amsat-bb] Falconsat-3 upload problem
Hello all,
Got all your TESTING UPLOAD messages in loud and clear. My message to K4KDR didn't get send out. I'm still (re)searching about the cause of this. Later......
Hans
BX2ABT
On 06/18/2019 09:45 PM, Mark L. Hammond wrote:
Hi Hans,
I was able to upload a message (to you!) on FS-3 last night/this morning, fully automated. So the satellite is evidently behaving OK.
Hope you get it figured out. Since I don't use Direwolf, sorry I can't give any suggestions.
73,
Mark N8MH
At 08:07 AM 6/18/2019 +0800, Hans BX2ABT wrote:
I didn't write it directly, but I assumed from the description you would read that I indeed run full duplex (and to add to this: my system is Linux, not Windows). If not Direwolf will wait for a free window to throw out packets which will never happen because FS-3 is on all the time. No, everything is working, except for the problem I described before: all commands to the bird are heard and responded to, but uploading a message will fail.
Desensing is also not the problem: got the appropriate filters in place for that. Cheers,
Hans
BX2ABT
On 06/17/2019 10:52 PM, Mark L. Hammond wrote:
Hello Hans, I have not been working FS-3 recently, since the IC-9700 will not do 9600 packet [iCom, please fix!!] :(   So I cannot comment on recent uploads. However, to add to Bob's thoughts--are you running full duplex?  It's critical. Also, is your transmit signal desensitizing your receive signal?  That is important, too.Â
In the next week or so I will change radios at my station so I can again use FS-3. Â I'll be better able to share current experiences with you.
73,
Mark N8MH
On Mon, Jun 17, 2019 at 9:19 AM Hans BX2ABT via AMSAT-BB <amsat-bb@amsat.org mailto:amsat-bb@amsat.org> wrote:
I'm not behind my shack computer right now, but I know that PSGS and Direwolf each have a TX delay. Are you referring to those maybe being too long? If so, then why are all other commands (DL and directory listings) giving me no problem? 73 de Hans BX2ABT On 06/17/2019 08:53 PM, Robert Bruninga wrote: > I am no expert. But remember that your RF and all processing has to > be full duplex. The turn arround for packets in the satellite is > instantaneous. > with no TXD delays. Bob > > > On Mon, Jun 17, 2019 at 2:24 AM Hans BX2ABT via AMSAT-BB > <amsat-bb@amsat.org <mailto:amsat-bb@amsat.org> <mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org>>> wrote: > >   Up til now I have been successful in getting PacSatGroundStation >   (PSGS) >   to work on receive. You can go here if you want to see my setup: >   http://bx2abt.com/main/Falconsat-3 <http://bx2abt.com/main/Falconsat-3> . I can hit FalconSat-3 with a >   directory request or file download request and get an immediate >   response >   and consequent downloads. Uploading is a different story, however. I >   have been able to get some messages uploaded, but it was more by >   chance. >   Right now if I want to upload I seem to get into a loop where PSGS >   keeps >   on sending out the same frame (I presume), then disconnects, after >   which >   the whole cycle starts over again. > >    From the PSGS debugging info you can see that I am successful in >   logging into PFS3-12. My file gets a designated ID (1f14 in this >   case) >   and is ready to be received. Then it uploads what I presume is one >   frame >   (you can see this in Direwolf where the same chunk of data is send >   over >   and over again) after which possibly the reason why things don't >   work: >   "ER_BODY_CHECK received while uploading: >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out". The only >   mention of ER_BODY_CHECK I can find on the internet is that it is >   sent >   when the checksum on the file body fails. After that the whole >   sequence >   starts again, so the message never gets uploaded and out of the queue. > >   Does this problem lie with FalconSat-3, Direwolf or PGSG, or >   somewhere >   else? Where is the checksum being made? This is my first forray into >   packet radio/PacSat, so I'm not an expert (yet). I don't want to make >   any (un)educated guesses, thus any help or hints are appreciated. >   Cheers, > >   Hans >   BX2ABT > > > >   This is the output (with debugging turned on) of PSGS: > >   --------BEGIN------- >   Open ABCD: >   Ready to upload file: BX2ABT17.txt.out >   B: 209908947. >   U>> >   DEBUG 3: Open: Adding UP LINK Event: UL_CONNECT >   PB: Empty.. >   I>>From:PFS3-12 to BX2ABT Ctrl: 0 Type: I Cmd PF: 0 NR: 0 NS: 0 >   5 2 cc >   a7 fb 5c 4> SUCCESSFUL LOGIN to PFS3-12 by BX2ABT >   DEBUG 3: Open: Adding UP LINK Event: From:PFS3-12 to BX2ABT Ctrl: 0 >   Type: I Cmd PF: 0 NR: 0 NS: 0 5 2 cc a7 fb 5c 4> SUCCESSFUL >   LOGIN to >   PFS3-12 by BX2ABT >   DEBUG 3: Cmd Ok: Adding UP LINK Event: UL_REQUEST_UPLOAD >   DEBUG 3: Cmd Ok: UL_CMD: From:BX2ABT to PFS3-12 Ctrl: 0 Type: I >   Cmd PF: >   0 NR: 0 NS: 0 8 3 14 1f 0 0 31 3 0 0 UL CMD: UPLOAD_CMD File: 1f14 >   Size: 331 >   S>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I Cmd PF: 0 NR: 1 NS: 1 >   8 4 >   14 1f 0 0 31 3 0 0> Ready to receive file: 1f14 from BX2ABT at >   off: 817 >   DEBUG 3: Waiting: Adding UP LINK Event: From:PFS3-12 to BX2ABT >   Ctrl: 22 >   Type: I Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to >   receive >   file: 1f14 from BX2ABT at off: 817 >   DEBUG 3: Waiting: UL_GO_RESP: From:PFS3-12 to BX2ABT Ctrl: 22 >   Type: I >   Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to receive >   file: >   1f14 from BX2ABT at off: 817 >   DEBUG 3: Waiting: GO FILE>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I >   Cmd >   PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to receive file: >   1f14 >   from BX2ABT at off: 817 >   DEBUG 3: Data: Adding UP LINK Event: UL_DATA_END >   DEBUG 3: Data: UL_DATA_END: UL_DATA_END >   S>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 44 Type: I Cmd PF: 0 NR: 2 NS: 2 >   1 7 >   10> UL NAK 16: ER_BODY_CHECK >   DEBUG 3: Data End: Adding UP LINK Event: From:PFS3-12 to BX2ABT >   Ctrl: 44 >   Type: I Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: ER_BODY_CHECK >   DEBUG 3: Data End: UL_NAK_RESP: From:PFS3-12 to BX2ABT Ctrl: 44 >   Type: I >   Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: ER_BODY_CHECK >   NAK: ER_BODY_CHECK received while uploading: >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out > >   TIME-1: PHT: uptime is 469/13:51:30. Time is Sat Jun 08 12:19:29 >   2019. >   U>> >   DEBUG 3: Idle: Adding UP LINK Event: UL_DISCONNECTED >   DEBUG 3: Idle: Adding UP LINK Event: Open ABCD: >   Open ABCD: >   B: 209908947. >   PB: Empty.. >   ---------END------- > >   This is what Direwolf's output is: > >   --------BEGIN------- >   PFS3-1 audio level = 68(+118/-110)  [NONE] ||||||||| >   [0.4] PFS3-1>LSTAT:I P:0x13A8 o:0 l:31473 f:31529, d:1 st:4 e:26<0x0d> >   Unknown APRS Data Type Indicator "I", Ambulance >   [0L] BX2ABT>PFS3-12:(SABM cmd, p=1) > >   PFS3-12 audio level = 69(+115/-111)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(UA res, f=0) > >   PFS3-12 audio level = 70(+119/-110)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=0, n(r)=0, p=0, >   pid=0xf0)<0x05><0x02>^<0xa8><0xfb>\<0x04> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=16, n(r)=120, p=0, >   pid=0x08)<0x08><0x03><0x14><0x1f><0x00><0x00>1<0x03><0x00><0x00> > >   PFS3-12 audio level = 70(+121/-110)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=0) > >   PFS3-12 audio level = 70(+121/-109)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=17, n(r)=120, p=0, >   pid=0x08)<0x04><0x14><0x1f><0x00><0x00><0xfe><0x00><0x00><0x00> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=1, n(r)=2, p=0, >   pid=0xf0)<0xfe><0x00> >   the internet server that you sent me a message on April 11, but >   unfortunately I never was able to download it. It took a while to get >   the transmitting part working, but now it does and I'm very >   pleased to >   be able to contact you via FS-3. Truly an amazin >   [0L] BX2ABT>PFS3-12:(RR cmd, n(r)=2, p=1) > >   PFS3-11 audio level = 65(+118/-109)  [NONE] ||||||||| >   [0.4] PFS3-11>PBLIST:PB: Empty.<0x0d> >   Unknown APRS Data Type Indicator "P", Original Balloon (think Ham b > >   PFS3-12 audio level = 66(+117/-109)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=1) >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=33, n(r)=120, p=0, >   pid=0x08)<0x08><0x03><0x00><0x00><0x00><0x00>1<0x03><0x00><0x00> > >   PFS3-12 audio level = 74(+125/-111)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(DISC cmd, p=1) >   [0L] BX2ABT>PFS3-12:(UA res, f=1) >   --------END------- > >   _______________________________________________ >   Sent via AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org> <mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>>. AMSAT-NA >   makes this open forum available >   to all interested persons worldwide without requiring membership. >   Opinions expressed >   are solely those of the author, and do not reflect the official >   views of AMSAT-NA. >   Not an AMSAT-NA member? Join now to support the amateur satellite >   program! >   Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb <https://www.amsat.org/mailman/listinfo/amsat-bb> > _______________________________________________ Sent via AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb <https://www.amsat.org/mailman/listinfo/amsat-bb>-- Mark L. Hammond [N8MH]
Okay, many hours googling and reading later......... I came upon two documents with some relevant information. First this is from the document "Pacsat File Header Definition". As it already says, it give a definition:
-------BEGIN------- 3.1.9 body_checksum
id : 0x09 length : 2 data : unsigned int body_checksum
A 16 bit checksum formed by adding all bytes in the file body into a 16 bit variable, ignoring overflow. The <body_checksum> does not include the bytes comprising the PACSAT file header.
The <body_checksum> is primarily intended to detect mis-corrected multi-bit errors caused by Single Event Upsets in the PACSAT memory.
INITIALIZATION - The correct <body_checksum> must be supplied. -------END-------
I don't quite understand the second but last sentence: does the PACSAT memory get upset by my messages?
From "Pacsat Protocol: File Transfer Level 0" document more on the upload procedures:
-------BEGIN------- 7.4. Completion of Upload
7.4.1 Successful Upload Completion
When the server receives the DATA_END packet it will check the integrity of the file as far as possible. If the checks pass, the server will downlink a UL_ACK_RESP packet.
Packet: UL_ACK_RESP Information: none
After transmitting the UL_ACK_RESP the server uplink state variable is UL_CMD_OK. After receiving the UL_ACK_RESP, the client uplink state variable is UL_CMD_OK.
7.4.2 Failure Caused by Server Rejecting Upload
The server may reject an upload while the client is sending DATA packets (due to file system problems on the server) or after the client has sent the DATA_END packet (due to corruption of the file).
If the server must abort the upload while receiving DATA packets or after receiving the DATA_END checks fail, it sends the UL_NAK_RESP packet.
Information: 1 byte unsigned char err_code; <err_code> must be one of:
ER_BAD_HEADER - The file either has no PFH, or has a badly-formed PFH. ER_HEADER_CHECK - The PFH checksum failed. ER_BODY_CHECK - The PFH body checksum failed. ER_NO_ROOM - The server ran out of room for file storage before the upload was complete. The server will implement procedures to avoid frequently running out of room, but this cannot be guaranteed.
After transmitting the UL_NAK_RESP packet, the server uplink state variable is UL_CMD_OK. After receiving the UL_ERROR_RESP, the client uplink state variable is UL_CMD_OK. -------END-------
So I clearly get a UL_NAK_RESP packet with the ER_BODY_CHECK error.
I also downloaded the PACSAT Ground Station software source code from G0KLA (hello Chris). The hex code for the BODY_CHECKSUM is 0x09. If you search for that in the source code you come up with the file Crc16.java. My coding skills are very minimal, so I don't grok the code completely, but I do see something strange in that file Crc16.java:
-------BEGIN-------
String s = "HELLO";
byte[] bytes = s.getBytes();
//Crc16 crc = new Crc16(bytes); short cs = 0; for(byte b : bytes) cs += b & 0xff; System.out.println(cs);
PacSatField pf = new PacSatField(cs, 0x09); System.out.println(pf); } -------END-------
String s is probed for the number of bytes, then "converted" into variable cs, which is the PacSatField 0x09, iow the Body_Checksum. Now string s is simply "HELLO" and I don't see if this is hard coded or that this string changes according to the content of the message body. Any Java programmers here who want to help me look at it?
Any help appreciated. Cheers,
Hans
BX2ABT
On 06/18/2019 10:07 PM, Hans BX2ABT via AMSAT-BB wrote:
Hello all,
Got all your TESTING UPLOAD messages in loud and clear. My message to K4KDR didn't get send out. I'm still (re)searching about the cause of this. Later......
Hans
BX2ABT
On 06/18/2019 09:45 PM, Mark L. Hammond wrote:
Hi Hans,
I was able to upload a message (to you!) on FS-3 last night/this morning, fully automated. So the satellite is evidently behaving OK.
Hope you get it figured out. Since I don't use Direwolf, sorry I can't give any suggestions.
73,
Mark N8MH
At 08:07 AM 6/18/2019 +0800, Hans BX2ABT wrote:
I didn't write it directly, but I assumed from the description you would read that I indeed run full duplex (and to add to this: my system is Linux, not Windows). If not Direwolf will wait for a free window to throw out packets which will never happen because FS-3 is on all the time. No, everything is working, except for the problem I described before: all commands to the bird are heard and responded to, but uploading a message will fail.
Desensing is also not the problem: got the appropriate filters in place for that. Cheers,
Hans
BX2ABT
On 06/17/2019 10:52 PM, Mark L. Hammond wrote:
Hello Hans, I have not been working FS-3 recently, since the IC-9700 will not do 9600 packet [iCom, please fix!!] :(   So I cannot comment on recent uploads. However, to add to Bob's thoughts--are you running full duplex?  It's critical. Also, is your transmit signal desensitizing your receive signal?  That is important, too.Â
In the next week or so I will change radios at my station so I can again use FS-3. Â I'll be better able to share current experiences with you.
73,
Mark N8MH
On Mon, Jun 17, 2019 at 9:19 AM Hans BX2ABT via AMSAT-BB <amsat-bb@amsat.org mailto:amsat-bb@amsat.org> wrote:
I'm not behind my shack computer right now, but I know that PSGS and Direwolf each have a TX delay. Are you referring to those maybe being too long? If so, then why are all other commands (DL and directory listings) giving me no problem?
73 de Hans
BX2ABT
On 06/17/2019 08:53 PM, Robert Bruninga wrote: > I am no expert. But remember that your RF and all processing has to > be full duplex. The turn arround for packets in the satellite is > instantaneous. > with no TXD delays. Bob > > > On Mon, Jun 17, 2019 at 2:24 AM Hans BX2ABT via AMSAT-BB > <amsat-bb@amsat.org mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org mailto:amsat-bb@amsat.org>> wrote: > >   Up til now I have been successful in getting PacSatGroundStation >   (PSGS) >   to work on receive. You can go here if you want to see my setup: >   http://bx2abt.com/main/Falconsat-3 http://bx2abt.com/main/Falconsat-3 . I can hit FalconSat-3 with a >   directory request or file download request and get an immediate >   response >   and consequent downloads. Uploading is a different story, however. I >   have been able to get some messages uploaded, but it was more by >   chance. >   Right now if I want to upload I seem to get into a loop where PSGS >   keeps >   on sending out the same frame (I presume), then disconnects, after >   which >   the whole cycle starts over again. > >    From the PSGS debugging info you can see that I am successful in >   logging into PFS3-12. My file gets a designated ID (1f14 in this >   case) >   and is ready to be received. Then it uploads what I presume is one >   frame >   (you can see this in Direwolf where the same chunk of data is send >   over >   and over again) after which possibly the reason why things don't >   work: >   "ER_BODY_CHECK received while uploading: >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out". The only >   mention of ER_BODY_CHECK I can find on the internet is that it is >   sent >   when the checksum on the file body fails. After that the whole >   sequence >   starts again, so the message never gets uploaded and out of the queue. > >   Does this problem lie with FalconSat-3, Direwolf or PGSG, or >   somewhere >   else? Where is the checksum being made? This is my first forray into >   packet radio/PacSat, so I'm not an expert (yet). I don't want to make >   any (un)educated guesses, thus any help or hints are appreciated. >   Cheers, > >   Hans >   BX2ABT > > > >   This is the output (with debugging turned on) of PSGS: > >   --------BEGIN------- >   Open ABCD: >   Ready to upload file: BX2ABT17.txt.out >   B: 209908947. >   U>> >   DEBUG 3: Open: Adding UP LINK Event: UL_CONNECT >   PB: Empty.. >   I>>From:PFS3-12 to BX2ABT Ctrl: 0 Type: I Cmd PF: 0 NR: 0 NS: 0 >   5 2 cc >   a7 fb 5c 4> SUCCESSFUL LOGIN to PFS3-12 by BX2ABT >   DEBUG 3: Open: Adding UP LINK Event: From:PFS3-12 to BX2ABT Ctrl: 0 >   Type: I Cmd PF: 0 NR: 0 NS: 0 5 2 cc a7 fb 5c 4> SUCCESSFUL >   LOGIN to >   PFS3-12 by BX2ABT >   DEBUG 3: Cmd Ok: Adding UP LINK Event: UL_REQUEST_UPLOAD >   DEBUG 3: Cmd Ok: UL_CMD: From:BX2ABT to PFS3-12 Ctrl: 0 Type: I >   Cmd PF: >   0 NR: 0 NS: 0 8 3 14 1f 0 0 31 3 0 0 UL CMD: UPLOAD_CMD File: 1f14 >   Size: 331 >   S>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I Cmd PF: 0 NR: 1 NS: 1 >   8 4 >   14 1f 0 0 31 3 0 0> Ready to receive file: 1f14 from BX2ABT at >   off: 817 >   DEBUG 3: Waiting: Adding UP LINK Event: From:PFS3-12 to BX2ABT >   Ctrl: 22 >   Type: I Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to >   receive >   file: 1f14 from BX2ABT at off: 817 >   DEBUG 3: Waiting: UL_GO_RESP: From:PFS3-12 to BX2ABT Ctrl: 22 >   Type: I >   Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to receive >   file: >   1f14 from BX2ABT at off: 817 >   DEBUG 3: Waiting: GO FILE>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I >   Cmd >   PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to receive file: >   1f14 >   from BX2ABT at off: 817 >   DEBUG 3: Data: Adding UP LINK Event: UL_DATA_END >   DEBUG 3: Data: UL_DATA_END: UL_DATA_END >   S>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 44 Type: I Cmd PF: 0 NR: 2 NS: 2 >   1 7 >   10> UL NAK 16: ER_BODY_CHECK >   DEBUG 3: Data End: Adding UP LINK Event: From:PFS3-12 to BX2ABT >   Ctrl: 44 >   Type: I Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: ER_BODY_CHECK >   DEBUG 3: Data End: UL_NAK_RESP: From:PFS3-12 to BX2ABT Ctrl: 44 >   Type: I >   Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: ER_BODY_CHECK >   NAK: ER_BODY_CHECK received while uploading: >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out > >   TIME-1: PHT: uptime is 469/13:51:30. Time is Sat Jun 08 12:19:29 >   2019. >   U>> >   DEBUG 3: Idle: Adding UP LINK Event: UL_DISCONNECTED >   DEBUG 3: Idle: Adding UP LINK Event: Open ABCD: >   Open ABCD: >   B: 209908947. >   PB: Empty.. >   ---------END------- > >   This is what Direwolf's output is: > >   --------BEGIN------- >   PFS3-1 audio level = 68(+118/-110)  [NONE] ||||||||| >   [0.4] PFS3-1>LSTAT:I P:0x13A8 o:0 l:31473 f:31529, d:1 st:4 e:26<0x0d> >   Unknown APRS Data Type Indicator "I", Ambulance >   [0L] BX2ABT>PFS3-12:(SABM cmd, p=1) > >   PFS3-12 audio level = 69(+115/-111)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(UA res, f=0) > >   PFS3-12 audio level = 70(+119/-110)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=0, n(r)=0, p=0, >   pid=0xf0)<0x05><0x02>^<0xa8><0xfb><0x04> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=16, n(r)=120, p=0, >   pid=0x08)<0x08><0x03><0x14><0x1f><0x00><0x00>1<0x03><0x00><0x00> > >   PFS3-12 audio level = 70(+121/-110)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=0) > >   PFS3-12 audio level = 70(+121/-109)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=17, n(r)=120, p=0, >   pid=0x08)<0x04><0x14><0x1f><0x00><0x00><0xfe><0x00><0x00><0x00> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=1, n(r)=2, p=0, >   pid=0xf0)<0xfe><0x00> >   the internet server that you sent me a message on April 11, but >   unfortunately I never was able to download it. It took a while to get >   the transmitting part working, but now it does and I'm very >   pleased to >   be able to contact you via FS-3. Truly an amazin >   [0L] BX2ABT>PFS3-12:(RR cmd, n(r)=2, p=1) > >   PFS3-11 audio level = 65(+118/-109)  [NONE] ||||||||| >   [0.4] PFS3-11>PBLIST:PB: Empty.<0x0d> >   Unknown APRS Data Type Indicator "P", Original Balloon (think Ham b > >   PFS3-12 audio level = 66(+117/-109)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=1) >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=33, n(r)=120, p=0, >   pid=0x08)<0x08><0x03><0x00><0x00><0x00><0x00>1<0x03><0x00><0x00> > >   PFS3-12 audio level = 74(+125/-111)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(DISC cmd, p=1) >   [0L] BX2ABT>PFS3-12:(UA res, f=1) >   --------END------- > >   _______________________________________________ >   Sent via AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org>. AMSAT-NA >   makes this open forum available >   to all interested persons worldwide without requiring membership. >   Opinions expressed >   are solely those of the author, and do not reflect the official >   views of AMSAT-NA. >   Not an AMSAT-NA member? Join now to support the amateur satellite >   program! >   Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb https://www.amsat.org/mailman/listinfo/amsat-bb >
_______________________________________________ Sent via AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb https://www.amsat.org/mailman/listinfo/amsat-bb
-- Mark L. Hammond [N8MH]
Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
Sorry for the late reply. I've been a bit buried in other tasks.
I don't think I have seen this issue before. I have seen the issue were we keep requesting a file, even though it is fully downloaded, because FalconSat-3 changes the timestamps when it updates files. But I have not seen this issue. So I have logged it here: https://github.com/ac2cz/Falcon/issues/43
I'll check the code and see if I introduced an issue with some changes I did to fix another bug.
Can you send me the file that you have difficulty uploading? Or attach it to the github issue?
73 Chris
On Wed, Jun 19, 2019 at 7:32 AM Hans BX2ABT hans.bx2abt@msa.hinet.net wrote:
Okay, many hours googling and reading later......... I came upon two documents with some relevant information. First this is from the document "Pacsat File Header Definition". As it already says, it give a definition:
-------BEGIN------- 3.1.9 body_checksum
id : 0x09 length : 2 data : unsigned int body_checksum
A 16 bit checksum formed by adding all bytes in the file body into a 16 bit variable, ignoring overflow. The <body_checksum> does not include the bytes comprising the PACSAT file header.
The <body_checksum> is primarily intended to detect mis-corrected multi-bit errors caused by Single Event Upsets in the PACSAT memory.
INITIALIZATION - The correct <body_checksum> must be supplied. -------END-------
I don't quite understand the second but last sentence: does the PACSAT memory get upset by my messages?
From "Pacsat Protocol: File Transfer Level 0" document more on the upload procedures:
-------BEGIN------- 7.4. Completion of Upload
7.4.1 Successful Upload Completion
When the server receives the DATA_END packet it will check the integrity of the file as far as possible. If the checks pass, the server will downlink a UL_ACK_RESP packet.
Packet: UL_ACK_RESP Information: none
After transmitting the UL_ACK_RESP the server uplink state variable is UL_CMD_OK. After receiving the UL_ACK_RESP, the client uplink state variable is UL_CMD_OK.
7.4.2 Failure Caused by Server Rejecting Upload
The server may reject an upload while the client is sending DATA packets (due to file system problems on the server) or after the client has sent the DATA_END packet (due to corruption of the file).
If the server must abort the upload while receiving DATA packets or after receiving the DATA_END checks fail, it sends the UL_NAK_RESP packet.
Information: 1 byte unsigned char err_code; <err_code> must be one of:
ER_BAD_HEADER - The file either has no PFH, or has a badly-formed PFH. ER_HEADER_CHECK - The PFH checksum failed. ER_BODY_CHECK - The PFH body checksum failed. ER_NO_ROOM - The server ran out of room for file storage before the upload was complete. The server will implement procedures to avoid frequently running out of room, but this cannot be guaranteed.
After transmitting the UL_NAK_RESP packet, the server uplink state variable is UL_CMD_OK. After receiving the UL_ERROR_RESP, the client uplink state variable is UL_CMD_OK. -------END-------
So I clearly get a UL_NAK_RESP packet with the ER_BODY_CHECK error.
I also downloaded the PACSAT Ground Station software source code from G0KLA (hello Chris). The hex code for the BODY_CHECKSUM is 0x09. If you search for that in the source code you come up with the file Crc16.java. My coding skills are very minimal, so I don't grok the code completely, but I do see something strange in that file Crc16.java:
-------BEGIN-------
String s = "HELLO";
byte[] bytes = s.getBytes(); //Crc16 crc = new Crc16(bytes); short cs = 0; for(byte b : bytes) cs += b & 0xff; System.out.println(cs); PacSatField pf = new PacSatField(cs, 0x09); System.out.println(pf); }-------END-------
String s is probed for the number of bytes, then "converted" into variable cs, which is the PacSatField 0x09, iow the Body_Checksum. Now string s is simply "HELLO" and I don't see if this is hard coded or that this string changes according to the content of the message body. Any Java programmers here who want to help me look at it?
Any help appreciated. Cheers,
Hans
BX2ABT
On 06/18/2019 10:07 PM, Hans BX2ABT via AMSAT-BB wrote:
Hello all,
Got all your TESTING UPLOAD messages in loud and clear. My message to K4KDR didn't get send out. I'm still (re)searching about the cause of this. Later......
Hans
BX2ABT
On 06/18/2019 09:45 PM, Mark L. Hammond wrote:
Hi Hans,
I was able to upload a message (to you!) on FS-3 last night/this morning, fully automated. So the satellite is evidently behaving OK.
Hope you get it figured out. Since I don't use Direwolf, sorry I can't give any suggestions.
73,
Mark N8MH
At 08:07 AM 6/18/2019 +0800, Hans BX2ABT wrote:
I didn't write it directly, but I assumed from the description you would read that I indeed run full duplex (and to add to this: my system is Linux, not Windows). If not Direwolf will wait for a free window to throw out packets which will never happen because FS-3 is on all the time. No, everything is working, except for the problem I described before: all commands to the bird are heard and responded to, but uploading a message will fail.
Desensing is also not the problem: got the appropriate filters in place for that. Cheers,
Hans
BX2ABT
On 06/17/2019 10:52 PM, Mark L. Hammond wrote:
Hello Hans, I have not been working FS-3 recently, since the IC-9700 will not do 9600 packet [iCom, please fix!!] :(   So I cannot comment on recent uploads. However, to add to Bob's thoughts--are you running full duplex?  It's critical. Also, is your transmit signal desensitizing your receive signal?  That is important, too.Â
In the next week or so I will change radios at my station so I can again use FS-3. Â I'll be better able to share current experiences with you.
73,
Mark N8MH
On Mon, Jun 17, 2019 at 9:19 AM Hans BX2ABT via AMSAT-BB <amsat-bb@amsat.org mailto:amsat-bb@amsat.org> wrote:
I'm not behind my shack computer right now, but I know that PSGS and Direwolf each have a TX delay. Are you referring to those maybe being too long? If so, then why are all other commands (DL and directory listings) giving me no problem? 73 de Hans BX2ABT On 06/17/2019 08:53 PM, Robert Bruninga wrote: > I am no expert. But remember that your RF and all processing has to > be full duplex. The turn arround for packets in the satellite is > instantaneous. > with no TXD delays. Bob > > > On Mon, Jun 17, 2019 at 2:24 AM Hans BX2ABT via AMSAT-BB > <amsat-bb@amsat.org <mailto:amsat-bb@amsat.org> <mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org>>> wrote: > >   Up til now I have been successful in getting PacSatGroundStation >   (PSGS) >   to work on receive. You can go here if you want to see my setup: >   http://bx2abt.com/main/Falconsat-3 <http://bx2abt.com/main/Falconsat-3> . I can hit FalconSat-3with a >   directory request or file download request and get an immediate >   response >   and consequent downloads. Uploading is a different story, however. I >   have been able to get some messages uploaded, but it was more by >   chance. >   Right now if I want to upload I seem to get into a loop where PSGS >   keeps >   on sending out the same frame (I presume), then disconnects, after >   which >   the whole cycle starts over again. > >    From the PSGS debugging info you can see that I am successful in >   logging into PFS3-12. My file gets a designated ID (1f14 in this >   case) >   and is ready to be received. Then it uploads what I presume is one >   frame >   (you can see this in Direwolf where the same chunk of data is send >   over >   and over again) after which possibly the reason why things don't >   work: >   "ER_BODY_CHECK received while uploading: >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out". The only >   mention of ER_BODY_CHECK I can find on the internet is that it is >   sent >   when the checksum on the file body fails. After that the whole >   sequence >   starts again, so the message never gets uploaded and out of the queue. > >   Does this problem lie with FalconSat-3, Direwolf or PGSG, or >   somewhere >   else? Where is the checksum being made? This is my first forray into >   packet radio/PacSat, so I'm not an expert (yet). I don't want to make >   any (un)educated guesses, thus any help or hints are appreciated. >   Cheers, > >   Hans >   BX2ABT > > > >   This is the output (with debugging turned on) of PSGS: > >   --------BEGIN------- >   Open ABCD: >   Ready to upload file: BX2ABT17.txt.out >   B: 209908947. >   U>> >   DEBUG 3: Open: Adding UP LINK Event: UL_CONNECT >   PB: Empty.. >   I>>From:PFS3-12 to BX2ABT Ctrl: 0 Type: I Cmd PF: 0 NR: 0 NS: 0 >   5 2 cc >   a7 fb 5c 4> SUCCESSFUL LOGIN to PFS3-12 by BX2ABT >   DEBUG 3: Open: Adding UP LINK Event: From:PFS3-12 to BX2ABT Ctrl: 0 >   Type: I Cmd PF: 0 NR: 0 NS: 0 5 2 cc a7 fb 5c 4> SUCCESSFUL >   LOGIN to >   PFS3-12 by BX2ABT >   DEBUG 3: Cmd Ok: Adding UP LINK Event: UL_REQUEST_UPLOAD >   DEBUG 3: Cmd Ok: UL_CMD: From:BX2ABT to PFS3-12 Ctrl: 0 Type: I >   Cmd PF: >   0 NR: 0 NS: 0 8 3 14 1f 0 0 31 3 0 0 UL CMD: UPLOAD_CMD File: 1f14 >   Size: 331 >   S>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I Cmd PF: 0 NR: 1 NS: 1 >   8 4 >   14 1f 0 0 31 3 0 0> Ready to receive file: 1f14 from BX2ABT at >   off: 817 >   DEBUG 3: Waiting: Adding UP LINK Event: From:PFS3-12 to BX2ABT >   Ctrl: 22 >   Type: I Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to >   receive >   file: 1f14 from BX2ABT at off: 817 >   DEBUG 3: Waiting: UL_GO_RESP: From:PFS3-12 to BX2ABT Ctrl: 22 >   Type: I >   Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to receive >   file: >   1f14 from BX2ABT at off: 817 >   DEBUG 3: Waiting: GO FILE>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I >   Cmd >   PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to receive file: >   1f14 >   from BX2ABT at off: 817 >   DEBUG 3: Data: Adding UP LINK Event: UL_DATA_END >   DEBUG 3: Data: UL_DATA_END: UL_DATA_END >   S>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 44 Type: I Cmd PF: 0 NR: 2 NS: 2 >   1 7 >   10> UL NAK 16: ER_BODY_CHECK >   DEBUG 3: Data End: Adding UP LINK Event: From:PFS3-12 to BX2ABT >   Ctrl: 44 >   Type: I Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: ER_BODY_CHECK >   DEBUG 3: Data End: UL_NAK_RESP: From:PFS3-12 to BX2ABT Ctrl: 44 >   Type: I >   Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: ER_BODY_CHECK >   NAK: ER_BODY_CHECK received while uploading: >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out > >   TIME-1: PHT: uptime is 469/13:51:30. Time is Sat Jun 08 12:19:29 >   2019. >   U>> >   DEBUG 3: Idle: Adding UP LINK Event: UL_DISCONNECTED >   DEBUG 3: Idle: Adding UP LINK Event: Open ABCD: >   Open ABCD: >   B: 209908947. >   PB: Empty.. >   ---------END------- > >   This is what Direwolf's output is: > >   --------BEGIN------- >   PFS3-1 audio level = 68(+118/-110)  [NONE] ||||||||| >   [0.4] PFS3-1>LSTAT:I P:0x13A8 o:0 l:31473 f:31529, d:1 st:4 e:26<0x0d> >   Unknown APRS Data Type Indicator "I", Ambulance >   [0L] BX2ABT>PFS3-12:(SABM cmd, p=1) > >   PFS3-12 audio level = 69(+115/-111)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(UA res, f=0) > >   PFS3-12 audio level = 70(+119/-110)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=0, n(r)=0, p=0, >   pid=0xf0)<0x05><0x02>^<0xa8><0xfb><0x04> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=16, n(r)=120, p=0, >   pid=0x08)<0x08><0x03><0x14><0x1f><0x00><0x00>1<0x03><0x00><0x00> > >   PFS3-12 audio level = 70(+121/-110)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=0) > >   PFS3-12 audio level = 70(+121/-109)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=17, n(r)=120, p=0, >   pid=0x08)<0x04><0x14><0x1f><0x00><0x00><0xfe><0x00><0x00><0x00> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=1, n(r)=2, p=0, >   pid=0xf0)<0xfe><0x00> >   the internet server that you sent me a message on April 11, but >   unfortunately I never was able to download it. It took a while to get >   the transmitting part working, but now it does and I'm very >   pleased to >   be able to contact you via FS-3. Truly an amazin >   [0L] BX2ABT>PFS3-12:(RR cmd, n(r)=2, p=1) > >   PFS3-11 audio level = 65(+118/-109)  [NONE] ||||||||| >   [0.4] PFS3-11>PBLIST:PB: Empty.<0x0d> >   Unknown APRS Data Type Indicator "P", Original Balloon (think Ham b > >   PFS3-12 audio level = 66(+117/-109)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=1) >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=33, n(r)=120, p=0, >   pid=0x08)<0x08><0x03><0x00><0x00><0x00><0x00>1<0x03><0x00><0x00> > >   PFS3-12 audio level = 74(+125/-111)  [NONE] ||||||||| >   [0.4] PFS3-12>BX2ABT:(DISC cmd, p=1) >   [0L] BX2ABT>PFS3-12:(UA res, f=1) >   --------END------- > >   _______________________________________________ >   Sent via AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org>. AMSAT-NA >   makes this open forum available >   to all interested persons worldwide without requiring membership. >   Opinions expressed >   are solely those of the author, and do not reflect the official >   views of AMSAT-NA. >   Not an AMSAT-NA member? Join now to support the amateur satellite >   program! >   Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb https://www.amsat.org/mailman/listinfo/amsat-bb >
_______________________________________________ Sent via AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb <https://www.amsat.org/mailman/listinfo/amsat-bb>-- Mark L. Hammond [N8MH]
Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
Just uploaded log files and a message to GitHub. HTH. 73 de Hans (BX2ABT)
On 06/25/2019 05:21 AM, Chris Thompson wrote:
Sorry for the late reply. I've been a bit buried in other tasks.
I don't think I have seen this issue before. I have seen the issue were we keep requesting a file, even though it is fully downloaded, because FalconSat-3 changes the timestamps when it updates files. But I have not seen this issue. So I have logged it here: https://github.com/ac2cz/Falcon/issues/43
I'll check the code and see if I introduced an issue with some changes I did to fix another bug.
Can you send me the file that you have difficulty uploading? Or attach it to the github issue?
73 Chris
On Wed, Jun 19, 2019 at 7:32 AM Hans BX2ABT <hans.bx2abt@msa.hinet.net mailto:hans.bx2abt@msa.hinet.net> wrote:
Okay, many hours googling and reading later......... I came upon two documents with some relevant information. First this is from the document "Pacsat File Header Definition". As it already says, it give a definition: -------BEGIN------- 3.1.9 body_checksum id : 0x09 length : 2 data : unsigned int body_checksum A 16 bit checksum formed by adding all bytes in the file body into a 16 bit variable, ignoring overflow. The <body_checksum> does not include the bytes comprising the PACSAT file header. The <body_checksum> is primarily intended to detect mis-corrected multi-bit errors caused by Single Event Upsets in the PACSAT memory. INITIALIZATION - The correct <body_checksum> must be supplied. -------END------- I don't quite understand the second but last sentence: does the PACSAT memory get upset by my messages? From "Pacsat Protocol: File Transfer Level 0" document more on the upload procedures: -------BEGIN------- 7.4. Completion of Upload 7.4.1 Successful Upload Completion When the server receives the DATA_END packet it will check the integrity of the file as far as possible. If the checks pass, the server will downlink a UL_ACK_RESP packet. Packet: UL_ACK_RESP Information: none After transmitting the UL_ACK_RESP the server uplink state variable is UL_CMD_OK. After receiving the UL_ACK_RESP, the client uplink state variable is UL_CMD_OK. 7.4.2 Failure Caused by Server Rejecting Upload The server may reject an upload while the client is sending DATA packets (due to file system problems on the server) or after the client has sent the DATA_END packet (due to corruption of the file). If the server must abort the upload while receiving DATA packets or after receiving the DATA_END checks fail, it sends the UL_NAK_RESP packet. Information: 1 byte unsigned char err_code; <err_code> must be one of: ER_BAD_HEADER - The file either has no PFH, or has a badly-formed PFH. ER_HEADER_CHECK - The PFH checksum failed. ER_BODY_CHECK - The PFH body checksum failed. ER_NO_ROOM - The server ran out of room for file storage before the upload was complete. The server will implement procedures to avoid frequently running out of room, but this cannot be guaranteed. After transmitting the UL_NAK_RESP packet, the server uplink state variable is UL_CMD_OK. After receiving the UL_ERROR_RESP, the client uplink state variable is UL_CMD_OK. -------END------- So I clearly get a UL_NAK_RESP packet with the ER_BODY_CHECK error. I also downloaded the PACSAT Ground Station software source code from G0KLA (hello Chris). The hex code for the BODY_CHECKSUM is 0x09. If you search for that in the source code you come up with the file Crc16.java. My coding skills are very minimal, so I don't grok the code completely, but I do see something strange in that file Crc16.java: -------BEGIN------- String s = "HELLO"; byte[] bytes = s.getBytes(); //Crc16 crc = new Crc16(bytes); short cs = 0; for(byte b : bytes) cs += b & 0xff; System.out.println(cs); PacSatField pf = new PacSatField(cs, 0x09); System.out.println(pf); } -------END------- String s is probed for the number of bytes, then "converted" into variable cs, which is the PacSatField 0x09, iow the Body_Checksum. Now string s is simply "HELLO" and I don't see if this is hard coded or that this string changes according to the content of the message body. Any Java programmers here who want to help me look at it? Any help appreciated. Cheers, Hans BX2ABT On 06/18/2019 10:07 PM, Hans BX2ABT via AMSAT-BB wrote: > Hello all, > > Got all your TESTING UPLOAD messages in loud and clear. My message to > K4KDR didn't get send out. I'm still (re)searching about the cause of > this. Later...... > > Hans > > BX2ABT > > > On 06/18/2019 09:45 PM, Mark L. Hammond wrote: >> Hi Hans, >> >> I was able to upload a message (to you!) on FS-3 last night/this >> morning, fully automated. So the satellite is evidently behaving OK. >> >> Hope you get it figured out. Since I don't use Direwolf, sorry I >> can't give any suggestions. >> >> 73, >> >> Mark N8MH >> >> At 08:07 AM 6/18/2019 +0800, Hans BX2ABT wrote: >> >>> I didn't write it directly, but I assumed from the description you >>> would read that I indeed run full duplex (and to add to this: my >>> system is Linux, not Windows). If not Direwolf will wait for a free >>> window to throw out packets which will never happen because FS-3 is >>> on all the time. No, everything is working, except for the problem I >>> described before: all commands to the bird are heard and responded >>> to, but uploading a message will fail. >>> >>> Desensing is also not the problem: got the appropriate filters in >>> place for that. Cheers, >>> >>> Hans >>> >>> BX2ABT >>> >>> On 06/17/2019 10:52 PM, Mark L. Hammond wrote: >>>> Hello Hans, I have not been working FS-3 recently, since the >>>> IC-9700 will not do 9600 packet [iCom, please fix!!] :(   So I >>>> cannot comment on recent uploads. However, to add to Bob's >>>> thoughts--are you running full duplex?  It's critical. Also, is >>>> your transmit signal desensitizing your receive signal?  That is >>>> important, too. >>>> >>>> In the next week or so I will change radios at my station so I can >>>> again use FS-3.  I'll be better able to share current experiences >>>> with you. >>>> >>>> 73, >>>> >>>> Mark N8MH >>>> >>>> On Mon, Jun 17, 2019 at 9:19 AM Hans BX2ABT via AMSAT-BB >>>> <amsat-bb@amsat.org <mailto:amsat-bb@amsat.org> <mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org>>> wrote: >>>> >>>> I'm not behind my shack computer right now, but I know that PSGS >>>> and >>>> Direwolf each have a TX delay. Are you referring to those maybe >>>> being >>>> too long? If so, then why are all other commands (DL and >>>> directory >>>> listings) giving me no problem? >>>> >>>> 73 de Hans >>>> >>>> BX2ABT >>>> >>>> >>>> On 06/17/2019 08:53 PM, Robert Bruninga wrote: >>>> > I am no expert. But remember that your RF and all processing >>>> has to >>>> > be full duplex. The turn arround for packets in the >>>> satellite is >>>> > instantaneous. >>>> > with no TXD delays. Bob >>>> > >>>> > >>>> > On Mon, Jun 17, 2019 at 2:24 AM Hans BX2ABT via AMSAT-BB >>>> > <amsat-bb@amsat.org <mailto:amsat-bb@amsat.org> <mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org>> >>>> <mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org> <mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org>>>> wrote: >>>> > >>>> >   Up til now I have been successful in getting >>>> PacSatGroundStation >>>> >   (PSGS) >>>> >   to work on receive. You can go here if you want to see >>>> my setup: >>>> >   http://bx2abt.com/main/Falconsat-3 >>>> <http://bx2abt.com/main/Falconsat-3> . I can hit FalconSat-3 >>>> with a >>>> >   directory request or file download request and get an >>>> immediate >>>> >   response >>>> >   and consequent downloads. Uploading is a different >>>> story, however. I >>>> >   have been able to get some messages uploaded, but it >>>> was more by >>>> >   chance. >>>> >   Right now if I want to upload I seem to get into a loop >>>> where PSGS >>>> >   keeps >>>> >   on sending out the same frame (I presume), then >>>> disconnects, after >>>> >   which >>>> >   the whole cycle starts over again. >>>> > >>>> >    From the PSGS debugging info you can see that I am >>>> successful in >>>> >   logging into PFS3-12. My file gets a designated ID >>>> (1f14 in this >>>> >   case) >>>> >   and is ready to be received. Then it uploads what I >>>> presume is one >>>> >   frame >>>> >   (you can see this in Direwolf where the same chunk of >>>> data is send >>>> >   over >>>> >   and over again) after which possibly the reason why >>>> things don't >>>> >   work: >>>> >   "ER_BODY_CHECK received while uploading: >>>> >   >>>> /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out". The only >>>> >   mention of ER_BODY_CHECK I can find on the internet is >>>> that it is >>>> >   sent >>>> >   when the checksum on the file body fails. After that >>>> the whole >>>> >   sequence >>>> >   starts again, so the message never gets uploaded and >>>> out of the queue. >>>> > >>>> >   Does this problem lie with FalconSat-3, Direwolf or >>>> PGSG, or >>>> >   somewhere >>>> >   else? Where is the checksum being made? This is my >>>> first forray into >>>> >   packet radio/PacSat, so I'm not an expert (yet). I >>>> don't want to make >>>> >   any (un)educated guesses, thus any help or hints are >>>> appreciated. >>>> >   Cheers, >>>> > >>>> >   Hans >>>> >   BX2ABT >>>> > >>>> > >>>> > >>>> >   This is the output (with debugging turned on) of PSGS: >>>> > >>>> >   --------BEGIN------- >>>> >   Open ABCD: >>>> >   Ready to upload file: BX2ABT17.txt.out >>>> >   B: 209908947. >>>> >   U>> >>>> >   DEBUG 3: Open: Adding UP LINK Event: UL_CONNECT >>>> >   PB: Empty.. >>>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 0 Type: I Cmd PF: 0 >>>> NR: 0 NS: 0 >>>> >   5 2 cc >>>> >   a7 fb 5c 4> SUCCESSFUL LOGIN to PFS3-12 by BX2ABT >>>> >   DEBUG 3: Open: Adding UP LINK Event: From:PFS3-12 to >>>> BX2ABT Ctrl: 0 >>>> >   Type: I Cmd PF: 0 NR: 0 NS: 0 5 2 cc a7 fb 5c 4> >>>> SUCCESSFUL >>>> >   LOGIN to >>>> >   PFS3-12 by BX2ABT >>>> >   DEBUG 3: Cmd Ok: Adding UP LINK Event: UL_REQUEST_UPLOAD >>>> >   DEBUG 3: Cmd Ok: UL_CMD: From:BX2ABT to PFS3-12 Ctrl: 0 >>>> Type: I >>>> >   Cmd PF: >>>> >   0 NR: 0 NS: 0 8 3 14 1f 0 0 31 3 0 0 UL CMD: >>>> UPLOAD_CMD File: 1f14 >>>> >   Size: 331 >>>> >   S>> >>>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I Cmd PF: 0 >>>> NR: 1 NS: 1 >>>> >   8 4 >>>> >   14 1f 0 0 31 3 0 0> Ready to receive file: 1f14 from >>>> BX2ABT at >>>> >   off: 817 >>>> >   DEBUG 3: Waiting: Adding UP LINK Event: From:PFS3-12 to >>>> BX2ABT >>>> >   Ctrl: 22 >>>> >   Type: I Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 >>>> 0> Ready to >>>> >   receive >>>> >   file: 1f14 from BX2ABT at off: 817 >>>> >   DEBUG 3: Waiting: UL_GO_RESP: From:PFS3-12 to BX2ABT >>>> Ctrl: 22 >>>> >   Type: I >>>> >   Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready >>>> to receive >>>> >   file: >>>> >   1f14 from BX2ABT at off: 817 >>>> >   DEBUG 3: Waiting: GO FILE>From:PFS3-12 to BX2ABT >>>> Ctrl: 22 Type: I >>>> >   Cmd >>>> >   PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to >>>> receive file: >>>> >   1f14 >>>> >   from BX2ABT at off: 817 >>>> >   DEBUG 3: Data: Adding UP LINK Event: UL_DATA_END >>>> >   DEBUG 3: Data: UL_DATA_END: UL_DATA_END >>>> >   S>> >>>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 44 Type: I Cmd PF: 0 >>>> NR: 2 NS: 2 >>>> >   1 7 >>>> >   10> UL NAK 16: ER_BODY_CHECK >>>> >   DEBUG 3: Data End: Adding UP LINK Event: From:PFS3-12 >>>> to BX2ABT >>>> >   Ctrl: 44 >>>> >   Type: I Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: >>>> ER_BODY_CHECK >>>> >   DEBUG 3: Data End: UL_NAK_RESP: From:PFS3-12 to BX2ABT >>>> Ctrl: 44 >>>> >   Type: I >>>> >   Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: >>>> ER_BODY_CHECK >>>> >   NAK: ER_BODY_CHECK received while uploading: >>>> >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out >>>> > >>>> >   TIME-1: PHT: uptime is 469/13:51:30. Time is Sat Jun >>>> 08 12:19:29 >>>> >   2019. >>>> >   U>> >>>> >   DEBUG 3: Idle: Adding UP LINK Event: UL_DISCONNECTED >>>> >   DEBUG 3: Idle: Adding UP LINK Event: Open ABCD: >>>> >   Open ABCD: >>>> >   B: 209908947. >>>> >   PB: Empty.. >>>> >   ---------END------- >>>> > >>>> >   This is what Direwolf's output is: >>>> > >>>> >   --------BEGIN------- >>>> >   PFS3-1 audio level = 68(+118/-110)  [NONE] ||||||||| >>>> >   [0.4] PFS3-1>LSTAT:I P:0x13A8 o:0 l:31473 f:31529, d:1 >>>> st:4 e:26<0x0d> >>>> >   Unknown APRS Data Type Indicator "I", Ambulance >>>> >   [0L] BX2ABT>PFS3-12:(SABM cmd, p=1) >>>> > >>>> >   PFS3-12 audio level = 69(+115/-111)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(UA res, f=0) >>>> > >>>> >   PFS3-12 audio level = 70(+119/-110)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=0, n(r)=0, p=0, >>>> >   pid=0xf0)<0x05><0x02>^<0xa8><0xfb>\<0x04> >>>> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=16, n(r)=120, p=0, >>>> >   >>>> pid=0x08)<0x08><0x03><0x14><0x1f><0x00><0x00>1<0x03><0x00><0x00> >>>> > >>>> >   PFS3-12 audio level = 70(+121/-110)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=0) >>>> > >>>> >   PFS3-12 audio level = 70(+121/-109)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=17, n(r)=120, p=0, >>>> >   >>>> pid=0x08)<0x04><0x14><0x1f><0x00><0x00><0xfe><0x00><0x00><0x00> >>>> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=1, n(r)=2, p=0, >>>> >   pid=0xf0)<0xfe><0x00> >>>> >   the internet server that you sent me a message on April >>>> 11, but >>>> >   unfortunately I never was able to download it. It took >>>> a while to get >>>> >   the transmitting part working, but now it does and I'm >>>> very >>>> >   pleased to >>>> >   be able to contact you via FS-3. Truly an amazin >>>> >   [0L] BX2ABT>PFS3-12:(RR cmd, n(r)=2, p=1) >>>> > >>>> >   PFS3-11 audio level = 65(+118/-109)  [NONE] ||||||||| >>>> >   [0.4] PFS3-11>PBLIST:PB: Empty.<0x0d> >>>> >   Unknown APRS Data Type Indicator "P", Original Balloon >>>> (think Ham b >>>> > >>>> >   PFS3-12 audio level = 66(+117/-109)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=1) >>>> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=33, n(r)=120, p=0, >>>> >   >>>> pid=0x08)<0x08><0x03><0x00><0x00><0x00><0x00>1<0x03><0x00><0x00> >>>> > >>>> >   PFS3-12 audio level = 74(+125/-111)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(DISC cmd, p=1) >>>> >   [0L] BX2ABT>PFS3-12:(UA res, f=1) >>>> >   --------END------- >>>> > >>>> >   _______________________________________________ >>>> >   Sent via AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org> <mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>> >>>> <mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org> <mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>>>. AMSAT-NA >>>> >   makes this open forum available >>>> >   to all interested persons worldwide without requiring >>>> membership. >>>> >   Opinions expressed >>>> >   are solely those of the author, and do not reflect the >>>> official >>>> >   views of AMSAT-NA. >>>> >   Not an AMSAT-NA member? Join now to support the amateur >>>> satellite >>>> >   program! >>>> >   Subscription settings: >>>> https://www.amsat.org/mailman/listinfo/amsat-bb >>>> <https://www.amsat.org/mailman/listinfo/amsat-bb> >>>> > >>>> >>>> _______________________________________________ >>>> Sent via AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org> <mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>>. >>>> AMSAT-NA makes this open forum available >>>> to all interested persons worldwide without requiring >>>> membership. Opinions expressed >>>> are solely those of the author, and do not reflect the official >>>> views of AMSAT-NA. >>>> Not an AMSAT-NA member? Join now to support the amateur >>>> satellite program! >>>> Subscription settings: >>>> https://www.amsat.org/mailman/listinfo/amsat-bb >>>> <https://www.amsat.org/mailman/listinfo/amsat-bb> >>>> >>>> >>>> >>>> -- >>>> Mark L. Hammond [N8MH] > > _______________________________________________ > Sent via AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org>. AMSAT-NA makes this open forum available > to all interested persons worldwide without requiring membership. > Opinions expressed > are solely those of the author, and do not reflect the official views > of AMSAT-NA. > Not an AMSAT-NA member? Join now to support the amateur satellite > program! > Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb > > >-- Chris E. Thompson chrisethompson@gmail.com mailto:chrisethompson@gmail.com g0kla@arrl.net mailto:g0kla@arrl.net
Thanks to the hard work of Chris this issue has now been fixed. I just downloaded the latest version (v0.24) of PacSat Ground Station and was successful in uploading two messages. This was done on my Linux box (Kubuntu 19.04) with Direwolf v1.5 as soundmodem/PE. A flow chart of my setup can be found here: http://bx2abt.com/main/Falconsat-3.
Thanks again to Chris for writing this modern day PacSat software.
73 de Hans
BX2ABT
On 06/26/2019 10:32 AM, Hans BX2ABT via AMSAT-BB wrote:
Just uploaded log files and a message to GitHub. HTH. 73 de Hans (BX2ABT)
On 06/25/2019 05:21 AM, Chris Thompson wrote:
Sorry for the late reply. I've been a bit buried in other tasks.
I don't think I have seen this issue before. I have seen the issue were we keep requesting a file, even though it is fully downloaded, because FalconSat-3 changes the timestamps when it updates files. But I have not seen this issue. So I have logged it here: https://github.com/ac2cz/Falcon/issues/43
I'll check the code and see if I introduced an issue with some changes I did to fix another bug.
Can you send me the file that you have difficulty uploading? Or attach it to the github issue?
73 Chris
On Wed, Jun 19, 2019 at 7:32 AM Hans BX2ABT <hans.bx2abt@msa.hinet.net mailto:hans.bx2abt@msa.hinet.net> wrote:
Okay, many hours googling and reading later......... I came upon two documents with some relevant information. First this is from the document "Pacsat File Header Definition". As it already says, it give a definition:
-------BEGIN------- 3.1.9 body_checksum
id : 0x09 length : 2 data : unsigned int body_checksum
A 16 bit checksum formed by adding all bytes in the file body into a 16 bit variable, ignoring overflow. The <body_checksum> does not include the bytes comprising the PACSAT file header.
The <body_checksum> is primarily intended to detect mis-corrected multi-bit errors caused by Single Event Upsets in the PACSAT memory.
INITIALIZATION - The correct <body_checksum> must be supplied. -------END-------
I don't quite understand the second but last sentence: does the PACSAT memory get upset by my messages?
From "Pacsat Protocol: File Transfer Level 0" document more on the upload procedures:
-------BEGIN------- 7.4. Completion of Upload
7.4.1 Successful Upload Completion
When the server receives the DATA_END packet it will check the integrity of the file as far as possible. If the checks pass, the server will downlink a UL_ACK_RESP packet.
Packet: UL_ACK_RESP Information: none
After transmitting the UL_ACK_RESP the server uplink state variable is UL_CMD_OK. After receiving the UL_ACK_RESP, the client uplink state variable is UL_CMD_OK.
7.4.2 Failure Caused by Server Rejecting Upload
The server may reject an upload while the client is sending DATA packets (due to file system problems on the server) or after the client has sent the DATA_END packet (due to corruption of the file).
If the server must abort the upload while receiving DATA packets or after receiving the DATA_END checks fail, it sends the UL_NAK_RESP packet.
Information: 1 byte unsigned char err_code; <err_code> must be one of:
ER_BAD_HEADER - The file either has no PFH, or has a badly-formed PFH. ER_HEADER_CHECK - The PFH checksum failed. ER_BODY_CHECK - The PFH body checksum failed. ER_NO_ROOM - The server ran out of room for file storage before the upload was complete. The server will implement procedures to avoid frequently running out of room, but this cannot be guaranteed.
After transmitting the UL_NAK_RESP packet, the server uplink state variable is UL_CMD_OK. After receiving the UL_ERROR_RESP, the client uplink state variable is UL_CMD_OK. -------END-------
So I clearly get a UL_NAK_RESP packet with the ER_BODY_CHECK error.
I also downloaded the PACSAT Ground Station software source code from G0KLA (hello Chris). The hex code for the BODY_CHECKSUM is 0x09. If you search for that in the source code you come up with the file Crc16.java. My coding skills are very minimal, so I don't grok the code completely, but I do see something strange in that file Crc16.java:
-------BEGIN-------
String s = "HELLO";
byte[] bytes = s.getBytes();
//Crc16 crc = new Crc16(bytes); short cs = 0; for(byte b : bytes) cs += b & 0xff; System.out.println(cs);
PacSatField pf = new PacSatField(cs, 0x09); System.out.println(pf); } -------END-------
String s is probed for the number of bytes, then "converted" into variable cs, which is the PacSatField 0x09, iow the Body_Checksum. Now string s is simply "HELLO" and I don't see if this is hard coded or that this string changes according to the content of the message body. Any Java programmers here who want to help me look at it?
Any help appreciated. Cheers,
Hans
BX2ABT
On 06/18/2019 10:07 PM, Hans BX2ABT via AMSAT-BB wrote: > Hello all, > > Got all your TESTING UPLOAD messages in loud and clear. My message to > K4KDR didn't get send out. I'm still (re)searching about the cause of > this. Later...... > > Hans > > BX2ABT > > > On 06/18/2019 09:45 PM, Mark L. Hammond wrote: >> Hi Hans, >> >> I was able to upload a message (to you!) on FS-3 last night/this >> morning, fully automated. So the satellite is evidently behaving OK. >> >> Hope you get it figured out. Since I don't use Direwolf, sorry I >> can't give any suggestions. >> >> 73, >> >> Mark N8MH >> >> At 08:07 AM 6/18/2019 +0800, Hans BX2ABT wrote: >> >>> I didn't write it directly, but I assumed from the description you >>> would read that I indeed run full duplex (and to add to this: my >>> system is Linux, not Windows). If not Direwolf will wait for a free >>> window to throw out packets which will never happen because FS-3 is >>> on all the time. No, everything is working, except for the problem I >>> described before: all commands to the bird are heard and responded >>> to, but uploading a message will fail. >>> >>> Desensing is also not the problem: got the appropriate filters in >>> place for that. Cheers, >>> >>> Hans >>> >>> BX2ABT >>> >>> On 06/17/2019 10:52 PM, Mark L. Hammond wrote: >>>> Hello Hans, I have not been working FS-3 recently, since the >>>> IC-9700 will not do 9600 packet [iCom, please fix!!] :(   So I >>>> cannot comment on recent uploads. However, to add to Bob's >>>> thoughts--are you running full duplex?  It's critical. Also, is >>>> your transmit signal desensitizing your receive signal?  That is >>>> important, too. >>>> >>>> In the next week or so I will change radios at my station so I can >>>> again use FS-3.  I'll be better able to share current experiences >>>> with you. >>>> >>>> 73, >>>> >>>> Mark N8MH >>>> >>>> On Mon, Jun 17, 2019 at 9:19 AM Hans BX2ABT via AMSAT-BB >>>> <amsat-bb@amsat.org mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org mailto:amsat-bb@amsat.org>> wrote: >>>> >>>> I'm not behind my shack computer right now, but I know that PSGS >>>> and >>>> Direwolf each have a TX delay. Are you referring to those maybe >>>> being >>>> too long? If so, then why are all other commands (DL and >>>> directory >>>> listings) giving me no problem? >>>> >>>> 73 de Hans >>>> >>>> BX2ABT >>>> >>>> >>>> On 06/17/2019 08:53 PM, Robert Bruninga wrote: >>>> > I am no expert. But remember that your RF and all processing >>>> has to >>>> > be full duplex. The turn arround for packets in the >>>> satellite is >>>> > instantaneous. >>>> > with no TXD delays. Bob >>>> > >>>> > >>>> > On Mon, Jun 17, 2019 at 2:24 AM Hans BX2ABT via AMSAT-BB >>>> > <amsat-bb@amsat.org mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org mailto:amsat-bb@amsat.org> >>>> <mailto:amsat-bb@amsat.org mailto:amsat-bb@amsat.org <mailto:amsat-bb@amsat.org mailto:amsat-bb@amsat.org>>> wrote: >>>> > >>>> >   Up til now I have been successful in getting >>>> PacSatGroundStation >>>> >   (PSGS) >>>> >   to work on receive. You can go here if you want to see >>>> my setup: >>>> >   http://bx2abt.com/main/Falconsat-3 >>>> http://bx2abt.com/main/Falconsat-3 . I can hit FalconSat-3 >>>> with a >>>> >   directory request or file download request and get an >>>> immediate >>>> >   response >>>> >   and consequent downloads. Uploading is a different >>>> story, however. I >>>> >   have been able to get some messages uploaded, but it >>>> was more by >>>> >   chance. >>>> >   Right now if I want to upload I seem to get into a loop >>>> where PSGS >>>> >   keeps >>>> >   on sending out the same frame (I presume), then >>>> disconnects, after >>>> >   which >>>> >   the whole cycle starts over again. >>>> > >>>> >    From the PSGS debugging info you can see that I am >>>> successful in >>>> >   logging into PFS3-12. My file gets a designated ID >>>> (1f14 in this >>>> >   case) >>>> >   and is ready to be received. Then it uploads what I >>>> presume is one >>>> >   frame >>>> >   (you can see this in Direwolf where the same chunk of >>>> data is send >>>> >   over >>>> >   and over again) after which possibly the reason why >>>> things don't >>>> >   work: >>>> >   "ER_BODY_CHECK received while uploading: >>>> >   >>>> /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out". The only >>>> >   mention of ER_BODY_CHECK I can find on the internet is >>>> that it is >>>> >   sent >>>> >   when the checksum on the file body fails. After that >>>> the whole >>>> >   sequence >>>> >   starts again, so the message never gets uploaded and >>>> out of the queue. >>>> > >>>> >   Does this problem lie with FalconSat-3, Direwolf or >>>> PGSG, or >>>> >   somewhere >>>> >   else? Where is the checksum being made? This is my >>>> first forray into >>>> >   packet radio/PacSat, so I'm not an expert (yet). I >>>> don't want to make >>>> >   any (un)educated guesses, thus any help or hints are >>>> appreciated. >>>> >   Cheers, >>>> > >>>> >   Hans >>>> >   BX2ABT >>>> > >>>> > >>>> > >>>> >   This is the output (with debugging turned on) of PSGS: >>>> > >>>> >   --------BEGIN------- >>>> >   Open ABCD: >>>> >   Ready to upload file: BX2ABT17.txt.out >>>> >   B: 209908947. >>>> >   U>> >>>> >   DEBUG 3: Open: Adding UP LINK Event: UL_CONNECT >>>> >   PB: Empty.. >>>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 0 Type: I Cmd PF: 0 >>>> NR: 0 NS: 0 >>>> >   5 2 cc >>>> >   a7 fb 5c 4> SUCCESSFUL LOGIN to PFS3-12 by BX2ABT >>>> >   DEBUG 3: Open: Adding UP LINK Event: From:PFS3-12 to >>>> BX2ABT Ctrl: 0 >>>> >   Type: I Cmd PF: 0 NR: 0 NS: 0 5 2 cc a7 fb 5c 4> >>>> SUCCESSFUL >>>> >   LOGIN to >>>> >   PFS3-12 by BX2ABT >>>> >   DEBUG 3: Cmd Ok: Adding UP LINK Event: UL_REQUEST_UPLOAD >>>> >   DEBUG 3: Cmd Ok: UL_CMD: From:BX2ABT to PFS3-12 Ctrl: 0 >>>> Type: I >>>> >   Cmd PF: >>>> >   0 NR: 0 NS: 0 8 3 14 1f 0 0 31 3 0 0 UL CMD: >>>> UPLOAD_CMD File: 1f14 >>>> >   Size: 331 >>>> >   S>> >>>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 22 Type: I Cmd PF: 0 >>>> NR: 1 NS: 1 >>>> >   8 4 >>>> >   14 1f 0 0 31 3 0 0> Ready to receive file: 1f14 from >>>> BX2ABT at >>>> >   off: 817 >>>> >   DEBUG 3: Waiting: Adding UP LINK Event: From:PFS3-12 to >>>> BX2ABT >>>> >   Ctrl: 22 >>>> >   Type: I Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 >>>> 0> Ready to >>>> >   receive >>>> >   file: 1f14 from BX2ABT at off: 817 >>>> >   DEBUG 3: Waiting: UL_GO_RESP: From:PFS3-12 to BX2ABT >>>> Ctrl: 22 >>>> >   Type: I >>>> >   Cmd PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready >>>> to receive >>>> >   file: >>>> >   1f14 from BX2ABT at off: 817 >>>> >   DEBUG 3: Waiting: GO FILE>From:PFS3-12 to BX2ABT >>>> Ctrl: 22 Type: I >>>> >   Cmd >>>> >   PF: 0 NR: 1 NS: 1 8 4 14 1f 0 0 31 3 0 0> Ready to >>>> receive file: >>>> >   1f14 >>>> >   from BX2ABT at off: 817 >>>> >   DEBUG 3: Data: Adding UP LINK Event: UL_DATA_END >>>> >   DEBUG 3: Data: UL_DATA_END: UL_DATA_END >>>> >   S>> >>>> >   I>>From:PFS3-12 to BX2ABT Ctrl: 44 Type: I Cmd PF: 0 >>>> NR: 2 NS: 2 >>>> >   1 7 >>>> >   10> UL NAK 16: ER_BODY_CHECK >>>> >   DEBUG 3: Data End: Adding UP LINK Event: From:PFS3-12 >>>> to BX2ABT >>>> >   Ctrl: 44 >>>> >   Type: I Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: >>>> ER_BODY_CHECK >>>> >   DEBUG 3: Data End: UL_NAK_RESP: From:PFS3-12 to BX2ABT >>>> Ctrl: 44 >>>> >   Type: I >>>> >   Cmd PF: 0 NR: 2 NS: 2 1 7 10> UL NAK 16: >>>> ER_BODY_CHECK >>>> >   NAK: ER_BODY_CHECK received while uploading: >>>> >   /home/hans/PacSatGroundData/FalconSat-3/BX2ABT17.txt.out >>>> > >>>> >   TIME-1: PHT: uptime is 469/13:51:30. Time is Sat Jun >>>> 08 12:19:29 >>>> >   2019. >>>> >   U>> >>>> >   DEBUG 3: Idle: Adding UP LINK Event: UL_DISCONNECTED >>>> >   DEBUG 3: Idle: Adding UP LINK Event: Open ABCD: >>>> >   Open ABCD: >>>> >   B: 209908947. >>>> >   PB: Empty.. >>>> >   ---------END------- >>>> > >>>> >   This is what Direwolf's output is: >>>> > >>>> >   --------BEGIN------- >>>> >   PFS3-1 audio level = 68(+118/-110)  [NONE] ||||||||| >>>> >   [0.4] PFS3-1>LSTAT:I P:0x13A8 o:0 l:31473 f:31529, d:1 >>>> st:4 e:26<0x0d> >>>> >   Unknown APRS Data Type Indicator "I", Ambulance >>>> >   [0L] BX2ABT>PFS3-12:(SABM cmd, p=1) >>>> > >>>> >   PFS3-12 audio level = 69(+115/-111)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(UA res, f=0) >>>> > >>>> >   PFS3-12 audio level = 70(+119/-110)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=0, n(r)=0, p=0, >>>> >   pid=0xf0)<0x05><0x02>^<0xa8><0xfb><0x04> >>>> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=16, n(r)=120, p=0, >>>> >   >>>> pid=0x08)<0x08><0x03><0x14><0x1f><0x00><0x00>1<0x03><0x00><0x00> >>>> > >>>> >   PFS3-12 audio level = 70(+121/-110)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=0) >>>> > >>>> >   PFS3-12 audio level = 70(+121/-109)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(I cmd, n(s)=17, n(r)=120, p=0, >>>> >   >>>> pid=0x08)<0x04><0x14><0x1f><0x00><0x00><0xfe><0x00><0x00><0x00> >>>> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=1, n(r)=2, p=0, >>>> >   pid=0xf0)<0xfe><0x00> >>>> >   the internet server that you sent me a message on April >>>> 11, but >>>> >   unfortunately I never was able to download it. It took >>>> a while to get >>>> >   the transmitting part working, but now it does and I'm >>>> very >>>> >   pleased to >>>> >   be able to contact you via FS-3. Truly an amazin >>>> >   [0L] BX2ABT>PFS3-12:(RR cmd, n(r)=2, p=1) >>>> > >>>> >   PFS3-11 audio level = 65(+118/-109)  [NONE] ||||||||| >>>> >   [0.4] PFS3-11>PBLIST:PB: Empty.<0x0d> >>>> >   Unknown APRS Data Type Indicator "P", Original Balloon >>>> (think Ham b >>>> > >>>> >   PFS3-12 audio level = 66(+117/-109)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(RR res, n(r)=1, f=1) >>>> >   [0L] BX2ABT>PFS3-12:(I cmd, n(s)=33, n(r)=120, p=0, >>>> >   >>>> pid=0x08)<0x08><0x03><0x00><0x00><0x00><0x00>1<0x03><0x00><0x00> >>>> > >>>> >   PFS3-12 audio level = 74(+125/-111)  [NONE] ||||||||| >>>> >   [0.4] PFS3-12>BX2ABT:(DISC cmd, p=1) >>>> >   [0L] BX2ABT>PFS3-12:(UA res, f=1) >>>> >   --------END------- >>>> > >>>> >   _______________________________________________ >>>> >   Sent via AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org> >>>> <mailto:AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org>>. AMSAT-NA >>>> >   makes this open forum available >>>> >   to all interested persons worldwide without requiring >>>> membership. >>>> >   Opinions expressed >>>> >   are solely those of the author, and do not reflect the >>>> official >>>> >   views of AMSAT-NA. >>>> >   Not an AMSAT-NA member? Join now to support the amateur >>>> satellite >>>> >   program! >>>> >   Subscription settings: >>>> https://www.amsat.org/mailman/listinfo/amsat-bb >>>> https://www.amsat.org/mailman/listinfo/amsat-bb >>>> > >>>> >>>> _______________________________________________ >>>> Sent via AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org <mailto:AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org>. >>>> AMSAT-NA makes this open forum available >>>> to all interested persons worldwide without requiring >>>> membership. Opinions expressed >>>> are solely those of the author, and do not reflect the official >>>> views of AMSAT-NA. >>>> Not an AMSAT-NA member? Join now to support the amateur >>>> satellite program! >>>> Subscription settings: >>>> https://www.amsat.org/mailman/listinfo/amsat-bb >>>> https://www.amsat.org/mailman/listinfo/amsat-bb >>>> >>>> >>>> >>>> -- >>>> Mark L. Hammond [N8MH] > > _______________________________________________ > Sent via AMSAT-BB@amsat.org mailto:AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available > to all interested persons worldwide without requiring membership. > Opinions expressed > are solely those of the author, and do not reflect the official views > of AMSAT-NA. > Not an AMSAT-NA member? Join now to support the amateur satellite > program! > Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb > > >
-- Chris E. Thompson chrisethompson@gmail.com mailto:chrisethompson@gmail.com g0kla@arrl.net mailto:g0kla@arrl.net
Sent via AMSAT-BB@amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: https://www.amsat.org/mailman/listinfo/amsat-bb
participants (2)
-
Chris Thompson -
Hans BX2ABT