DBBC3 Tsys support for non-continuous cal #194
Comments
|
At Onsala, we have to use non-continuous calibration at 22, 43 and 86 GHz. Because of the Chopper Wheel calibration, we have a local program to calcuate TCal and opacity. However, we still need these FS supports to get proper Tsys data in the log files. |
|
I have tried 32 BBCs to measure Tsys during the running 3-mm GMVA session. However, FS 10.2.0-alpha1 only outputed values for 12 BBCs. There seems to be an internal limit of the maximum BBC nubmers. |
|
Somehow, these total power monitoring data from DDC_U v126 are 0 in the FS log file. This is also strange. See: |
|
I should also mention that these FRB observations using VLBI backends at L band require to non-continuous calibration. In the project Pinpointing REpeating ChIme Sources with EVN dishes, PRECISE, there are about 1000 hours ad-hoc VLBI obsevations per year. |
|
Thank you @vlbi-jun-yang.
There shouldn't be anything limiting how many of the detectors you can use per se. I believe the problem stems from the fact that the buffer for the DBBC3 commands has not been updated for the longer devices (and the increased number of them) for the DBBC3. Thank you for catching this. Could you please point me to (or send me) a log or post a snippet that shows this problem, so I can confirm the cause? If it is, I think you may be able put the detectors in multiple commands as a workaround. Fixing this will improve the situation a lot, but it will still not be possible to handle naming every possible DBBC3 device individually in one command. The maximum input line, 512 characters, that can be processed is too short for that. It could be expanded to 1024 now to match the maximum class buffer length, but that won't handle all individual DBBC3 detectors either. When R2DBE support is added, the maximum class buffer length will be increased to 2048, which could handle this situation. OTOH, 512 already seems like a ridiculously long length. Usually, for large numbers of detectors, more general mnemonics are used and are sufficient for most purposes. The most useful,
This has already been fixed and will be available soon (see below). It stems from the fact that much of the original DBBC3 development used an early release of DBBC_V v124 that apparently had the order of the BBC cal-on/cal-off TPI values swapped in the multicast (this also affects non-continuous cal). The fix will be available soon (see below). For the early releases of v124, it will be necessary to use the tools for swapping TPI values in 10.2-alpha3 to handle this. Once I have increased the command buffer size, I will put it and the other fixes onto main to make them available and close this issue. We still won't have onoff and fivpt verified, but that will take more time and coordination. They should (hopefully) work as is. I will move verifying them to the "Testing 10.2-alpha3" discussion, #196. |
|
We need a snappier name for "non-continuous cal". The best I have heard so far is "spot cal", which seems pretty good. If you have a suggest, please let me know. |
|
The text part below is the output from my local test of 32 BBCs. Because DBBC2 controled our hotload, these total power readout numbers from DBBC3 DDC_U v126 were not meaningful. Moreover, BBC 81 should be removed in the list. |
|
I have also noticed that the SNAP command |
|
Thanks. As an example, looking at:
The 80th character pf the I have fixed both of these buffering problems. One or both of them also occur for the other rack types. I'll clean those up as well. In meantime, I think splitting the long lines into multiple ones, each with a total length of less than 80 characters (and making sure that each parameter is a complete specifier for a detector), is a work around. |
The I hadn't bother to implement those mnemonics for "spot" cal because I had thought (hoped?) we were only going to use continuous cal for the DBBC3. It wasn't possible to implement them until 10.1 anyway because we didn't have the |
I have opened a discussion topic for Chopper Wheel support, #200 |
* Increase command buffer Now big enough to accomodate each detector being menitoned once its long form. BOSS can't currently pass a buffer that big. * Pre-blank working buffer for parameter decode So we don't get some trailing left overs and mistake a partial parameter for a real one. Closes #194
* Increase command buffer Now big enough to accomodate each detector being menitoned once in its long form. BOSS can't currently pass a buffer that big. * Pre-blank working buffer for parameter decode So we don't get some trailing left-overs and mistake a partial parameter for a real one. Closes #194
@BeppeMc reported that DBBC3 Tsys with non-continuous cal (still!) works, but does not support
formbbcandformifintpi=.../tpical=.../tsys=.../etc.Continuous cal is the preferred way to go if it is available. If someone can't use continuous cal, we can look into cleaning up the remaining loose ends. I think the exhaustive task list is:
formbbcandformifmnemonics for DBBC3 in Tsys related commandsIt did not because it was based on early v124 TPI on/off order, but fixed now.
Possibly switch to using multicast for the count data (for speed)This should not be needed. The communication for the
bbcNNNandiftpXcommands seems plenty fast enough. It was tested using 64 BBCs and 8 IFs with DDC_E v126. Extrapolating from that, even 128 BBCs should be okay. This has improved since v121.For @BeppeMc's test, getting the count data via DBBC3 commands seemed fast enough for 8 BBCs and two IFs, but it is not clear yet if it will be for 64 BBCs (or more) and eight IFs:
The text was updated successfully, but these errors were encountered: