Beam syncing code for cv

[ksterne]

@sshepherd, I tested this additional code on fhr between 435 and 5 on 20191128 and see the timing's coming out pretty good. There's some wiggle on the start of the beam sounding that I haven't quantified yet, but it's not an iterative delay like we're experiencing now.

I don't see any of the rxonly code for changing the cpid here, so I wouldn't suggest merging this until you've pushed changes from the radar back to this repo. (Something you should do sooner than later if you'd like to have a backup for your code) At least you can see the changes that you'd need to make and where from this pull request. You should be able to test this out during common time as it doesn't have break CT guidelines/rules if you keep the integration and beam times down to do a full scan.

[egthomas]

@ksterne the cv_dev branch may be a more appropriate target for this pull request rather than the cv_ops branch, since cv_dev contains all of the other bistatic/triggering updates. At least that's my impression from the commit histories.

[ksterne]

Sounds good, I'd taken a guess as it's hard to tell which branch is appropriate here. @sshepherd can you comment on which branch I should target this pull request to...or even if you'd like to merge this in?

[sshepherd]

Possibly, but I won't be looking at this until after AGU.

…

On Mon, Dec 2, 2019 at 10:14 AM Kevin Sterne ***@***.***> wrote: Sounds good, I'd taken a guess as it's hard to tell which branch is appropriate here. @sshepherd <https://github.com/sshepherd> can you comment on which branch I should target this pull request to...or even if you'd like to merge this in? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAWYGPYO6XSNXVDCW4WQ3D3QWUQ3RA5CNFSM4JTESXZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFTZ4UY#issuecomment-560438867>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWYGPZ4BQZBPK6RG6RDBTDQWUQ3RANCNFSM4JTESXZA> .

[sshepherd]

Kevin, I am revisiting this code. Can you remind me of the numbers that you used to test (3.000 seconds? 2.xxx seconds?) and what the remaining issues may have been? You made this change to your normalscan control program? This is something I could/should test when the computers come back up at the site... Simon

…

On Fri, Nov 29, 2019 at 9:37 PM Kevin Sterne ***@***.***> wrote: @sshepherd <https://github.com/sshepherd>, I tested this additional code on fhr between 435 and 5 on 20191128 and see the timing's coming out pretty good. There's some wiggle on the start of the beam sounding that I haven't quantified yet, but it's not an iterative delay like we're experiencing now. I don't see any of the rxonly code for changing the cpid here, so I wouldn't suggest merging this until you've pushed changes from the radar back to this repo. (Something you should do sooner than later if you'd like to have a backup for your code) At least you can see the changes that you'd need to make and where from this pull request. You should be able to test this out during common time as it doesn't have break CT guidelines/rules if you keep the integration and beam times down to do a full scan. ------------------------------ You can view, comment on, or merge this pull request online at: #2 Commit Summary - Adding wait on beam sounding functionality File Changes - *M* linux/rst/usr/codebase/superdarn/src.bin/os/cp/normalscan.1.7/normalscan.c <https://github.com/SuperDARN/msi_software/pull/2/files#diff-0> (14) Patch Links: - https://github.com/SuperDARN/msi_software/pull/2.patch - https://github.com/SuperDARN/msi_software/pull/2.diff — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAWYGP4HONYDUZ5TBBWWFVDQWHGXDA5CNFSM4JTESXZKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H47ESFQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWYGP4JHBLWTDHJTT2TCVDQWHGXDANCNFSM4JTESXZA> .

[egthomas]

It may be worth noting the Site***StartScan and Site***EndScan functions are slightly different between the FH and CV site libraries. For example, at CV this code block

smsg.type=SET_ACTIVE;
TCPIPMsgSend(sock, &smsg, sizeof(struct ROSMsg));
TCPIPMsgRecv(sock, &rmsg, sizeof(struct ROSMsg));

is called at the end of SiteCv*EndScan, while for FH it is called within SiteFh*StartScan.

[sshepherd]

Good catch Evan. I am not entirely sure which is correct (maybe neither!) but should look into it. I am guessing that this will affect the coordination handling. Simon

…

On Tue, Apr 7, 2020 at 6:38 PM Evan Thomas ***@***.***> wrote: It may be worth noting the Site***StartScan and Site***EndScan functions are slightly different between the FH and CV site libraries. For example, at CV this code block smsg.type=SET_ACTIVE; TCPIPMsgSend(sock, &smsg, sizeof(struct ROSMsg)); TCPIPMsgRecv(sock, &rmsg, sizeof(struct ROSMsg)); is called at the end of SiteCv*EndScan, while for FH it is called within SiteFh*StartScan. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWYGPZH4MMEQOZQLGPO7ZTRLOTPBANCNFSM4JTESXZA> .

[sshepherd]

This is definitely a bit troubling. It appears that the FH version is more correct, i.e., it makes sense that you would set something to "ACTIVE" at the start of a scan, rather than at the end. That being said, it the code is quite complicated and perhaps this has no effect... You might also notice (at least in the version that I have) that SiteFh?Exit() is called three times in the FH version of SiteFh?EndScan(), whereas it is called only once in the CV version. Jeff was clearly doing it for a reason, but it doesn't really make sense. After a little more digging, it seems that the purpose of the ACTIVE/INACTIVE setting is to simply indicate that the control program is running but waiting for a boundary. In the CV version of SiteCv?EndScan() it is basically: SET INACTIVE sit in a loop checking the time every 50 milliseconds until we have *passed* the start time of the next beam or scan SET ACTIVE I am a bit concerned about the logic that is used (at both sites) to determine whether we have *passed* the start time of the next beam/scan. There are several places where doubles are not type cast to integers or longs. I can see where we might end up sitting in the wait-loop for an entire beam, particularly when we have gone from a 120 sec scan to a 3 sec beam. Rounding might make a big difference in the latter case. Also, I think we should drop the time checking from 50 milliseconds to 5 milliseconds. It means we are checking the time 10x, but otherwise we just are just sleeping.

…

On Tue, Apr 7, 2020 at 6:38 PM Evan Thomas ***@***.***> wrote: It may be worth noting the Site***StartScan and Site***EndScan functions are slightly different between the FH and CV site libraries. For example, at CV this code block smsg.type=SET_ACTIVE; TCPIPMsgSend(sock, &smsg, sizeof(struct ROSMsg)); TCPIPMsgRecv(sock, &rmsg, sizeof(struct ROSMsg)); is called at the end of SiteCv*EndScan, while for FH it is called within SiteFh*StartScan. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWYGPZH4MMEQOZQLGPO7ZTRLOTPBANCNFSM4JTESXZA> .

[ksterne]

There's probably lots we could do to improve things. I'm game for any of them, but it seems as though this has veered away from the original topic. That and I'm guessing @sshepherd got it running without git. So, I think this PR can be closed?