Date   

Re: Developments.....

Pierre Martel
 

Hi to all. 

I am one of the admin of the canadian BM server and I also dont get it as Micheal said. 

As all Sysop have access to the dashboard of the repeater on BM they can put any TG as static one on the slot they want. And they can have all the other tg on demand with a simple private call "a la dstar" as when someone send a command to "link" a repeater to a reflector in dstar, we program  the "To" feild of our radio with the desired link LXRF001A or unlink (4000) . The same apply to BM in dmr. You make a privite call on TS1 to 3022 and you are on the 3022 TG and you have 30+ repeater all over the Quebec province ready to send your audio. want a specific repeater, send a private message to 302208 and the repeater you are on will connect to repeater 302208. 

Or even best, ask the repeater owner to be part of a "cluster" and every TG8 activity will be sent to all of the repeater in the cluster as if it was a local call on TS2 

There are so many ways of linking repeaters, I just dont get it why we need another one. BTW all repeater or even user ID can be use as a TG. Just be sure that the user or repeater sysop is ok with that. As if a repeater ID is used as a TG all transmition sent to that TG will also be tranmitted on the repeater also.

Pierre
VE2PF

Garanti sans virus. www.avast.com


Le mar. 28 avr. 2020 à 02:50, VK5ZEA <michaelcarey@...> a écrit :

Hi Everybody,

Good to see more development with MMDVM

I've never quite understood the Talkgroup vs Reflector argument on Brandmeister.  Can someone point out advantages/disadvantages of each for me?

Is the end result (as far as the user goes) not the same.  You can have a group (be it Talkgroup or Reflector based) and when someone talks, everyone else in that group hears them.

Is there any technical advantage of Reflectors over Talkgroups?   I always though because the concept of Talkgroups is built into many of the radios used with MMDVM that it would make sense to use Talkgroups over Reflectors.

Regards,

Michael.
VK5ZEA

On 2/04/2020 2:46 am, Jonathan Naylor via Groups.Io wrote:
Hi Folks

It looks like I have some development time available to me, just like everyone else, the KLX being forced to stay at home for the time being, and no current QRL :-( However I hope to be working in Belgium sometime in the future.... which will also allow me to some development work.

Anyway my current development list is (not in any order):

1. A couple of potential paying projects.

2. A Kenwood to Icom NXDN protocol network bridge to allow the NXCore systems to communicate via software. I may well add the Kenwood networking protocol to the MMXDM to go alongside the already existing Icom protocol within it.

3. An FM repeater controller for the MMDVM. This will be fairly customisable and will run alongside the digital modes, even the Arduino Due could probably run it.

4, A new type of rule for DMR Gateway. I will explain below:

Currently BrandMesiter in the UK is based on reflectors. I personally much prefer reflectors to talk groups. Anyway this facility is being removed from BM by the end of the year. I have therefore been asked to add a new dynamic rule to the DMR Gateway. This would allow for the dynamic mapping of a talk group to a fixed talk group number. For example (and I think I have this right), you would send a transmission to TG9999 to activate TG999 on BM, and the DMR Gateway would then map to TG9 (for example). At a later time a transmission to TG4000 would remove the mapping of TG9999 to TG9 at the DMR Gateway, and also passed to BM to drop the dynamic talk groups.

I think I have that right.

The entry for DMR Gateway would be similar to:

PseudoRef=2,1000,5000,4000,9

Indicating that on slot 2, TGs 1000 to 5000 are dynamic, 4000 disconnects them, and they're mapped onto TG9 when active.

Jonathan G4KLX


Re: Developments.....

VK5LN
 

Hi Everybody,

Good to see more development with MMDVM

I've never quite understood the Talkgroup vs Reflector argument on Brandmeister.  Can someone point out advantages/disadvantages of each for me?

Is the end result (as far as the user goes) not the same.  You can have a group (be it Talkgroup or Reflector based) and when someone talks, everyone else in that group hears them.

Is there any technical advantage of Reflectors over Talkgroups?   I always though because the concept of Talkgroups is built into many of the radios used with MMDVM that it would make sense to use Talkgroups over Reflectors.

Regards,

Michael.
VK5ZEA

On 2/04/2020 2:46 am, Jonathan Naylor via Groups.Io wrote:
Hi Folks

It looks like I have some development time available to me, just like everyone else, the KLX being forced to stay at home for the time being, and no current QRL :-( However I hope to be working in Belgium sometime in the future.... which will also allow me to some development work.

Anyway my current development list is (not in any order):

1. A couple of potential paying projects.

2. A Kenwood to Icom NXDN protocol network bridge to allow the NXCore systems to communicate via software. I may well add the Kenwood networking protocol to the MMXDM to go alongside the already existing Icom protocol within it.

3. An FM repeater controller for the MMDVM. This will be fairly customisable and will run alongside the digital modes, even the Arduino Due could probably run it.

4, A new type of rule for DMR Gateway. I will explain below:

Currently BrandMesiter in the UK is based on reflectors. I personally much prefer reflectors to talk groups. Anyway this facility is being removed from BM by the end of the year. I have therefore been asked to add a new dynamic rule to the DMR Gateway. This would allow for the dynamic mapping of a talk group to a fixed talk group number. For example (and I think I have this right), you would send a transmission to TG9999 to activate TG999 on BM, and the DMR Gateway would then map to TG9 (for example). At a later time a transmission to TG4000 would remove the mapping of TG9999 to TG9 at the DMR Gateway, and also passed to BM to drop the dynamic talk groups.

I think I have that right.

The entry for DMR Gateway would be similar to:

PseudoRef=2,1000,5000,4000,9

Indicating that on slot 2, TGs 1000 to 5000 are dynamic, 4000 disconnects them, and they're mapped onto TG9 when active.

Jonathan G4KLX


NXR-800

Jonathan Naylor
 

Could the person who emailed me about his NXR-800 NXDN repeater please contact me again. I've lost your email and wanted to reply to you.

Jonathan  G4KLX


The New MMDVM FM Repeater Controller

Jonathan Naylor
 

Hi Folks

As you may be aware an FM repeater controller has been added to the MMDVM. Most of the processing is done in the firmware with the host only providing the initialisation information, which is different from how the other modes operate. At some stage, we will be offering network access to the repeater and then it'll be more like the other modes.
 
Before I start explaining how to use the repeater I must point out that it takes a lot more configuration than the digital modes. Most of the digital modes are pretty flexible regarding their input levels, the FM repeater isn't. There are also tone levels to set up, and this can best be done with either proper test equipment or some for of SDR so that the spectrum and deviation can be compared.
 
With that out of the way, onto the details. Currently the repeater is available in the FM branches of the firmware and the host. They are dated 20200426 or later. We have had the repeater running Arduino Due's and STM32 M7 hardware, and it certainly loads onto an NXP M4 (Teensy 3.6), but not tested on that platform.
 
Ideally this controller should be run with a hardware COS line wired into the controller, but it will work without so existing systems should be able to go FM with relatively little work, especially since most of us can't easily leave our homes.
 
Once the firmware has been loaded, you will need to add some extra information to your MMDVM.ini, or use the one in GitHub as a basis for your system. In the Modem section the TXLevel and RXLevel values also apply to the FM repeater. Like the other modes, it is possible to override the TXLevel parameter for FM only with an optional FMTXLevel parameter. The Callsign and Timeout values in the General section also apply to the FM controller, but these may be overridden in the FM controller configuration.
 
Now to the FM repeater configuration. Here is the one in the example MMDVM.ini:
 
[FM]
Enable=1
# Callsign=G4KLX
CallsignSpeed=20
CallsignFrequency=1000
CallsignTime=10
CallsignHoldoff=0
CallsignHighLevel=50
CallsignLowLevel=20
CallsignAtStart=1
CallsignAtEnd=1
RFAck=K
# NetAck=N
AckSpeed=20
AckFrequency=1750
AckMinTime=4
AckDelay=1000
AckLevel=50
# Timeout=180
TimeoutLevel=80
CTCSSFrequency=88.4
CTCSSThreshold=30
CTCSSLevel=20
KerchunkTime=0
HangTime=7
UseCOS=1
RXBoost=1
MaxDevLevel=90
 
Firstly, Enable=1 switches on the FM controller. If you set this to 0 then you may as well stop reading this message!
 
The Callsign here, which is commented out in this example, is the callsign to be used for all CW Id's from the FM controller. In the UK it is common to include a letter after the callsign to indicate the CTCSS frequency in use so a suitable callsign value might be G4KLX B. If this is not set then the callsign from the General section will be used.
 
The CallsignSpeed is the speed of the CW callsign in Words per Minute. The CallsignFrequency is the tone frequency of the callsign in Hertz. The CallsignTime is the interval between callsign transmitted when the FM repeater is in operation, in minutes. Note that CW callsigns transmitted when the FM controller is not active are handled in the same way as before by the MMDVM. The CallsignHoldoff is the time interval, in minutes, that the callsign will be suppressed after the last callsign has been transmitted. A value of 0 means that no callsign suppression happens and all callsigns are transmitted.
 
The CallsignHighLevel is the percentage of the maximum output level that a full deviation callsign is sent at, this is typically when the repeater is shutting down. The CallsignLowLevel is the percentage of the maximum output level that a low deviation callsign is sent at which happens at all other times. The CallsignAtStart and CallsignAtEnd control whether a callsign is transmitted when the repeater is opened up, and when it closes down respectively.
 
RFAck is the normal acknowledgement signal sent between overs, usually indicating that the timeout timer has been reset. It is usually a K in morse, or an E for a short pip, or a T for a longer bleep. The NetAck value is not used yet, but will be used for incoming network audio. The settings for the AckSpeed, the AckFrequency and AckLevel are similar to their callsign equivalents. There is only one deviation setting for the ack, and any incoming transmission when the ack is being sent will cause the ack to stop being transmitted.
 
The AckMinTime is the minimum time in seconds for an incoming transmission to be received before an ack will be generated once it ends. This stops people kerchunking the repeater to generate a series of K's for example. A value of 0 for this parameter would allow an ack to be generated in all cases. The ack delay is the amount of time, in milliseconds, between the end of an incoming transmission and the ack being transmitted, or if suppressed by the AckMinTime setting, reset the timeout etc.
 
The Timeout value is in seconds and this overrides the value in the General section for the FM controller only. A value of 0 disables the timeout function. The TimeoutLevel is the audio level as a percentage, of the busy tone used by the repeater to indicate that a user has timed out, it takes the form of a telephone busy signal, European style.
 
The CTCSSFrequency is the frequency used to access the repeater in Hertz. Only the fifty docuemnted CTCSS tone values are allowed here. This tone is both used to detect incoming transmissions and is added to outgoing transmissions. The CTCSSThreshold is the way to control how sensitive the CTCSS decoder is, too low a vaue will cause it to trigger on noise, too high and no one will be able to access your repeater. This is a trial and error setting. The CTCSSLevel is the percentage of the full output level that the CTCSS tone is added to the transmission, this is usually a very low value.
 
The KerchunkTime controls how long the initial transmission must be to open the repeater fully, it is in seconds. The repeater will still relay during the kerchunk time, but will not stay open if the transmission ends before the full time has been reached.
 
The HangTime controls the amount of time, in seconds, between when the last ack occurs and the repeater closing down if no further activity takes place.
 
UseCOS is used to indicate that the COS line coming into the hardware is valid to use to indicate an incoming transmission. It is used in conjunction with the CTCSS decoder to determine a valid signal, working without means that there will be a squelch tail on incoming transmissions as it takes a finite time for the CTCSS decoder to determine that the incoming signal is no longer there.
 
RXBoost is used to increase the level of the received audio from the user into the repeater. This allows the system to be used with the correct settings for the digital modes, but then allowing for the FM audio to be increased to a more usable level without upsetting the other modes. This value is a multiplier, 1 means no change, 2 means double the amplitude, etc. A value of 0 would make your repeater very quiet indeed!
 
MaxDevLevel is the amplitude in percent above which an incoming signal is deemed to over deviating and the controller will take action. What is does is to blank the audio for 500ms and insert a 100ms 2kHz pip, this will hopefully avoid an overdeviating signal from causing your repeater to also overdeviate. This can be disabled by seting it to 0. The audio level of this pip is the same as set above for the timeout tone.
 
I am sure that there's more to say, but for now this should allow people to test it out. There will be further changes as bugs are found (or added) and additional features added.
 
Jonathan  G4KLX
 


Re: DMR Gateway dynamic talk group rewriting

rafaelgcpp@...
 

Hi Jonathan,

Congratulations on the new rewriting rule! Could it be chained to the TGRewriteRule?

Let me explain:

In my area, we have a DMR+ master, and my radio is configured for all local talkgroups (724, 72411, 72421...). So, I set DMRGateway to PassAllTG on the DMR+ section.

On the other hand, I'd like to map my BM talkgroups to 4000000 (31621 -> 4031621), and TGDynRewrite would be perfect for that, so that I would only have to setup a channel for, say, TG4.

I tested putting both rules, but it did not work, as the TGRewrite reassiged the TG to the new range, but then TGDynRewrite could not rewrite it to TG4, as it did not run...

Maybe could it be implemented as the PCRewrite/SrcRewrite?

Best Regards

Rafael Pinto (PU1OWL)


Re: shutdoRE: [OpenDV] Developments.....

Phil M0VSE
 

Hi all.

 

Well I found the problem, if you enter any other CTCSS frequency than the default of 88hz, MMDVM crashes!

 

73 Phil

 

From: Phil M0VSE <phil@...>
Sent: 20 April 2020 19:01
To: 'OpenDV@groups.io' <OpenDV@groups.io>
Subject: shutdoRE: [OpenDV] Developments.....

 

Hi Jonathan.

 

I have been trying to get the FM branch to work but there seems to be something “amiss”.

 

Not sure what hardware you have tested it on but on my v1.0 MMDVM-Pi  (STM32F7xx based) as soon as I start MMDVMHost with FM enabled, the MMDVM goes into TX and crashes. I need to press the reset button to get it running again.

 

All other modes work fine still with FM disabled.

 

At first I wondered if the CTCSS decoder was triggering on white noise as by default I run the Tait TB7100 repeater with open squelch so I tried enabling squelch and it still does the same.

 

Any ideas?

 

73 Phil M0VSE

 

From: OpenDV@groups.io <OpenDV@groups.io> On Behalf Of Phil M0VSE via groups.io
Sent: 19 April 2020 23:53
To: OpenDV@groups.io
Subject: Re: [OpenDV] Developments.....

 

Hi Jonathan.

 

I have a test repeater here that I use for development with a Zum MMDVM-Pi board so I will have a play!

 

73 Phil M0VSE

 

From: OpenDV@groups.io <OpenDV@groups.io> On Behalf Of Jonathan Naylor via groups.io
Sent: 19 April 2020 22:02
To: OpenDV@groups.io
Subject: Re: [OpenDV] Developments.....

 

Things have moved on a little. I've been busy.

1. The Icom to Kenwood NXDN gateway is close to being finished, unfortunately a lot of it is guesswork and it hasn't been used in anger yet. Indeed as part of testing I have added the Kenwood protocol alongside the Icom one in my NXDN Gateway program. The default is Icom as now, but Kenwood can be specified, and it may even work. I have done some desk testing and it looks approximately right. However plugging it into a Kenwood repeater would be the best test.

2. There have been some enhancements to the DMR Gateway. It can now be sort-of controlled externally, so that scripts can interrogate the BM API and ensure that the DMR Gateway is always in the correct state. These scripts are not yet included with the DMR Gateway, but once finished they will be. I have also modified the gateway so that any voice message doesn't interfere with incoming network audio if it appears during the time for the voice message.

3. The FM Repeater is now code complete, however testing is in the very early stages, and to be honest it's making a wretched noise! However Geoffrey F4FXL is testing it on his local repeater, F5ZEE and together we will get it working. More news as it happens will appear here. The fun can be found on the FM branches of the host and the firmware, but only play with it if you feel happy reading/debugging C++ code, otherwise leave well alone.

That's about it for now.

Jonathan  G4KLX


Re: Developments.....

Steve, KB9MWR
 

Jonathan,

I made a post a while back about trying to find someone to work on improving the existing opensource AMBE vocoder that we have (a solution for those who host cloud based bridges). I'm willing to donate either an AMBE hardware dongle or the equivalent money to someone willing to work on this.

I think this is outside of your areas of expertise though, but please spread the word to anyone who you might know who would might be able to help.

Thanks
Steve, KB9MWR


Re: Developments.....

Phil M0VSE
 

Hi Jonathan.

 

I have been trying to get the FM branch to work but there seems to be something “amiss”.

 

Not sure what hardware you have tested it on but on my v1.0 MMDVM-Pi  (STM32F7xx based) as soon as I start MMDVMHost with FM enabled, the MMDVM goes into TX and crashes. I need to press the reset button to get it running again.

 

All other modes work fine still with FM disabled.

 

At first I wondered if the CTCSS decoder was triggering on white noise as by default I run the Tait TB7100 repeater with open squelch so I tried enabling squelch and it still does the same.

 

Any ideas?

 

73 Phil M0VSE

 

From: OpenDV@groups.io <OpenDV@groups.io> On Behalf Of Phil M0VSE via groups.io
Sent: 19 April 2020 23:53
To: OpenDV@groups.io
Subject: Re: [OpenDV] Developments.....

 

Hi Jonathan.

 

I have a test repeater here that I use for development with a Zum MMDVM-Pi board so I will have a play!

 

73 Phil M0VSE

 

From: OpenDV@groups.io <OpenDV@groups.io> On Behalf Of Jonathan Naylor via groups.io
Sent: 19 April 2020 22:02
To: OpenDV@groups.io
Subject: Re: [OpenDV] Developments.....

 

Things have moved on a little. I've been busy.

1. The Icom to Kenwood NXDN gateway is close to being finished, unfortunately a lot of it is guesswork and it hasn't been used in anger yet. Indeed as part of testing I have added the Kenwood protocol alongside the Icom one in my NXDN Gateway program. The default is Icom as now, but Kenwood can be specified, and it may even work. I have done some desk testing and it looks approximately right. However plugging it into a Kenwood repeater would be the best test.

2. There have been some enhancements to the DMR Gateway. It can now be sort-of controlled externally, so that scripts can interrogate the BM API and ensure that the DMR Gateway is always in the correct state. These scripts are not yet included with the DMR Gateway, but once finished they will be. I have also modified the gateway so that any voice message doesn't interfere with incoming network audio if it appears during the time for the voice message.

3. The FM Repeater is now code complete, however testing is in the very early stages, and to be honest it's making a wretched noise! However Geoffrey F4FXL is testing it on his local repeater, F5ZEE and together we will get it working. More news as it happens will appear here. The fun can be found on the FM branches of the host and the firmware, but only play with it if you feel happy reading/debugging C++ code, otherwise leave well alone.

That's about it for now.

Jonathan  G4KLX


Re: Developments.....

Phil M0VSE
 

Hi Jonathan.

 

I have a test repeater here that I use for development with a Zum MMDVM-Pi board so I will have a play!

 

73 Phil M0VSE

 

From: OpenDV@groups.io <OpenDV@groups.io> On Behalf Of Jonathan Naylor via groups.io
Sent: 19 April 2020 22:02
To: OpenDV@groups.io
Subject: Re: [OpenDV] Developments.....

 

Things have moved on a little. I've been busy.

1. The Icom to Kenwood NXDN gateway is close to being finished, unfortunately a lot of it is guesswork and it hasn't been used in anger yet. Indeed as part of testing I have added the Kenwood protocol alongside the Icom one in my NXDN Gateway program. The default is Icom as now, but Kenwood can be specified, and it may even work. I have done some desk testing and it looks approximately right. However plugging it into a Kenwood repeater would be the best test.

2. There have been some enhancements to the DMR Gateway. It can now be sort-of controlled externally, so that scripts can interrogate the BM API and ensure that the DMR Gateway is always in the correct state. These scripts are not yet included with the DMR Gateway, but once finished they will be. I have also modified the gateway so that any voice message doesn't interfere with incoming network audio if it appears during the time for the voice message.

3. The FM Repeater is now code complete, however testing is in the very early stages, and to be honest it's making a wretched noise! However Geoffrey F4FXL is testing it on his local repeater, F5ZEE and together we will get it working. More news as it happens will appear here. The fun can be found on the FM branches of the host and the firmware, but only play with it if you feel happy reading/debugging C++ code, otherwise leave well alone.

That's about it for now.

Jonathan  G4KLX


Hotspot usage

Jonathan Naylor
 

This message contains important information that I want disseminated far and wide please.

I have been approached by the people who run aprs.fi and REF001/REF030 (not the same people) about problems being caused by hotspots. This is down to usage and I hope that people will act on this information:

1. APRS, it is important that when configuring your hotspot, that you ensure that the suffix used for accessing aprs.fi is unique. For example if you use more than one hotspot, then ensure that for every mode and for every hotspot, the aprs.fi access callsign is unique. This is usually done by specifying a unique suffix to the callsign used by the hotspot. If more than one hotspot attempts to access aprs.fi with the same callsign+suffix combination, the first one is thrown off, and the new one connects. In the meantime the original one tries to connect and throw the new one off. This can happen multiple times per second, and is causing problems for them. Please, please, please, look at your configurations and if you have a duplicate, change one of them.

2. REF001/REF030, apparently the network load on these D-Star reflectors is now very high due to the number of hotspots connecting and staying connected. Could you please consider changing your gateway configuration so that you disconnect after a certain period of inactivity (this means local RF activity) so that they aren't overloaded. I know we like to listen out for activity, but we must also realise that D-Star popular reflectors const money to run, and that includes network and processor usage. A quick look at their dashboards will reveal the problem, they're huge.

Jonathan  G4KLX


Re: Developments.....

Jonathan Naylor
 

Things have moved on a little. I've been busy.

1. The Icom to Kenwood NXDN gateway is close to being finished, unfortunately a lot of it is guesswork and it hasn't been used in anger yet. Indeed as part of testing I have added the Kenwood protocol alongside the Icom one in my NXDN Gateway program. The default is Icom as now, but Kenwood can be specified, and it may even work. I have done some desk testing and it looks approximately right. However plugging it into a Kenwood repeater would be the best test.

2. There have been some enhancements to the DMR Gateway. It can now be sort-of controlled externally, so that scripts can interrogate the BM API and ensure that the DMR Gateway is always in the correct state. These scripts are not yet included with the DMR Gateway, but once finished they will be. I have also modified the gateway so that any voice message doesn't interfere with incoming network audio if it appears during the time for the voice message.

3. The FM Repeater is now code complete, however testing is in the very early stages, and to be honest it's making a wretched noise! However Geoffrey F4FXL is testing it on his local repeater, F5ZEE and together we will get it working. More news as it happens will appear here. The fun can be found on the FM branches of the host and the firmware, but only play with it if you feel happy reading/debugging C++ code, otherwise leave well alone.

That's about it for now.

Jonathan  G4KLX


Re: linking vs linked

Ken Jamrogowicz
 

I think what is happening is the reflector at the other end is disconnecting me due to some timeout - either inactivity (sadly) or simply total amount of time connected. Not every reflector does this.
If I disconnect from my end (already disconnected from the other end) and connect to something else, it works.  Then I can usually connect back to the reflector that disconnected me.

If this is the way it works, I am OK with that.

Question: is there a way to use the remote control app (or other technique) to automatically make or change ircDDB gateway connections on a time schedule? 
I know how to do this with an ICOM G3 gateway, but I have not found how to do it with the ircDDB gateway daemon.

Ken


Re: Developments.....

M6NBP Norman
 

A good friend made this up for me.

Looking good on this Document
http://hamradio.joomla.com/images/PDF/Linking_to_Gateway_Dynamic_Talk_Groups.pdf

Norman 73


Re: Developments.....

M6NBP Norman
 
Edited

Hi Jonathan

We ran it last night and it was working 100%
Have set for 90 to 999999

The only issue was Static Talk Group and this falls under what Simon is working on.
TGRewrite=2,9,2,23510,1
So if I am on XYZ Talk Group it all worked until, via the net 23510 was used and then my end reverted back to the static 23510.

Simple to setup up on Pi-Star and nice clean rules for both slots if I wished to use.


I have made this doc up for GB7BC users to read and give feedback on what they think, regarding using it on the repeater.
http://hamradio.joomla.com/images/PDF/Linking_to_Gateway_Dynamic_Talk_Groups.pdf

Thank you so much for all that you do.

 

Norman 73

 


Re: Developments.....

Jonathan Naylor
 

Hi Norman

That's the idea, which is why choosing the Talk Group is via a Private Call. In fact I've expanded it to allow almost all of the functions to be either a Talk Group or a Private Call now.

In fact I've updated DMR Gateway again to improve the functionality. Firstly you can have multiple copies of the dynamic rewrite that will announce correctly whereas before they shared the same voice generator.

More importantly, it is now possible to set the dynamic Talk Groups to be a very wide range, and add exceptions as needed. If you look at the example ini file, you will see a rule that covers TG 90 to TG 999999 with exceptions for 4000 and 5000 as you would expect as they have special functionality, and also 9990 which is now listed at the end of the configuration line. You can have as many Talk Groups/Private Calls listed at the end which are outside of the dynamic Talk Group processing.

GitHub has been updated and the version is now 20200408.

Jonathan  G4KLX


On Friday, 3 April 2020, 11:19:34 BST, M6NBP Norman <brightonirish@...> wrote:


[Edited Message Follows]

Hi Jonathan

Can I request that you can call a Talk Group via Manual Dial Private Call.
This would mean a new read write for Private Call 1 to 99999 apart for 9990 echo to read write to Group Call and call a Talk Group.

Most DMR radios you can do Manual dial a Private Call.
Newer radios like a the Anytone you can do Manual dial a Group Call and Private Call.

It would need to be up to 6 digit numbers so it does not change users 7 dig IDs and prevent Private Call.

 

Many thanks for all your hard work.

 

Norman 73

 


Re: DMR Gateway dynamic talk group rewriting

M6NBP Norman
 

I can not get 4000 unlink or 5000 status to go back out on TG9
We have that working now at this end :)

Norman 73


Re: DMR Gateway dynamic talk group rewriting

Simon
 

I'll get back on the case Norman. I have been pleasantly distracted by a new 4m radio and antenna this weekend ;-)

73

Simon


On 06/04/2020 20:41, M6NBP Norman wrote:
Talk Groups time out at 10 mins

This is why we need what Simon is working on


Norman 73



Re: DMR Gateway dynamic talk group rewriting

M6NBP Norman
 

I can not get 4000 unlink or 5000 status to go back out on TG9
Always comes back to me

Anyway to make this happen ??

 

Norman


Re: DMR Gateway dynamic talk group rewriting

M6NBP Norman
 

Talk Groups time out at 10 mins

This is why we need what Simon is working on


Norman 73


Re: DMR Gateway dynamic talk group rewriting

Dominic
 

Looks like a good mechanism to mimic reflector operation.

How long will they remain connected, I'm gathering only a short amount of time compared to the existing reflector system?

Dom G7NPW


On 06/04/2020 18:17, Jonathan Naylor via groups.io wrote:
Hi Folks

After working with Jon G4TSN with beta versions of this new rewrite rule for the DMR Gateway, it has now been merged into master and available for all to play with. This allows for the use of pseudo reflectors once the existing reflector functionality is removed from BrandMeister. Of course this may be used with other networks too. The new rule looks like:

TGDynRewrite=2,23500,4000,5000,9,100

This means that a group of dynamic talk groups can be mapped to a single talk group, along with voice acknowledgements and control over which one is being used. The configuration line means the following:

The 2 means using slot 2 for all of the following talk groups and private calls.
The 23500 is the first of the dynamic talk groups, and the 100 at the end is the number of talk groups from that number to use. This maps talk groups 23500 to 23599 in this example. These are triggered by sending a private call to the desired talk group number. This cases a spoken confirmation to be transmitted.
4000 is the private call number to disconnect the dynamic talk group. This causes a spoken confirmation to be transmitted.
5000 is the private call number to cause the current talk group mapping information to be spoken.
9 is the talk group to be used for all communications to the selected dynamic talk group, as well as the voice messages.

The reason for using private calls is the ability of many radios to have front panel programming so the dynamic talk group numbers can be done manually or programmed on your radio.

I hope people find this useful. It's possible that more work using the BM API will need to be added externally to the DMR Gateway, but that is an area for other people to investigate.

Jonathan  G4KLX

_._,_._,_



1281 - 1300 of 1433