0

I am writing a program to capture serial data from an old GPS unit (Garmin Etrex Venture) connected to a PC. After sending a 'send time' packet to the unit, I use a readfile from the COM3 port (hCom).

int read_packet()   //READS PACKET FROM DEVICE hPort
    {
        unsigned char inbuff[64]; 
        unsigned char inchar [1];
        DWORD nb;
        int j=0;
        ReadFile(hPort, inbuff, 32, &nb, NULL); int k; for (j;j<25;j++) {printf("<read_packet> inbuff[%i] = %i \n",j,int(inbuff[j]));

        //for (j=0;j<25;j++) {ReadFile(hPort, inchar, 1, &nb, NULL); printf("<read_packet> inchar[%i]: %i \n",j,int(inchar[0]));
        }
    return 0;
    }

Valid packets start with 0x10 and end in 0x10 0x03. I expect to see an ACK packet (0x06) and then a second packet containing the actual time.

When reading the data all in one go to inbuff, the read continues after the final 0x03 at inbuff[21] with what seem to be nonsense values: 

<read_packet> inbuff[0] = 16
<read_packet> inbuff[1] = 6
<read_packet> inbuff[2] = 2
<read_packet> inbuff[3] = 10
<read_packet> inbuff[4] = 0
<read_packet> inbuff[5] = 238
<read_packet> inbuff[6] = 16
<read_packet> inbuff[7] = 3
<read_packet> inbuff[8] = 16
<read_packet> inbuff[9] = 14
<read_packet> inbuff[10] = 8
<read_packet> inbuff[11] = 9
<read_packet> inbuff[12] = 14
<read_packet> inbuff[13] = 225
<read_packet> inbuff[14] = 7
<read_packet> inbuff[15] = 22
<read_packet> inbuff[16] = 0
<read_packet> inbuff[17] = 12
<read_packet> inbuff[18] = 25
<read_packet> inbuff[19] = 176
<read_packet> inbuff[20] = 16
<read_packet> inbuff[21] = 3
<read_packet> inbuff[22] = 42
<read_packet> inbuff[23] = 0
<read_packet> inbuff[24] = 32

When I uncomment the second line and read one character at a time, I received the 2 packets expected (although keeps reading the final 0x03):

<read_packet> inchar[0]: 16
<read_packet> inchar[1]: 6
<read_packet> inchar[2]: 2
<read_packet> inchar[3]: 10
<read_packet> inchar[4]: 0
<read_packet> inchar[5]: 238
<read_packet> inchar[6]: 16
<read_packet> inchar[7]: 3
<read_packet> inchar[8]: 16
<read_packet> inchar[9]: 14
<read_packet> inchar[10]: 8
<read_packet> inchar[11]: 9
<read_packet> inchar[12]: 14
<read_packet> inchar[13]: 225
<read_packet> inchar[14]: 7
<read_packet> inchar[15]: 22
<read_packet> inchar[16]: 0
<read_packet> inchar[17]: 12
<read_packet> inchar[18]: 0
<read_packet> inchar[19]: 201
<read_packet> inchar[20]: 16
<read_packet> inchar[21]: 3
<read_packet> inchar[22]: 3
<read_packet> inchar[23]: 3
<read_packet> inchar[24]: 3

Can anyone advise why the first situation using inbuff happens? I guess that it happens because the Readfile does not know when to stop reading. However I don't understand where the additional values after inbuff[21] are coming from.

Thanks.

Vahid Boreiri
  • 3,418
  • 1
  • 19
  • 34
user19425
  • 11
  • 3
  • ReadFile() returns whatever is available in the receive buffer, it doesn't know beans about "packets". You *must* pay attention to `nb`. – Hans Passant Sep 14 '17 at 22:46
  • According to a Garmin document I am looking at, "there is some possibility that the GPS will transmit a few extra bytes at the end of the data... you can safely ignore the extra bytes." They recommend using the "Protocol Capabilities Protocol" to find the expected length of data for receiving. – ttemple Sep 15 '17 at 01:16
  • So I added `nb` to the `prinft` as well as the actual value. For the second example, `nb` is 1 as you would expect until it gets to the end of the sequence at `inchar[21]` and drops to 0. For the first example, the value of `nb` seems to vary arbitrarily despite sending the same request each time: 3, 18, 16, 8, 6, 17....and the `inbuf` values do not appear meaningful. Guess I'll stick with reading 1 byte at a time! – user19425 Sep 19 '17 at 13:20
  • ...and thank you both for your comments. – user19425 Sep 19 '17 at 13:27

0 Answers0