You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lim at Onsala , and Christian at Wettzell, reported that multicast format has changed in the recently released DDC_V v126 firmware. Lim also reported that, unlike other versions, vsi1-2 is used for inputselect. There may be other differences.
The main advantage of the new version seems to be that it provides v126 firmware that supports 16 channels per Core3H board for eight boards (VGOS) without crashing the DBBC3. The DDC_U version apparently crashes the DBBC3 for at least some systems (reported by Lim). It appears that, like the DDC_U version, the DDC_V version suppresses every other multicast message (i.e., half of them) when eight Core3H boards are in use.
The long-term solution for this is, of course, to add support for the differences in DDC_V v126:
Support change in multicast format. It appears that the only change was to add a VDIF epoch field per Core3H board.
Change to vsi1-2 for inputselect
Adjust for other differences. if any ...
Although we can't overcome the v126 versions suppressing every other multicast message, we could:
Add a user settable option (on by default iff using v126 with eight Core3H boards), that suppresses error reports for loss of every other multicast message. Visual cues for the lost messages in the Tsys Monitor display window could remain. Whether this is an acceptable operating scenario would have to be considered.
In the short-term, two workarounds may be possible:
If the DDC_U v126 doesn't crash, use it. The loss of every other multicast message for eight boards systems is not ideal of course, but would also happen for DDC_V v126. There will still be TPI data for amplitude calibration at half the usual time density. When continuous-cal is in use, there will also still be Tsys for system monitoring. If that is acceptable, the only remaining concern is that the operator will see summary error messages about dropped multicast messages every minute (FS 10.2). It should be possible to suppress those with: tnx=dn,-25. Note this may also cause some multicast messages lost for other reasons to not be reported.
Use DDC_V v126 and accept not having TPI/Tsys data. This may not be acceptable for operations, but may be adequate for test observations. Lim was able to get usable VLBI data. The tnx=dn,-25 command (FS 10.2) can also be used to suppress the summary error message about dropped multicast messages. In addition, it should be possible to suppress the dr -622 messages about the inputselect setting with tnx=dr,-622. It may be necessary to suppress multiple message versions for that error code.
The text was updated successfully, but these errors were encountered:
Lim at Onsala , and Christian at Wettzell, reported that multicast format has changed in the recently released DDC_V v126 firmware. Lim also reported that, unlike other versions,
vsi1-2
is used forinputselect
. There may be other differences.The main advantage of the new version seems to be that it provides v126 firmware that supports 16 channels per Core3H board for eight boards (VGOS) without crashing the DBBC3. The DDC_U version apparently crashes the DBBC3 for at least some systems (reported by Lim). It appears that, like the DDC_U version, the DDC_V version suppresses every other multicast message (i.e., half of them) when eight Core3H boards are in use.
The long-term solution for this is, of course, to add support for the differences in DDC_V v126:
vsi1-2
forinputselect
Although we can't overcome the v126 versions suppressing every other multicast message, we could:
on
by default iff using v126 with eight Core3H boards), that suppresses error reports for loss of every other multicast message. Visual cues for the lost messages in the Tsys Monitor display window could remain. Whether this is an acceptable operating scenario would have to be considered.In the short-term, two workarounds may be possible:
If the DDC_U v126 doesn't crash, use it. The loss of every other multicast message for eight boards systems is not ideal of course, but would also happen for DDC_V v126. There will still be TPI data for amplitude calibration at half the usual time density. When continuous-cal is in use, there will also still be Tsys for system monitoring. If that is acceptable, the only remaining concern is that the operator will see summary error messages about dropped multicast messages every minute (FS 10.2). It should be possible to suppress those with:
tnx=dn,-25
. Note this may also cause some multicast messages lost for other reasons to not be reported.Use DDC_V v126 and accept not having TPI/Tsys data. This may not be acceptable for operations, but may be adequate for test observations. Lim was able to get usable VLBI data. The
tnx=dn,-25
command (FS 10.2) can also be used to suppress the summary error message about dropped multicast messages. In addition, it should be possible to suppress thedr -622
messages about theinputselect
setting withtnx=dr,-622
. It may be necessary to suppress multiple message versions for that error code.The text was updated successfully, but these errors were encountered: