M0RVB ⁽²⁹⁴⁾

Both my 868MHz and 433MHz nodes are being odd today. I had been looking into the data that arrives when '--noproto' is sent to the node and, typically there is a fairly constant stream of data. But today, despite both being power cycled there is no data at all. Odd, because when I ask the 868Mhz node for its nodelist it is being updated. Maybe it's something in the new firmware but for now I've been fiddling enough and it's time to take a step back. I have not had any successful traceroutes today, I responded to a couple of requests and got no reply. It's made worse by the fact that, having moved the nodes in the loft they are now out of BLE range. Both are connected to a Raspberry Pi via USB so I can access the nodes that way but for client use I use my mobile node assuming that the node in the loft will relay everything - maybe not. And for 433MHz I only have the one node anyway. Mind you, it is raining and I suspect that is making a fairly decent shield for 868MHz, and I have yet to see any activity…

Some time ago I wanted a logging program that would do things my way. Although there is absolutely nothing wrong with any of the various offerings they generally try to be everything for everyone and none of them really sat well with me. So I wrote my own in PHP (learning Python is high on my list of things to do, along with Mandarin, Morse, cooking...) which uses the QRZ.com logbook as the backend. Ok then, really I wrote a series of various scripts in PHP that make it all work. The advantage is it does just what I need and nothing more and can easily be modified to add functionality. The downside is I never was a coder (well, ok, I have a certification in COBOL from the 1970's!) and it is not going anywhere other than my own server. So you can't have it... The way I tend to log stuff is via wsjt-x or other software that logs to a local file. I then have a script that takes the ADIF data and populates QRZ.com on a QSO-by-QSO basis. Somehow having to actually do something after each QSO feels like I am actually engaging in the process.

After a lot of fiddling about writing code to look at mesh traffic I am on other projects (like, sorting the house out!)... so here is my current state of play... I have an 868MHz node in the loft directly connected to a collinear which is hanging off the rafters. This is powered by USB from one of the Pi systems in the shack. It is set to work over wifi, not BLE as it's just too far away. Its position coordinates are fixed. But I do not need to access it directly, see below. The useful thing here is I have installed the Python CLI on that Pi and can access the node's data stream directly. There is one 868MHz node in the shack with the supplied stubby little antenna. There is no way this can see any other nodes in the local area (I've tried) but can access the node in the loft. So this one has hops set to 4 as it uses one just to get upstairs. This node is set to read position data from the iPhone and can thus go mobile. Well, ok, it could go mobile anyway but at least this way it…

This Meshtastic business seems often very hit and miss. Locally there is an expectation that it will always work and if you can hit one node one day you should always be able to. Or at least that's what I glean from comments. Of course, just a few mW at 868MHz is not destined for long distance comms, and yet I can get 24 miles provided the path is line of sight. Not bad. But I can't manage 1.3km to my nearest neighbour who can get out all over the place. There is a hill to consider there, plus many houses, so not surprising really. Oh yes, and there is the small matter of the antenna still being in the loft so it has to punch through wood and concrete, often wet at that, before it gets to air. For now, at least locally traffic is mostly messages asking if one can be heard. There is a series side of course. Nodes can be placed in advantageous positions, run off battery and solar recharged, and left as area repeaters (or routers in Meshtastic parlance) forming a mesh with other similarly advantageously placed nodes. We have this locally to some extent.

I've been rationalising hardware, in particular as the PoE HAT on the Pi running the GB7RVB packet mailbox was noticeably noisy and needs replacing. I had originally moved the packet mailbox off of my AMPRnet router Pi as I needed to install a VPN and the networking was becoming a bit too complex for my liking. In the end I had no use for the VPN, so GB7RVB has gone back, removing one Pi. Linbpq went across just fine - there is an apt for it (https://wiki.oarc.uk/packet:linbpq-apt-installation) so installation is easy. Just install and copy the config across and the files under /opt/oarc/bpq (there are neater ways but this sledgehammer method works). With the node running I could access via the web interface as expected, but then the axudp route disappeared. Then I realised that our broadband router had a NAT rule for the UDP port needed for axudp and that was still pushing it to the now switched off Pi. And I'm sure I've forgotten this same thing before! So now I have a note as a reminder, assuming I bother to check the note... Now having removed one Pi with a noisy fan the NTP server Pi is…