[time-nuts] Re: St Veran gravity red-shift misson

Bob Camp kb8tq at n1k.org
Tue Jul 18 15:02:41 UTC 2023


Hi

Yup, it certainly did. It was somewhat unique i that specific bug. It also had a pretty nasty
roll over issue on some versions of the firmware. I believe some firmware updates
went out to OEM’s to fix this and that. I don’t know if they are available to the general 
public. 

Bugs are indeed a very common thing in giant piles of code. All these modules are 
well into that range. The CW parts are in no way unusual for having a bug here or a bug 
there….. They simply are the only ones I’ve seen with the 1 ms jump issue. 

Bob

> On Jul 18, 2023, at 4:36 AM, Azelio Boriani via time-nuts <time-nuts at lists.febo.com> wrote:
> 
> The CW12 (based on the CW25) had PPS jumps in 1ms steps. It was
> discussed here about ten years ago. I'm not able to find anything in
> the archive right now. I had that issue in my GPSDO where the PPS
> would jump an integer number of ms and stay there until a power cycle.
> 
> On Tue, Jul 18, 2023 at 7:25 AM Magnus Danielson via time-nuts
> <time-nuts at lists.febo.com> wrote:
>> 
>> Kit,
>> 
>> So, with that spirit, I keep updating.
>> 
>> Life on the observatory base is somewhat different. The power is
>> delivered from photovoltic panels and stored in a battery bank, water
>> comes from the melt water of snow. Therefore being restrictive with
>> energy and water is both encouraged and required. Drinking water each
>> mission bring up. You leave provisions for the next mission, so there is
>> a discovery delight in finding what previous mission donated over. Half
>> the house is for astronomers, and half the house for the housekeeper and
>> tourists. The tourists provide a source of income, but every day we get
>> the oppertunity to explain what we do, and it is not an insignificant
>> part of a mission here. There is also hikers that comes over they day.
>> 
>> As for experiment, the setup was done in a haste. This also means
>> accidents happens and cleanup needs to be done. I lost the 12 V bus when
>> converted failed. Turns out, due to another issue I had, and I am not
>> proud to say this, a short circuit. Luckily there is a wealth of fuses
>> (and a wealth of spare fuses). When the more critical parts sorted
>> itself out, I have been able to debug the 12V side and resurrect the
>> large pressure sensor and a TICC.
>> 
>> As we arrived, we where a little too tired, so lifting batteries failed
>> so I dropped a pair (again not proud), and the connection broke between
>> the pair. No short circuit and I could quickly secure the connection to
>> avoid short circuit. I was able to repair the connection and hook the
>> batteries up to the charger again, so I have full battery capability again.
>> 
>> I've been able to integrate the Victron MPPT charger into the
>> InfluxDB/Grafana environment. While this sis not very critical when on
>> base, it will be relevant as we travel down, as that is a more
>> challenging thing.
>> 
>> I've been able to make many upgrade to the Grafana environment.
>> 
>> We have had some initial data from the GNSS processing, and discovered a
>> 1 ms jump in time, but under that we see cesium noise as we should. We
>> suspect that this comes from any of a number of sources, for integer 1
>> ms jumps can exist in receivers and compensated by post-processing
>> tools. We will start to analyze that. As a caution we took the decision
>> to synchornize the PPS of the cesium, as a previous failure it was not
>> initiated but kept. With measurements we felt confident we could take
>> the disruption and start measure again. The underlying 10 MHz is not
>> affected.
>> 
>> As you see, things happens. Maintaining a log of what happend when is
>> important. Some of these failures was completely avoidable, but lack of
>> time, stress, tiredness contributed to the process. As the mission
>> progresses, robustness is improved. Considering that just continuous
>> operation in a dynamic environment of a car over several days, then
>> reloading to another car and then reloading into the station and
>> transport up is challenging, but only once we lost power to cesium, and
>> that was before it was really critical. We lost logging in GNSS
>> receivers due to cable errors and power issues. We lost logging in
>> Raspberry pi due to power issues and not having the time to make things
>> autostart. Then again, I keep working to improve robustness, provide
>> fixes and make other improvements.
>> 
>> I get the oppertunity to learn more about Raspberry Pi environment,
>> Python, InfluxDB, Grafana and a whole bunch of sensors.
>> 
>> The aim is to leave tools and knowledge for comming adventures, and as
>> we do this again, we do it better from start from all we learned this time.
>> 
>> I had also intended to bring a passive hydrogen maser, but it was too
>> much work remaining, as it had issues and had not locked up. However,
>> I've built an improved toolset to apply for more devices as well as the
>> home lab.
>> 
>> I've written python code to integrate masers and environment sensors and
>> push into the InfluxDB, this is done using Python. While some is not yet
>> "clean" in so many aspects, not only me learning Python but also a few
>> short-cuts that I want to fix later, some stuff has been done pretty OK.
>> For Grafana, I keep updating things as I learn. I intend to export the
>> Grafana Dashboards and have them available with the code, so that you
>> can use both the python code and the Dashboard for your 5071. The
>> Grafana Dashboard is done in JSON, so that should work well. I need to
>> parametrize it, because if you have multiple clocks, you want a
>> dashboard for each clock. I have already prepared so that all data
>> gathering tags it with both masertype and maser.
>> 
>> It may sound like a lot, but it is quite small amount of code, but it
>> helps a lot.
>> 
>> There is a whole round of other issues such as having udev mapping
>> device drivers to the right place, and that I need to fix, it's part of
>> overall robustness. I've done some work, but not enough.
>> 
>> You only learn by attempting to do something. You only risk failing by
>> attempting. So far, we had minor failures, but nothing catastrophic.
>> After arriving to the base, new problems have not arrived at the same
>> rate or degree of risk. There is not much remaining uphill from here! :)
>> (The actual peak is a nice little hike we will do)
>> 
>> We do this not because it is easy, but because we thought it would be
>> easy! ;-D
>> 
>> I hope to be able to spend more time on the scientific result data now
>> that other practical issues pan out.
>> 
>> The 5071A is humming about just fine. I can see how control loops combat
>> temperature shifts. Closed loop controls on essentially all parameters
>> will suppress environmental effects over to phase and frequency. It is
>> only by exposing it to non-ideal environments that you can see that, and
>> I've added as much environmental stuff as I could in order to capture as
>> much data on that as I can, even if this is lower priority and less than
>> ideal.
>> 
>> Validation of sensors is a separate topic alone. I've seen temperature
>> dependences even from calibrated stuff. That will be analyzed.
>> 
>> Cheers,
>> Magnus
>> 
>> On 2023-07-17 05:24, Kit (Kitski) wrote:
>>> Magnus,
>>> 
>>> A wonderful word-picture you're painting.  Please keep the messages flowing.
>>> 
>>> Take care,
>>> 
>>> Kit
>>> VK1LL
>>> 
>>> -----Original Message-----
>>> From: Magnus Danielson via time-nuts <time-nuts at lists.febo.com>
>>> Sent: Sunday, July 16, 2023 6:42 PM
>>> To: Christopher Hoover <ch at murgatroid.com>; Discussion of precise time and frequency measurement <time-nuts at lists.febo.com>
>>> Cc: Magnus Danielson <magnus at rubidium.se>
>>> Subject: [time-nuts] Re: St Veran gravity red-shift misson
>>> 
>>> Dear Christoffer,
>>>>>> snip
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com




More information about the Time-nuts_lists.febo.com mailing list