MMDVMHost
MMDVMHost copied to clipboard
g4klx
OVCM - actual implementation has severe issues and does not really work
Hi,
after testing a lot we found that the actual OVCM implementation has some severe issues and does not work anyway - fist the issues, what is more critical :)
It appears that also in DMR traffic from an OVCM enabled hotspot to the net something is changed, but not the right thing. This has the effect that receiving Motorola radios do not decode, or only decode for a fraction of a second and then go mute. This only can be overcome by setting OVCM=0 in the ini. This issue is critical as it breaks some connections, and almost nobody makes the connection that the combination Moto radio with OVCM MMDVM is the cause.
Now about functionality:
When I listen on an OVCM enabled MMDVM repeater to its transmissions with an OVCM radio and empty RX group list, I get a short audio fragment, then the radio mutes again. It appears the OVCM bit is only present in the first frame, then not any more. Also no late entry is possible. When the same radio receives directly from a correct OVCM implementation, audio stays on, the talk group stays in the display for the configured hang time, and one can reply into this TG. As intended. Also late entry works as intended, as the OVCM signaling is present during the whole transmission.
We will try to see if we find something, but maybe Jonathan or some other skilled coders will find the last quirks with this description :)
Thanks a lot for all the great work you all are doing here, we users and repeater and master sysops highly appreciate this fantastic software!!!
I have looked at the MMDVM code and the LC data with IVCM enabled is carried by the header and by the the embedded LC sent for the duration of the transmission so it should still be active for late entry. I need someone to look at the data going to the modem to check that the embedded data is correct and that the OVCM bit is present.
This would not be difficult to do but would require time, of which I have very little. We need people who are happy to get into the guts of DMR and analyse the data being sent out looking for bugs. Sorry I can't be more helpful but I only have limited time available.
Sure, time is also our issue :) I am so far in the guts of DMR, but I am not in the guts of C/C++ :)
I have changed the software to switch OVCM off by default when there is no OVCM option in the ini file. If it worked I would like it to be on by default, but it is not a good idea at the moment.
I've added a pull request for adding also the OVCM bit in the two supported CSBKs: "Unit to Unit Voice Service Request CSBK" and "Unit to Unit Voice Service Answer Response CSBK". But this still does not fix the problem which @dk5ras has. As I'm also working on the MMDVMSdr, I've a running system, where I could debug if the bit is also available in the MMDVM. I also wanted to see if I could borrow a test device from work to analyze the complete signal including the protocol.
You can easily dump out the data sent to the modem by the use of configuration options and then you can see the transmitted bits. In addition you can sprinkle dump commands in the code to supply the unencoded LC data which would be a good way to see if the bit is set at the beginning of the process of encoding it.
Incoming traffic from the net, sent out by the MMDVM on RF, looks good now, OVCM works as intended. Amazing! The outgoing variant I did not yet check in all combinations, but it looks good.
One conversation came in weird, a guy with a GD-77 was shown as phone call, however another guy on the same repeater with MD-380 came with normal OVCM mode, so I assume it is some issue with the GD-77.
I will look into the dumping options when I have some more continuous time chunks available :) This is nothing to do on the go...
But this still does not fix the problem which @dk5ras has.
So it actually did fix the problem. Great to hear that. :)
I split up the configuration for setting the OVCM bit in TX and RX direction. I couldn't check it here, but @dk5ras reported,that this somehow does not work and still sends the bit to the network... I will do a push request. Maybe you see where I've been wrong...
I changed the code so that the OVCM bit is only SET when configured for this direction, but is never UNSET if received over RF or network. This is currently as a pending pull-request. What are the remeining problems or open questions?
@maierp Does it mean your previous pull request that split up the configuration for setting the OVCM bit is not solving your problem and do we still need keep that 2 configurations there ?
I discovered OVCM started to misbehave since several months. I bet it worked well at least in March. When its value is enabled (1 or 3) in /etc/mmdvmhost, only the first second (or half) of the transmission can be heard, like the respective flag would be transmitted only in the beginning. Switching to a channel with an ongoing conversation doesn't show anything at all.
I use Pi-Star 4.1.5, MMDVMHost version 20210617_PS4 git #9106fd6.
There is a workaround with choosing a BM master server with OVCM enabled by default (2621 for example) - in such case OVCM transmissions are received smoothly regardless of mmdvmhost settings.
R9XBC figured out the issue with only hearing a half second of the transmission in OVCM=1 mode disappears when DMR EmbeddedLCOnly mode is enabled -- when TA and GPS data are disabled. I just tested it out and I can confirm this dependency.
That makes no sense protocol wise. I wonder if it's a bug in the radio firmware?
On Friday, 24 June 2022, 15:04:45 BST, Inga Muste ***@***.***> wrote:
R9XBC figured out the issue with only hearing a half second of the transmission in OVCM=1 mode disappears when DMR EmbeddedLCOnly mode is enabled -- when TA and GPS data are disabled. I just tested it out and I can confirm this dependency.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Also possible. No issues with Hytera as I have heard.
I started experiencing the issue since last spring and I always keep the firmware of my Moto radios up to date.
Will try with both TA and OVCM TX between radios, without MMDVM.
I can confirm there are no issues when calling between two Motorola radios in simplex with both OVCM TX and TA enabled. So it may be in MMDVMHost though.
I need someone to try and find the problem at the protocol level for me to be able to do anything about it. There is something else going off here. According to the specification the OVCM exists in certain CSBKs and also in the Header and Terminator LC blocks. In all cases I think I am setting them correctly. I need considerably more information about this before I can do any more.
On Monday, 27 June 2022, 20:32:27 BST, Inga Muste ***@***.***> wrote:
I can confirm there are no issues when calling between two Motorola radios in simplex with both OVCM TX and TA enabled. So it may be in MMDVMHost though.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Hi @g4klx,
Are there any news about putting both OVCM and TA together?
Thank you!
Since I have no radio capable of TA, this requires someone else to work on it. The MMDVM is volunteer led development, so improvements and fixes depend on people making contributions, and not just demanding answers. On Monday, 2 January 2023 at 14:02:42 GMT, Inga Muste @.***> wrote:
Hi @g4klx,
Are there any news about putting both OVCM and TA together?
Thank you!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>