-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help with embedded outbound Reverse Channel information #8
Comments
Hey @kantooon
https://github.com/OK-DMR/ok-dmrlib/blob/master/okdmr/dmrlib/etsi/crc/crc.py#L291
Not sure why you have final_xor_value=0x7A |
Hi, thanks for responding, answers below:
Unfortunately I don't. I'm writing this blind, and the only way of testing it is with my radios (Hytera HP785, manual says it supports transmit interrupt and power control).
ETSI TS 102 361-1, section B.3.12 Data Type CRC Mask, table B.21, reverse channel has a CRC mask of 0x7A. Isn't that the purpose of final_xor_value? Also, if you can, is it possible to add odd parity option to VBTC3211 as in B.2.2.2 Reverse Channel Single Burst BPTC? |
Ok, data type mask, i handle those differently since the CRC impl is typically not data-type-specific, indeed I think that's where your problem might be If you take a look for example in CRC9 ok-dmrlib/okdmr/dmrlib/etsi/crc/crc9.py Line 51 in fdb3fa7
I apply the mask to calculated and two-complement value of CRC, you can try similar flow, coding the crc's was the most tricky part for me as well :)) And last, how did you figure your payload is not taking effect because of invalid CRC ? Working with Hytera radios sometimes the reason is codeplug settings or licensing or just straight firmware bug. If you're able to capture full traffic with your MS as PCAP, we could maybe see more? I guess you're already aware of pcap tooling we have |
Thanks for the advice, I'll try this method as well, but for CRC9 the standard specifies an inversion polynomial, whereas for CRC7 it explicitly says there's no inversion polynomial.
I guess I will need to double check the codeplug, power control is explicitly enabled, but there's no setting for receiving TX interrupt, only for transmitting. As far as licenses, I'm covered, the tier III license has everything. |
Regarding the network, suffices to capture network traffic between mmdvmhost (i assume you have some rpi hotspot or similar) and your computer (hblink maybe?), pcap can then be filtered and data extracted using dmrlib-pcap-tool, usually simply running "dmrlib-pcap-tool PATH_TO_YOUR_CAPTURE.pcapng" shows you data and stats, then you can fiddle with cli switches, see help
|
Oh I see what you meant with pcap. The RC PDU is only trnsmitted via RF currently, but I can also add it to the network transmisssion so I can wireshark it. I don't have a classic hotspot, my setup is all SDR-based and running on x86_64 Linux. If you're curious, my test tier III system consists of a LimeSDR family device, qradiolink as lower PHY with 7 RF channels multiplexed in GNU radio flowgraphs, and some custom forks of MMDVM and MMDVMHost called MMDVM-SDR and MMDVMHost-SDR. The RC PDU transmit is initiated from the trunking controller (dmrtc) and sent on the alternate logical channel (it only works with aligned timing and not offset timing). |
very impressive, i've yet to work more with downlink and Tier-III PDUs, and the reason is i don't have them captured (i have SDR but it wasn't my priority so far to get it), if you could supply me with the on-air data, i would add a support for all these PDUs and routines to handle them. Regarding form of the data, you can take inspiration from our and lwvmobile's last-years adventure with dsd-fme "DSP structured output" lwvmobile/dsd-fme#94 (comment) And last I guess your note about aligned/offset timing is just the current state of implementation, not actual AI protocol limitation? |
Yes sure, I use dsd-fme as well to test PDUs. Let me know what PDU captures you need, I already asked lwvmobile for a few changes in the DMR decoder and supplied him with some captures off the air. The aligned timing limitation is specified in the standard at 5.1.1 Channel timing relationship. |
I'm going to close this now, as I haven't been able to find the solution yet, but I'm busy with other stuff. I'll come back to this later with a fresh perspective and if I find the right solution I'll also let you know. |
Keep it open, its bookmark for my brain as well, thanks and good luck 🤞 |
Hi, I'm trying to implement in MMDVMHost the DMR tier III reverse channel commands for MS de-key and MS power control.
I use ok-dmrlib to generate the 32 bit PDUs, but the radios do not respond to the commands so there seems to be some issue with my code.
I figured out by myself that in VBPTC3211 I have to invert the parity bits row to odd in the set_parity() method and changed it accordingly. I'm not so sure about CRC7 configuration.
I wonder if you could help me troubleshoot my ok-dmrlib code below. Otherwise, the EMB fields are set with LCSS 0, PI 1 and correct colour code. The PDU is only transmitted in voice burst F so that seems fine as well.
The text was updated successfully, but these errors were encountered: