I'm not sure if this is the right place to post this question, but i'm an absolute newbie, so I hope if this is the wrong place, somebody could perhaps tell me where i should post it... My problem: I want to have as cheap as possible transmitters (i'll need 100's of them), that will need to send approximatly once every second 40 bits of data, to one receiver. It won't matter if some of these packets are lost. So what would be the easiest/cheapest way to accomplish this?
Newbie question
Started by ●January 24, 2005
Reply by ●January 24, 20052005-01-24
mkruisselbrink wrote:> I'm not sure if this is the right place to post this question, but i'm > an absolute newbie, so I hope if this is the wrong place, somebody > could perhaps tell me where i should post it... > > My problem: > I want to have as cheap as possible transmitters (i'll need 100's of > them), that will need to send approximatly once every second 40 bits of > data, to one receiver. It won't matter if some of these packets are > lost. So what would be the easiest/cheapest way to accomplish this?I don't know the right place. Your question is too vague. In what medium are your signals transmitted? Pity the poor receiver! how is it to untangle the bits from all those transmitters bombarding it at random times? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 25, 20052005-01-25
Jerry Avins wrote:> mkruisselbrink wrote: >>My problem: >>I want to have as cheap as possible transmitters (i'll need 100's of >>them), that will need to send approximatly once every second 40 bits of >>data, to one receiver. It won't matter if some of these packets are >>lost. So what would be the easiest/cheapest way to accomplish this? > > > I don't know the right place. Your question is too vague. In what medium > are your signals transmitted? > > Pity the poor receiver! how is it to untangle the bits from all those > transmitters bombarding it at random times? > > JerryIt almost sounds like a job for RFID tags. It seems those receivers are able to cope. -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 Quidquid latine dictum sit, altum sonatur. Whatever is said in Latin sounds profound.
Reply by ●January 25, 20052005-01-25
"Jim Thomas" <jthomas@bittware.com> wrote in message news:10vcmnknt8h0o00@corp.supernews.com...> Jerry Avins wrote: > > mkruisselbrink wrote: > >>My problem: > >>I want to have as cheap as possible transmitters (i'll need 100's of > >>them), that will need to send approximatly once every second 40 bits of > >>data, to one receiver. It won't matter if some of these packets are > >>lost. So what would be the easiest/cheapest way to accomplish this? > > > > > > I don't know the right place. Your question is too vague. In what medium > > are your signals transmitted? > > > > Pity the poor receiver! how is it to untangle the bits from all those > > transmitters bombarding it at random times? > > > > Jerry > > It almost sounds like a job for RFID tags. It seems those receivers are > able to cope.They aren't that random after all (in the case of RFID tags) since the receiver actually energizes the tags with energy and waits for a response. So it's a little more controlled.> -- > Jim Thomas Principal Applications Engineer Bittware, Inc > jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 > Quidquid latine dictum sit, altum sonatur. > Whatever is said in Latin sounds profound.
Reply by ●January 25, 20052005-01-25
"mkruisselbrink" <m.kruisselbrink@student.tue.nl> wrote in message news:1106575273.295749.141620@z14g2000cwz.googlegroups.com...> I'm not sure if this is the right place to post this question, but i'm > an absolute newbie, so I hope if this is the wrong place, somebody > could perhaps tell me where i should post it... > > My problem: > I want to have as cheap as possible transmitters (i'll need 100's of > them), that will need to send approximatly once every second 40 bits of > data, to one receiver. It won't matter if some of these packets are > lost. So what would be the easiest/cheapest way to accomplish this?Let's see; 40bits/second/transmitter x 100's of transmitters = 4000's of bits/second. Ordinarily that's not a large bandwidth. What if you simply use ethernet or a related protocol at even 10Mbits/second or, more likely, 100Mbps. Then the bandwidth would be more in the reange that an ethernet will handle very nicely - ven with the occasional collision. From there it's a matter of deciding how to implement isn't it? It would likely be inexpensive because the chips are in use already in some quantities. Fred
Reply by ●January 25, 20052005-01-25
Fred Marshall wrote:> "mkruisselbrink" <m.kruisselbrink@student.tue.nl> wrote in message > news:1106575273.295749.141620@z14g2000cwz.googlegroups.com... > >>I'm not sure if this is the right place to post this question, but i'm >>an absolute newbie, so I hope if this is the wrong place, somebody >>could perhaps tell me where i should post it... >> >>My problem: >>I want to have as cheap as possible transmitters (i'll need 100's of >>them), that will need to send approximatly once every second 40 bits of >>data, to one receiver. It won't matter if some of these packets are >>lost. So what would be the easiest/cheapest way to accomplish this? > > > Let's see; > > 40bits/second/transmitter x 100's of transmitters = 4000's of bits/second. > Ordinarily that's not a large bandwidth. > > What if you simply use ethernet or a related protocol at even 10Mbits/second > or, more likely, 100Mbps. > Then the bandwidth would be more in the reange that an ethernet will handle > very nicely - ven with the occasional collision. > > From there it's a matter of deciding how to implement isn't it? > It would likely be inexpensive because the chips are in use already in some > quantities. > > FredBefore we get too detailed, we ought to find out more about the environment. Wire? Radio? IR? Ultrasound? Under water? Ethernet was originally a broadcast -- as in FM radio -- protocol developed to link sites of the University of Hawaii. It's one of those "The experts said it would never work" things with a lot of sophistication that the experts either didn't look at because they weren't important or that they didn't understand. The actual carrying capacity of an X bits/second ethernet link X/e bits/second before it chokes, but delays are long then. A practical rate is around X/5. The sophistication of an ethernet-like protocol pretty much precludes "very cheap". For one thing, collision detection requires that each transmitter have an associated receiver that is live during transmission. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 26, 20052005-01-26
"Jerry Avins" <jya@ieee.org> wrote in message news:35oaunF4nveopU1@individual.net...> Fred Marshall wrote: >> "mkruisselbrink" <m.kruisselbrink@student.tue.nl> wrote in message >> news:1106575273.295749.141620@z14g2000cwz.googlegroups.com... >> >>>I'm not sure if this is the right place to post this question, but i'm >>>an absolute newbie, so I hope if this is the wrong place, somebody >>>could perhaps tell me where i should post it... >>> >>>My problem: >>>I want to have as cheap as possible transmitters (i'll need 100's of >>>them), that will need to send approximatly once every second 40 bits of >>>data, to one receiver. It won't matter if some of these packets are >>>lost. So what would be the easiest/cheapest way to accomplish this? >> >> >> Let's see; >> >> 40bits/second/transmitter x 100's of transmitters = 4000's of >> bits/second. >> Ordinarily that's not a large bandwidth. >> >> What if you simply use ethernet or a related protocol at even >> 10Mbits/second >> or, more likely, 100Mbps. >> Then the bandwidth would be more in the reange that an ethernet will >> handle >> very nicely - ven with the occasional collision. >> >> From there it's a matter of deciding how to implement isn't it? >> It would likely be inexpensive because the chips are in use already in >> some >> quantities. >> >> Fred > > Before we get too detailed, we ought to find out more about the > environment. Wire? Radio? IR? Ultrasound? Under water? > > Ethernet was originally a broadcast -- as in FM radio -- protocol > developed to link sites of the University of Hawaii. It's one of those > "The experts said it would never work" things with a lot of > sophistication that the experts either didn't look at because they > weren't important or that they didn't understand. The actual carrying > capacity of an X bits/second ethernet link X/e bits/second before it > chokes, but delays are long then. A practical rate is around X/5. > > The sophistication of an ethernet-like protocol pretty much precludes > "very cheap". For one thing, collision detection requires that each > transmitter have an associated receiver that is live during transmission. > > JerryJerry, Well, I would have said that an ethernet network design should be no greater than X/20 or 5% loading - I think that's the standard rule of thumb (when there are no switches and everything collides with everything). It may be more robust and could go to X/5 if the messages are always short as these are - but that's not my area of expertise. There are a lot of chips out there that provide the interface - thus the potential for very cheap (depending on the user's context of make vs. buy). With regard to the medium, wired and wireless are pretty much covered with low-cost products. Of course there could be reasons that have not been revealed that would preclude either. Fred
Reply by ●January 26, 20052005-01-26
Fred Marshall wrote:> "Jerry Avins" <jya@ieee.org> wrote in message...>> The actual carrying >>capacity of an X bits/second ethernet link X/e bits/second before it >>chokes, but delays are long then. A practical rate is around X/5....> Jerry, > > Well, I would have said that an ethernet network design should be no greater > than X/20 or 5% loading - I think that's the standard rule of thumb (when > there are no switches and everything collides with everything).A great deal depends on one's criterion. (It what flux density does this transformer iron saturate?) Maximum delivered bits occurs at X/e. The system chokes beyond that, with throughput becoming very small. At X/5 there is poor latency but even temporary choking is very unlikely. At x/20 it is possible for each user to think he has a private channel. Take your pick. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 26, 20052005-01-26
Jerry Avins wrote:> Ethernet was originally a broadcast -- as in FM radio -- protocol > developed to link sites of the University of Hawaii.I think they called that the Aloha protocol. The transmitter didn't check the medium before transmitting, but waited for an ack. If it didn't get one, it would retransmit. The only reason I remember any of this is because my in-laws operate on a modified-Aloha protocol in their everyday conversation. The modification is that if they don't receive an ack, they retransmit with MORE POWER. I remember the first Christmas Eve I spent with them. One of my wife's uncles was talking to me when his brother just butted in. Not knowing how to respond, I ignored him. That's when he retransmitted. Louder. I ignored him again and soon learned until he got that ack, he was going to keep retransmitting at ever greater power levels. Apparently, his loop termination condition did not include a maximum-retries term. Meanwhile, the first uncle upped his power too. In an attempt to prevent the volume from overpowering my receiver, I was forced into TDM mode. Unfortunately, their protocol did not include an allowance for backing off the power levels. Those uncles never once called one another out with a "I was talking first," nor did they seem to think it was odd. It was their protocol. That's how it progressed the WHOLE EVENING, with upwards of a dozen transmitters (and I was not the only receiver either). -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 Quidquid latine dictum sit, altum sonatur. Whatever is said in Latin sounds profound.
Reply by ●January 26, 20052005-01-26
Jim Thomas wrote:> Jerry Avins wrote: > >> Ethernet was originally a broadcast -- as in FM radio -- protocol >> developed to link sites of the University of Hawaii. > > > I think they called that the Aloha protocol. The transmitter didn't > check the medium before transmitting, but waited for an ack. If it > didn't get one, it would retransmit. > > The only reason I remember any of this is because my in-laws operate on > a modified-Aloha protocol in their everyday conversation. The > modification is that if they don't receive an ack, they retransmit with > MORE POWER. > > I remember the first Christmas Eve I spent with them. One of my wife's > uncles was talking to me when his brother just butted in. Not knowing > how to respond, I ignored him. That's when he retransmitted. Louder. I > ignored him again and soon learned until he got that ack, he was going > to keep retransmitting at ever greater power levels. Apparently, his > loop termination condition did not include a maximum-retries term. > Meanwhile, the first uncle upped his power too. In an attempt to > prevent the volume from overpowering my receiver, I was forced into TDM > mode. Unfortunately, their protocol did not include an allowance for > backing off the power levels. > > Those uncles never once called one another out with a "I was talking > first," nor did they seem to think it was odd. It was their protocol. > That's how it progressed the WHOLE EVENING, with upwards of a dozen > transmitters (and I was not the only receiver either).An essential part of the protocol is the transmitter- and retry-count dependent waiting time before retransmitting after a collision. With that, collision is the second attempt is less likely, and "frustration" incrementally increases one's priority. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
