IRC as a transport. Very clever.
## What is it?
An RNode is any [supported device](https://unsigned.io/guides/2022_01_25_installing-rnode-firmware-on-supported-devices.html) (see the _"Device variations"_ section) that runs Mark Qvist's firmware.
What does the firmware let you do?
1. LoRa sniffer
2. LoRa TNC
a. Think of a point-to-point IP link over LoRa
b. This will be covered in part 2
3. LoRa interface for a Retciulum node
You can see all of this in the _"One tool, many uses"_ section [here](https://unsigned.io/hardware/RNode.html).
## Parts list
)
)
I decided to purchase 2 of the **LillyGo T3-S3**'s which make use of the SX1276 chipset.
* This is important as this is a chipset which has support in the RNode firmware.
* The model I am buying is the 868Mhz model as that was all I could get my hands on in ZA
I specifically bought 2 because I doubt there is anyone in my area running the RNode firmware and doing Reticulum over it. Secondly, _even_ if there was someone then I wouldn't have full control over my tests.
This device can be purchased locally [here](https://www.robotics.org.za/development-boards/esp32-lilygo-boards/H596).
## Flashing the firmware
I have documented two ways in which one can install the firmware onto your device. The reason for this was because I initially had some issues using the auto-installation feature of `rnodeconf` - it would flash but wouldn't fully perform all the needed parameter setting on my device.
#### Prerequisites
Firstly you will need to install the `nrs` package using `pip`. This package will make the `rnodeconf` executable available for you, which will allow us to both **install the firmware** _and_ **configure our RNode** (as multiple modes exist).
Installation can be performed with:
```bash
pip3 install rns -y
```
#### Serial device access
When we plug in our device it will appear as some sort of `/dev/ttcyACMx` device (where $x$ is some number). This device type is a serial device and in order to get access to all-and-any serial device one must either be a part of the `dialout` group or `root`. The latter is overkill and I would much rather we use an approach that **doesn't** require us running the `rnodeconf` tool as a user other than our own.
To add yourself to the `dialout` group run the following command to append (`-a`) a new group (the `-G`) to your current user:
```bash
sudo usermod -aG dialout deavmi
```
In my case my username is `deavmi`.
#### Flashing the firmware
The first step is to plug in your device. **However**, whilst plugging it in via the USB-C port you must be holding the `Boot` button on the board:
)
Now you will need to run `dmesg -w` (you might need to run it as `root`). This is just so we can see the device path of the serial device we just plugged in:
)
As you can see mine is `/dev/ttyACM1`
>**Note:** Before we begin, ensure that no other application is using this serial device. I had that happen to me by mistake (as I had `rnsd` running and pointed to my RNode at the same device path). It will not work if something else is using the serial device at the same time (specifically if it is actively communicating with it whilst `rnodeconf` is _also_ trying to)
Let's now begin the installer with the command `rnodeconf /dev/ttyACM1 -a`. Next we will be asked a few questions:
1. You will be asked which device you are using, in my case it is the `[9] LilyGO LoRa T3S3` option.
2. Next you will be asked to select the band that the radio is to be configured in. In my case that would be the 868Mhz band, so I must select the `[2] 868/915/923 MHz (with SX1276 chip)`
a. Also note that there are normally two options **per** band, I went with this option as I am using the `SX1276` chipset as mentioned earlier
3. Now you will be presented with the following screen, check that everything is in order before hitting any key:
```
Confirm detals:
Serial port : /dev/ttyACM1
Device type : RNode 820 - 960 MHz
Platform : ESP32
Device MCU : Espressif Systems ESP32
Firmware file : rnode_firmware_t3s3_sx127x.zip
```
**Note:** The tool only seems to support downloading with `AF_INET` (meaning that IPv6 support doesn't work)
Now hit enter. Please note that, at least for now, the installation is not complete when it finishes and it won't reboot the device automatically for you. Once you get the message that the installer failed to do so, then you can power cycle your device.
#### Finishing up
Because there is a slight bug in the installer we now need to perform the following.
Firstly, when you boot the device you will get a nasty warning that the "hardware failure":
)
To fix this we first completely wipe the data that says what model the firmware is expecting and replace it with what it _should_ expect (our model details); hence getting rid of the mismatch of models. Before we begin you must hit the `Reset` button:
)
Now we can run the command:
```bash
rnodeconf --eeprom-wipe /dev/ttyACM1 # Wipe old settings
rnodeconf -r --model aa --product f0 --hwrev 1 /dev/ttyACM1 # Set the CORRECT model information
```
Now we will have _another_ error, this one occurs because the firmware has a hash digest generated for it and then one stored in memory as well. If the `hash(firmware_current) != hash(firmware_expected)` then a UI warning appears:
)
This can be fixed by obtaining the hash of our _current firmware_ and then overwriting the _expected hash value_ parameter; therefore making them match and making that UI error disappear. First let's get the current hash with:
```bash
rnodeconf /dev/ttyACM1 -L
```
Now set the hash from the previous command's output with:
```bash
rnodeconf /dev/ttyACM1 -H
```
Afterwards we shall see that the warning disappears and we should be left with a screen that appears as follows:
)
#### Bring it all together
)
We are now done and have a working RNode 🎊️!
New blog post released!
[Take a look!](https://deavmi.assigned.network/blog/building_my_first_rnode/)
A Nostr-native post will be out later!
Healthy competition! More the better!
# The plan
Firstly let me describe the components for what I want to accomplish today and then also what the goals are.
## Antennas
What I wanted to get done today was to test out two of my new antennas and at a further range than I had tested before with my RNodes.
### Antenna with magnetic base
)
These antennas come with a **3m** lead which means that you can place the radio and antenna at quite the distance apart. This is helpful for cases where you want the antenna to reach some place far away but at the same time you wouldn't be able to run the data cable to the radio (the RNode) at that same length.
We shall see how the above use case was rather handy for me in my setup that I had when using this antenna today.
These are available for purchase [here](https://www.robotics.org.za/communication-wireless-Industrial/antenna-866mhz/YN-868MHZ-5DBI).
### Longer pole antenna
)
These larger antennas fit the same use case of the original stubby antennas that are provided with the LoRa T3-S3 board of mine:
)
They are useful for portable devices that you can whip out and begin using. The antenna is probably as big as one is willing to slog around and have permanently fixed. It's also easy enough to store as it is rather rigid.
It has 3 angles it can be adjusted to on its hinge at `0`, `45` and `90` degrees.
These are available for purchase [here](https://www.robotics.org.za/communication-wireless-Industrial/antenna-866mhz/YN-868MHZ-5DBI).
## Tests
What I wanted to actually get done today was to test out _just how much better_ the new antennas would perform. Now I must state firstly that it wasn't a very scientific test really because I had nothing to compare the antennas too besides my previous stubby antennas (as mentioned earlier) but I never put them through the same test in any case so I feel it is rather unscientific.
Either way, we're going to see how they work in either case.
The approach used will be to send a few messages from my phone to my laptop. In order to test the bi-directionality I need not send something form the laptop to the phone. The reason the latter need not be _explicitly_ tested is because whenever a message is sent a message receipt is sent back (upon arrival at the endpoint) - therefore if I see that I will know that bi-directionality worked.
* Technically when establishing a _link_ it would test bi-directionality as well.
* Therefore back-and-forth communication is tested a few times already just by me sending a message from my phone to my laptop.
### Devices
I will be running tests from my phone running [_Sideband_](https://github.com/markqvist/Sideband) which is an Android-based LXMF client which can communicate over Reticulum:
)
The second device will be running the CLI-based LXMF client called [_nomadnet_](https://github.com/markqvist/NomadNet):
)
I have setup both devices such that the only interface they have available is the RNode-based interface. This will ensure that I only have traffic delivered to my phone via the LoRa radio and not any other interface such as via the Internet.
>Note: The laptop had other interfaces active but none of which my phone would have been reachable via; hence it would always have to find a path over the LoRa-based RNode interface
### Antennas
#### Stationary antenna
The antenna with the magnetic mount would be connected to the one RNode that my laptop was connected to (over USB-C).
The antenna _itself_ was mounted ontop of the patio's shade-roof as it had a metallic base that was magnetic:
)
The above antenna connects to the RNode (for my laptop) via the long $3m$ cable that terminates with an SMA connectors on the board:
)
#### Mobile antenna
As for my mobile device running Sideband, that would be connected to my phone via Bluetooth Low Energy (BLE) but powered via my phone's USB-C port:
)
# Test
## Test 1 - _"Line of sight"_
The first test was to walk to a road parallel to the house and right across from the antenna mounted on the roof. This was chosen as it would provide line-of-sight for the antennas and be a good first test.
)
I began the test by opening up Sideband and then sending some messages:
)
We can see that they were all delivered, this meant we received and acknowledgement from the laptop node!
I think the _last message_ was sent in the park actually (see the next test)
## Test 2 - _"obstructing concrete"_
The next test was sort of a mistake actually. I decided to walk back home through the same path I had come originally; this meant walking via the park.
)
It was also a **very hot** day
)
I was rather surprised here as there are multiple walls of concrete obstructing the stationary antenna and my mobile one. Yet, believe it or not, I was able to get some messages through here:
)
As you can see these messages were **all** delivered.
I found these results rather exciting as it meant it can work with some obstructions; good to know because it means slighter obstructions - perhaps of tree - should definitely still allow for the signal to reach both ways.
)
I do wonder if the waves were bouncing off the walls in some way - who knows? 🤔️
# Conclusion
I was rather happy with the outcome of the first test as it showed everything I had setup was in working order (the new antennas).
Secondly, the surprise of how well it worked with obstructions of the concrete walls was just mind boggling in the good sense of the word.
## Next plans
I have decided that the next place I want to test from is at a tree on top of a hill in the same line-of-sight as where I stood but just at a **much greater distance**.
)
In the mean time, I will plan on taking a trip to an estate that is on a hill and should have line-of-sight to my stationary antenna but at a further distance and accessible with a normal vehicle (instead of an off-road one which would be required for the tree on the hill site).
My blog on building RNode is coming out soon too!
This will include flashing and configuration.
#rnode
New blog post released!
[Take a look!](https://deavmi.assigned.network/blog/rnode_adventure_part1/)
A Nostr-native post will be out later!
Please Zap I am broke (and was born in Africa so I lost the genetic lottery)
New blog post released!
[Take a look!](https://deavmi.assigned.network/blog/rnode_adventure_part1/)
A Nostr-native post will be out later!
Too slow for IPv6 traffic for Babel that needs to be reactive to network changes. Too much clashing I think too.
Not good fit, but I wanted to try it anyways. As for basic IPv6 it can work for small data not going back and forth too much. UDP-esque
Just spent this Sunday proving to myself that, no, LoRa is not _yet_ suitable for large scale IPv6 + Babel.
I refuse to read any technical documents stating the obvious; I will figure out the obvious for myself 🤡
Monero+Talk:+Unmasking+Elon+Musk:+Derrick+Broze+on+Free+Speech+and+Technocracy+|+EPI+336
Episode+webpage:+https://www.monerotalk.live/monerotalk-336
This looks epic!
Are there desktop signers for Nostr?
#asknostr
What's a good Nostr client for long-form Markdown-based posts?
