New Australian DMR+IpSC2 settings

posted in: DMR | 23

Update Saturday 17th November (2018)

Yet more changes today… (See the updates below..)

After updating PiStar this morning, both Australian IPSC2 servers are now back in the list

DMR+_IPSC2-AUS-1 and DMR+_IPSC2-AUS-2

Both appear to be working.

I’ve had reports that anyone that was on the original non-IPSC2 server now appears to be on one of the IPSC2 servers, which presumably means that he IP Address used by at least one of the IPSC2 servers must be the same as the old DMR+Australia server.

 

Currently its unclear whether people should be using the AUS-1 or AUS-2 servers; my guess is that the hotspots will probably all end up being on AUS-2 and the repeaters will connect to AUS-1, but this is pure speculation.

 

 

 

 

Update Friday 16th November (2018)

 

Changes have been made to the Australian DMR MARC network over the last 1 or 2 days, which make the post I wrote 2 weeks ago, partially incorrect.

NOTE. The screengrab for this post has not been updated. Please see the text below and ignore this screen grab as its now incorrect.

 

I’ll write a updated post, when the status of the network becomes clear (and stable),…

 

but at the moment, hotspot users should run their update system, and the server DMR+_IPSC2-Australia will be removed.

In its place is DMR+_IPSC2-Australia-2, and this server will need to be selected and the static talk groups re-entered.

Apart from that the settings appear to be the same as I described on 28th Oct.

The other notable changes appear that the only the repeater network is on the old IPSC-AUS1 server and all hotspots are now on IPSC2-AUS2

There are separate dashboard pages for the hotspots  http://he.vkdmr.net/ipsc/ and the repeaters http://xe.vkdmr.net/ipsc

 

_____________________  Original post from 28th Oct starts here __________________________________

 

 

At the end of October the Australian DMR MARC IPSC2 server stared to allow connections from hotspots..

 

Please note. I originally wrote this post about 4 days ago, and since then I’ve had to post a few updates as more information has become available, but as I’ve revised a lot of my suggestions, in light of new information, I’ve decided to rewrite this post.

 

The new IPSC2 server allows for a wider range of connection options, in that it not only supports access via TalkGroup 9 via a reflector (e.g. Reflector 4800 = DMR+ TG505), but also now supports direct transfer of the TalkGroup being transmitted by the transceiver into the server.

 

To use the new feature, you will need to change your PiStar settings if you have a Brandmeister / DMR + configuration, using DMR Gateway to only connect to DMR+_IPSC2 Australia

As well as changing the “DMR Master” setting the other important change is to the DMR+ Network Options.

If you want to continue to use a reflector, you will need to add the option StartRef=4800, because IPSC2 does not seem to enable reflector 4800 automatically, like the old DMR+ server does.

However to make use of direct access to Talk Groups, without needing to specify a reflector (normally by doing manual dial on a reflector code e.g. 4803), you need to use different options.

 

Specifically you need to use

 

TS2_1=505;

 

 

What the option “TS2_1=505;” does is tell the IPSC2 server that you want any traffic on 505 sent to your hotspot.

 

The obvious question is what happens if I want to have a QSO on a different Talk Group e.g. 3803.. Don’t I also need to add “static routes” for those talk groups.

e.g. the syntax for this would be

 

TS2_1=505;TS2_2=3803

 

The answer is effectively no..

Its only essential that you put in a static route for TG505.

This is because the IPSC2 server treats the hotspots in virtually the same way as a real repeater, and it is setup so that all other TS2 TG’s behave a bit like User Access (aka UA) Talk Groups, in that you can transmit using TG3801 on your local repeater in VK2 or VK3, and this will cause your VK2 or VK3 etc repeater to connect to the VK1 repeater(s).

Looking on the IPSC2 dashboard, (http://xenon.vkdmr.net/ipsc)  you can see that when a dynamic route is setup by IPSC2 between real repeaters, that this route has a timeout before the route is disconnected. I think the timeout for this is 20 seconds.

 

However the same is not true for TG505. As soon as you stop transmitting on TG505 you’ll see on the IPSC2 dashboard that all repeaters will stop transmitting after a small carrier hold delay.

 

So you will be able to use TG3807 etc  simply by transmitting on that Talk Group, and the IPSC2 server will setup a dynamic route between your hotspot and all the VK7 repeaters.

 

However if you don’t add TG505 as a static route, because of the way IPSC2 is configured, a dynamic route is not setup, and you will find you will not hear any incoming signals on TG505 even if there is traffic on TG505 on any of the repeaters.

 

If you want your hotspot behave exactly the same as a repeater in a specific state, e.g. VK3, you can setup the static routes like this.

 

TS2_1=505;TS2_2=3803;

 

However, there is a potential downside to this configuration, which I will cover later in this post.

 

Assuming that you have reconfigured your PiStar (or other hotspot to connect to IPSC2 and have configured the Options to include a static route to TG505, the next thing you need to change is your codeplug.

 

When using the old DMR+ server, all traffic to the server should have been on TG9 (or TG8 if you are using DMR Gateway – but DMR Gateway was actually converting TG8 from the transceiver to TG9 into the DMR+ server)

However using the IPSC2 server it now operates very much like the Brandmeister network, in that you transmit on the Talk Group that you want to use.

Hence you need to create a set of channels for all of the TG’s that you want to use on the Australian DMR MARC network.

e.g. these Talk Groups

 

505,3801,3802, 3803, 3804, 3805, 3806, 3807, 3808

and also

113,123,133,3809,3810 (You may also be use TG13, however I’ve not tested this myself.)

 

Any of you who has been on DMR for a while will notice that I have split the TG’s into two groups, because TG505, TG380x etc are all on TimeSlot 2 whereas TG113, TG123 , TG3809 and TG3810 etc are on TimeSlot.

 

So what happens if you have a simplex hotspot, like the Jumbospot?

 

Well, what I found out today, is that the IPSC2 server seems to automatically handle the conversion of TS2 to TS1 for the TG’s that are on TS1.

 

So you can setup your codeplug to have all the channels on TS2, but be able to have QSO’s on the TS1 TG’s like 3809 and also the User Access TG’s like 113

 

However this is where the number of static routes you define becomes more important

Since a simplex hotspot, like the JumboSpot can only handle one TimeSlot at a time, you’ll notice occasionally on IPSC2, something like this, where VK2PWR’s hotspot is showing a red box in TimeSlot 1

 

 

The reason this is happening, is because at the time I took the screengrab, VK2PWR had static routes setup for TS1: TG113 and TG123 as well as static routes for TS2: TG505 and TG3802, e.g. his options would have looked like this

 

TS2_1=505;TS2_2=3802;TS1_1=113;TS1_2=123;

 

And this is causing contention because I am transmitting on TG113, and VK2PWR himself is transmitting on TS2: 3802.

The same problem would occur even if VK2PWR is not transmitting, if the station he is in the QSO with, was transmitting on TG3802.

 

So this brings be back to which options you should use, and my current advice is to just use

 

TS2_1=505;

Because this would allow you to use a TS1 TG even if a local TG e.g. 3802 was in use.

However it will still not allow you to start a QSO on TS1 if there is any traffic on TG505 – but this is unavoidable at the moment, and I doubt whether this will be resolved, because of the way IPSC2 has static routes for TG505

 

A note about TG8

TG8 uses a special setup on IPSC2, were it has static routes between groups of repeaters, and it is not possible to use it even if you to setup a static route.

 

Duplex hotspots

For anyone who has a duplex hotspot the setup in PiStar is the same, however because the hotspot can handle both TS1 and TS2 at the same time, the codeplug in the transceiver needs to be setup so that the TS1 TG’s e.g. 113, 123 , 3809 etc, are on TS1 not TS2

duplex hotspots do not suffer from the TimeSlot contention issue, so its perfectly possible to have a QSO on TS1 even if there was already a QSO in progress on TS1

 

 

 

Well..  I hope this post clarifies a few things and helps people make the most out of the new server.

23 Responses

  1. Carlos Lopes
    |

    This is fine but how to disconect if you don’t want it any more i deleted the line but routing continues !!! thanks

  2. Roger Clark
    |

    AFIK. You can’t disconnect if you assign static routes via the options.

  3. Anonymous
    |

    Because you are using static routes, no need to disconnect. Just change channel to the other TG you wish to use and transmit. The key is then to include a channel for each TG you intend using in your code plug.

  4. Roger Clark
    |

    I think the problem with this on a Simplex hotspot is that you can’t transmit when the hotspot is transmitting, hence if you have an incoming transmission on TG505 you can’t transmit on TG3803

    So this only works if you are using DMR+ only, and will not allow operation of both DMR+ and BM on the same hotspot.

    When I get chance I’m going to try to use the duplex hotspot with MARC (ISPC2) on TS1 RF and BM on TS2, however this will need DMR Gateway to remap different TG’s on TS1 to either TS2 or TS1 i.e TG 1,13,113,123,133, 3809 and 3810 are all on TS1 but 505 and 3801 – 3808 are on TS2

  5. Glenn Lyons
    |

    Hi Rodger, Excellent article …. big thank you for putting in the time and effort to write a blog.

    Now I confess to a pedantic nature. A neurosis from a life time of coding.

    Your example is not terminated in a “;” “TS2_1=505;TS2_2=3803;TS1_1=113;TS1_2=123”

    Refering to https://github.com/g4klx/MMDVMHost/blob/master/DMRplus_startup_options.md
    dg9vh committed on 12 Nov 2016 this example terminated in a “;”
    Options=StartRef=4013;RelinkTime=15;UserLink=1;TS1_1=262;TS1_2=1;TS1_3=20;TS1_4=110;TS1_5=270;

    I recall reading that the last parameter is ignored if not followed by a “;”, but cannot find the reference off hand.

    My question is: Is a terminating “;” necessary or not?

    Thanks VK4PK Glenn (No! the “P” is not for pedantic.)

  6. Scott
    |

    Hi Roger, just a minor typo with the following “However, there is a potential downside to this configuration, which I will over later in this post.” over should be cover I believe!

  7. Roger Clark
    |

    Thanks Scott

    I’ve corrected it now.

    Unfortunately the WordPress text editor only spell checks, it doesn’t grammar check like MS Word etc does

  8. Bevan VK5BD
    |

    Hello Roger,

    I am currently having a go at having my duplex hotspot (STM32) on both DMR-MARC (DMR+) and BM, I have kept my usage the same in that TS1 is for DMR+ and TS2 is for BM, I have used two TGRewrite entries in the expert setup for DMR Network 2 (DMR+), they being;
    TGRewrite=1,505,2,505,1
    TGRewrite=1,3800,2,3800,9

    This list will have to expand once I know which TG’s need pushing to TS2 for DMR+ to work correctly

    So far I have been happy with the operation, however I have not seen enough traffic on DMR+ to see how things go with say a TG3809 and a TG3805 QSO trying to occur at the same time to see who wins. I have tested having a QSO on BM TG505 and hearing DMR+ TG505 seperately on a second radio.

    I am not sure how things are going to go with reflectors, since the change to AUS-2, I have not had much joy using reflectors, but I also haven’t made the time to make any changes and test the reflectors since the AUS-2 server seems treat hotspots like real repeaters, the reflector method becomes redundant, although the ability to “Direct Dial” from the keypad was useful.

    Please let me know if you can see any downfall to my methodology.

    Regards,
    Bevan
    VK5BD

    PS All we need now is for the GURU’s behind the IPSC software, to track which Repeater/Hotspot a radio was last heard on so that radio to radio calls and SMS’s can be routed through the network, may require storing of the SMS’s (up to 24hrs) if undelivered until the radio is detected as active on the network.

  9. Roger Clark
    |

    Hi Bevan

    I did consider doing something similar, when I thought simplex hotspots could not get onto 3809 and 3810 (and 113 etc), but I then found out that IPSC2 seems to map TG3809 TS2 to TG3809 TS1

    So your TG rewrites should work, as long as IPSC2 thinks you are running a simplex hotspot. (Well, I’ve not tried transmitting on my duplex hotspot on TS3809 TS2 to see what happens.

    From what I’ve seen on the dashboard, if someone is having a QSO on 3809, and 505 becomes active, then 505 shows in red to indicate that the hotspot can’t handle processing both TS’s at the same time, and in that 3809 seems to win.

    Re: SMS

    I’ve not tried that, but private calls work from hotspot to hotspot, as long as both hotspots are on the same IPSC server i.e either AUS-1 or AUS-2, but the link between AUS-1 and AUS-2 does not seem to pass private calls.

    You may find SMS’s work in the same way.

    Yes. Ideally, IPSC would keep some Last Heard data.

    PPS.
    I’ve never tried it, but it looks like in theory you can send a SMS to a TG, e.g. 505 but I’ve no idea what would happen if you did that 😉

  10. Roger Clark
    |

    BTW. I noticed PiStar has an annoying habit of overwriting the DMRGateway TGRewrite’s if I changed anything on the normal PiStar “configuration” page

  11. Bevan
    |

    Yes that is correct, it does delete additional entries, apparently due to the way PHP handles the INI files, it cant handle the same handle (ie TGRewrite=) for each entry being the same and so drops the additional ones, you have to keep a local copy of the Expert Configuration to paste back in if you are making changes via the normal configuration name.

  12. Roger Clark
    |

    OK. Thats interesting

    Did you try TGRewrite0 TGRewrite1 TGRewrite3 etc, because I’ve noticed some of the rewrite files use this syntax.

    I think Adrian VK4TUX told me that PiStar uses a customised version of DMR Gateway, and potentially has modified the syntax it can handle.

    But it also seems to support the original syntax of multiple lines called TGRewrite

  13. Steven Booker
    |

    Hi Roger, first, thanks for your helpful posts. Since you seem to know what you are doing with DMR, do you mind if I ask some questions?

    For someone who has a jumbo spot and usually uses it for accessing BM TG’s but would occasionally like to use it to access VK DMR+ TG’s like 3802 etc:

    1. should the pi-star config option “DMR Master” be set to “DMRGateway” or “BM_Australia_5051”?

    2. should pi-star config option “Brandmeister Master” be set to “BM_Australia_5051”?

    3. should pi-star config option “DMR+ Master” be “DMR+_IPSC2-Aus-2”?

    4. should pi-star config option “DMR+ Network” be options= “TS2_1=505”?

    5. when programming the code plug to work VK DMR+ TG’s via jumospot, should the TG number be the same as the VK DMR TG number (i.e. VK DMR TG 505 is prorammed as TG 505 in codeplug)?

    6. in your reply to this post of 29/10/18, you wrote: “So this only works if you are using DMR+ only, and will not allow operation of both DMR+ and BM on the same hotspot”. Do I understand this correctly to mean that if I want to switch between using BM and VK DMR TG’s on the hotspot, I have to go into Pi-star configuration each time i want to change from VK DMR to BM and fiddle with the options? If the answer is “no”, how does the hotspot know if I’m calling BM TG 505 or VK DMR TG 505?

    Thanks

    Steven
    VK2HSL

  14. Roger Clark
    |

    Re: Your questions

    1. Because of the way IPSC2 now allows direct use of TG’s into your hotspot e.g. transmit on 505 and you come out on the DMR+ network on 505 etc.
    You can’t use the DMR Gateway option in PiStar as it assumes that all traffic to IPSC2 will use TG9.

    So you can’t use DMR Gateway for the Australian DMR+ network (unless you still want to use reflectors – and most people don’t want to use reflectors if they can be avoided)

    2. The Brandmeister option only applies if you select DMR Gateway (see the answer to question 1 about not using DMR Gateway)

    3. Currently the best option seems to be to select “DMR+_IPSC2-Aus-2”, because although I think “DMR+_IPSC2-Aus-1” still works, the general consensus is that “DMR+_IPSC2-Aus-1” is likely to become the connection for real repeaters only.

    4. Yes. Without that, you won’t be able to use TG505 at all. Some people also add “TS2_1=505;TS2_2=3803” (or another 380x TG), but the additional TG is not required, unless you specifically want to be able to monitor both TG505 and TG3803 etc.
    You can still use For Example 3803 simply by tramsmitting on 3803, you won’t need to have it as a static TG if you QSY to it.

    5. The codeplug setup for the hotspot can now be the same as for a real repeater. i.e you transmit on TG505 on the frequency of your hotspot.

    6. If you use the new method, of transmitting on the TG you want to use e.g. TG505, you can’t use both BM and DMR+ on the same hotspot without changing the configuration each time you want to swap networks.
    See my post about how I fitted a physical switch to my hotspot to allow me to change networks using a 2 position switch, to select which network I wanted to use.

    Note. If you have a duplex hotspot, it would be possible to configure it to send all traffic on TS1 to BM and all traffic on TS2 to DMR+ (or vice versa), but since you have a simplex JumboSpot you wont have that option.

    Alternatively you could go back to the old method, which AFIK is still supported by IPSC2, of using TG8 and reflector codes to select the TG e.g. Manual dial 84800 to tell DMR+ you want to use TG505, however since this is far more difficult to use, you’ll find the majority of people are using the new method
    e.g. Look at http://he.vkdmr.net/ipsc/
    And note how many VK stations have static routes of 505 in the TS2 column and how many people still have a reflector code in the Ref column.
    (I suspect some of the people still using reflectors many not have updated their pistar to the new method – but I know some people still use reflectors so that they can use BM and DMR+ without changing the config)

  15. Steven Booker
    |

    Thank you!

  16. Bevan
    |

    Hello Roger,

    I have continued to do some testing with a simplex hotspot and have found that I believe it is possible to have both VK-DMR(DMR+/DMR-Marc) and BM both enabled, however further testing to be done.

    I have trialed programming my radio with TG for VK-DMR starting at 8000001 ie 505 is 8000505, 3805 is 8003805 etc just to keep the two networks TG’s far apart.

    In my Pi-Star expert settings for Network2 (VK-DMR) if have added the following TGRewrite rules:

    TGRewrite0=2,8000505,2,505,1
    TGRewrite1=2,8003800,2,3800,9
    TGRewrite2=2,8003809,1,3809,2
    TGRewrite3=2,8000001,2,1,123

    With these rules in place I have been able to use both networks (one at a time) although I have not tried having a BM QSO and also VK-DMR active with traffic, not sure how this will be handled by the hotspot, clearly only one lot of traffic would get through but if you didn’t have the hotspot attached to TG’s and treated all TG as User Activated (much like reflectors) then there shouldn’t be an issue.

    There are downfalls that I have not yet come up with a solutions for:
    The Talk Group Hang time on the VK-DMR network is set at a server level and is quite short, where as a reflector hang time was set via the options entry.
    BM Talk Group Hang time can be repeater dependant, but seems like it cant be set on a simplex hotspot via the selfcare, my test indicates it is about 2 mins.

    I don’t know how often the “options=” field gets sent to the IPSC2 server, if it was regularly sent then it could be a case of having code update the “options=” with the TG you are wanting to use and then the server would attach it. Am thinking the same may be doable with the BM Manager section of Pi-Star once you have used the BM API key to link the accounts and run the code behind the “Modify Static” button with the required information about the TG to be added and removed.

    That is what I have found so far, I don’t know if it is of any benefit or if it is just making a beast out of programming the radio and making Pi-Star more complex to navigate, there is validity to having the radio programmed with one set of TG’s and having the physical switch to choose the required network, or maybe a remote control code to do the switching, there does seem to be a bit of us vs them with respect to the different networks.

    73
    VK5BD

  17. Roger Clark
    |

    Thanks Bevan

    That’s very interesting.

    Re: Changing the options to suit the TG you were on.

    I’ve seen some stuff done with modified versions of PiStar Remote, where people transmit on a specific Private Call (or manual dial), and that triggers certain actions to occur on the PiStar.

    So you could for example do a manual dial on 3809 and get a modified PiStar Remote to change the “options” and set TS2_1=3809;
    But operating the hotspot would be quite complex, with having to manually dial first etc

    I think the way you have it now, is a reasonable workaround for anyone with a simplex hotspot.

    Using a duplex hotspot with TS1 for BM and TS2 for DMR+ is probably a more workable option, as it can handle both networks (Timeslots) at the same time, albeit you will be operating on DMR+ as if its a simplex hotspot, so there could be contention if you were using a TS1 TG e.g. 3809, which IPSC2 seems to convert to TS2 3809 for simplex hotspots.

    This assumes that IPSC2 thinks that the duplex hotspot is simplex and does the translation, otherwise you may not get access to the TS1 TG’s on DMR+

  18. Bevan
    |

    Hello Roger,

    I have a Duplex Hotspot set up as a repeater, in my case TS1 is VK-DMR and TS2 is BM, through the use of TGRewrites I can direct the TG back to the correct TS at the IPSC2 server end
    TGRewrite=1,505,2,505,1
    TGRewrite0=1,3800,2,3800,9
    TGRewrite1=1,3809,1,3809,2
    TGRewrite2=1,1,1,1,123

    As you can see all traffic comes in on TS1 and then a specific rule directs the TG’s to the correct TS, I am yet to find a complete list of the TG’s and their TS for the VK-DMR network to be able to cover all TG’s via the TGRewrite rules, currently if there is not a rule for the TG it is dropped at the Pi-Star level.

    Regards,
    Bevan

  19. Roger Clark
    |

    Thanks

    I think that’s the entire list that’s working at the moment..

    Did you try rewriting the TS1 TG’s onto TS2 for DMR+ ? The simplex hotspots send TS2 traffic on 3809, 3810 , 113, 123 etc and these end up on TS1 on the repeaters.

    Does leaving it on TS1 cause less clashes ? Because BM has TG91 etc which is in the same range.

  20. Bevan
    |

    I think the simplex and duplex hotspots need to be treated differently,

    In the case that you have a Duplex Hotspot with each Time Slot assigned to the different networks, things are pretty easy to manage, because of the routing done of the talk groups, I have not had any issues with keying up DMR+ and having the BM react to it.

    For example, if I make a call on VK-DMR TG505, at my end at RF it is TS1, I have a Network 2 (VK-DMR) TGRewrite=1,505,2,505,1 this handles shifting the time slot to TS2 on the IPSC2 server.

    Also in my configuration I have PassAllTG=2 in my Network 1 (BM) settings and the fact that BM is time slot agnostic (it doesn’t matter what TS you send TG data on, as long as you have used the TG on the “correct” TS for your repeater it gets directed back there).

    Until I find out otherwise, I believe the TG rewrites and the seperate TS’s stop cross network triggering.

    In the case of having a Simplex Hotspot, all traffic is handle on the one time slot, generally considered TS2 via Pi-Star, I did the experimenting with Dual Networks as per my previous comment, however if you were using the system for a single VK-DMR network only I believe you would do the following redirecting
    TGRewrite=2,505,2,505,1
    TGRewrite0=2,3800,2,3800,9
    TGRewrite1=2,3809,1,3809,2
    TGRewrite2=2,1,1,1,123
    This would put the TG’s back to the “right” TS’s at the IPSC2 server end, and now that I have seen the differences between this case and the previous post the only change in the rules was the starting TS from 1 to 2.

    Now that I have seen it presented this way, with the only difference being the starting TS of the TGRewrite instructions, there is a valid argument to setting up a Duplex Hotspot on two networks as having TS1 dedicated to BM and TS2 dedicated to VK-DMR (DMR+) as the documentation to guide a newbie would be identical with respect to the TGRewrite rules for either Simplex Single VK-DMR network or a Duplex Dual Network operation. Disclaimer: I have not had any thoughts about the third network operation using XLX Master.

    Further to my previous post about a Simplex Hotspot on Dual Networks, with out the ability to simply attach/detach a TG from either network, it becomes clumsy to operate and you would need to have Pi-Star dashboard access to make it work which sort of defeats the intention of simply choosing the “channel” on the radio to make connection to either network, Being able to switch networks via a private call remote command would be the most desirable option if you don’t have ease access to the hotspot.

    Regards,
    Bevan

  21. Roger Clark
    |

    Thanks Bevan

    I’ll probably give the settings a go on my duplex hotspot, as I’ve loaded my only simplex hotspot to someone at the local club.

  22. Bevan
    |

    If you are going to go with TS1 as BM and TS2 VK-DMR, I think you will need to change/add the PassAllTG=1 and PassAllPC=1 in the expert section of DMR GW against Network 1 (BM)

  23. Roger Clark
    |

    OK

    Thanks.

    I’ve always found the PassAllTG etc a bit of a strange concept, as think you can only put them in one of the networks, but I suppose it makes sense somehow 😉

Leave a Reply