Topics

DMRmonitor


Steve N4IRS
 

I have started to play with DMRmonitor. I think it may be a good way to display real time or near real time data from DMRlink, HBlink and maybe "other" programs.

Steve 


Cort <n0mjs@...>
 

Yeah… Like most things I do, I design by building and modifying. I don’t usually sit down and work out the details, then implement. I implement on the fly. The biggest thing will be the opcodes used between *link and DMRmonitor… at some point, need to standardize a set that can inform DMRmonitor what kinds of tables to build/populate, etc.

Well, that and the fact that I know NO javascript…. 

Some things for the group that I feel really strongly about and hope to keep everyone on board with:

Continue using a python-based web server for it — maybe a different, more robust module — but I just hate making folks have to run apache, or nginx behind it… and an sql server, etc. I’d like to keep this so folks only have to know how to run one program to make it work.

The other is I *REALLY* want to keep it web socket based and avoid trying to support a gaggle of persistent http hacks (i.e. long polling). Why? I’ll explain by example: At the day job, we implemented IPv6 with full feature set parity back in 2003 (no shit)… because it’s the right thing to do, and someone needs to push forward instead of keep using a “it’ll-get-us-by” hack.

Goals for DMRmonitor on the IPSC side include using the same messages sent as log messages to update fields in the main DMRlink table in real-time about transmissions, etc…. and also to use RCM messages to show what each repeater is actually reporting that it’s doing — not just lighting it up red b/c it *should* be transmitting (a la c-Bridge). There are some really important reasons for this — I’ll give one example.

If you’re talking on a repeater and key up during BSID, you get bonked. If you’re talking away and when you let up the repeater sends a BSID, the channel is blocked. But the very nature of a call router isn’t going to “back block” that call through the entire network… So, you let up, the repeater goes into BSID, confbridge.py sends the other guy’s transmission back to you, consisting only of a short transmission like “See you at breakfast” and you never hear it. Then you say… well, the network is broken. There’s packet loss… something’s wrong…. I’d really like to get RCM in the mix because a repeater WILL REPORT if and why it blocks a call. I am pretty sure I’ve had COUNTLESS reports of problems for situations like this over the years - and sometimes actually gone chasing a problem that didn’t exist.

On May 24, 2017, at 9:11 AM, Steve N4IRS <szingman@...> wrote:

I have started to play with DMRmonitor. I think it may be a good way to display real time or near real time data from DMRlink, HBlink and maybe "other" programs.

Steve 

Cort Buffington
785-865-7206


Steve N4IRS
 

I'm starting to get my first look at the output of rcm.py I have to update my confbridge to support DMRmonitor. Here is a snip:

Call Monitor - Repeater State
TIME:          2017-05-24 11:16:11
DATA SOURCE:   911249, 911249
TS1 State:     Idle
TS2 State:     Idle
 
Call Monitor - Repeater State
TIME:          2017-05-24 11:17:51
DATA SOURCE:   911249, 911249
TS1 State:     Repeating
TS2 State:     Idle
 
Call Monitor - Call Status
TIME:         2017-05-24 11:17:51
DATA SOURCE:  911249, 911249
IPSC:         IRSC
IPSC Source:  1911249, 1911249
Timeslot:     1
Status:       Active
Type:         Group Voice
Source Sub:   3134499, W2SWX
Target Sub:   TGID: 3, North America
 


Cort <n0mjs@...>
 

That file is a hot mess.... but it'll demonstrate what RCM is about. Note you need to set RCM True and 3rd party console app to True In the config to get full info from repeaters

Sent from my iPhone

On May 24, 2017, at 10:21 AM, Steve N4IRS <szingman@...> wrote:

I'm starting to get my first look at the output of rcm.py I have to update my confbridge to support DMRmonitor. Here is a snip:

Call Monitor - Repeater State
TIME:          2017-05-24 11:16:11
DATA SOURCE:   911249, 911249
TS1 State:     Idle
TS2 State:     Idle
 
Call Monitor - Repeater State
TIME:          2017-05-24 11:17:51
DATA SOURCE:   911249, 911249
TS1 State:     Repeating
TS2 State:     Idle
 
Call Monitor - Call Status
TIME:         2017-05-24 11:17:51
DATA SOURCE:  911249, 911249
IPSC:         IRSC
IPSC Source:  1911249, 1911249
Timeslot:     1
Status:       Active
Type:         Group Voice
Source Sub:   3134499, W2SWX
Target Sub:   TGID: 3, North America
 


Steve N4IRS
 

Might be a hot mess, I have DMRmonitor running. 
http://stn2600.dvswitch.org:8080/


Cort <n0mjs@...>
 

I started work on a real-time RCM-based table today. Imagine even seeing when repeaters are IDing!

Sent from my iPhone

On May 26, 2017, at 2:29 PM, Steve N4IRS <szingman@...> wrote:

Might be a hot mess, I have DMRmonitor running. 
http://stn2600.dvswitch.org:8080/


Steve N4IRS
 

Looking forward to it. I like how the confbridge shows me exactly which repeater is is connected PTT and how long is left on the timer.

On 05/26/2017 06:46 PM, Cort wrote:
I started work on a real-time RCM-based table today. Imagine even seeing when repeaters are IDing!

Sent from my iPhone

On May 26, 2017, at 2:29 PM, Steve N4IRS <szingman@...> wrote:

Might be a hot mess, I have DMRmonitor running. 
http://stn2600.dvswitch.org:8080/


Steve N4IRS
 

I just realized that the Bridge Group Status table makes it a heck of a lot easier to setup PTT TGs. Or at least see how they are configured.
 

On 05/26/2017 06:46 PM, Cort wrote:
I started work on a real-time RCM-based table today. Imagine even seeing when repeaters are IDing!

Sent from my iPhone

On May 26, 2017, at 2:29 PM, Steve N4IRS <szingman@...> wrote:

Might be a hot mess, I have DMRmonitor running. 
http://stn2600.dvswitch.org:8080/


Steve N4IRS
 

DMRMonitor just pointed out why I was talking to myself on a connected TG. I have a User Activated (PTT) TG bridged for 31201. I know it's a active TG but over the last few weeks whenever I throw out my call sign, I get no reply.
Looking at the DMRmonitor Bridge Group Status Tables, I found that I was connected to the wrong Master! Yes, I could have found it by reading the confbridge rules. With DMRmonitor it stuck out like a sore thumb.

 


Cort N0MJS <n0mjs@...>
 

I’m leaving an “air gap” on DMRlink and HBlink core stacks for the time being as Mike continues his work — it’s so important I want to stay well clear of it. The completion of the AMBE handling components now in the dmr_utils package give me a boost in making some needed updates to how confbridge works on both sides too!

In the meantime, I am having a TON of fun working on the monitor. I’ve got a side branch now that has the hooks in for RCM-based live-updates on what repeaters are doing (I’ve mentioned this before).

Attached is a screenshot (if it works) of what that table looks like. You’ll see the “master” device is shows in the dark orange type, the stuff in the current DMRmonitor is all there, but “squished” into the lefthand side, and space on the right for live activity updates.

I’m looking for two things right now: Community discussion about this — but please limited to IPSC at this point. And also anyone who has experience with javascript for the browser side who wants to help with that part of it.

So…. discussion now open! If anyone is interested in this, let’s talk on the forum here about it?

On Jun 20, 2017, at 10:52 AM, Steve N4IRS <szingman@...> wrote:

DMRMonitor just pointed out why I was talking to myself on a connected TG. I have a User Activated (PTT) TG bridged for 31201. I know it's a active TG but over the last few weeks whenever I throw out my call sign, I get no reply.
Looking at the DMRmonitor Bridge Group Status Tables, I found that I was connected to the wrong Master! Yes, I could have found it by reading the confbridge rules. With DMRmonitor it stuck out like a sore thumb.

 

Cort Buffington
785-865-7206