| NurdBot Lora Failover | |
|---|---|
 | |
| Participants | Melan |
| Skills | Arduino, python |
| Status | Done |
| Niche | Infra |
| Purpose | Use for infra |
| Tool | No |
| Location | |
| Cost | |
| Tool category | |
NurdBot Lora Failover Property "Tool Image" (as page type) with input value "File:{{{Picture}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process. {{{Picture}}} {{#if:No | [[Tool Owner::{{{ProjectParticipants}}} | }} {{#if:No | [[Tool Cost::{{{Cost}}} | }}
As we are transitioning to a new internet connection, there is a high chance that we will be without internet on the space for a few days. This project aims to make is so that Nurdbot will still have access to IRC so that we can keep using certain commands and still somewhat interact with the space while it's in a state of offline.
What/How/Setup
The idea first was to roll our own code. And while a lot of success was booked during the weekend, IRC communication turned out to be troublesome. So we went looking for an alternative
Meshtastic supports running a tcp/ip tunnel over the mesh network. This worked, but the RRT was incredibly high.
melan@nurdbot-node:~$ sudo ping 10.115.130.156
PING 10.115.130.156 (10.115.130.156) 56(84) bytes of data.
64 bytes from 10.115.130.156: icmp_seq=2 ttl=64 time=6422 ms
64 bytes from 10.115.130.156: icmp_seq=4 ttl=64 time=15670 ms
64 bytes from 10.115.130.156: icmp_seq=6 ttl=64 time=16630 ms
64 bytes from 10.115.130.156: icmp_seq=7 ttl=64 time=20545 ms
64 bytes from 10.115.130.156: icmp_seq=8 ttl=64 time=22640 ms
64 bytes from 10.115.130.156: icmp_seq=9 ttl=64 time=27665 ms
64 bytes from 10.115.130.156: icmp_seq=11 ttl=64 time=34147 ms
64 bytes from 10.115.130.156: icmp_seq=13 ttl=64 time=48633 ms
64 bytes from 10.115.130.156: icmp_seq=15 ttl=64 time=58938 ms
64 bytes from 10.115.130.156: icmp_seq=16 ttl=64 time=61078 ms
64 bytes from 10.115.130.156: icmp_seq=18 ttl=64 time=60796 ms
Looking for something else, I came across rnode by unsigned.io in combination with tncattach.
Tncattach allows you to attach TNCs or any KISS-compatible device as a network interface, and the rnode can function as a TNC device. After a bit of tweaking, I was able to get some decent ping times with the nodes about two meters apart in a single room.
melan@debi:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2154 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=1302 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=789 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=441 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=437 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=437 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=437 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=440 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=440 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=440 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=437 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=438 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=440 ms
64 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=437 ms
64 bytes from 10.0.0.2: icmp_seq=15 ttl=64 time=437 ms
64 bytes from 10.0.0.2: icmp_seq=16 ttl=64 time=437 ms
This allows to use IRC over TCP over LoRa! And it works surprisingly alright once the server (znc) has synced with the client. There is a lag of a few seconds, as well as the occasional lag spike. But the client (hexchat) seems to able to recover from it without any problems.
If it will work in the field (from the space to Melans house) will still have to be tested so that's a TBD.
As expected, the connection to Melan's house wasn't really working. The antenna at the space had enough oompf to reach but the other way around was very poor. Possibly, changing the node at Melan's house could have worked.
However, we decided to place the node at a other member's house instead (Boopatroopa) as he lives only about 200 meters from the space. The node was attached to his attic's window, pointed towards the space. Which provided a stable enough connection that we were able to, surprisingly well, push traffic through it while it remained somewhat stable!
nurds@sdr:~$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=471 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=451 ms
64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=437 ms
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=437 ms
64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=438 ms
64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=437 ms
--- 10.0.0.1 ping statistics ---
9 packets transmitted, 6 received, 33.3333% packet loss, time 8054ms
rtt min/avg/max/mdev = 437.169/445.366/471.162/12.595 ms
Both ends are running a ZNC that are connected to each other. This way, disconnects are barely noticeable. What takes the longest is the initial sync as it takes a few minutes to get all the channel and user information. After that the bot responds pretty well. Often the bot would take some time to respond to a command, but there are also times the bot responds incredibly fast (within a second).
Stability is an issue, though. As about 24 hours since the deployment ZNC at Boopatroopa's side started having weird issues. A reboot of both nodes proved to be sufficient to bring it all back up. (Worst case, we can now fall back to LTE if we really wanted.)
July 8 update: It worked, although every 24 hours or so ZNC started to have an issue and everything needed to be restarted. Eventually we switched the bot to be over LTE as well. Still, this worked surprisingly well and it allowed the bot to have more uptime. All by all, it was a success.
settings
After playing around with the settings for the LoRa transceiver I settled down on the following:
[18:59:13] Radio reporting frequency is 863.0 MHz
[18:59:13] Radio reporting bandwidth is 120KHz
[18:59:13] Radio reporting TX power is 17 dBm
[18:59:13] Radio reporting spreading factor is 7
[18:59:13] Radio reporting coding rate is 4
To set the rnode to this, you have to run the following command:
rnodeconf /dev/ttyUSB0 -T --freq 863000000 --bw 125000 --txp 17 --sf 7 --cr 4
After that, you can run tnattach with
tncattach /dev/ttyACM0 115200 --mtu 400 --noipv6 --noup -v
- Note: you can also run it without the -v or by enabling daemon mode (-d)
After running tnattach on both sides you can make the point-to-point connection
sudo ifconfig tnc0 10.0.0.1 pointopoint 10.0.0.2 (node A)
sudo ifconfig tnc0 10.0.0.2 pointopoint 10.0.0.1 (node B)
Old idea
The (old) idea was to proxy irc over MQTT and lora. A program was to be run the NurdSpace side and a program running at a melan's house. The communication between these would have been over Lora, using mqtt to receive and send the data to the lora transceivers.
