November update

I’ve been hard at work behind the scenes recently. Enhancements include:

  • Repeater dashboard (see sidebar link)
  • Talkgroup ReWrite (see user guide)
  • Slot 1 also supporting TG23510, rewritten to TG9 (see user guide)
  • Purchased some RG214 to upgrade the radio <-> duplexer links, to minimise possible de-sense from stray RF.
  • SMS service – repeater is able to send welcome messages, send you your current BER etc. (More on this soon, in the mean time, please see user guide).

I am also interested in getting some feedback on some points of discussion:

  1. Should FR go true multi-mode? Note, I don’t have radios for other modes at present, so this would require input from other stations to monitor the repeater in other modes, either by loan equipment or by users listening and reporting back to me if any issues are seen.
  2. GB7FR social meet – I’ve been meaning to do this for ages, probably at The Henty in Ferring. Are you interested?

Feedback welcome.

 

73 Simon

Extra client-side functionality from the MMDVM repeater and dmrshark

Right from the beginning I wanted to be able to extend the basic functionality of the MMDVM DMR repeater beyond just simple voice traffic. Whilst BrandMeister and MMDVM are both great pieces of work, I’m not sure I agree completely with the BrandMeister architecture and the fact that pretty much all functionality is handled at the server, taking a lot of control away from the repeater keeper.

In my quest to be able to do more with the MMDVM from the computer side, I’ve been trying to get my head around the source code, because I’d like to be able to do things like filter talk-groups at the repeater and send DMR SMS messages.

During my research, I discovered dmrshark. Dmrshark uses libpcap to analyse the traffic flowing over a Hytera IPSC network and do things with the data gathered. It’s yet to be seen how much modification it will need to work with the homebrew repeater protocol but it could provide a useful tool for analysing what is going on, gathering data and responding to it.

I am particularly interested in the fact that it might be able to drive an SMS-based information system. Both SMS and IP data are currently under-utilised on Amatuer networks.

I built a system for information request and weather data transmission etc. for APRS a couple of years back. It seems to me that DMR SMS would enable this type of functionality whilst getting away from some of the limitations of APRS. APRS is outdated and does not scale well and there is much resistance to progressive ideas and development on the APRS network. DMR should be able to handle this type of system and voice traffic, with neither system causing any impact or degradation to the other.