How do I display 115200 BAUD, N81 ASCII data in a text terminal?

[Robert_Mensah]

Hello All,

I am working with SirFStar4e GPS module. When the module is powered it transmits NMEA protocol at
4800 Baud, N81. I am able to receive the transmitted data (which include GGA, GSA, GSV) which I
display in ASCII in a text terminal. "SirfLive" (an application written by SirF which displays
data coming out of GPS module) displays same data that I get on my text terminal. The function
I used to configure the comport to read NMEA data is:
    OpenComConfig (1, "", 4800, 0, 8, 1, 20480, 20480);              // 4800 Baud, N81 at COM1.
I used item 3. under NOTES: (below) to display NMEA data on my text terminal.

The problem is when I switch from NMEA mode to One Socket Protocol (OSP) mode which is also
called "Binary" mode, the data that gets displayed on the text terminal once every second is the
character "¢". When I used "SirfLive" to view the data after I switched to OSP mode, "SirfLive"
indicated I am in OSP mode (which is what I wanted) and the data coming out (which is a lot)
was the correct OSP data at 115200 Baud, N81.

The question is why don't I get the same data in my text terminal as displayed in SirFLive
although I successfully switched from NMEA to OSP?

NOTES:
1. I used the two lines of code below to successfully switch from NMEA to OSP:
   BytesWritten = ComWrt (1, "$PSRF105,1*3E\r\n", 15);                     // Set Device data = ON.
   BytesWritten = ComWrt (1, "$PSRF100,0,115200,8,1,0*04\r\n", 28);  // Switch from NMEA to OSP.
    
2. To read OSP data I reconfigured comport as shown below:
   OpenComConfig (1, "", 115200, 0, 8, 1, 20480, 20480);                    // 115200 Baud, N81 at COM1.

3. To display data on my text terminal I used the three lines of code below:
   strLen = GetInQLen (1);                                                                 // Get length of data.
   BytesRead = ComRd (1, ReadBuffer, strLen);                                  // Save data in ReadBuffer.
   SetCtrlVal (SerialPanelHandle, SERIAL_RECEIVED, ReadBuffer);     // Display data.
 
4. Data being displayed is the character "¢" about one every second.

Will someone please help.
Thank you in advance.

Bob.

[RobertoBozzolo]

I made some search on google for Open Socket Protocol and found this document about the protocol that may apply to your situation. You are correctly pointing to the crucial concept when you say "One Socket Protocol (OSP) mode which is also called "Binary" mode": a binary communication mode is not as simple as text mode since messages are not in plain text; in binary modes each byte in the message must be decoded in a special way depending on the type of message, which is what probably does SirfLive application without explicitly telling it to you. Binary communication modes are more compact than plain text modes and so they may support faster transmission speeds, at the cost of some special effort to decode and handle them.

As per "¢" character you are receiving (0x4A), in the document I linked it is explained as MID_SESSION_CONTROL_RESP, that is a message sent in response to a request to open a session with the instrument, which I suppose is the meaning of the message you send to start OSP communication.

I never used SirFStar devices so what I am saying and the document I linked may not be the correct response to your question. Nevertheless, that binary you stated marks a path to the correct response, which is to find the correct documentation that applies to your instrument protocol and try translating the messages with it.

[Robert_Mensah]

Hello,

I have read the documentation you specified, and many more but none did help.

I need a way to display One Socket Protocol data from a GPS unit. Any help from anyone would be appreciated.

Thank you.

Bob

[RobertoBozzolo]

Bob,

I haven't a SirfStar unit here to interface so I cannot help you in detail.

Did you checked that the documentation I pointed you to is the correct one? Have you found additional resources that may apply to it?

Are you experienced in binary communication with external devices?

Can you copy here the content of a message you receive from the unit after switching to OSP mode? I mean, message lenght and the value of each byte in hex format: it could help to understand how to decode it.

[Robert_Mensah]

Hello Roberto,

I have attached some NMEA and OSP data with some descriptions of the data. I hope that would help.

Thank you.

Bob.

[RobertoBozzolo]

Hi Bob,
the message sniffed by Serial Port Monitor when using SirfLive seems to follow the description of the document I linked in my first answer. I'll show you part of the decoding task so that you can understand which work has to be done on received data.

General message structure (all bytes in hex format. Structure described at page 25 of that document):

A0 A2		>Message header
00 43		>Lenght of data
40 02 08 14 02 00 14 54 03 D3 2A 01
 E9 15 60 C2 A2 E6 0C 06 67 72 FF FD 00 0C 01 4A
 30 E4 FF FF FF C9 FF FF 8A 77 00 00 19 00 FC BE
 FE 5C 00 BC 00 00 01 63 00 22 01 4A 30 84 00 01
 00 00 00 00 00 00 01	   >Data
15 F8		        >Checksum
B0 B3		>End of message

Now, the "data" field contains as first characters the message ID and sub-ID:

40		>Navigation Library (NL)
02		>Auxiliary Measurement Data

These are described at page 340 of that document; let's look at some of the immediately following bytes:

08		>Satellite number
14		>General tracker status 0x14 = binary 00010100, which means:
		0
		0
		1	Possible cycle slip
		0
		1	Multipath detected
		0
		0
		0
02		>Tracker channel status: 0x02 = binary 00000010, that is:
		0
		1	False lock
		0
		0
		0
		0
		0
		0
00		>Bit sync quality
14 21 03 D3	>Time tag
...and so on

So the problem is what's happening when you switch from NMEA to OSP in your application as received messages apparently do not follow the standard: I don't have any documentation on the command you are issuing so I ask you to double check its structure and look for additional documentation on the time immediately following that point.

As you see, decoding a binary transmission is a boring task as each individual byte must be checked against the documentation and appropriately handled, without forgetting to check for message checksum as the first operation. On the other hand, binary transmission usually gives you more informations than plain text communications using shorter messages. The problem thus becomes: do you really need to use OSP protocol in your application? And is this worth the effort?

As a last hint, as I already told you it would be useful too to observe the raw content of received messages in your application, that is hex value together with corresponding text format like in the output from Serial Port Monitor.

[Robert_Mensah]

Hello Roberto,

I have checked over your response and you are correct. The detailed example you gave is for decoding and extracting information from OSP protocol data. This implies that you already have the OSP data.

The problem I have is that I do not get the correct OSP data displayed on my hyperterminal (although I have successfully switched from NMEA to OSP). Without the correct OSP data I would not know which data to fetch and parse to obtain the information I want.

The reason I need to use OSP is that I need to e.g. poll software version from the GPS module, poll Almanac, poll Ephemeris, poll Navigational parameters etc. non of which is available in NMEA mode.

So, the question still remains:     How do I display OSP data from a GPS module (using CVI) for it to display as it is displayed by SirfLive?

Help is still needed.

Thank you.

Bob

[RobertoBozzolo]

Robert,

as I already told you, I have no experience on SiRFStar communication.

Looking in the Internet I have found this document that offers some information more. As I said previously, this may or may not apply to your actual device, so the basic question comes back again: have you some specific documentation on your device? Where have you taken those commands to switch between the two standards? Are they correct?

I have noted these details by reading that document:

1. ComWrt (1, "$PSRF105,1*3E\r\n", 15); with this command you enable the sendback of additional informations from the device on possible causes of errors. As far as I can understand, this means that on a incorrect / wrong / damaged message the device will return some error informations. I got no descriptions on those additional informations but you should look for them, as the message you are receiving may be one of them (last resort hint: have you tried disabling this mode?)

2. ComWrt (1, "$PSRF100,0,115200,8,1,0*04\r\n", 28); the last two bytes of the message ("04") are a checksum on the message itself. How have you calculated it? Is it correct?