Software

I will ultimately bring all of the details of the various software elements used in the Nodes described elsewhere on this site under this section. For the time being, given that these are essentially just project notes, I will simply begin with some of the specific areas of software development that have come in for attention during this project. Most of these will probably find their way to separate pages, accessible through the left-side menu, as the documentation task proceeds.

Arduino IDE

Development Environment

Current sketches have been developed using the Arduino IDE (2.0.4) running under macOS (10.14.5). Heltec boards are supported by board-specific Heltec support software (0.0.7).

Software Environment

I will ultimately provide a more complete description of my specific software environment here. The software that drives the various Nodes in my network is generally based on common parameters and functions associated with the LoRa configuration for the various platforms in use, specific, individual Node parameters defined within the nodeHandler library, some of which are stored in EEPROM and accessed through the eepromHandler library, and an underlying packet structure defined through the packetHandler library. In the mean time, the individual elements are generally described in the various pages accessible through the menu options at left.

Pin Definitions

A set of common pin definitions was developed to help with the portability of code segments for different processor platforms. As well as identifiers for the common interface standards (I2C & SPI), definitions are included for the other pins used in the A4a 'Sandwich' and sensor interfaces and those used for non-standard sensor connectivity, as illustrated below.

Langlo Pin Identifiers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// I2C
#define SCL[Pin to use for SCL]
#define SDA[Pin to use for SDA]

// ALF4all
#define A4a_A0[Pin to use for A4a_A0]
#define A4a_A1[Pin to use for A4a_A0]
#define A4a_A2[Pin to use for A4a_A0]
#define A4a_A3[Pin to use for A4a_A0]

// Wind/Rain
#define rainCollectorPin[Pin to use for rain collector interrupt]
#define windDirectionPin[Pin to use for wind direction]
#define windSpeedPin[Pin to use for wind speed interrupt]

// GPS
#define gpsTx[Pin to use for GPS data receive]
#define gpsRx[Pin to use for GPS data transmit]

// AJ-SR04M Ultrasonic Distance Sensor
#define ultraTrig[Pin to use for ultrasonic sensor trigger transmit]
#define ultraEcho[Pin to use for ultrasonic sensor echo receipt]

// Sensor Interface
#define sensorWake[Pin to use for A4a sensor interface wake function]
#define sensorInterrupt[Pin to use for A4a sensor interface interrupt]

#define sphygOUT[Pin to use for sphygmomanometer OUT connection]
#define sphygSCK[Pin to use for sphygmomanometer SCK connection]

The above definitions are included in the pin definition files created for each of the processors that have been used in the present project. Descriptions of the respective definition files are included in the sections describing the software for the individual processor families, which can be accessed through the left side menu.

MQTT Server

At this point, I have not provided any details of the configuration of the MQTT server. I currently use a Mac (macOS 10.14.6) with a standard installation of Node-Red and Mosquitto. My ultimate intention is to use a LoRa/WiFi-enabled Raspberry Pi to host the gateway and server functions.

Update: 12 Jun 2022 Having now completed 'proof-of-concept' testing on the Raspberry Pi configuration, and having migrated the core 'Node' code to a software library within the Arduino IDE, providing a consistent environment for all Nodes, it is apparent that separating the gateway function from the Node [hardware] environment might not be such a good idea. The Node software library provides a single location for the definition of packet structures and associated variables. As such, it might prove more convenient, from a maintenance perspective, to keep these functions entirely within the Node software environment and just let the Raspberry Pi manage the MQTT broker and subsequent data processing tasks. This would limit the common elements that need to be maintained between the two to just the MQTT topics.

This would be tidier from a software perspective, but perhaps not so from a hardware perspective, as we then lose the convenience of having a single piece of hardware supporting both the gateway and data processing functions...

Either way, it turns out that configuring Mosquitto, the MQTT broker software, on the Raspberry Pi platform is a trivial task and Node Red is included as one of the standard software packages in the current [Buster (legacy) or Bullseye] Raspberry Pi OS release.

Automatic Configuration

One of my goals from the outset was to create a platform that was, to the extent both possible and practical, self-configuring. The ultimate idea was, for example, that the common configuration parameters would be defined in one or more universal configuration files, accessed when compiling Node code modules, and that new Nodes could be added 'on the fly', that their individual hardware configurations could be auto-detected by the Node software, and the existence of any [new] Node could be automatically (i.e. without having to recompile the Gateway software) registered with the [MQTT] Gateway Node.

I have made some progress on the former goal, but the latter remains a work in progress. Obviously automatic Node registration is a part of the LoRaWAN protocol, but I was interested in exploring the possibility that I could achieve this goal, in my specific environment, using some more basic protocol. This was as much an academic exercise as anything else, and LoRaWAN always potentially remains the most practical option.

Node Identification

Valid Nodes are currently defined (statically) within the NodeHandler library, which is currently a component of the PacketHandler library 'package'.

Individual Nodes are identified by a MAC address that is derived from either the processor Ethernet or WiFi MAC address or chip ID. In the present environment, I use an 8 byte MAC address—0xDC followed by the last 6 hexadecimal digits of the Node's Ethernet or WiFi address or its chip ID. This does not result in a MAC address that is guaranteed to be unique, but for such a small network as mine, it has proven to be adequate for the time being.

Sensor Detection

Automatic sensor detection is no big deal, it just needs to be added to the various Node code modules. I'll include the details as I get around to adding this feature.

03-12-2024