Reading Packets?

[SwingeyP]

Hi again.

Today's quiz is this...

I have a GPS module which produces this output every second.

10 82 02 10 03 
10 46 00 01 10 03 
10 4B 5A 00 01 10 03 
10 6D 64 40 4A 74 CE 3F C9 7F 37 40 2F 9B BD 40 0F 78 36 09 1A 1C 05 08 0F 10 03 
10 82 02 10 03 
10 5C 18 00 02 00 00 00 00 00 48 ED C7 CB 3E 9B 15 5D 40 87 F1 54 00 00 00 01 10 03 
10 5C 09 08 01 02 40 AC CC CD 48 ED C7 CB 3F 9F 79 1B 40 87 0C 68 00 00 00 01 10 03 
10 5C 1A 10 01 02 41 03 33 33 48 ED C7 CB 3F B3 84 83 3F DA 0D EE 00 00 00 01 10 03 
10 5C 1C 18 01 02 41 03 33 33 48 ED C7 CB 3F 67 0C 74 3F D3 97 93 00 00 00 01 10 03 
10 5C 05 20 01 02 40 C6 66 66 48 ED C7 CB 3F 1B 37 E0 40 4F D8 66 00 00 00 01 10 03 
10 5C 08 28 01 02 40 D9 99 9A 48 ED C7 CB 3F 14 C4 19 3F 86 49 FA 00 00 00 01 10 03 
10 5C 15 30 02 00 00 00 00 00 48 ED C7 CB 3E 7D 55 84 40 A5 9A BD 00 00 00 01 10 03 
10 5C 0F 38 01 02 40 26 66 66 48 ED C7 CB 3F 75 01 93 40 A1 75 DA 00 00 00 01 10 03 
10 41 48 ED C7 CB 06 C3 41 80 00 00 10 03 
10 8F 20 00 00 00 00 00 00 00 1D 06 A6 18 25 60 AA 3A FE A6 B9 31 00 03 8B 80 00 00 01 18 06 00 06 C3 09 5D 1A 53 1C 46 05 5A 08 09 0F 35 00 00 00 00 17 01 FE 00 3C 00 FC 03 10 03 
10 6D 64 40 4A 74 CE 3F C9 7F 37 40 2F 9B BD 40 0F 78 36 09 1A 1C 05 08 0F 10 03

I need to read this somewhow looking for a change in this packet - 10 46 00 01 10 03

At cold start with no satelite info the packet (status) sends 10 46 01 01 10 03

I need to see the status change of this packet but I am also confused as how to read all the other packets or ignore them. Ho to I synchronise my read with what is being sent?

I have this at present

'-- Read data from the GPS
Hseropen 9600

getdata:
Hserin data(0)  '10
Hserin data(1)  '46

If data(0) = 0x10 And data(1) = 0x46 Then  'Status Packet
	Hserin data(2)
	Hserin data(3)
	Hserin data(4)
	Hserin data(5)
	Lcdcmdout LcdLine1Pos(1)
	Lcdout #data(2), " ", #data(3), " ", #data(4), " ", #data(5), "     "
Else
	Lcdcmdout LcdLine1Pos(1)
	Lcdout "Waiting"
Endif

WaitMs 500
Goto getdata

but it doesn't work in that when the status packet is updated I always see 10 46 01 01 10 13 - or 1 1 16 3 in my case. - I'm sure ths is because things are out of sync.

Any ideas?

Regards - Paul

 

[ericgibbs]

hi Paul,
In your block listing of the Data, is there a CR/LF and/or a Carriage Return, Line Feed code, ???

ie: 0x0D , 0x0A at the end of each line of data.

Eric

EDIT:
also see that every line ends with '03'

 

[SwingeyP]

Hi Eric,

No CrLF that I know of. I do see the 03 at the end of every line. All packets begin 10 and end 03 but they are varying length and how do you know where in the packet list you are at start up. I thought of doing some kind of while loop but i'm not sure you can do this around a hserin.

How to know which packet you are reading? If you just looked for the 03 that could appear as data in any of the packets along with the 10 at the begining. The only thing I can see is that a packet 10 46 is never repeated along with 10 82 - 10 4B - 10 6D .. ie the first two of every packet. They are reffered to like this in the manual - 0x46 - This is the status packet.

I thought if I read 10 46 i'd know this was the status packet and I expect to see 4 more hserin.

If it was a 10 5C i'd expect a further 26 hserin's ... Does this make sense?

Hserin waits until something appears so wont the above code just loop until it sees 10 46 again? - It appears not :-(

I'm a bit stuck with this one ...

Regards - Paul

 

[jpanhalt]

I don't understand the code, but I see a slightly different pattern. Every line ends with 10 03; 03 alone exists in several lines. 10 is the first character of every line and after a line ends with 10 03. The key apparently is the 10 03 (line end), as 10 by itself also appears elsewhere.

Also, the second hex appears to correlate with the line length. Maybe that is the key.

Don't know if that helps, but it is a little different than defining a line beginning.

John

 

[languer]

Something like the following state machine should give you a start...

'General Configuration
Define CONF_WORD = 0x33c4  'for internal 8MHz osc

'Oscillator/Clock Configuration for internal 8MHz osc
Define CLOCK_FREQUENCY = 8
OSCCON = 0x71

'Debug Option
Dim debug As Bit
	debug = True
	debug = False

'Variable Declarations
'>>I/O
	Symbol out_rs232 = RB7  'rs232 output (HW UART)
	Symbol in_rs232 = RB5  'rs232 input (HW UART)
	Const _trisa = %11111111
	Const _trisb = %01011111
	Const _trisc = %11111111
'>>Variables
	Dim gps_array(6) As Byte
	Dim _true As Bit
	Dim _false As Bit
	_true = True
	_false = False
	Const stx_byte1 = 0x10
	Const stx_byte2 = 0x46
	Const etx_byte1 = 0x03

'Main Program
	'-- Read data from the GPS
	Hseropen 9600

	Dim idx As Byte
	Dim gps_byte As Byte
	
	idx = 0
	gps_byte = 0

	'scan through gps bytes
	While _true
		Select Case idx
		Case 0  'if first byte matches store it and increment counter, otherwise reset counter
			Hserin gps_byte  'get gps byte
			If gps_byte = stx_byte1 Then
				gps_array(idx) = gps_byte
				idx = idx + 1
			Else
				idx = 0
			Endif
		Case 1  'if second byte matches store it and increment counter, otherwise reset counter
			Hserin gps_byte  'get gps byte
			If gps_byte = stx_byte2 Then
				gps_array(idx) = gps_byte
				idx = idx + 1
			Else
				idx = 0
			Endif
		Case 5  'if last byte matches store it and display, reset counter either way
			Hserin gps_byte  'get gps byte
			If gps_byte = etx_byte1 Then
				gps_array(idx) = gps_byte
				Call display_gps_sentence()
			Endif
			idx = 0
		Case Else  'store byte and increment counter
			Hserin gps_byte  'get gps byte
			gps_array(idx) = gps_byte
			idx = idx + 1
		EndSelect
	Wend
End                                               

Proc display_gps_sentence()
	Dim idx As Byte
	For idx = 0 To 5
		Hserout gps_array(idx), " "
	Next idx
	Hserout CrLf

 

[SwingeyP]

Well I know why the code doesn't work. After the first time round it never sees 10 46 as a pair again so that idea was rubbish.

What do you mean the 2nd hex correlates to the line length?

Regards - Paul

 

[JimB]

You appear to be reading the output of the GPS in TISP format.

Can I suggest that it may be easier to use NMEA 0183 format which appears to be available from this GPS module.
The NMEA messages all start with the $ symbol, and end with [CR[]LF], and the data fields within the message are comma separated.

I assume that you have the manual for this GPS?
If not, it can be downloaded from here:
https://data.manualslib.com/pdf/19/...oors/sk8.pdf?fb3088076d870a90bea6fc21b4d45460

JimB

 

[Ian Rogers]

You appear to be reading the output of the GPS in TISP format.

Can I suggest that it may be easier to use NMEA 0183 format which appears to be available from this GPS module.
The NMEA messages all start with the $ symbol, and end with [CR[]LF], and the data fields within the message are comma separated.

I assume that you have the manual for this GPS?
If not, it can be downloaded from here:
https://data.manualslib.com/pdf/19/...oors/sk8.pdf?fb3088076d870a90bea6fc21b4d45460

JimB

My thoughts exactly.... I have a slightly different module, the NMEA sentences are standard... There are a few types each with there own data in

$GPBOD - Bearing, origin to destination
$GPBWC - Bearing and distance to waypoint, great circle
$GPGGA - Global Positioning System Fix Data
$GPGLL - Geographic position, latitude / longitude
$GPGSA - GPS DOP and active satellites
$GPGSV - GPS Satellites in view
$GPHDT - Heading, True
$GPR00 - List of waypoints in currently active route
$GPRMA - Recommended minimum specific Loran-C data
$GPRMB - Recommended minimum navigation info
$GPRMC - Recommended minimum specific GPS/Transit data
$GPRTE - Routes
$GPTRF - Transit Fix Data
$GPSTN - Multiple Data ID
$GPVBW - Dual Ground / Water Speed
$GPVTG - Track made good and ground speed
$GPWPL - Waypoint location
$GPXTE - Cross-track error, Measured
$GPZDA - Date & Time

I only use $GPGLL

eg3. $GPGLL,5133.81,N,00042.25,W*75
1 2 3 4 5

1 5133.81 Current latitude
2 N North/South
3 00042.25 Current longitude
4 W East/West
5 *75 checksum

Everything else I dismiss...

 

[SwingeyP]

Hi thanks for thaT. I'll have at look at that protocol.

I am perplexed as to why this doesn't work though. - Fine in simulation but not in the real world. What i am trying to do is read the data from the status packet and just display it. I'll then look to see the change in byte 2 to see if satelites have come on line yet.

So this code posted by languer earlier looks good.

Define CONF_WORD = 0x3f50  'Internal Oscillator'
Define CLOCK_FREQUENCY = 4
AllDigital

'Define the comms for the LCD display.
Define LCD_LINES = 4
Define LCD_CHARS = 20
Define LCD_BITS = 4
Define LCD_DREG = PORTB
Define LCD_DBIT = 4  'Use the high order bits'
Define LCD_RSREG = PORTA
Define LCD_RSBIT = 2
Define LCD_EREG = PORTA
Define LCD_EBIT = 0
Define LCD_RWREG = PORTA
Define LCD_RWBIT = 1
Define LCD_READ_BUSY_FLAG = 1


Define LCD_COMMANDUS = 5000  'delay after LCDCMDOUT, default value is 5000
Define LCD_DATAUS = 100  'delay after LCDOUT, default value is 100
Define LCD_INITMS = 20


Define SEROUT_DELAYUS = 1000

Symbol txcr_pin = PORTA.7
Dim i As Byte  'used for loops
Dim j As Byte  'used for loops
Dim pos As Byte  'used for lcd position
Dim ch As Byte  'used to hold individual character
Dim times_sent As Byte  'used to check number of times sent before waiting

Dim data(5) As Byte  'Array to store raw Data (Remember 0-3)

startup:
Lcdinit LcdCurBlink
Lcdcmdout LcdClear
Lcdcmdout LcdLine1Pos(1)
Lcdout "Pause ...... "


WaitMs 50
Lcdcmdout LcdClear

'-- Read data from the GPS#

	Dim gps_array(6) As Byte
	Dim _true As Bit
	Dim _false As Bit
	_true = True
	_false = False
	Const stx_byte1 = 0x10
	Const stx_byte2 = 0x46
	Const etx_byte1 = 0x03


	Hseropen 9600

	Dim idx As Byte
	Dim gps_byte As Byte

	idx = 0
	gps_byte = 0
While _true
	'scan through gps bytes
	Select Case idx
		Lcdcmdout LcdLine2Pos(1)
		Lcdout "idx - ", #idx
		Case 0  'if first byte matches store it and increment counter, otherwise reset counter
			Hserin gps_byte  'get gps byte
			If gps_byte = stx_byte1 Then
				gps_array(idx) = gps_byte
				idx = idx + 1
			Else
				idx = 0
			Endif
		Case 1  'if second byte matches store it and increment counter, otherwise reset counter
			Hserin gps_byte  'get gps byte
			If gps_byte = stx_byte2 Then
				gps_array(idx) = gps_byte
				idx = idx + 1
			Else
				idx = 0
			Endif
		Case 5  'if last byte matches store it and display, reset counter either way
			Hserin gps_byte  'get gps byte
			If gps_byte = etx_byte1 Then
				gps_array(idx) = gps_byte
				Call display_gps_sentence()
			Endif
			idx = 0
		Case Else  'store byte and increment counter
			Hserin gps_byte  'get gps byte
			gps_array(idx) = gps_byte
			idx = idx + 1
	EndSelect
Wend
End                                               

Proc display_gps_sentence()
	Dim idx As Byte
	pos = 1
	For idx = 0 To 5
		'Hserout gps_array(idx), " "
		Lcdcmdout LcdLine1Pos(pos)
		Lcdout #gps_array(idx), " "
		pos = pos + 3
	Next idx
	'Hserout CrLf
Return

Problem is it never updates in the real world. After the first read - (I put a delay in to make sure I wasn't fluking a read right at the start).

I'd like to solve this using TSIP first.

Regards - Paul

 

[alec_t]

Could Case 5 be the problem? 03 is always at the end of a line but if it also occurred mid-line wouldn't it cause a false sentence display?

 

[SwingeyP]

Hmmm it appears it was a fluke first time round. I have set the delay as waitms 5000 and it now never updates ...

 

[SwingeyP]

Hi alec_t.

The case works perfectly in simulation and does exactly what it should. The 5 is looking at the 5th element of the packet once the other cases have been fulfilled. Setting the idx back to zero each time if not.
It works like this - read the data is it 10 yes read the data is it 46 read the data (doesn't matter what ths is just store it - 01) read data (doesn't matter what ths is just store it -01) read the data is it 10 yes = read the data is it 03 - display the data.

If at any time any of the reads don't work the idx is set to 0 and the whole process starts again. That way you are scanning all the packets looking for 10 46 xx xx 10 03.

Works great in simulation as I said - just dies in the real world.

I am using a 16f628a with internal (as im lazy) maybe I need to up the clock speed?


I did have a look at using the other protocol mentioned earlier but I can't get the trimble Studio to congigure properly .... so i'm a bit stuck with this at present.

Regards - Paul

 

[SwingeyP]

Ok having messed about all day with this and really got nowhere can anyone tell me how to get the SK8 into NMEA mode. I have TSIP CHAT, and TrimbleStudio_V1-01-21. This is the only software I have for talking to the GPS unit. The trimble studio doesn't seem to recognise the SK8 - I think it's very old. I would like to get it going though so does anyone know what to do to get it into NMEA mode?

Regards - Paul

 

[ericgibbs]

hi Paul,
Check this pdf out, it may help.
Eric

 

[SwingeyP]

Hi Eric.

I have that manual and read and read and read it .... Having just read it again I realise I have spent all day requesting data from the wrong port. NMEA = PORTB - Aghhhhh!!!! %$%$^%^$%

I'll start again ....

I'm in the wood but can see no trees ....

Regards - Paul

 

[SwingeyP]

I feel such an idiot. moved the wires to PORTB and lots of lovely NMEA data pouring out ..... Ah well another lesson learned.

 

[languer]

Did you try without updating the LCD until after you have completed the capture of the valid data?

		Lcdcmdout LcdLine2Pos(1)
		Lcdout "idx - ", #idx

Reason is you have 1 sec between updates, but you have very little time between bytes once the message starts. So you want to do all processing first, and then do the slower update to the outside world.

Hi alec_t.
The case works perfectly in simulation and does exactly what it should. The 5 is looking at the 5th element of the packet once the other cases have been fulfilled. Setting the idx back to zero each time if not.
...
Regards - Paul

 

[SwingeyP]

Hi Lanquer.

I realised that was the problem but have now switched to NMEA protocal. I have started a new thread on this and could really use some help.

Regards - Paul

 

[languer]

Even though the following may not be norm, I'll say it anyways. The NMEA protocol is actually harder to decode than the lower-level (platform-specific) ones (e.g. TSIP). The reason for this is that the NMEA protocol is made to be easily read (by a human or a PC), and universal. But by the same token it requires a lot more characters (i.e. bytes) to communicate the same information; so it's a lot less efficient - which also means you have to do a lot more parsing and storing to collect the same data.

As an example take the Health-of-the-Receiver message; the TSIP indicates this message is available with two bytes: 0x10 and 0x46. NMEA on the other hand gives you 6 bytes: $GPGSV.

That being said, the NMEA protocol is super popular and there are tons of examples. But when you want to streamline and reduce overhead, then you know other options are better suited.

 

[SwingeyP]

I would MUCH rather have gone with TSIP. I find it a lot easier to understand what is being transmitted and how to store it. The string functions in OSHON appear poorly represented to a novice like me and despite knowing what I wanted to do in basic I just couldn't get any syntax to run.

I will return to this with a little more research on the correct pic to use and trying to either sort the timing issue or stopping the data from polling until requested.

Your case code made perfect sense to me and im sure i'll use that method in the future.

Many thanks for all the help.

Regards - Paul