Date   

Re: The New MMDVM FM Repeater Controller

Jonathan Naylor
 

Hi Waldek

That is exactly what I was thinking. I am not sure I will be writing the gateway program for FM, just the host part, and some of the firmware part. I am sure someone else, or a group of people, will do the gateway portion when the rest is ready. The audio will probably be sixteen bit samples at 8 kHz sample rate, but other bit widths and  sample rates could easily be supported in the gateway.

Jonathan  G4KLX


On Thursday, 30 April 2020, 12:55:56 BST, Waldek SP2ONG <sp2ong@...> wrote:


[Edited Message Follows]

Congratulations, a very interesting idea with support for FM Analog in MMDVM and MMDVMHost.

Perhaps, as for DV, we could add sections

[FM Network]
Enable = 1
Localaddress = 127.0.0.1
#LocalPort = 3200
GatewayAddress = 127.0.0.1
GatewayPort = 5100
Debug = 0

In Europe and not only a very popular solution is based on SVXLink https://github.com/sm0svx/svxlink which also has SVXRefelctor https://github.com/sm0svx/svxlink/tree/master/src/svxlink/reflector

Probably we would need SVXGateway program (like YSFGateway etc) that connects MMDVMHost FM Network with SVXReflector just like in DV.

SVXGateway.ini

[FM network]
PORT=5300
HOST=192.168.1.2
CALLSIGN=N0CALL
AUTH_KEY="Password"
#JITTER_BUFFER_DELAY=0
DEFAULT_TG=260
MONITOR_TGS=112,260,261
TG_SELECT_TIMEOUT=30
ANNOUNCE_REMOTE_MIN_INTERVAL=900





Re: The New MMDVM FM Repeater Controller

SP2ONG Waldek
 

Example working Dashboard of SVXReflector for FM Network:

https://svxportal.sm2ampr.net/


Re: The New MMDVM FM Repeater Controller

SP2ONG Waldek
 
Edited

Congratulations, a very interesting idea with support for FM Analog in MMDVM and MMDVMHost.

Perhaps, as for DV, we could add sections

[FM Network]
Enable = 1
Localaddress = 127.0.0.1
#LocalPort = 3200
GatewayAddress = 127.0.0.1
GatewayPort = 5100
Debug = 0

In Europe and not only a very popular solution is based on SVXLink https://github.com/sm0svx/svxlink which also has SVXRefelctor https://github.com/sm0svx/svxlink/tree/master/src/svxlink/reflector

Probably we would need SVXGateway program (like YSFGateway etc) that connects MMDVMHost FM Network with SVXReflector just like in DV.

SVXGateway.ini

[FM network]
PORT=5300
HOST=192.168.1.2
CALLSIGN=N0CALL
AUTH_KEY="Password"
#JITTER_BUFFER_DELAY=0
DEFAULT_TG=260
MONITOR_TGS=112,260,261
TG_SELECT_TIMEOUT=30
ANNOUNCE_REMOTE_MIN_INTERVAL=900





DummyRepeater??

Dave, KI7VLV
 
Edited

Good day,

Is this forum supporing the (Linux) DummyRepeater? I once had a Windows version (last year) that I was able to connect my ID-51A p2 via USB. I'm on Linux now. I hope this DummyRepeater is still it.

YIkes. I step away from DV for just a little while to rear children and come find yahoo groups shutdown, github the new source and documentation on
http://db0fhn.efi.fh-nuernberg.de/doku.php?id=projects:dstar:ircddb:ircddb-lin-g4klx
a little out of date. Direct from the ircddb website. :-)

(2) I managed to compile and install the Gateway just fine.

Now I'm on to DummyRepeater.

I am receiving compile errors on a Debian distro. The github docs indicate 'wiringpi' is not needed for NON-Pi installs. ' fatal error: wiringPi.h: No such file or directory'
Yet I am receiving the compile errors below. 'wiringpi' package is also not found in repositories.

Please advise and 73,
Dave KI7VLV

<------- GPIOControllerBase.cpp:24:10: fatal error: wiringPi.h: No such file or directory 24 | #include | ^~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:18: GPIOControllerBase.o] Error 1 make[1]: *** Waiting for unfinished jobs.... GPIOController.cpp:16:10: fatal error: wiringPi.h: No such file or directory 16 | #include | ^~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:18: GPIOController.o] Error 1 g++ -MM -O2 -Wall -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -DWXGTK -pthread -DGPIO Utils.cpp > Utils.d g++ -MM -O2 -Wall -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -DWXGTK -pthread -DGPIO UDPReaderWriter.cpp > UDPReaderWriter.d g++ -MM -O2 -Wall -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -DWXGTK -pthread -DGPIO URIUSBController.cpp > URIUSBController.d make[1]: Leaving directory '/home/d/Downloads/DummyRepeater-master/Common' make: *** [Makefile:20: Common/Common.a] Error 2
<--------------


Re: Developments.....

Peter VK2MPJ
 

Why all the muck around with the private call though? What am I missing here.


Whether on BM or DMR+, group call the desired TG and it is linked as a dynamic TG to the repeater or hotspot. 
When finished, you can disconnect or let the inactivity timer take care of it?

I and many that I know have the TGs that I like to use programmed in as a channels in my code plug, I simply switch to that channel, and key up. Boom, TG linked and I keep talking on that same channel.
The most frequently used are set as static.

Anyway, thanks to the gurus doing the work in the background. I look forward to seeing the finished additions. 

Pete
VK2MPJ

On 29 Apr 2020, at 11:34 am, Pierre Martel <petem001@...> wrote:

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





MMVMHost and MMDVM build on the new Buster OS for raspberry pi

PAUL PHILLIPS
 

Hi All

With the new Buster OS for raspberry pi.  I wonder can the scripts be used which Chris Andrist, KC7WSU created many years ago.  Link https://github.com/candrist/mmdvm-image

I am keen to update my raspberry pi build which is currently running an old unsupported OS.

I wonder what users use now when building raspberry pi?

Regards


Paul
G7KBR


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

Rafael Pinto [PU1OWL]
 

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

 

901 - 920 of 1059