SERIN2 = ok, HSERIN = no!

[ScaleRobotics]

Well I am a bit confused too. It looks like he is inverting it, and using a max232, and has success with that (If I am reading it right). So, if that is the case, don't invert it, and don't use a max232.

[Demon]

... So, if that is the case, don't invert it, and don't use a max232.

That's what I was going to post, but thought I'd sound even more weird than usual.

I see where my debugging went wrong; I relied on his comments, not his settings.

GPSbps    = 32852       'Open,True,N,9600bps (TTL level)

He said TRUE (non-inverted) but then contradicted with N (inverted) in his comment. It can't be both. I was looking for T or N, to compare against the table in PBP manual.

Using PIC Multicalc:
9600, open, inverted, no parity = 49236
9600, open, true, no parity = 32852

The working SERIN was using non-inverted, that would explain why inverting a MAX232 would work.

Does that make sense?

Robert

[mackrackit]

The "N" in his comment is for No parity.
As in "8,N,1"

[Demon]

That's possible, but that only explains why I got confused trying to follow his settings.

The fact remains that he was using non-inverted in SERIN, and then trying inverted in HSERIN at the end, no?

He shouldn't have to use a MAX232 with HSERIN if his GPS worked with SERIN non-inverted. Or is he on to something with HSERIN creating higher voltages than SERIN? (I have no idea about that).

Robert


EDIT: Look at SERIN in the PBP manual, that's where I got N as being inverted. His comment didn't mention a stop bit so I didn't catch on as it meaning 8N1.

[Archangel]

I Think HSERIN only speaks TRUE and likes a nice pull up resistor, just to keep it honest. The max232 would invert it, NO?

[Ioannis]

Some PIC have the option to select true or inverted.

Ioannis

[Archangel]

Some PIC have the option to select true or inverted.

Ioannis

Don't know what I saw, I thought he was working with a 16F628 . . . still I did not know this anyway. Thanks to you and Walter.

[flotulopex]

Based on the code in post #12, I removed the WAIT modifier to be able to see what happens on each try (= display anything data that comes into the PIC): HSERIN[STR GPS_D\6].

...and likes a nice pull up resistor...

I removed the MAX232, added a 10k pull-up on PORTC.7 (PIC's RX pin) and changed BAUDCON to % 01001000 (not inverted). It works now!!!


I re-modified the code to: HSERIN [WAIT("$GPGGA,"),STR GPS_D\6]

I now can see "HH:MM:SS" as it should.

Nevertheless, I have my PIC running for more than an hour now and it often hangs (= time is no incrementing every second anymore) and starts overs maybe 10 or 20 seconds later. Seems that the data signal is just at the limit the PIC can "read" it properly. This does not happen in my SERIN2 mode.

With the oscilloscope, I measure 4,7VDC for the highest data signal level on PORTC.7 while the PIC and the GPS module are powered by the PICKit2 and its 4,95VDC from USB.

I think I will choose to stay on the SERIN2 version since it looks more "reliable" and, as already said, needs less components.

[Darrel Taylor]

Nevertheless, I have my PIC running for more than an hour now and it often hangs (= time is no incrementing every second anymore) and starts overs maybe 10 or 20 seconds later.

That sounds more like a USART buffer overflow.
If it isn't cleared ... it will hang.

Try adding ...

DEFINE HSER_CLROERR 1 ' clear overflow automatically