| |
ZL3AI > APRDIG 03.04.04 13:41l 255 Lines 9840 Bytes #999 (0) @ WW
BID : 3088-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 31, 1/2
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040403/1128Z @:ZL3VML.#80.NZL.OC #:21889 [Chch-NZ] FBB7.00i $:3088-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Wednesday, March 31, 2004.
1. Re: New tracker design suggestions & Trimble info
2. Re: New tracker design suggestions & Trimble info
3. Re: New tracker design suggestions
4. Re: New tracker design suggestions
5. Mic-E Packet Help Needed
6. Re: Mic-E Packet Help Needed
7. RE: Mic-E Packet Help Needed
8. RE: Mic-E Packet Help Needed
9. RE: Mic-E Packet Help Needed
10. Re: New tracker design suggestions
11. Re: [OZAPRS] VK email server
12. FW: [ui-view] RE: Mic-E Packet Help Needed
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions & Trimble info
From: Derek Koonce <redderek@jps.net>
Date: Tue, 30 Mar 2004 21:25:19 -0800 (GMT-08:00)
X-Message-Number: 1
For long battery life, the LEDs should be an option and not be active. I
agree.
I have been attending the Electronica show in San Francisco this week and
talked to the Trimble rep regarding the small GPS receiver. I found out the
1-50 pricing for the Lassen SQ module - $xx. The antenna for this is $xx.
The sales person said I can pass his name out on this list so that people
can contact him about purchase if desired. [commercial content deleted]
There is also another company, LeadTek. But I do not have pricing at this
time. The link to their units is http://www.leadtek.com/gps.html
For SAR work, just having a simple tranamitter unit for each team could be
an easy implementation - GPS receiver, TinyTrak (or similar) module,
antenna, radio. Everything, except radio, could be under $100. This would
be VERY small to the point that one could integrate the TT, GPS, antenna
into the top of a hat. A bit of conformal coating would then provide the
weatherproofing if the unit is under the fabric of the hat. -- Just some
wild thinking on implementation for the field. Oh, batteries not included
yet in this thought process, but in the works.
Derek
KE6JTP
-----Original Message-----
From: Jeff King <jeff@aerodata.net>
On Tue, 30 Mar 2004 14:51:37 -0800, Scott Miller wrote:
>>Absolutely, the LEDs on my printer eat more than the printer, when
>>it's
>sleeping. In fact, all five on is equal to the drain of the two
>ATMEGA128's, and the rest of the logic running at full speed.
>
>I think I'm going to make all of the LEDs, power included, software-
>controlled. Even when 'on', the LEDs can be pulsed rapidly in the
>timebase interrupt routine to save power, they could be set to
>'blink' only, or they could be completely shut off.
I think I was reading the other day on the CCS message board where someone
suggested "high brightness" LED's as a way to save power. Apparently, the
poster claims they are still quite bright at 200uA. See:
http://www.ccsinfo.com/forum/viewtopic.php?t=18730
in cyril's post.
The PWM idea is also a good one, because you then could use a much smaller
resistor and put more power into the LED while keep the average current
low... heck maybe replace the resistor with an inductor and recover some of
the energy assuming the pulse was short enough! I guess one can take this a
bit too far, but you get my drift.
73
Jeff
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions & Trimble info
From: Dale Blanchard <wa7ixk@arrl.net>
Date: Tue, 30 Mar 2004 21:36:40 -0800
X-Message-Number: 2
Derek Koonce wrote:
>For long battery life, the LEDs should be an option and not be active. I
>agree.
>
>I never look at the LED after I get it working. I put a pair of jumper pins
on my last TT 3. I just pull the jumper and turn them all off. I would
like one of those tiny
push on /push off switches that fit the jumper pin spacing on the board.
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: John <bigjohn45@cox.net>
Date: Wed, 31 Mar 2004 09:08:08 -0500
X-Message-Number: 3
At 05:57 PM 3/30/2004, you wrote:
>At 02:51 PM 3/30/2004 -0800, Scott Miller wrote:
>
>>>Lexan overlays are easy for this.
>>>As many holes as needed in the metal, and then self-adhesive lexan over
>>the top. It seals pretty well, at least rainproof.
One idea for a waterproof on off switch might be to find a circuit similar
to the one in my electronic dog training collar. It uses a magnetic switch
that is internal to the sealed box. Bringing a magnet within about 3-5mm of
a red dot on the box causes it to beep for about 8 seconds then turn on or
off depending on prior state. The same box has a small micro sized led
that has six states GREEN BLINK, YELLOW BLINK, RED BLINK, RAPID FLASHING
RED, RAPID FLASHING GREEN, OFF.
OFF
GREEN BLINK [BATTERY OK STANDBY]
YELLOW BLINK [BATTERY LOW OR AWAITING PROGRAM CODE AFTER CHARGING]
RED BLINK [BATTERY TOO DEAD TO WORK]
Then when receiving commands from the remote it has two states.
RAPID FLASHING RED [training shock being delivered]
RAPID FLASHING GREEN [training tone being delivered]
The collar uses a rubber plug to seal the charger hole that is the only
potential water leak site. The dog often swims with this thing on and over
the past year it has worked great.
I just offer this as food for thought.
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: David VanHorn <dvanhorn@cedar.net>
Date: Wed, 31 Mar 2004 09:14:26 -0500
X-Message-Number: 4
At 09:48 PM 3/30/2004 -0500, Jeff King wrote:
>On Tue, 30 Mar 2004 16:17:02 -0800, Scott Miller wrote:
>>>The "easy-Bake" SMD production method is somewhat labor intensive,
>>>but
>>very cost effective for small quantities.
>>
>>You mean doing reflow with a toaster oven, like this:
>>http://www.seattlerobotics.org/encoder/200006/oven_art.htm ?
>
>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.
----------------------------------------------------------------------
Subject: Mic-E Packet Help Needed
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Wed, 31 Mar 2004 10:19:28 -0500
X-Message-Number: 5
2004-Mar-31 09:54:25 (UTC) KB4TOH-13>S5QT6V,K4ROK-10*,WIDE,KE4TZN,I:'i?6l
k/]"4"}
2004-Mar-31 09:54:26 (UTC)
KB4TOH-13>S5QT6V,K4ROK-10,KD4PBS-3*,qAR,N8VNR-1:'i?6l k/]"4"}
I noticed a problem on the network last night. When one station (actually
it was occurring with other station's Mic-E packets as well) was sending a
Mic-E packet out it was hitting two I-Gates (as sometimes happens). This is
when I started noticing that the dup suppression on the IS wasn't filtering
one of them out. On a closer look, I noticed that the packet received and
processed at N8VNR-1 has an extra space in the Mic-E portion of the packet
compared to one heard by KE4TZN. I looked to see if this was happening to
"regular" packets but I did not see this occurring.
I queried both stations to get software/hardware information:
KE4TZN: KPC-3 and UI-View32 V1.99. Verified that the TNC had 8bitconv ON
and that his modem was in KISS mode.
N8VNR-1: APRSd v2.2.5. No other information was confirmed at this station
at this time.
So, my question is:
1) Which packet is correct?
2) If it is an added space (which I suspect) what does this do to the packet
on decode? If it is a deletion of a character, why is it occurring and,
well, I can guess what that does to the data.
3) Is this a known issue?
An obvious problem would be the fact that more than one packet is making it
through the IS Servers and are not being duped out, which adds to the IS
load and to the load of the databases that are gathering the data.
DISCLAIMER: Callsigns left in for later support. I am not blaming a
specific user but rather trying to narrow down a problem so that if it is a
software issue it can be fixed.
Thanks,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: Mic-E Packet Help Needed
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 31 Mar 2004 10:37:36 -0500
X-Message-Number: 6
On 3/31/04 at 10:19 AM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU> sent:
>1) Which packet is correct?
>2) If it is an added space (which I suspect) what does this do to the packet
>on decode? If it is a deletion of a character, why is it occurring and,
>well, I can guess what that does to the data.
>3) Is this a known issue?
Last question first, yes this is a known issue, as old as the APRS Internet
System. The problem is not an added space but rather a deleted non-printing
character (NPC). If you look at the findU data:
KB4TOH-13>S5QT6V,K4ROK-10*,WIDE,qAr,KE4TZN:'i?6l k/]"4"}
what you saw as a space shows here is a box, showing it is an NPC. This is a
problem that popped up as soon as the APRS IS was created, and I made the
incorrect conclusion that the trouble was in the internet system, which is why
the recommendation was made to convert the packets to "normal" APRS position
packets, a recommendation which, though long recinded, still haunts us.
The problem is actually usually in the TNC settings for the IGate, I
believe the offending parameter is MFILTER, which removes NPCs.
>An obvious problem would be the fact that more than one packet is making it
>through the IS Servers and are not being duped out, which adds to the IS
>load and to the load of the databases that are gathering the data.
These are minor issues compared to the fact that the shorter report cannot
be interpreted correctly (some, but not all, of these can be detected and
fudged to be closer to where they really are).
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
