[aprssig] Local Event using RELAY?

Robbie - WA9INF mwrobertson at comcast.net
Mon Mar 28 12:56:21 EST 2005



Robert Bruninga wrote:
>>>>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.
> 

He did not make that statement Bob.

> 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.
> 

He did not say how busy 144.390 was excluding DIGIs, just that his 
tracker would not be able to reach a digi, thus he was going to use his 
TMD-700 to help his tracker, which was a terrific idea, and a lot of us 
have done just that and caused no problem.

> 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.
> 

If there was a home station nearby, then the TMD-700 RELAY would not 
have been needed.. The home station's callsign could be used.

> 
>>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.
> 

You never gave the impression that he should have considered anything, 
just do it because you say so.. One should consider transmitting 
anywhere without listening first. QRM'ing a digipeater or another mobile 
or small home station on a handheld or whatever has as much right to be 
transmitting as the "I don't care!" TMD-700 transmitting with 50 watts 
or more than likely..

> 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...
> 

Then give more things to consider for someone than to do it a certain 
way like you did below responding to me..

> 
>>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.
> 

If it were  one or two trackers involved, but then it still does not 
justify having to use 144.990 in the first place. You are still wanting 
someone to transmit blind on 144.390 regardless of other users.

> I agree, if it was not in a remote area,

He did not state "a remote area", just that he could not reach a WIDE 
digipeater with his tracker

> 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.
> 

Crossband without monitoring the transmitting frequency is not correct, 
period, no excuse. Further more, only you have stated there is a need to 
qsy off 144.390 for events! I know others have around our area, but not 
for the reason of their being interfered with, but mainly to cut down 
the distractions of normal APRS activity and having to use the extra 
SPECIAL or ALTNET configurations.

Anyway, I gave my opinion for what its worth, <g>

Robbie

> 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
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
> 






More information about the aprssig mailing list