Just to let you know, the addition of GSM_PCHAN_TCH_F_TCH_H_PDCH in libosmocore implicitly broke the ctrl interface tests in openbsc.
FAIL: testBtsChannelLoad (__main__.TestCtrlBSC) ---------------------------------------------------------------------- Traceback (most recent call last): File "./ctrl_test_runner.py", line 237, in testBtsChannelLoad self.assertEquals(r['value'], 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0') AssertionError: 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0 unknown 0xb,0,0' != 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0'
because this is unexpected output: "unknown 0xb,0,0"
So *any* commit submitted to openbsc will currenty fail. I'll probably fix it shortly with a commit to openbsc...
This also directed my attention towards the pchan_load mechanics. It always shows a TCH/F_PDCH entry, but in PDCH mode those would not have any load. I guess it makes sense in the current scheme of things, though it could make even more sense to record channel load not as separate TCH/F_PDCH but in the TCH/F slot, depending on current pchan mode? Similarly for upcoming TCH/F_TCH/H_PDCH: record in the TCH/F or TCH/H slot according to current pchan mode... (For now I'm focusing on completion of TCH/F_TCH/H_PDCH usability, if at all pchan_load tweaks would come later)
~Neels