Hi,
I've been lost in the land of GPS modules, and their 400 page manuals , Now having set my modules to only send the GXRMC message, there is no need to 'select' it out of the set of messages. (I didn't know this was possible, or I would have done it years ago).

I'm just getting into the latest program again, and see a problem, that I'm trying to solve.
In case anyone can beat me to the answer, here is the problem, STR1(1) should = 82. for the REMOTE sentence:

EDITED
Re-EDITED
RE-EDITED
C

 

hi C,
The String length should not be a problem
Clip:
All declared string variables will reserve fixed number of bytes in microcontroller memory. That number is set by the Define directive and STRING_MAX_LENGTH parameter. The allowed range for the parameter is 8-100; the default value is 16. The string variables will take one extra memory byte containing zero value to define the end of string (string termination byte).
Define STRING_MAX_LENGTH = 8

E

 

hi C,
The String length should not be a problem
Clip:
All declared string variables will reserve fixed number of bytes in microcontroller memory. That number is set by the Define directive and STRING_MAX_LENGTH parameter. The allowed range for the parameter is 8-100; the default value is 16. The string variables will take one extra memory byte containing zero value to define the end of string (string termination byte).
Define STRING_MAX_LENGTH = 8

E

Hi E,
To clarify: If you look at the STRING STR1() in the image #201 you can see it goes from 0-79, but in position STR1(1) it shows [ 0 ] but it should show "R" = 82, so that later in the program where $sentences are selected, see [ ZZZZZZZZZZ } in the now modified text #201, [ R ] is relevant.
C.

 

Hi,
I've been lost in the land of GPS modules, and their 400 page manuals , Now having set my modules to only send the GXRMC message, there is no need to 'select' it out of the set of messages. (I didn't know this was possible, or I would have done it years ago).

I'm just getting into the latest program again, and see a problem, that I'm trying to solve.
In case anyone can beat me to the answer, here is the problem, STR1(X) should = 82. for the REMOTE sentence:

EDITED
C

Maybe you can post the latest program or the msg# containing it here.

 

Maybe you can post the latest program or the msg# containing it here.

Hi J,
Here's the latest program:
NOTE: I've added the correct TXT file in #201 showing the SELECTION at ZZZZZZZZZZ
C.

 

Hi,
As I carry out simulations, I make very small changes to the program.

I've been simulating the attached program, and the previous [ STR1(1) = 0 ] problems are not always present.

Here is an image showing errors.

Some of the errors are due to the [ MSG_EOL ] not being implemented, so the next message uses the last [ MSG STRING ] for information.

C.

 

Hi,
With this program:

the HSERIN doesn't block, which is the purpose of this thread, thanks for unblocking.

It isn't working perfectly, so I'm clearing it up till it does.

Noting that since the thread was started, I managed to get the GPS to only SEND the $sentence I want making the the RED section unnecessary. Noting that much of it is COMMENTED OUT with [ ' ] , how much can I cut out.
C.

 

C, The SIM is true as well, but the timing of it can be off somewhat when trying to compare hardware emulation (from what I find). Since the UART is a slow serial to parallel (byte) conversion, you see things in the SIM while the UART emulation is still "emulating".
DJ is correct in that while there may be a character somewhere in the UART, until PIR1.RCIF = 1, you should not be attempting any read of the UART. The PIR1.RCIF is the "master flag", and any processing has to be around that flag only. It is UART hardware controlled, and you only process RCREG when that flag is set. The UART then clears that flag once you have fully read all the contents of RCREG (which may be a clock cycle or two later)
There is a flag bit called RCIDL in the register BAUDCON that indicates that the UART is actively getting some serial bits (UART is active), but that does not indicate that all the bits are received just yet. It is a bit that a main program loop can check to say "hey, something is coming into the UART, so I'll get ready to read it soon". But, that may only confuse you even more, so ignore it for now unless you build a more sophisticated program.. Only PIR1.RCIF shows things are "complete" in receiving any character

Hi,
I've been trying to get programs including RCIDL, but even though I can't be sure, it seems as though it introduces odd things when simulating, so I will try programs prior to introducing RCIDL again.

NOTE: I am not a good programmer, so the above may be going backwards?!?
C

 

Hi,
I tried earlier programs not including RCIDL but now I don't think that this is a problem.

The problem of STR1(1) (#201) not equaling [ 82 ] has mysteriously disappeared?

When stepping through the program on the SIMULATOR, I see the DATA being parsed from the STR1() STRING, but the INTERRUPT is jumping in before the process has finished. Is there a way of temporarily turning off the INTERRUPT, then back on later, after the process has finished? I've tried DISABLE HIGH-DISABLE LOW, but this didn't stop the INTERRUPT.
C

 

Try to disable global interrupts.
INTCON.GIE=0

 

Try to disable global interrupts.
INTCON.GIE=0

Hi J,
I'm just testing: PIE1.RCIE = 0 'EUSART [ Receive Interrupt Enable bit ]
which seems to work in SIMULATOR, next LIVE.

Is INTCON.GIE=0 [ Global Interrupt Enable bit ] a better option?

EDIT: With PIE1.RCIE = 0 [LIVE] It looks promising, but a bit sporadic. At one point the RECEIVING TERMINAL showed two GPS READings one second between them, with a REMOTE READing in between them. Next I'll try INTCON.GIE=0

EDIT EDIT: Both results are very similar.
C

 

Try to disable global interrupts.
INTCON.GIE=0

Hi J,
I've tried both settings in #211. They give similar results so I'll leave [ INTCON.GIE=0 ] until someone tells me different.
I consider this thread resolved, so I'll return the the main thread.
Thanks to all involved,
C.