GPS clock timing !

[skimask]

I'd like to build a small Clock with GPS time-sync, look, I'm using the Darrel instant interrups to drive the Timer 1 clock, it works great ! (Thanks Darrel !), but when I tried to read the GPS data (over Pin RB1) there is a lot of missed/corrupted bytes in my buffer, something like this:

Probably the interrupts interrupting the SERIN statements. Disable the interrupts before going into SERIN, reenable after coming back.

I knew this is a time issue (software generated timing "serin2"), another plan is to use the internal UART build in my pic (i'm using a18f452), but my GPS only outputs TTL levels this create interfacing problems, how can I get working this project?

Normal, Inverted RS232, the PICs capabilities, all discussed fairly well in the PBP manual.

[Darrel Taylor]

Since you're using a GPS, you already have a clock that's more accurate than anything you could possibly add to a PIC.

Just read the GPS time to use as a time stamp in the logs.

OR, a single transistor with 2 resistors can invert the serial data to the USART, if you still want the internal clock.
<br>

[Darrel Taylor]

OOPs.

I just looked up the 188 from your SERIN2 statement.

That's 4800 baud TRUE levels.
You can hook it up to the USART's RX pin. No transistor needed.

hth,

[bethr]

Thanks by answer Skimask, Darrel !
you both Are right, there is no interfacing conflicts, but unfortunately I always get the ' no gps ' string on the LCD (with or without running the RTC), I mean, I have made changes for using Hserin instead serin2,

'''''''''''''' INCLUDES ''''''''''''''''''''''''''''''''''''	
	DEFINE OSC 4 
	INCLUDE "DT_INTS-18.bas"
	INCLUDE "ReEnterPBP-18.bas"
	INCLUDE "Elapsed_INT-18.bas"  
	INCLUDE "LCDPICDEM2.BAS"		' it runs on PIDEM2 PLUS Board
	
	DEFINE HSER_TXSTA 20h
	DEFINE HSER_RCSTA 90h
	DEFINE HSER_BAUD 4800

''''''''''''' VARIABLES ''''''''''''''''''''''''''''''''''''	
		j    var byte
		rmc  var byte[100]	' this gets RMC data
		led1 var  portb.2
		b0   var byte
		adcon1 =$07
		trisa.2 = 0
		trisa.4 = 1
		trisb.1 = 1
		trisb.2 = 0
		trisb.0 = 1
		trisc.2 = 0
		trisc.7 = 1
	    porta.2 = 0
		gps var portb.1
	 	spk    var portc.2

''''''''''''' CODE ''''''''''''''''''''''''''''''''''''	
	
init:	
	ASM
	INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
	        INT_Handler   TMR1_INT,  _ClockCount,   PBP,  yes
	        endm
	INT_CREATE                 
	ENDASM 

	@    INT_ENABLE  TMR1_INT      
	GOSUB ResetTime
	GOSUB StartTimer           
	hours = 11 : minutes = 30: seconds = 0
    
Start:
	LCDOUT $FE,1                    ' Initialize LCD
	PAUSE  200	
	lcdout $fe,2,"Starting ..." : pause 500

Main:  
	Hserin 1500,no_gps,[wait("MC"),str rmc\15\10]	'15 bytes only for testing () wait for RMC message
  

	lcdout $fe,$c0,"Time : ",dec2 hours,":",dec2 minutes,":",dec2 seconds
 
	lcdout $fe,2,"$",str rmc\15 :pause 500						' these are the bytes as captured !
	goto main

no_gps:
 
	lcdout $fe,1,"No Gps stream "
	lcdout $fe,$c0,"Time : ",dec2 hours,":",dec2 minutes,":",dec2 seconds
	goto  main
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

currently for debug I'm using an GPS software simulator:


and I'm sure that it works, this is a debug rs232 window (hyperterm)

that was taken on Sub-DB9 connector of the picdem2 board

there is something missing in the set-up hardware UART ???

Thanks again !

[Darrel Taylor]

Try it like this...

	DEFINE HSER_TXSTA 24h ' BRGH=1
	DEFINE HSER_RCSTA 90h
	DEFINE HSER_BAUD 4800
        DEFINE HSER_CLROERR 1 'Hser clear overflow automatically

[bethr]

It's alive !!

it works Darrel, I'm wondered why this bit must be set in hi speed if my bps is low ! (4800 bps)

bit 2 BRGH: High Baud Rate Select bit
Asynchronous mode:
1 = High speed
0 = Low speed

and now it looks run pretty ! (with RTC running ), look this:


Now, I'll keep it running for a while, I hope the RTC doesn't have long-delays. any-way as you said, always there is way to update ths RTC register with GPS ones !!
BTW currently I'm not using UART interrupts, but . . .
. . . what if . . .

I enable it ?, this give more reliable data incoming form the GPS line ? or it can be dangerous for the RTC health ?

[Darrel Taylor]

It's alive !!

WooHoo!

I'm wondered why this bit must be set in hi speed if my bps is low ! (4800 bps)

With a 4mhz OSC, I wouldn't consider 4800 "low".

In the datasheet there's a couple tables that show the baud rates vs. OSC freq with BRGH either 1 or 0. With BRGH=0 @ 4mhz, the highest baudrate in the table is 2400. With BRGH=1 it's 19200.

It may still work with BRGH=0, but it's close to the edge, so why not just make it BRGH=1.

I think the HSER_CLROERR 1 may have had the biggest effect.
The GPS will just spit out the data at regular intervals. It doesn't wait for the PIC to be ready. And at 4800 baud it can send a byte every 2ms. So when the program sits in a 500 ms pause, it may receive a couple hundred bytes before the program gets around to looking at the data. There's only a 2 byte buffer in the USART so it causes an Overflow that must be cleared before it will start receiving data again.

BTW currently I'm not using UART interrupts, but . . .
. . . what if . . .

I enable it ?, this give more reliable data incoming form the GPS line ? or it can be dangerous for the RTC health ?

HSERIN is not compatible with USART interrupts.
You would need to parse the incomming data 1 byte at a time with your own handlers.

It's much easier to use HSERIN.

hth,