User Mesh Distances. Lets come up with an average

General
1

There is a similar topic which got closed Mesh distance between devices

So I am starting a new one.

This link is more about how many devices to have to cover an area.

In this thread I have some results from my preliminary studies but I think as a community if many people post their results we can get a better understanding of the new Mesh Devices.

Using the ideas of Business-Home-LineOfSight here are my results averaged over several days. Using this concept:

Business/School: concrete floors, lots of metal framing/school lockers, Busy Wifi
Home: wood, a few walls, private Wifi, windows
LineOfSight: Outside, both devices can directly see each other

results
results904Ă—213 13.3 KB

I am still not sure if the Argon (Gateway) or Xenon (Endpoint) having the antenna makes any difference.

My home amounts might be too high since I had to go outside for all of them, someone with a bigger house may have smaller values.

2 Likes
2

Thanks for re-opening this topic/opening a new topic and sharing your findings.

My particular interest is a Business Office/School/University environment and my initial results (using the macro:polo test code and monitoring via the console for missing devices) indicate much shorter distances even with 0.8.0-rc.26 (with radio power boosted by 8dB) with no external Antennas.

The improvement with external antennas is encouraging - I run all current devices (Photons) with antennas as experience has shown that this generally gets devices away from the borderline signal strength. Monitoring the RSSI over time in busy environments has shown the enormous variations in signal due to interference and attenuation.

It would be interesting to be able to monitor the RSSI for mesh radio nodes?

1 Like
3

@rocksetta, to better represent range, your circle boundaries should overlap at their centres. This represents the node-to-node maximum distance:

image

This “matrix” configuration follows the optimal 4-neighbour arrangement for redundancy. By filling in the intesticial spaces will allow each node to have a 70% max distance neighbour, increasing mesh connectivity with very few extra nodes:

image

This is what I meant by careful mesh design.

I believe current testing methods for range need to be standardized. Also, Mesh connectivity and Cloud connectivity need to be tested separately. I have observed uninterrupted mesh connectivity while a device was trying to the Cloud. Their interdependence in a mesh design is still not crystal clear to me. As mesh stability improves, this “balance” should be explored.

5 Likes
4

Nice diagrams @peekay123, that makes a lot of sense. Still Dmax is variable based on the landscape (walls, metal, concrete etc) and decreasing Dmax will probably strengthen your network stability, but dramatically increase your number of devices.

By the way, has anyone done a line of sight effect of a simple pane of glass? Haven’t fully tested it but it seems that a mesh device inside a car with line of sight through the window has a much reduced range.

Found this article which might be relevant https://community.ubnt.com/t5/airMAX-General-Discussion/Is-it-normal-to-lose-15-dB-through-a-single-double-pane-window/td-p/250353

Never realized glass was so complex. At work and in my car the glass might have a metalic layer killing RF, but my house glass might be fine. Will need to test.

5

@rocksetta, agreed regarding Dmax. However, my point was that mesh topology planning is crucial to a successful mesh deployment. My interest is in separating the mesh connectivity from the Cloud connectivity for testing. Characterizing mesh antennas (eg. duck vs pcb) is important as well. Your approach to characterizing different obstructions such as wall, concrete, glass, etc. is excellent. Given the 2.4GHz frequency being used, I wonder if some data is not already available.

There is much work to be done that remains to be done. Your contributions will hopefully get others to contribute to this body of knowledge.

BTW, I have asked Particle if they could come up with a suite similar to marco-polo for mesh testing. It would be interesting to know not only the distance a node can remain connected at but also what data rate is achievable at that distance.

3 Likes
6

Really good point. Shouldn't we be able to make some software that gives a sense of data rate? Can't get my brain around how to do it. Would it just be an increasing for loop with Mesh.publish?

7

@rocksetta, a mesh pub/sub would need to be time-characterized with various fixed payloads. Knowing the average pub-recv-pub-recv transaction time, an estimate of single-leg (eg. gateway to node) can be calculated and plotted. Another approach is to not use mesh pub/sub and do UDP directly from a node to the gateway with the gateway sending back a simple ack via UDP. I suspect when the DeviceOS overhead is removed from both approaches, the data rate will be the same. Again, more to discover!

3 Likes
8

Good article about what effects the range

http://www.pearsonitcertification.com/articles/article.aspx?p=1329709&seqNum=3

Interesting chart on the page and this summary

Physical objects: Trees, masonry, buildings, and other physical structures are some of the most common sources of interference. The density of the materials used in a building’s construction determines the number of walls the RF signal can pass through and still maintain adequate coverage. Concrete and steel walls are particularly difficult for a signal to pass through. These structures will weaken or at times completely prevent wireless signals.

Radio frequency interference: Wireless technologies such as 802.11b/g use an RF range of 2.4GHz, and so do many other devices, such as cordless phones, microwaves, and so on. Devices that share the channel can cause noise and weaken the signals.

Electrical interference: Electrical interference comes from devices such as computers, refrigerators, fans, lighting fixtures, or any other motorized devices. The impact that electrical interference has on the signal depends on the proximity of the electrical device to the wireless access point. Advances in wireless technologies and in electrical devices have reduced the impact that these types of devices have on wireless transmissions.

Environmental factors: Weather conditions can have a huge impact on wireless signal integrity. Lightning, for example, can cause electrical interference, and fog can weaken signals as they pass through.

Lots more testing can be done even before Particle gets full mesh connectivity going.

I need to do my line of sight tests on a foggy day and users should expect complete collapse of there outdoor systems during a thunder storm.

My update is that I am only really interested in the line of sight studies. Too many ways that the data can get messed up inside a building. I will try testing glass today. One cool idea is; could a mirror or sheet of aluminum foil strategically placed inside a building reflect a signal around a major RF blocker!

1 Like
9

Most likely not but it would be the typical location for a repeater node.

3 Likes
10

Typically people attenuate wifi signals and because they move around that makes the attenuate dynamic and thus difficult to plan a mesh topology for - this is where the mesh repeater devices come in.

I think you are onto something with the WiFi coverage design tools - I have seen a very good one from aerohive. I wonder if there are any open source tools?

11

You got to read this

12

Update on experience using Mesh network in a very hostile WiFi environment.

I just visited the EdTech show that is on in London this week called Bett 2019. I had the opportunity to test out a simple mesh network on one of exhibitors stands (with their permission). With the base using a xenon with ethernet featherwing connected to LAN and with a 20cm whip antenna and the end node a xenon with an external antenna but of the PCB variety with a short tail.

The simple application was to check whether the end node acting as a remote control (up and down buttons) would operate reliably in this environment. Both base and end node were running on 0.8.0-RC.27. The base subscribes to the end node and the end node does a mesh.publish() when a button is pressed.

Not much quantitative testing as I could not watch the console while the test was being performed unfortunately but findings were as follows:

  1. Mesh network established itself quickly and reliably (when base and end node close < 1m).
  2. Comms appear to work reliably while the base antenna was vertical and off the ground (it was in cupboard on the stand and everytime someone went in they would knock the base over!).
  3. The mesh connection worked up to 5-6m from the base but would then lose connection - going back nearer to the base allowed the mesh connection to re-establish itself (again worked quickly).

This environment had at least 50 visible WAPs - probably more but my phone only displays that many. Photons are completely defeated. The range was a little disappointing but highlights the need for base and end nodes to use external antennas. Is there more scope to up the transmitting power?

2 Likes