Hi Rowell. I know this is old now but very much still relevant. I definately use offsets in design, but only if I have APOS data. I keep the initial prediction at measured and then tune the wall and area attenuation levels to match the passive results as best as possible. Once it is as near as possible, I can then use offsets from the customers devices to help plan coverage cells / AP locations. I guess this topic really highlights the importance of APOS surveying and getting the real world coverage pattern in the environment. EG: a wall that actually measures say 3dB attenuation in the passive survey, I may have to decrease or increase on the planner to make up for a slightly incorrect in-built Ekahau AP pattern. In your Video as an example, I would drop the wall attenuation, well to 0dB! Or I have sometimes used a different antenna or AP model in the planner in order to more accurately represent the real-life coverage. Or to decrease the overall signal spread of a virtual AP, I drag an attenuation area around the whole floorplan, and tweak the attenuation level until it matches the passive survey. Gees, that got long quick! Love your podcast, long time listener. Paul
Depends on the propose of the network. If it's important to make sure all smartphones are properly served, I give a look at rssicompared.com a check the values for a particular smarphone (usually iphone 6 or samsung S8). But, more importantly, if I'm planning for a warehouse, I'll try to find the specs of their worst bar-code readers and adjust accordingly. If that's not possible, I use the -10dB offset as a precaution. But lately I've seen some recent bar-code readers measuring the same level or very close to the one reported by the sidekick.
7:22 Hey Rowell, do you still disable the offset when performing a predictive planing with Ekahau? In this video, there is a really huge deviation between simulation and real world measurement. But I'm not sure if that is an issue within Ekahau's software or if it was speific to this location or your Sidekick. The question is, if Ekahau needs to adapt/tune their algorithms or if is really best practice to only use the offsets in active measurements. Have you seen the same behavior at other locations or with latest Ekahau software? Thanks and best Regards Tony
I haven't used offsets with predictive planning in a long time. With the latest updates, I can do a new test and see if there's any difference. I have access to an additional sidekick which we can use to rule out any sidekick issues.
Hi Rowell, nice video! It would be very interesting to see what your solution was for this environment. A series of problem/solution examples like this would be very educational because it is very graphical and real-life.
I had advised to move access points and turn some off. In this case they didn’t move any but time will tell. I may be able to share other scenarios in the future.
I dont like the offsets being on by default. a 10dB diff can make it inconsistent if you design with an offset and measure without it. depends on who is driving ekahau you could get a customer reviewing a data set and not like what they see due to the offset being on. I like things to be consistent. the sidekick is great for this. i can have 2 different people walk a room with sidekicks and we have almost identical heat charts. + - couple dB depending on which way you walk. On the too many APs....well there are a lot of seats there, if they dont have hardwired stations, and rely on wifi for primary connectivity, then maybe its not such a heavy handed design. There are enough 5G channels to support the number of APs if using 20MHz channel width. certainly disable some of the 2.4G radios. I dont like the AP layout so much, would have some in the meeting rooms.
Unfortunately, someone had made that design choice before I was engaged. I did make the recommendation to move some APs into the meeting room(s). I don't like using offsets by default either. I only find them useful in a validation survey.
Hey Rowell, I am trying to understand how come you have 27 dB diff between raw predictive and raw Sidekick data at 6:27. That is a massive difference and I believe it can only be explained by having different Tx power levels or the attenuation levels are not correct. When the diff is that massive, the "View as Mobile" or any offset is not going to make the situation suddenly any better.
I did use only a 3 dB wall measurement and I know the APs were set the same transmit power level. I plan on doing a follow up video with a different project to see if there’s anything similar.
I agree with Mikko that the difference in dBm is too big. I don't want to be too pedantic but looking at the survey view (right side) the AP's are not blue (blue indicates that the AP's were frozen during the validation walking). If I am right and the AP's were not frozen during validation then the validation survey values will be overexaggerated (incorrect) as the software cannot delineate the boundaries of signal propagating from each of the individual AP's at each location: essentially, the signal from all these AP's gets added and aggregated (and compounded) and that's what may be causing one AP appear to cover the entire floor and account for this massive 27 dBm difference here. Just a thought. I would also ensure that the scaling is precisely the same for both predictive and validation.
what was the difference between the powers levels of the 2 access points that you showed? In my opinion this difference was far too big and why was this chosen for this?
@@ClearToSend the two on the left in the validation. The first you showed covered almost the compleet room and the second you showed at the end did just covered a small area.
nice Prusa
Haven't used it in a while :/
Hi Rowell. I know this is old now but very much still relevant.
I definately use offsets in design, but only if I have APOS data.
I keep the initial prediction at measured and then tune the wall and area attenuation levels to match the passive results as best as possible.
Once it is as near as possible, I can then use offsets from the customers devices to help plan coverage cells / AP locations.
I guess this topic really highlights the importance of APOS surveying and getting the real world coverage pattern in the environment.
EG: a wall that actually measures say 3dB attenuation in the passive survey, I may have to decrease or increase on the planner to make up for a slightly incorrect in-built Ekahau AP pattern.
In your Video as an example, I would drop the wall attenuation, well to 0dB! Or I have sometimes used a different antenna or AP model in the planner in order to more accurately represent the real-life coverage. Or to decrease the overall signal spread of a virtual AP, I drag an attenuation area around the whole floorplan, and tweak the attenuation level until it matches the passive survey.
Gees, that got long quick! Love your podcast, long time listener.
Paul
Depends on the propose of the network. If it's important to make sure all smartphones are properly served, I give a look at rssicompared.com a check the values for a particular smarphone (usually iphone 6 or samsung S8).
But, more importantly, if I'm planning for a warehouse, I'll try to find the specs of their worst bar-code readers and adjust accordingly. If that's not possible, I use the -10dB offset as a precaution.
But lately I've seen some recent bar-code readers measuring the same level or very close to the one reported by the sidekick.
Thanks for your input, Vasco. That’s a great resource to use and saves on guessing the offset.
7:22 Hey Rowell, do you still disable the offset when performing a predictive planing with Ekahau? In this video, there is a really huge deviation between simulation and real world measurement.
But I'm not sure if that is an issue within Ekahau's software or if it was speific to this location or your Sidekick. The question is, if Ekahau needs to adapt/tune their algorithms or if is really best practice to only use the offsets in active measurements.
Have you seen the same behavior at other locations or with latest Ekahau software?
Thanks and best Regards
Tony
I haven't used offsets with predictive planning in a long time. With the latest updates, I can do a new test and see if there's any difference. I have access to an additional sidekick which we can use to rule out any sidekick issues.
@@ClearToSend Thank you for your fast response! I will also test that with one of my next surveys.
Hi Rowell, nice video! It would be very interesting to see what your solution was for this environment. A series of problem/solution examples like this would be very educational because it is very graphical and real-life.
I had advised to move access points and turn some off. In this case they didn’t move any but time will tell. I may be able to share other scenarios in the future.
High agree
I dont like the offsets being on by default. a 10dB diff can make it inconsistent if you design with an offset and measure without it. depends on who is driving ekahau you could get a customer reviewing a data set and not like what they see due to the offset being on. I like things to be consistent. the sidekick is great for this. i can have 2 different people walk a room with sidekicks and we have almost identical heat charts. + - couple dB depending on which way you walk.
On the too many APs....well there are a lot of seats there, if they dont have hardwired stations, and rely on wifi for primary connectivity, then maybe its not such a heavy handed design. There are enough 5G channels to support the number of APs if using 20MHz channel width. certainly disable some of the 2.4G radios. I dont like the AP layout so much, would have some in the meeting rooms.
Unfortunately, someone had made that design choice before I was engaged. I did make the recommendation to move some APs into the meeting room(s). I don't like using offsets by default either. I only find them useful in a validation survey.
Hey Rowell, I am trying to understand how come you have 27 dB diff between raw predictive and raw Sidekick data at 6:27. That is a massive difference and I believe it can only be explained by having different Tx power levels or the attenuation levels are not correct. When the diff is that massive, the "View as Mobile" or any offset is not going to make the situation suddenly any better.
I did use only a 3 dB wall measurement and I know the APs were set the same transmit power level. I plan on doing a follow up video with a different project to see if there’s anything similar.
I agree with Mikko that the difference in dBm is too big. I don't want to be too pedantic but looking at the survey view (right side) the AP's are not blue (blue indicates that the AP's were frozen during the validation walking). If I am right and the AP's were not frozen during validation then the validation survey values will be overexaggerated (incorrect) as the software cannot delineate the boundaries of signal propagating from each of the individual AP's at each location: essentially, the signal from all these AP's gets added and aggregated (and compounded) and that's what may be causing one AP appear to cover the entire floor and account for this massive 27 dBm difference here.
Just a thought.
I would also ensure that the scaling is precisely the same for both predictive and validation.
what was the difference between the powers levels of the 2 access points that you showed? In my opinion this difference was far too big and why was this chosen for this?
Which two access points? The top left access point in the predictive and in the validation are both set to 20 dBm.
@@ClearToSend the two on the left in the validation. The first you showed covered almost the compleet room and the second you showed at the end did just covered a small area.
@@deleeuw83 Rowell said in the video that the other AP was at the lowest power possible. That is why there is such a big difference.