Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Do
nmea_sentence
Andrew Rich VK4TEC
www.tech-software.net
Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210
Posted: 03:25pm 30 Dec 2012
Copy link to clipboard
Print this post
Thanks Rich,
I'm still not sure.
The way I understood it, the nmea_sentence got the string and when it saw the * at the end of the line it exited from the sub and continued on. When it came back and got the string again it started with an empty buffer. Anyway, I know I'M WRONG (because it screwed up) but I seem to have it running okay now. What does the Close #1 actually do. Does it clear the port of data? It doesn't mention it in Geoffs commands info.
It only got screwed up when I disconnected the Garmin. Now it's okay.
The program is a little bit different now but not all that much. I'm using Pulse 2, 2000 to give me a high on pin 2 every minute. I was using Settick which is more messier. I didn't know about the Pulse command. Do you know if you can have individual Pulse commands at the same time? I might try and test it today.
BTW - I was licensed as VK1BUM and P29TD but haven't been licensed or active for a while now.
Regards
TrevorTalbit
vk4tec Senior Member Joined: 24/03/2012 Location: AustraliaPosts: 239
Posted: 03:40pm 30 Dec 2012
Copy link to clipboard
Print this post
Trevor
Names "Andrew"
The USART in a PIC has to have some items "set" and then the port enabled.
This is most likely done with the "open" command
You set things like speed ( really a RX divider of the clock )
The length, parity and number of stop bits.
The close stops data coming into the receiver of the PIC.
This stops the buffers from being over run.
The NMEA data keeps coming - you can't stop that.
What you can stop is when the PIC32 "listens" OPEN or does not listen "CLOSE"
When I was programming in assembly too, it was important to "flush" the buffer
The Receive buffer on my PIC16F628 was 3 bytes "deep"
To clear it out, I read from it three times.
Having grown up on PIC assembly language I can get a feel for what MMBasic is doing.
It is of interest to me how Geoff has coded up to handle certain "considerations"
BTW - I have now sold my original PIC boards and programmers - thanks Geoff ;-)
- Andrew - Andrew Rich VK4TEC
www.tech-software.net
paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328
Posted: 03:46pm 30 Dec 2012
Copy link to clipboard
Print this post
Trevor - I'm pretty sure I read somewhere that CLOSE does flush the buffer. If it's not in the MMBasic Manual then it was probably in one of Geoff's Silicon Chip articles.
Greg
Edit: Here it is Trevor - in the "Reading and Writing" section of Appendix A in the Manual.
Serial ports can be closed with the CLOSE command. This will discard any characters waiting in the buffers,
return the buffer memory to the memory pool and set all pins used by the port to the not configured state. A
serial port is also automatically closed when commands such as RUN and NEW are issued.Edited by paceman 2013-01-01
Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210
Posted: 04:04pm 30 Dec 2012
Copy link to clipboard
Print this post
Sorry Andrew,
I'm working on 2 Back Shed subjects at once!
Geoffs info says the "Open2:19200" as #1 has a buffer default of 256 bytes and a default of 8. N. 1. I certainly don't fill up the buffer with the NMEA data nor do I need to flush the buffer. I don't normally need to Close the port if I'm running as normal. But I do if I play around with interrupting the NMEA string and the PPS. Anyway the Close command fixes it.
I can send you a test program that will demonstrate the problem. All you need is to be running Terra Term and your Garmin. It all runs fine until you disconnect and reconnect the Garmin. When the PPS comes back all hell breaks loose. It's also handy to have a GPS clock that you know is accurate running along side. Really I should be doing a lot more checking of the data/PPS sequence but the Close fixed it.
TrevorTalbit
vk4tec Senior Member Joined: 24/03/2012 Location: AustraliaPosts: 239
Posted: 06:27pm 30 Dec 2012
Copy link to clipboard
Print this post
Curious - why the use of the PPS ?
- Andrew - Andrew Rich VK4TEC
www.tech-software.net
Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210
Posted: 10:00pm 30 Dec 2012
Copy link to clipboard
Print this post
Andrew,
The PPS is critical for precise timing. If you read the NMEA string and simply display it straight away or print it or whatever, it will be about 500ms late. The GPS gives you the PPS first then you get the NMEA string relating to that PPS. A pity it's not the the way around.
So what I do is read the NMEA, parse it to get the data I need - time, position, date etc. Then I update the time by 1 second then wait for the PPS to arrive. Then I display it. The PPS can be very accurate and is the only thing coming from the GPS that you can time anything by.
TrevorTalbit
vk4tec Senior Member Joined: 24/03/2012 Location: AustraliaPosts: 239
Posted: 10:15pm 30 Dec 2012
Copy link to clipboard
Print this post
Ah
The PPS is a video gate for your display.
I think you mentioned about the compenstation of the display routine as well.
GPS is used at work to tick some things over.
Yeah the PPS can be good as a timing reference.
- Andrew - Andrew Rich VK4TEC
www.tech-software.net
Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210
Posted: 10:51pm 30 Dec 2012
Copy link to clipboard
Print this post
Paceman,
Thanks for your comments on the Close command. I thought I posted a reply but maybe I didn't hit the go button.
Anyway you are absolutely right. Geoff does talk about the Close command and that it clears the buffer.
I've got it all working solidly now using the close command. But I'm still curious as to exactly what is going on inside the beast and what was going on.
Maybe when I've got some more time.
Thanks
TrevorTalbit
Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210
Posted: 11:02pm 30 Dec 2012
Copy link to clipboard
Print this post
Andrew,
In the current Silicon Chip articles by Jim Rowe on his frequency counter, he proposes using a GPS PPS as a very accurate time reference. My guess he's going to do some more articles using GPS.
BTW - A fellow at work has developed some software to set the system clock in the field PC using GPS. He then periodically checks the accuracy of the PC time against the GPS and slowly nudges the PC time until it's correct. He could just reset the PC time in one jump but that would mean a step in time as opposed to a gradual correction. He has reasons for doing it that way.
I'm sure you have figured out by now that as soon as the NMEA and PPS is lost in my clock the time freezes. Ideally, the best thing to do would be to have the battery backed RTC in the MM as the system clock and set it by the GPS on startup. Have you or anyone else done anything like that?
TrevorTalbit
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Print this post