On Thu, 24 Aug 2000, Miguel Angel Heredia Moreno wrote:

> >Sure.  Does it **HAVE** to be done in real time?  I bet not.
>
> No, I can afford a little delay, lets say : the guy is in the street with
> his unit and put the numbers in and it say : "wait, busy" and then he
> retries till its ready, lets say about really 10 numbers per minute.

Of course the system can accept his input, then transmit as soon as it
can, and let him/her keep working...

> >If it's got to be fast but not real-time, you could store up X amount of
> >messages from a remote and send them in a batch.  You would still wind up
> >with a pretty busy channel.  Send a packet every five minutes, maybe.
> >Then you could get away with 1200BPS at VHF, and 1200 is a *lot* easier to
> >get working reliably than 9600 or higher.
>
> I was taking this in account too, to upload the data in the evenings but,
> Wouldn be more problems if ALL them send ALL their data around a time ? it
> wouldnt be better if they upload piece-by-piece bytes of data every few
> minutes ?

Not really.  The boxes would have all night to uplink, and the AX.25
protocol will handle congestion OK.  You could run a BBS-type package on a
PC at the base end that would handle multiple connections at the same
time.  All the error correction and reliable connection details are
handled by the AX.25 protocol, so the PIC doesn't have to worry about
those details.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                -- Isaac Asimov

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.