20/10/2013 - Bushfire Related Logging

ivahri
Posts: 843
Joined: Sun May 31, 2009 8:24 pm

Re: 20/10/2013 - Bushfire Related Logging

Post by ivahri » Wed Oct 23, 2013 10:30 pm

Scotty wrote:
ivahri wrote:You also totally misunderstand what the function of the feature is. It has nothing to do with gaining priority- that only comes into play when the network is busy while the function is needed 365 days a year- it is about alerting the radio operator that someone needs immediate assistance. It turns the console RED and displays the radio ID and alias.
I've no doubt that the orange button could have many different functions programmed, including the way that you describe, but I was referring to the button being used as an emergency 'priority access' button, which was in context to the message that I was replying to from Andrew.

The way you describe the FRNSW radios as having the orange button programmed simply alerts the operator that the button has been pressed. It doesn't give the person who has pressed the button priority/immediate access to the network, which it what was being discussed.

If all channels on any given site are busy, then pressing the orange button programmed in the way you describe won't get the message from the radio through any quicker. The user would still get a 'busy' :)
Scotty,

You seem to be very confused....

The purpose of the button is an Emergency button. Depending on the network type it behaves differently. On a P25 trunking network the data gets priority. It DOES get priority. The network determines that- not the radio. On a P25 conventional or an analogue (MDC signalling) network it is just a glorified selcall with a status "bit" that triggers the consoles.

It isn't about getting the message to the operator quicker- it is about alerting the operator to a situation... as most emergency services do not use selcall this is the way in which an operator can be alerted. Red Red Red does much the same... however there are circumstances potentially when the person could be incapacitated & unable to speak.

This feature is considered to be absolutely critical...

Cheers

Richard

BerryV
Posts: 189
Joined: Fri Aug 15, 2008 8:08 pm

Re: 20/10/2013 - Bushfire Related Logging

Post by BerryV » Wed Oct 23, 2013 11:53 pm

Bigfella237 wrote:As I'm sure you know, there are simular features programmable for emergency activations with P25, such as "Hot Microphone" etc. and I know user radios can be programmed to receive emergency calls also, but I've never tried it on a radio with a colour display so I'm not sure if P25 displays flash to red as well, but it wouldn't surprise me, we know it happens on APX portables in a low battery situation?

Andrew
Yes I know about the similar features on P25. the xts/xtl series does not flash red, it stays as normal.

Maybe I should have posted a size and weight comparison between a Tetra MTP850 and a XTS5000 ? :) *yes I know, Tetra uses half the power output, terrible coverage even in meto areas etc). they do bounce well hehe.

Scotty
Posts: 739
Joined: Sun Dec 20, 2009 2:50 am
Location: Sydney and surrounds

Re: 20/10/2013 - Bushfire Related Logging

Post by Scotty » Thu Oct 24, 2013 7:36 am

ivahri wrote:Scotty,

You seem to be very confused....

The purpose of the button is an Emergency button. Depending on the network type it behaves differently. On a P25 trunking network the data gets priority. It DOES get priority. The network determines that- not the radio. On a P25 conventional or an analogue (MDC signalling) network it is just a glorified selcall with a status "bit" that triggers the consoles.

It isn't about getting the message to the operator quicker- it is about alerting the operator to a situation... as most emergency services do not use selcall this is the way in which an operator can be alerted. Red Red Red does much the same... however there are circumstances potentially when the person could be incapacitated & unable to speak.

This feature is considered to be absolutely critical...

Cheers

Richard
Richard,

Mate I'm not confused - you are talking about a different function. :D

The first two posts on page 2 will show where the discussion was heading. The discussion was on some sites repeatedly reaching capacity and emergency service users not being able to pass voice communications, along with ways to correct this issue.

The possibility of having the orange button programmed to give a user priority access to a voice channel was raised by Andrew. I stated that no user currently has this function programmed, and that this would not solve the general issue which was site capacity.

You raised that FRNSW have the orange button programmed to send an alert to the console - this is a different function and not related to what was being discussed. If a site is at capacity pressing that button will not give that user priority access to a voice channel and the user would remain in the queue until a voice channel is available.

The issue was the general capacity of the system when used in times of emergency and ways to give emergency services better overall access. Hopefully that makes sense.

Cheers,
Scott

matthewn1983
Posts: 1532
Joined: Sat Feb 06, 2010 9:41 am

Re: 20/10/2013 - Bushfire Related Logging

Post by matthewn1983 » Thu Oct 24, 2013 7:12 pm

Currently on Mt Tomah (Site 133)

10129 - D401 C-WEST
10060 - GD64 OPS3
10013 - ESO 4
40073 - RFS OPS 6
12036 - NSWPF Specialist Group
10010 - ESO 1
10331 - 9 RUR OPS (ASNSW)

Interesting that several RFS talkgroups are getting denied, including Hunter Valley and Cumberland, the site is only small with 4 voice channels + the 2 control channels.

User avatar
cartman
Posts: 2181
Joined: Wed Aug 13, 2008 12:54 pm
Location: Liverpool, NSW, Australia

Re: 20/10/2013 - Bushfire Related Logging

Post by cartman » Thu Oct 24, 2013 11:19 pm

Hawkesbury talkgroup 10048 was only using the grn for air ops ... The bulk of the action is happening on p25 PMR digital and fireground channels
Professional Scanner nut. Ibis bin chicken of radio scraps
Scanners:
Uniden 325P2, Whistler TRX-1, GRE PSR800 x 2, Uniden 780 x 3, Uniden 796, Uniden 396 x 2, Uniden 246,
Software:
DSD v2.368, Unitrunker, Trunkview

User avatar
JAFO
Posts: 495
Joined: Fri Aug 15, 2008 10:35 pm

Re: 20/10/2013 - Bushfire Related Logging

Post by JAFO » Fri Nov 01, 2013 6:20 pm

Bring in MDT's for RFS & FRNSW, half the problem solved as far as Radio Traffic is concern.

Half the problem with getting a message over the air theses days is the needless time consuming messages passed by the RFS and FRNSW Crews. MDT's would solve some of the problems by removing the need to Press any PTT to pass Fire Call Address Details, Response, Arrivals and when an appliance becomes available again.

FRNSW Should had brought them in once the trial was over and done with years ago.
JAFO
VK2FGQ

UBCD369XT, UBCD536-PT, UBCD436-PT

Longreach
Posts: 1085
Joined: Mon Aug 25, 2008 7:38 pm
Location: Goulburn NSW

Re: 20/10/2013 - Bushfire Related Logging

Post by Longreach » Fri Nov 01, 2013 6:41 pm

Hi all,

Agreed JAFO, seems to work well for ASNSW and now the police. not perfect die to Next G coverage limitations but the vocie traffic is down due to MDT's. All or nearly all ACT stuff has MDT's (RFS, SES for starters).

Cheers
Matt
VK2MRC

Scotty
Posts: 739
Joined: Sun Dec 20, 2009 2:50 am
Location: Sydney and surrounds

Re: 20/10/2013 - Bushfire Related Logging

Post by Scotty » Sat Nov 02, 2013 4:39 pm

MDT's are for transiting non-urgent messages that do not need to be overheard by others.

In situations where there is a going bush fire I would argue that most messages need to be overheard by others, and as such MDT's would have little to no effect on the radio traffic.

Day to day structure fires attended by FRNSW are a different story, but no good for going bush fires where locations etc are regularly changing and where messages need to be overheard by others.

Can't compare the use of MDT's by fire services in bush fires to the way the ambos and police use them. All urgent messages with the police are still broadcast, only non-urgent messages etc via terminals. Ambos are in a similar situation, where details of jobs are acknowledged over the air so all on the channel can hear, with the details then appearing on the terminal.

centralcoastscanman
Posts: 750
Joined: Fri Oct 31, 2008 7:58 pm
Contact:

Re: 20/10/2013 - Bushfire Related Logging

Post by centralcoastscanman » Sat Nov 02, 2013 8:32 pm

JAFO wrote:Bring in MDT's for RFS & FRNSW, half the problem solved as far as Radio Traffic is concern.

Half the problem with getting a message over the air theses days is the needless time consuming messages passed by the RFS and FRNSW Crews. MDT's would solve some of the problems by removing the need to Press any PTT to pass Fire Call Address Details, Response, Arrivals and when an appliance becomes available again.

FRNSW Should had brought them in once the trial was over and done with years ago.
The same would go for NSW SES as well, the amount of crap i've heard people come across the air with is just wasting grn air time and if its at the same time as a going fire there could be an appliance trying to pass a red message that gets a busy tone or something like that

User avatar
JAFO
Posts: 495
Joined: Fri Aug 15, 2008 10:35 pm

Re: 20/10/2013 - Bushfire Related Logging

Post by JAFO » Wed Nov 06, 2013 9:26 am

Scotty wrote:MDT's are for transiting non-urgent messages that do not need to be overheard by others.

In situations where there is a going bush fire I would argue that most messages need to be overheard by others, and as such MDT's would have little to no effect on the radio traffic.

Day to day structure fires attended by FRNSW are a different story, but no good for going bush fires where locations etc are regularly changing and where messages need to be overheard by others.

Can't compare the use of MDT's by fire services in bush fires to the way the ambos and police use them. All urgent messages with the police are still broadcast, only non-urgent messages etc via terminals. Ambos are in a similar situation, where details of jobs are acknowledged over the air so all on the channel can hear, with the details then appearing on the terminal.
To tell you the Truth Scotty from my prospective I would have to disagree.

Both NSW Fire Services over the past 15 years have got worse as far as their RATEL Procedures are concern as far as I am concern. The Radio Procedure Training in both services these days are designed to tie up radio networks with needless long drawn out voice transmissions, more so on the RFS side of the net.

It use to be very simple in my early days, all transmissions were to be short and to the point to keep the channel open for other users. These days we see longer drawn out messages of up to a minute or longer which just tie up the channel. These fires were the first where I was hearing Comm's telling Crews to phone in their Response and also where Comm's were calling appliance mobile phones to redirect crews to other calls/addresses.

These were small fire's, where high Volume Radio Traffic only ran for a very short time compared to the 1994 Bushfire where High Volume Radio Traffic was consent for 4 to 5 days where all we had were Appliance Radio's - no Portable Radios, No Mobile Phones, and in 2013 we are resorting to Mobile Phone Networks to pass messages . . . mobile phones should be the last resort, not a common part of the comm's network.

The RATEL procedures we see today goes a long way towards contributing to the GRN Failure. In fire like these MDT's would allow crews to be assigned to Jobs, Redirected, pass Code 1, Code 2, Code 3, Code 4, Code 5 messages and even STOP's and Other Operational messages without a single PPT (Voice) Button being pressed, leaving our Channels near 70% free for those "RED" Urgent Voice Messages.

There are more positive outcomes for the introduction for MTD's for end users like me . . . the Crews then there are negatives.

But hy, what would I know, I am only an end user with 24 years and major bushfire -1994, 1997, 2001, 2003 campaign pass experience.
JAFO
VK2FGQ

UBCD369XT, UBCD536-PT, UBCD436-PT

Post Reply