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

[Magnus Danielson]

Dear Krishna,

Our goal is to illustrate the gravitational red-shift of general 
relativity. Then, we try to record environmental measures to illustrate 
any sensitivity we end up seeing.

It's more a pedagogical exercise than science, but we attempt to do it 
as scientific as possible.

It's done in cooperation with Observatoir Royal de Belgique and a few 
others, as you can find in another post.

It's interesting to see just how much of my hobbyist gathering of 
equipment can be put into use.

Cheers,
Magnus

On 2023-07-19 02:26, Krishna Makhija wrote:
> Hello Magnus,
>
> Not sure if you mentioned this elsewhere, but I am curious about what 
> exactly you are trying to do. What exactly are the science goals? Have 
> they been documented somewhere?
>
> -Krishna
>
> On Tue, Jul 18, 2023 at 12:40 PM Magnus Danielson via time-nuts 
> <time-nuts at lists.febo.com> wrote:
>
>     Jim,
>
>     Thanks for the kind words. I try to keep you updated, and that
>     becomes
>     easier and easier now that much of the clean-up is done. This
>     experiment
>     continues as we travel back, since we need the reference measurements.
>
>     I take photos and share on my Facebook page. Maybe I should collect
>     things on a web-page. Other work is part of the mission, so I just
>     come
>     out of an interview that me and Bruno Bertrand of Observatoir
>     Royal de
>     Belgique did. This is done in cooperation with them and further
>     support
>     from their excelent scientist Pascal du Fraigne.
>
>     Further, we attempt to document things for a film that should become
>     accessable eventually.
>
>     I think it is important to be transparent with the challenges and
>     hurdles. Some of them is unique to a mission like this, but some
>     is as
>     relevant for a static lab. I'm working on software support that I
>     keep
>     updating and aim to improve further as things go more quiet here.
>
>     I've made stupid mistakes due to stress and fatigue, let's
>     identify them
>     for what they are.
>
>     I hope we can provide better info eventually. We have expected to
>     drift
>     200 ns over this time. We have multilpe ways to measure this.
>     Unfortunatly we lost the calibration before, to characterize the
>     rate of
>     the clock as sea level, so we will do that afterwords.
>
>     The challenge of being part of a Belgic mission is that they force
>     you
>     to drink Belgic beer, if only I like that... (having a good time,
>     as I
>     really enjoy Belgic beers).
>
>     As for mistakes today... none. We have had a day of fooling around,
>     taking photos, preparing and doing interviews. In addition we show
>     the
>     setup for the turists, which is a nice moment in any day. We love
>     teaching.
>
>     Cheers,
>     Magnus
>
>     On 2023-07-18 12:19, James Littlefield wrote:
>     > Magnus,
>     >
>     > Being a long time reader of the time nuts list, I am very much
>     > enjoying your posts regarding this experiment. The issues with
>     > cabling, power, and software are fascinating to follow along. I look
>     > forward to your future updates.
>     >
>     > Best regards,
>     >
>     > On Tue, Jul 18, 2023 at 1: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
>