| |
ZL3AI > APRDIG 03.04.04 14:48l 256 Lines 9654 Bytes #999 (0) @ WW
BID : 3089-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 31, 2/2
Path: DB0FHN<DB0FOR<DB0SIF<DB0NHM<DB0ERF<DB0FBB<DB0IUZ<DB0GOS<ON0AR<ON0AR<
VE3FJB<WA7V<VK7AX<ZL2BAU<ZL3VML
Sent: 040403/1135Z @:ZL3VML.#80.NZL.OC #:21893 [Chch-NZ] FBB7.00i $:3089-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Mic-E Packet Help Needed
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 31 Mar 2004 10:42:49 -0500
X-Message-Number: 7
Steve,
Okay! Good information... I'll check on that setting in the KPC-3 when
John gets home to see what the setting is. So I guess the big question is:
How do we fix the problem?
Eric KF4OTN
----------------------------------------------------------------------
Subject: RE: Mic-E Packet Help Needed
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 31 Mar 2004 11:11:50 -0500
X-Message-Number: 8
On 3/31/04 at 10:42 AM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU> sent:
>Okay! Good information... I'll check on that setting in the KPC-3 when
>John gets home to see what the setting is. So I guess the big question is:
>How do we fix the problem?
Only way is to make sure all IGates run with MFILTER off. Be grateful for
the q construct, before that was implemented it was impossible to tell who
IGated these packet...this was in fact a prime impetus the impetus for the
creation of the q construct.
The bad packet you posted cannot even be detected. It is of adequate length
to be a valid Mic-E packet, the Kenwood identifier '}' is a valid
character. Only non-kenwood mic-E packets without comments can be reliably
detected as errors because they come up one byte short.
Steve K4HG
----------------------------------------------------------------------
Subject: RE: Mic-E Packet Help Needed
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 31 Mar 2004 12:53:27 -0500
X-Message-Number: 9
Would this be the same as "FILTER" on the Kantronics firmware? Anyone know?
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: Jeff King <jeff@aerodata.net>
Date: Wed, 31 Mar 2004 12:45:17 -0600 (CST)
X-Message-Number: 10
Quoting David VanHorn <dvanhorn@cedar.net>:
>At 09:48 PM 3/30/2004 -0500, Jeff King wrote:
>>Yeah, I tried that once. Nightmare of shorts and debugging. Now I solder all
>>my SMD's, at least for prototypes, including 25 mil pitch parts.
>
>I've had generally good results.
>Too many shorts means too much paste usually.
>I wouldn't try it on a PCB without soldermask.
I did have a solder mask, the problem was paste that was under a part
didn't get melted and/or solder balls. I'm sure if I had applied the paste
more accurately, I wouldn't have had a problem (like you said, less paste).
But it just about as easy for me to solder each pad as it was to apply
paste accurately to each pad. The paste I was using, in a syringe, it was
also hard to control the flow and I often got more paste then I wanted on
the pad. It was new paste and I had stored it in the refrigerator before
using (but warmed it up). BTW, one little trick I found about paste, it
flows alot better if it is hot, I needed to use a old syringe of it, and by
placing it in some hot water for a while, it flowed really good. Maybe if I
had done that the first time I wouldn't have had a problem?
Willing to try it again, I subscribed to your group yesterday and will take
a look at some of those links.
73
Jeff
----------------------------------------------------------------------
Subject: Re: [OZAPRS] VK email server
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Wed, 31 Mar 2004 14:42:48 -0500
X-Message-Number: 11
I am STRONGLY opposed to having an APRS program automatically line-wrap and
generate MULTIPLE message lines transparent to the user's intent.
I DO believe that the user must be alerted to the maximum 67 character
size, so that he can properly PHRASE what he wants to say in 67 characters
or less. We are COMMUNICATORS and that's why we are her. We should know
and understand what is going on!
BECAUSE: APRS MESSAGE lines are stand-alone and independent and because of
the requirement for an ACK, they are MUCH less reliable. Hence, the
probability that ONE line will get though can be almost an order of
magnitude greater than having two lines successfully ACKED.
Thus, letting a stupid computer do stupid things for "communicators" such
as blindly chopping up knowledge into multiple lines when the sender is
oblivious to the GREAT difference in delivery probability is BAD for APRS
operations.
Imagine the message:
At water stop 18 we despirately need more blankets. Please send us
20 more
And then to have the FIRST line delivered in seconds, but the second line
that requires a successful ACK to the first one before it can be delivered,
arrives 10 minutes later.
Please, if any APRS software is doing line wrapping, please educate the
author! (and of course the users!)
de WB4APR, Bob
>>>"John Williams" <vk5zty@bigpond.com> 3/31/04 6:07:44 AM >>>
The way I understand it is that aprs messages contain 0 - 67 chars in the
message field.
If your aprs client allows you to go beyond 67 chars then it places the
additional text in another packet.
The aprs email server would then need to know if the packet is a
continuation packet for the same email address or another message addressed
to another email address.
I have not tried to send an email longer than the allowed length to the
other servers. Do the current servers process such messages.
Richard VK3JFK suggested the > char as an indication that more text was to
follow.
Aprs uses un-numbered info frames so the only possible way to determine
packet sequence is via the ack field. This is not necessarily numeric but
if it is lexigraphically sortable then this field can be used to assemble
received packets in sequence.
You need to consider that packets may not arrive in order. Packets might
be sent by other stations and seen by the server while you are still
sending your message text.
What I currently do is check that the first part of the message is an
attempt at a valid email address. If it is, grab it then the message text
and send an ack to the sender. The email is then sent.
Anything without a valid email address in the beginning of the message is
rejected.
Using a continuation character would then let the server know to expect
more text. Then we would need an end of message sequence. FBB uses /ex but
it really could be anything unique.
I would be interested in any ideas of way around not using a continuation
flag and end of message flag. Given that you cant guarantee the arrival
order of packets or the intention of the people sending messages.
Cheers
John
VK5ZTY
On 29 Mar 2004 at 12:34, Robert Bruninga wrote:
>>>>"John Williams" <vk5zty@bigpond.com> 3/27/04 9:50:53 PM >>>
>>
>>I am testing an aprs email server...
>>The aprs spec only allows 0 - 67 characters in the
>>message field which includes the email address.
>
>I would not object in this instance, since we know that
>the first part of the Email Message is an EMAIL address,
>and that part of the message, after being parsed out
>and used for addressing, is no longer part of the "message"
>content, therefore, that the next 67 bytes AFTER the email
>address may be retained.
>
>Thats a messed up wordy sentence to ssay that these
>might be the best rules for an Email ENgine:
>
>1) If APRS message is less than 67 then use as is.
>2) If APRS message is longer than 67, then remove the
> email address from the body and send what's left
>3) If that is still more than 67 bytes, then truncate.
>
>BUT wait.... hummh... at this point, the message is
>no longer on APRS anyway, but is in Email, so
>why do we need to truncate it at all?
>
>de Wb4APR, Bob
----------------------------------------------------------------------
Subject: FW: [ui-view] RE: Mic-E Packet Help Needed
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 31 Mar 2004 15:42:27 -0500
X-Message-Number: 12
John is the one running UIV with KPC-3 in KISS mode.
-----Original Message-----
From: Roger Barker [mailto:roger@peaksys.co.uk]
Sent: Wednesday, March 31, 2004 14:03
To: ui-view@yahoogroups.com
Subject: Re: [ui-view] RE: [aprssig] RE: Mic-E Packet Help Needed
I'm losing track of this thread because it seems to have another life in
another list, but if "John" is the person running UI-View32 with a KPC-3 in
KISS mode, then none of the TNC terminal mode commands have any effect on
the way the packets are decoded. So the setting of FILTER or MFILTER cannot
possibly be relevant.
Christensen, Eric wrote on 31/03/2004 18:53:
>Would this be the same as "FILTER" on the Kantronics firmware? Anyone
>know?
>
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Sent: Wednesday, March 31, 2004 11:12
>To: TAPR APRS Special Interest Group
>Cc: 'TAPR APRS Special Interest Group'; 'Kevin Otte';
>'jojohnson@tritonpcs.com'; 'ui-view@yahoogroups.com'
>Subject: [aprssig] RE: Mic-E Packet Help Needed
>
>On 3/31/04 at 10:42 AM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU>
>sent:
>
>>Okay! Good information... I'll check on that setting in the KPC-3
>>when John gets home to see what the setting is. So I guess the big
>>question is: How do we fix the problem?
>
>Only way is to make sure all IGates run with MFILTER off. Be grateful
>for the q construct, before that was implemented it was impossible to
>tell who IGated these packet...this was in fact a prime impetus the
>impetus for the creation of the q construct.
>
>The bad packet you posted cannot even be detected. It is of adequate
>length to be a valid Mic-E packet, the Kenwood identifier '}' is a
>valid character. Only non-kenwood mic-E packets without comments can
>be reliably detected as errors because they come up one byte short.
>
>Steve K4HG
---
END OF DIGEST
Read previous mail | Read next mail
| |
