nrarfcn: Fix behaviour on invalid input parameters
Contrary to earfcn, where band can be automatically deduced from earfcn number because 4G bands never overlap, most functions in nrarfcn accept as input parameters both nr_arfcn and band, because 5G bands can and do overlap. As the result it is possible to invoke e.g. dl2ul with dl_nr_arfcn being outside of downlink spectrum of specified band. However in b8065120 I've made a thinko and handled such situation with simple assert which does not lead to useful error feedback from a user perspective, for example: In [2]: xnrarfcn.dl2ul(10000, 1) --------------------------------------------------------------------------- AssertionError Traceback (most recent call last) Cell In[2], line 1 ----> 1 n.dl2ul(10000, 1) File ~/src/wendelin/xlte/nrarfcn.py:85, in dl2ul(dl_nr_arfcn, band) 83 if dl_lo == 'N/A': 84 raise AssertionError('band%r does not have downlink spectrum' % band) ---> 85 assert dl_lo <= dl_nr_arfcn <= dl_hi 86 ul_lo, ul_hi = nr.get_nrarfcn_range(band, 'ul') 87 if ul_lo == 'N/A': AssertionError: The issue here is that asserts can be used to only verify internal invariants, and that reported error does not provide details about which nrarfcn and band were used in the query. -> Fix this by providing details in the error reported to incorrect module usage, and by consistently raising ValueError for "invalid parameters" cases. The reported error for above example now becomes ValueError: band1: NR-ARFCN=10000 is outside of downlink spectrum
Showing
Please register or sign in to comment