Different Tcal[Jy] with DBBC3 FS 9.12.12 for BBCs with same sky RF, but using USB/LSB #97
Comments
|
It is an interesting situation. Picking on 10664.4 (which has the largest differences in what you sent), I went through and verified the Tsys, SEFD, and Tcalj calculations by hand based on the information in the log. This is given in (gasp :) Issue97.xlsx. The Tcal and flux values were the same for From the spreadsheet, we can see that the off source values for both detectors are noisier than the on source values. Perhaps this is due to RFI, but the spread is still small. The differences between the two detectors for a given type of value are somewhat bigger, and probably the cause of the differences in the calculated values. Since the values don't differ by a constant, I am inclined to not think they are due to the actual zero levels of the detectors (which the FS does not measure) being different. I agree that there could be differences due to being different devices and different timing. The FS doesn't actually measure the zero levels (there is no way I know of for the DBBC3). Since these are digital detectors the zero levels should be small, if not actually zero. Maybe upper/lower sideband bandpass shape could be an issue, if in fact they are different. The FS sets the gains to manual for the duration of the measurements. I think that must be working or the measurements would be a big mess. Something we can do with the (in development) DBBC3 branch of the FS is to compare the BBC responses with the multicast values to see if they agree. Since the values from a single multicast message should all be from the same second, we could also verify whether they are producing the same values for overlaid sidebands in the same second. There could be both USB/LSB and USB/USB comparisons. I think this raw TP value check should be done before going onto other comparisons. You might be able to do a partial raw TP check by hand with 9.12.12 for a couple BBCs, using a SNAP procedure that samples the two BBCs with overlaid sidebands in quick succession. You might have to try a few times to get samples from the same second. It may make sense in the future to switch to using the multicast for the ONOFF measurements. It could potentially make them faster. However, it would probably not make the agreement between overlaid sidebands better unless the difference is driven by RFI, in which case, you could still have time variations. |
|
I've had no time to dig into this yet, and likely not for a few weeks. But I just want to note that this issue happened with v124 of the DBBC3 firmware. I have not tested levels or TPI logging from v125 yet. |
|
This post is a relevant digression into the read back of TP data. A later post will compare TP results from overlaid upper and lower sidebands. It might be awhile until the second one because we ran into some things we don't understand about v125. All of this was done with v125. First, it seems that it can take some time, around 40 seconds in the case I looked at, for the gain to stabilize after a BBC frequency change. I only looked at a relatively "small" change of 32 MHz. The time involved probably isn't too surprising. Presumably there can be cases where it take more or less time. Once it stabilizes, two BBCs with the same frequencies get the same counts, generally: However, there are still occasional differences at the single count level: The can also be larger differences: Note that the gains are also different in this case. The On-Off differences are nearly the same, differing by 2 for USB, and 5 for LSB. The latter is about 6%. However, this only seems to happen if the measurements are near what might be called the "update epoch" (see below). The antenna was looking at the ground these tests. That may have exacerbated the difference. (FYI, the order of the TP values is USBon, LSBon, USBoff, LSBoff.) Second, it looks like the TP values from the BBCnnn commands are the same as from the multicast: (The I am a little confused about the timing of this. The multicast arrives at about 570 ms into the second. After sampling repetItively, it looks like the BBC commands update their outputs at about 370 ms into the second, the "update epoch". For example: Note that my example above for comparing to the multicast is well away from this transition point. It seems like there could be at least two scenarios: (1) everything changes at about 370 ms and that is when the multicast data is generated, or (2) internally it changes at the 1 PPS, but it takes 370 ms to get that into the BBCnnn response and multicast. Maybe the latter is more likely, but I don't think that matters for most purposes. However, if you are trying to scan across a source continuously (not in steps like fivpt), the position is changing relative to the source while you are sampling. I think you could measure it by scanning first from one side and then from the other; resolution might be low in terms of changing power levels though. It could be that the "update epoch" changes, but if it and the multicast are driven by the 1 PPS, it may be stable. @varenius it would still be useful to redo your original measurement with |
|
Continuing the digression on TP read back, it seems that the "update epoch" depends on the BBC number. For example: The transition times vary at the few 10s of ms level. The summary is:
This might be explained by there being two threads for updating the BBC command TPs: one for BBCs 1-64; the other, BBCs 65-128. With both starting at about the PPS epoch and requiring about 10 ms per BBC. Wild guess. |
|
Since the equivalence of the BBC command and the multicast TP output, and additionally the Tsys calculation for the multicast, has apparently been established by #90, I thought I would try to look at this from the point-of-view of the multicast data. This test was done with DDC_V v124, which is hopefully no different for these purposes than DDC_U v125 used in that issue. Starting with the setup loaded by Eskil (VGOS I think). I did a simple baseline test of two BBCs (23 and 24) with the same frequency (2360.6). It required about 25 seconds for the TP values to stabilize to agreement after the frequency was set, but then all four TP values agreed exactly between the two BBCs for the 10 or so further seconds I collected data. As would be expected, Tsys was also identical for those samples. So far so good. Then I looked at the USB/LSB issue more using Eskil's choice of 049u and 050l (without changing frequencies, BBC049 at 919.6 and BBC050 at 951.6). The raw data is in 4950.txt. After deleting the two samples with overflows, there were 46 sets of multicast samples to compare. Neither the counts nor the Tsys values were equal for the overlaid USB and LSB channels. Summarizing the Tsys results from looking at the ground:
The scatter of the individual channels is about 10%. The differences between the two channels that should nominally agree, 049u and 050l, have an even larger scatter. The difference between the two channels on the "wings", 049l and 050u, have a scatter that is smaller by about a factor of two. If significant, this seems odd. I saw similar behavior for two other BBCs I tested in this way. It seems unlikely that the channels could be mislabeled, but that should be easy to check by injecting a test tone. I included the additional cross channel differences in the table out of curiosity. For this number of samples, the sigma of the mean is about a factor seven smaller than the RMS. Some of the average differences might be significantly different from zero. It seems odd that LSB-LSB and USB-USB differences seem closer to zero than the others, but maybe it is chance. OTOH, maybe there is something systematically different between USB and LSB channels. It could be that I still don't have counts properly aligned in some way or that the assumption that the two firmware version behave in the same way is wrong. This may be the first time we have this situation with digital down conversion, settable channel frequencies, and simultaneous samples for an USB/LSB comparison. It would be interesting to look at the results on the sky. A run of onoff with |
|
I'm preparing a sky test with FS10 to continue this ticket. I know how to run onoff with echo=on. I know how to set BBCs. I can arrange overlaid USB and LSB (one BBC USB overlaps with LSB of another bBS), and I can arrange boths sidebands set to the same frequencies (so both USB and LSB overlap). But I'm not sure exactly what @wehimwich is after with "also the other two sidebands for the BBCs involved (the "wings")". Could you please clarify? Then I can get everything you want in one go. |
|
I'm glad you will be able to look at this @varenius. What I meant was that if you have overlaid different sidebands for two different BBCs, say |
|
Here is a log with the VGOS setup but using FS10, and echo=on. I also set two BBCs to the same frequency, so full overlap. Hopefully this will provide the requested data. If you need more, please let me know. |
|
Thank you @varenius. I looked through these data fairly thoroughly. My overall conclusion is that if there is a problem it is not in the FS. I think we can close this issue for the FS. In oo01.log, there are two runs of onoff. The general scheme for the data is that that 49u and 59l are overlaid side-bands (therefore nominally the same RF bandpass, but reversed images) and BBCs 51 and 52 were at the same BBC settings as each other (so they have matched upper and lower sidebands). There were 60 more BBCs (120 more sidebands) in each run, but I did not look at those. The basic question we are interested in is how different are the overlaid sidebands. I used a spreadsheet, oo01.xlsx, to compare the results. There are two sheets, one is I calculated the differences in the Percentage differences for the first onoff run:
The second onoff run gave very similar results, which are shown here for completeness:
Quick comments:
I think it is somewhat remarkable that the wing channels agree better than the overlaid sidebands. We had seen this before when the telescope was pointed at the ground. So it seems to be consistent behavior. It could be that this is just the way data are (for whatever reason), but if the sideband count data labels were reversed within a BBC or the FS reversed the data, the results for the wings would actually be for the overlaid sidebands. To check on this for the FS, I reviewed the onoff calculations from the raw data through the
So the I recalculated the NOTE: The flux values used in the calculations for 49l, 49u/50l, and 50u, are, respectively, 333.65, 334.55, and 335.45 (LSB first LO and BBC49 is set to a lower frequency than BBC50). The total range is about 0.6%. That variation does not seem to be a dominating contribution. If the 334.55 is used for the wings in the first onoff run, the difference of 49l-50u for SEFD improves to 0.1%; Tcal(j) gets worse, 0.9%. This is calculated in the In summary, I am inclined to think that the differences in the overlaid sidebands are just the way the DBBC3 behaves, maybe due to differences in bandpass shapes or other considerations. Sven might know. I don't think it is likely that it is caused by mislabeling of the count data by the DBBC3. If someone is interested and has a DBBC3 at their disposal, they might be able to verify that by injecting a signal that will raise the counts of just one sideband of a BBC. |
|
One thing I did not mention in the post above is that for the first onoff run the count data had values of around 6000. However, for the second run the counts were about 16000, which is the expected nominal value. The values being lower than nominal in the first run might be explained by the run being started soon after the telescope was moved away from ground and the gain not having fully settled. The gain is set to |
1 FS_DBBC3_MULTICAST_BBC_TPI_USB_LSB_SWAP
0 FS_DBBC3_MULTICAST_BBC_ON_OFF_SWAP
0 FS_DBBC3_MULTICAST_CORE3H_POLARITY0_ON_OFF_SWAP
1 FS_DBBC3_MULTICAST_CORE3H_POLARITY2_ON_OFF_SWAP
0 FS_DBBC3_MULTICAST_CORE3H_TIME_ADD_SECONDS
FS_DBBC3_MULTICAST_CORE3H_TIME_INCLUDED
0 for DDC_V
: 1 for all others
1 FS_DBBC3_MULTICAST_VERSION_ERROR_MINUTES
1 FS_DBBC3_BBCNNN_TPI_USB_LSB_SWAP
1 FS_DBBC3_BBCNNN_GAIN_USB_LSB_SWAP
0 FS_DBBC3_BBCNNN_ON_OFF_SWAP
0 FS_DBBC3_IFTPX_POLARITY0_ON_OFF_SWAP
1 FS_DBBC3_IFTPX_POLARITY2_ON_OFF_SWAP
1 FS_DBBC3_BBC_GAIN_USB_LSB_SWAP
Closes #97
Closes #192
Specifically the USB_LSB_SWAPS close those issues.
Before every DBBC3 experiment, I run "ONOFF" on Cas A to check the TCAL strength. For various reasons, the DPFU/gain used to Kelvin-conversion is not a priority, so instead I check and compare the Tcal[Jy] columns. Significant changes here indicate noise diode is not stable. (The Tcal[Jy] can be used to scale the TPI data, logged externally for now as per #32, given that we have a stable diode).
In standard VGOS observations, 64 BBC channels in the DBBC3 are used with 32 MHz bandwidth each. For recording, Oe/Ow antennas use the Upper Sideband (USB) for Band A (3-3.5GHz), and Lower Sideband (LSB) for bands B, C, D. Only one 32MHz sideband gets recorded in the VDIF; one of the BBC sidebands is filtered out by the VSI bitmask when the VDIF streams are created. However: For the FS ONOFF procedure, each BBC has both sidebands available for TPI measurements. This means that we, effectively, have 128 BBC channels for frequency measurements.
Checking these things in detail, I noted something curious. Because it so happens that the USB of some BBCs is the LSB of other BBCs, we get some lines in the ONOFF VAL output with multiple values for the same frequency. In theory, these should be exactly the same. However, I found that they can differ, see for example Ow b21060 logfile (see e.g. ftp://ivs.bkg.bund.de/pub/vlbi/ivsdata/aux/2021/b21060 for full Ow logfile) data for Band D, where we have the following doublets in band D (I picked this to mitigate any RFI-issues for my comparison):
(there are others overlapping USB/LSB pairs in other bands).
Interestingly, we see that for X-pol LSB 10664.40 we get Tcal 111.474 Jy, but for the same USB frequency we get 121.779 Jy, so a difference of about 10%. This is surprising to me, I thought these would be identical. Is this a bug/feature/limitation of the DBBC3/FS (still running 9.12.12 here)?
Theories: Even though the frequencies are the same, the BBCs are different. This means different signal paths (although same core3h board), different BBC gain levels (since the AGC would adjust for both BBC USB/LSB in total, and the total would be different from the two BBCs). Still, I would assume that the power we get would be the same, as it should be a physical power. Perhaps, given that the BBCs are in different orders, the readout time, and possible the set/reset time (for 0-level measurements, agcs etc.) is slightly different. Maybe all these factors could explain the behaviour. But, nevertheless, I find it curious.
One interesting test could be to tune all 8 BBCs of the core3h board (running v124 firmware here) to the same BBC freq, and see if they are identical or not. Then, shift half of them so the USB becomes LSB of the other 4, and check again. Then, do the same but shift down so LSB becomes USB. Maybe there is a pattern somewhere?
We should test this with FS10 at some point too.
The text was updated successfully, but these errors were encountered: