Brandmeister always hands me my own radio id in the “repeater id” field, bytes 11-14 (inclusive) in the DMRD…. If anyone has seen different, let me know soon. I’m about ready to normalize it all so that a master always sends the client’s ID to it in that field, and a client always uses it’s ID in transmissions to the master. This will fix a few discrepancies, and will be done in hblink.py so all applications will be normalized in the process.
Speak now please….
0x49 DE N0MJS
On Jul 28, 2018, at 8:58 PM, Cort N0MJS via Groups.Io <n0mjs@...
Ok, I’m going to admit to having not looked at any of this for a long time. I've found a few discrepancies in what I’ve done over time
I have a question that needs answered by the stewards of HB Protocol:
Should the “repeater_id” field (bytes 11-14 of the DMRD), when a master is sending to a client, be the radio ID of the client, or the radio ID of the originating repeater? I’ve sorta treated it both ways and don’t apparently know the real answer.
What is that field really about? And is it the same in either direction? (client -> master and master -> client).
With that answered I can clean up this entire mess once and for all. I asked G4KLX a question about HBP once and the answer I got was read the (completely un-commended C++) source code of MMDVM and figure it out… Not helpful. Brandmeister does not approve of or want HBlink talking to their system… so not a good move either. Maybe the DMR+ guys are more help, but I don’t know them. Maybe one of you who is friendlier with BM or Jonathan can get us an answer?
On Jul 28, 2018, at 4:15 PM, Matthew 2E0SIP <groups.io@...
Understood on the muddling of OSI layers - I get where you're coming from.
I think the easiest work around in that case is an option to rewrite the RADIO_ID for frames being sent to a Master to hblink's own Client RADIO_ID, as you suggested.