hi C,
If you recall, when using the Oshonsoft IDE we could not easily add directly to the end of a STRING the CRLF code with the Hardware UART tool, so we made the EOS [end of string] code a '?' which we could type at the end of a test string.

So the code the program looks for in SIMULATION as the EOS is a '?' and not LF [0x0A].
Its commented in the program that when using an external RS232 input you must change the '?' to a 0x0A.

The '$' at the start of the string is required, both in simulation and in a real PIC, as this determines the start of a GPS message.
E

Hi E,

I do recall, but if possible I would prefer a suggested sentence e,g, [$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47?] until I'm more up to speed on data transfer, please.

C.

 

Hi E,

I do recall, but if possible I would prefer a suggested sentence e,g, [$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47?] until I'm more up to speed on data transfer, please.

C.

hi,
If you are using Putty to send test messages to the PIC, the '?' will be OK, but of course when you get a string message from the GPS module it will be a CR LF [ hex 0D , 0A] end of string, OK.?

You will have to change the PIC program from '?' to 0x0A at that time.
E

 

hi,
If you are using Putty to send test messages to the PIC, the '?' will be OK, but of course when you get a string message from the GPS module it will be a CR LF [ hex 0D , 0A] end of string, OK.?

You will have to change the PIC program from '?' to 0x0A at that time.
E

Hi E,

Changed program to '0x0A' [Thanks for reminding me!!]

The GPS is passing through a MAX232 so the input to PIC RX is almost 5V. Nothing on the LCD.

I touched the PIC RX pin [From GPS TX] with the Putty RX pin. See attached JPG. Does this tell you anything?

C

 

Hi E,

Changed program to '0x0A' [Thanks for reminding me!!]

The GPS is passing through a MAX232 so the input to PIC RX is almost 5V. Nothing on the LCD.

I touched the PIC RX pin [From GPS TX] with the Putty RX pin. See attached JPG. Does this tell you anything?

C

hi C,
The output from the GPS module is at TTL levels, it does not require a MAX232.
Its a direct connection, GPS RXD out to PIC TXD in.

Its ONLY the PIC's TXD out to a PC [Putty] that requires the MAX232.
E

 

hi C,
The output from the GPS module is at TTL levels, it does not require a MAX232.
Its a direct connection, GPS RXD out to PIC TXD in.

Its ONLY the PIC's TXD out to a PC [Putty] that requires the MAX232.
E

Hi E,

We've had this conversation before. I've tested the output of the GPS with an Oscilloscope, and it's 3.3v I've also tried it directly to the RX pin.

Here is something I found today, that I will investigate. I'll try a few tests.

C

 

Hi E,

New GPS module. 3.3v on oscilloscope.

Program 'CamPad_Uart1V-1 B 0x0a.bas' Same program with 0x0a.

GPS connected directly to PIC RX----When switched on text on the LCD, jumbled ublox message www.ublox.com blah blah.----touch putty RX onto PIC RX pin. See attachment.

C.

 

hi,
Are you saying when Putty RX and the GPS module are connected at the same time, the Putty displays the correct data and the LCD on the PIC is garbled.??

Is the voltage supply to the PIC 5V and the GPS 2*1.5V batteries ie: 3V.??

E

 

hi,
Are you saying when Putty RX and the GPS module are connected at the same time, the Putty displays the correct data and the LCD on the PIC is garbled.??

Is the voltage supply to the PIC 5V and the GPS 2*1.5V batteries ie: 3V.??

E

Hi E,

Yes they are both connected at the same time momentarily for that test. Putty shows data, LCD doesn't show data.

When initiated the GPS sends text to the screen (Slightly garbled), which stays the same.

5v is from a regulator. PIC and GPS are powered from it. The GPS has a 3.3v regulator on it. I'm not sure but I think it can deliver TX 5v, but I haven't found out how yet.

C

 

Hi E,

At the moment I don't have PIC TX to GPS RX is this ok?

C

 

Hi E,

At the moment I don't have PIC TX to GPS RX is this ok?

C

hi,
The notes I have read about the GPS indicate it will not tolerate a +5V input on its RXD input pin, so do not connect the 5V PIC to the 3.3V module.

If it has a 3.3V regulator on the module, applying only 3V volts from two 1.5V batteries will not correctly enable the on board regulator.

I would say you need to find out how to use 5V for the module or add a 3.3V to 5V level shifter.

E

 

Hi E,

I have two inputs, with a changeover switch.

One I can plug the GPS directly to PIC RX the other through a MAX232, then PIC RX.

In the following both act the same:

If I have the switch connecting the GPS at initialisation, the UBLOX.com slightly garbled message comes on the LCD.

If I have the switch in the no GPS way, at initialisation, the '!' appears on the LCD only. If I then switch over to connect the GPS, data shows on the LCD. Usually, 'GPRMC, *********etc appears on the LCD. This just sits, with no change.

EDIT: GPRMC is the first sentence on the list of different GPS data.

C

 

hi,
You will often get a corrupt character in the RXD buffer if you use a mechanical switch to select an alternative input.

What have you done to get the GPS data appearing on the LCD.? earlier you said you could not get anything at all.??

E

 

There is usually a big pause >500mS between the GPS text packet that is sent every second.

I detect the pause with a "timeout detect" code, and clear the buffers and then re-sync the receiving and display at the start of the next packet.

 

There is usually a big pause >500mS between the GPS text packet that is sent every second.

I detect the pause with a "timeout detect" code, and clear the buffers and then re-sync the receiving and display at the start of the next packet.

hi C,
There is no need to detect the pause between GPS messages.??

You are using a UART Intr on RXD, the ISR receives the complete GPS message string and over writes the previous str1(array) buffer contents with the latest data, byte by byte as its received.

During the 'pause', between GPS messages, the final program will be doing the 'maths' on the GPS message, using the data thats contained in the buffer.

The only 'time out' action thats required is in the UART ISR, in the event the loss or corruption of the received message,, you don't want the UART to 'lock up' the program waiting for non existent data.!

E

 

hi Roman,
I have working setup, using a programmed PIC and a external PC which provides the simulated GPS messages.

The PIC is doing the maths/etc on the $GPGGA message, using the Haversine equations to calculate Range and Azimuth of the Remote point relative to the Local Point.
The LCD displays the results.

I have also tried a 'cut down' version of the Coord to Polar maths, which works quite well.

I have had to build a working prototype in order to check out the Oshonsoft FP maths routines, as they are limited to only 6 places of decimal.

The accuracy results and 'free program time' so far have been more than adequate for the OP's application.

My concern is the additional program space/time load when the OP starts having to detect the 'rotatory encoded' disc and PWM motor drives in the X, Y, and Z axis!

Eric

EDIT:
The Flash program memory usage to date is 38% [18F452]
The UART uses the High priority intr and the 16 Key Pad uses the Low priority intr.

 

hi,
You will often get a corrupt character in the RXD buffer if you use a mechanical switch to select an alternative input.

What have you done to get the GPS data appearing on the LCD.? earlier you said you could not get anything at all.??

E

Hi E,

Ok, on corrupt characters.

I have been trying everything I can think of to get it to work, new GPS, MAX232, Putty verification etc. Only when I delayed switching the GPS on to PIC RX, data showed on the screen.

To me it looks like when the GPS initialises, the Ublox message appears on the LCD, and is not being cleared, if I wait till the GPS is collecting data, then switch it into the system, that's when it gets the first NMEA data sentence, anything that follows is too long for the LCD.

It would be interesting to test if an isolated sentence, taken from the incoming data e,g, '$GPGGA,123519,5050.198,N,00106.769,W,1,08,0.9,123.4,M,46.9,M,,*47? was printed on the LCD.


C

 

My concern is the additional program space/time load when the OP starts having to detect the 'rotatory encoded' disc and PWM motor drives in the X, Y, and Z axis!
[18F452]

Hi Eric,

If the rotary encoder program space could be a problem, I could try using HCTL2000 or similar (I have two) chips if it helps.

C

 

Hi Eric,

If the rotary encoder program space could be a problem, I could try using HCTL2000 or similar (I have two) chips if it helps.

C

hi,
Is it possible you could post me the the Ublox message string. I will then try to duplicate the problem you have..

E

I will look thru the HCTL2000 d/s

 

hi,
Is it possible you could post me the the Ublox message string. I will then try to duplicate the problem you have..

E

I will look thru the HCTL2000 d/s

Hi E,

Here is the putty screen on initialisation, the LCD is trying to show this but is garbled.

C

 

hi C,
We can dump the 5 lines of Initialise if you dont need it.??

I am puzzled by the actual GPS messages shown in that image taken from the Putty screen.

There is no time or coordinate data in the GPS messages.???

E