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

Tue Jul 25 13:24:35 UTC 2023

Tom,

On 2023-07-24 19:47, Tom Van Baak via time-nuts wrote:
> Magnus,
>
> I'm glad you got to experience the challenge of powering cesium clocks 
> on a road trip! Fun, yes?
Yes, an interesting challenge and the main focus.
> Here's what I used:
>
> AC system -- I tapped off the car's battery with dual 100 A fuses and 
> thick wire to feed in parallel two 80 Ah batteries below the passenger 
> seat. That gave redundant, low impedance, 12 VDC for two sinewave 
> inverters, one per battery, to supply 120 VAC to two power strips, the 
> A-bus(AC) and B-bus(AC). All AC feeds used standard IEC cords, no 
> custom wiring was necessary.

I had two AC busses two, one generated of the cars power and one 
generated of the battery 24V bus. It should have been on the load bus, 
but I did not have time to do that as I bought that one at a gas station 
in France and inserted into the system as parked there. Having a spare 
banana-jack to PowerPole cable came to rescure. However, there was no 
banana holes in the terminals, even if they looked just like that, but 
putting the bananacontacts on the side and screw down was the field 
engineering that turned out robust enough for the rest of the mission. 
No special cables was done on 230 VAC.

>
> DC system -- I removed both rear seats and bolted into place a frame 
> for eight 120 Ah VRLA batteries arranged in series and diode-or 
> parallel to create two redundant independent sources of 24 VDC, the 
> A-bus(DC) and B-bus(DC). All DC feeds were done with Anderson 
> PowerPole [1] connectors and accessories.

My DC system was a Anderson PowerPole connector heaven, this includes 
Solar panels. The upside being that an cable can act as extender at any 
point in the DC system. Quick to connect and disconnect in the field.

I could use batteries directly on the clock to handle swich of AC output 
while moving for instance.

>
> 5071A system -- Each clock had internal 24V battery packs re-made from 
> fresh EnerSys Cyclon 2.5 Ah cells. Each clock was powered by 120 VAC 
> from an AC bus, and also powered by 24 VDC from a DC bus. Note that 
> the internal backup battery inside a 5071A is slowly charged only when 
> AC is present.

I had no time to replace the internal battery. I would have loved to 
have that additional safety. One of the most critical issues was lack of 
time, as I got involved with only 3 weeks to do it, and working daytime 
job most of that time.

Having the internal battery fixed would have saved several "oups". That 
is part of the learning, which I could easily forsee and knew, but time 
was not allowing for finding a fix. I tried to replace the PHM batteries 
for exactly this reason, but did not find a match locally. So root cause 
ends up lacking time to prepare.

>
> Attached are two screen shots, from page 56 and 57 from [2], that show 
> some of the setup.
>
> I carried long AC extension cords so that when "shore power" was 
> available at any point during the experiment I could power any AC bus 
> from that source and/or recharge the main 8x VRLA batteries using 
> marine battery chargers that I brought along.
>
I had two long cables two, and that helped both with "land power" 
overnight as well as when transfering clock between cars and transfering 
clock to and from laboratory (mine, Saint Veran and Royaal Observatory 
of Belgium).
> As you found out, the logistics of failure-proof clock power is quite 
> a bit more complicated than any of the 10 MHz and 1PPS timing stuff!

I knew that was the challenge, from start, so that is what I focused on. 
I honestly did not care too much about all the measuring stuff, but 
tried to add as much as I could while building power.

A particular care was to build the system so I avoided low charge on the 
batteries.

>
> I'm impressed with your use of solar panels. I wish I could do that, 
> but solar doesn't often work well in the Pacific Northwest, and my 
> power requirements are higher due to multiple clocks and related 
> electronics. But my car is a Toyota Highlander Hybrid which acts as an 
> efficient generator if non-battery power is required. It's not quite 
> as "green" as solar, but it works in all weather.

The solar panels ended up overproducing power, and thus loading 
batteries for most of the day-time. I had a 55 W load as measured, 
somewhat more I guess because of bush-rewiring. The 200 W rate is a bit 
theoretical as it is several "It depends". Since they where not flat, 
you loose some. For Stockholm, a graph showed I would only have 82% from 
angle error. So, 160 W. Many times I was reading 80-140 W. I peaked at 
189 W as I recall. Some clouds reduced power, but during the drives it 
was mostly well. It was only on the way home yesterday that I had heavy 
rains, but then the cesium was off the system and I was down to 14 W load.

While I could have deployed multiple SR620 TI-counters, I chose to use 
two TADR TICCs instead. This has huge impact on the power budget. First, 
the SR620 runs hot and has a fan because it is needed. The ECL age shows 
it's choice of balance. The SR620 would have to be run on 230 VAC, so 
that would mean additional loss in the 24V/230V system. Double 
conversion should be avoided, but I did not have time to do that, but I 
optimized so that the major load, the cesium, was on DC power as primary 
source while running batteries, this removes it's losses in the AC to DC 
conversion. I used the cesiums AC as auxillary source for it for 
redundancy. That did not play out exactly as planned, as I think it used 
the AC path at times, but I ended not being so low on power that it 
cared in the end. Anyway, an SR620 would need either a GPIB or RS232 
dongle in addition. While that does not add much power, compared to use 
a TADR TICC. I had my DPM7885 pressure sensor and two TADR TICC and it's 
24V/12V DC supply consuming just about 6 W of power in total. Using the 
TADR TICC in time-stamping mode, I have 2-4 channels depending on how 
you want to measure. The USB of the TADR TICC shows up as /dev/ttyACM0 
and /dev/ttyACM1 in the Raspberry Pi, and thanks to a few lines of 
python was feeding into the InfluxDB. I used a USB hub with external 
power to feed those devices, which includes RS232 adaptors. I aim to 
describe the measurement stuff in a separate thread.

In general, I tried to avoid unnecessary power conversions. For 
instance, providing power and charging the batteries from the car I had 
intended to use a 12V to 24V DC/DC converter. I had a separare cable for 
an outlet in the boot that was on a 15 A fuse. That cable was very easy 
to access (open a little panel (no tools required) that I had not 
noticed before, and the cable just fell out. Connecting to the cable 
seemed straight-forward, so a small adaptor over to Anderson PowerPole 
could have been built quickly. However, I ended up not having the time 
to buy a suitable DC/DC. Instead, I had to use the 12VDC to 230 VAC 125 
W converter that I bought lighly used at a ham-meet, naturally from a 
friend of my radio-club. I also got the 24V to 12V converter at the same 
time, since I expected that to come in handy for the home lab. This 
DC/AC was critical at many times, but provided an issue since you had 
the double conversion issue, and also since the second converter was not 
aware of the limitations of the first, as I have already described. This 
shows that the double conversion strategy feeding into the system should 
be avoided. Double conversion is however not always wrong. When feeding 
from house AC, the conversion into the 24V busses and then have one 
conversion from the 24V bus to whatever is good strategy since you avoid 
breaking power. It is the double conversion from the 24V bus that needs 
to be avoided, since that is unnecessarily draining the batteries when 
depending on those.

So, the double conversions from battery done where:

PolaRx4TR - forgot the DC cable and we had not had time to adapt power, 
it went on the produced 230 VAC bus with it's AC-adaptor.

Raspberry Pi - it's DC/DC converter seemed to be overloaded constantly, 
so I pulled out a AC/DC converter and used that and removed the DC/DC 
converter.

5071A - at times.

The Raspberry Pi had power issues in the beginning, and it did not start 
clean every time. I had to do quite a bit of clean-up on that, but I was 
not able to finalize. I decided to rip out the DC/DC (cut away!) and use 
the AC/DC. Not ideal, but not the largest power loss. The RPi went 
stable power-wise from that. I did have other issues.

While not everyone will need to have a portable and moveable lab, some 
of the lessons is relevant even for a static lab. In fact, this forced 
me to do many of the things going into my static lab.

While many things could have been done better before and during this 
mission, I think sharing the system thoughs and experience in the field 
(context, I've now driven 4900 km with this setup, or 15 degrees south 
and 11 degrees north (at summerhouse, has another 4 degrees north to 
drive) will be interesting and food for thought, even for those building 
a smaller system for static operation in their labs.

I remain unsatisfied with preparations, but many of the necessary things 
worked and provided needed dynamic in the field to handle the 
encountered challenges, so I am quite satisfied that many of the system 
thoughs and moves worked as intended. The failures and near failures 
stands as learning experiences for the future, and I think the best way 
is to share the experience of both good and bad, to learn how to 
progress. I am already thinking about the many improvements I would like 
to do for a future next event. More clocks, better power management, 
better physical and electrical build etc. The use of the PV panels 
turned out very well. The mount for panels and choke ring antenna turned 
out to work very well, even if I consider the build being a hack, and 
not even my best mechanical build.

Cheers,
Magnus

>
> /tvb
>
> [1] http://leapsecond.com/pages/powerpole/diode-or.htm
>
> [2] 
> http://leapsecond.com/ptti2020/2020-PTTI-tvb-Atomic-Timekeeping-Hobby.pdf
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com