Reset helper for NodeMCU ESP8266 modules

A common scheme for Lua scripted NodeMCU modules with automatically start the script init.lua is to incorporate some logic to test the condition of a GPIO pin to determine whether to boot to the application or drop to the lua prompt for programming etc. In fact the scheme can be elaborated to provide a simple multi level selection based on the time the input condition is applied.

The obvious pin to use is the pin that commonly has a “BOOT” or “FLASH” button on it, GPIO0 or D3. It is used to activate the ESP8266 boot loader if it is low during boot, so it must be left high at boot to allow the lua interpreter to run, but it can be pulled low shortly after boot up and tested from init.lua.

An example init script follows.

print("\n\nHold Pin00 low for 1s t0 stop boot.")
print("\n\nHold Pin00 low for 3s for config mode.")
tmr.delay(1000000)
if gpio.read(3) == 0 then
  print("Release to stop boot...")
  tmr.delay(1000000)
  if gpio.read(3) == 0 then
    print("Release now (wifi cfg)...")
    print("Starting wifi config mode...")
    dofile("wifi_setup.lua")
    return
  else
    print("...boot stopped")
    return
    end
  end
print("Starting app.lua")
dofile("app.lua")

 

Above is a pic of the helper. The DIP switch allows selection of the BOOT pulse in 1s increments. It has four connections, ground, Vdd, BootOut, and Reset (optional). The button near the DIP switch resets the helper which in turn will apply a 10ms reset pulse to the Reset line. Continue reading Reset helper for NodeMCU ESP8266 modules

ESP8266 IoT DHT22 temperature and humidity – evolution 2

This article documents a first project with the Espressif ESP8266 in its second evolution.

The objective is a module that will take periodic temperature and humidity measurements and publish them to an MQTT message broker.

This inital implementation is very basic, it is largely configured in code, though it does use DHCP. Later extensions might include a web interface for configuration of WLAN parameters etc, but for the moment the emphasis is assessment of reliability given some reports on the ‘net.

Evolution 2

The original design embedded key configuration variables in the main source code for simplicity in getting the code working.

Evolution 2 separates configuration variables from code, and provides a web interface for configuring the most common variables. The screenshot above shows the configuration screen including the use of a datalist on the SSID input field.

Hardware

A module was purchased with on board CP210x USB to serial chip. The only other component needed was the DHT22 digital temperature and humidity sensor.

NodeMCU was chosen for the ESP2866 firmware because of the inbuilt support for ‘interesting things’, including the DHT22.

Above is a breadboard of the system for development. The board had a 4MB (32Mb) flash chip on it. Continue reading ESP8266 IoT DHT22 temperature and humidity – evolution 2

DHT22 (AM2302) input for the generic heating / cooling controller

The generic heating / cooling controller (hcctl) is a flexible bang-bang thermostat controller based on an ATTiny25.

The project has been expanded to accept the Aosong DHT22 temperature and humidity sensor. The DHT22 produces a digital output (signed tenths of a degree) has a range of -40° to 80°, accuracy of about 0.5°, and 0-99.9% RH and costs a few dollars. hcctl can be configured for either temperature or humidity sensing (not both simultaneously).

Above is a development prototype with the DHT22 being heated by a small incandescent dial lamp to test function.

Continue reading DHT22 (AM2302) input for the generic heating / cooling controller

NodeMCU devkit V1 deep sleep

Low cost implementations of the NodeMCU devkit V1.0 abound on eBay, and are featured in lots of projects.

Deep sleep mode is used in a lot of projects, the MCU is but into sleep mode and it requires circuitry so that the  from the /WAKE pin (D0, GIO16) can pull the /RST pin to wake the processor up.

The problem

The common schematics as above simply wire /WAKE pin (D0, GIO16) to /RST (yellow wire), but this disrupts operation of the reset circuit, which degrades development productivity. Continue reading NodeMCU devkit V1 deep sleep

ESP8266 IoT DHT22 temperature and humidity

This article documents a first project with the Espressif ESP8266.

The objective is a module that will take periodic temperature and humidity measurements and publish them to an MQTT message broker.

This inital implementation is very basic, it is largely configured in code, though it does use DHCP. Later extensions might include a web interface for configuration of WLAN parameters etc, but for the moment the emphasis is assessment of reliability given some reports on the ‘net.

Hardware

A module was purchased with on board CP210x USB to serial chip. The only other component needed was the DHT22 digital temperature and humidity sensor.

NodeMCU was chosen for the ESP2866 firmware because of the inbuilt support for ‘interesting things’, including the DHT22.

Above is a breadboard of the system for development. Continue reading ESP8266 IoT DHT22 temperature and humidity

EmonTx3 v3.4 ‘wired’ implementation

Introduction

EmonTx3 is a measurement node for an energy measurement system. It has measurement inputs for 4 current transformers, AC voltage, 6 DS1820B temperature sensors and a meter pulse counting sensor.

The standard configuration uses a HopeRF RFM69CW radio transceiver to emonhub running on some host.

This article describes modifications to the system to use a wired serial connection to the emonhub host.

Above is the emonTx3 board.

The approach taken is a minimal change to existing firmware and software, no change to existing hardware, and inexpensive components to extend the connection.

Outline of the solution

The existing firmware writes a debug stream to the connector used for firmware upgrade. It is a different format to that used for the radio link, and there are good reasons for that, but it means writing an interface handler for emonhub to parse the debug stream.

emonTx V3.4 Discrete Sampling V2.80
OpenEnergyMonitor.org

No EEPROM config
RFM69CW Node: 8 Freq: 433Mhz Group: 210

ct1:-51,ct2:0,ct3:0,ct4:0,vrms:23910,pulse:0,t0:223
ct1:-71,ct2:0,ct3:0,ct4:0,vrms:23924,pulse:0,t0:223
ct1:-6,ct2:0,ct3:0,ct4:0,vrms:23921,pulse:0,t0:223

The solution involves some hardware to interface the emonTx3 to the wire line, and a similar interface at the other end to the host running emonhub.

Hardware

Above is the debug stream from the modified firmware.
Above is an adapter (~$3) from the TTL levels of the UART port to RS485. The port is currently run at 115200bps, and that can be carried 800m with good noise immunity on good copper using RS485.

USB-485-10

Above is the host end adapter.

Firmware changes

The firmware was changed to repurpose the output that may be used for switching power to the DS19B20 sensors, it is now used primarily as an RTS signal to the RS485 adapter to reduce current consumption when there is no traffic. In fact, the RTS signal has been asserted also at times when the DS18B20 sensors are read and it could also be used for its original purpose without conflict.

Host changes

Assigning a consistent name to the RS485 adapter

A problem with USB serial adapters is that they may acquire different device names depending on the order in which they are started.

This is solved in this solution by use of FTDI adapters which have a serial number that uniquely identifies the adapter, and setting udev rules to assign a consistent symbolic link to the device. It is this symbolic link that is used in emonhub.conf

The link is achieved by adding the file /etc/udev/rules.d/75-RS485.rules with the contents below (the contents must match the actual adapter).

#Assign fixed symlink to RS485 adapter for emonttx

SUBSYSTEM=="tty", ENV{ID_SERIAL}=="FTDI_FT232R_USB_UART_A9WRVDPD",SYMLINK+="ttyRS485-0"

The udevadm command will provide the information needed.

root@emonpi(rw):log# udevadm info -n /dev/ttyUSB0
P: /devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
S: serial/by-id/usb-FTDI_FT232R_USB_UART_A9WRVDPD-if00-port0
S: serial/by-path/platform-20980000.usb-usb-0:1.2:1.0-port0
S: ttyRS485-0
E: DEVLINKS=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9WRVDPD-if00-port0 /dev/serial/by-path/platform-20980000.usb-usb-0:1.2:1.0-port0 /dev/ttyRS485-0
E: DEVNAME=/dev/ttyUSB0
E: DEVPATH=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0
E: ID_BUS=usb
E: ID_MODEL=FT232R_USB_UART
E: ID_MODEL_ENC=FT232R\x20USB\x20UART
E: ID_MODEL_FROM_DATABASE=FT232 USB-Serial (UART) IC
E: ID_MODEL_ID=6001
E: ID_PATH=platform-20980000.usb-usb-0:1.2:1.0
E: ID_PATH_TAG=platform-20980000_usb-usb-0_1_2_1_0
E: ID_REVISION=0600
E: ID_SERIAL=FTDI_FT232R_USB_UART_A9WRVDPD
E: ID_SERIAL_SHORT=A9WRVDPD
E: ID_TYPE=generic
E: ID_USB_DRIVER=ftdi_sio
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_VENDOR_ID=0403
E: MAJOR=188
E: MINOR=0
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=8089809829

Interfacer module to parse the debug stream

An additional interfacer module was written to parse the debug stream, and it was hooked to the main module.

The interfacer is configured in emonhub and port layout copied in from source.

(the contents must match the actual adapter).

#Assign fixed symlink to RS485 adapter for emonttx

SUBSYSTEM=="tty", ENV{DEVLINKS}=="*usb-FTDI_FT232R_USB_UART_A9WRVDPD*",SYMLINK+="ttyRS485-0"

Code source

Code source is available the original git emonhub repo, and in the following git repository forked from the official repo:

Test

The wired configuration is under test with emonhub installed on a Ubuntu server, and about 40m of cat5e cabling from emonTx3 to host. No issues have arisen.

References / links

EmonTx_V3.4

DS18B20 input for the generic heating / cooling controller

The generic heating / cooling controller (hcctl) is a flexible bang-bang thermostat controller based on an ATTiny25.

The project has been expanded to accept a Dallas / Maxim DS18B20 1-Wire temperature sensor. The DS18B20 produces a digital output (signed sixteenths of a degree) has a range of -85° to 125°, accuracy of about 0.5°, and costs a dollar for bare chips, a few dollars for an encapsulated probe.

Above is a development prototype with the DS18B20 being heated by a small incandescent dial lamp to test function.

Continue reading DS18B20 input for the generic heating / cooling controller

Modifications for Jasic 200A TIG welder and pedal

In about 2009 I purchased a Uni-mig Jasic 200A TIG welder (though these are sold under many brands).

The welder came with unusual 2 and 5 pin connectors for the torch trigger switch and an optional pedal. The optional pedal was quoted at around $500, probably partly as the seller had locked the market up with the unusual connectors. (I note that the XS12K2P etc connectors are now available on Aliexpress.)

There is no standardisation of these connectors, but the pedal internals are pretty common. A quite common configuration is a 2 pin Foster (microphone) connector for the trigger switch and 3 pin Foster (microphone) connector for the current pot.

A further usability issue is that the pedal varies current from 5 to 200A, it is not possible to set the maximum current when the pedal is fully depressed. Continue reading Modifications for Jasic 200A TIG welder and pedal

BLHeli 14.8 damped light and active freewheeling

Aficionados of BLHeli call out the benefits of “damped light” and “active freewheeling”, terms coined by BLHeli’s author.

Since these are terms invented by BLHeli, so you might wonder whether they are truly innovative or just marketing hype for existing techniques.

Lets go to the BLHeli manual for an explanation.

Pwm damped light mode adds loss to the motor for faster retardation. Damped light mode always uses high pwm frequency. In damped light mode, two motor terminals are shorted when pwm is off

Taking the last statement first, in fact, what happens that as that during the OFF phase of the PWM drive, the high side FETs at both ends of the winding are turned ON. One FET is on for the whole phase, and the other one switches on a short time after its corresponding low side FET turns off. The short time is to allow the low side FET to cease conducting, otherwise both high and low side FETs would conduct at the same time, a current from battery +ve to -ve via the two FETs. There is a corresponding pause at the end of the PWM phase. The time delays allowed depend on the driver circuitry and FET performance, they are specified in the firmware  for a specific and don’t necessarily apply to a pin compatible ESC.

This technique is known in the wider community as COMPLEMENTARY PWM, a very standard technique. Continue reading BLHeli 14.8 damped light and active freewheeling

Fan controlled by humidity sensor – pre implementation data gathering

This article documents measurements of temperature and relative humidity (RH) over 10 days prior to implementing the fan solution to provide a baseline for designing the Fan controlled by humidity sensor.

A RC-4HC datalogger was used to collect temperature and RH measurements over 10 days which included a range of late winter weather, some rain, some fine clear days. The logger was located at 1.5m above floor level in the shed in a relatively clear spot in the middle of the area..

Screenshot - 22_08_16 , 15_53_17

Above is a chart of temperature and RH. The daily RH peaks are typically between 08:00 and 09:30, and pretty much coincide with the minimum observed temperature. There is clearly a lag from outside temperature which would tend to be minimum a few hours earlier, and a lower minimum (there were plenty of frosty days in the sample set). Continue reading Fan controlled by humidity sensor – pre implementation data gathering