Post by thread:[EE]: FM Transmission

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. 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. 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 --- 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

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. {Quote hidden}>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 ? {Quote hidden}>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.

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: {Quote hidden}> 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.

At 05:59 p.m. 24/08/00 +0100, you wrote: >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. Sound good, Ill consider it. >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? Actually it will be something like 10 numbers every minute, with high-rate times about the midday. Its like collecting survey data. >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... Heehehe, i guess we dont have pretty the same technology in Mexico and, even if we import it, the need to be cheap I dont think that it apply here. Thanks for the info. >Greetings to the list, > >Jochen Feldhaar Thank you Jochen, a lot. {Quote hidden}>"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. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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... {Quote hidden}> >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.