Implementing some missing features

[ok1pt]

Hi!
I would like to ask, whether there is a plan to implement some features which are still missing in the current version, for example:
- Storing the power setting per channel. Very handy! Let's imagine you are alternating between a repeater far away from you and a local hotspot. You need 5W for the repeater and 50mW for the hotspot. Now you need one press to change the channel and 8 shifted presses to change the power. It's not good especially for the cheap chinese keyboard (or for the battery if you will stay on 5W for both).
- Responding to and being able to send Radio Check packets. I like to check, whether the person I want to call is attached to the network, to prevent useless noise. Now I can't doi it from my radio, and even if I use another radio I'll not get a response if the target uses OpenGD-77.
I'm asking not only because I would like to have these features, but also because it's possible I could help with their development. I believe that I can do the first one just with a small guide with UI and also a recommendation where to grab 4 bits in the channel structure for storing the power value. The second is probably still too advanced for me as a whole, but I can possibly help with some particular portions of it.
With regards & 73,
Pavel

[ki4gst]

Hi!
I would like to ask, whether there is a plan to implement some features which are still missing in the current version, for example:
- Storing the power setting per channel. Very handy! Let's imagine you are alternating between a repeater far away from you and a local hotspot. You need 5W for the repeater and 50mW for the hotspot. Now you need one press to change the channel and 8 shifted presses to change the power. It's not good especially for the cheap chinese keyboard (or for the battery if you will stay on 5W for both).
- Responding to and being able to send Radio Check packets. I like to check, whether the person I want to call is attached to the network, to prevent useless noise. Now I can't doi it from my radio, and even if I use another radio I'll not get a response if the target uses OpenGD-77.
I'm asking not only because I would like to have these features, but also because it's possible I could help with their development. I believe that I can do the first one just with a small guide with UI and also a recommendation where to grab 4 bits in the channel structure for storing the power value. The second is probably still too advanced for me as a whole, but I can possibly help with some particular portions of it.
With regards & 73,
Pavel

To answer your first part on power. From what I understand the problem is even thou the firm ware supports all the diffrent power setting the code plug part only supports 2. So that we’re the hang up is. Since the code plug part of memory only supports high and low and Roger hasn’t found a way around it.

[ok1pt]

Hi!
Yes, I know the problem that there is just one bit reserved for the power setting in the original codeplug, but as I remember, some codeplug items which were nost used in the original firmware has been "adapted" for a new purpose. So, let's go that way again and steal somewhere a four-bit value. For example, I found the "encrypt" item, which is 8 bits and we know we will NEVER use it for the original purpose - so let's use 4 (or possibly 3 bits and the 4th one will be the original flag one) from it and the worst thing which may happen when somebody loads it to the original firmware will be that some strange encryption will be set and will need to be reset from the CPS...
WIth regards,
Pavel

[VK3KYY]

Radio Check packets are data transmissions like SMS but we do not have any information about how to make the C6000 send or receive SMS.

Also there is very little document action about how SMS is implemented on DMR because I think its a manufacturer specific implementation e.g. by Motorola who do not make information easily available

SMS wuod need to be implemented before Radio Check, and most people told me they would not want the radio to respond to Radio Check data, so even if it was implemented it would be disabled by default.

[VK3KYY]

Power would need to reuse some other data in the codeplug, there are some fields which I don't even think the official firmware uses , e.g. offset freq

[ok1pt]

Radio Check packets are data transmissions like SMS but we do not have any information about how to make the C6000 send or receive SMS.

I was afraid that the RC messages have similar format as SMS, but I didn't know that we don't have enough info to handle them on our chipset.

Also there is very little document action about how SMS is implemented on DMR because I think its a manufacturer specific implementation e.g. by Motorola who do not make information easily available

And what about Brandmeister developers ? BM can handle both formats (Moto & Chinese) and even convert them on the fly, so they probably have something as they programmed it...

SMS wuod need to be implemented before Radio Check, and most people told me they would not want the radio to respond to Radio Check data, so even if it was implemented it would be disabled by default.

Of course making an option allowing/disallowing RC replies would be the easiest part of this task .

OK, so it looks like a really complex challenge, but to have SMS support would be even better than the RC alone . I believe we will be able to reach it!

[ok1pt]

Power would need to reuse some other data in the codeplug, there are some fields which I don't even think the official firmware uses , e.g. offset freq

OK, I understand. So, my proposal is the following:
We currently have 9 power levels. When indexing from 0, the last value is 8. So, let's use the original power level bit for the highest bit of our index. When the codeplug will be loaded to the original FW, 5W will be interpreted as "High" (which is all right) and all the rest as "Low". And let's reserve 3 bits (for example the lowest ones for simplicity now) in the Offset Freq. to store the remaining 3 bits.
Do you think it's reasonable ?

With regards & 73,
Pavel

[YT5HOK]

We currently have 9 power levels.
...

We have 10 power levels, but 10th is hidden.

[ok1pt]

We currently have 9 power levels.
...

We have 10 power levels, but 10th is hidden.

OK, I can see . So let's keep it hidden and allow to store only 8 levels .

[VK3KYY]

And what about Brandmeister developers ? BM can handle both formats (Moto & Chinese) and even convert them on the fly, so they probably have something as they programmed it...

Generally BM does not process any of the DMR data.

The whole BM system, just wraps the "On-air" data protocol in a header which contains the source and destination IDs.

The hotpots like the Jumbospot or even the MMDVM boards which use external analogue FM transceivers, are "dumb" in that all they do is decode the physical layer of 4FSK tones into binary, and then send the raw binary data across the network.

I've looked at the MMDMV source code and the only processing the MMDVM is to decode the Link connect headers, which specify the Source and Destination ID's and (the call type)

The only part of the data that BM modifies is the Talker Alias data, because BM insert the Callsign into one of the TA frames, but TA just re-uses the same part of the DMR signal which also contains the Source and Destination Id. Because there is part of the initial byte that contains a number which indicates whether the shared header field contains Source and Destination Id, or TA.

BM does not process the SMS to transcode between different manufacturers, because the BM network does not know what type of radio is receiving the data.

I guess it would be possible to possibly determine what sort of radio was transmitting the data, but not what type of radio was receiving the data.


I'm not even sure if any of the BM source code is publicly available. There is virtually nothing on their GitHub repo

https://github.com/BrandMeister