[Top][Home]
These are the setting of my Pi-Star JumboSpot for operating on the VKDMR Network:
[Top][Home]
The Australian Bandplan designates 439.125 and 439.150 for digital/internet gateways
Hotspots may be considered as gateway devices.
Note that 439.200 is assigned for digital simplex operation, and 435.000 to 438.000
used internationally for satellite communication, which can be disrupted by even low power hotspot.
Manufacturers' default frequencies are:
These are the source files for building the MMDVMHost, the program that
interfaces to the MMDVM or DVMega on the one side, and a suitable network
on the other. It supports D-Star, DMR, P25 Phase 1, NXDN, and System Fusion
on the MMDVM, and D-Star, DMR, and System Fusion on the DVMega.
On the D-Star side the MMDVMHost interfaces with the ircDDB Gateway, on DMR
it can connect to BrandMeister, DMR+, HB Link, XLX or DMRGateway (to connect
to multiple DMR networks at once) on System Fusion it connects to the YSF
Gateway. On P25 it connects to the P25 Gateway.
https://github.com/g4klx/MMDVMHost
How to set jumper:
Updating the JumboSpot by John's Musings:
http://www.hagensieker.com/blog/page/?post_id=99&title=jumbospot-dmr-hotspot
[Top][Home]
Now add a zone called DmrGateway (or your hotspot name) and put all 3 channels in it. When you switch to this zone to use the hotspot, you can decide if you want to use BM, DMR+ or XLX by **channel selection**.
To change reflectors or modules use the keypad, Menu--> Contacts--> 3 Manual Dial and you will find yourself with a clear white screen headed "Radio Number". This is where you type your commands. A press of the ptt for a moment will cause the reflector change to take place.
There is a bit of important info here:-
Calls to BM are as usual ie 4000, 5000, 4404 etc. (but they could be put in as 94000, 95000, 94404 etc.
Calls to DMR+ must have an 8 in front as in 84000, 85000, 84400
Calls to XLX must have a 6, as in 64001,64002,64003...64026 to switch between modules
(reflectors?) A to Z Note that XLX925 is a master. To switch master, from XLX925 to
XLX950 the prefix is 68 so the call would be 68950. The xlx masters have a default
reflector. For instance, if you switched from XLX950 to XLX925 you'd end up
dumped in default reflector D, so then you must call 64001 to switch to XLX925/A
to bask in the CQ-UK sunshine.
>
[Top][Home]
You can set some configuration options in the MMDVM.ini file which are send to the DMR-Master on logon. This options provide the same features like sysops of "public repeaters" know from the registration database.
The options that you may set are:
| StartRef | The reflector which will be connected at startup (4000 means "disconnected") |
| RelinkTime | If the reflector is not used the DMR-Master will reconnect to StartRef after this time (in minutes) |
| UserLink | Set to 1 to allow users to change the reflector, set to 0 to switch remote control off |
| TS1_1 to TS1_5 | 1 to 5 static linked talk groups on timeslot 1 |
The command line in the sample MMDVM.ini looks like this:
In older sample files it may be missing, add it after the last entry of the block which starts with [DMR Network].
Change the line to this format:
The line starts with "Options=". This is required for MMDVMHost. The rest of the line is sent transparent to the DMR+Master. In the sample above the DMR-Master will get this part:
It is a semi-colon separated list of the options which were described before.
Special limitations apply for DMO mode (hotspots). There is only one timeslots in DMO-Mode, therefore the settings are limited.
DMR-Master maps the single DMO channel to one of the two timeslot of the network based on the destination address.
This influences the options.
By default a DMO repeater will be connected to a reflector, either given by the
DMR-Master, or by options, or by registration database. If you do not want to
connect to a reflector at startup, but want to book a talk group on TS1,
set StartRef to 4000 (not linked) in the options and set "TG1_1" to your needs.
The DMR+Master will book "TG1_1" if no reflector is set.
"TG1_2" to "TG1_5" are not supported in DMO mode.
Priority of settings:
The idea with this order is: Many public repeaters are located at special locations with limited access and often sysops are no Linux experts. Therefore the configuration on a web-page may be preferred for public repeaters. Database settings may easily be switched off if sysops prefer settings by MMDVM "options".
When you connecting to a non-DMR+System deactivate the Options line by inserting a "#" at the 1st position.
Source:
http://dc7jzb.de/downloads/dmr/misc/mmdvm-options.txt
[Top][Home]
In normal usage the option string, which is specific to the DMR+ network, allows you to connect and disconnect or not be connected to a reflector by default. A example of normal Option statement is StartRef=4639;RelinkTime=60;UserLink=1;
However, this particular option string is special. It is a Special Hack that allows the connection to a DMR+ server without any default Reflector activated. With DMR+, and no options sent the server determines the Reflector thats automatically assinged (eg; 4400 for UK servers etc) The combination of Ref=4000 (no reflector) and TS1_1=9 for Hotspots means no active Reflector.
There are a couple of things to keep in mind with DMR+
The option line above sets the connected reflector to 4000 (Unlink), the relink time
can probably be omitted, this is the idle timer (in mins) to relink to your chosen
reflectors when idle.
UserLink - as you expect, allows RF link commands.
TS1_1= - linked TG1 is set to TG9,
that sounds weird, since we know that DMO mode uses TS2, and TG9 is a
special one, that is the input TG for connected reflectors. This is just some special
magic combo that makes DMO mode on DMR+ un-linkable.
[Top][Home]
DMO is the term used by the TETRA industry to describe the ability of TETRA radio terminals
to communicate directly with each other independent of the Trunked Mode Operation (TMO) network. DMO is not new and has been a fundamental mode of operation by many traditional PMR user organisations for several decades.
Source:https://tcca.info/tetra/direct-mode-operation-dmo/
[Top][Home]
The UK Phoenix Network is is very similar to the Austrlian VKDMR Network in Australia.
Both use the propriety IPSC2 server software.
Current publicly accessible dashboards used by the Phoenix network:
For Repeaters:
http://phoenix-k.opendmr.net/ipsc/
For Hotspots:
http://phoenix-f.opendmr.net/ipsc/
If you need to make a reflector FIXED so that users cannot unlink, for schedulling connections via CRON for example you can use the the following:
Should you wish to Un-Fix a reflector, relink to the same reflector without the fixed flag, such as:
These instruction show how to log into Brandmeister and generate an API key:
https://brandmeister.network/
This key is a string of random characters. Once generate and display on the
screen it will never be displayed again, so make a copy to a file in a
safe place. I use my Dropbox account. If you lose it you can simply generate
another key and if you are concerned that someone else is using your key,
simply revoke the key.
http://wiki.pistar.uk/PI-Star_integration_with_BrandMeister_API
This page shows the "Last Heard" on the Mt Cotton Digital Repeater, VK4RDB, repeater node number 505424
https://brandmeister.network/?page=lh&ContextID=^505424$
[Top][Home]
In an IEEE 802.11 system, RSSI is the relative received signal strength in a
wireless environment, in arbitrary units. RSSI is an indication of the power
level being received by the receive radio after the antenna and possible cable
loss. Therefore, the higher the RSSI number, the stronger the signal.
Source: https://en.wikipedia.org/wiki/Received_signal_strength_indication
File: /usr/local/etc/RSSI.dat # should be populated similar t below but depends on
radio. The stock values are there for MMDVM_HS units that support RSSI, if you use
anything else, yes you may well need to tune to the radio.
There is an editor for that in the expert section.
This is what is in that file :
My understanding is that with these settings, the relevant TG (eg 4409 and 2351)
are sent off (re-directed) to the UK Pheonix-F server for re-direction/connection
instead of been sent to DMR+_Australia reflector/server which does not know what to
do with them. Conversely, I would guess, that the Phoenix-F server does not handle
the Australian DMR+ TG's very well. However, with this setup the BM linked TG's are
still processed in Aust by the BM_Australia_5051 reflector/server. Probably best to
set it back to DMR+_Australia after testing.
Set up 4409 and 2351 in the DMR radio/HH to reach CQ-UK.
This is another way you can connect to CQUK:
Running pi-star use dmr/xlx - look for xlx/dcs/xrf 925 A for cq-uk
This way you miss out the middle server Pheonix_F and connect directly to Rickie in
Belfast who will transcode OR or setup a talk group on the repeater Rickie can
give you an ip address and this way you could keep the talkgroup connected all the time.
| Gateway Hardware Information | ||||||
|---|---|---|---|---|---|---|
| Hostname | Kernel | Platform | CPU Load | CPU Temp | ||
| pi-star | 4.9.35-v7+ | Pi 3 Model B (1GB) - Embest, CH | 0.05/0.01/0.01 | 46.2°C / 115.2°F | ||
It may be necessary to add a throttle to the web interface to slow AJAX refreah rates.
It is not an optimal fix principally because page changes are also affected by the delay,
and the display may sometimes miss events taking place.
The throttle period is currently set to 6 seconds. The system still spits out
approx 5 to 15 K Bytes of data every throttle period even with nothing going on
That equates to about 10 Mega bytes per hour. Goodness knows what it would have
been without the throttle!
Other pages like 'configuration' also regularly output data, but they don't
output as much as the 'live' status pages.
The web interface appears to be designed for a local area network
There may be other more suitable 'control panels' around for MMDVM that play
nicer over low bandwidth Internet.
The changes required are:
Adding the throttle to index.php seems to affect all pages (which is what is needed).
The throttle period can be adjusted by setting RATE_LIMIT_IN_MS in the file throttle.js.
Reference:https://github.com/dh3wr/RasPagerDigi/tree/master/software/Simple-WebSocket-Server
[Top][Home]
These are the source files for building the MMDVMHost, the program that interfaces to the MMDVM or DVMega on the one side, and a suitable network on the other. It supports D-Star, DMR, P25 Phase 1, NXDN, and System Fusion on the MMDVM, and D-Star, DMR, and System Fusion on the DVMega.
On the D-Star side the MMDVMHost interfaces with the ircDDB Gateway, on DMR it can connect to BrandMeister, DMR+, HB Link, XLX or DMRGateway (to connect to multiple DMR networks at once) on System Fusion it connects to the YSF Gateway. On P25 it connects to the P25 Gateway.
https://github.com/g4klx/MMDVMHost
How to set jumper:
Updating the JumboSpot by John's Musings:
http://www.hagensieker.com/blog/page/?post_id=99&title=jumbospot-dmr-hotspot
[Top][Home]
What is CQ-UK? My best answer is a communication hub for digital traffic. It
attempts to provides as many "spokes to the wheel" as possible allowing many
different modes and communication systems to cross connect,with the notable
exception of BrandMeister. Brandmeister repeaters NOT AVAILABLE on CQ-UK
This diagram, from the CQ-UK.net web site puts it visually...
http://www.cq-uk.com/linking
These are the setting to access the PI-Star MMDVM Gateway (Repeater) that should work
for UK-CQ:
My understanding is that with these settings, the relevant TG (eg 4409 and 2351)
are sent off (re-directed) to the UK Pheonix-F server for re-direction/connection
instead of been sent to DMR+_Australia reflector/server which does not know what to
do with them. Conversely, I would guess, that the Phoenix-F server does not handle
the Australian DMR+ TG's very well. However, with this setup the BM linked TG's are
still processed in Aust by the BM_Australia_5051 reflector/server. Probably best to
set it back to DMR+_Australia after testing.
Set up 4409 and 2351 in the DMR radio/HH to reach CQ-UK.
This is another way you can connect to CQUK:
Running pi-star use dmr/xlx - look for xlx/dcs/xrf 925 A for cq-uk
This way you miss out the middle server Pheonix_F and connect directly to Rickie in
Belfast who will transcode OR or setup a talk group on the repeater Rickie can
give you an ip address and this way you could keep the talkgroup connected all the time.
It may be necessary to add a throttle to the web interface to slow AJAX refresh rates.
It is not an optimal fix principally because page changes are also affected by the delay,
and the display may sometimes miss events taking place.
The throttle period is currently set to 6 seconds. The system still spits out approx 5 to 15 K Bytes of data every throttle period even with nothing going on - so that equates to about 10 Mega bytes per hour by my reckoning. Goodness knows what it would have been without the throttle!
Other pages like 'configuration' also regularly output data, but they don't output as much as the 'live' status pages.
The web interface appears to be designed for a local area network
There may be other more suitable 'control panels' around for MMDVM that play nicer over low bandwidth Internet.
The changes required are:
Adding the throttle to index.php seems to affect all pages (which is what is needed).
The throttle period can be adjusted by setting RATE_LIMIT_IN_MS in the file throttle.js.
References:
[Top][Home]
This is a tricky one. As I see it there is a time zone problem.
Since the VKDMR server is in Melbourne it is logging calls in AEDT.
All the logs are an hour early since daylight saving started.
Our repeater is in QLD, so rightly, it should have a TZ=+10.
However, for practical proposes, we should set TZ=+11. (actually AEDT)
The sole purpose of the RPi is the service the MMDVM which is presently only set
to DMR. This could get very complicated if we were to run multi mode and say,
the DStar server was in Perth and logged in AWST.
BTW, for the easily confused, like me, Australian Eastern Daylight Time (AEDT)
is 11 hours ahead of Coordinated Universal Time (UTC) from the first Sunday in
October to the the first Sunday in April.
Maybe, Pi-Star has a setting to adjust for the server and reflector being in a
different time zones, but I cannot find it, or any reference to such a setting
in my searches. I will keep searching