Hi Mark,
From my notes @ 26-Oct-2017 telecon, I think the MOBY264 BS track selection was
2=Es,
5=EdT,
6=LuT,
8=EdM,
9=LuM,
12=EdB,
13=LuB

...to avoid using the CCD-edge tracks #1, 14,
...note: M264 will not have Ed collectors.
Does this seem correct to you Stephanie?

I'll do some digging in the morning to answer the attenuation question.
MF

On 01-Dec-2017 04:39, Mark Yarbrough wrote:

Hi Mike,
id like to work on assembling BSG4 Saturday.  Do we know the track assignments and attenuation amounts needed for this unit?
Mark

Below is my recollection of the track numbers.  With the exception that LuBot would be track 13 not 14.  See Kens discussion below.   The change is because the Ed are impacting fairly largely the LuTop Red data with cross track light.  And if we don't used Ed and Lu at the same time then this would eliminate the cross track.  And removed the problems caused by the track at the edge of the array when the tracks move.

Hi Steph, Hi Mark,
Here are my additional notes to Steph's summary below:

MOBY262 had BS01cfg007.  This BS had iris added, but no Neutral Density (ND) filters.

MOBY263 had BS03cfg003.
BS03 had 7 collectors: Es=port/trk#1, EdT=3, EdM=5, EdB=7, LuT=9, LuM=11, LuB=13

BS03 had iris added at all 7x ports.
Es/port#1 also had added filters = ND1 + ND0.5.
Ed/port#3,5,7 also had added filter = ND1.
Lu/port#9,11,13 had no ND filter added.

ND1 = Thorlabs NDUV510B, OD=1.0.  ND0.5 = Thorlabs NDUV505B, OD=0.5.

Es/port#1 iris was not adjusted = left wide open.  Vs trk#14 ref was 112x down.
Ed/port#3,5,7 iris were adjusted, target = 100x dn.  Vs trk#14 ref were ~82x dn.
Lu/port#9,11,13 iris were adjusted target = 10x dn.  Vs trk#14 ref were ~10x dn.

From Steph's plot below via MOBY263/BS03, the Es signal is too low by ~2.5x (1.5 ADU*2.5=3.75 ADU).
If the 0.5ND filter gives a 32% transmission (T=10^-OD),
then not using the additional 0.5ND filter would give a signal increase ~3x (right?).
So, maybe we do not need the extra 0.5 ND filter on Es for MOBY264 (?).
MF

R.E. pre-M264 BS04 cfg & cals in Dec-2017:

Darryl was correct in his remembery, w.r.t what he described on the tele this avo, in that...

I did pre-deployment cals on the BS04 in the tent Friday night, 15-Dec-2017 HST == 16-Dec GMT = "Day08",
via what I called the BS04cfg004 with the FO-block and window-block attached to the shutter-block -
but with camera control via USB + SOLIS software and camera power via Andor pwr sup PS25,
i.e. the BS had not yet been housed with the Linux ctrlr & M.Yarbrough pwr sup & cooling etc.

Then, on Saturday, Mark & Art did BS & OM testing in the tent -
where the BS was not yet housed but all the pieces were in-place,
including the Linux ctrl + MY pwr + cooling system + electrical-connector-endcap.

Then, on Sunday the BS was housed with the Linux ctrl + MY pwr + cooling system -
which required removal of the FO-block.  I think this may have been where the BS
was carted from the tent back to rm.124 for Mark to bolt together the optics with
the ctrlr+pwr+cooling (?) as Darryl did recall - I was not in for this, but I do recall
the PVC housing being installed on the assembled BS in the tent on Sunday.

Then, on Sunday the housed BS was installed in MOBY, and the FO-block was re-attached.

So, there was indeed the dis-connection & re-connection of the FO-block between
the pre-cals and the deployment.  Which I will try to duly document somewheres...
And, therefore I think that the deployed BS should be called BS04cfg005.

This all reminds I that I probably have not completed my upload to the NAS
of pre-M264 photographic evidence of this process - which I hope to remedy...

Over

Steph  

I turned on BSG acquisitions today.  
The order is:  
! NDk1 NLt NDk2  Tracks(re:0)    ! comment
   3    5   3            8 10 12 ! Lu
   3    5   3    0 2 4 6 8 10 12 ! All

That means, for each shutter configuration:  
3 dark (ext shutters closed, internal open)  
3 background (ext open, internal closed)  
5 light  
3 background (ext open, internal closed)  
3 dark (ext shutters closed, internal open)    

Thus a complete series will have 17 images with just Lu  and then 16 images with all the tracks.    

I am doing a run now at 22Z as a test, but in general  you should get one at 23Z. (hopefully 2 sets today).    

They are taking 30 sec each image today so maybe  it’s cloudy? Sun should be higher now (22Z).    

I can do the 100 image set one of these days but if it takes 30 sec/image and we throw in some darks it will be over 1 hr.  We need to figure out a  good day to do that.    

Art  
----  
Art Gleason

Art  
  
I just checked the GOES images and it looks very clear and 22 hour is   the highest zenith angles.  So I'm wondering if our iris and filter   reductions are bigger than M263.   By the numbers Mike took the Lu   reduction is more than M263 and the Es reduction is less.  I guess we   will have to wait until we see the data.  
  
For the 100 day stuff, if the int times are really 30 seconds then maybe   we don't need 100 files but less will do?  Maybe let me know a few days   that might work for you to try the 100 file test and I can check for   clear days and let you know when it looks like it will be clear?  
  
PS: I thought we where not putting Ed collectors on M264 so there is no need for the Ed tracks to be on??  Mark or Mike is this right or wrong?  
  
Steph  

----------------------------------------------------------
Mike

Correct: there are no BS Ed sensors on M264 - only 3x Lu + 1x Es.

Mike

@ I second read of this email...  
The trk cfg for BS04 on M264 is: T02=Es, T06=LuTop, T09=LuMid, T13=LuBot.  
MF  
    

OK well that would make a big difference indeed.  
I made some fixes tonight - tried to run another test set to  see if it worked but after sunset in HI, so we will see if it  fixes it tomorrow.     

Steph - I removed the garbage files from today so if you had  already downloaded them you should delete.    

Art

Yeeeah�� So, small mistake; long story short I told the BSG to run if it were  
turned on in the 23 hour, but moby boots late, at like 2351 or so, so by the  
time the BGG tested whether to run or not it was already the 00 hour�� so no go.    

Just fixed that, so you should see some data today.    

Whoops.    

Art

Hi Steph,    

I turned that one off (only Lu).  I thought that because there were no Ed’s we only needed one set.  
I can turn it back on  no problem - should I do that?    

Art

Hi Steph,    

OK no problem I just set it to:    
! NDk1 NLt NDk2  Tracks(re:0)    ! comment 
   3    5   3      5 8 12        ! Lu M264 
   3    5   3    1 5 8 12        ! EsLu M264    

Also I turned on the OM data stream.  However, I noticed some problems communicating with the OM just now.  
There were numerous but intermittent packet losses on the network:    --- rom ping statistics ---  60 packets transmitted, 2 received, +3 errors, 96% packet loss, time 59447ms      
This is really odd. Normally on a LAN like in MOBY you see either perfect  connections or no connection at all. I have only ever seen partial  
loss (or in this case really partial success) when traversing   wide, congested networks where there was not enough bandwidth to serve  all the 
traffic (not the case within MOBY)..  We did not see this in  the tent, so seems something has changed.  Anyway, it will try to  collect now, at 
the same time MOS is running. We’ll see if any data  comes back or if we just get a bunch of 0 sized files.    

Art

Hi gang,    

Yesterday there was a question about what’s causing the spurious high voltage  readings on the lower batteries on M264.    

I still don’t know the answer but characterized the problem a bit today.  

Here are some observations:    
- Problem is only on B2,3,4. B1 seems to always give reasonable values    

- B2 and B3 are correlated; if B2 reads high B3 reads high and vice-versa.   B4 is not necessarily correlated with either B2 or B3 but sometimes is.    

- Problem is not during charging. A battery that is being charged will  report voltage of 0 (not high value).    

- Problem is not obviously related to just coming off charging. For example  I found cases where B1 was being charged 
and then immediately after that  B2,3,4 read high. I guess I should say not related to charging in a simple way,  
e.g. a battery always reads high just after being charged.    

- Problem does seem to occur only during the battery maintenance cycles,  not when selecting battery to run mos. 
However, it does not occur during  every battery maintenance cycle.    

- Problem is not related to BSG because BSG has hardly been used this  deployment thus far.    

- The last 3 days (1/10, 1/11, so far 1/12) have been good. No anomalies seen.    

Any of this make sense at all?  Not sure what to try next.    

Art  

Yes (We lost two collections  on the 13th?)      
17, 18, 20 Z on the 13th worked fine. Then:  
22Z crashed while trying to get GPS from the NTP server  
23Z crashed while starting the orientation module time series    

In addition, other problems since then (i.e. moving forwards in time):  
03Z (on the 14th) never started  
04Z (on the 14th) crashed while starting the orientation module time series  
17Z (on the 14th) crashed while starting the orientation module time series  
18Z (on the 14th) crashed while starting the orientation module time series  
17Z (on the 15th) crashed while starting the orientation module time series  
18Z (on the 15th) crashed while starting the orientation module time series  
03Z (on the 16th) crashed while starting the orientation module time series    

Other recent problems (moving backwards in time):  
03Z (on the 13th) crashed while starting the orientation module time series  
03Z (on the 11th) crashed while checking the magnetic switch for turning on the WLAN  
04Z (on the 8th) crashed while checking the magnetic switch for turning on the WLAN  
18Z (on the 2nd) crashed while turning the modem on at boot time    

The timing is coincident with running the OM but I am not convinced that  the OM itself is 
the problem (in part because it does crash at other   times as well). I think there is some 
odd coincidence of timing  going on. Still working on debugging this. Will keep you posted.    

Art  
----  
Art Gleason

Ken's reply
We lost another one, should we turn off the orientation module for now until we figure it out?

Art turned the OM off

ok done, let’s see if it changes anything the next few days.  

Art
      

Hi Steph,    

No we have not turned off the 100 image data set (runs at the 20Z session).  
20Z on the 4th did not run. Neither MOS nor BSG.  
There was a problem with the internal communications at that time.     

20 Z files (really from 21:02-21:30 or so) should be 148 files  
22 Z files (really from 22:32-23:10 or so) should be 68 files  
23 Z files (really from 00:16-00:36 or so) should be 34 files    

20Z files are 4 tracks  
22Z files are 4 sets of 1 track each  
23Z files are 2 sets: first with all 4 tracks, then with just 3 tracks    

1/31 20Z is from 20180131_210232.fits to 20180131_212410.fits = 148 files  
1/31 22Z was not enabled for BSG  
1/31 23Z was not enabled for BSG  
  
2/01 20Z is from 20180201_210235.fits to 20180201_212214.fits = 148 files  
2/01 22Z was not enabled for BSG  
2/01 23Z was not enabled for BSG    

2/02 20Z is from 20180202_210228.fits to 20180202_212311.fits = 148 files  
2/02 22Z is from 20180202_223306.fits to 20180202_230938.fits = 54 files  
2/02 23Z is from 20180203_001317.fits to 20180203_002454.fits = 34 files   
 
2/03 20Z is from 20180203_210228.fits to 20180203_211903.fits = 148 files  
2/03 22Z is from 20180203_223253.fits to 20180203_230851.fits = 62 files  
2/03 23Z is from 20180204_001622.fits to 20180204_003650.fits = 34 files    

2/04 20Z failed (both mos and bsg)  
2/04 22Z is from 20180204_223240.fits to 20180204_230848.fits = 40 files  
2/04 23Z is from 20180205_001311.fits to 20180205_002457.fits = 34 files    

The problem with the 22Z sessions is that they are taking too long.  
The MOS finishes and the controller shuts off the buoy before the 22 series  of BSG has finished.  
It seems the integration times for the Lu tracks  are pretty long (30+ seconds) so we just run out of time.  
Could I move one of the single tracks from 22Z to 23Z run? I think there  would be enough time that way.  
Would that mess up the single track  experiment (to have them separated in time by some 30 mins or so)?    

As for the error at 20Z yesterday - very rare but not unprecedented.  
Basically the falcon could not contact the upper power junction board.    

Making sense?   

Art

OK i just switched the last single track acquisition from the 22 Z to the 23Z.
      
Just to summarize, the new sequence (starting with today’s acquisitions) is:     
at 20Z (100 image set)   
3 dark, 3 background, 25 light, 3 background, 3 dark  EsLu   
3 dark, 3 background, 25 light, 3 background, 3 dark  EsLu   
3 dark, 3 background, 25 light, 3 background, 3 dark  EsLu   
3 dark, 3 background, 25 light, 3 background, 3 dark  EsLu     
that = 148 fits files     

at 22Z:   
3 dark, 3 background, 5 light, 3 background, 3 dark track 1 only   
3 dark, 3 background, 5 light, 3 background, 3 dark track 5 only   
3 dark, 3 background, 5 light, 3 background, 3 dark track 8 only     
that = 51 fits files     

at 23Z:   
3 dark, 3 background, 5 light, 3 background, 3 dark track 12 only   
3 dark, 3 background, 5 light, 3 background, 3 dark  EsLu   
3 dark, 3 background, 5 light, 3 background, 3 dark  Lu only     
that = 51 fits files    

All the same order as the last few days, the only difference is the  track 12 only is moved from 
last one at 22Z to first one at 23Z.  Hopefully this reduces the number of files acquired at 22Z 
that we  can get them all.     

Art

Hi Steph,  

Ken told me to turn off the 22Z (single track) acquisition yesterday.  
So you should still see the 21 and 23(00) files starting today but no 22z files.    

Art

Second email at 8:27 AM

Ooops. 

I just realized: we were doing the last single track at the start of  the normal (23/00z) acquisition. 
I just removed those files (the first 17 from  20180301).   Will make sure this is off today.    

Art