[aprssig] Local Event using RELAY?

Robert Bruninga bruninga at usna.edu
Mon Mar 28 12:15:56 EST 2005


>>> mwrobertson at comcast.net 3/28/05 11:47:58 AM >>>
>That then makes the [mobile event digi] transmit on 144.390 
>without listening first and thus qrm'ing anything else on 
>144.390. That is not the right way to operate period.

Too many angeles on that pin, I am sorry to say...
You are not looking at the big picture and not seeing
the forest for the trees.  Its just common sense.

1) At the scene, the ONLY thing the mobile digi could  hear
by listening on 144.39 will be the distant digi.  Thus the ONLY
thing it can avoid colliding with is the distant digi.

2) If he colides with the digi, then no one else is impacted
since no one else is in direct range to hear his event digi 
anyway.   His own mobile digi is the only thing that suffers 
in the collision and since it is not set up to relay or even care
about what is on the distant digi, again, nothing is lost and
no one outside the event is impacted.

3) If there is a home station nearby, that transmits once ever
30 minutes, then he could collide with that.  But that is one
chance in 1800, or 0.006.  That probability is so low as to
be insignificant compared to the 100% improvement in
operation of the event.

>We have had this discussion before, and others agreed. 
>If there is no  other transmission being heard by a station, 
>it is assumed ok to transmit, but just to turn on without 
>listening for a signal is wrong.

Yes, and no.  It all depends on careful and thoughtful
consideration of the scenario.  Yes it would be wrong
and stupid to put a mobile digi on a hill in the center
of a city that does not listen first.  But the difference 
between that situation which is "wrong" and the remote
event in the middle of nowhere where there is not one
single non-event station within miles that can even hear
the mobile digi direct, then it is a NON problem.

What we have to do is get people to *think*, not just
plug-n-play.  For every "right" way that you can insist on
something there is always a way to use it "wrongly".
Thus, one has to think and consider applications when
one is tryping to apply platitudes...

>If the event stations on 144.990 were to be transmitting 
>at a fast rate, and 4, 5 or more units, then the TMD-700 
>would be constantly key down irrespectful of other activity 
>on 144.390.  

No, at a fair rate of say 1 packet per minute and one 
tracker or two trackers which was the original scenario
then it would be one packet every 30 secs average
or only 0.03 of channel capacity.  Again, that was the
scenario.

I agree, if it was not in a remote area,
if it was more than a few trackers
if they were using high rates
if the mobile digi was on a hill in a busy area
if the area was full of other activity that could be heard
direct, etc, etc,

Then the cross band mobile digi might not be the best
idea for the reasons you mention.  But in this case
of one or two trackers in a confined remote area
it is essentiall zero additional impact to anyone while
assuring orders of magnitude overall better success
rate.

de WB4APR, Bob


To suggest that others do this is not correct.

Robbie

Robert Bruninga wrote:
>>>>Boyd D Garrett Sr <N5CTI at texasnative.com> >>
>>
>>I plan to support a public service event from my bicycle.
>>(TH-D7)... so Net Control can track my position. I ...have 
>>virtually no chance of getting into a WIDE digi ...
>>so I plan to have my truck in the vicinity with my 
>>TM-D700 set for RELAY digipeating.
> 
> 
> Then I would set your mobile DIGI to RELAY but set it
> to listen on 144.99 and TX on 144.39.  Then operate
> all trackers at the event on 144.99.  That way they
> get a 100% clear channel and yet the event and
> everything else shows up on 144.39
> 
> Bob
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
> 
> 



_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig




More information about the aprssig mailing list