Esp8266 - Programming Success

For several weeks, I have been failing at programming the Esp8266 ES-11.

I had purchased a group of five Esp8266's for initial experimentation. I also purchased a small number of 3.3v/5.0v FTDI (USB to Serial) Adapters which are used to program the Esp8266's (see previous post).

Esp8266 and FTDI

The FTDI is also used to configure the Esp8266's using simple (default) "AT" instructions.  I could configure the Esp for "Station", "Access Point", and for "Both" modes. In "Both" modes, the Esp can be configured as a WIFI-to-WIFI Router. The cellphone APPs; "Net Scan" and "WIFI Analyser" are very useful to understand what is going on (or not).

Everything was looking great.

So, the next step was to compile a program, to replacing the Default functions with a Program that I have written. The instructions looked simple, and there are several Programming Environments to choose from; Arduino IDE, nodemcu, ESPlorer, and others. Besides, supposedly, there are easy to use programs to re-Flash the device back to the "Factory Fresh" original (ROM) state (so I thought).

This is where the Trouble Started.

At each attempt to do something interesting, that is; Program the Device or Reflash it back to original configuration - I killed another of my Esp8266s, in other words I BRICKED it!

Of the five purchased Esp8266's, I managed to BRICK three of them, I only had two good Esp's left. Now, being gun shy, with the new Exp8266, everything was suspect.

The goal became "How to UnBrick a Esp8266" without "Bricking" another. I have been working this problem for about two weeks without progress or solution.

There is a ton of information on the Internet regarding Bricked Exp8266's, but a lot of it is confusing and conflicting.

This post is about what I did to UnBrick my Esp8266's.

I gave my friend Jeff - KO7M a Bricked Esp8266 and one of my FTDI USB-to-Serial Adapters. We worked several days trying to download or ReFlash the Exp8266 - without much luck.


The Fix.

After several more hours of work, Jeff suggested and tried a different FTDI.

It worked !

To make a very long story short, we replaced the FTDI with another variety, the Parallax PropPlug. We think the previous FTDI was corrupting the downloaded data that was being sent to the Esp8266's.

Yes I know, the PropPlug is a 5V device and Esp8266 are 3.3v devices. But I forgot that on the original test, and it is working, so I have not changed the configuration (only TX/RX/RST/GND are connected).

UPDATE: One of my readers (yeti) provided correction, the PropPlug is actually a 3.3v chip and device, I have always thought it was 5v. See Link,  Thanks !!

The PropPlug (on the right)
connected to
the Esp8266 (on the left)

Question: why would the original FTDI work interactively, but would NOT work to download Batch and Binary files? - "I Don't Know, and Don't Care" - with the PropPlug, I now have something that works.

Since I started using the PropPlug I have NOT had a single failure, and we have recovered each of the Esp8266's with either the original Binaries, or my compiled programs.

Currently I am playing with Arduino IDE Compiled WIFI WebServers, one of the servers has been running for greater than 48 hours, and has serviced about 4800 test page requests. I have three running side-by-side.

Three Web Servers

These will become a part of my Internet-of-Things (IoT).

I can't guarantee that they are online, but you can check at: http://dc02.ebcon.com:8160/

Esp8266 Web Server

Note: the page refreshes each 30 seconds.

More fun and information to follow.


-- Home Page: https://WA0UWH.blogspot.com

More Playing with MQTT

With updated software, mosquitto version 1.4.1, it is very easy to connect two Brokers (see problem as suggested on previous post). A few new line in the configuration files is all that is needed. To publish (upload-only) my Broker's Topics to the public Broker at iot.eclipse.org, I used the following.

Content of: /etc/mosquitto/conf.d/bridge.conf

connection ebcon.com
address iot.eclipse.org
topic # out 0 "" ebcon.com/

Out-bound topics have "ebcon.com/" pre-pended, currently I do not allow or receive data from iot.eclipse.org directly by my Broker. If I want a topic, I subscribe directly with an application (mosquitto_sub).

My own local Brokers (in three different physical locations) exchange data from the two lesser Brokers in bidirectional fashion. Brokers do not have to be hierarchical, they can be peers. In my case I chose to configure the "bridge" on what I consider the lesser Brokers.

connection remote1
address <remote broker IPA>
topic # both 0

As a test, I created a "JoyStick" control publisher, when the joysticks are moved, all Brokers receive the data, much faster than I expected. Performance is very good. Eventually, I will control remote servos to direct (point) Raspberry PI Cameras.

You can subscribe to my testing with:

$ mosquitto_sub -v -h iot.eclipse.org -t 'ebcon.com/#'

Note: Mosquitto MQTT Brokers can publish any kind of data, including Web Pages and Photos.



I am just learning and having FUN with MQTT !


-- Home Page: https://WA0UWH.blogspot.com

Esp8266 With 0.1 Inch Header

In preparation for programming my Esp8266 and the Internet of Things (IoT), I have installed a 0.1 inch header. The connector pad on the Esp8266 are 2mm and therefore a lot of lead bending was necessary.

I think this was my first soldering project that required full 15X Microscope magnification. The Esp8266-Esp11 board is much smaller than implied from the ebay photos (a previous post). The on-line diagrams and documentation are correct, but in your hand it is very small.

Esp8266-Esp11 with
0.1 Inch Header Installed

I have on order the programming interface, which should be received soon. I will use the Esp8266 with the installed header for use on Protoboards, actual projects will use direct solder to matting "Castellated Pads" on custom PCB's.

Esp8266-Esp11 Pin Layout

For my later reference, I have included the pin diagram.


-- Home Page: https://WA0UWH.blogspot.com

MQTT - Bridge Work-a-Round

 UPDATE:
I was using a very OLD version of "mosquitto" which did not support Bridges well, I am hoping the current version will work better.

-

To experiment with the Internet-of-Things (IoT), while waiting to receive my Esp8266's (see previous post), I have enlisted my Raspberry PI's into playing the part of a remote data collection device. My Desktop Workstation is the Control Point and the Master MQTT Message Broker.

Originally I had planned to use a Master/Slave Bridged Broker configuration, where the Workstation would be the Master, and the Raspberry PI's would be a Bridged Slave Brokers, and they would collect data and messages from the Esp8266's.

But, I have not been able to get the "mosquitto" Bridged Broker configuration to work as documented :-(

I have a work-a-round; I will temporary use an "ssh tunnel" to directly collect messages from the Raspberry PI's.

At each Raspberry PI's, an "ssh tunnel" is created for "port 1883" (the MQTT port), and therefore the Master Broker is directly available to the Raspberry PI's. A side benefit of is; the "tunnel" is compressed and encrypted.

On Raspberry PI:

$ ssh -CnNTf -L 1883:localhost:1883 <master workstation IPA>

With this setup, I can conduct; tests for camera servo control, send SMS messages to the Cell Phone, and other experiments (see previous posts).



-- Home Page: https://WA0UWH.blogspot.com