-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fivpt reports exactly 100 for Tsys with non-negative Tcal in 9.13.2 for continuous cal #125
Comments
@stuartdweston wrote (from #122): Looking at the code in incom/get_rxgain_files.c I see a commented out line to print the file names, so I uncommented and did a make When starting the FS I now see it reads the correct rxg files : running incom But doesn't explain the Tsys 100 in fivpt, as in the "c.rxg" I have not used -100 (see earlier email and response to issue). |
On May 17, 2021, at 5:07 PM, Stuart Weston <@stuartdweston> wrote: Please find attached the c.rxg file, you will see TCAL is not -100. When I use onoff with any source that line in fivept has Tsys=100 every time. Note : my point about debug levels as in this example it would be nice to see if it's reading the right rxg file ! or which rxg file it is actually using. As there are others for different bands, these still have TCAL -100. I have 4 rxg files, ie : l.rxg : For L-Band, fixed is set to 1130 For this I would expect it to be using "c.rxg" as I am using bands around 6.7 Ghz. |
On May 18, 2021, at 1:34 AM, Eskil Varenius <@varenius> wrote: On 2021-05-17 23:07, Stuart Weston wrote:
I would expect the system to match the LO you set against the LO in the files. Given that you have "fixed" in your files, the LO should/must match exactly (otherwise you need/should use a range in your RXG file). Perhaps (just idea) if the system is not finding any matching RXG file (i.e. LO is set to some value not matching the file) it would assume Tcal -100? |
On May 18, 2021, at 5:41 AM, Stuart Weston <@stuartdweston> wrote: The LO in the RXG file is the one being used : "fixed 5843" If I change things in this file like TCAL then I get a corresponding change on the ONOFF output. Add the LO 5843 to the DBBC BBC Freq settings and they match with the one's listed in the TCAL table. |
@stuartdweston, to make long story short, this looks like it is a bug in 9.13.2 that was fixed in 10.0.0. If so, I forgot it was fixed and will add it to the Changes from FS9 document. I'm sorry about that. It is extremely unlikely it will be fixed in 9.13.x (never more). Some of the longer story follows. I looked at the oriona.log (using the older Tcal value of 90), you sent, sent by email. It looks like that although fivpt is producing incorrect Tsys values, that is not interfering with its primary function. It does look like it is still able to find peaks. So this isn't quite just a cosmetic issue, but of course it isn't right. Also from the log it looks like fivpt is getting a positive Tcal and it is not trying to control the cal. That should mean it is using continuous cal. The timing and values in the Also from the log, it looks like this system is still on 9.13.2, so this isn't a question of something not making it to 10.0.0 properly. Looking at the 9.13.2 code, it does look like there is a bug in continuous cal support that would cause this. That particular bug seems to be fixed in 10.0.0. I think you have said that you remember this working correctly before. Could it be that was for non-continuous cal and/or with 10.0.0? |
Thanks Ed - keep the chatter here. I have my "test" FS with 10 on it. I'll try that shortly
It would have been an earlier version prior to 9.13.2, can't remember which one as it was 2-3 yrs ago. |
I have tried FS 10.0.0 with the same flux.ctl etc copied from our FS 9.13.02 system, controlling the 30m antenna fivept no long produces a tsys of 100 :
405.891 seem's a tad high ... But at least it's not 100. |
onoff I can almost believe :
|
Yay, progress, great stuff! |
@stuartdweston, if you can please attach a short log with a fivpt and onoff run with |
fivpt / onoff on taurusa in C-Band |
Here is one of the new sources I have added to flux.ctl. In C-Band 6.7 GHz it should be 8.478 Jy, the 30m should see this and has in the past.
For some reason today It just can't pick it out. Weather is pritty good, we have a cold southerly no rain and clear blue sky's. |
@stuartdweston, thank you for attaching github_125.log. I looked at the fivpt and onoff data briefly. The raw and reduced data from the fivpt Tsys measurement are:
With a spreadsheet using the Tcal value of (Note that only using the CalOff value in the numerator is a small bug in the code that lowers the reported Tsys level by about one-half the Tcal value, about 5K in this case. This only affects the background level that Tant for the source is measured against. The background level is removed as part of the fitting process for the peak anyway, so the pointing results are unaffected. (Perhaps this bug has some benefit since it makes it less likely that Tant will be negative, which is always a little unpleasant.) It does affect the Tsys derived values of the Looking at the onoff data. The raw and reduced data for the first onsource point for
A spreadsheet calculation of the average and standard deviation (of the sample) agree to the printing precision in the log. I think that validates the basic data collection. The full "high-level" data collected and reduced values for
A spreadsheet calculation gives the same Tsys and SEFD to the printing precision in the log. Whew! It is nice once and awhile to reverify that these calculations are correct (and we found a small bug). Now about the data in the log. It has some interesting features. At the highest level, the fivpt data is similar to what was pasted in a comment above. The Tant values while scanning the source are often strongly negative. This can be an indication the Tsys measurement (which is just used to set the scale for Tant) had strong RFI and/or was picking up another object (the Moon has occasionally been discovered). In those cases, the effect on the background level is mostly a constant (and maybe some scale error). We can see that the level is varying from point-to-point in the scan. It seems more likely that there is time and/or direction dependent interference. Looking at the raw data for the fivpt Also, the raw data are not noise-like on this time scale. In particular, the I may be wrong, but I thought we typically used a a target level of 16000 for DBBC TP measurements. We aren't near that, particularly for the fivpt Tsys data. It looks like the IF target levels are set, but perhaps a bit high (actual 42892 vs target 32000), but I don't see a read-out or setting of the BBC target levels. I suppose it is possible the DBBC is not operating in a good regime, but I thought we did this mostly for resolution. The latter is probably not an issue here. Lastly, looking at the high level onoff data, there is something odd. The off source data on the two sides differ significantly, around, 9000 vs 6000 counts (the raw data appear to agree), a third to half of Tsys depending on how you look at it. The on source values seem to have 10+% variation as well. The Anyway, I don't think this is a fivpt, (or onoff) issue. As a result I will close this issue (please feel free to continue to comment). I have attached a spreadsheet, github_125.xlsx, which includes the calculations mentioned above and some simple plots of the raw fivpt Tsys data. |
On May 11, 2021, at 9:31 PM, Stuart Weston <@stuartdweston> wrote:
What I can't work out is why it comes up with a Tsys of 100.000 :
021.131.23:05:42.88#fivpt#tsys 71.274 32.456 100.000 0.1592
In the past I have managed to get a value in there, can't remember what I did as it was some years ago. But now with my current c.rxg file setup it always put's in 100.
The text was updated successfully, but these errors were encountered: