[drats_users] Possible Who Is Online feature request

[Nate Duehr]

On Tue, 21 Apr 2009 13:49:35 -0700, "Dan Smith" <dsmith at danplanet.com>
said:
> > Doesn't have to be that tricky.  You could send any known message
> > (known to both sides, hard-coded into the app) and determine whether
> > or not it's being received correctly at the far-end.
> 
> Right, I understand the principle :)
> 
> I'm saying that it's difficult to know where it starts and stops, and
> if the start/end markers get blown, then it's hard to calculate the
> error rate.  If you assume a quiet channel and a coordinated "I hit
> receive, now you hit send" sort of scenario, then that helps.  It's
> still kinda ugly.

I hear ya.  In telco, there are a number of pre-defined test patterns
that start/stop can easily be found via mathmatical functions... so if
one "sequence" is blown, the whole sequence is marked "bad", and the
next "start of frame" sequence is looked for.  

<http://www.telect.com/downloads/ResourceCenter/Copper%20Connectivity%20Patch%20Panels%20Systems/T1-DS1-E1%20Installation%20and%20General%20Usage/DS1%20Digital%20Test%20Patterns.pdf>

Problem is, at 1200 bps... most of these would take a long time... 

Ultimately, since you're trying to determine if communications can even
be done over the D-STAR RF "circuit", blown start/stop frames after a
small "Hey you, I'm going to send you a test pattern" frame that's easy
to detect (a large frame of all the same character, perhaps... even if
part of it gets blown, if you see 80% of that single character, you know
what follows is a test pattern)... would make it simpler to tell if the
communications link is "good" or "bad" with pretty good accuracy.  

(Of course, in RF things get squirrelly when someone's moving, or
there's multipath that changes over time, or ... you know already.  Just
reiterating it for anyone reading along who hasn't been-here-done-this
already.)

Hmm, now that I think about it... that's another simpler thing... a test
pattern is always just an enormous packet with all the same characters
in it... LOL... then if you see a packet "big enough" (pick a size) and
with at least 80% "test characters" you know immediately at the far end
that the thing got hammered.  If the far end NEVER responds (you can't
even detect 80% of the characters are the test character), the link is
so crappy it can't be used anyway, and you tell the end user... "No way,
Jose!" for the results of the test.

Just brainstorming.  I'm no protocol engineer, so just thinking up
"simple" ways to implement, probably not GOOD ones!  Heh heh.  KISS is
good though... because if the packet gets hammered and the "show bad
packets" is on, people can be trained to see "wow, that's a really nasty
looking test packet there Bob... who'd you try to send that to?  You're
not even close to being into the repeater from there!"  I guess.

(I'm probably hoping that people "get it" more than some do... but with
a little training... who knows?)

> The other thing I can do is have the new echo ping try to inspect
> received echo packets even if the checksum fails (assuming the
> packetization markers survive) and calculate the error rate of the
> contents...  It would require some layering violations in my current
> stack though... :)

Hmm, I thought there was some bug in the Echo that you don't always get
back what you sent into it?  (I could be WAY wrong there, but I seem to
recall something about that in a list somewhere, many moons ago...?)

> But, if you just care about how many were received intact, then it's
> exactly like a ping.  If my "connectivity test" has the ability to
> send, say, 10 packets of very small size (32 bytes perhaps) and show
> you how many come back, is that good enough?

Yeah, that'd work!  (GRIN!)  I guess it doesn't really matter... could
start with small and ramp up as you originally were thinking.  What'd be
really interesting is a way to automate it for someone "right on the
fringe" where it'd try small stuff, then make it bigger and "see" if
things got worse (which they would if the person was having only a VERY
slight amount of lost bits).  Thinking through it, this is one of the
hardest parts of this whole thing -- none of us really has any good way
to test our repeaters.  The Echo thing would be useful to benchmark even
different repeaters with a test radio, a bunch of attenuation, and
plugging right into the repeater's receiver... we could see if the
repeaters all have similar characteristics, and also do an ISO-T or
Directional Coupler type test with the receive antenna attached to see
if the system is desensing itself or suffering from other "outside"
factors at the mountain... by slowly de-coupling the digital signal and
seeing where a "well-working" system falls apart, then using those
numbers as a comparison to other more "questionable" repeater systems. 
In other words... a laptop with D-RATS in some new test mode, and a
well-documented carefully done RF injection test at a repeater site
could become the "gold standard" way to test a repeater system for
receiver sensitivity/performance... Interesting!

> Well, on a 91/92 you could, yes, but it would get ugly and wouldn't be
> fast enough to really do carrier-sense in the way that would be
> helpful for multiple access.  The radio does that itself, where it
> won't transmit when the busy indicator is lit.  Even still, it isn't
> fast enough and regularly steps on other stations.  The repeater makes
> it worse because there's 2 seconds of delay at times and you can't
> hear the other stations.  So you think the channel is free for a
> second and start transmitting, but another station has already been
> keyed for a while.  It's hard :)

Yeah, understand.  Not quite the benefit that was seen in Packet by
getting everyone on a high-mountain repeater... that switching was
always fast enough that it helped eliminate the "hidden node" problem
where one station can't hear the majority of others communicating
direct, while not really adding that many more collisions.  The Icom
repeaters are bloody SLOW to detect a valid signal, and that signal is
quite delayed just passing through the repeater, let alone going through
the Gateway or to other places.

> The 880 and 80 will not have rig control and none of the other mobiles
> have it.  Only the 91, 92, and ID-1.

Weird.

> > Automatic?  I was just talking about manually forced routes...
> 
> Ah, okay, that's part of what I have planned.

Cool... :-)

Nate 
--
  Nate Duehr
  nate at natetech.com