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@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 > >

Happy to host pictures and any of your related blog posts on the NTF website, I don't care if it's on the main site or on a separate projects page. H On 7/18/2023 9:18 AM, Magnus Danielson via time-nuts 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@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 -- Harlan Stenn <stenn@ntp.org>, part of http://networktimefoundation.org - be a member!