Monitoring an RF24/NRF52x Network Continued...

 Monitoring an RF24/NRF52x Network Continued...

Explaining the recent changes

So in my last blog post I noted the progress I made in automating and monitoring my radio network, and it has been super interesting. Due to the ongoing activities affecting my network, it has become more robust and functional than ever, with bug fixes and recent changes vastly improving functionality of the network.

The network uses the RF24Gateway & RF24Ethernet libraries to enable use of the RF24 & RF52 radios as standard Network Interface Cards (NICs), with full TCP/IP support. The system makes use of the HTTP & MQTT protocols for communication. This along with software like Home Assistant and/or Node Red allows full automation of the network, including the generation of graphs, charts and buttons/controls.

The obsessive hacker activity that has been going on for years has now finally stopped for an astounding few days! I'm not exactly sure what finally did it, but I can only assume this person reads my blog.

The following screenshot shows the results of the past few days now, with the tail-end of some interference lowering the results, but very promising none the less. This is 0.3 percent packet loss after a few days of monitoring on a network with 17-18 Mesh/Ethernet nodes and going up!

It is super nice to be able to test, monitor and operate these little radios the way they were intended, without constant bombardment and incoming packets from my neighbor. Due to recent changes and a lack of interference, my MQTT nodes are now staying connected to the server for a large number of hours instead of minutes, and because of this are more responsive and communicative than ever. All statistics are up from the norm and looking good! The below video shows the connection times for 10 MQTT nodes on my network.

The video below shows my 'activity monitor' in which 15 of my active nodes are reporting in every few seconds. They simply identify themselves and show that they are active. An inactive node will fall behind quickly, making it obvious it is not active as its bar will not move. The intent is simply to put extra load on the network and keep track of any nodes that are failing.

Interestingly enough, when I introduced the ability to change the channel the network operates on, a small number of nodes would fail when I activated this functionality. I've found the issues to be hardware related, as when adding capacitors or replacing the connecting wires and/or nodes themselves, the problems went away. It seems changing channels regularly is kind of hard on the devices. It requires them to be pretty sound hardware-wise. All in all its been a good few days for the radio network. Lets just hope this keeps up!