Software
I had originally planned to include all discussion of software development and usage in this area. In practice, however, it turned out to be both more logical and convenient to deal with relevant, specific software issues when discussing the hardware to which they applied.
This section is therefore dedicated to the discussion of more general software issues, issues that tend to apply across a range of hardware platforms and applications.
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).
Note: 24 Jun 2025 In reality, these software revision details only ever applied to a particular period of time and, in practice, this would always be the case. I do not generally update software just because there's a new release. My updates will generally coincide with the identification of a 'software shortcoming' or the purchase of hardware that requires an update.
In future, I will endeavour to make a note here of the dates applicable to relevant development environment software updates. The dates on any sketches or libraries provided on this website should then help to identify the development environment under which this software is/was known to operate.
24 Jun 2025 Status
| Software | Revision | Date |
|---|---|---|
| macOS | 10.14.5 | 13 May 2019 |
| piOS | 10 | 4 Apr 2022 |
| Arduino IDE | 2.2.1 | 31 Aug 2023 |
| Heltec ESP32 Support | 1.0.0 | 13 May 2024 |
| Heltec CubeCell Support | 1.2.0 (base) | updates to 31 Dec 2024 |
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
I currently use the Arduino IDE to maintain software. In this environment, a set of predefined pin names is included for each supported MCU in its respective pins_arduino.h file. These pin definition files are located in the variants directory within the support software directory hierarchy for the relevant MCU:
ESP8266
| ~/Library/Arduino15/packages/esp8266/hardware/esp8266/<Software Revision Level, e.g. 3.0.2> |
ESP32
| ~/Library/Arduino15/packages/Heltec-esp32/hardware/esp32/<Software Revision Level, e.g. 1.0.0> |
Heltec CubeCell [Plus]
| ~/Documents/Arduino/hardware/CubeCell/CubeCell |
In addition to these default pin definitions, which vary widely between the different MCUs, 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.
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.