Hi Christian,
I can confirm that -h works - stupid error on my side.
My trunk mode repeater is running for evereral days now and only once
needed a restart for unknown reason.
Roaming between two tier II repeaters (DB0BR/DM0BT) here in Bayreuth and
my Tier III repeater at home works flawlessly.
Registraration: ok
Talkgroup Attachment works. I programmed button TK1 with "Scan Group
List" to get rid of annoying ongoing background calls if I want to talk
on my selected talkgroup. Unfortunately, I cannot find any indication in
the UI of the radio if the scan group list feature is on or off. In
dmrtc, you can see additional TGs being subscribed once the feature is
active.
I have make quite a few QSOs with a local OM working on a Brandmeister
DMR repeater near Kulmbach - works flawlessly.
Great, thanks for letting me know. I'll put your radio model in the list as
supported now.
Private Voice calls: Had not yet had an opportunity for thourough
testing. The terms OACSU and FOACSU are nowhere to be found in my CPS.
I did test a lot calling 9990 on brandmeister. I can say that this only
works sometimes, but unreliably, and usually with very bad audio
quality. weird.
Private calls are a bit of a problem, same as private SMS, from a routing
perspective. If you have only one DMR system (eg. Brandmeister) connected,
private calls can be passed on using PassAllPC in DMRGateway.ini for that
network configuration.
The situation gets trickier if you are connected to multiple systems (DMR+,
Brandmeister, etc.). Then it is pretty much impossible to know where a
particular private call should be routed to. This is a pretty bad limitation
of the current system that needs to be worked on in the future, but I'm open
to pretty much any architecture changes that enable more features.
SMS: No test yet. Try to send me one: DB9CR, my device is logged in most
of the time I am at home in homeoffice.
SMS should only work between two Tier III sites and radios, the UDT message
protocol is only standardized in TS 102 361-4 so Tier II radios will not be
able to receive them. In addition, I remember that I needed to modify
something in MMDVMHost for UDT short data message support, so classical
hotspots might not even be able to pass them on to RF.
I'm not sure what the situation is on the reflector software side and if it
will support passing through this type of messages. Brandmeister may be able,
other networks may not. So needs further testing and maybe additional code.
Also the rest of the items still needs some testing.
I did have a chat with Ralph DK5RAS - he pointed me to
Seems to me that this could completey replace the ugly^h^h^h^hcreative
:-) multi DMRgatway setup. Technically it's probably a SIP trunk with
AMBE2 codec, but I did not have a chance to look at the relevant
original DMRA paper
(). Will
try to dig deeper into this. Also, having a generic SIP implentation
could make it possible to attach to an asterisk VOIP server - we have
one here on db0bt.ampr.org in the HAMNET.
Yes, that seems like the ideal. Unfortunately other DMR networks don't support
this system, and many people use other networks, myself included. It would be
nice it there was some standards group among us amateurs that aimed at
compatibility between implementations.
Anyway there is really no need for complications like a SIP trunk. A simple
limitation being removed on the reflector side would be enough. And that
limitation is the blocking at reflector-side of any calls coming on a timeslot
if there is already a call ongoing in that timeslot. Then you can define one
Tier III site as one connection only. A call is basically a sequence of UDP
packets with a stream id, and as long as you have enough bandwidth there is no
reason not to have hundreds of calls at the same time on one UDP socket
connection.
73, Adrian
