[time-nuts] TruePosition and Arduino Progress

Daniel Watson watsondaniel3 at gmail.com
Sun May 21 23:11:20 EDT 2017


Hi,

Here's an interesting addition to the project once you get the serial
parser and display driver worked out. It is quite easy to generate the
$GPZDA NMEA message in your program. You can send this off to a Raspberry
Pi or BBB along with the PPS signal and drive an NTP server. :)

[image: Inline image 2]

Dan

On Sun, May 21, 2017 at 5:48 PM, Chris Albertson <albertson.chris at gmail.com>
wrote:

> The root of the problem is that he is doing all the parking at once
> and ignoring inputs from both the serial line and the 1PPS
>
> Even if the iPPS were connected to an interrupt (and it should be) he
> is still busy parking input when the ISR sets the flag.
>
> He needs to read the data fro the serial line one character at a time
> and not wait to start parsing.
>
> Either that or he needs to insert calls to some kind of CHECKINPUTS()
> every few lines in the parser and that just look ugly.
>
> On Sun, May 21, 2017 at 11:56 AM, Jim Harman <j99harman at gmail.com> wrote:
> > Another way to do is to use the 1 PPS to trigger an interrupt on the
> > Arduino. Look at the documentation for attachInterrupt(). In the
> interrupt
> > routine, have it set a flag. The flag variable should be declared up
> front
> > as volatile.
> >
> > Then in your main loop, do all your parsing then loop waiting for the
> flag
> > to be set. When set, update the clock then clear the flag and repeat.
> >
> >
> >
> > On Sun, May 21, 2017 at 2:32 PM, Chris Albertson <
> albertson.chris at gmail.com>
> > wrote:
> >
> >> To add to my last message.
> >>
> >> You CAN collect all the data then parse it like you are doing if you
> >> were to move to an interrupt driven serial port reader.   Each
> >> character is then read by the interrupt handler anyplace in a large
> >> circular buffer.   The parcer then reads out of the other and of this
> >> buffer.
> >>
> >> The phlegm with the current code is the parse ingnores serial input
> >> and will drop data, in also ignore the PPS and will as you found drop
> >> pulses.
> >>
> >> Typically in real time processors like your that must be interrupt
> >> driven or they must poll MANY times laster then the data arrives
> >>
> >> so as I wrote before, parsing the data stream one character at a tie
> >> is in effect pooling the serial port much faster then characters
> >> arrive.    Adding a ring buffer and interrupts guarantees yo never
> >> miss a character and certainly you need to interrupt in the PPS to
> >> handle the case there three s serial data and the PPS at the same
> >> time.
> >>
> >> The ring buffer is like you big string except you data data onto one
> >> end at the same time as soured data off the other.  Hopefully the ring
> >> buffer never has much data in it as the parser should be fathers then
> >> the serial line.  BUT if a PPS happens then the parser in interrupted
> >> while the display updates so th ring buffer might get filled up a
> >> little.  But the ISR terminals the parser clears the buffer.
> >>
> >> On Sun, May 21, 2017 at 11:20 AM, Chris Albertson
> >> <albertson.chris at gmail.com> wrote:
> >> > The problem is that you get the ENTIRE string then parse it.  This is
> >> > not going to work well as you found out.   Your CPU spends almost the
> >> > entire time waiting for characters to come in slowly off the serial
> >> > line.  You are just waiting on bits and wasting CPU cycles
> >> >
> >> > What you need to do is parse one character at a time.   I bet your
> >> > parser reads one character at a time from the string.   Have it read
> >> > one character at a time directly from the serial port.   (Use a state
> >> > machine.  It will work for such a simple  job as this)
> >> >
> >> > Yes if your CPU was MUCH faster your plan could work.  But on some
> >> > GPSes the data never has a break.   You are trying to do ALL the work
> >> > in the break but actually most of the down time when you should be
> >> > working is between the characters.    There is not a lot of work a
> >> > finite state machine needs to do between characters, just move state
> >> > based on a 'character class" table.       I you ever studied this
> >> > formally, what you are building here is a "lexer" not a parcer.   The
> >> > "Language" is not recursive and you never need to backtrack so it can
> >> > be de-coded literally one character at a time.
> >> >
> >> > You DO really want the 1PPS to drive an interrupt.   Thisway you just
> >> > continue working on the data stream and don't wait for the PPS.   When
> >> > the PPS happens you do something QUICK. never do anything time
> >> > consuming in the ISR or you will miss the next serial character.
> >> > increment a seconds count and write two bytes the the LCD and exit
> >> >
> >> > On Sun, May 21, 2017 at 6:45 AM, Ben Hall <kd5byb at gmail.com> wrote:
> >> >> Good morning all,
> >> >>
> >> >> A quick update for those interested on my Arduino code development
> for
> >> the
> >> >> TruePosition boards.  I've got Arduino code together than can read in
> >> the
> >> >> serial stream, parse it, and display time, date, number of
> satellites,
> >> and
> >> >> TFOM on a 2x16 LCD display.  It does not do multiple screens, handle
> >> survey,
> >> >> or display lat/long yet.
> >> >>
> >> >> What I'm having issues with is handling the 1 PPS.  Ideally, I want
> to
> >> use
> >> >> the 1PPS signal to trigger the display update.  IE:
> >> >>
> >> >> void loop()
> >> >> {
> >> >> getSerialString()  // uses serial.available to pull in the serial
> data
> >> >>
> >> >> parser()  // this parses the data
> >> >>
> >> >> wait for 1PPS tick to go high
> >> >>
> >> >> if there has been a clock message, updateDispay()  // update the
> display
> >> >> }
> >> >>
> >> >> This works great when there is a just a clock message.  But when
> there
> >> is a
> >> >> clock message, an extstatus message, and a status message, it seems
> >> like it
> >> >> is still parsing when the 1PPS tick comes in...so it will display
> >> seconds as
> >> >> follows:  30, 31, 33, 34, 35, 36, 37, 39, etc...
> >> >>
> >> >> (If I don't wait for the 1PPS tick, it seems that my clock is one
> second
> >> >> fast.  I say "seems" to be fast, as the time agrees with an NTP clock
> >> on one
> >> >> computer, but seems a half second slow per GPSCon's time display on
> the
> >> >> Z3801.  I think I need to put up the antenna and check against WWV.)
> >> >>
> >> >> I've got one of those cheap little USB logic analyzers on order to
> >> figure
> >> >> out how much time elapses between the clock, extstatus, status, and
> 1PPS
> >> >> tick.  I may need something faster than an Arduino Uno to do this.
> >> >>
> >> >> I'm sure there is a way to do this with an interrupt...but I couldn't
> >> make
> >> >> that work yesterday.  More to follow.
> >> >>
> >> >> thanks much and 73,
> >> >> ben, kd5byb
> >> >> _______________________________________________
> >> >> time-nuts mailing list -- time-nuts at febo.com
> >> >> To unsubscribe, go to
> >> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >> >> and follow the instructions there.
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Chris Albertson
> >> > Redondo Beach, California
> >>
> >>
> >>
> >> --
> >>
> >> Chris Albertson
> >> Redondo Beach, California
> >> _______________________________________________
> >> time-nuts mailing list -- time-nuts at febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> >
> >
> >
> > --
> >
> > --Jim Harman
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2725 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20170521/dcc8abfa/attachment.png>


More information about the time-nuts mailing list