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
_____________________ 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
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
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.
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
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
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
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.
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.