Re: St Veran gravity red-shift misson
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@lists.febo.com
Sent: Sunday, July 16, 2023 6:42 PM
To: Christopher Hoover ch@murgatroid.com; Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Magnus Danielson magnus@rubidium.se
Subject: [time-nuts] Re: St Veran gravity red-shift misson
Dear Christoffer,
snip
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@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@lists.febo.com
Sent: Sunday, July 16, 2023 6:42 PM
To: Christopher Hoover ch@murgatroid.com; Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Magnus Danielson magnus@rubidium.se
Subject: [time-nuts] Re: St Veran gravity red-shift missonDear Christoffer,
snip
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@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@lists.febo.com
Sent: Sunday, July 16, 2023 6:42 PM
To: Christopher Hoover ch@murgatroid.com; Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Magnus Danielson magnus@rubidium.se
Subject: [time-nuts] Re: St Veran gravity red-shift misson
Dear Christoffer,
snip
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com