Bill Pitz <dakota@billpitz.com> wrote:
: On Mon, 12 Jul 2004 23:33:10 -0400, jon@dakota-truck.net wrote:
:>possible. Using this sort of method, it would be possible for
:>telemetry from trucks in absolutely impossible locations to reach
:>DML HQ because it can essentially jump from truck to truck until
:>it finds a line of sight connection back home. :-)
: That was a bit more complex than I was thinking, but it would work
: with enough technology. I'm thinking of a cheap (D-Link or Linksys)
: box in every truck. Short-range could even work with just the
: built-in antennas. (Otherwise, magnet-mount omnidirectional antennas
: would work great) All of the newer boxes include "repeater" mode,
: which will just pass along all of the traffic they receive from other
: connected nodes. In this way, you just build one giant bridged
: network. In a "real" application that wouldn't be as practical for
: performance and security reasons, but for this applicatoin I think it
: would be just right. Every client could see every other client,
: regardless of how many "hops" were necessary to get there. Since
: we're not really talking about that many nodes, it wouldn't be too big
: of a problem.
Ok, I hadn't realized that (wireless newbie) :-) - that
"repeater" mode would sure make things easier. :-) Basically
it would accomplish the same thing I was talking about but with
a lot less complexity on our part, and that's a whole lot of code
that wouldn't need to be written. :-) See, this probject is
getting easier and easier! :-)
As far as the "repeater" mode goes, is this something that
the access point does, or can a laptop with a wireless card in
it perform the same function? That is, can a group of laptops
with nothing but PCMCIA 802.11B/G cards talk to each other as
if they were connected via a hub on a LAN, or is at least one
access point required?
Speaking of doing something along those lines, I should think
that if you had a group of say, 5-10 trucks, an intermediate step
might be to have each one set up in the manner you described, with
a server in one of the vehicles, accepting GPS data from the others.
Then, later on, this data could be used to generate a "blips moving
on a map" display to show exactly what happened and which truck went
where. This isn't exactly our ultimate goal of a realtime display with
'net access, but it would certainly be a fine way to work out the
bugs and test the system. Taking the server along for the ride also
conveniently eliminates all of the problems of extending the network
from the trucks back to home base where the 'net connection is. Once
the system is up and running like that, if a way to provide a wireless
connection back to home base were found, it would be a relatively
simple matter to convert the existing software from a "playback" type
application to something that can handle realtime display of the data.
This might be a fun thing to have with the BBQ report - web browsers
could download a simple application (or possibly it could be java based
and right in the browser itself) to see where all the trucks went
during the BBQ, you can possibly click on each one to get more data
like current speed, elevation, etc. Other fun extrapolated data could
be generated like finding out who drove the most during the event, who
had the fastest average mph, the quickest elevation change, etc. :-)
: This is a project that would be a lot of fun. At least in my opinion.
: :-)
Absolutely! :-) Done right, it might even be something
other groups (offroading, racing, whatever) might be interested
in, and may even have some market potential were someone so inclined.
At the very least, it would make a neat thing to have on one's resume. :-)
:> Another thing to think about would be what sort of TTL this
:>data might have. For example, say a truck goes around a corner
:>and loses communication with everybody. It is still gathering
:>telemetry, so does it store this data and attempt to send it out
:>upon reconnection with the network, or does it throw it away? If
:>it stores it, how long should it do so before the info is
:>considered to be so stale that it is worthless?
: I think the thing to do would be to have each client just cache the
: data until it were reconnected to the network. If the clocks on all
: of the equipment were synchronized, every piece of telemetry data
: could be timestamped and then assembled in order, plotted on a map,
: etc. even if it arrived back at HQ later on.
That's probably the best way to go. Taking this even further,
something like this could achieve a "playback" type system.
Think of 5-10 trucks, not networked with each other but each with
an 802.11 equipped laptop connected to a GPS. Each truck goes about
its merry way, and the application records all the GPS data. The
next time the truck happens to wander close enough to DML HQ for the
wireless connection to establish, the application feeds all the data
its collected to the main server. Since each laptop has their clock
synchronized, this data could be assembled as you mentioned, and all
the trucks could be seen moving around at the same time. (Speaking
of which, doesn't the GPS signal include time data? Could that be
used either to synchronize the computer's clock, or maybe even better,
just include a timestamp directly from the GPS with each piece of
stored data?) A system like this technically wouldn't need each truck
to be wireless capable. The stored data could simply be copied onto a
floppy and the main server updated the really old fashioned way. ;-)
Another idea I just had related to the whole idea of getting some
sort of property-wide network-ability, is that the FRS radios we
use are actually pretty good, range-wise, and have handled things
like the ravine fairly well, overall. I wonder if some sort of
"FRS modem" could be created to piggyback the network on those
radio waves? Perhaps a couple of these FRS modems, in one or two
trucks could act as a bridge between the wireless network and
DML HQ?
--
-Jon-
.-- Jon Steiger ---- jon@dakota-truck.net or jon@jonsteiger.com --.
| 1970 Barracuda - 1990 Dakota 'vert - 1992 Ram 4x4 - 1996 Dakota |
| 1996 Intruder 1400 - 1996 Kolb FireFly - 2001 Ram QC 3500 CTD |
`------------------------------------ http://www.jonsteiger.com --'
This archive was generated by hypermail 2b29 : Sun Aug 01 2004 - 00:46:14 EDT