OVERVIEW

The DMR monitor system basically uses 3 components:


1) Client

This is the data capture software. It should work on every PC which 
has access to the IP datastream of a single DMR repeater or a DMR 
network. In Germany we run it on a SmartPTT-server which has access
to 5 DMR networks.

It has also been tested with a cheap Mikrotik router RB750 in the 
line to a repeater using Mikrotiks free remote sniffer tool "trafr".
These routers are able to run a sniffer tool with filters and send
the datastream to a PC on the network.
A setup like that only allows to see traffic of one single network, 
where the setup on a SmartPTT server or similar bridges allows to
capture several networks and to see even traffic on repeaters where
a timeslots ist switched local/not linked.

Our SmartPTT Server currently uses 5 network ports where different 
networks are connected.

I modified the known standard network tool "tcpdump".
It is called "windump" for Windows platforms, but it is the same 
sourcecode.
tcpdump allows to interpret some router protocols, I added basic 
DMR interpretation to that feature.

SmartPTT runs on Windows, so we use the Windows version "windump" 
to get access to the network traffic.

The Mikrotik remote sniffer tool works on Linux, there we use the 
Linux version of "tcpdump".

The Windows executable can be found in the client directory.
The Linux version is supplied as a patch to the original source
code from tcpdump.org only.
All standard functionality is still implemented, in case of questions
on standard features please first check the tcpdump manpage.

The modified version of tcpdump captures the DMR header and reduces
traffic like the keep-alive messages between all repeaters and other 
components on the network.
It also converts the IDs and sequence numbers of the header from
hexadecimal to decimal values and groups it to a human readable format.
This is usefull for debugging network issues.

There is no decoding of any voice data, only parts of the header 
which are transferred open in simple hexadecimal format are converted
and reformatted.

The tool sets up an internal cache with unique transmission-IDs 
build from repeater-ID, timeslot and sequence number to keep track
on each connection and prevent duplicate messages from streams.
As a result it creates 1 message per minute for each active gateway 
on the network, and 2 messages for each voice transmission, 1 at 
the start and 1 at the end.

Most of the visualisation part is taken from the DStar ircDDB project
(www.ircddb.net).

The output of the modified tcpdump is transfered to the database
server by the standard tool "netcat" (nc).
This is simply done by UDP, one way, no feedback.
The tool netcat is also availble for Linux and Windows platforms.



2) Database Server
The receiver of the UDP transmissions is a perl script running on
a Linux machine.
There the IDs are looked up in a table, translated to the actual
callsigns and finally stored to a MySQL database.
The ID/callsign table is updated twice per day by another perl-tool,
which reads the official registration table from the MARC website.



3) Webapplication
Finally some php-scripts create the output on the webserver by 
selecting the appropiate data from the SQL-database.

The "server" directory supplies scripts, sample configurations, samples
of start files, screenshots of the layout and a dump of the MySQL
database.
Please find more comments inside the scripts.

There are also some little tools included, for example to request the
status of a specific repeater, like this: 
http://dmr.darc.de/status.php?call=DB0MYK
This tool will answer with a string of a timestamp and 3 digits, the
first saying if the system is up, the second if it is linked on TS1, 
the 3rd on TS2.
This may be used to show the status of the own repeater on webpages
with icons and other grafics.
Such little nice things can easily be realized with a simple SQL-
request to the database server.



73 de Hans, DL5DI