Hello Miguel Angel,

you could also implement DAMA protocol in your packet transmissions. DAMA means
that all stations logged in get polled cyclically, so one station is something
like a "master" calling the shots. This way most airtime collisions of aignals
can be avoided.

But.....what the (...) do you need to let your poor guys transmit 10 numbers
every 6 seconds?? Don't they have something else to do?? What kind of
application are you considering?

Apart from that, dedicated links in Germany use different data rates up to
57.600 presently, but on bands above 440 MHz. The 2.45 GHz ISM band would give
the needed capacity. Then all your worries about data rate are over. There are
some cheap controllers available for these data rates, German Hams use them
plenty...

Greetings to the list,

Jochen Feldhaar

"If it starts to work, it's no fun any more"

Miguel Angel Heredia Moreno schrieb:

> At 10:56 p.m. 23/08/00 -0500, you wrote:
> >On Wed, 23 Aug 2000, Miguel Angel Heredia Moreno wrote:
> >
> > > for the FM transmission first post ... consider this :
> > >
> > > 1) You got 50-100 people around a city working office-time jobs
> > > 2) Each one of them collect about 20 numbers every minute
> > > 3) They mut send this and verify they were received well and store them
> > locally
> > > 4) They need this units to be mobile (no car)
> >
> >Tall order, especially if you need it done cheaply.
> >
> > > theres another way to do this than packet radio ?
> >
> >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.
>
> >If it's got to be done in real time, you're looking at possibly 100 * 20 =
> >2000 messages, plus ACK packets, for a total of 4000 packets per minute,
> >or roughly 67 packets per *second*, assuming no retries or collisions. To
> >say that would be difficult to engineer would be an understatement.  You
> >would need to be running very high data rates on UHF with several Watts at
> >the very least, and I doubt even that would work.  The battery to keep a
> >radio delivering that kind of duty would be heavy, too.
> >
> >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 ?
>
> >If it doesn't have to be real time, why not a small, portable, non-radio
> >device to store the information during the day and uplink it via modem, or
> >even by packet radio, at night?  If real-time is not a requirement, I
> >would trade lots of on-board RAM and occasional uplinks for the complexity
> >and cost of a radio solution.
>
> >Just some ideas for you.  I love radios.  I love working solutions even
> >better, though.
> >
> >Dale
>
> Thank you Dale, a lot! :)
>
> >---
> >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 list server can filter out subtopics
> >(like ads or off topics) for you. See http://www.piclist.com/#topics
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

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