| |
ZL3AI > APRDIG 01.04.04 14:13l 259 Lines 10702 Bytes #999 (0) @ WW
BID : 3073-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 29, 2/7
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<JE7YGF<LU6DTS<ZL2TZE<
ZL3VML
Sent: 040401/1157Z @:ZL3VML.#80.NZL.OC #:21750 [Chch-NZ] FBB7.00i $:3073-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: older Trimble GPS receiver
From: Doug Bade <doug@clecom.com>
Date: Mon, 29 Mar 2004 12:17:45 -0500
X-Message-Number: 8
You can flash them to NMEA with files off the trimble ftp site... save
yourself a lot of grief.... You will need the hardware revision to get the
correct flash files. It is probably an S-VEE-Six engine inside... I have
some expeience flashing them, and probably all the files if you need them,
and cannot get them from trimble..
Doug KB8GVQ
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 29 Mar 2004 09:23:48 -0800
X-Message-Number: 9
>1) An extremely low-power digi, that we can throw into an ammo-can
>with a low-current handheld and a gell-cell.
Yeah, that's one of the planned uses. I've been considering a built-in NiMH
charger circuit. Probably not worth it though, considering you still have
to power the radio and doing that with a gel cell in an ammo can is fairly
easy to do.
>2) Something that implements what you talked about way back when,
>before you started the OpenTrac project: The capability for the
>portable trackers to keep a detailed log, then blast that log back
>to base whenever a path is found, including the capability for any
>of the portable trackers between you and base to function as relays.
Yep, that's certainly on my list. In fact, I'll probably have a specialized
firmware written just for SAR. Storing track logs on the MultiMediaCard
would be useful too - when teams return to the command post, you can save
time by just pulling the cards rather than having to hook up each GPS
receiver and do a download.
>3) Capability to plot positions of other units as waypoints on the
>Garmin map screen (as the Kenwoods, the anti-tracker, and Xastir can
>do).
Yeah, that's what I meant by anti-tracker functionality. If only there was
a way to get the Garmins to display areas...
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: David VanHorn <dvanhorn@cedar.net>
Date: Mon, 29 Mar 2004 12:39:33 -0500
X-Message-Number: 10
At 09:23 AM 3/29/2004 -0800, Scott Miller wrote:
>>1) An extremely low-power digi, that we can throw into an ammo-can
>>with a low-current handheld and a gell-cell.
>
>Yeah, that's one of the planned uses. I've been considering a built-in
>NiMH charger circuit. Probably not worth it though, considering you still
>have to power the radio and doing that with a gel cell in an ammo can is
>fairly easy to do.
Twice the weight for same power, or half the power per unit volume though.
NIMH charging isn't too hard, but start with fully spec'd cells.
Sanyo "C" series cells can be used with Nicad charger circuits, long term
low overcharge dosen't bother them much.
Radio power is interesting as well. Lowest possible current on receive, not
very important what it draws on transmit.
Maybe no receiver at all, though you pay for it in collisions.
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 29 Mar 2004 09:40:29 -0800
X-Message-Number: 11
>A NIMH pack, and switching regulators would be a huge improvement in any
>low-power project. A linear reg, taking 12V to 5W wastes more power in heat
>than it delivers to the load. The long term consumption is far more
>important than the short term transmit pulses.
>A switcher is typically 90%+ efficient. Linears win again at extremely low
>currents where the static drain of the switcher becomes significant.
My main concern with a switcher is noise. Shouldn't be too big a deal,
though. The modem section is already has lots of decoupling, and the rest
isn't that sensitive.
MOST of the design will run on 3.3 volts. The only thing that'll need 5
volts is the (optional) LCD. With the LCD off, I think you might even be
able to get it down to 2.7 volts or so. Since it'll have the option of
powering the system using the 5 volts supplied by the USB port, it'll need a
low-dropout regulator of some sort to get the 3.3 supply. I haven't really
worked on the power supply design yet.
>In my printer project, my drain while printing is 3-10A from a small nimh
>pack. But the largest part of the power budget, in it's four day lifetime
>after charge, is the 3mA that the sleeping system draws.
The CPU's power consumption will depend greatly on how much of the time it's
busy doing something, which will depend on how the system is configured. 1
ma average for the CPU alone is probably reasonable. The modem will need
about 3 ma. With the USB system shut down, the other components should be
under 1 ma. So say the spec sheets, anyway. At any rate, it should be
under 10 ma. Much less than the idling radio will probably draw. A backlit
LCD would kill that, though.
>Not a bad idea, as long as you max out the number of positions reasonably.
>Also, timestamping could be a bit wierd.
>You will be heard more often than you think you are, so you'll essentially
>be saying "I'm back over there again". A timestamp IN the original packet
>would have been a good idea, way back when the protocol was designed.
The OpenTRAC protocol is specifically intended to do this. It's got compact
timestamps and supports sequence numbers, so you can go back and 'fill in'
missed reports later without clients thinking you're reporting new data.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 29 Mar 2004 09:47:00 -0800
X-Message-Number: 12
>Twice the weight for same power, or half the power per unit volume though.
Well, I've got samples of Li-Ion charger chips around here too. Not sure
that I want to get into that, though.
>Radio power is interesting as well. Lowest possible current on receive,
>not very important what it draws on transmit.
>
>Maybe no receiver at all, though you pay for it in collisions.
Makes a lousy digipeater, though. =]
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: "Curt, WE7U" <archer@eskimo.com>
Date: Mon, 29 Mar 2004 09:49:13 -0800 (PST)
X-Message-Number: 13
On Mon, 29 Mar 2004, David VanHorn wrote:
>At 09:23 AM 3/29/2004 -0800, Scott Miller wrote:
>
>>>1) An extremely low-power digi, that we can throw into an ammo-can
>>>with a low-current handheld and a gell-cell.
>>
>>Yeah, that's one of the planned uses. I've been considering a built-in
>>NiMH charger circuit. Probably not worth it though, considering you still
>>have to power the radio and doing that with a gel cell in an ammo can is
>>fairly easy to do.
>
>Twice the weight for same power, or half the power per unit volume though.
>
>NIMH charging isn't too hard, but start with fully spec'd cells.
>Sanyo "C" series cells can be used with Nicad charger circuits, long term
>low overcharge dosen't bother them much.
>
>Radio power is interesting as well. Lowest possible current on receive,
>not very important what it draws on transmit.
>
>Maybe no receiver at all, though you pay for it in collisions.
That's fine for _some_ portable trackers (although not what I envision
long-term for SAR), but doesn't work for a repeater, which was what the
ammo-can setup I mentioned is for.
The same setup (ammo-can with TX/RX radio/TNC) can be used as a
quick-to-setup mobile rig for SAR, so we can move it to whatever vehicle
we're using at the time. There it's better to use a gel-cell, a
cigarette-lighter plug, and a mobile rig though.
I'd like to see TX/RX for portable trackers as well, so that the positions
of nearby teams can be displayed on the Garmin map screen. Yes, this
involves more complexity in the TNC and radio, and higher current
consumption hence extra battery weight, but I think it's worth it.
Those that don't want to pay the cost/weight penalty can run something more
like the pockettracker (TX-only radio/TNC) and a GPS.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: New tracker design suggestions
From: David VanHorn <dvanhorn@cedar.net>
Date: Mon, 29 Mar 2004 12:56:54 -0500
X-Message-Number: 14
>My main concern with a switcher is noise. Shouldn't be too big a deal,
>though. The modem section is already has lots of decoupling, and the rest
>isn't that sensitive.
If done right, you won't see any noise. I used to design both modems and
SMPS, and ours were low signal level modems. <30dBm or less.
Proper bypassing, and grounding the bypasses to the proper point solves
most of it. Buck topology is pretty quiet too.
>MOST of the design will run on 3.3 volts. The only thing that'll need 5
>volts is the (optional) LCD. With the LCD off, I think you might even be
>able to get it down to 2.7 volts or so. Since it'll have the option of
>powering the system using the 5 volts supplied by the USB port, it'll need
>a low-dropout regulator of some sort to get the 3.3 supply. I haven't
>really worked on the power supply design yet.
5-3 isn't really LDO territory, you have 1.7V margin.
An LDO wouldn't hurt.
>>In my printer project, my drain while printing is 3-10A from a small nimh
>pack. But the largest part of the power budget, in it's four day lifetime
>after charge, is the 3mA that the sleeping system draws.
>
>The CPU's power consumption will depend greatly on how much of the time
>it's busy doing something, which will depend on how the system is
>configured. 1ma average for the CPU alone is probably reasonable. The
>modem will need about 3 ma. With the USB system shut down, the other
>components should be under 1 ma. So say the spec sheets, anyway. At any
>rate, it should be under 10 ma. Much less than the idling radio will
>probably draw. A backlit LCD would kill that, though.
High efficiency LEDs, in series, and turn them off after a few seconds.
>The OpenTRAC protocol is specifically intended to do this. It's got
>compact timestamps and supports sequence numbers, so you can go back and
>'fill in' missed reports later without clients thinking you're reporting
>new data.
Excellent.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
