The following versions of the SPARO data acquisition program, that runs
on the Macintosh computer called 'gnu', have been developed:
Ver. 160 - nov. 11, 1999 - network crashes fixed, UV rots fixed
Ver. 161 - nov. 13, 1999 - aborts gracefully, other fixes
Ver. 162-164 - approx. Nov. 17, 1999 - hwp moves on command,
scheme for synchronizing hwp on wakeup, using encoder,
other changes
Ver. 165 - nov. 26, 1999 - has chg. Directory command, other changes.
Not tested in Nov/Dec 99
Ver. 180 - may 7, 2000 - lets another machine communicate with the indexer
Ver. 180a - may 8, 2000 - same as above, but writes hwp angle in different place
Ver. 181 - june 12, 2000 - newdir bug fixed
The following E-mail messages give some of the details of these versions:
Date: Sun, 07 May 2000 10:42:21 +1200 (NZST)
From: Greg Griffin
To: Bob Loewenstein
Subject: cool idea?
Bob,
After debugging some serial-port details this morning, I came up with what
might actually be a cool idea.
This is sweet. If it works, that is:
- YOU don't have to change your code at all
- we can take real polarimetry files with gopol just like normal
- we can servo the hwp every time
However, I still need your advice on whether the plan will work.
Here's the idea. bbrown (our new indexer client) can move the hwp just
fine using serial port#1 (confirmed that yesterday). It can also talk with
the mac via a null modem cable using serial port#2 (confirmed that this
morning).
You may already see where this is going. Let's keep the mac in the hwp
driver's seat. What the mac won't know is: it isn't talking to the indexer
anymore, it's talking to bbrown, which is servoing the hwp on a different
port and then PRETENDING to be the indexer.
This would be pretty straightforward from a communications point of view,
but it does require that the mac WAITS for a response from the indexer
each time it sends a command, instead of just blasting serial commands out
into the ether. Presumably this is how it already behaves, but I haven't
checked yet. Do you know off the top of your head?
Thanks,
-Greg
Date: Sun, 07 May 2000 21:55:21 -0500
From: rfl
Subject: new code
Greg,
Here's the new code. This code can do photometry and polarimetry.
Photometry as in the past.
Polarimetry assumes the following:
Sparo program does NOT talk to HWP during nods, your program will.
Sparo will send " Move the HWP" after the last L of a LRRL.
Sparo will wait until you send "Continue hwpangle=xx.x"
You can have only one LRRL pair per HWP angle.
You need to make sure NINTS=6 prior to beginning the file.
One file will be written for the 6 lrrl, as usual.
Command for polarimetry is still gopol and command for
photometry is still gophot.
DAVE:
The encoder value of the hwp will be in the 3rd uvrot position
(one prior to the mac hwp positions)
Sparo will not keep track of the hwp positions, so the 4th
position will be zero.
Program type (category) is still 1 for polarimetry and 0 for
photometry. Version number has not changed.. I can change it
if you want me to.
I think this covers everything. I tried this program at home and
it seems to work. What I did not check, not having a good data
generator, was the validity of the data. It should not have
changed, but that doesn't mean it hasn't. Dave, If this program
works, I'd check a file and its statistics. I don't know if you
anything to calibrate on, though. (moon is down for a while)
Let me know if this works.
Bob
Date: Tue, 09 May 2000 03:04:42 +1200 (NZST)
From: Greg Griffin
Subject: daily report (Monday 5/9)
Dailies,
Closed the heat switch this morning then wrote up an indexer device.
Matt's net.tcl routines make this pretty easy. Added a few odds and ends,
like polling the indexer until the move is complete. You now can say
tell $s indexer "init" #to initialize
tell $s indexer "move -30" #to move -30 degrees
Here are the results of a brief test of the new device, with servoing:
0.06 30.03 59.83 90.16 120.19 150.04
...
-0.14 30.10 60.04 90.16 120.33 150.15
The values are not perfect, because the indexer still has problems making
small moves (probably some stickiness somewhere along the shaft).
Meanwhile, started a new tilt measurement on rcw57.tcl. Just got Bob's new
sparo.com180 and will test that in the deadzone (in about 1 1/2 hours).
Will send the resulting data file to Dave asap.
-Greg
Date: Mon, 8 May 2000 21:07:28 -0500 (CDT)
From: Bob Loewenstein
To: chuss@belmont.astro.nwu.edu, greg@cmu.edu
Subject: Re: sparo.com180 test
Greg,
I've placed a newer version sparo.com180a.sea onto pharlap.
Use fetch.
The only major difference is that the hwp angle that you send me is
now stored in the place where Dave's code expects it (4th word
in the uvrot record).
This program now expects you to zero the hwp before the start of
a dataset.
Photometry and Polarimetry should work. Keep fingers crossed.
Bob
Date: Mon, 12 Jun 2000 12:12:53 -0500
From: rfl
To: Greg Griffin
Subject: Re: data system, newdir problem
Greg,
I've placed a new version sparo.com181.sea.bin onto
astro.uchicago.edu/pub/MAC/
Use anonymous ftp into astro, and use fetch from the mac
to download the sea file.
Dave can explain that we never got the revised control computer
to successfully talk to my mac (we've never had a problem communicating
in the past). In looking at my code, I found a 'possible' way for
such garbage as you describe from corrupting the dir name. In testing,
however, I was never able to see the problem you described. My
testing without the control computer simply created a new directory
by throwing the command 'sparo set newdir="mycomputer:data#"' into the
tcp/ip buffer. #
increment from 0 to 100. I wrote 10 files into each of the 100 folders
and never saw a problem. Because the commands that I created were placed into
the input buffer that the tcp/ip connection uses, the code executes
identically as if the command came from the network rather than my
internal script. That's the theory, at least.
The text McSink and and KeyCaps are desk accessory programs on the mac.
Somehow they get into the garbage that you've seen.
In any event....
I modified the code to eliminate the 'possibility' I found for corruption.
So try the new code and let me know how it works. I'll be out of
touch for the next 40 hours or so.
Good luck.
Bob
Date: Wed, 14 Jun 2000 16:05:30 +1200 (NZST)
From: Greg Griffin
To: daily SPARO reports
Subject: daily report (Tuesday 6/13)
Dailies,
Today,
- tested newdir: the problem seem to be fixed. Thanks, Bob!
- ngc6334 amplitude was about 42 at a tau of 1.2 (that's the raw
array data, not the map). Whereas you would expect 67 or
higher for well-phased data, according to Dave's calculations.
- this led to some phase checks on ngc6334, which I don't quite
have the results for yet
-Greg