ESP8266 and 433Mhz Radio together?

Toying with ideas right now… it could be that the ESP-01 WIFI units are not ideal for acting as both listeners and for sending information off.  Before I started all this I was considering switching to one of the better (yet inexpensive) radios from China to work with the Radiohead library.  The ESP had me thinking that as well as doing away with the Ethernet card I might also do away with the radios. Perhaps that was over-optimistic..

So – the 433Mhz radios in question are RM22 compatible – 433Mhz jobs which work well with Radiohead – I have 3 of them in front of me – my “test rig”… and I was pondering one of those on the back of a board with the ESP-01 hanging off the end where needed (normally only one per household or whatever.

tmpCA92

So imagine the scenario… one of these is the main controller – it acts as a TCP listener (that already works fine with AT command set) and you can talk to it remotely. On the back it has the radio and runs the Radiohead network. (I’d need to lose a couple of indicator pins for the control signals for the radio which I seem to recall uses SCK/MI/MO). Run the lot off 3v3 so no interface components for either and put a 3v3 reg on the board with lots of copper as you could be talking 500ma peak for both radios…

tmp7B99Most of the time the unit with the WIFI acts as a listener while the radios share logging info with it vial commands – I already have that in place.  Commands such as OUT1=1 turn a light on –  3/OUT1=1 turns a light on internal unit 3 via the radio network. Done all of this with NRF24L01 and Ethernet board…  at some point in the night, reboot the WIFI – or just change mode – have it go get the time, perhaps dump off any eeprom-based logs which the unit has collected – and either switch mode or reboot the WIFI all within, what, half a minute or even less.

All of that seems eminently usable – unless someone can save me a lot of hassle and confirm you CAN keep up listener mode and send off web requests at the same time like any worthwhile ETHERNET Card could do….. the chip incidentally would be the 1284 maybe – the Radiohead library kind of eats up 328 memory.

Thoughts? Another scenario – main board is sitting there listening to a mobile app – and needs to talk to another –  if this were Ethernet – you’d simply have it open a client as well – I’ve done that many times… but I’m doubting you can do this with the ESP8266 – I have asked Espressif for their view – if you CAN – then you don’t need the 433Mhz radio and that’s a WAY better solution – we’ll have to wait and see. As you can see on the left- part of it is already on the go – I’ll be leaving this one for a while to see how it goes – right now it gets the time once on power up… the rest is just a matter of deciding the best way to go. If the display looks familiar, regular readers will know I’ve been working on Ethernet card based control for a long time- it’s all in the blog somewhere in the history.

Pete.

Friday Morning ESP8266

div class=”mycode” style=”color:blue; margin-left: 40px;”>

ESP8266This morning I saw a note from a Mr Steve Brown who pointed out this link for a little add-on board for the ESP-01. Our friends in America might be interested at $1.59 but sadly for the rest of the world the postage kills this one – $13+ to the UK – what WERE they thinking? I think this suffers in a couple of ways, firstly I don’t understand why 2 boards and also while it’s great to see a meaty 800ma regulator, there isn’t enough copper to let you run that at 800ma unless the input voltage is quite low..  what I would REALLY like to see is a low cost motherboard that contains a 3v3 regulator and level shifters on serial in and reset so that the ESP-01 board becomes usable on 5v systems without bodging. A little further down the line I can see a session with EAGLE PCB coming on.

10:38AM – Updates for you: Nothing new on the Frankenstein front, I asked Espressif about Windows based development and they just sent me a one-liner pointing me to the VM version – which unless you’re a Linux hack is a real nightmare and throws out error messages which mean nothing to most of us. As for the original web server, nothing new there to report, it’s still not picking up routers. 

On the LUA front – this wonderful high level language is coming along, the board will now perform trivial tasks like adding two numbers together – however the example of running a Telnet session falls over immediately and the web page example resets the ESP-01 board after 5 or 6 retries… so we’ve a little way to go.  He’s even put up a new version of the Telnet code and that won’t even load in without killing the interpreter.

However the latest attempt at a web server DOES work. Here’s the code – I loaded it in – pointed a web browser to it and it does work. Someone more advanced with LUA might want to offer a suggestion as to how to alter this so it ONLY returns any GET information – and only once as browsers tend to send several attempts..

srv=net.createServer(net.TCP)
srv:listen(80,function(conn)
conn:on(“receive”,function(conn,payload)
   print(payload) print(node.heap())
   conn:send(“<h1> Hello there</h1>This is a test”)
   end)
conn:on(“sent”,function(conn) conn:close() end)
end)

 

No other updates for that this morning and I did write into here to detail what’s going wrong with the LUA code. I’m hoping we might see a fix over the weekend – but that’s just a hope. I guess what really excites me about the LUA option is the possibility to develop code for the board without having to worry about that whole convoluted compile/link/Linux/GCC process – maybe I’m dreaming…

I think part of the problem is that some of the developers, Expressif etc are Chinese and while that’s not a problem in itself it is really hard for some of us to get a dialog going with them – I get very short answers from Espressif and get the distinct feeling no-one understands my emails – though they are trying to improve the firmware.

Daver Allan's hacked ESP-01Hacks: A friend of mine, Dave Allan (who has been helping me with testing) has been working on hacking the ESP-01 to get back some valuable pins – oh yes, you can!! Mind you we’re talking accurate soldering but if you’re desperate for some I/O, just to prove it can be done.. here’s the picture. Please DON’T write in if you burn up your board!

When I find out more – I’ll be sure to write in here. For now… it’s winter in the UK and one of my little radio boards which controls the heating has given up and died. I was hoping by now to have a WIFI alternative – but I think we’re a little way off that. Time to get the soldering iron out (elsewhere on this blogsite I have details my home control efforts spanning quite some time now).

08:54AM – Got some feedback this morning indicating that there is a new tool (Python) for uploading scripts to the LUA interpreter… not used it as I find Cool Terminal does that easily for me – but it’s probably worth making a note of for those of you for whatever reason can’t or don’t want to use the latter.

Just to be clear on the pins – a zoom below..

Pete.

Comments from Dave:   For those of you with good soldering skills and a steady hand I’ve developed a system to give you 4 extra gpio pins that are on a firm socket rather than hanging wires off the pins. It consists of removing the existing pins (pcb), replacing the 2 rows of 4 pins with 2 rows of 7 pins. Remove the 5th pin on both rows and solder the 2 rows in with the extra pins to the left.
Next solder fine wire from these extra pins to pins 9,10,12,13.

The extra pins are GPIO14, GPIO12, GPIO13 and GPIO15.

You can now plug this into a 14 pin IDC socket or any other of your choosing.

See the attached photo.

I accept no responsibility for your lack of skill if you screw the board 😆

Zoomed ESP-01

Probably the Cheapest WIFI Computer in the World (ESP8266+LUA)

07:20PM – This one is turning into a MONSTER of a blog entry  – lots of new stuff.

This article describes the ESP-01, fitted with LUA firmware that is able to converse with a serial terminal in a high level language, store programs and data, turn things on and off in a package that costs almost nothing. The possibilities for ridiculously cheap remote temperature sensors and more are finally here. The software is new, the hardware is relatively new – and we need people working on software to make remote access easy. No guarantees here as I have only tested (and reported on) some of the features. Am important fix that made this practical to use only came through in the early hours of this morning – there will be bugs but at least it’s a starting point – all you have to lose is a little time.

tmpBE85Cheapest computer is of course a grandiose title, for sure and one one that would have been invalid as far back as, oh, yesterday, but I think its’ fair to say that as of this morning we have a stunning new development.  That is not to detract from the many worthwhile firmware developments on-going for the ESP-01 and similar boards, but here I’m going to present you with all you need to get the cheapest computer in the world up and running.

What do I mean by a computer in this context? I mean a device capable of connecting to the outside world via WIFI and doing real things – like flashing a light or reading a sensor – and having a human interface installed…. I’m stretching this a little, but essentially right now as I write this I have in front of me a computer capable of responding to commands in a terminal window – for £2 – does that have your interest?

So now we have probably the world’s cheapest WIFI computer.

The ESP-01 has been around for a little while now- what you are looking at top left is a processor with built-in WIFI radio, a memory chip, a PCB aerial and a few passives. It has a 0.1” spacing (therefore easy to use) connector and that is about it. It comes with some firmware which will have you tearing your hair out if you have any – but that’s no the point – the firmware is easilty replaceable and that has not been lost on the community out there. One of the developments I’ve been following VERY closely over the past few days is that of the LUA firmware for ESP8266. That is, given the starting point of our £2 ESP-01 boards (if they cost a LOT more than that you are being ripped off) and some firmware for it that actually works. We’ve had problems with the indigenous firmware (but those problems are slowly going away, I hope) and there are a couple of alternative firmware sets floating about – and I have NO doubt they will find their place and I will be using them and blogging about them. Compiling the firmware to make your own amendments is a PAIN IN THE BACKSIDE and assumes you love using Linux – which I don’t and the compilation process churns out hundreds of miles of messages (well, quite a few anyway). But the purpose of THIS entry is to sweep away all of that and to detail this one fabulous attempt to make the ESP-01 not only act as it should, as a WIFI board- but to do it STAND-ALONE without understanding compilers or Linux or having to stick another processor on to make it work (though you CAN of course do that and some of us almost definitely will, sometimes).

LUA is a high level language – and I’ll be honest despite knowing DOZENS of computer languages I’d never come across until last week and I am so glad I now DO know a little something about it. So before delving into explanations, lets cut the bull and see what we can expect for £2.

CooltermTake one £2 board  + FTDI. i.e. a USB to serial interface, cheap – like… a fiver – if you’re into Arduino programming you probably already have one) and very common in the Arduino world – feed that into a PC with a suitable terminal program and VOILA. See the picture on the left. Does THAT get your interest up? You are looking at the BEST free serial terminal software I’ve found this week – having wasted a good day of my life with the absolutely horrible REALTERM – this free package could not be better suited to this application IF IT TRIED. 

So what we’re looking at on the right is the output from the little ESP-01 board, loaded up with the LUA firmware (this morning’s version). I’ve installed a couple of routines I put together and I’m talking to the board on my Windows PC, via Coolterm at 9600 baud. In this example I’ve given you the world-famous “Hello world” but there is so much more that you can do already. I envisage testing something like this – then lifting the EPS-01 off onto it’s own motherboard (yet to come into existence, we’re looking at this right now) and controlling something via WIFI.

What you see on the right is the board, connected to a 3v3 supply (should be able to handle maybe 250ma minimum so NOT the very tiniest of regulators) and the FTDI which gives it access to serial commands from my computer using this great Coolterm package.

To follow…. far more information and the high level software to get this far. I figured you’d want to set up a board, get the firmware and grab the terminal software. Refresh this page to see the latest version. I’ll show you examples of coding. If you want more information see my previous blog entries. You will be able to write to the WIFI board directly from the terminal and even “dump” in a while set of instructions or a “file”. In my example, wifi-sta-getap(listap) is a built-in function that is calling a user function which was loaded in by me and stored in the non-volatile storage of the board. In time, examples of functions you can save permanently on the board will appear – all of this with nothing more than a text editor and free terminal program. Hell, you could do all of this from a tablet – on holiday, on the beach (if you know any beaches with WIFI or you have a MIFI unit, for example).

LUA beginners guide01:53PM – So, the basic LUA interpreter requires a start-up function and that start up function can initialise variables and make the connection to your WIFI router – it’s all interpreted, it all sits in FLASH and hence can be remembered when the power is cycled. Actually creating a product out of this is beyond the scope of this article but the good thing is that armed with the terminal software you can experiment, often the easiest way to learn. You need to get the software which has some instructions and an API guide. Also grab online a beginners guide to LUA – it really is easy if you’re used to C or similar languages and you’ll find yourself as you’re reading the guide thinking “oh THAT’s a good idea”.

You should be looking to learn about LUA 5.1 – not 5.0 and apparently not 5.2 – and beware the implementation of LUA used in the ESP8266 is not right now a full one – it does not (unless I missed something) handle floating point. But what is in there is support for things you’d never imagine in such a low-cost board – the writer has implemented (I’ve not tested these yet) i2C and some analog functions – he’s also implemented PWM on pins (ok so you’ve only got a maximum of 4 pins and only 2 if you want serial comms to play interactively… but think about it – port extender on those two pins!!!  To get there in the first place you’ll need one of the means of programming the firmware into the boards – I suggest checking previous blog items here as I’ve already mentioned this. I’m using for this firmware the simple esp8266_flasher.exe on my Windows based PC.

As you will see in the documentation, for this “computer” you will need to define a start-up routine. That is, something that runs when you power up the kit so that it is connected to your broadband. Now, once it’s been set up and has an IP address, actually you don’t need this as it will remember the address of the router and hook up automatically, but that is new and you might want to give that a good test rather than take my word for it.

ZeroBraneNow, you may be wondering – can I get LUA for Windows so I can have a play? Well yes but remember this will be more feature-rich than the one we have for the little board. You can get LUA for Windows here. Don’t ask me questions though – I know nothing about it except to say it is a command-line version of the interpreter.

But what if, like me you hate command line stuff and want the usual graphical IDE? Well you’re in luck as the ZeroBrane IDE will let you have a tinker without getting your hands too dirty. If  on a Windows PC grab the LUA code and install, grab the ZeroBrane and install and (well in my case) within minutes without any effort other than to learn to press F6 – I had my first test program running – see the window on the right. What fun. I repeat this is for learning only – you won’t get any of the graphical examples running on the little ESP-01 – but at least you get to play with variables and functions etc. and quickly get to know how to use LUA which the new firmware is based on (based on version 5.1).

Programming:

As I referred to earlier, in order to do anything sensible you need a start-up routine. I cannot get into LUA programming here but I’m going to show you a “file” I’m playing with – which works.

Couple of things you need to know about LUA for this to make sense You can surround strings by single quotes, or double quotes or 2 opening and 2 closing brackets. The advantage of the latter is you can freely mix quotes inside there – neat, huh!  There is an operator for concatenating strings – 2 dots, like this.   ..

So given that you have the firmware in place and given that the Serial terminal is running at 9600 (and if you want to send several lines pasted into the window I suggest setting a 300ms interval in between each line)… here is my code.

file.remove(“init.lua”)
file.open(“init.lua”,”w”)
file.writeline([[print(“Pete’s LUA module 0.1”)]])
file.writeline([[tmr.alarm(4000, 0, function() dofile(“thelot.lua”) end )]])  
file.close()

file.remove(“thelot.lua”)
file.open(“thelot.lua”,”w”)
file.writeline([[print(“”)]])
file.writeline([[print(“Loading functions”)]])
file.writeline([[tmr.stop()]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[connecttoap = function (ssid,pw)]])
file.writeline([[wifi.setmode(wifi.STATION)]])
file.writeline([[tmr.delay(500000)]])
file.writeline([[wifi.sta.config(ssid,pw)]])
file.writeline([[tmr.delay(4000000)]])
file.writeline([[print(“Connected to”,ssid,”IP:”,wifi.sta.getip())]])
file.writeline([[end]])

([[print(“Connecting”)]])
file.writeline([[connecttoap(“loft-east”,”xxxxxxxxx”)]])
file.writeline([[print(“OK”)]])
file.close()

Functions can be stored in the board by typing them in – but you lose them on power up – another way is to add “files” to the board which do NOT get wiped at power up – and “DOING” the files – it running the contents therein. Best to ERASE (remove) an old file before putting a new one in – just to be safe. So as you’ll see above I am wiping an old file called “init.lua” and replacing it with a new one – that’s the startup routine – I’m then writing another file which contains functions I may want to call. In the start-up routine there is a timer that mean that after the start-up routine has all done, a few seconds later the second file will be run – putting various routines in place, connecting to my router (put your own details in there) and saying OK.

If this does not make sense please don’t shower me with questions – I’m only one step ahead of you. It’s all pretty much explained in the files that come with the LUA firmware – print them out and study. PLEASE NOTE at the time of writing there are still bugs in the interpreter, not the least being the stack runs out almost immediately when for example trying to run a simple web server. The author is aware of this.

Mo Hasan has pointed out an Indiagogo campaign for another board here – though they don’t seem to be getting too far at the time of writing – and you might also be interested in a more expensive board here. One thing is for sure, we’re soon going to have WIFI boards popping out of our ears. That sparks off TWO new conversations… 1) Security and 2) I wonder how many gadgets your average cheap home router will handle before croaking!

There are of course a number of variations on these boards as well as the ESP-01.

ESP-09

The ESP-09 seems interesting in that it has no aerial on-board and the pins are solderable underneath. More’s the point – there are 19 of them – now THAT could be useful – especially with the LUA software which can support other IO pins than GP00 and GP02

tmpC031

Then there is the ESP-02 – this does not have an internal aerial but this one just seems to have the normal number of pins so unless you really need that extra range, not sure of the point.

 

tmpB430

And here we see the ESP-08 which seems to have neither an internal aerial NOR an external aerial socket. Wierd. That has a few more pins.

 

In case you are interested (well, you would be or your would not be reading this article) I found this and updated from Chinglish into English – (I hope – you might want to check and not take my word for it)

Different type of ESP8266 Serial boards have their own features:

1. ESP-01: PCB Antenna, 400m Distance (yeah, right), easy to use
2. ESP-02: Surface Mount Device, longer distance, antenna can be attached to the shell by using an IPX header
3. ESP-03: Surface Mount Device, Built-in ceramic antenna , all IO available
4. ESP-04: Surface Mount Device, customisable antenna, flexible design, all IO available
5. ESP-05: Surface Mount Device,  compatible with external antenna – sorry even I could not translate the rest
6. ESP-06: Bottom SMT technology, all IO available, with metal shielding case
7. ESP-07: Semi hole SMT technology, all IO available, with metal shielding case,supports external IPX antenna as well as internal ceramic antenna.
8. ESP-08: Semi hole SMT technology, all IO available, with metal shielding case, type of antenna can be defined by customers (what does THAT mean?)
9. ESP-09: Ultra small packaging 10*10mm. 4 layer technology, 1M byte (must be a bigger FLASH –  but how would you use THAT?)
10. ESP-10: Patch Interface, narrow body design, 10mm width, suitable for LED Controller.
11. ESP-11:Patch Interface, ceramic antenna, small body design.
 

More information generally including many links here.

08:31PM – Note: The Telnet example does not work – crashed immediately on use for two of us on two installations – reported.

If you come up with some interesting ideas for code – or thoughts as to how this amazing little device might be used in this context, please DO write in here – we’re all on a learning curve. If you want to know more about me (can’t imagine why) – there’s an about page in here – see menu at the top – links off that.

ESP8266 Options

Firstly let me say this is not intended to be authoritative, so please don’t come back to say I have it all wrong… these are just my views for now – they may change as things develop.

tmp962BYou may have noticed I’ve been taking an active interest (there’s an understatement) in the development of firmware for the ESP8266-type WIFI boards. Why? Well I see this little board as a saviour on two fronts:

1. As a low-cost stand-alone unit – using either C or a higher level language to make the ultimate in low cost controllers.

2. As a means to accessing the Internet for Arduino and other microcontroller systems at low cost.

Up until now, the lowest-cost means of scattering devices around an area included the likes of the NRF24L01 radio modules, at around £1 each you don’t get much cheaper, but they have very limited range. This can be mitigated somewhat by networking software and in my own homes and elsewhere I am using a network of Arduino-type devices to control and monitor heating and lighting. It works – but the hoops you have to go through to get range make it not a lot of fun. Low cost alternatives include RS485. Again at around £1 from China you can get RS485 interface boards and these are fine – but you have to wire everything together.

In my case the whole thing is held together by a master board using hardwired Ethernet to talk to the outside world. All well and good but for all the wires and intermediate wireless points to boost the range.

And then along comes the possibility to use WIFI. I have simply dismissed the alternatives available at £10+ as the cost per point starts to become excessive – especially for anyone doing this as a hobby.

A few weeks ago, the ESP-01 and similar boards appeared out of the woodwork, a dirt cheap Chinese WIFI board around the size of the NRF24L01. At first I started to think of them as a  simple cost-saving replacement for my own main Ethernet card and so I was very interested in the AT version released by Espressif. To explain: The little board uses serial control to talk to a host microcontroller such as an Arduino. I have spent every spare minute on this as we’ve gone from a board being released with almost useless firmware, to the point where today we have maybe 3 viable options for taking this forward and I’ll go into that in a moment.

tmp2ED3The hardware: The ESP-01 is probably the most popular design and sadly it is not ideal. The tiny board has an 89-pin header and it’s sole saving grace is that it is CHEAP – just over £2 at best. It has a PCB antenna which works but doesn’t give the best range but it’s save to say that if you have routers offering a strong signal throughout the building, this board will work for you.  As a unit designed to work with, say an Arduino, it is perfect.  As a stand-alone board it is useless as you only have simple access to one pin! The problem there is that with 2 pins you can implement, say, I2c which opens a whole world of peripherals. With 1 pin –  well, you can flash a light or read a temperature sensor.

There are others, the ESP-03 design brings out the pins to the edge of the board. In both cases these boards use 3v3 – which is fine unless you consider that many controllers and many peripherals run on 5v and those microcontroller boards which offer 3v3 do so with insufficient current to safely power these boards which can use up to 250ma (tiny 3v3 regulators often supply only 100ma).

In my experience, while powering the boards with 3v3 you can feed the output directly to, say a 5v Arduino but you need at a minimum a resistive divider to the inputs – that is the serial input – and the reset (and you really do need to be able to access the reset).  There is even a board out there which I won’t discuss which has access to power and serial only – that is dead in the water for me.

What I would LIKE to see is a 5v compatible board with internal aerial, the pins available on 0.1” centres and an optional aerial socket for external aerial. Do I want this? YES, do I want to pay over £3 for it? NO. Therein lies the issue. Only the Chinese can make that happen at the price.

What absolutely is needed is a minor change to ESP-01 to bring out at least one more port wire. The magic phrase… “I2C”.

The software: This has been an absolute minefield and I would say it is only in the last 2 days that I’ve come to the conclusion that we have a real winner of a board here. There are to my mind 4 routes to potential success available to us, depending on our requirements…

1. The original Espressif software. To call this awful up to now would be generous.. Using the existing software is a nightmare as it has bugs – several trivial and one major. The “busy…s” problem is firmly embedded in my brain as a timeout which won’t go away and as for some of the error messages, “no is fun” comes to mind.  However as of yesterday, an as-yet unavailable version seems to have tamed but not eliminated the first problem.

I have an Android App for my mobile phone which controls 4 outputs on an Arduino which is using the ESP-01 board. Until yesterday I could not keep it running for more than a few minutes without the dreaded lockup. The busy issue still appears but is now an inconvenience. My App has not fallen over in 20 hours (to keep this in perspective, my Ethernet-based home controllers have stayed up for well over 1100 hours without a hitch). I am relatively confident that if Espressif continue to develop this we will have source code access to working software within days or weeks.

2. Frankenstein. There is one complete re-write of the software, no longer using AT commands which, until the designer got the flu last week was starting to look promising. Badly documented to date this is a potential alternative to the Espressif software.

3. There is, floating around, an implementation of a standalone web server designed to initially turn a LED (or whatever) on and off from the ESP-01 etc. using the board itself with no external support. This can act as a router for setup and via a web page can be set to use your router. Another fellow has developed this to read temperature and you can see the possibilities here… but right now, it is NOT a practical solution as there is a bug in the setup software which means the part where it runs stand alone and gives you a list of available routers… doesn’t actually work. You end up having to FLASH the original Espressif software to setup the router – then re-flash this software …. erm, no thanks.

I do have promises this will be fixed and if and when that happens, I think this has a niche all of it’s own – not in it’s original form but with custom software to make better use of I/O.

4. Finally, one great hope is a development that puts a LUA-based interpreter inside the ESP-01 etc. and allows for a stand-alone unit needing no other hardware. See my notes however about I2C and the need for another pin. So – WHAT ON EARTH is LUA? I’d never heard of it until last week when the first implementation came out – which didn’t work properly. I am about to test the update completed only hours ago and a colleague of mine is already onto it and getting excited. Essentially LUA is a high level language interpreter. You can send commands, functions and even complete  programs and data to the ESP-01 serially and have them run on the board with nothing else but power attached.

There is even a start up function you can send which will ensure the board acts sensibly on power up. If you are familiar with C and Java etc you’ll find LUA reasonably straight forward but you might want to get something printed out. The ZIP file for this software contains a lot of info and if you look up LUA on Google you’ll find a complete reference website – concentrate on the features of version 5.1, not 5.0 or 5.2 (as far as I can tell). 

Today I intend to give this last option a good hammering – one of the features CLAIMED to work with e LUA version is I2C. Now, how you do that with 1 wire I don’t know, I suspect on the ESP-01 it’s going to involve micro-surgery but we’re still trying to work this out. But think about it – even if it’s slow (as interpreters tend to be) if it will act as a web client and web server that’s half the battle (reading time servers etc., remote access) and the ability to handle I2C means the little board on it’s own, with no compiling from your perspective, can talk to a myriad of devices including port extenders, clocks, LED drivers – there are thousands of devices out there that talk I2C ( for the uninitiated, a 2-wire bus where devices have addresses and can talk both directions). Remember that this is not an Arduino – it’s a powerful little Microprocessor with a reasonable amount of room – the possibilities are huge.

We have cheap WIFI devices, we have at least one company working on a prototyping board for them, we have many suppliers ensuring we should have reliable access to the devices…what we need is for at least one of the above options to mature to the point where we can rely on them to do whatever it is we want them to do. I could see, best case, these things being a fantastic, low-cost alternative to radio networks for so many applications around the home and office. Sadly the current devices use a lot of power which makes solar operation “challenging” – but that’s just for now – you never know what might happen tomorrow. What would really be nice would be a cheap supply of the actual chips so those of us with PCB abilities could make our own versions.

Everything I describe above, has links in my previous blog items in here. I am so lucky as a man who spends his life going from meeting to meeting around Britain and Europe that at this very time I’ve a short lull in said meetings which means I can spend a little time indulging in this challenging but exciting development. I don’t normally get the time to do this so please, take advantage, do look in over the next couple of days to see what’s new – it’s changing by the hour.

ESP8266 LIFE

This is turning into a diary – my life with the ESP8266 – sounds like a serious disease.

Last night I tried increasing the speed at which my Arduino-like board talks to the ESP8266. I’ve been using 115,200 baud and it was suggested that the problem might not exist at HIGHER speeds. Sadly the Arduino-type boards just will not talk at much higher speeds – either because of inaccuracies or because of the resistive divider I use to talk to the ESP-01.  As the results were SO bad at high speed, I thought I’d try a LOWER speed just in case, in fact it was my serial that was causing the “busy…s” problem – turns out it wasn’t.

So this morning I received a reply from one chap who has tried the LUA version of the ESP8266 software only to find it crashes for him when stressed. His example code is as follows:

i = 0 repeat print (i) i=i+1 until (i == 800)

Well there’s a surprise and another hope dashed for now. Meanwhile the latest Frankenstein code (all of this is referred to in previous blogs) failed last night – latest BINARY files go into a loop on powerup. Hopefully we’ll see another release of that tonight as the author is now aware of the issue.

For my own part, I received an email from ESPRESSIF to ask me to test an archive file they sent me – an experimental version of the software to see if the “busy…s” problem would go away.  That was nice of them and it’s good to know that someone at least understands there is an issue.  I’m including the contents of my reply and their email so you can see the problem and how it occurs.

Here it is in total….my response to Espressif followed by their original email trail – you’ll see they acknowledge the issue, were originally too busy but it’s nice to see them now trying to help.  This is running at 115,200 on an Arduino-type board with 2 UARTS – one for the ESP-01, one for the Serial debug.

………..

Thank you for the test code… but the problem still exists with the new code.  Here is an example.

AT+CIPSEND=0,3
> 1
SEND OK
+IPD,0,4:GO3
OK
AT+CIPSEND=0,3
> 0
SEND OK
+IPD,0,4:GO2
OK
AT+CIPSEND=0,3
> 0
0,OFF
0,CONNECT
+IPD,0,4:GO3
OK
AT+CIPSEND=0,3
busy s…
0
busy s…
DOING A FULL RESET

So.. here is what I do..

I use an Android program called NETIO (http://netio.davideickhoff.de/en/)

My Arduino (Mega) uses TWO Serial ports at 115200 – one to talk to the debug serial you see above – and one to talk to the ESP-01 board… hence there are responses above from the ESP-01 AND messages from the board. You can see at the end I am doing a reset to make the board recover but this is not the solution.

Here is what happens…

On power-up my program looks for a valid IP address and if it does not find one it sets up the board. It sends one instruction at a time, waiting for the relevant response – or a timeout.

It sets up the connection to my router then sets up a TCP/IP listener on port 4000. From there, when the APP is running on my phone that sends requests for button status to the ESP-01 – and my board picks that up and sends responses… to say a LED is on or off…

AT+CIPMODE=0
AT+RESET
AT+CWJAP=”loft-east”,”1012423423”
AT+CIPMUX=0
AT+CIFSR?
AT+CIPMUX=1
AT+CIPSERVER=1,4000
AT+CIPSTO=10

The board then receives messages from the Android APP

+IPD,0,4,G01

The instruction is requesting the state of LED1

Arduino sends back a reply…

AT+CIPSEND=0,3
0

i.e. It is sending 3 characters = “0” followed by CR/LF.

So typically we see checks for 4 LEDS as such.

+IPD,0,4,G01
AT+CIPSEND=0,3
0
+IPD,0,4,G02
AT+CIPSEND=0,3
0
+IPD,0,4,G03
AT+CIPSEND=0,3
0
+IPD,0,4,G04
AT+CIPSEND=0,3
0

The above shows 4 requests for status – for lamps 1-4 and the Arduino sends back “0” in each case for lamp OFF (or “1” for lamp ON).

This happens continuously.

This works perfectly.. BUT… at any time I might turn the phone off [or swap apps] – or go out of range. Much of the time the data simply stops – and recovers when I start again – but SOMETIMES as in the example above – the BUSY_S occurs and that is the end of it, a reset is required…

Can you help eliminate this bug. I have no control over the NETIO APP – which works utterly perfectly with wired Ethernet.

Regards

Peter.

From: support-at@espressif.com [mailto:support-at@espressif.com]
Sent: 17 November 2014 02:53
To: pete
Cc: support-at@espressif.com
Subject: Re: RE: Esp 01

Hi,

Please test bins as the attachment, if it still has “busy s”problem or not

boot_v1.1.bin downloads to flash 0x00000

user1.bin downloads to flash 0x01000

esp_init_data_default.bin downloads to flash 0x7C000

blank.bin downloads to flash 0x7E000

If it still has“busy s”problem, please tell us your test steps, list of AT commands that you sent. 

Thanks for your interest in ESP8266.

Regards,


support-at@espressif.com

From: Peter Scargill

Date: 2014-10-30 17:39

To: support-at@espressif.com

Subject: RE: Esp 01

Thanks but many of us merely want to USE the module, not develop it – I have no experience of using GCC and the Linux environment, I simply want a WIFI module that works. Please fix the firmware so that the “busy s” problem goes away..

Regards

Pete

From: support-at@espressif.com [mailto:support-at@espressif.com]
Sent: 30 October 2014 08:12
To: pete
Cc: support-at@espressif.com
Subject: Re: Esp 01

Hi,

Sorry, our schedule is so full that we will put this till later,

but our code is open source now,  on BBS http://bbs.espressif.com/

You can get full source code and do your own development

Regards,


support-at@espressif.com

From: Peter Scargill

Date: 2014-10-30 15:57

To: support-at@espressif.com

Subject: Esp 01

Hi

Esp01 esp8266…  When will we see a fix for the “busy s…” Problem?? We

are unable to make serious use of these boards until this is fixed.

Currently using 0922 version software.

Regards

Peter Scargill

LUA-Based Firmware for esp8266

imageFirstly let me start by saying I have never used LUA before so I have no idea if this is any good. As you may know, armed with not enough time to get into doing my own compilations, I’ve been frantically looking around every night for firmware for the ESP8266 (in my case the inexpensive ESP-01 WIFI board) and I’ve come across a couple of promising developments which I’ve detailed elsewhere. I’m essentially trying to get away from the buggy software that comes with the boards. If you look elsewhere in the blog you’ll see I’ve even made a short video on the subject. It’s driving me nuts.

Anyway after a couple of days breaks as I have to attend business meetings constantly, I’m back and I stumbled across this link this evening. Now, I can tell you that if you use something like the ESPE8266_flasher.exe on the binary file this fellow provides – it WILL work. It seems to work at 9600 and I’ve not yet figured out how to ramp up the speed if indeed that’s been included. Further I can’t tell you if it will work as a WIFI listener as I could not get that to work. I also note on reset you get a worrying message…

> 8ŸŽþŠšƒ�‡‚‚þ�‡‚ŽþX�ö
lua: cannot open init.lua
NodeMcu 0.9.2  powered by Lua 5.1.4
>

BUT…. it’s worth a few minutes of your time – he’s developed a high level language-based firmware for the board and if he keeps going we might just have another way to access our cheap WIFI boards.. I hope one of you can spend more time on this than I’ve had available – I got it to connect to my router no problem (and that survives powerup) but that’s about it – it just has a feel about it – LOOKS like a winner and there’s no shortage of documentation if you follow the link.

Incidentally for anyone afraid to turn their one and only WIFI board into a brick – I’ve blown so many different options into this board and it always recovers.

ESP8266–An Interesting Development

Updated Sunday night:

I got up this morning to see if my ESP-01 board now set to run at 57600 was being any more reliable, constantly polling the state of an output and sending it back over WIFI… erm, no, the board had reset for some reason. Still struggling with the official software. Anyway, I thought I’d scan the web to see if anything was new. I’ve been using Google since it was invented and I’ve only just discovered the option to see only what’s new (I know, sad).

Anyway, I stumbled across this link – something called esp8266-frankenstein – “alternative firmware for ESP8266 modules”. In there is a BIN directory and in there are two .BIN files. I took my new FLASH DOWNLOAD_TOOLS_V0.9.2 tool (for Windows) using PYTHON (essentially loaded Python onto the PC (couple of button presses) and run the code… that lets me download multiple .BIN files onto the ESP8266 boards… I’d never had any luck up to now but then, these two .BIN files load at 0x00000 and 0x40000 respectively. I punched in the information and… GOOD GRIEF – it worked.

tmp6CBCThis is completely new software for the ESP8266, it says “release candidate”, Andrew has even made a very nice prototype board up to add reset and other bits to the board… but up to now I can find zero documentation because there isn’t any – this is in fact just very early alpha stage software – but apparently an update will appear late tonight – worth keeping an eye out? The new software does not use AT commands, but has a pretty verbose setup… here it is in action when I type help. As you can see, nothing like before. When I asked it to show a list of access points, it showed a disappointing one access point (normally shows 3 or 4) but I’ve no way to understand right now why the discrepancy.  If you’ve figured out how to blow .BIN files into your #esp8266 board you’ve nothing to lose but time by having a look at this to see if it has wings.. and it is Sunday after all. As things stand, the commands are indecipherable to me but then it may be this is some standard I’m not aware of – or maybe I’m just missing the point.

Has anyone else spotted this software (well, you have now)? At least out of this I got the confidence that the Python-based chip blowing software actually works so if nothing else that’s a plus.

As an update, a new set of binaries were uploaded tonight and some instructions – but this loops permanently for me – I’ve been in touch with the author and as soon as I get it working (next iteration hopefully I’ll try some simple TCP/IP socket commands – if this works – could this be an alternative to the buggy AT command set??? Time will tell.

ESP8266 Woes… a Ray of Light

tmp7BABSo I’ve been continuing to test the Espressif (manufacturer) ESP8266-based WIFI module called the ESP-01 and I’m starting to get somewhere with the “busy s” problem. This board is the more common of a few variations of the board and has power, ground, transmit, receive and 4 control lines called GPIO0, GPIO2, CH_PD and RST. The board runs on 3v3 and consumes up to 250ma (note that some of the smaller Arduino-type boards which have 3v3 power supplies internally, cannot supply this much current. Better to use a 3v3 regulator capable of handling much more. I use one on my home-made Arduinos which can handle up to 1 amp.

Some more hardware info – the pins are not 5v tolerant… clearly the output TX can be connected directly to a 5v Arduino input but you need level conversion for output from Arduino to the WIFI board. I use a resistive divider. 560r from the Arduino output to the WIFI input and 1k2 from there to ground. In normal use including programming you only need 2 of these dividers. This fellow gives a lot more info on hardware.

I’ve done some in-depth tests with an Android mobile phone (Samsung S4)  sending commands to the board over a WIFI TCP socket (using NETIO) – and monitored what happens (I use a 1284-based board so I have 2 serial sockets – AWFULLY handy for testing but you could do similar with a bog-standard Arduino). While the phone was sending polling commands constantly, all was working well, until I swapped apps on the phone (or shut it down or had an issue with WIFI signal)  in which case it might only get part way through sending the command.

You CANNOT avoid this happening with WIFI by the very nature of it being wireless, there might be a glitch, might be a lack of signal momentarily, interference etc., there will always be occasions when you lose data.

Rather than recover gracefully, the ESP8266 (I imagine) has a flag set to say it is in mid-command… as it pulls in data. A new command coming in is NOT clearing that flag (this is a sheer guess) and so no matter what you do it will just say “busy s” until you reset. One kind gentleman has added a blanket reset command to the ESP8266 but that’s not the answer as you then have to wait for the reset and set up your modes again – what’s needed is for the designers to fix this bug.

SO yesterday afternoon I wrote to them, not very hopeful as I figured they’d be Chinese and might not even understand what I had to say.

Imagine my delight when this came back from ESPRESSIF  – a lady by the name of Sue Chen….

Dear Sir,

Thanks for contacting Espressif Systems!

This is due to a software bug. We will fix this bug in a software release soon.

Have a great day! Thanks.

Best regards,
Sue Chen 陈思祐

ESP8266 typical pinsThis not only confirms that it IS a bug as I thought – but gives us hope that they will soon sort it out – I’ve asked ESPRESSIF to let me know when the update is available and I’ll be sure to put the info in here (make sure you follow my blog – there’s a “follow my tech blog” blue indicator on the upper right of the blog screen).

In the early hours of this morning, I received another email from them asking for debug info – basically which version I’m using – I told them 0019000902 which is the latest though I’m not sure now if it’s the official latest number, as my version has the AT+XRST command which was added by a third party (detained in this or previous blog items)… which WORKS but really you don’t want to be resetting the unit as it takes too long and happens too often.

tmpC37ESPRESSIF confirmed that the issue is incomplete commands – I suggested that such commands should be quickly timed out… you might even be sending data with AT+CIPSEND=ID,value,data and if it’s a mobile device sending this, it could fail at ANY point… the ESP8266 needs to recover from this rapidly and move on without losing the current mode – this should be simple enough – if I were designing this I’d simply time out commands. So let’s say you are talking to the board at 115k baud, that’s 10k characters a second – let’s say 1k characters a second to be charitable… so if there is a gap of say 1ms or more mid-command, or an unexpected character then the unit should simply wind back and start looking for AT….  I believe this would solve the problem…

I’m getting excited already…I could be using these boards in so many projects…  #ESP8266  #ESPRESSIF #ESP-01

Further back on this blog you’ll see other items on the subject of the ESP8266 as I fumbled my way along with very little info. There is also some technical blogging regarding Arduino and similar on my home blog

There is some code for the ESP8266 on this blog for the Teensy 3.1 …   http://forum.pjrc.com/threads/26873-ESP8266-with-Teensy

Investigating the ESP8266–Serial Killing

The ESP8266 is a potentially revolutionary new, small WIFI module costing under £3 ($4). Revolutionary because it will allow small microcontrollers to interface with the web without a) a costly ETHERNET card, b) a more costly traditional WIFI unit and c) without a costly (in terms of storage) library for Ethernet – which can take up half of, say an Arduino UNO’s FLASH memory.

The ESP8266 units work serially – i.e. you talk to them via serial in and they talk back via serial out. They require +3.3v and ground. Regardless of whether you are using a 5V processor or 3v3, the serial output will work with both – but you may consider a level shifter to talk from the processor to the WIFI board if the former uses 5v. This can be as simple as a resistive divider. I am using just in fact a series resistor – but then – my one and only board doesn’t work properly.

Initial translations and blogs out there suggest you need serial in and out – and SOME of tem suggest you also need to take a pin called  CH_PD to +3.3v. The problem is that there are identical looking boards some of which have that pin and NEED it connecting high – others don’t have that pin.  Check out here and here.

So – most of the common code you see will instruct you that the units need 115,200 baud data – and that you start the ball rolling with a reset command. They usually show the use of the Arduino serial port – sending out the command – and an option I’d never used before to analyse the result.. i.e. Serial.find()

So – armed with my new chip I went off and tried this – everyone in the web is using an Arduino with only one serial port – I prefer the Atmega1284 which is the same but better and has 2 serial ports – so when you see me refer to Serial1.find() you’ll realise I’m talking about the second serial port.

So to start the ball rolling you send this…

Serial1.println(“AT+RST”);

And you get (or I get) this rubbish back if you care to look at it.

OK

Eh? What’s this – that’s not what I SAW – it’s what pasted into this blog. What I SAW was this..

OK

  ets Jan  8 2013,rst cause:4, boot mode:(3,7)tail 12
chksum 0xe0
ho 0 tail 12 room 4
load 0x3ffe8000, len 3168, room 12
tail 4
chksum 0x93
load 0x3ffe8c60, len 4956, room 4
tail 8
chksum 0xbd
csum 0xbd

ready

How can this be? Why can’t I paste the lot?  This happened over and over – the copy and paste from the COM window to Windows Live Writer would not work – I ignored it – software bug.

But herein lies the rub…here’s the code I used…

Serial1.setTimeout(5000);
Serial1.begin(115200); // for debugging
delay(1000);

Serial1.println(“AT+RST”); // reset and test if module is ready
my=millis()+2000;
while (my>millis()) { if (Serial1.available()>0){  Serial.print((char)Serial1.read()); my=millis()+2000; } }

Why on EARTH would the result be spit up like that above…

So – here’s what everyone else is using with a variation, I’m looking for (OK) – others look for “ready” – bear with me..… we’ll not repeat the initialisation code here.

Serial1.println(“AT+RST”); // reset and test if module is ready
if (Serial1.find(“OK”)) Serial.println(“Got OK”);

I’d never used this before.. send the data out and wait 5 seconds OR return if you get the sequence OK.

But – what of the REST of the result.. all that crap that comes after ok? SURELY the find() function must wait SOME time and get rid of it – or is it  going to be sitting there waiting to ambush future checks?

And it gets worse.. because the ABOVE works! But this which others are using, doesn’t.

Serial1.println(“AT+RST”); // reset and test if module is ready
if (Serial1.find(“ready”)) Serial.println(“Got ready”);

How can that be – everyone else couldn’t possibly be wrong – how can they find “ready”?  So I made this combination..

Serial1.println(“AT+RST”); // restet and test if module is redy
if (Serial.find(“OK”)) Serial.println(“Got OK”);

my=millis()+2000;
while (my>millis()) { if (Serial1.available()>0){  Serial.print((char)Serial1.read()); my=millis()+2000; } }

So this time I’d trap OK – and then look to see if there was anything left… and little surprise there. All the stuff following OK came flying into view!!

So I tried this – as the data all comes within a second or so – surely a delay after sending would ensure the whole lot was in the buffer ready for checking?

Serial1.println(“AT+RST”); // reset and test if module is ready
delay(3000);
if (Serial1.find(“OK”)) Serial.println(“Got OK”);

my=millis()+2000;
while (my>millis()) { if (Serial1.available()>0){  Serial.print((char)Serial1.read()); my=millis()+2000; } }

Erm, NO!!

Got OK

ets Jan  8 2013,rst cause:4, boot mode:(3,7

Exactly – by now I was thinking of taking up woodwork… the OK was trapped but not only was some of the stuff left in the buffer – but the text “ready” was missing off the end!! A light bulb turned on… Could some of this  have to do with fact that the Serial buffer in Arduino is only 64 bytes long?? There’s more than 64 bytes here…  So presumably by waiting, I’d LOST the remainder.

Then I twigged – if you’re waiting for “ready” you might never get it if the buffer fills up and does not discard what’s there… and that would account for the result above – how on EARTH are others getting this to work?

Then I remembered something about increasing the default buffer size for serial.

In HardwareSerial.cpp – which is located at  hardware/cores/standard  or in my case as I’m using the 1284 chip and have a special setup for it the file is located under my documents at hardware\mighty-1284p\cores\standard

Sure enough – I increased the size of the SERIAL_BUFFER_SIZE from 64 to 512 bytes (I have 16K Ram on the 1284) and the LOST DATA problem above went away.

But it STILL would not find “ready” – at which point I thought – you know – I’ve invested 512 bytes of RAM and this is getting WAY too messy – I’ve never used .find() before – so it won’t be missed  – I could only assume there must be a special character in there somewhere stopping me finding “ready”

And sure enough – it would find OK but not reset or ANY word after that OK area – maybe a NULL in there somewhere??  I could have checked but life is short.  There had to be a better way. SO I wrote my own… I wanted something that would search for a phrase, waiting a certain length of time – but also waiting after anything ELSE came through until the buffer was truly empty..

Serial1.println(“AT+RST”); // reset and test if module is ready
if (SerialFinder(Serial1,”ready”,3000,300)) Serial.println(“GOT IT!!”);

Spot on!  Now, that still does not account for why my WIFI module won’t work  properly – that may well need another module purchasing to compare with – but I hope that helps others who may well be struggling with this very issue. Here is the function below – just drop it in your code or in a library somewhere  – do what you will with it. It’s simple enough… feed it the string – it will return true or false whether it finds the string or not – but not until the timeout. You could add a parameter to kill the timeout once the string is found – but then – what about anything coming in after then and you can’t just flush the buffer – info may not have yet finished coming in. Seems to me the right option would be to just make the delay “sensible”.  You can of course change from Serial1 to Serial etc (multiple serial does not work if you’re using a humble UNO but the mega has either 2 or 2 UARTS and I DEFINITELY recommend having one for your project and one for monitoring/programming) anyway – here it is.

boolean SerialFinder(HardwareSerial &refSer, char *str,unsigned long howlong,unsigned long timeout)
{
   boolean gotit=false;
   unsigned long mytime;
   char *strtemp;
   char incoming;
   strtemp=str; mytime=millis()+howlong;
   while ((mytime>millis()) || refSer.available()) // if timer demands or there is something there
   {
    if (refSer.available())
      {
       mytime=millis()+timeout; incoming=refSer.read();
       Serial.print(incoming); // for debug
       if (incoming==*strtemp) { strtemp++; if (*strtemp==0) {strtemp=str; gotit=true; } } else strtemp=str;
      }
   }
  return gotit;
}

And so I start again from scratch but at least this time knowing my searches work… and so it begins..

Serial1.begin(115200);// talking to WIFI
Serial.begin(115200); // for monitoring
delay(1000);
Serial.println(“Initiating with AT+RST”);
Serial1.println(“AT+RST”); // restart module
if (SerialFinder(Serial1,”ready”,2500,200)) Serial.println(“Good”); else Serial.println(“Nope!”);