ESP-12 bootloader modes and GPIO state at startup

Since I encountered some initial difficulties in programming the ESP-12 version of the ESP8266 module using the Arduino IDE, let me here summarise some findings based on information from [1,2,3].

esp12-pinout

The ESP-12 module exposes 11 GPIOs. Three of them are especially relevant, as they determine the bootloader mode at startup or following reset.

                                  | GPIO 0 | GPIO 2 | GPIO 15
----------------------------------|--------|--------|---------
Flash Startup (Normal)            |   1    |   1    |   0
UART Download Mode (Programming)  |   0    |   1    |   0
SD-Card Boot                      |   0    |   0    |   1

Furthermore, CHPD should be pulled up and RESET should be pulled up or should be floating. If you connect RESET to ground, the module resets.

I have not yet figured out what the SD-Card boot means, so in my applications GPIO 2 should always be pulled up and GPIO 15 should always be pulled down. I am using 10k resistors, but smaller values (e.g. 3.3k) should also work.

To facilitate development, I connected two push button switches to the GPIO 0 and RESET pins, shorting them to ground when pressed. When the buttons are not pressed, they are both pulled up to 3.3V using a 10k resistor.

This allows me to do the following two-finger-action to restart in programming mode and allow the Arduino IDE to upload a new firmware:
– press reset button
– press programming button
– release reset button
– release programming button

References

[1] https://zoetrope.io/tech-blog/esp8266-bootloader-modes-and-gpio-state-startup
[2] http://www.instructables.com/id/Getting-Started-with-the-ESP8266-ESP-12/
[3] http://www.instructables.com/id/ESP8266-Using-GPIO0-GPIO2-as-inputs/

TTN/LoRa using Dorji DRF1272F module

Teensy connected to DRF1272f

Sofar I have been experimenting with LoRa and TTN using a Multitech MDot board and with a HopeRF RFM95W module connected to a Teensy, but I decided to try something else. Franz, one of the members of the TTN Nijmegen community, started experimenting with node-to-node communication using Dorji DRF1278F 433MHz modules. I’d like to support him in converting to 868MHz, so that he can post data to TTN once a gateway become available in his range.

The Dorji modules are currently among the cheapest LoRa modules available on Ebay. So some weeks ago I ordered a DRF1272F 868MHz module for about $8, which arrived this week.

The first surprise is that it has a 1.27 mm pitch header connector. The module has 13 contacts, but not all are required for the LMIC Arduino library. To make it more easy to handle, I made a custom break-out board that connects the required pins to a 2.54 mm pitch 8-pin header. Soldering the wires at 1.27 mm pitch was quite a challenge; you may want to use a magnifying glass, as those pads are tiny!

DFR1272f module adapter board

Based on the DRF1272F datasheet, the LMIC Arduino library documentation, and the Teensy pinout I connected it as follows:

 DRF1272F  |   Teensy 3.2
--------------------------
 RESET     |   nc
 DIO0      |   2
 DIO1      |   5
 DIO2      |   nc
 DIO3      |   nc
 DIO4      |   nc
 DIO5      |   nc
 3.3V      |   3.3V
 GND       |   GND
 SCK       |   13 - SCK
 MISO      |   12 - DIN 
 MOSI      |   11 - DOUT
 NSS       |   10 - CS

Please note that I did not connect the RESET and the DIO2 pin, which would be needed for FSK.

I used the following snippet of code in my Arduino sketch to specify the pin mapping:

// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = 9,
.dio = {2, 5, 6},
};

On the software side I am using Arduino 1.6.9, the LMIC library and the same sketch that I have been using with the RFM95W module.

I had to change the Semtech radio from SX1276 to SX1272 in the arduino-lmic/src/lmic/config.h:

#define CFG_eu868 1
//#define CFG_us915 1
// This is the SX1272/SX1273 radio, which is also used on the HopeRF
// RFM92 boards.
#define CFG_sx1272_radio 1
// This is the SX1276/SX1277/SX1278/SX1279 radio, which is also used on
// the HopeRF RFM95 boards.
//#define CFG_sx1276_radio 1

Following all of this, this node is nicely sending packets to my TTN application.

Bidirectional communication over The Things Network

I have been experimenting today with an RFM95W hooked up to a Teensy and managed to implement full bidirectional communication to/from The Things Network.

The Teensy by default sends the temperature (from a ds18b20) with every transmit. If you press the button, it sends the button press event instead. Furthermore, on every transmit it listens for a message (which can be scheduled downlong through the TTN dashboard), and blinks the led if a message is received.

The Arduino code running on the Teensy can be found here and the server application code running on the Raspberry Pi here.

Still to be done is to extend the server application code with the button (to circumvent the TTN dashboard alltogether) and to come up with an actual application that is smarter than a button and a LED. I am thinking to link both up and downlink to an IFTTT maker channel.

teensy_app2

KlikAanKlikUit “Blender Defender”

Some 2 year ago I came across the “Blender Defender“, a nifty DIY solution to train cats to stay off the counter. You should have a look at the original site, the video’s there are great!

We have cats, so you can imagine that we also have need for one… I started implementing my own version quite some time ago, but shortly after finishing it, it broke down somehow and I never came to diagnose the problem and fix it. Today I did: it turned out that rather than a fried RM module (what I was afraid for), it was simply a wire that came loose.

The design I followed for the Blender Defender is based on a Passive Infrared (PIR) sensor, linked to an Arduino that subsequently controls a KlikAanKlikUit RF switch.

Blender Defender

Blender Defender

In the end it is of course simply a movement sensor that can switch anything connected to the KAKU switch. But since we have a blender, I also added that to the photo.

The components I used are:
Arduino Mini, about 20 Euro (see below)
PIR sensor, about 1 Euro
SparkFun 5V Step-Up Breakout – NCP1402, about 5 euro
RFM12b module, about 4 Euro
– KlikAanKlikUit switch, about 10 euro
– 2 NiMH rechargeable batteries
– dual AA battery holder
– ABS project box

The reason for using the Arduino Mini is that I had it lying around 2 years ago and had no other use for it. Nowadays I would not use a Mini, but rather an Arduino Pro Mini. The Pro Mini is cheaper (especially if you get a clone of Ebay or DX.com) and easier to hook up to an FTDI cable. Also the choice of the RFM12B was based on me having it lying around and not having any other use for it. For my other RF projects I am using 868 MHz radio modules. A simpler (non SPI) 433 MHz radio transmitter module would also work, although the code (see below) would have to be modified.

2016-06-12 15.30.22

2016-06-12 15.30.52

Wiring it all up is quite easy. Besides 5V (VDD) and ground (GND), these connections need to be made between the radio module and the Arduino:

  RFM12b         Arduino 
    3      SDI     11
    4      SCK     13
    5      SS      10
    6      SDO     12
    7      IRQ      2

The output of the PIR sensor is connected to pin 9 of the Arduino, the button to pin 4, a green LED (placed under the button) to pin 3 and a red LED (also under the button) to pin 5.

Arduino Mini

Arduino Mini

RFM12b DIP

RFM12b DIP

The combination of the green and red LED allows to monitor the state of the sensor and to toggle between disarmed/armed:
– at startup the sensor is disarmed and the button is green
– click button -> blinking red for 5 seconds (about to be armed)
– after 5 seconds -> constant red (armed)
– upon movement -> yellow (both LEDs on) and the Blender switches on
– click button -> green (disarmed)

The sensitivity of the PIR sensor and the duration that it remains on can be adjusted with two small screws under the sensor.

2016-06-12 15.28.35 2016-06-12 15.28.45 2016-06-12 15.28.51

The source code is available from my GitHub repository.

The Things Network Nijmegen – LoRaWAN module

Next Tuesday we will meet with the core team of the TTN Nijmegen in a small workshop to get things moving. There are some gateways now in Nijmegen (see the coverage map here), so we can and should get started with prototypes and trying to build the local community!

Preparing for next weeks meeting, I ordered a HopeRF RFM95W module at IdeeTron that is compatible with LoRaWAN. Since the hole spacing is 2 mm, making it incompatible with standard headers and a breadboard, I soldered short wires to each of the pads.

RFM95W module

This allows me to plug it into a standard breadboard with a little bit of bending of the “legs”.

RFM95W

Note that – compared to the layout in the data sheet – I soldered it upside-down. This allows me to still read the silk screen labels on each of the connections.

Raspberry Pi – getting the RFM12b to work

Now that I know how to blink a LED, it is time to move to slightly more interesting applications of the GPIO interface on the Raspberry Pi. I have a few Arduino modules in and around the house monitoring the climate and various other measures. They are all battery operated and send their information to a relay that forwards all data to Thingsspeak.

My current relay module consists of an Arduino Uno with an Ethershield, connected over i2c to another Arduino pro mini. The second Arduino is connected to a RFM12b module and uses JeeLib to receive data from the sensing modules. Would it not be nice to receive that data on a slightly more powerful platform and be able to do more with it than just forwarding it elsewhere…

Raspberry Pi with RFM12b

Raspberry Pi with RFM12b

I decided to give the rfm12b-linux kernel driver a try, as it explicitly supports the JeeLib format. I followed the instructions from rbi-source without problems. After changing the board type (RFM12B_BOARD) and group (RFM12B_DEFAULT_GROUP_ID) in rfm12b_config.h, the module compiled without problems. However, it would initially not load, showing errors in the dmesg output.

Following some suggestions here and here, I used rasps-config to disable the SPI, I2C and the Device Tree. After that, it did load and dmesg showed

[ 478.278166] rfm12b: added RFM12(B) transceiver rfm12b.0.1
[ 478.278391] rfm12b : driver loaded.

I compiled the example applications and used this

pi@hackpi:~/rfm12b-linux/examples/bin $ sudo ./rfm12b_read 

successfully opened /dev/rfm12b.0.1 as fd 3, entering read loop...

Fri Apr 29 20:07:50 2016
	32 bytes read
		4 0 0 0 115 24 0 0 87 14 109 64 102 230 11 65 41 44 124 68 
		0 0 192 127 0 0 192 127 115 162 189 253 
Fri Apr 29 20:08:14 2016
	32 bytes read
		2 0 0 0 59 77 2 0 122 233 110 64 210 225 148 65 0 0 192 127
		0 0 192 127 0 0 192 127 93 112 175 32 

showing two messages from two modules. I recognise the pattern as

typedef struct payload_t {
  unsigned long id;
  unsigned long counter;
  float value1;
  float value2;
  float value3;
  float value4;
  float value5;
  unsigned long crc;
};

belonging to the lm35 and bpm085 modules that are sending their data approximately every minute.

lm35

bmp085

Raspberry Pi – first steps to blink a LED with Python

I already purchased my first Raspberry Pi in 2011, but have been postponing connecting any electronics to its GPIO interface. Instead, I have been using it for more general computing applications (media center, web server, remote ssh access and tunnel, etc.). Rather than using the Raspberry Pi for in refacing with hardware and IOT, I have been using a bunch of Arduino’s to implement sensors and actuators for home automation.

Since I recently have been brushing off my Python programming skills for the EEGsynth project and been teaching myself Node JS, I was triggered to revisit the Raspberry Pi for GPIO electronics. With the Raspberry Pi it will be easier to implement my own web server and to use webhooks to integrate my home automation hardware projects with online platforms such as IFTTT.

I decided to try Python first and after browsing the web decided to use the WiringPi interface, as it supports C programming in the same style as on the Arduino, but also has wrappers for more high-level languages (Python, PHP, Ruby and Perl).

I started with installing the WiringPi library as per instructions

git clone git://git.drogon.net/wiringPi
cd wiringPi/
./build 

and tested it with a LED in series with a 680 Ohm resistor attached to the first GPIO pin, aka pin 17 on the Pi cobbler. I still have to wrap my head around the pin numbering, but understand that there are different numbering schemes.

Subsequently I ran the test from

cd examples/
make blink
sudo ./blink

and also tried out this on the Linux command line

gpio write 0 1
gpio write 0 0
gpio write 0 1
gpio write 0 0

This all worked as expected and the LED would nicely blink. I subsequently moved on with Python. Instead of following the detailed installation instructions, I simply tried

sudo pip install wiringpi

which worked like a charm. The following Python code

#### this is blink1.py #### 

import wiringpi
import time

wiringpi.wiringPiSetup()

wiringpi.pinMode(0,1)

while True:
    time.sleep(0.5)
    wiringpi.digitalWrite(0,1)
    time.sleep(0.5)
    wiringpi.digitalWrite(0,0)

works with sudo, i.e.

sudo python blink1.py

As with the pin numbering, it is still a bit of a puzzle to me when super user rights are needed and when not. But the following worked for me without sudo

#### this is blink2.py #### 

import wiringpi
import time
import os

wiringpi.wiringPiSetupSys()

os.system('gpio export 17 out')

wiringpi.pinMode(17,1)

while True:
    time.sleep(0.5)
    wiringpi.digitalWrite(17,1)
    time.sleep(0.5)
    wiringpi.digitalWrite(17,0)

and then on the Linux command line

python blink2.py

It is already rewarding to see a simple LED blink. Next challenges will include combining it with a RFM12B or RFM69CW module to have the Rasperry Pi receive the messages from the (battery operated) Arduino’s for which I use the RFM12B for communication.

Furthermore, Adafruit has a nice tutorial showing how to use Node JS with a Raspberry Pi. That is also something to explore…

Raspberry Pi as Eurorack synthesizer module

Processing realtime EEG data from the OpenBCI system requires software running on a computer. For the EEGSynth project we do the rapid application development using the platforms that we are most familiar with, i.e. standard laptops and the FieldTrip toolbox, which is based on MATLAB. However, in the end we want to implement as much as possible using affordable and open hardware and software. Hence we opted for the Raspberry Pi, a credit card–sized single-board computer. It runs Linux, which makes it easy to use standard programming platforms and interfaces such as Python and Redis to implement the software stack.

In the first EEGSynth studio performance you can see Stephen in the middle, operating the MATLAB-based GUI for the EMG/EEG processing, and Jean-Louis at the back operating the synthesizer. The goal of the technological development is to put Jean-Louis completely in control and to make the interface of the EEG synthesizer as similar as his other modular synthesizer modules. Hence the need for fitting the Raspberry Pi into a Eurorack synthesizer case.

Here you can see some photo’s from the construction of the front panel.

2015-11-14 15.32.52 2015-11-14 16.30.57

The front plate has holes for the various interface ports to interface with the Raspberry Pi. For a sturdy mount I glued a section of L-profile rails to the front plate.

2015-11-14 21.36.36

After mounting the Raspberry Pi, I connected the HDMI and audio port with a short cable to the front panel.

DSC_0061

Here you can see the Raspberry Pi in the Eurorack case, next to the power supply.

DSC_0084

Eurorack power supply

I am working on fitting a Raspberry Pi as a Eurorack module in the EEGSynth. A previous post shows the completed case. Besides the Raspberry Pi which needs 5V, it will also hold a CV/Gate controller and some other modules for interfacing between the digital and analog parts of the synthesizer. The operational amplifiers and some other ICs on those modules require a symmetric positive and negative rails.

As I am not planing any critical parts that require an very stable voltage (such as a VCO) in my enclosure, I decided not to go for an expensive linear power supply, but rather construct one myself on the basis of two 12V switching power supply that I salvaged from some old wall-warts that once served some external 3.5 inch USB hard disks. The AC-DC converters have the 220V side isolated from the 12V side. This allows to connect the positive DC rails of one to the negative DC rails of the other, resulting in +12V and -12V from either converter relative to the common ground.

The Raspberry Pi requires quite a bit of current compared to most synthesizer modules, hence converting the 12V into 5V with a voltage regulator such as the L7805 would not be very efficient. Therefore I also added a 5V 2A AC-DC converter.

DSC_0071

DSC_0069

For safety I made a small plexiglass enclosure using the laser cutter at the Techlab Nijmegen. All electronics, except for the connector, switch and three LEDs are completely enclosed behind the aluminum front panel.

DSC_0072

The connector with the synthesizer modules consists of a flat cable, wired according to the A-100 system bus.

The LEDs show the status for each of the three voltage levels. Surprising is to see that it takes a good 10 seconds for the capacitors of the +12V and -12V to completely drain when switching the power off.