IoT Nodes

Includes optional support for:

• LoRa-Pi module
• EEPROM
• Auxiliary power input

A4a LoRa Pro Mini Schematic

Top	Bottom

A4a LoRa Pro Mini PCB

A4a LoRa Pro Mini Eagle CAD Files

[128 KB]

A4a LoRa Pro Mini CAM Files

[147 KB]

Pin Configuration

See notes on pin usage under ESP-12F below.

Includes optional support for:

• LoRa-Pi module
• EEPROM
• 74HC4051 8-Channel analog multiplexer
• Auxiliary power input
• Configurable 'deep sleep' wake-reset

This board will only fit in the larger, 100 x 68 enclosure.

A4a LoRa NodeMCU Schematic

Top	Bottom

A4a LoRa NodeMCU PCB

A4a LoRa NodeMCU Eagle CAD Files

[121 KB]

A4a LoRa NodeMCU CAM Files

[174 KB]

Pin Configuration

There was a bit of fiddling required to come up with a workable configuration for the ESP-12 MCU. Some pins have to be in a specific state during boot, others have reserved functions during the boot cycle or program loading, but are otherwise available, and there is only one analog channel. This article, from Random Nerd Tutorials, provides a good overview of these requirements, and this 'Instructable' provides the basic set-up/configuration instructions for the ESP12.

The first part of the pin assignment issue was resolved by using GPIO0/GPIO2 (which have specific boot and programming functions but are otherwise available) for the I²C interface, which is not used during the boot cycle or when uploading software. This freed up GPIO4 and GPIO5 (the default I²C pins) for general use, without any constraints on their boot time configurations.

The presence of only a single analog pin was resolved by adding an 8-channel multiplexer to the configuration. With GPIO4 and GPIO5 being generally used for specific functions, only one [digital] pin remained, GPIO10, which itself is only available on the ESP-12E/F modules and even then only under specific conditions. As such, with only one channel to specify a mux port, only two mux ports could be used. The 74HC4051 8-channel IC was, nonetheless, the most economical option available. This does at least allow two separate analog 'sensors' to be monitored, e.g. both analog temperature (TMP35/TMP36) and battery level, through the single ADC pin.

Unfortunately, things get even more complicated at this point. The A4a 'Sandwich' interface used for the power/sensor board supports four control channels (A0–A3), but was originally designed to support the Arduino Pro Mini, which has several pins that support both analog and digital I/O. In addition to having only a single analog input channel, the ESP-12 does not have any pins that support both analog and digital I/O.

After allocating pins for the RFM95W SPI and general I²C buses, the ESP‑12E/F has only three remaining 'free' digital pins, in addition to the single analog channel. As such, there are two possible configuration options: three digital channels and one analog channel (without using the mux) or two digital channels (one digital channel being required for mux port select) and two analog channels (using two ports on the mux).

Noting that much of the motivation for developing these boards is for prototyping work, I have included a switch on the board to allow the selection of either of these modes—the switch effectively manually toggles the 'Sandwich' A2 pin between digital and analog inputs. I will provide a more detailed description of how the switch is configured in the assembly instructions for this board, which I will provide just as soon as I get everything tested and working as intended.

If you're figuring, at this point, that it's hardly worth all of this trouble to use the ESP-12 processor in this environment, when there are several other alternatives described herein, you could well be right...

The present PCB includes optional support for:

• LoRa-Pi module
• EEPROM
• 74HC4051 8-Channel analog multiplexer
• Auxiliary power input with [optional] voltage regulator
• ESP-01 programmer interface
• Reset button
• Flash/Prog button
• Configurable 'deep sleep' wake-reset
• LED on GPIO16

A4a LoRa ESP-12 Schematic

Top	Bottom

A4a LoRa ESP-12 PCB

A4a LoRa ESP-12 Eagle CAD Files

[51 KB]

A4a LoRa ESP-12 CAM Files

[218 KB]

Pin Configuration

To help with my prototyping work, I also created a breakout board for the ESP-12 (S/E/F) MCU. The board provides direct breakout of all 22 ESP-12F pins, with support for the following options:

• ESP01 serial interface module
• Reset button
• Flash/Prog button
• Wake from deep sleep interrupt switch
• Pull-up resistors on EN, RST, GPIO0, GPIO2
• Pull-down resistor on IO15

ESP-12 Breakout Board Schematic

Top	Bottom

ESP-12 Breakout Board

After I'd done all of this, I discovered these:

ESP-12 Programmer

available for both the ESP-12 and ESP32 processors. I now have a couple to play with and, while they're more expensive than a simple breakout board, there's no soldering required (the processor module just clips into the board—very neat!). This looks like a much more convenient way to test configurations.

Update: Having now had an opportunity to use these programmers, they're not ideal if one needs to exploit the full potential of the processor. Their hardware configuration means that not all pin configuration options are available.

In the present case, these programmers inhibit the use of GPIO0/GPIO2 for the I²C interface. Scripts seem to load OK, but something in the programmer's hardware configuration interferes with the use of at least one of these pins. Either way, scripts will not execute as intended when running on a processor within one of these programmers if the I²C interface is configured on GPIO0/GPIO2, regardless of which pin is configured as SCL or SDA.

As with the ESP12 processor, the ESP32 requires certain pins to be configured or used in certain ways at certain times. Much of this is hidden from the casual user and ESP32 modules, like the ESP32-WROOM-32 used here, only break out a select subset of pins for general use. There are, however, more pins available on the ESP32 (38 on the ESP32-WROOM-32 vs 22 on the ESP-12F, although in each case some pins are reserved for specific 'system' functions) and ESP32 pin usage is generally much more flexible. The ESP32 also includes an on-board multiplexer that allows most pins to be configured, through software, for any function, including analog or digital I/O, supported by the processor.

This article, once again from Random Nerd Tutorials, provides a good overview of the ESP32 processor and associated pin usage.

The present PCB includes optional support for:

• LoRa-Pi module
• [External] EEPROM
• Auxiliary power input with [optional] voltage regulator
• USB-TTL/UART Interface
• Reset button
• Flash/Prog button

A4a LoRa ESP32 Schematic

Top	Bottom

A4a LoRa ESP32 PCB

A4a LoRa ESP32 Eagle CAD Files

[47 KB]

A4a LoRa ESP32 CAM Files

[198 KB]

Pin Configuration

To help with my prototyping work, I also created a breakout board for the ESP32-WROOM-32 MCU. The board provides direct breakout of all 38 ESP32-WROOM-32 pins, with support for the following options:

• USB-TTL/UART Interface
• Reset button
• Flash/Prog Button
• Pull-up resistor on EN
• Switchable LED on IO2

ESP32 Breakout Board Schematic

Top	Bottom

ESP32 Breakout Board

For reasons I've not been able to determine, I was unable to flash the ESP32 using an ESP-01 USB to TTL adaptor (which worked fine with the ESP-12) but I had no trouble with other USB-TTL/UART modules, like this one (hence the 6-pin single row header for the USB adaptor).

After I'd done all of this, I discovered these:

ESP32 Programmer

available for both the ESP-12 and ESP32 processors. I now have a couple to play with and, while they're more expensive than a simple breakout board, there's no soldering required (the processor module just clips into the board—very neat!). This looks like a much more convenient way to test configurations. Time will tell...

Includes optional support for:

• LoRa-Pi module
• EEPROM
• Auxiliary 3.3V power input

At this point, the STM32 is a total unknown. I have a couple of modules, but I've never even loaded a sketch onto one yet, so for the time being this is little more than a thought bubble.

As a result of its physical dimensions (the board is longer and narrower than any of the others), the STM32 requires an auxiliary adaptor board to provide the ALF4all Sandwich interface and will only fit in the larger, 100 x 68 enclosure.

A4a LoRa STM32 Schematic

Top	Bottom

LoRa STM32 'Blue Pill' + A4a Adaptor PCBs

Pin Configuration

I did originally design an A4a processor PCB for the WiFi LoRa 32 board but, following my initial experience with the Wireless Stick Lite board (see below), I went no further. Like the other Heltec boards, the WiFi LoRa 32 board includes an on-board TP4054 charging module and, while the WiFi LoRa 32 board doesn't include a specific pin for connection to a solar panel, a solar panel can be configured as a charging source. As such, the BCS A4a base boards offer little benefit when using this and the other Heltec modules, making the development of specific battery/base boards to support the individual Heltec processor boards a more logical approach.

While I have generally tended to favour the CubeCell boards in the development of Node (as distinct from Gateway) applications to date, the Heltec WiFi LoRa 32 and Wireless Stick [Lite] development boards retain one particular advantage over the CubeCell boards: they support WiFi and bluetooth communications. As such, these boards, and the Raspberry Pi, are preferred for applications like the Gateway, that require both LoRa and WiFi/LAN communications.

The Gateway application, however, effectively needs to support the potential for continuous operation and so is not suited to support by battery alone. As such, battery power in such situations is provided more as a backup, to guarantee continued operation through power failure. The primary objective of the WiFi LoRa 32 (10068-BHWL) baseboard was therefore to provide battery backup for a primary power source in addition to the provision of a convenient mounting platform within an appropriate enclosure.

An important factor that was considered in the design of the original 10068-BHWL base board was the fact that the pin configurations of the WiFi LoRa 32 V1 & V2 boards are slightly different. The difference is mainly in the use of the various power pins but, in the present case, also impacts GPIO21. The V2 board includes a Vext pin, to control power supply to attached peripherals, and the state of this pin is controlled via GPIO21, which was previously used in the I²C interface.

This situation has been complicated even further with the release of the WiFi LoRa 32 V3 board. This board uses a different ESP32 processor (ESP32-S3FN8) and LoRa node IC (SX1262)—the ESP32-D0WDQ6 processor and SX1267 LoRa node IC had been used on earlier board revisions—and an almost entirely different pin configuration. This was way too much to attempt to accommodate on a single base board, so a new base board (10068-BHWL3) has been designed to specifically support the V3 board.

The V2 and V3 boards include on-board circuitry to monitor the battery supply voltage. There are actually two revisions of the V2 board—V2 and V2.1, although both are marked "V2" and appear identical to the casual observer—and each uses a different pin for this function. This feature was not included on the V1 board and the 10068-BHWL board includes its own battery voltage measurement circuitry. The original V2 board used GPIO13 to measure battery voltage but this apparently caused a conflict with the processor's WiFi configuration—GPIO13 used the second analog-to-digital converter, ADC2, which was not available when WiFi was configured. To address this problem, Heltec modified the V2.1 board design to use GPIO37 (an 'input only' pin) to read the battery voltage, without identifying this fact on the board hardware in any way, so it is not a simple matter to determine which configuration is applicable on any particular V2 board. This issue is discussed in detail here.

In the earlier revisions fo the 10068-BHWL board, I attempted to accommodate the differences between the V1 and V2 boards but, given that production of the V1 boards was discontinued some years ago, and even the V2 boards have now been superseded, the current revision of the 10068-BHWL board is designed for the WiFi LoRa 32 V2.1 board. It will support the earlier revisions, but possibly with limitations.

In relation to the battery monitoring circuit included on the 10068-BHWL board, a 33kΩ resistor, rather than the 27kΩ resistor used on other boards, is configured in the voltage divider to better accommodate the performance of the ESP32 ADC. While it is a 12-bit ADC (0..4095) with a voltage range of 0–3.3V, the performance of the ADC is not linear towards the ends of this range. The current voltage divider configuration thus maps the possible Li-Ion battery voltage range of 0–4.2V to a slightly reduced ADC input voltage of 0–3.16V. The difference is accounted for appropriately in software. Regardless, given that the current revisions of the WiFi LoRa 32 board include their own on-board circuitry for battery management, the 10068-BHWL battery monitoring circuitry is probably redundant and need not be configured.

Top	Bottom

10068-BHWL PCB

See here for CAD and CAM files.

Pin Configuration

Note that, while the above table identifies connections to various sensors, these are generally just labels. The relevant connectors simply provide access to the associated MCU pins and can be configured as required by any given application.

Heltec WiFi LoRa 32 V3

The 100x68 BHWL3 board is much the same as BHWL board, the MCU pin connections have simply been changed as required to accommodate the new processor. There is currently [Feb 2023] very little guidance on how the newly available pins can be used, so the details below are only preliminary—I am yet to verify that the new pin connections function as intended.

Top	Bottom

10068-BHWL3 PCB

See here for CAD and CAM files.

Pin Configuration

I originally purchased a couple of Wireless Stick Lite modules as a more economical alternative to the Heltec WiFi LoRa 32 modules I had been using, where I did not need a display. At the time I created the present A4a processor board, I did not realise that the Wireless Stick boards included their own on-board TP4054 battery charging module. It was nonetheless noted that, to use the on-board power management capabilities (all I knew about at the time was the on-board voltage regulator), the board had to be powered through its [JST SH1.25] battery connector. As such, this is the default configuration on the present A4a processor board and requires the battery be directly connected to the Wireless Stick Lite module.

This board includes optional support for:

• [3.3V] power input via Vcc pin (configured via solder jumper)
• EEPROM

A4a Wireless Stick Lite Schematic

Top	Bottom

A4a Wireless Stick Lite PCB

Pin Configuration

The on-board TP4054 charging circuit, however, obviates the need for the battery management circuitry included on my [BCS-A4a] solar power base boards. On this basis, I may have to rethink my approach to the use of Heltec boards in my current environment. The whole idea of this project was to create a hardware environment where I could swap different processors in and out to see how they compared.

Given the integrated nature of the Heltec boards that I'm working with, I have had to modify my approach to assessing their suitability for individual applications and look at using specific, custom boards for the individual Heltec processor modules. To date, however, I have not created such a board for the Wireless Stick Lite.

While I have generally tended to favour the CubeCell boards in the development of Node (as distinct from Gateway) applications to date, the Heltec WiFi LoRa 32 (V1 & V2) and Wireless Stick [Lite] development boards do, however, retain one particular advantage over the CubeCell boards: they support WiFi and bluetooth communications.

Heltec Wireless Stick Lite V3

Like the WiFi LoRa 32 boards, the Wireless Stick Lite V3 Dev-Board is not pin compatible with the earlier V1 Dev-Board (I am not aware of there ever having been a V2 in the Wireless Stick series) but I am in the process of designing a specific 85x58 base board for the V3 Dev-Board, similar to the BHWL3 board, for use with applications that do not require an OLED display. There is currently [Feb 2023] very little guidance on how the newly available pins can be used so, again, the details below are only preliminary—I am yet to test this board or even verify that the new pin connections are valid.

Top	Bottom

8558-BHWSL PCB

See here for CAD and CAM files.

Pin Configuration

The CubeCell includes its own onboard power management circuitry that supports Li-Ion and LiPo battery technology and direct solar panel input—when both are connected directly to the CubeCell module, the solar panel is used to charge the battery. This is the default configuration on the adaptor board below and requires that the CubeCell module be powered via a direct connection from the battery to the CubeCell (JST SH1.25 connector) and that the solar panel, if configured, be connected directly to the CubeCell ALF4all 'Sandwich' processor board (JST PH2.0 connector).

There have been claims that LiFePO₄ battery technology is also supported, but these have not been verified—it's not clear how this would be possible, given that the charging regime for LiFePO₄ cells differs somewhat from that used for Li-Ion and LiPo cells.

Includes optional support for:

• EEPROM
• Direct power input (configured via solder jumper)
• Solar panel input

Top	Bottom

A4a CubeCell PCB

Pin Configuration

As I worked through the testing cycle on this board, however, as with the Heltec Wireless Stick, it became apparent that this is not really a very appropriate way to be using the CubeCell, as the module itself includes much of the functionality provided by the [BCS-A4a] solar power base boards. In particular, and quite logically, effective power management through the on-board power management system not only requires direct connection of the battery and solar panel but also the supply of power to any connected sensors.

On this basis, I abandoned further development of this board and have instead designed a base board (initially only for the 85x58 enclosure) specifically for the CubeCell that provides sensor connectivity that is compatible with my current prototyping environment. The current version also includes specific connectors for anemometer and rain gauge sensors.

Includes optional support for:

• Power switch
• Direct power input (configured via solder jumper)
• Solar panel input
• Circuit current monitoring
• 24V Boost converter
• Weather station (anemometer/rain gauge) sensor input
• EEPROM

Top	Bottom

8558-BHC PCB

See here for CAD and CAM files.

Pin Configuration

While it uses the ASR6502, rather than ASR6501, processor, the CubeCell Dev-Board V2 is pin compatible with the V1 board and as such is generally interchangeable with the V1 board in the present environment.

The CubeCell Plus board has become the basis for the two specific applications that are currently active. The main feature of interest over the CubCell, which was originally based on the ASR6501 MCU, is that the Plus, which is based on the ASR6502 MCU, includes three ADC channels—this limitation has been alleviated somewhat on the CubeCell V2 Dev-Board, which is now based on the same ASR6502 MCU, although the CubeCell Dev-Board still only provides access to two of the three ADCs. The Plus also includes an inbuilt OLED display, although I hadn't ever anticipated much use for a display on a device that would depend on battery power. Nonetheless, it's simple enough to deactivate the display during 'normal' operations and it has proven useful for 'in field' status checking.

As with the CubeCell, I have developed a board (but in this case, for the 100x68 enclosure) specifically for the CubeCell Plus that provides sensor connectivity that is compatible with my current prototyping environment. Again, as with the CubeCell board, the current version also includes specific connectors for anemometer and rain gauge sensors.

Includes optional support for:

• Power switch
• Direct power input (configured via solder jumper)
• Solar panel input
• Battery voltage/current monitoring
• DS18B20 temperature sensor
• 24V Boost converter
• Weather station (anemometer/rain gauge/I²C/Aux) sensor input
• EEPROM

Top	Bottom

10068-BHCP PCB

See here for CAD and CAM files.

Pin Configuration

As with the CubeCell board, this board can be configured with a (100x68) 'weather station' board that provides 'native' (RJ11) connectivity to weather station sensors, with line protection circuitry, as illustrated below.

Top	Bottom

10068-WS PCB

---