Hi Ken, Just closing the loop here. I did take a look and can confirm that the py38 branch for casperfpga at https://github.com/casper-astro/casperfpga had already received all the updates necessary for tbs3’s changes.
Mitch > On Feb 4, 2026, at 2:52 PM, Mitchell Burnett <[email protected]> > wrote: > > Ignore the previously suggested branch for caspefpga, the best one to try > would already be https://github.com/casper-astro/casperfpga py38 branch. It > had previously been changed to immediately trigger an update or wait for some > other external event. > > Mitch > >> On Feb 4, 2026, at 2:44 PM, Mitchell Burnett <[email protected]> >> wrote: >> >> Hi Ken, >> >> A version with your requested change was made last night and can be found >> here: https://casper.groups.et.byu.net/zcu216/zcu216update/. It’s the >> tcpborphserver3_v8.1 file with md5 checksum 6b9f2c25a7d1c0f34883574a5e0fcb04. >> >> I’m still working on the changes to casperfpga’s rfdc.py to push back. But, >> you may be able to try this branch until I can get some time tonight to push >> it back: https://github.com/mitchburnett/casperfpga/tree/rfsocs/rfdc-mts-nco >> >> Hope this helps, >> Mitch >> >>> On Jan 29, 2026, at 3:59 PM, Ken Semanov <[email protected]> wrote: >>> >>> Hello, >>> >>> We are attempting to perform MTS on a quadtile ZCU216. Our use-case >>> requires a call to API function, XRFdc_ResetNCOPhase( ) At present, it >>> does not appear that tcpborphserver3 has functionality for this, neither >>> in master branch nor rfsoc/rfdc branch. >>> >>> Below is a section of rfsoc.c located at >>> /alpaca/casper/katcp/-/blob/rfsoc/rfdc/tcpborphserver3/rfsoc.c starting >>> line 1413, >>> >>> int rfdc_update_nco_cmd(struct katcp_dispatch *d, int argc) { >>> struct tbs_raw *tr; >>> struct tbs_rfdc *rfdc; >>> // cmd variables >>> int result; >>> unsigned int tile, blk; >>> XRFdc_Mixer_Settings mixer; >>> char* type; >>> int converter_type; >>> double nco_freq; >>> double nco_phase; >>> unsigned int trigger_update = 1; // defaulat to force update event >>> >>> To match our use-case we would make the following modifications. >>> >>> (1) trigger_update would be moved to a function argument , so that we can >>> toggle it. (we believe a call to XRFdc_UpdateEvent() at line 1506 invokes >>> an error by design) >>> >>> (2) XRFdc_ResetNCOPhase( ) would be called somewhere after the call to >>> XRFdc_SetMixerSettings() (line 1498 in rfsoc.c ) >>> >>> Are these modifications possible? >>> Thanks for reading! >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected] >>> <mailto:[email protected]>. >>> To view this discussion visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/551bd52d-4c0d-43f5-93a9-3c06dd5eda9fn%40lists.berkeley.edu >>> >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/551bd52d-4c0d-43f5-93a9-3c06dd5eda9fn%40lists.berkeley.edu?utm_medium=email&utm_source=footer>. >> > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/9873A2E0-162A-4EF8-B899-7EDC45618F6F%40gmail.com.
