Hmm...I think you have to qualify that statement a bit, since, technically it is feasible. The end-to-end delay would be far from optimal, however.
It can, if Layer-3 routing is used. However, I will concede that some cheating would be required (topological cheating that is).
Now this is very doable, using existing hardware, and new software.
Not sure how hard it is to do with TCP/IP and related topology- discovery algorithms, but if one rearchitects a new protocol in parallel TCP/IP, I think it would be frighteningly simple, relatively speaking.
Hint: Great ideas, that work on a small scale, do not necessarily scale very well into larger systems. MESH is one of those ideas. Given enough frequencies (and channels), it can be sorta made to work, but not with what's currently available with wi-fi.
Incidentally, the driver safety people (the one's that brought us the California hands free cellular fiasco) would have a fit if you even suggested inter-vechicle mobile computing. I ran into that 25 years ago when working on anti-collision vehicle radar. They want the driver to do driving and NOTHING else. Frankly, I think it's a good idea as a friend was recently rear ended by a driver fumbling with her cell phone and not paying attention.
Nope. Not in the slightest. Metricom tried that about 10 years ago. Cost of infrastructure, greedy site owners, and municipal bureaucracy killed it (among other problems).
There are lots of problems, but the killer is store and forward performance. Let's pretend your system can do 10Mbits/sec point to point. Add one mesh repeater into the system, and the maximum speed goes down to 5Mbits/sec. Add another and it does down to
2.5Mbits/sec. Keep going and you rapidly approach zero. The number of packets that will be flying through the air doubles with each repeater, resulting in nothing but collisions and retransmissions.
I can supply articles on the subject but Firefox 3.0 just ate my bookmark file and I'm too lazy to dig out the backup at 4AM.
Home, yes. It's called a "range expander", "repeater", or other form of marketing speak for something that barely works. Compatibility with existing access points and wireless routers are the big problem. Repeater were not clearly specified in IEEE 802.11 specs, resulting in some rather creative and incompatible implimentations.
As for the neighborhood, I don't think so. Once you get outside of the limited RF environment of the typical home, and into the great outdoors, with its pollution from other 2.4GHz sources, I don't think it has a chance.
It's an old pitch line which is basically correct. Communications is the alternative to transportation. If you wanna clean up the traffic and impending gas shortage mess, communications is a great fix.
However, mobile mesh networks are not the right answer unless you plan for everyone to work and live in their cars. IMHO, fiber to the home is the right answer, with unlimited peak bandwidth, metered service (pay by the megabyte), and work at home. Lots of things will need to change to make that happen. Think about what problems you're trying to solve first. Then go looking for solutions. Don't try to push the latest high fashion technology.
There are many, many things that can do to get around the repeater "issue". I put "issue" in quotes because they are not really issues, any more than eating sweets are "issues" for diabetics. You know what you are going to get when you do it. The key is to ask what you want, then find a way to do that given what you have. Putting up repeaters is obviously not the way to do it. You have to rely on Layer 3 software and above. And there are some tricks you can do with routers to guarantee scalability. Unfortunately I cannot yet say what they are.
In other words, you do not have to be an electrical engineer to solve this problem, but you do have to know how to write software, and it would not hurt to have solid understand of graph-theoretic algorithms.
If you can code, DD-WRT is not a bad place to start, but again, you will have to solve some theoretical problems (in software) to make it work.
Le Chaud Lapin wrote in news:d456e801-1ba4-4ef0- email@example.com:
My company recently started design of an IP 900 mHz SS radio.
I've been in a constant battle for the past two months with the decision- maker........I want the design to be a Layer3 routing device, but he wants it to be just a bridging device, because it's 'easier to get working' is his argument.
I can see his point, because all of the companies we deal with that win bids for contracts, seem to have really no clue about how wireless really works.
Worse yet, if you are designing the radio, it is very likely that whatever you are doing can be create from COTS components, even for some military applications.
This is a *huge* problem at the electronics/software boundary in general. The electrical engineers want to do it all in hardware. The software people want to do it all in software. Both can be dogmatic, but often the software people are more right than wrong.
The best modern examples I can think of are BlueTooth and ZigBee. They did far too much thinking about things they probably should not have been thinking about, IMO. The very best thing that an RF designer can do is
Make it fast.
Make it reliable.
Make it controllable (power, etc)
Get out of the way so the software people can do their job.
I spent all of 45 seconds flipping through the BlueTooth specification. The moment I saw the word "printer" and other things that indicated that they were meddling with printers and other things that, IMO, is the domain of other types of engineers, I closed the book.
What is ironic is that, except for handover-delay, it is possible, today, in 2008, to solve the mobility problem, where PDA's are used like cell phones, etc., using COTS hardware. But that doesn't stop people from trying to make special radios for mobility.
Sophisticated software running on top of a simple but spartan generic hardware will rout special-purpose systems 100 times to 1.
The good news is that the future is inevitable, so you will have your day. :)
Le Chaud Lapin wrote in news: firstname.lastname@example.org:
At this time, the radio module itself is a COTS component, and the rest of it is what I'm designing. It should be a fairly simple design. Actually, we already have several applications of the existing hardware, but running only RS232 data.
Lots of 900MHz stuff out there. Trango, Canopy, Freewave, Waverider, Ubiquity, AvaLAN, FreeWave, MaxSpeed, etc.
Why do you want Layer 3 wireless? I know some advantages, but I'm curious as to your logic. My never humble opinion is that native IP routing wireless doesn't offer any improvements in the constant battle between: Good, fast, cheap. Pick two. It won't be any better because writing router code is best left to the router manufacturers. Sure, you could lift open source code and "adapt" it for your product, but it doesn't have any of the features found in MAC layer wireless, such as retransmissions, error detection, error correction, collision avoidance, self healing paths, path length optimization (STP), etc. IP layer wireless also doesn't buy you anything in the way of speed. That's entirely dependent on the timing, packet sizes, handshaking, error detection, error correction, etc. Moving things up a layer eliminates encapsulation, but that doesn't really improve speed unless your device is CPU bound. It certainly doesn't make it any cheaper as much of the hardware is identical. What's your rational?
Enjoy it while it lasts. Wireless is rapidly becoming a commodity. I actually saw an intelligently written RFQ last week for a wireless system.
Jeff Liebermann wrote in news: email@example.com:
True, but we mainly deal with Oil and Gas Utilities, Environmental Departments.....even several government agencies....and the product's aren't used for broadband as a consumer would use it. We are connecting lower data rate remote telemetry and SCADA equipment, and doing remote I/O.
Our 900 SS product is capable of doing 115kbs half-duplex in a transparent master/slave configuration PtMP, and in polling systems, traffic is usually light, for the most part. There are log d/l's and program updates from time to time, but mostly 10 bytes (are you there) and then ten bytes (yes i'm here). Programs for the devices are 10's of KBytes, not huge either.
Let me clarify a little bit, I'm not talking about a full-blown rtr like a Cisco rtr. There would be no NAT or ACL's or the like. Just basic rtr'g function's.
Also, it's not 802.anything. The radio portion is proprietary, and already takes care of retries, FEC, etc. It's a modular design as the radio can be used alone utilizing RS232 data. Adding eth/IP to it is an enhancement, as a lot of our clients are now starting to utilize eth/IP field equipment.
And yes....CPU ticks are at a premium. We could get more CPU power...for a price. The controller mfg gives the complete source code for their TCP/IP stack for no extra charge as well, so it's not like design from the ground up.
Enjoy it ?!?!?!?! I can't stand dealing with some of the people we deal with. These companies make bids for wireless contracts when they don't even really know what's truly involved in building out a wireless network. Here's an example, that has happened twice over the past year....I get a support call for one reason or another. The first thing to do is to check a couple of configuration setting's. The person can't get to a config prompt with a terminal program. Check the terminal baud rates, cabling, etc. and then they asked the question.....'Does the radio need DC power to configure it ?'.....What !?!?!?!......Twice !!!!
Ideally, I'd like to sell product to intelligent people that don't call support for basic RTFM questions. People that realize you can't run 200' of RG58 coax for anything. Another experience.....one group is doing radix feed in an underground mine setting and narrow-band 800/900 mHz using 25W radios. Each locomotive has a radio in it. On some the radio, is mounted at one end, the antenna the other. The loco is 40 or 50 feet long. Whomever designed the system had then order pre-cut lengths of RG58 @ 150' each. They then just rolled up the excess and put it off out of sight. There were performance issues, and when our field engineer went there to help, it was easily identified as the major problem in the whole system. RG58 @ ~16db loss per 100/ft. meant that at the radio connector, the unit had 25W of output and a usuable RX sensitivity of -112 dbm....but by the time it reached the antenna, it was down to 100 mW, and a minimum operating RX sensitivity of -88 dBm.
Yeah, right. That's what you start with. Just the basics. Then, one customers wants a static route. Another wants to initialize a VPN connection. Another wants bursty traffic. Another wants streaming traffic. Someone is sure to want SNMP. Maybe RIP2. Ad infinitum. If you think small now, you're going to get burned big later. If you really do have a gutless CPU, you're going to be very limited in what you can do.
Ok, there's hope. You can always do both a MAC layer 802.11 implimentation *AND* an IP version. Incidentally, I would kill to have FEC in some of my flakey 802.11 links. I have one that's been running with 50-80% retransmissions due to interference for perhaps the last year. It works, but only barely.
Incidentally, Digi/Maxstream has a 900MHz IP bridge box:
No clue on price and I haven't tried it.
I used to have a slogan at a previous employer. "This would be a nice place to work if it weren't for the customers". Also, "Choose your customers wisely".
That's fairly bad. I've seen similar problems with computers, wireless, commercial radio, etc. Once in a while, I've even done something clueless in an area I'm not familiar with. The technology is sufficiently advanced and complexicated that Joe Sixpack is no longer expected to know anything about how things work. For example, I was tinkering with a friends new big screen HDTV, cable box, and Blue Ray player. Three remotes and he asks me to which box to point the remote. He really didn't know how they worked or which box controlled with video source or did what. Yet, his knowledge of camera and microscope optics is well over my head. Some things are not obvious to everyone.
That will never happen. Clueful customers get promoted until they are no longer functional. It's called the Peters Principle:
Please resign yourself to dealing with fools, idiots, incompetents, beginners, and managers. That's a part of what they pay you to do.
Heh-heh. I've had exactly the same thing happen to me. We sent out a standard length of coax with each installation. Far too many installers didn't bother to RTFM and cut the coax to length with similar results. There were also those that snaked the coax carefully through whatever, and then cut the coax too short at both ends to complete the install. That's what field service is all about.
Of course you learn some new things visiting customers. One of Intech's products was the M360 radio direction finder. A customer called complaining that the antenna could not be installed on the mast. The antenna was assembled in two pieces, a funnel shaped base and the antenna platform assembly. To keep water out of the fasteners, they were installed from the BOTTOM through the base. Ever try installing 8 screws from below an antenna on top of a 30ft mast, on a swaying boat? I succeeded but nearly killed myself doing it. Redesign followed shortly thereafter..
Anyway, clueless users no longer bother me. I just smile, take their money, and go on to the next clueless user. If I meet someone with a clue, it's a welcome change, but most often, also a suprise.
It's not so basic when you know zero about the technology. Ever ask the satellite, cable, or telco installer anything about the underlying technology? Most don't know how it works.
Mesh can be made to work. The first step is to avoid the single channel store and forward problem, and use multiple channels. Some of the mesh vendors are doing just that with 2.4GHz 802.11 mesh. That usually requires 2 or more radios in the box, but that's not all that horrible. For example:
uses 2-3 radios for mesh. Tropos recently released a similar product. How it works:
I also have major issues with the use of omnidirectional antennas. Details later...
Incidentally, I equate "serious" potential with investment capital. Only "serious" project get the attention of big capital.
Yes, sorta. There's a simple test that I offer to any proponent of mesh technology. Take a few client radios, a few access points, maybe a few repeaters, and put them in an enclosed room. It can be as large or small as convenient, as long as every radio can hear every other radio. Configure the system (or let it self-configure, self-heal, or self-destruct). Run some traffic through the system and run thruput benchmarks. My prediction is that the self interference will kill any such system that doesn't have frequency agility, steerable antennas, backhaul fallback, and bandwidth management (QoS). I've actually done this with several systems and demonstrated the predicted dismal results. I can also demonstrate bottleneck issues if only one radio is internet connected.
Best? I have no idea. There are plenty of mesh vendors and products. The multi-radio variety are less disgusting than the store-n-forward single channel type, but I still don't like any of them.
You could easily set it up. That's not the problem. You might even be able to make it work. It's what happens when it stops working that's the problem. How's your troubleshooting abilities?
I sorta blundered across this a few days ago:
I really don't know anything about it. Seems to be based on MIT Roofnet and Meraki Networks mesh. At $50, it's cheap enough to try on off the shelf hardware.
Jeff Liebermann wrote in news: firstname.lastname@example.org:
I'm most likely going to have to follow the boss' wishes and go the bridging way.....but, that doesn't mean I won't code in the routing way as well available as a menu choice. :)
$500 if you click the 'Buy Online' link. Our RF deck has much better specs, other than throughput.
The MaxStream: 935 kbps throughput RX sens. of -97 dBm for a BER of 10 e-4. Pwr Out of 125 mW Sub-Block Error detecion and retransmission (whatever that means) 12 non-overlapping channels
We've got: 115 Kbps thru -108 dBm for 10e-6 20-to-30 dBm output user selectable......(I know big mouth-small ears.) FEC I'm not sure how many can be deemed as non-overlapping, but 128 channels (because of the smaller bandwidth). The 128 channels are broken up into 8 blocks of 16 each. You can disable up to 4 of the blocks for persistant interference. Store-And-Forward repeater. (I'm not sure how I'm going to handle this in the IP version. If the rptr does not need to be an ethernet node, the standard serial based unit will work fine.) 32,000 different hop patterns based on the Network ID. Support for co-locating masters.
That's about all I can think of off-hand.
Again, the data thruput rate is lower obviously, but for our typical applications, that is not a huge concern.
Unfortunately, he 'chooses' customer's with the most technical difficulties for what their application is. Seems like the deals that interests him the most are the one's where he gets to solve problems.
Yes, some are really bad. I'm not expecting the clients to be wireless guru's, but, since they are bidding and winning contracts for wireless systems, you'd think they'd have some knowledge of what needs to be accomplished....even to just be able to bid the job.
We may have discussed that before...people that perform well are promoted until they don't, and then just stay there. Regards,