| |
ZL3AI > APRDIG 25.03.07 08:04l 132 Lines 5798 Bytes #999 (0) @ WW
BID : 9927-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 33 #21, 1/1
Path: DB0FHN<DB0MRW<DB0ERF<DB0EAM<DB0SMG<DB0RES<ON0AR<ZL2BAU
Sent: 070325/0432Z @:ZL2BAU.#79.NZL.OC #:39386 [Waimate] $:9927-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Today's Topics:
1. e: [aprssig] D7's,D700's and TinyTrak (Alex Carver)
2. Re: javaprs port that doesn't send a "keepalive" packet? (Gregg Wonderly)
3. Re: javaprs port that doesn't send a "keepalive" packet? (Matt Werner)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Mar 2007 22:34:43 -0700 (PDT)
From: Alex Carver <agcme2002_at_yahoo.com>
Subject: e: [aprssig] D7's,D700's and TinyTrak
What I found insulting was being told I was behind the times when I didn't
say (on purpose) exactly how I was implementing my design and that someone
already tried it. So what? Trying it again is a waste of time, is that
what I am to infer from that comment?
Keep in mind the words you used: "it had been done years ago". Lots of
things can change in "years" especially in the microelectronics realm. New
designs for ASICs come out all the time. I'm sure the MAX232's and other
related hardware have gotten some updates between now and then. Even
Parallax has had some upgrades with things like bigger Basic Stamps and
their Javelin Stamp running a subset of Java.
The BS2 could have serial ports if I choose to use a bit-banging method of
serial. It does not, however, have the ability to do serial I/O on more
than one pin simultaneously which is what I desire hence the reason not to
use it. Parallax documents such in their Basic Stamp manuals. Only one
serial I/O instruction can occur at a time. So the code would have to be
extremely streamlined in order to catch any data appearing at any "port".
I'm aiming for essentially several serial drivers with small buffers on one
or two buses to shift data around from the various devices attached.
You're right, that will require something a bit more powerful than a BS2
though I doubt I'd even think of doing it with a PIC either. I'm trying to
decide whether I want to use an Altera or an Intel.
Peer review is one thing. Insults and just saying "well, it didn't work
last time, so it probably won't work this time" is not peer review, that's
just laziness. Had it been worded something like, "You know, so and so did
this a few years ago but it didn't work well for him. I am, however,
curious about what you have thought that you feel will work better." is far
more inviting than what was actually written.
What I won't bother with is explaining the idea to you. You've already
established that you believe any attempt at a microcontroller addition to
the D700 is faulted and not worth the effort then or now. So why expend
the effort to explain it to you?
Of course, having purposefully inserted an insulting comment (and saying
so) into your reply is a pretty good measure of your character.
>Date: Mon, 19 Mar 2007 18:47:32 -0400
>From: "Brian B. Riley" <brianbr_at_mac.com>
>Subject: Re: [aprssig] D7's,D700's and TinyTrak
>To: TAPR APRS Mailing List <aprssig_at_lists.tapr.org>
>
>Whooee, you must have thin skin if you found that insulting.
>
>Now a PICAXE 08M could have 3-4 serial ports and that is the little 8
>pin critter. A BS2 has 16 pins and theoretically each of them could
>do serial. If you consider a 'port' to be to be bidirectional, at two
>pins per 'port' that gets you 8 ports on a BS2. If you are rolling in
>bucks you could do a BS2P40 and that has 32 i/o pins and that would
>get you 16 ports.
>
>That said, for anything beyond Wes' original implementation you are
>right that a Stamp won't do the job. However, it doesn't have
>anything to do with the number of ports. A Basic Stamp, even the on-
>steroids BS2PX would have a hernia handling serial i/o on several io
>ports simultaneously.
>
>I went back and reread your explanation and appears to me only to add
>more complexity without ever addressing the original flaw which lies
>in how the D700 does things... and before you run off with your
>jockey shorts in a knot (yes that is mildly insulting) what I am
>doing is criticizing what I saw as flaws in your proposal and
>pointing out that it had been done years ago and found lacking. If
>you and your idea cannot stand up to peer review then why should
>anyone take it serious? If indeed you have thought of a better way
>then restate your thesis and show us how it resolves/bypasses the
>underlying D700 problem.
------------------------------
Message: 2
Date: Wed, 21 Mar 2007 08:50:01 -0500
From: Gregg Wonderly <gregg_at_wonderly.org>
Subject: Re: [aprssig] javaprs port that doesn't send a "keepalive" packet?
AE5PL Lists wrote:
>TCP keep-alives were looked at but do not provide the granularity needed
>for APRS-IS.
Is this because of TCP default timing, or something else?
>Also, there are a number of (not broken) clients that look
>for data from the server to be assured that the connection to the server
>is still valid.
I understand that there are also clients which want "everything" and try
hard to reestablish a new connection in the event of server malfunction
(software or otherwise). Because this is not a transactional system, any
attempts to resolve the lost data problem are just best effort. So, I am
just curious what the real need is such that the keep alive traffic is a
must have vs selectable filter.
Gregg Wonderly
------------------------------
Message: 3
Date: Wed, 21 Mar 2007 08:59:38 -0500
From: "Matt Werner" <kb0kqa_at_gmail.com>
Subject: Re: [aprssig] javaprs port that doesn't send a "keepalive" packet?
Perhaps being able to send the server a command (similar to a filter
command) to change the default keep-alive for that port to something
else (or 0 to shut it off)?
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 33, Issue 21
Read previous mail | Read next mail
| |
