Discussion:
TymServe 2100 1995 Issue - A Kludgy Fix
(too old to reply)
Andrew Cooper
2015-05-05 00:42:47 UTC
Permalink
We also ran into the TS2100 1995 bug this weekend. For us the consequences are a bit more severe... The telescopes will not point to the right location in the sky without accurate time!

For now we have configured a temporary fix... We set up two units, previously our primary and hot spare. The first unit is set to use GPS, which of course has the correct time but the wrong date. The first unit is sending a 1PPS signal to a second unit which is set to 1PPS input mode with a manually set date and time. We now have all of the IRIG and NTP capability we need and the correct date.

Yes, there is also an order in with purchasing for an S350 SyncServer unit.

Andrew


Andrew Cooper
Electrical Engineer
W. M. Keck Observatory
808-881-3862
mailto:***@keck.hawaii.edu

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Pete Stephenson
2015-05-05 07:30:04 UTC
Permalink
On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper <***@keck.hawaii.edu> wrote:
> We also ran into the TS2100 1995 bug this weekend. For us the consequences are a bit more severe... The telescopes will not point to the right location in the sky without accurate time!

Ouch. I have some friends who work at the Subaru telescope. I'll check
in to see if they're affected.

> For now we have configured a temporary fix... We set up two units, previously our primary and hot spare. The first unit is set to use GPS, which of course has the correct time but the wrong date. The first unit is sending a 1PPS signal to a second unit which is set to 1PPS input mode with a manually set date and time. We now have all of the IRIG and NTP capability we need and the correct date.

Out of curiosity, is there no way to "prime" the device with the
current date/time (e.g. from a wristwatch) so it can interpret the GPS
week information correctly? I recall that several other devices have
that ability.

Is there a list of other common time-nut devices that are susceptible
to similar issues? Lots of time-nuts use surplus equipment that's no
longer supported and it'd not be fun to have them stop working.

Cheers!
-Pete

--
Pete Stephenson
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob Camp
2015-05-05 11:49:51 UTC
Permalink
Hi

The simple list of devices susceptible to this problem is:

Almost all of them from before 1998, many of them after that.

The issue is inherent in the design of the GPS coding and un-aided
recovery of that coding. The need to address it only was apparent to
most marketing departments after the first batch of gear started failing
in the late 90’s.

Bob



> On May 5, 2015, at 3:30 AM, Pete Stephenson <***@heypete.com> wrote:
>
> On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper <***@keck.hawaii.edu> wrote:
>> We also ran into the TS2100 1995 bug this weekend. For us the consequences are a bit more severe... The telescopes will not point to the right location in the sky without accurate time!
>
> Ouch. I have some friends who work at the Subaru telescope. I'll check
> in to see if they're affected.
>
>> For now we have configured a temporary fix... We set up two units, previously our primary and hot spare. The first unit is set to use GPS, which of course has the correct time but the wrong date. The first unit is sending a 1PPS signal to a second unit which is set to 1PPS input mode with a manually set date and time. We now have all of the IRIG and NTP capability we need and the correct date.
>
> Out of curiosity, is there no way to "prime" the device with the
> current date/time (e.g. from a wristwatch) so it can interpret the GPS
> week information correctly? I recall that several other devices have
> that ability.
>
> Is there a list of other common time-nut devices that are susceptible
> to similar issues? Lots of time-nuts use surplus equipment that's no
> longer supported and it'd not be fun to have them stop working.
>
> Cheers!
> -Pete
>
> --
> Pete Stephenson
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Chuck Harris
2015-05-05 13:33:49 UTC
Permalink
Seems to me that the obvious simple answer works this way:

Since the GPS must use an RS232 connection to communicate
its information to the other devices in the telescope, all
that need be done is to write a fairly trivial program to
run on a PIC, or Arduino, that when presented with the date,
adds 20 to the year, and then sends it on to the rest of the
system. Everything that is not a date gets passed through
unmolested.

-Chuck Harris

Pete Stephenson wrote:
> On Tue, May 5, 2015 at 2:42 AM, Andrew Cooper <***@keck.hawaii.edu> wrote:
>> We also ran into the TS2100 1995 bug this weekend. For us the consequences are
>> a bit more severe... The telescopes will not point to the right location in the
>> sky without accurate time!
>
> Ouch. I have some friends who work at the Subaru telescope. I'll check in to see
> if they're affected.
>
>> For now we have configured a temporary fix... We set up two units, previously
>> our primary and hot spare. The first unit is set to use GPS, which of course
>> has the correct time but the wrong date. The first unit is sending a 1PPS
>> signal to a second unit which is set to 1PPS input mode with a manually set date
>> and time. We now have all of the IRIG and NTP capability we need and the
>> correct date.
>
> Out of curiosity, is there no way to "prime" the device with the current date/time
> (e.g. from a wristwatch) so it can interpret the GPS week information correctly? I
> recall that several other devices have that ability.
>
> Is there a list of other common time-nut devices that are susceptible to similar
> issues? Lots of time-nuts use surplus equipment that's no longer supported and
> it'd not be fun to have them stop working.
>
> Cheers! -Pete
>
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Tom Van Baak
2015-05-05 14:44:13 UTC
Permalink
Hi Chuck,

It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are always 604800 seconds long).

So you have to convert the incorrect UTC date and time back to GPS date and time, then apply the 1024 GPS week correction, and then convert back to UTC. This requires knowledge of all leap seconds during the past 1024 week cycle and this information is not present in the GPS signal or in the binary or NMEA messages that come out of a GPS receiver. Don't forget to account for all the leap years during that period too: 1024 weeks is 19.638 normal years but 19.585 leap years. And when you power-on the GPS receiver it may have the wrong leap second count as well, wrong for both 1995 and wrong for 2015. You have to wait up to 12.5 minutes for that information to come down at 50 baud.

Not saying it isn't possible, but it's not easy. And then you need to test it against last week and this week, and the week before and after June 30 of this year when the next leap second occurs. I realize the TymServe 2100 issue is unrelated to leap seconds. But leap seconds severely complicate any "simple" conversion between time scales, especially if you are interested in second or sub-second accuracy.

/tvb

----- Original Message -----
From: "Chuck Harris" <***@erols.com>
To: "Discussion of precise time and frequency measurement" <time-***@febo.com>
Sent: Tuesday, May 05, 2015 6:33 AM
Subject: Re: [time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix


> Seems to me that the obvious simple answer works this way:
>
> Since the GPS must use an RS232 connection to communicate
> its information to the other devices in the telescope, all
> that need be done is to write a fairly trivial program to
> run on a PIC, or Arduino, that when presented with the date,
> adds 20 to the year, and then sends it on to the rest of the
> system. Everything that is not a date gets passed through
> unmolested.
>
> -Chuck Harris

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Chuck Harris
2015-05-05 16:18:09 UTC
Permalink
Hi Tom,

One of the first words I taught my precocious kid when he was
less than a year old was balderdash. It seemed appropriate for
him to know that word if I was going to be his father. Hard
for me to believe that little boy graduates from CMU with his
BS in physics this month....

The currently buggy GPS receiver is outputting UTC time that is
offset by 1024 weeks, and some number of seconds from reality.
The past is irrelevant if we know the present offset. Add in
that offset, reformat the UTC data frame and send it out when
asked. An Arduino can do that in a very small number of
milliseconds. And, the Arduino's time burden can be well known
and applied to the data, if it is significant.

Surely the receiver is still producing correct frames that
identify the future leapsecond, and those frames could be
read, and used to set a little routine that wakes up at the
appropriate second, and adjusts the overall offset?

Seems way simpler to me than all of that code I had to wade
through and cleanse of Y2K bugs.

Since the OP was talking about a multi million dollar research
telescope, which presumably matters to a lot of people, I will
refrain from commenting about the wisdom of ignoring the well
publicized 1024 week roll over bug, and not replacing/reflashing
the GPS receiver years ago.

-Chuck Harris


Tom Van Baak wrote:
> Hi Chuck,
>
> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years). And
> not UTC weeks (which may have leap seconds) but GPS weeks (which do not, and are
> always 604800 seconds long).
>
> So you have to convert the incorrect UTC date and time back to GPS date and time,
> then apply the 1024 GPS week correction, and then convert back to UTC. This
> requires knowledge of all leap seconds during the past 1024 week cycle and this
> information is not present in the GPS signal or in the binary or NMEA messages
> that come out of a GPS receiver. Don't forget to account for all the leap years
> during that period too: 1024 weeks is 19.638 normal years but 19.585 leap years.
> And when you power-on the GPS receiver it may have the wrong leap second count as
> well, wrong for both 1995 and wrong for 2015. You have to wait up to 12.5 minutes
> for that information to come down at 50 baud.
>
> Not saying it isn't possible, but it's not easy. And then you need to test it
> against last week and this week, and the week before and after June 30 of this
> year when the next leap second occurs. I realize the TymServe 2100 issue is
> unrelated to leap seconds. But leap seconds severely complicate any "simple"
> conversion between time scales, especially if you are interested in second or
> sub-second accuracy.
>
> /tvb
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hal Murray
2015-05-05 11:46:32 UTC
Permalink
***@heypete.com said:
> Is there a list of other common time-nut devices that are susceptible to
> similar issues? Lots of time-nuts use surplus equipment that's no longer
> supported and it'd not be fun to have them stop working.

We should make a list of good/bad units.

The Z3801A does the right thing if you tell it the date. (I had one that was
off by 1024 weeks and it's working correctly now.)


--
These are my opinions. I hate spam.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Esa Heikkinen
2015-05-06 19:33:11 UTC
Permalink
Andrew Cooper kirjoitti:

> We also ran into the TS2100 1995 bug this weekend.
> For us the consequences are a bit more severe...

So this is happening already.. Didn't notice this because have been
using PPS from Thunderbolt to keep the TS2100 in time. It failed with
leap second already in February (if I remember correctly) so I think if
you have same firmware than I have (the most recent one) you have
already got 1 second offset from real UTC since February.

However, with PPS everything is fine. The unit is not rebooted after
February (when removing the inegrated GPS unit) and it's in time.

However that's not only bugs TS2100 has. I'm currently creating my own
IRIG-B decoder and noticed that there's something strange going on with
IEEE1344 checksums. The checksum will fail with random hours and beign
ok on others. Seems that hour number is not included in the checksum or
something. But that's another story...

--
73s!
Esa
OH4KJU
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
descoubes
2015-05-20 17:17:06 UTC
Permalink
Esa Heikkinen <***@...> writes:

>
> Andrew Cooper kirjoitti:
>
> > We also ran into the TS2100 1995 bug this weekend.
> > For us the consequences are a bit more severe...
>
> So this is happening already.. Didn't notice this because have been
> using PPS from Thunderbolt to keep the TS2100 in time. It failed with
> leap second already in February (if I remember correctly) so I think
if
> you have same firmware than I have (the most recent one) you have
> already got 1 second offset from real UTC since February.
>
> However, with PPS everything is fine. The unit is not rebooted after
> February (when removing the inegrated GPS unit) and it's in time.
>
> However that's not only bugs TS2100 has. I'm currently creating my own
> IRIG-B decoder and noticed that there's something strange going on
with
> IEEE1344 checksums. The checksum will fail with random hours and beign
> ok on others. Seems that hour number is not included in the checksum
or
> something. But that's another story...
>



Hi everybody,
I am working for HEOL DESIGN company, and we are currently investigating
this TS2100 1995 bug. We have developped the N024, a clone of Trimble
ACE III receiver (which is mounted inside the TS2100). They are many
issues with the TS2100-ACE III internal protocol, and we have good hopes
to solve it out by N024 software.
I will keep people informed when this bug will be solved, on the Heol
Design N024 web page. Then you will be able to purchase it.
Regards


_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Esa Heikkinen
2015-05-23 13:45:29 UTC
Permalink
This post might be inappropriate. Click to display it.
descoubes
2015-05-25 14:15:13 UTC
Permalink
Hello all,
I am very pleased to inform you that the 1995 year bug on the TS2100 has
been solved.
You will have to replace the existing Trimble ACE III GPS receiver by
our N024 with special firmware.
If you wish to purchase it, just inform me how many units you will need,
and also your shipping address for cost calculation.
Best regards
Olivier
HEOL DESIGN



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Esa Heikkinen
2015-05-26 14:18:47 UTC
Permalink
descoubes kirjoitti:

> I am very pleased to inform you that the 1995 year bug on the TS2100 has
> been solved. You will have to replace the existing Trimble ACE III
> GPS receiver by our N024 with special firmware.

Does this also correct the 1 sec offset caused by upcoming leap second?
To remind, TS2100 GPS mode failed already in February, having 1 sec
offset right after the information about upcoming leap second was added.

How can we know that it doesn't fail again when actual GPS week rollover
will happen? Now it seems to be week 1846 and 2047 will come less than
four years. Did you test this with GPS simulator?

Best regards,

--
73s!
Esa
OH4KJU
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hal Murray
2016-06-27 20:51:43 UTC
Permalink
I assume you are doing this for fun. That means you get to do whatever you
think will be fun.

The DS3231 is pretty crappy by time nuts standards. If you can also measure
the temperature, you should be able to make neat graphs. If you watch it as
the temperature ramps up slowly, you should see a sawtooth pattern. The
crystal will track the normal freq/temp curve until the temperature changes
enough for the correction logic to add in another step.

Have you looked at tvb's PICPET and friends?
http://www.leapsecond.com/pic/picpet.htm
http://www.leapsecond.com/pic/picdiv.htm

I think he has one that turns 32KHz into PPS. You could feed that PPS into a
picPET running off your Thunderbolt.

If you have a spare counter, you can run that in frequency mode and feed that
to a PC.


Where are you going to collect the data?

The PPS input on a PC may be be useful.


***@heypete.com said:
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
...

Use one of the counters to divide things down to a rate that is easier to
handle.



--
These are my opinions. I hate spam.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Dan Rae
2016-06-27 22:28:29 UTC
Permalink
On 6/27/2016 1:51 PM, Hal Murray wrote:
> I assume you are doing this for fun. That means you get to do whatever you
> think will be fun.
>
> The DS3231 is pretty crappy by time nuts standards.
Maybe, but simply by adjusting mine by measuring the 32 kHz output with
an accurate counter I can get them to keep to within about one second a
month. I have two incorporated in homebrew HF transceivers that I built
and find that their performance is actually pretty impressive, /for what
they are/. Being able to set time zones and UTC offset from the radio's
front panel is also handy. After all they only claim to be a fairly
accurate clock. I doubt that any of the fancy schemes being proposed
for measurement will improve the basic accuracy much.

Dan


_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Pete Stephenson
2016-06-28 09:04:03 UTC
Permalink
On Mon, Jun 27, 2016 at 10:51 PM, Hal Murray <***@megapathdsl.net> wrote:
>
> I assume you are doing this for fun. That means you get to do whatever you
> think will be fun.

Indeed, this is strictly for fun. I have strange values for "fun".

> The DS3231 is pretty crappy by time nuts standards. If you can also measure
> the temperature, you should be able to make neat graphs. If you watch it as
> the temperature ramps up slowly, you should see a sawtooth pattern. The
> crystal will track the normal freq/temp curve until the temperature changes
> enough for the correction logic to add in another step.

Oh, I know the DS3231 isn't terribly great. The datasheet calling it
an "Extremely Accurate...RTC/TCXO/Crystal" makes me laugh, as it's
tooting its own horn.

For more precise stuff timing, I have a Thunderbolt and other goodies.
(Speaking of which, I really need to figure out how to use the
Thunderbolt as an external clock source for my Arduinos.)

Still, the DS3231 is a reasonably accurate RTC, inexpensively priced,
is easy to interface with my Raspberry Pis, Arduinos, etc., and
provides a handy 32kHz output. It also has an internal temperature
sensor that it checks every 64 seconds, the output of which is also
accessible. Your idea of plotting the temperature vs. frequency is a
good one; I'll add it to the project list.

> Have you looked at tvb's PICPET and friends?
> http://www.leapsecond.com/pic/picpet.htm
> http://www.leapsecond.com/pic/picdiv.htm
>
> I think he has one that turns 32KHz into PPS. You could feed that PPS into a
> picPET running off your Thunderbolt.

I have seen those, but I have little experience with PICs and the Wife
Acceptance Factor of buying more stuff for a one-off measurement is
low.

> If you have a spare counter, you can run that in frequency mode and feed that
> to a PC.

Alas, I'm ashamed to say I have no frequency counter at all.

> Where are you going to collect the data?

My plan was to have the ATmega328 simply output the data over a serial
connection so I can put it in a spreadsheet or something.

> The PPS input on a PC may be be useful.

Indeed. I normally use it for NTP.

Thanks for the advice!

Cheers!
-Pete

>
> ***@heypete.com said:
>> I'm a little concerned about the speed at which the pulses need to be
>> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
>> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
> ...
>
> Use one of the counters to divide things down to a rate that is easier to
> handle.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



--
Pete Stephenson
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Nick Sayer via time-nuts
2016-06-29 15:56:26 UTC
Permalink
>
> For more precise stuff timing, I have a Thunderbolt and other goodies.
> (Speaking of which, I really need to figure out how to use the
> Thunderbolt as an external clock source for my Arduinos.)
>

I don’t think you can do it for an Arduino without hardware changes. The CLKI pin is shared with XTAL1. But you can clock almost any AVR from an external clock source as long as the Vcc vs frequency “safe operating area” is respected (see the datasheet for your particular device). Note that if you fuse the device for an external clock source of any kind, that source must be present during (non-HV) programming as well as operation.

I use a DC blocking cap and self-biased inverter nowadays as an input conditioner for external clock inputs. It allows me to accept sine as well as square inputs if necessary. My principle use for this is my Crazy Clock calibrator, which I clock from one of my GPSDOs. It’s not 100% reliable, and I’m not sure why. Every once in a while, the AVR will lock up, even with the watchdog turned on. The square wave on CLKI looks *perfect*. I can only guess that there’s a glitch every once in a while that screws something up, but I haven’t figured it out yet.
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Van Horn, David
2016-06-27 22:14:13 UTC
Permalink
***@heypete.com said:
> I'm a little concerned about the speed at which the pulses need to be
> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]

Huh?

Instruction cycle time is 62.5nS for almost all instructions at that clock.
That’s a pretty long ISR by my standards.

1: Reserve a couple of registers for handling data inside ISRs, avoiding push and pop.
2: Reserve a register for holding SREG during the ISR.

ISR: in STEMP,SREG
At this point you can fearlessly trash SREG and ITEMP and ITEMP2
Do Stuff using ITEMP and ITEMP2.
Do as little as practical in the ISR, letting the non-isr code do the heavy lifting.
Out SREG,STEMP
RETI

Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 bit operations.
Keep data you need FAST in registers in the low page, rather than in RAM.





_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Pete Stephenson
2016-06-29 09:08:52 UTC
Permalink
On Tue, Jun 28, 2016 at 12:14 AM, Van Horn, David
<***@backcountryaccess.com> wrote:
>
>
> ***@heypete.com said:
>> I'm a little concerned about the speed at which the pulses need to be
>> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
>> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
>
> Huh?
>
> Instruction cycle time is 62.5nS for almost all instructions at that clock.
> That’s a pretty long ISR by my standards.

According to the "How long does it take to execute an ISR?" part of
http://www.gammon.com.au/interrupts, it takes 82 cycles total to
service an external interrupt (i.e. one triggered by an interrupt
pin), including the time needed to enter the ISR and to leave it after
it's done whatever you needed it to do. At 62.5nS for each clock
cycle, that's 5.125uS just to process the interrupt. That doesn't
include the time needed to execute whatever code you want it to do.

> 1: Reserve a couple of registers for handling data inside ISRs, avoiding push and pop.
> 2: Reserve a register for holding SREG during the ISR.
>
> ISR: in STEMP,SREG
> At this point you can fearlessly trash SREG and ITEMP and ITEMP2
> Do Stuff using ITEMP and ITEMP2.
> Do as little as practical in the ISR, letting the non-isr code do the heavy lifting.
> Out SREG,STEMP
> RETI
>
> Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 bit operations.
> Keep data you need FAST in registers in the low page, rather than in RAM.

Thanks! I think that may be a bit beyond my ken for the time being,
but I'll definitely keep it in mind for when I know more.

Cheers!
-Pete

--
Pete Stephenson
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Bob Camp
2016-06-29 11:04:44 UTC
Permalink
Hi

> On Jun 29, 2016, at 5:08 AM, Pete Stephenson <***@heypete.com> wrote:
>
> On Tue, Jun 28, 2016 at 12:14 AM, Van Horn, David
> <***@backcountryaccess.com> wrote:
>>
>>
>> ***@heypete.com said:
>>> I'm a little concerned about the speed at which the pulses need to be
>>> counted. The 32kHz pulses come in every ~30.5 microseconds, and handling an
>>> interrupt on an ATmega328 running at 16MHz takes about 5.125 microseconds[1]
>>
>> Huh?
>>
>> Instruction cycle time is 62.5nS for almost all instructions at that clock.
>> That’s a pretty long ISR by my standards.
>
> According to the "How long does it take to execute an ISR?" part of
> http://www.gammon.com.au/interrupts, it takes 82 cycles total to
> service an external interrupt (i.e. one triggered by an interrupt
> pin), including the time needed to enter the ISR and to leave it after
> it's done whatever you needed it to do. At 62.5nS for each clock
> cycle, that's 5.125uS just to process the interrupt. That doesn't
> include the time needed to execute whatever code you want it to do.

That all assumes you have turned interrupts off for some reason. Common
reasons could be that you are in another interrupt service routine or that
you are executing interrupt related code.

Bob


>
>> 1: Reserve a couple of registers for handling data inside ISRs, avoiding push and pop.
>> 2: Reserve a register for holding SREG during the ISR.
>>
>> ISR: in STEMP,SREG
>> At this point you can fearlessly trash SREG and ITEMP and ITEMP2
>> Do Stuff using ITEMP and ITEMP2.
>> Do as little as practical in the ISR, letting the non-isr code do the heavy lifting.
>> Out SREG,STEMP
>> RETI
>>
>> Optionally, set a register (I usually call it "ZERO") to 0x00 to speed up 16 bit operations.
>> Keep data you need FAST in registers in the low page, rather than in RAM.
>
> Thanks! I think that may be a bit beyond my ken for the time being,
> but I'll definitely keep it in mind for when I know more.
>
> Cheers!
> -Pete
>
> --
> Pete Stephenson
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Van Horn, David
2016-06-29 13:01:06 UTC
Permalink
>That all assumes you have turned interrupts off for some reason. Common reasons could be that you are in another interrupt service routine or that you are executing interrupt related code.
>
>Bob


What I saw in their interrupt routine was a "full boat" implementation, pretty typical for C code, saving registers without regard for what happens in the ISR, but nothing about the interrupts being turned off.
If you mean not having re-enabled ints during the ISR, then yes, and that is how I would urge anyone to write an ISR. The reason that you would re-enable ints during an ISR is that your ISR takes too long.
Making the ISR take even longer isn't really a solution. Write faster ISRs.

The key is to do absolutely as little housekeeping as needed, and have the ISR do as little as possible.

I have had cases where I didn't even preserve SREG because what I was doing in the ISR didn't alter SREG.

Don't blame the hardware for poor implementation of software.

There really is no actual minimum code in an ISR. In one case, I had a useful ISR that had actually no code in it!. A very special case, but they happen.
What I showed is my typical intro and outro code for probably 90% of what I write. I avoid pushing and popping because it wastes time. Copying SREG into a dedicated register is faster. Using dedicated ISR registers is faster than pushing and popping to free up registers.

All this pushing and popping causes deep stack usage, which isn't even an option on some processors. When your stack collides with your data, you're toast. It is to your significant advantage to minimize stack usage.

I will typically put a stack guard below where I expect the stack to live, and monitor that in the "sanity check" routine for any changes. The sanity check routine looks at this and other things that I know should never change, and if they are not the correct values, then the watchdog won't be reset. The sanity check routine is also the only place that the watchdog gets reset. WDRs scattered through the code are symptomatic of poorly written code.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Van Horn, David
2016-06-29 12:36:20 UTC
Permalink
This post might be inappropriate. Click to display it.
Brooke Clarke
2016-06-29 16:44:50 UTC
Permalink
Hi David:

I built a number of clocks based on PIC uC and using interrupts. The idea is to use the output from a frequency standard
as the heart beat of the clock.
Depending on what the PIC was doing when interrupted the delay can different by one cycle and a simple test corrects
that. Clock settable to 1ms and keeps perfect time.
http://www.prc68.com/I/PRC68COM.shtml#07092006
I wrote this directly using the Microchip assembler. I'm not a fan of C.

My first uC was the SWTP kit that came with no software. I learned to write directly in hex machine language. The
problem with that is every time code is changed inside a loop the target address needs to be recomputed. Later I got a
copy of the Motorola assembler and editor which was a big help.
http://www.prc68.com/I/comp.shtml#SWTP

--
Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html
The lesser of evils is still evil.

-------- Original Message --------
> O M G..
>
> So I followed the link and saw how they do it. Wow. They write interrupts like the DMV processes applications. I can only imagine what this looks like on the PIC, where every instruction takes 4x as many cycles.
> All of that pushing and popping is PRECISELY what you need to avoid.
> Pushing any register that the ISR does not actually change is totally insane.
> My average ISR is far shorter than their intro and outro code.
>
> "C" does not cooperate easily with this, but you can declare your interrupts "naked" and write them in assembler so as to avoid this insanity.
>
> I say this as someone who has been developing on the AVR platform for something like 20 years. My first application was on the 8515, and they didn't even have production silicon yet. My development was done on a chip with date code "ES" (Engineering Sample)
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hal Murray
2016-06-28 19:48:31 UTC
Permalink
***@heypete.com said:
> I have seen those, but I have little experience with PICs and the Wife
> Acceptance Factor of buying more stuff for a one-off measurement is low.

The PIC family is very similar to AVRs. The picPET and friends are 8 pin
DIPs so the Wife is unlikely to notice the additional clutter.


>> The PPS input on a PC may be be useful.
> Indeed. I normally use it for NTP.

Than you want a second serial port for things like this.

Or maybe you can use the parallel port if your system is old enough to have
one. I haven't tried it, but I think Linux has a module that supports it.



--
These are my opinions. I hate spam.



_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Scott Stobbe
2016-06-29 04:49:49 UTC
Permalink
For pulse counting, the timer hardware is the way to go. Setup a 16-bit
timer clocked off your DUT. Then input capture on your PPS edge. This
leaves you plenty of processor time for string formatting and other tasks
you may wish to perform.

If you do the decimation as post-processing on your PC (i.e. log cycle
count every PPS), you can use a zero-phase moving average filter, which may
provide more visual insight over just a single data point every 1000s.

On Tue, Jun 28, 2016 at 3:48 PM, Hal Murray <***@megapathdsl.net> wrote:

>
> ***@heypete.com said:
> > I have seen those, but I have little experience with PICs and the Wife
> > Acceptance Factor of buying more stuff for a one-off measurement is low.
>
> The PIC family is very similar to AVRs. The picPET and friends are 8 pin
> DIPs so the Wife is unlikely to notice the additional clutter.
>
>
> >> The PPS input on a PC may be be useful.
> > Indeed. I normally use it for NTP.
>
> Than you want a second serial port for things like this.
>
> Or maybe you can use the parallel port if your system is old enough to have
> one. I haven't tried it, but I think Linux has a module that supports it.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-***@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Pete Stephenson
2016-07-04 08:25:35 UTC
Permalink
I ended up doing just this and it worked out nicely. Using the timer
hardware as a counter freed up the CPU for other tasks and could run
in the background so I wouldn't miss any ticks. It turns out that
using the built-in timer hardware was a lot easier than using external
"jellybean" logic to accomplish the same thing, even if it took a bit
of reading to better understand it.

I whipped up a quick-and-dirty Arduino sketch that I've made available
at https://github.com/heypete/Frequency_Counter_32kHz/ for anyone
who's interested.

I make no claims to its quality, but I've tested it with runs from 10
seconds to 20,000 seconds and it seems to produce the expected results
on both a standard Arduino Uno and a bare 16MHz ATmega328P. Any
suggestions or improvements would be welcome.

Also, thanks to everyone for your assistance. It was a fun learning
experience and excursion outside the standard Arduino commands into
the mysterious depths of the datasheet and hardware registers.

Cheers!
-Pete

On Wed, Jun 29, 2016 at 6:49 AM, Scott Stobbe <***@gmail.com> wrote:
> For pulse counting, the timer hardware is the way to go. Setup a 16-bit
> timer clocked off your DUT. Then input capture on your PPS edge. This
> leaves you plenty of processor time for string formatting and other tasks
> you may wish to perform.
>
> If you do the decimation as post-processing on your PC (i.e. log cycle
> count every PPS), you can use a zero-phase moving average filter, which may
> provide more visual insight over just a single data point every 1000s.
>
> On Tue, Jun 28, 2016 at 3:48 PM, Hal Murray <***@megapathdsl.net> wrote:
>
>>
>> ***@heypete.com said:
>> > I have seen those, but I have little experience with PICs and the Wife
>> > Acceptance Factor of buying more stuff for a one-off measurement is low.
>>
>> The PIC family is very similar to AVRs. The picPET and friends are 8 pin
>> DIPs so the Wife is unlikely to notice the additional clutter.
>>
>>
>> >> The PPS input on a PC may be be useful.
>> > Indeed. I normally use it for NTP.
>>
>> Than you want a second serial port for things like this.
>>
>> Or maybe you can use the parallel port if your system is old enough to have
>> one. I haven't tried it, but I think Linux has a module that supports it.

--
Pete Stephenson
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Loading...