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

[Magnus Danielson]

Dear Jim,

On 2023-08-04 18:27, Lux, Jim via time-nuts wrote:
> On 8/3/23 6:55 AM, Magnus Danielson via time-nuts wrote:
>> Dear all,
>>
>> I have written multiple times about the mission, but I thought I 
>> share a separate view this time, and I think it may be equally 
>> interesting. This time I would like to bring up the topic of logging. 
>> You can see traces in various posts from before, but maybe I can 
>> contribute a somewhat more comprehensive picture. 
>
> <snip>
>
> This is great stuff, Magnus.  It's all these little practical details 
> that help some one planning a similar activity know what kinds of 
> stuff happens - it won't be the same, of course, but it's the kind of 
> thing you encounter.
Thanks!
>
> And why we used to have this cynical phrase "all you gotta do is..."
>
> Someone would have a block diagram on the white board or a power point 
> slide - it looks simple in concept, but the practicalities take a lot 
> of time and effort.
>
I think this is where is becomes much more relevant for many, to see the 
hurdles and to learn from them. My motto is that the real failure is not 
to learn from the failure. I think all these big and small problems is 
the interesting stuff, but it also display how things actually work. 
Most importantly, don't do this with two weeks of preparation. Build 
things such that it keeps working, autostart with as much autonomy, 
protection switch etc. so that you with that as your base can do the 
dance and transfer things over.

This afternoon I transfered the remaining system (the 5071A used is in 
Brussles) over from the car and into the lab. While it does not care as 
much, I have maintained the experiment runing as if there was a clock 
still there, and thus moved batteries and measurement case over and is 
still continuous operation. I do have problem with the RPi, and I think 
this is a re-currence of an old problem, and I want to track that 
problem down to finally fix that.

The block schematics for this I drawed into my notebook as I was sitting 
at Observatoir de Saint Véran. One page for the power setup, and another 
page for the scientic interconnection. The later is about 2/3 of the 
first. Power and various interconnection of cables is what brings things 
down in real life. Like having the exact right USB-cables, the needed 
DB9 null-modem cables or the right N, TNC, BNC, SMA adapter(s). The 
constant need to be inventive to solve things and having prepared for it 
is the real challenge.

So, will I do this again? Who knows. Will I be better prepared? Sure. 
Much better prepared. I also know what things needs to make this stuff 
up and it will be much better tested in advance.

Much of the things is the same as needed for a fixed laboratory, so that 
is what I will build now.

> One thing that one seems to always have to create your own tools for 
> is combining time series of measurement, where the clock are not the 
> same. InfluxdB does time serieses (or, I suppose, it has a native time 
> type and is theoretically optimized for such things), but it doesn't 
> do resynchronization or time correlation. That's still on the user.

InfluxDB is not a tool for processing time-series, it's just a tool to 
record them and retrieve them from. It does that job much better than 
having to mess with SQL databases directly. I've done one tool to 
extract the TICC time-series, but eventually it should be generalized so 
that I can do correlations etc. Now, much of the needed toolbox exists 
in Python so it is more a matter of making the pieces fit. Luckily, 
these are things that can be done in post-processing.

Cheers,
Magnus