search

slaclab / pysmurf

Other
2 stars 9 forks source link

Subband Centers Off by 1 Subband Width #675

Closed msilvafe closed 2 years ago

msilvafe commented 2 years ago

https://github.com/slaclab/pysmurf/blob/0fef2dda87e6da292485266b3bf630c9b7ca97dc/python/pysmurf/client/util/smurf_util.py#L2481-L2485

The center frequencies returned from get_subband_centers are off by one half subband width. The current math means that we span the range -N_subbands/2 + 1 to N_subbands/2+1 with the current number of subbands (512) this is the range -255 to 257 but the range should be -256 to 256 to get the center frequency locations returned correctly.

agustiner commented 2 years ago

Unfortunately I'm not clear on the theory for why subbands are needed here, but note that for 512 subbands, the current code returns 512 integers from -255 to 256 inclusive. That is, (numpy.arange(1, 512 + 1) - 512/2). Do you still want the range to be -256 to 256 inclusive? I've attached the current code for reference: 1.txt

msilvafe commented 2 years ago

I will close this @aer7 I just put on a tone on and then read back it's frequency using this get_subband_centers command and found that it returned the frequency I commanded and matched what I measured on a spectrum analyzer. Not sure how I had an issue before. I must have just made a mistake or was looking at the wrong thing.

For reference this is what I ran:

band, channel = S.set_fixed_tone(4567.89,12)
sb = S.get_subband_from_channel(band,channel)
sbs, sbc = S.get_subband_centers(band)
freq = sbc[sb] + S.get_center_frequency_mhz_channel(band,channel)
print(freq + S.get_band_center_mhz(band))

4567.890000009536 was returned and the tone on the spectrum analyzer was at the correct frequency (see photo below). image