Issues with multiple gateways + choosing frequency / channel

[Yveaux]

Build the sniffer. It will answer your questions...

[bjornhallberg]

@Yveaux Thanks for the suggestion. I've set up your sniffer now and it seems to be capturing as intended. I'll run it for a while and see what it picks up. Any hint as to what I'm looking for? Crc errors? This is completely incomprehensible to me ...

Hmmm. Turning on the sniffer seems to have immediately affected the serial gateway I have connected to my RPi and the script gets bungled up after having run perfectly for the past day. From the log:

2014-09-17 07:38:25 | 23 1 1 0 0 | 23.3
2014-09-17 07:38:25 | 23 0 1 0 1 | 48.4
2014-09-17 07:56:35 | .3 0 0 0 0 | 0
2014-09-17 07:56:36 | 22 0 1 0 0 | 22.3
2014-09-17 07:59:24 | 23 1 1 0 0 | 23.2
2014-09-17 07:59:25 | 23 0 1 0 1 | 48.3

Node 22 seems wonky. In Wireshark I see some repetition and CRC errors:

The battery powered node 24 is just dead since yesterday so no data on that yet.

[bjornhallberg]

I moved node with id 24 back into its position where it worked reasonably well yesterday, pushed the reset and got this in the log:

Basically, all nodes are sending the same data multiple times, often just twice, but sometimes up to 15 times ... ? The serial gateway log shows none of this, but it is on the other hand two more walls and several meters away.

A more general question though, are all of you running on channel 76? Has anyone tweaked this and if so what happened?

[Yveaux]

@bjornhallberg In MySensors 1.4 the auto-ack feature of the nRF24 has been enabled. This means the nRF24 will wait for an acknowledge from the destination node for messages sent and automatically retry after a configurable timeout.
The maximum number of retries is set to 15 in the MySensors library, with 5*250us (= 1250us) timeout.
This is what you see in the WireShark logs: The sending node does not receive an ack from the destination and retries up to 15 times before giving up. This clearly indicates the destination is out of range.
If you run the sniffer near the gateway you'll probably see very few messages arriving there, or a large amount of CRC errors.
The first few messages after startup are sent without auto-acks and are therefore not retried.

You mention a change in sensor reception when the sniffer is capturing, but the sniffer should not influence the behavior of other nodes within range, as it's set to receive only.

[bjornhallberg]

@Yveaux Ah, thanks for explaining. I thought ack was something you had to manually enable or something. Did not know it ran by default. It does make more sense now. I'll make some more tests, but range so far is pretty disappointing. On the other hand I have put my serial gateway in a very stupid place, just to be able to run everything on the same RPi. I might have to reconsider that.

As for the other issue it could have been a fluke with the reception at the serial gateway. Running two gateways also seemed to make things worse but I don't know.

Do you think there is anything to gain from meddling with the channel / frequency?

Or is the RepeaterNode a more viable option perhaps? How does that work with ack?

[Yveaux]

@bjornhallberg said:

I thought ack was something you had to manually enable or something.

For end-to-end acknowledgement you have. Hop-to-hop is auto-enabled in 1.4.

range so far is pretty disappointing

Using filters, as explained on my blog, you can determine where reception is best or test how it improves.

Running two gateways also seemed to make things worse but I don't know.

Running two gateways with the same base network-ID and channel will certainly make things worse as you then have two captains on your ship. Behavior is undefined then...

Do you think there is anything to gain from meddling with the channel / frequency?

Possibly, but channel 76 is nowhere near wifi. There is a scanner sketch accompanying the original RF24 library that scan channels for activity. You can use it to determine where it is 'silent'.

Or is the RepeaterNode a more viable option perhaps? How does that work with ack?

When two nodes are out of eachothers reach (what seems to be the case in your situation) a repeater somewhere inbetween might certainly help. Again, hop-to-hop acks are auto (sensor <-> repeater and repeater <->gateway) and end-to-end (sensor <-> gateway) you have to enable.
To be sure the route will go through your repeater you'd better use static node ID's and pass the parent gateway along in the constructor. If everything is left to be determined automatically, your sensor node might just see the gateway and still try to talk to it directly....

[daulagari]

@bjornhallberg said:

The default MySensors frequency is (2400+76)MHz, which puts it just outside of the reach of WIFI channel 11 (2451-2473MHz). Is it worth tweaking this? Running it higher would put it outside sanctioned space, but it would also decrease wall penetration somewhat (enough to be noticed)?

I think it is worth a try to just above the band, in Europe channel 13 is allowed, so 2462-2482 MHz, so if you are in Europe, 2482 MHz would be a good pick.

Running it lower would make it contend with actual WIFI traffic but might give you some slightly better reach. Thoughts?

No, you will not noticed the better reach unless you have strange multi-path reflection that by accident interfere.

How far as the closest by WiFi devices?

The LNA of the receiver of the nRF24L01 is (like almost all 2.4 GHz IC's nowadays) wide-band meaning it is seeing the whole 2.4 GHz band. Even if the WiFi channel is on channel 1 and you are at the end of the band a WiFi signal that comes in 20 dB louder than the nRF24L01 receive signal will likely impact the receive either due to ACI effects or to WLAN Out-Of-Band.

[bjornhallberg]

@Yveaux said:

Running two gateways with the same base network-ID and channel will certainly make things worse as you then have two captains on your ship. Behavior is undefined then...

Roger that. I didn't consider this initially, just thought it was neat for testing different controllers.

Possibly, but channel 76 is nowhere near wifi. There is a scanner sketch accompanying the original RF24 library that scan channels for activity. You can use it to determine where it is 'silent'.

I did run this before building your sniffer but forgot about it. Not sure how to interpret the results though, the serial monitor outputs 127 1s or 0s. But what does 1 mean in this context? Just unsuitable? Or dead impossible? I can run it some more and post the results here, but I do recall I got sporadic 1s all the way up to channel 74 or 75, and that was in the middle of the day with not much traffic coming from my neighbors' WIFI, only my own. Ironically never got any 1s on the first couple of channels (despite using WIFI channel 1 myself) so from that scanner it seems about as likely that 2401 or 2402 MHz would work as 2476 MHz.

When two nodes are out of eachothers reach (what seems to be the case in your situation) a repeater somewhere inbetween might certainly help. Again, hop-to-hop acks are auto (sensor <-> repeater and repeater <->gateway) and end-to-end (sensor <-> gateway) you have to enable.
To be sure the route will go through your repeater you'd better use static node ID's and pass the parent gateway along in the constructor. If everything is left to be determined automatically, your sensor node might just see the gateway and still try to talk to it directly....

Sorry for being a bit daft (again) but how does this work? Without a repeater the signal could only hop through other nodes (and they will most likely all be sleeping). Does the radio wake or some such? And given the nature of the network, would adding more nodes all over automatically heal the network and improve its performance? Re-reading the official description, it seems I'd have to convert at least some sensor nodes to sensor-repeater-nodes and that there is no way to do this on battery power.

I should try the repeater then. Since I don't have a proper controller I should probably get used to static IDs anyway.

But why am I seeing double entries in the sniffer log even for a node that is literally 1m away from the sniffer and perhaps 2m (and two thin walls) away from the serial gateway? That seems to me like some pretty bad range. Could this be power (capacitor) related somehow?

@daulagari said:

I think it is worth a try to just above the band, in Europe channel 13 is allowed, so 2462-2482 MHz, so if you are in Europe, 2482 MHz would be a good pick.

I'll definitely experiment with this and beyond. The reason I asked is that the rule of WIFI channels afaik is to overlap rather than try to be clever and cram in between channels. So I wondered if that would be true for the nrf24 as well.

How far as the closest by WiFi devices?

Well, I have a dedicated WIFI access point behind the TV just for my mobile phone, so two meters perhaps from node 24 (the worst performer). A TP-Link TL-WA901nd (three big antenna) running OpenWrt. When I access the network from the other side of the house, OpenWRT has this to say:

Channel: 1 (2.412 GHz) | Tx-Power: 15 dBm
Signal: -75 dBm | Noise: -95 dBm

I do recall I had Tx-power higher when I first installed it but later dialed it down a bit and improved at least the perceived network speed. Though it is hard to say with all these custom roms running on Android phones. Could be a newer rom worked better thats all. Or a newer OpenWRT. Hard to say.

I also have DECT phones, one right next to the sniffer in fact, BUT they are newer DECT that operates around 1.7-1.9 GHz. Though who knows what else they put out.

The LNA of the receiver of the nRF24L01 is (like almost all 2.4 GHz IC's nowadays) wide-band meaning it is seeing the whole 2.4 GHz band. Even if the WiFi channel is on channel 1 and you are at the end of the band a WiFi signal that comes in 20 dB louder than the nRF24L01 receive signal will likely impact the receive either due to ACI effects or to WLAN Out-Of-Band.

I should probably look into this. Turn off my WIFI temporarily and see if it makes any difference, perhaps I could schedule it to turn off a few hours during the night to get a good comparison.

[bjornhallberg]

Node 22 sure is noisy ... but how to interpret this? Is the gateway supposed to answer or is it just spontaneously looking for a sensor/repeater node? Something wrong with the gateway's ability to send? Need to reset the eeprom and routing table of the gateway (I reset all the sensor nodes before flashing them already)?

Also, I brought up the apparently dead node next to the sniffer and pushed reset

So it's alive at least but with some repetition.

[Yveaux]

@bjornhallberg Regarding your first trace:
You see node 22 sending to 0 (gateway) and starting from record #15 sending to 255 (broadcast). This is where it decided it has lost its parent because it failed too many communications to its parent and starts looking for a new one (INTERNAL & FIND_PARENT).
The messages either don't reach the gateway and/or the gateway's replies doen't reach node 22.

In the first trace you see the startup sequence of node 24 communicating to gateway. It does send messages multiple times, but this could be related to a bug I fixed in the development tree.

Not sure how to interpret the results though, the serial monitor outputs 127 1s or 0s. But what does 1 mean in this context?

What I recall from running this sketch in the past is you should leave it running for quite some time and occupied channels will show an increasing value over time. Choose a channel which remains 0 (or even better the center of a number of channels that remain 0).

Sorry for being a bit daft (again) but how does this work? Without a repeater the signal could only hop through other nodes (and they will most likely all be sleeping).

Sleeping nodes should not be started as repeater. You're right that most of the time they will not be able to route messages because they're... uhhhmmm... sleeping ;-)
So add a repeater somewhere inbetween gateway and problematic node(s), add this gateway's node ID as static parent to the sleeping nodes and try again.

[bjornhallberg]

@Yveaux Ok, thanks for the clarification. I'll look into both the repeater and troubleshooting/moving the gateway.