Measure the size of the beam

[hcrowl]

We are told that the beam of this telescope is ~6 degrees. That is consistent with what we would expect from the simple diffraction-limited resolution equation: resolution = 1.22 * wavelength/diameter

We should actually measure the size of the beam. Some basic details here: http://www.ras.ucalgary.ca/radiotel/calibration.html

[theDarkLard]

It is also one of the MIT srt student labs: http://www.haystack.mit.edu/edu/undergrad/srt/SRT%20Projects/

[theDarkLard]

wrote a command file to carry out the test, seeing if it works now

[theDarkLard]

Well srtn crashed before the procedure finished...but it worked up to that point! And the rotor limits definitely work! It also made a cool little intensity map of the sun.

[edaniszewski]

pix or it didn't happen

[edaniszewski]

also, from your wiki post

even if you assign a filename to the output file, like ": record myfile.rad," the data doesn’t actually get put into myfile.rad. It instead gets put into a generically named output file. myfile.rad gets created, but nothing gets put in it. Working on why this is happening.

I think that's hilarious. I'm laughing on the inside.

[theDarkLard]

srtn is laughing at me too :(

[edaniszewski]

for that particular thing, after looking at it quickly (my break is almost over :cry: ), it could be that in cmdfl.c, around line 140:

             if (strstr(str, "record")) {
                    d1.record = 1;
                    if (sscanf(str, "%*s %*s %255s", d1.filname) == 1)
                        d1.foutstatus = 1;

the sscanf(...) isnt successful, thus giving a return code of 0, so it doesn't enter the if conditional. If d1.foutstatus is not set to 1, in outfile.c, the file name is set to a YYYYDDhh format.

Though, thinking about it, since the named file is being created, it seems like it is more of an error on how files are being written out in outfile.c. There is some weird if-clause nesting and flag setting going on in there, so its a distinct possibility.

[theDarkLard]

Alright so. Been running the beamsize test for two hours. SRTN keeps freezing when the telescope reaches the sun during the elevation scan. Gonna reset the limits in SRTN/hard limits so the rotor goes past 90 degrees and keep on trying. If it doesn't work in the next 3-4 tries, it's back to the drawing board.

[theDarkLard]

I could do it manually but I really want this command file thing to work. Manual beamsize test is plan b.

[theDarkLard]

Crashed three times again. Doing it manually.

[theDarkLard]

shorter el scan finished its run.

[theDarkLard]

no crashing!

[theDarkLard]

will resume tomorrow with slowly bumping up limits to see how many degrees of offset induces a crash.

[theDarkLard]

So it seems that srtn starts crashing at offsets greater than 20 degrees. Both 25 degrees and 22 degrees caused crashes but 20 remains stable. Going to do a manual test as well to have the full 30 degree offset range, then get down to plotting and calculating beamsize.

[theDarkLard]

Now that I think about it, maybe a manual test isn't such a good idea because I hhave no way of tracking the sun. Will see how feasible the results from the 20 degree offset scan are.

[theDarkLard]

Evan is a doofus alert ~ So i forgot to write a stop record command in the command file so I was doing another run through but now srtn is crashing at offsets of 20 degrees. Trying again, will move back down to 15 if necessary and maybe then back up.

[edaniszewski]

When it crashes, is there a stack trace or error message that shows up in the command line (assuming it is still being run via command line)?

[theDarkLard]

Both 20 and 15 crashed. Turning everything off and then back on because that's what always fixes everything.

[theDarkLard]

Well my plan for fixing everything broke everything instead. Srtn can't even get through the first azel command. I will persevere.

[theDarkLard]

@edanisweski no, nada. Everything just stops and then once you force quit it it just says "Killed"

[hcrowl]

Can we (and by "we," I mean "you," @theDarkLard) dig into why we think this is failing? Is this some incompatibility with srtn running on our (somewhat) non-standard system? A general issue with srtn? A problem of it not handling errors gracefully? Something else?

[theDarkLard]

Oh my god it finished a scan! @hcrowl I'll do my best but I'm not promising anything. I have a feeling this is an endeavour that involves me fruitlessly reading through code that I don't understand, looking for "something" while I don't really know what that "something" even is. Still, I must seek out the portal that leads out of this pergatory of computer ignorance. Will let you know what I find.

[edaniszewski]

@theDarkLard If there are some bits of code that you can't figure out, drop me a line and I can try to explain. Past that, I don't think I can be much use here, being remote and all.

If all else fails, pray to Yaesu for guidance.

[theDarkLard]

Thanks @edaniszewski, you're a god-send. I've gotten sidetracked trying to come up with a way to process the data from the successful run, but once I start digging around you'll most likely be hearing from me.

[theDarkLard]

*Yaesu-send

[theDarkLard]

I've been trying to make sense of this output file...calculated avg Tant for each spectra then analyzed the time and position each spectrum was taken, but as I was attempting to make a plot, none of it added up, so I think what's wrong with it is that it is the results of that scan (the one that makes the cool color intensity map of the sun) that srtn was doing even though i wouldnt tell it to. I've been trying to make another pass at getting a good output file with 20 degree offsets but the crashes are relentless. Additionally, when I do 15 degree offsets, it does that scan again and screws up the output file.

[theDarkLard]

Any scan I try to do with any amount of sort-of workable magnitudes of offsets crashes. Seems to be getting worse and worse. Praying to Yaesu for guidance. Will dig into the code as a last ditch effort to see if anything pops out at me.

[edaniszewski]

hmmm. are we using any hardware that wasnt in the MIT specs? I find it weird that it keeps crashing and not performing as it should, when it (presumably) is working for others who use it.

we did make some modifications to the software to get it to work on Ubuntu, but IIRC they were just changing some array/buffer sizes -- nothing that I would expect to create havoc and pandemonium..

[theDarkLard]

Yeah all our hardware is the same. Hugh recalled the changes to the software but I think we also brushed it off as too insignificant to be causing such a problem (or maybe it was in terms of the weirdness of the calibraiton procedure?). I didn't really see anything that popped out at me as weird when I was looking through it yesterday but ill give it another shot.

[edaniszewski]

Yeah.. I read through all the github commit changelogs last night and even did some minor comparisons with a clean version of srtn v3 from the MIT site, and it looks like the only code changes were either formatting, organizing, removing dead code, or adding comments.

I know we were having trouble with getting the right version of gcc and gtk.. I don't remember if we ended up getting the exact version as needed, or if we got the closest version we could find. It seems somewhat unlikely, but it might be crashing because of some weird version difference either in the gtk library or a difference in how things are compiled between various versions of gcc.

I don't think that's the issue, but I'm throwing it out there as a possibility..

[edaniszewski]

I don't know if you are following any of the MIT docs/which of the docs you may be looking at to guide the calibration process, and other processes. I took a look at 2 of the docs on the MIT site though, and it seemed like they were describing the old java version. Could be that the procedures described there are different than they would be for the C versions.

[theDarkLard]

I am indeed following the MIT docs, but I have found that the commands all nearly work the same, the only major difference I've noticed is that a source command like "galactic 10 0" doesn't work, but that's pretty minor and there are ways to get around. The offset commands work as intended in both versions as far as I can tell, srtn just keeps on freaking out during the elevation scan.

Additionally, it took me all this time to figure out a solution to the problem of the spectra in the output file being separated by huge swaths of space and time -- just tell the telescope to stick around an offset point for 10 seconds. This has shaved the difference in position of each spectra down to 2-3 degrees.

[theDarkLard]

Also @edaniszewski if you know of any good libraries/python methods off the top of your head -- plz don't do any unecessary research -- for data extraction, give me a holler. But really only if its off the top of your head, I'm going to look into it myself once I trawl through this new output file a little bit.

[edaniszewski]

Depends what you mean by data extraction. If you mean extracting the data from the output files generated from the software, you'd be fine using the Python standard library to write something which would open the file, parse out what you want, then save the data to CSV format or something (could use the csv library for that)

if you want to do data analysis/manipulation, the popular tools are pandas, numpy, scipy. I think they all incorporate functionality to the matplotlib library too, for plotting the data.

[edaniszewski]

also, @theDarkLard , if you do write a parser for the output files, you could probably check it in to the repo, since that seems like a useful bit of code to have with this.

[theDarkLard]

Cool, thanks for the tips, will certainly drop it into the repo If i am successful!

[theDarkLard]

Spent a lot of time today trying to figure out #120 , got very confused and lost, decided to go manual for a bit to make myself feel better, made a plot. It looks nice! Haven't figured out how to save it to an image so I can't post it here but it's something. I kind of also want to throw this data into logger pro since they have those nice line fitting capabilities and use that to calculate beamwidth.

[theDarkLard]

Plots! So as you can see the az scan pot peaks at about +7 degrees, so the feed must be off center a bit. I'm going to futz around with it a bit and do another scan to see if I fixed it, then redo the el scan as well.

[hcrowl]

Nice plot. Agreed that this makes it look like the feed is not precisely aligned.

[edaniszewski]

this is so cool :+1: :us:

[theDarkLard]

Been working on aligning the feed...it's better, about 4 degrees off center now. Tried to get another El scan in but it kept crashing :(. I've gotta run now but I'm taking the output files with me (including the rotation curve one) to make something of them over the weekend. Even thogh the feed is still off center, the entire beam was dragged through the sun so we should be able to get some sort of idea of the beamwidth.

[theDarkLard]

So I finally got the beam aligned..however, the strongest signal comes in at 0 degrees offset only when the feed is NOTICEABLY schewed from the center. And when the feed is in fact centered, there's about a 5 degreed offset from where the peak should be. So I think the issue is that the telescope doesn't have a totally accurate picture of where the Sun is, and thus where anything is. @hcrowl, do you think that nudging the lat/lon values in srt.cat would be a suitable fix? There's no srt.cat keyword for offset so that's how to fix it in the software. Otherwise, I could reset the rotor to be about 5 degrees past astronomical north.

I'm going to go the software route first because it's easier to jimmy around. Will report results.

[theDarkLard]

Now that I think about it, I'm not sure that changing the lat/lon settings is gonna do it...I think it will throw the whole telescope off instead, and I think resetting the rotor will have a smiliar effect, so I'm going to leave those ideas alone for now. Instead, I'm going to account for the pointing weirdness in the command file, i.e. push all the offsets forward by 5 degrees.

[theDarkLard]

Max power is at offset 3 degrees with correct alignment.

[edaniszewski]

not sure if this would matter at all, but I noticed something odd in the time.c file on line 25

secs = (2011 - 1970) * 31536000.0 + 17.0 * 3600.0 + 15.0 * 60.0 + 58.0778;

It seems like its getting the number of years since 1970, but its doing it from 2011, not 2015. I dont think this would be enough to make that much of a degree offset difference, but I'm no doctor. Perhaps changing the 2011 to 2015 could do something? Or maybe it would just break it more.

You could also check out the Lat/Long defined under the LOCATION keyword in srt.cat. I know I set it to Bennington's lat/long at the beginning of the class, but I don't remember what the accuracy was for it. Perhaps getting a more accurate reading of that may help?

[theDarkLard]

Yeah I set it at the beginning of the summer to Btown's location, so that should be accurate. I'll try the 2015 thing now.

[theDarkLard]

Well I'll be darned. Seems to have done the trick. Huzzah! Yaesu bless you @edaniszewski!

[theDarkLard]

Revised plots

[edaniszewski]

This is awesome. I'm so happy I was able to figure something out and help.

Funny thing is that even in the new version on the MIT Haystack site (v4), they still have the time calculation as (2011 - 1970).

[theDarkLard]

Once you have the plots it turn out calculating beamwidth is super easy. Our plots are very obviously a Gaussian curve so you can find the full width at half maximum (FWHM) to find the beamwidth in degrees, since the x axis is already plotted in degrees. To get the FWHM, pick out your maximum y-value (maximum Tant) and half it. Then find at what number of offset degrees the plot passes through the half max value. Subtract the smaller x value from the larger x value to get FWHM, which for us translates to beamwidth. For the az scan, I got a beamwidth of 16.59 degrees (which is really really big..??) from half max value of (1247/2) which gave offset degree values of 9.32466 and -7.26543. For the el scan, I got a beamwidth of 6.63 degree from a half max value of (1221/2) which gave offset degree values of 3.9 and -2.726. So the curious thing is why is our beam so wide in the azimuthal plan, or x-plane of the feed. The y-plane width seems to be in the ballpark of the MIT scope but our x-plane width is huge comparatively. I'm not quite sure how to interpret this, @hcrowl do you have any ideas?