Thanks both for replies I have to say I put in the "????" for just this reason. This whole RSSI% vs RSSI dBm mapping leaves me very bewildered !! Although Steve I think your results are more like what I would expect to see.
The default AB mapping (internal formula) is 2% -93dBm 5% -91dBm 7% -89dBm 10% -87dBm 12% -85dBm 15% -82dBm 20% -78dBm 30% -70dBm 40% -61dBm 50% -53dBm 60% -44dBm 70% -36dBm 80% -27dBm which looks like a very sensible way to calibrate: lowest workable signal at close to 0%, raging hot signal at fsd. As far as agc dynamic range will take it. So this says we need 2% for 1Mbps (@~ -94dBm see product spec) 10% for 5.5Mbps (@~ -87dBm) 13% for 11Mbps (@~ -84dBm) All very reasonable. Lets add ~15dB safety margin (thats a very well engineered link) to give -70dBm - a roaring signal. This corresponds to just 20%. So, thats it then, anything above 20% is a knock out rock solid signal !!!!! Everyone agreed ? Why doesn't that stack up with reality ? Not leaving a customer 'til you've got 80% !! Well, the receiver should have steam coming out of its ears with -27dBm at the antenna socket ! With +17dBm Tx, 13dBi antenna at each end, direct LOS in free space, no feeder loss etc you will get -46dBm at 300m (~58%). Thats a ~40dB fade margin for 11Mbps. But who expects to put up 13 dbi at both ends for 300m in perfect conditions ? Even with an ABI (~2dBi antenna indoors) the result is usually much better than 58% at this distance. It just doesn't add up I only wish I had the correct test gear to calibrate a receiver. sB support team, are you there ? What am I doing wrong ? Is the internal formula sooooo far out ? If so could you give us a sample table for typical user defined values. bw ----- Original Message ----- From: "Steve Good" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 25, 2003 3:48 PM Subject: RE: [smartBridges] Minimum working config suggestion (was Tranzeo CPE / APPO Compatibility) In response to your RSSI part. I use some WUSB (linksys) units because the customer is close to the tower and they work like a champ getting T-1 speeds from them. But in SIMPLE NMS or SIMPLEMONITOR they show they might only have 50-55% RSSI. Does anyone know if non SB products will show a true RSSI and/or LQ in Simple NMS or SimpleMonitor? THanks, Steve ________________________________ From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Tue 11/25/2003 7:15 AM To: [EMAIL PROTECTED] Subject: Re: [smartBridges] Minimum working config suggestion (was Tranzeo CPE / APPO Compatibility) The only thing I disagree with is the use of a spectrum analyzer. By choosing from an available access point the only way to see the access point is to either know the SSID and statically enter it in the the CPE or the device that is potential interference must be set to broadcast the SSID or it will not show up in the available access points list. Microwaves, cordless phones, and other wireless ethernet devices will not be detected without one. Another thing, the recommendation for signal strength I believe is no less than 75%. That should be no less than 80% average based on my experience. I had one client that I left running around 77% average, it was a mistake because I rolled the truck out to replace the ABO with 13db to an outdoor with a Maxrad 18db flat panel. That bumped the 77% average up to around 87% and I have not heard from them since. Marginal LQ and RSSI = marginal service. I now do not leave a customer site with less than an 80% average, no acceptions. If I cannot get that I deem the service unavailable in that location. I have also had very good luck by eliminating the Auto Fallback ability. I set all my CPE's to 2Mps and my APPO's are set with 1Mps and 2Mps enabled. Both devices have Auto Fall back disabled. This has provided stability. Marginal signal devices continualy trying to change the rate is additional overhead and results in latency as the rate change takes place, busies the AP during that time which affects all users, and if you have multiple devices doing this on a regular basis times the problem time the number of users and you end up with a busy system. I have mentioned this before on this forum, but a great way to test if this is being an issue is to watch the link status in Simple NMS and while performing a performance test on Toast.Net to see if the LQ ever drops to zero during the test. If so, back the data rate off (with auto fallback disabled on both ends) and continue to back it off until the link remains stable during the test. Basic internet browsing will not behave this way, it is only during periods of heavy traffic. If you get down to an unacceptable speed then it is time to go back to square one for that particular client. I get just under full T1 speed set to 2Mps. Some folks say that in doing this it negatively affects the AP because it keeps the communcation throttled back and busies the AP, but not as busy if it is continually changing rates and/or re-associating and the end result is retransmitting packets. I would rather see the packets get through reliably the first time. So the theory of let it get through as fast as it can I would say is great under perfect conditions, we are all not under perfect conditions when we go in the field. Auto fallback in my opinion is meant to be used in a WLAN environment where the signal levels can be kept high in a more controlled environment to eliminate the data rate changes. I am not sure it is set this way by default because it is the recommended setting, I think it is more to do with the 802.11b standard, very much like by default the SSID broadcasting is enabled and is one of the first things that gets enabled, but to be 802.11b compliant it must be enabled to meet the standard. My 2 cents. Very good post Brian. ----- Original Message ----- From: Brian Winter <mailto:[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 4:53 AM Subject: [smartBridges] Minimum working config suggestion (was Tranzeo CPE / APPO Compatibility) I'm one who currently believes that many "issues" seen on this forum (lockups etc) are down to the way we, all of us, expect to utilise this fragile airtime protocol in the real world - sB have little control over this if their kit is to remain standards compliant (however bad the standards are!). There will be some problems which are due to faulty kit. I wonder if it would be useful for list members to jointly devise a minimum working configuration which does not push the protocol to its working boundaries, and a check list of observations to best get through the most common areas of concern. Once basic operation is achieved, each parameter can be backed off towards its expected operational state or 'til it stops working. Time consuming, but scientifically satisfying ;) Does this already exist on sB site ? I have also had very good luck by eliminating the Auto Fallback ability. I set all my CPE's to 2Mps and my APPO's are set with 1Mps and 2Mps enabled. Both devices have Auto Fall back disabled. This has provided stability. Marginal signal devices continualy trying to change the rate is additional overhead and results in latency as the rate change takes place, busies the AP during that time which affects all users, and if you have multiple devices doing this on a regular basis times the problem time the number of users and you end up with a busy system. I have mentioned this before on this forum, but a great way to test if this is being an issue is to watch the link status in Simple NMS and while performing a performance test on Toast.Net to see if the LQ ever drops to zero during the test. If so, back the data rate off (with auto fallback disabled on both ends) and continue to back it off until the link remains stable during the test. Basic internet browsing will not behave this way, it is only during periods of heavy traffic. If you get down to an unacceptable speed then it is time to go back to square one for that particular client. I get just under full T1 speed set to 2Mps. Some folks say that in doing this it negatively affects the AP because it keeps the communcation throttled back and busies the AP, but not as busy if it is continually changing rates and/or re-associating and the end result is retransmitting packets. I would rather see the packets get through the first time. So the theory of let it get through as fast as it can I would say is great in theory under perfect conditions, we are all not under perfect conditions when we go in the field. Auto fallback is much better and in my opinion meant to be used in a WLAN environment where the signal levels can be kept high in a more controlled environment to eliminate the data rate changes.. The main technical concerns seem to be (list start - please add) 1. Poor receive signal strength (long distance, non LOS, leaves and other obstructions, poor aerial/feeder etc, multipathing, dead spots) 2. Interference - Poor link quality (co-channel traffic, adjacent channel traffic, multipathing, microwaves, heavy current switches, electric railways, high power broadcast transmitters, pulsed radar etc) 3. Inappropriate data rate for low sigs or interference 4. Use of software which needs broadcast messages (eg dhcp) 5. Non-reciprocal radio paths My first suggestions for config are: 1. Fix to one channel for results gathering - different chans may show different results - confusing. When one channel is eliminated (noisy etc) fix to another one and start again. 2. Disable WEP - WEP protocol overhead means 50% of the traffic across the air is unnecessary for testing. On top of this many (most) probs are in fringe coverage, so much of the real and overhead traffic will be retried, reducing throughput further. If you have congestion this might relieve some of it. 3. Select "Basic Rate" = 1Mb "AutoFallBackRate" = off (should not matter as basic rate is set to minimum, but will prevent any rate negotiation). 4. Set fixed IP for client side radio, and the first device on the client side. DHCP involves broadcast messages which are unreliable in the protocol - VERY IMPORTANT (esp thro AB) 5. Set preamble = ???. For best performance in poor signal conditions. 6. Set allow "Non IP Traffic" off - less extraneous traffic to deal with. 7. Set Fragmentation = ???. For best performance in poor signal conditions. 8. Set RTS/CTS = ???. For best performance in congested conditions. Messages of length < this value are sent without regard for others on the channel, which can give contention/retry problems on a busy channel. Messages of length > this value tell other radios to "shut up" so it can get this message out and hear the reply without someone else butting in. This adds a significant overhead of its own - much of the available airtime is spent "busy waiting" - Although this parameter is most beneficial in high capacity systems, thats where you need least overhead - theres the rub !! Also note that this is only worthwhile where the other radios can hear you properly (see discussion on reciprocity later). Also read up on the "hidden node" problem - google "hidden node". 9. Use a cheap router at the client end to get rid of all the default Windoze network management traffic (eg broadcasts from Computer Browser service) 10. Set the radio transmit power (not eirp) to be the same at both ends !!! With tx/rx on the same aerial, there is nothing to be gained by whacking up the output power at the client end, nor by changing it for other kit with higher power output. The link is only as good as the worst leg, and can be much worse than that. By increasing only one end you are forcing the far end to send (and resend) replies that you just can't hear - this is just more "noise" for everyone else on the same channel, and no benefit for you. Observations to report should include: 1. RSSI (should be > ??? for 1Mb data rate) - Link Status tab 2. LQ (should be > ???) - Link Status tab 3. RSSI/LQ observed on other channels ? SM for AP(CB mode), "Site Survey" tab, "Select from Available Acess Points" (I could never figure why anyone should need a spectrum analyser when we have a perfectly good sensitive receiver in exactly the right location, with exactly the antenna arrangement, on exactly the freq of interest etc etc that we want to measure - toys for the boys) 4. Compare stats for transmitted "Unicast Packets" and received "Received ACK" - They should be very similar. 5. Received RTS and CTS will give some idea of how the system is managing contention 6. Failed Packets and Aged Packets are the results of contention, poor reciprocity, one end interference etc. Measure over fixed periods at different time of day Its a real shame that SimpleNMS/Monitor can't let us change parameters (at both ends) and watch statistics at the same time Comments welcome. Discussion on Reciprocity: Consider a pretty normal path between A (say APPO, AP mode) and B (say ABI, CB). For this discussion ignore feeder losses, assume LOS, perfect path etc - I'm not suggesting that a link of 10Km is viable in this way !! >From A > B Tx A +17 dBm Antenna A +13 dBi (eirp = +30dBm Illegal in UK) PathLoss -120 dB (eg 10Km @ 2437Mhz) Antenna B +02 dBi ================== Rx sig str -88 dBm (at B) Best Rate 2 Mbps (assuming no fading etc !!!) >From B > A Tx B +17 dBm Antenna B +02 dBi (eirp = +19dBm) PathLoss -120 dB (eg 10Km @ 2437Mhz) Antenna A +13 dBi ================== Rx sig str -88 dBm (at A) Best Rate 2 Mbps (assuming no fading etc !!!) You have a good reciprocal path. No matter how you change the aerials you will always have a reciprocal path - Good Now, on a whim, you decide to increase the client end transmit with an amp (yuk) or a 200mW pcmcia card >From A > B (no change) Tx A +17 dBm Antenna A +13 dBi (eirp = +30dBm Illegal in UK) PathLoss -120 dB (eg 10Km @ 2437Mhz) Antenna B +02 dBi ================== Rx sig str -88 dBm (at B) Best Rate 2 Mbps (assuming no fading etc !!!) >From B > A Tx B +23 dBm (=200mW) Antenna B +02 dBi (eirp = +25dBm) PathLoss -120 dB (eg 10Km @ 2437Mhz) Antenna A +13 dBi ================== Rx sig str -82 dBm (at A) Best Rate 11 Mbps (assuming no fading etc !!!) This has not improved the system even slightly. In fact all we have is a client install spraying out louder messages that it can't hear the reply (ACK) to - further cluttering up the AP with useless noise. It might even be worse than this as the dialog during association will be full of retries etc. DHCP might be OK for client AP but pointless even trying for AB. This could lead to all sorts of strange issues. ----- Original Message ----- From: Nimesh D. Parikh <mailto:[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 3:04 AM Subject: RE: [smartBridges] Tranzeo CPE / APPO Compatibility Hi Ian, I am sorry to hear of the problems you are having with the aBOs. Since you are running 1.08 and still having to reset, I think the problem should be some thing else. This firmware had solved the issue of occasional dis-association of the aB. This dis-association used to happen on a relatively small number of installations, depending on some combination of conditions. After many months of investigation we could never figure out what were these conditions. During these investigations we learned that this is a common and unpredictable problem with almost all manufacturers' devices. Well anyway, now we are happy that 1.08 solves the dis-association issue. As others have pointed out, this is a tech support forum. So most times you get to hear only the "I got problem" cry for help. Once the issues are resolved you would seldom find a post that clarifies the issue. We think that there are perhaps less than 1% or 2% of our users posting regularly on this forum. Typically when somebody is having problem, jumps on the forum, gets help from the experienced users and then becomes a passive reader. This is a great forum with so many friendly and willing users contributing their expertise. The forum helps us stay in close contact with our customer base. A little balance should be kept while reading the forum to get the best out of it. With best regards, Nimesh sB ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Ellison Sent: Tuesday, November 25, 2003 10:39 AM To: [EMAIL PROTECTED] Subject: Re: [smartBridges] Tranzeo CPE / APPO Compatibility Yes, all of my ABO's are running 1.08. At least 25% of them still need to reset frequently. It isnt as bad as it was, and I am tyring to setup a "ping" keepalive system by recommendation of this list. It shouldnt be necessary, but it it works for now, I'm game. Ian Pascal Losier wrote: Are those corporate account running the 1.08 firmware and still have to power cyle their unit ???? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Ellison Sent: Monday, November 24, 2003 8:55 PM To: [EMAIL PROTECTED] Subject: Re: [smartBridges] Tranzeo CPE / APPO Compatibility It is great that there are those of you who are experiencing no problems withe sB equipment, sincerely. However, that does not dismiss the fact that there are SEVERAL people using these products, who are all experiencing the same difficulties, that do not seem to exist (at least as much) in so many other manufacturers products. I made the mistake of buying several units at an early stage (all of my units came with the old TRULY transparent firmware), with the (and Im so glad this is no more) 50' of cable attached to the radio. Perhaps since then they have better quality control, or other factors. In the meanwhile, those of us who are so unfortunate to be experiencing these problems are hardly seeing any "price performance" when we are constantly doing tech support and truck rolls to alleviate the issues. the first unit i bought was an Alvarion DS.11, which has (is) run flawlessly (reaching WELL beyond 200 feet i might add ;o). For "price performance" reasons, I made the change to smartBridges. Noise and interference could definitely be an issue, but we are not finding any noise of significance at our location. The suggested steps for resolving my 100% RSSI, 0% Quality problem included checking for interference, etc. When all of htis turned up nothing, i simply replaced the ABO, and it was fine (as well as could be expected anyway). This unit had only been in (highly problematic) operatoin for about 3 months. We havent even made enought money from the subscriber to cover the cost of the unit, and we have to replace it.... I just hope you can see why this is so frustrating to those of us who ARE experiencing these issues. I havent tried RMA yet, but im going to have to try soon. Hopefully smartBridges will make good on their products, and perhaps the newer units will be more robust and less problematic. It goes without saying that one has to appreciate their online customer interaction and responsiveness to suggestions. they get an A+ in that category. I truly hope that the issues get resolved. I have almost all smartBridges equipment in use, and didnt really want to mix manufacturers for CPE. I still have about 10 ABO units brand new in the box (the ones with the attached 50' cable). It would make my day to "trade" them back to smartBridges for the newer units so i can see if there is in fact hope to continue deploying smartBridges. I apologize for the rant, but my largest corporate account has been on the phone ranting to me about how ridiculous it is that they have to reset their internet connection once a day.... I'm about to deploy a PTP 5.8 Ghz link as a temporary solution to make them a happy customer. Another $1000 spent. thats one expensive band aid :o\ Looking forward to a brigher future! Ian [EMAIL PROTECTED] wrote: Just a reminder, there are many of us not having to reset the AB's or any problems for that matter. If you have a problem with 2.4 in general due to noise and interference a different manufacturer is not going to help you. I had a potential competitior who attempted to deploy the "higher priced" Alvarion gear. The furthest they could reach out from the tower was 200', although I think it was stable at 200'. : ) They threw in the towel and are no longer pursuing the wireless internet industry. Be careful in what you spend. A $300 AP and a $1500.00 AP will both become obsolete within 5 years. Again, not everyone is experiencing problems. ----- Original Message ----- From: "Ian Ellison" <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> Sent: Monday, November 24, 2003 4:07 PM Subject: [smartBridges] Tranzeo CPE / APPO Compatibility Has anyone tried using the Tranzeo CPE units with an APPO? Due to the way too many headaches I'm having with ABO's needing reset (constantly), I am venturing out and trying some new CPE until (and then, maybe) sB can get some issues resolved. I'm not even using APPO at my next AP, but am using high-priced Alvarion equipment to test the stability. However my other AP's are still running APPO's, so I'm wondering if anyone else has tried this combination, or has any opinions on the Tranzeo line of products. Thanks, Ian The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org
