Lars DIY GPSDO with Arduino and 1ns resolution TIC

[Mike99]

Afaik for example the 7"M" is rom-based (an needs battery backup) and 7"N" has got the flash (provided it is not fake)..
https://portal.u-blox.com/s/question/0D52p00008HKCbDCAX/how-update-firmware-for-ublox-7-by-ucenter

Yes, that is correct. I replaced the modules with 8M and M8T which both have flash memory.

Mike

[AndrewBCN]

Unfortunately Lars is not among us anymore, but I just wanted to express my sincere admiration for the brilliant engineering in his DIY GPSDO project. The more I examine his circuit (which is apparently very simple) and the more I read his source code (well... not so simple), the more I understand the long hours and sheer dedication poured into this masterpiece project.
I have browsed through the dozen or so DIY GPSDO projects published on the net, and two projects really standout:
1. Brooks Shera's original project from 1998, which was the precursor to all other DIY GPSDO projects.
2. Lars' DIY GPSDO, which was inspired by Shera's design.
Both are based on a PLL control loop, but it's interesting to see how they differ in the way they implement it, and how each project tried to maximize the functionality of the MCU used (a PIC 16C73 in Brooks Shera's design, an ATmega 328P in Lars' design).

[Johnny B Good]

Hi Mike,

 Last night/this morning, I finally got round to rerunning an experiment I did a few months ago to compare the timing offsets between the GPS, the Glonass and Galileo constellations where I discovered (but didn't make hard copy notes of) the offsets involved. I seem to recall that the Galileo offset from GPS had been in the 3 to 5 ns region whilst that of the Glonass had been a massive 18ns or so.

 I reran only the GPS versus Galileo experiment (the Glonass had been so far out, I didn't see any point in repeating that experiment ) and my best estimate of the offset this time round was that it was somewhere around the 1 to 2ns mark.

 Since I'd gained the impression that using the GPS on its own had definitely, if only slightly worsened the VFC variations to circa 600uV pk-pk versus the 300 to 400uV when using both GPS and Galileo together, I decided to go back to that combination after running this test.

 The daily  room temperature mediated VFC voltage excursions are around the the 1mV at present - not an issue as far as a basic James Miller styled GPSDO design is concerned. Quite frankly, a basic, microcontroller free GPSDO can deal with this sort of temperature variation (a half to one degree per hour rate of change) without any measurable detriment to its phase stability. With a single frequency timing module like the M8T, the biggest issue is that of the ionospheric induced phase shifts at rates of 1 to 5ns per 5 to 15 minutes and longer time periods which totally swamp the slower room temperature variations which are almost totally compensated for by being part of the PLL error correction process anyway.

 The upshot of this being that I'm not at all surprised at your improved stability and tighter positional survey in results after ditching the GLONASS constellation. 

John

 Regarding the above, I now have what may be news to everyone. I'd put my RFS project in hiatus for lack of a suitable enclosure to accommodate the additional 2cm thick polystyrene foam all around the LPRO-101 and just recently decided to resume the project sans case but with the LPRO-101 insulated as above to continue testing - with that much insulation, an actual enclosure becomes somewhat redundant when running thermal stability tests.

 Anyhow, the news is that including the Galileo constellation now seems to be degrading the timing as I eventually discovered after trying to syntonise the RFS to my basic GPSDO over the past three or four days. Instead of the 6ns pk-pk wobbles on the GPSDO's output, along with the corresponding 300μV variation on the VFC pin that I had been typically observing some eight months back, I was now seeing some 10 to 12ns pk-pk (along with 600μV variations in the VFC voltage) which was making my attempts at syntonising the RFS an all but impossible task.

 I'd started monitoring the M8T's performance through the u-centre app the day after starting this current round of testing to see if there was any obvious reason for the degraded stability. Everything looked normal so I carried on struggling and monitoring for a few more days until this afternoon when I decided to exclude the Galileo SVs to see whether sticking only with the GPS SVs would have any effect.

 After the initial 50ns phase excursion transient such configuration changes cause, there was an immediate improvement in the phase stability of the GPDSO's output. I'm still seeing variations but they now seem to be back to what they had been some eight months ago.

 I'm now fine tuning the RFS after having forced the fan to run full tilt off its current 12v supply (I'm going to use 15 v in the final design) to bring the baseplate temperature down to just 3.2 deg C above room temperature to get a better idea of the max room temperature margin for my current 36 deg baseplate temperature setting. I expect to have a slightly lower delta T at that setting on account of it being closer to the physics package set temps with less heat energy being pumped in by the heaters (and a bit more whoomph courtesy of the 15v supply). I'm aiming for a max room temperature rating of 32 deg or better with a minimum room temperature limit around the 15 deg mark.

 The lower limit will be defined by the level of passive heat leakage when the fan is at a standstill. To this end I'm mounting the LPRO-101 on its edge with the fan cooled heatsink fins parallel to the base to minimise convective cooling from the plenum intake mounted to draw in cooling air via a large vent in the base of the enclosure which will be raised by 10mm rubber feet. The exhaust air vents will be low down on the rear panel to kill off any convective air flow to minimise heat loss at the lower temperature extreme. However, I will be testing the current uncased assembly outdoors in the cool night air to determine whether I actually need to go to quite such an extreme with the ventilation layout (or, Heaven forfend! add a "cold weather" heating circuit).

 Anyhow, it does look as though using both GPS and Galileo constellations together is now no longer the good idea it once was. The chances of getting the RFS to keep within half a cycle or better over a 24 hour test run are now looking a lot better since I dropped the Galileo constellation. Only time will tell.

[Johnny B Good]

I have the results for my "24 hour" test run, comparing my RFS project's frequency stability against a modern day respin of the rather worthy James Miller GPSDO (essentially just a GPS rx module update  using a u-blox M8T instead of the original Jupiter  GPS engine).

 The "24 hour" test run was more like a 26 to 28 hour run, hence the quotes. Anyhow, I didn't manage to achieve the half cycle in 24 hours target I'd hoped to hit but did manage to better the one cycle drift limit in 24 hours which I'd not been able to manage in any of my earlier tests over six months ago.

 One of the issues being the question of the sensitivity of the LPRO-101 to barometric pressure variations which in my location, showed up as a drop from 1003 to 983 mBars during the past three days, over half of which occurred in just the last 24 hours. According to this Dec 1975 NIST document  https://tf.nist.gov/general/pdf/82.pdf I would have expected the RFS to have dropped in frequency rather than show the increase revealed by my test run.

 That NIST document whilst getting on for half a century old offers some interesting insights into Rb lamp atomic clock technology which remains essentially unchanged between then and when my LPRO-101 had been manufactured circa 1998 with some 23 years worth of technological refinements (eg the unnamed unit they'd used was twice the volumetric size of the LPRO).

 I'd started this test run yesterday, just before teatime (6pm BST or 1700 hrs UTC - the scope date/time being 4 minutes behind UTC makes this a relevant point), possibly even an hour earlier but it hadn't occurred to me to take a screenshot or two to mark the event. If I had, it would have looked a dead ringer for the final screenshot of the sequence I took over the final 5 hours or so of the run.

 I've archived them into two 7z files to stay within the EEVBlog 5MB server limit and attached the first 7z file plus the first 9 images uncompressed to this post with the second 7z file plus the last 9 uncompressed images to the follow up post for anyone the least bit curious in my RFS v GPSDO stability contest. I've included the uncompressed images as a common courtesy to those, who like me, find it a bit of an imposition to have to actually download an attachment before you get the chance to view its contents.

 I've chosen to trigger from the GPSDO (CH2) even though that's the source of the 6ns pk-pk wobble simply because long term it remains within a few ns of the World's Atomic Time reference (effectively 'zero drift'). The RFS (CH1), otoh, can and will drift even if that drift is some 2 or 3 orders of magnitude less than a typical OXCO, hence the need to calibrate it against a World Atomic Clock  derived standard such as that offered by the GPS system.

 

[Johnny B Good]

As per the preceding post, here are the second lot of attachments.

[erikka]

Hope there is someone here that understands the calculation routine

Somewhere at the beginning there is this line

 timer_us = timer_us + 50000 - (((timer1CounterValue - timer1CounterValueOld) * 200 + TIC_Value - TIC_ValueOld)+50000500)/1000;

and later

    diff_ns = (timer_us - timer_us_old)*1000 + long (TIC_ValueCorr - TIC_ValueCorrOld + 0.5); // = Frequency in ppb if updated every second! Note: TIC linearized

Where TIC_ValueCorr is the quadratic corrected TIC_Value

So why is the phase used twice? Once with the uncorrected value and once with the corrected value?

[AndrewBCN]

Hope there is someone here that understands the calculation routine
...
So why is the phase used twice? Once with the uncorrected value and once with the corrected value?

Hi Erik,
I have little knowledge of the Lars' source code, but from my limited understanding:

1. The TIC is very much non-linear, so you want the linearized (corrected) phase values when they are used to calculate the OCXO frequency.

2. On the other hand, the non-linearity does not seem to affect the timer calculation, so the non-linearized (uncorrected) values can be used.

[AndrewBCN]

Hello,
I would like to upload Lars' code to GitHub, so I wanted to know if anybody here is aware of what open source license would be applicable (of course the copyright is and will remain Lars Walenius, over the software and hardware design).
Also if there is any member of the family or friends I should ask for permission and how to get in touch?
Thank you all for your help regarding this matter.
Andrew

[Miti]

You may contact forum member HighVoltage, he may be in contact with his family. See below.

https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/

[AndrewBCN]

You may contact forum member HighVoltage, he may be in contact with his family. See below.

https://www.eevblog.com/forum/metrology/farewell-to-our-friend-lars/

Thank you. 

PM sent to HighVoltage.

[AndrewBCN]

After receiving a kind answer from HighVoltage, I have created a repository on GitHub for Lars' DIY GPSDO with copyright 2017 Lars Walenius on all files, under a GPL V3 Open Source license.
This I believe respects Lars' wishes for his project, before he passed away.
The files are unchanged from Lars' first post in this thread.

The repository is here: https://github.com/AndrewBCN/Lars-DIY-GPSDO

The README in the repository points back to this thread.

[2N3055]

After receiving a kind answer from HighVoltage, I have created a repository on GitHub for Lars' DIY GPSDO with copyright 2017 Lars Walenius on all files, under a GPL V3 Open Source license.
This I believe respects Lars' wishes for his project, before he passed away.
The files are unchanged from Lars' first post in this thread.

The repository is here: https://github.com/AndrewBCN/Lars-DIY-GPSDO

The README in the repository points back to this thread.

Very nice of you and very respectful of late Lars. Thank you.

Regards,
 Sinisa

[AndrewBCN]

Hi,
I have undertaken the long term project of refactoring Lars' code / Arduino sketch for his GPSDO. My objective is to keep Lars' code mostly intact without any changes or adding any new features, but add comments, rearrange the code, correct the indentation and other formatting details, etc to improve readability and maintainability. Note that this is in no way a criticism of Lars' elegant code.

I guess I'll spend around an hour per week for the coming months working on this.

If any of you have read or worked on Lars' code and would like to comment or discuss any parts, please feel free to chime in. There are many parts that are still a black hole for me, and unfortunately Lars is not among us anymore to answer any questions.

To give you an example of the mostly trivial changes I am making to the original code:

Lars used

Code: [Select]

Serial.println("");
which I replace with

Code: [Select]

Serial.println();
Attached what I have done until now. I'll probably post on my progress around once per month.

EDIT: I forgot to add that I am currently building a version of Lars' DIY GPSDO to be able to test the refactored code for regressions. I'll post a few pics once I have it working.

[metrologist]

Hi,
I have undertaken the long term project of refactoring Lars' code / Arduino sketch for his GPSDO. My objective is to keep Lars' code mostly intact without any changes or adding any new features, but add comments, rearrange the code, correct the indentation and other formatting details, etc to improve readability and maintainability. Note that this is in no way a criticism of Lars' elegant code.

I guess I'll spend around an hour per week for the coming months working on this.

If any of you have read or worked on Lars' code and would like to comment or discuss any parts, please feel free to chime in. There are many parts that are still a black hole for me, and unfortunately Lars is not among us anymore to answer any questions.

To give you an example of the mostly trivial changes I am making to the original code:

Lars used

Code: [Select]

Serial.println("");
which I replace with

Code: [Select]

Serial.println();
Attached what I have done until now. I'll probably post on my progress around once per month.

EDIT: I forgot to add that I am currently building a version of Lars' DIY GPSDO to be able to test the refactored code for regressions. I'll post a few pics once I have it working.

Isn't the first print case used to print string data and the second to print a value of a variable?

Edit: OK, I looked at your code and then read https://forum.arduino.cc/t/serial-print-f-hello-world/411623

I wanted to add the ability to print to OLED and read GPS NMEA data, and I think I needed more program space than the 328 has to do so.

Thanks!

[AndrewBCN]

...
Lars used

Code: [Select]

Serial.println("");
which I replace with

Code: [Select]

Serial.println();

Isn't the first print case used to print string data and the second to print a value of a variable?

What this code does in both cases is simply print a linefeed character to serial. Adding the empty double quotes "" (an empty string) as a parameter changes strictly nothing so is redundant.

It's a very tiny change in Lars' code but it's the sort of thing that improves the readability, imho.

And indeed, Lars' code is very dense, because he had to work with the ATmega328P's limited 32kB of flash and 2kB of RAM. I haven't tried it myself but I don't think there is enough program space left to add code for a display or a GPS library to parse NMEA messages.

I do have an OLED and I do parse NMEA messages in my STM32 GPSDO, but I am using 130kB of flash. 

[metrologist]

That is what I figured so it seemed I would use a second 328p to read both the GPS and the serial out of Lars' 328p controller.

[MIS42N]

Use assembler for 8 bit processors. C is OK when there's plenty of memory. PIC16F1455 has 14kbyte program memory and 1kbyte RAM. My GPSDO program occupies about half the program and most of the RAM. Fully decodes NMEA messages to get date, time, validity of fix. 32 bit signed arithmetic. Could use less RAM, it keeps a history of control voltage changes. I was going to use a nano but it didn't have the right peripherals. Driving a display would be tricky with 14 pin package, would need to go to 20 pin PIC16F1459.

[AndrewBCN]

That is what I figured so it seemed I would use a second 328p to read both the GPS and the serial out of Lars' 328p controller.

Use assembler for 8 bit processors. C is OK when there's plenty of memory. PIC16F1455
...

There are probably various different solutions, it really all depends on what family of processors and programming tools you feel more comfortable working with.

[metrologist]

Hey all - I got inspired to pull out my lars GPSDO project. I didn't have a good GPS and recently came across the Condor C1919C module (PPS +/-25ns). It's still a navigation GPS but much better than what I had. Even so, I was not getting stable lock status even at low TC. One thing I wanted to try was to generate the PPS from a 10M OCXO using PICDiv, and here I have set that up, but I still do not get good lock status.

The ns stabilizes at large offsets. I think Lars said somewhere that the system needs some instability, but it's been a while so not sure. I'd expect this setup to drift, but rather slowly, and still keep very good lock.

Here is plot of ns and DAC after initiating run mode (after a day of warm-up). tc=4. ns settles in at ~-1500. I am monitoring both 10M reference and 10M disciplined OCXO on scope and see it tune in fairly quickly. The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value. Lars says that Lock will occur when the TIC value is within 100ns for five time constants. He mentions TC=16s so maybe with tc=4 that is different?


Here is 3000 seconds plot of ns and lock status. tc=4. I am not sure why it goes in/out of lock when it does.


I have not had success acquiring lock with higher tc, but these runs above were latest after tinkering with tuning pots and voltage regulator circuit so will try again now.

Another thing that might be plaquing my project is the OCXO. I've noticed some spikes or frequency jumps. When I see a 60ns spike, the same DAC line has a spike. Then I'm not sure if the DAC made the spike or it's reacting to change in frequency, or maybe the flip-flop missed a cycle. I suspect some frequency jumps I was seeing, where the ns value suddenly changed 200ns might have been due to flakey tuning pot on ref xo.


Update:

Here is plot of run after changing tc=16. It stabilizes quickly around ns=4100. It will run like this but never get lock.

[AndrewBCN]

I didn't have a good GPS and recently came across the Condor C1919C module (PPS +/-25ns). It's still a navigation GPS but much better than what I had. Even so, I was not getting stable lock status even at low TC. One thing I wanted to try was to generate the PPS from a 10M OCXO using PICDiv, and here I have set that up, but I still do not get good lock status.
...

From the charts you posted it seems to me like your GPS module is frequently loosing good satellite acquisition, which causes the PLL to lose lock, then when the GPS reacquires enough satellites, the PLL (with a short time constant) reacquires lock, and the cycle repeats erratically. AFAIK some GPS modules will continue to output a 1PPS signal even when they have marginal satellite reception and their accuracy is all over the place. The PPS +/-25ns specification assumes ideal conditions.

Lars' DIY GPSDO like many other DIY GPSDOs was not designed to monitor the GPS module satellite reception, you have to rely on an external device (a PC, another MCU, or an SBC such as a Raspberry Pi) reading the serial output stream from the GPS module to understand what is happening. If you were using a u-blox module I would advise you to check your GPS module with u-blox ucenter, otherwise there is the excellent Lady Heather software.

All the above assumes you are using the 1PPS from the GPS module as an input to Lars' TIC. You should not use the 1PPS from a picDIV connected to a second 10MHz OCXO, as an input to Lars' TIC. Otherwise what you'll get is exactly what you got: a fixed, more or less constant phase difference that never gets reduced to <100ns (you never get a PLL "locked" status).

[metrologist]

I didn't have a good GPS and recently came across the Condor C1919C module (PPS +/-25ns). It's still a navigation GPS but much better than what I had. Even so, I was not getting stable lock status even at low TC. One thing I wanted to try was to generate the PPS from a 10M OCXO using PICDiv, and here I have set that up, but I still do not get good lock status.
...

From the charts you posted it seems to me like your GPS module is frequently loosing good satellite acquisition, which causes the PLL to lose lock, then when the GPS reacquires enough satellites, the PLL (with a short time constant) reacquires lock, and the cycle repeats erratically. AFAIK some GPS modules will continue to output a 1PPS signal even when they have marginal satellite reception and their accuracy is all over the place. The PPS +/-25ns specification assumes ideal conditions.

Lars' DIY GPSDO like many other DIY GPSDOs was not designed to monitor the GPS module satellite reception, you have to rely on an external device (a PC, another MCU, or an SBC such as a Raspberry Pi) reading the serial output stream from the GPS module to understand what is happening. If you were using a u-blox module I would advise you to check your GPS module with u-blox ucenter, otherwise there is the excellent Lady Heather software.

All the above assumes you are using the 1PPS from the GPS module as an input to Lars' TIC. You should not use the 1PPS from a picDIV connected to a second 10MHz OCXO, as an input to Lars' TIC. Otherwise what you'll get is exactly what you got: a fixed, more or less constant phase difference that never gets reduced to <100ns (you never get a PLL "locked" status).

I went back to using my Condor GPS and monitored status using Trimble time lab. It only locks to 9 SVs but showed to be fully locked. From what I can tell, it's actually locked as the diff_ns numbers wander around low values like usual (mostly under 10 with periodic 20-30ns jumps + or -). For some reason it settles in a few thousand ns low.

I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing? I certainly expect a free-running OCXO to drift, but wouldn't the drift, especially divided down, be very small and take years to show in any significant way? I've had a free running OCXO that I tuned to another GPS reference a couple years ago. I measure that one periodically and the long term drift has been trending in the same direction and is +3.5 Hz over the two year period (using a counter referenced to GPSDO). That is just within its aging spec. The short term drift of the ÷10M should be on the order of ps.

This is the same project board and setup I was using with a +/- 100ns GPS a couple years ago and it used to at least lock in around 0 ns. I think something is wrong but cannot figure out what. The 1M, 5M, and 1us decay are all there.

[AndrewBCN]

...
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing?
...

Because unless you are disciplining the OCXO, the 10MHz from the OCXO divided down to 1 Hz does not really get you 1Hz, it gets you a 1s period +/- a fixed bias. That is not a problem per se, but (if I have understood Lars' "calculation" routine correctly) Lars' DIY GPSDO does various calculations based on the assumption that the 1PPS from a GPS has an exact 1s period with a statistically zero bias (which is a very reasonable assumption, I think). I believe this is why you get: "... The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value..."

You can check if I am right or wrong by simply switching back the 1PPS to that from a GPS, and verifying whether or not you get a low ns value.

Note that all the above is from the little I managed to understand of Lars' code, and maybe I am completely wrong.

[thinkfat]

...
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing?
...

Because unless you are disciplining the OCXO, the 10MHz from the OCXO divided down to 1 Hz does not really get you 1Hz, it gets you a 1s period +/- a fixed bias. That is not a problem per se, but (if I have understood Lars' "calculation" routine correctly) Lars' DIY GPSDO does various calculations based on the assumption that the 1PPS from a GPS has an exact 1s period with a statistically zero bias (which is a very reasonable assumption, I think). I believe this is why you get: "... The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value..."

You can check if I am right or wrong by simply switching back the 1PPS to that from a GPS, and verifying whether or not you get a low ns value.

Note that all the above is from the little I managed to understand of Lars' code, and maybe I am completely wrong.

Hm, as far as I understood Lars' code, the control loop will align the disciplined LO to whatever source provides the 1PPS. If that's a separate divided-down 10MHz OCXO, the disciplined LO will be phase aligned with it. I've frequently used a 1PPS signal out of an AWG for testing and it always worked within reason, so long as the 1PPS was somewhat close to 1 second. Within reason means that the target frequency for the LO must be within its pull range, of course. But that's the only limitation, AFAICS. The control code will take the LO frequency as gospel. So the ns readings may be indeed a bit off against an external, accurate time source, but that's about it.

[metrologist]

...
I'm not sure why a 10M OCXO divided down to 1Hz would not be a suitable PPS for testing?
...

Because unless you are disciplining the OCXO, the 10MHz from the OCXO divided down to 1 Hz does not really get you 1Hz, it gets you a 1s period +/- a fixed bias. That is not a problem per se, but (if I have understood Lars' "calculation" routine correctly) Lars' DIY GPSDO does various calculations based on the assumption that the 1PPS from a GPS has an exact 1s period with a statistically zero bias (which is a very reasonable assumption, I think). I believe this is why you get: "... The routine always starts at top end of dac and seems to stop when it gets the signal stable in phase rather than tune in to a low ns value..."

You can check if I am right or wrong by simply switching back the 1PPS to that from a GPS, and verifying whether or not you get a low ns value.

Note that all the above is from the little I managed to understand of Lars' code, and maybe I am completely wrong.

Hm, as far as I understood Lars' code, the control loop will align the disciplined LO to whatever source provides the 1PPS. If that's a separate divided-down 10MHz OCXO, the disciplined LO will be phase aligned with it. I've frequently used a 1PPS signal out of an AWG for testing and it always worked within reason, so long as the 1PPS was somewhat close to 1 second. Within reason means that the target frequency for the LO must be within its pull range, of course. But that's the only limitation, AFAICS. The control code will take the LO frequency as gospel. So the ns readings may be indeed a bit off against an external, accurate time source, but that's about it.

That's what I expect. Time is a relative thing, so the system has no reference to absolute time. I expect the reference OCXO primary phase drift to be less than 0.1rad/day, and 10 million times less on the PPS.

My second plot above shows phase wander between -1110ns to -1120ns (10ns total) over more than 600 seconds. I think I could say that is the noise of the system, but I the fact it's locked in so far off I cannot say. I cannot even toss out wild ideas of why it's behaving this way.

Any suggestions? I'm going to reload the Arduino code in the off chance I was monkeying around with it a couple years ago (unlikely).

[metrologist]

I figured out the problem!

My tempcoeff was set to max dac. I bet I fat fingered a dac setting (d vs c). I was absolutely going bonkers. Top it off, this new PC had to have everything set up again. I could not get the Arduino IDE to program (had to set tools>processor>old bootloader), and then I was not aware that EEPROM data is not erased when uploading a new "sketch". That is what gave me a clue - to look for f2 defaults.

Actually, I have a new theory how this happened. A high energy, OMG cosmic particle came from deep space, scattered through our atmosphere, and one of the secondary particles hit my Arduino and flipped the tempcoeff value's msb. It's happened before, and it coulda happened to me too... 

Thanks everyone who chimed in. Please continue the normal discussion...