Monit7:tsys U/L inverted

[BeppeMc]

On fs-10.2-alhpa1 I found monit7 tsys U/L inverted, at least for A and B core I test.

[wehimwich]

Is this a change from 10.1? I don't think anything has changed here.

[BeppeMc]

I don't know. I didn't this w3oh test with 10.1.

[wehimwich]

Okay. More details would be helpful here. I don't see anything on vlbeer for this, but I may not be looking for the right thing. I assume this is single sideband or maybe the signal is different enough between the two that you can distinguish them. Is the labeling of the sideband for the mutlicast data in the log correct? Posting a log snippet could be useful.

[wehimwich]

Posting a log snippet could be useful.

Both the full setup and at least one second of multicast data from the log would be best.

[BeppeMc]

In attach a log extractions. bbc003 and 9 at 242.51/4MHz, so OH maser (245.51) must fall in USB of both.
Untill the comment "antenna onsource now" you see the K band background an all bbc's. At source reached, you will see increasing tsys of 3l and 9l while is quite stable 3u and 9u, as opposite of what expected.
Then some further on/off source cycles. Hope it can be helpful.
ed.log

[wehimwich]

Thanks. I see it. Can you also possibly do a bread on source and off source?

[wehimwich]

Thanks. I see it. Can you also possibly do a bread on source and off source?

It would be best if the echo=on output for those two cases can be included. Thanks.

[wehimwich]

Actually, just bbc003 and bbc009 with echo=on would be enough (smaller log file).

[BeppeMc]

ed1.log
In attach the log file with bbc003 & bbc009 on/off on W3oh with echo=on. Also w/o agc.

[wehimwich]

Thanks for sending the log. I think a case can be made that the U and L TPI are inverted from the DBBC3. There were hints of this in #97.

Looking at the data here, the format of the dbbcNN commands from the DBBC3 documentation is

DBBCnn/freq,IF,bwd,tpint,gainctrl,gainU,gainL,tpU/calon,tpL/calon,tpUcaloff,tpLcaloff

So the order is calon, then caloff. Within a cal state, it is U then L.

Picking just one sample off the source from the most recent log:

2023.070.07:05:29.47#dbbcn#[dbbc003\0]<dbbc003/ 242.510000,a,4,1,man,205,203,15760,15674,11654,11562;>

and one of on the source:

2023.070.07:05:58.87#dbbcn#[dbbc003\0]<dbbc003/ 242.510000,a,4,1,man,205,203,15759,16252,11660,12118;>

Just assuming a Tcal value (25) that gives about the right Tsys, we get:

source	U on	L on	U off	L off	U on-off	L on-off	U Tsys	L Tsys	U-L Tsys
off	15760	15674	11654	11562	4106	4112	83.46	82.79	+0.67
on	15759	16252	11660	12118	4099	4134	83.61	85.78	-2.17
on-off							-0.36	+2.99

Although the U-L Tsys difference will depend on the relative Tcal levels, the differences for a given sideband do not. It seems pretty clear that LSB Tsys increased on the source. A spreadsheet,Tsys.xlsx, is attached that uses all the samples from the log and both BBCs. The conclusion appears to be the same. The agc Tsys values seem to be slightly biased compared to the man values, but I am not sure there is a reason to expect that and it may just be within the normal variability.

We know from #90 that the output of the bbcNNN commands agree with the multicast at the raw data level. In this case, we are getting agreement on which sideband is seeing the increase in Tsys on the source.

BTW for all you alpha testers: @vlbi-jun-yang found an issue with the terminate command. It may be limited to FSL11, which is also pre-release but @BeppeMc was using it in these tests. The issue doesn't happen all the time. It appears that the format of /proc/[pid]/stat has changed slightly (it is poorly documented, but appears to be fairly stable). If you get an internal error -5 in a bo -177 and/or bo -178 error, just trying again, maybe a few times, may get around this. If you don't have an active autoftp or fs.prompt. or don't care if they are killed off, you can use terminate=force. A fix that is much more robust has been put on main. A new tagged version will come out in a few days. If you are using git, you can install the fix now with (as prog):

cd /usr2/fs
git checkout main
git pull
make -s

All the testing and reports are greatly appreciated. Thank you.

[wehimwich]

If the analysis looks correct, I think we should contact Sven. Are we sure the LO settings put the maser in the USB?

[vlbi-jun-yang]

@BeppeMc I am wondering which DBBC3 firmware are you using. So, I may load the firmware and then repeat the results at Onsala.

[BeppeMc]

The fw was DDC-U125, may be they already solved the problem in U126. I cannot try it, we are in maintenance.

[BeppeMc]

@ Ed: of course! Maser line was in USB.