Mega with ESP-01 v WeMos D1 Mini

We have 2 identical sketches with the exception of the libraries and connection details for a Mega (with ESP-01 shield) and a WeMos. We have 2 identical dashboards with separate tokens, one for the Mega and one for the WeMos.

WeMos run perfectly, Mega is a nightmare. ESP-01 has separate 1.2A power supply.

The debug for the Mega shows constant Cmd Skipped and Cmd error messages and reconnects to the server perhaps every minute.

The Cmd skipped messages cover instructions that are sometimes accepted and at others they are skipped. These are the instructions being accepted:

<vw 0 p 0 0 21.1 C
Temperature is now 21.1 deg C
Time is 23:03:27
[58695] <msg 20,7,28
<vw 0 p 0 1 Time is 23:03:27
[59103] <msg 20,9,9
<vw 7 23:03
[59512] <msg 20,9,9
<vw 6 21.1

V0 is LCD, V6 and V7 are Value Displays.
Next time around the loop the instructions are skipped.

I haven’t worked out what the Cmd errors are but the WeMos has no errors so I’m ruling out an issue in the sketch itself.

I did notice when I created the identical dashboard for the Mega one of the Value Displays wasn’t being updated at all. In the end I had to delete the Value Display and recreate it, second time around it was fine but it appears the Blynk server doesn’t always correctly register the widgets you create.

So why is the WeMos working fine and the Mega working dreadful with fundamentally the same sketch?

Could be many reasons, but the first thing I’d suspect is the ESP. I am very hesitative (is that even a word?) to use the ESP as shield. I had very bad experiences with it. I use it either standalone or not. Could be the Mega’s serial interface or just the combination of both. After all, they weren’t made for each other whereas, I hope, the Wemos has good interaction with all it’s components (I ordered one, so we’ll see, lol).

What is the serial speed you are using? If you use a Mega clone it could be a faulty/fake FTDI chip I think. Have you tried with a Nano? I believe they use different (CH340 if I’m not mistaking) serial chips.

@Lichtsignaal you might be right about ESP’s being generally bad shields. We have 4 or 5 ESP-01’s working in standalone and they are fine. I need to check the circuits of these as I’m pretty sure they are running at 5V and they are fine.

It is a genuine Mega. When I have time I will try the same sketch on a genuine Leonardo and then on one of the many Nano clones we have.

I decided some time ago that WeMos was the way to go and we are expecting 30 more from China in the next few days. However we have come up with a problem with the WeMos where the analogue readings are not as accurate as we require (out by 10%) so we were considering moving back to Nano’s with ESP-01’s.

We are using 115,200 baud for the Mega.

I just did a quick search and there are some integrated products of Esspressif which adhere to the Wi-Fi alliance certification program, but the ESP-xx is probably not on that list. It lists some Android TV things and a a home domotic thing. Wemos is also not on that list.

This basically means there is no guarantees whatsoever that either of the two products will follow official Wi-Fi standards. Since there are a couple of things you have to do, for example WPA2 Enterprise (username/password ID wifi networks) which neither can do I think because the platform isn’t fast enough for the encryption part.

So, there you have at least one reason not to sell integrated solutions with these chips. To be honest, I haven’t checked it before because I still see this as a home solution and not something to be commercially sold.

Anyway, back to the stuff at hand, is there a reason why the Wemos is not accurate enough? Isn’t an idea to try and fix that problem? Assuming you guys already haven’t put in some time. Maybe try and use some filters to get better results from analog sensors?

@Lichtsignaal are you familiar with the Steinhart formula for resistance to temperature?

The D1 (full and mini) uses a voltage divider on the analogue port changing the ADC voltage range from 0 to 1V up to 0 to 3.2 V (R1 220K and R2 100K) .

Normally we have a 10K resistor between V and A0 and the thermistor probe between ground and the A0 end of the 10K resistor.

On a regular Arduino the Steinhart formula for resistance to temperature works fine with the 10K resistor in place but not on the D1. Will the D1 voltage divider affect the formula used in the Steinhart equation? If it does affect the formula which part will we need to change and with what figures based on the D1 R1 220K and R2 100K?

It seems only logical to me that if in a formula the variables change, inevitably the outcome changes. I’m not familiar with that specific formula, but apparently the Wemos and Arduino behave differently in the sense of the analog port. What exactly is this formula? Isn’t it possible to change the resistors on the Wemos to different ones?

@Lichtsignaal the Steinhart formula simply starts with a resistance pair formula. Basically if you know the resistance of R1 then you know the Resistance of R2.

We have contacted WeMos to advise the following margin of errors on 3 of the Mini’s we tested yesterday. R1 10050 and R2 9920 with Mini providing the results for R2 the readings from the 3 Mini’s were:

  1. 8798 margin of error 11.3%
  2. 9079 margin of error 8.5%
  3. 9114 margin of error 8.1%

These results tie up with the double digit margin of error we obtained when using the 10K NTC 3950 thermistor as R2.

@Costas, Sorry for the bump but I have been using Steinhart-Hart in a recent project and I’m have good success using this approach. Not sure this applies in your case, but you need to be sure of a few things:

  1. The value of the series resistor needs to be the average of your probe’s nominal resistance.
  2. If you are using an ADC that is sensitive to high impedance (like an MCP3204) you need to buffer the inputs (e.g. unary amplification op-amps)
  3. You should have a small cap (say 47pF) in parallel with the series resistor to smooth out the input.
  4. You can improve accuracy by measuring the actual resistance of the series resistor and using the exact value vs the labeled value.
  5. Accuracy is also improved by deriving the calibration coefficients (A, B, C in the equation) for your particular probe.

An excellent guide to getting S/H to work can be found here: https://learn.adafruit.com/cloud-thermometer/hardware

Hope this helps. Apologies in advance if this is not new/helpful for you.

RD7

1 Like

@Rom3oDelta7 thank you for your feedback on Steinhart-Hart. The guide we have always used is an older Adafruit guide at https://learn.adafruit.com/thermistor/using-a-thermistor

The guide you referenced brings things more up to date with the inclusion of ioT.

It is noticeable that both guides are using Arduinos rather than ESP’s to obtain the analogue data. The guide we use also refers to using the ‘more stable’ 3.3V REF voltage on the Arduinos rather than the 5V supply.

Not sure we noticed much difference between 5V and 3.3V when we last tested it. What we found is analogue data capture appears to be one of the few areas where ESP’s don’t perform as well as the Arduinos.

Are you using ESP’s for analogue data capture?

No, the analog port on the ESP is pretty much worthless IMHO. At 1.0V max it even needs at least a voltage divider to even work. As I mentioned in the previous post, I use an MCP320x 12-bit ADC that in this particular thermistor application also requires an LM324A op-amp to convert the high impedance (> 100k!) thermistor network input to low impedance. Without it, the reading returned from the ADC is off by about 0.2V skewing the temperature by ~20 degrees F. I also had to modify a very old MCP320x SPI library and ended up just rewriting it.

Eventually, I will release everything as an open source project:

  • Blynk interface
  • Sketch
  • MCP320x library
  • Eagle .sch and .brd files and parts library
  • 3D design for the enclosure

However, still need to work out a few more Blynk issues - it is currently alternately connecting and disconnecting. I even rolled back to the version I had working yesterday and it does the same thing. Perhaps a server problem. Guess I need to get around to putting Blynk on my Linux server …

RD7

@Dmitriy could you perhaps move this thread to the Need Help With My Project section as it is not really an issue with Blynk, more a comparison between Arduino and ESP performance.

@Rom3oDelta7 I use the term ESP to include boards that contain ESP’s so there are at least 2 suppliers that have analogue ports with built in voltage dividers to take the 1V up to 3.2V. One supplier informed me he copied the voltage divider circuit from the other supplier which wasn’t a wise move as IMHO they are now both using the wrong resistors. A slight change would have taken the 3,2V up to 3.33V and then the analogue port would actually function as intended.

One of our systems is currently using the analogue port on an ‘ESP board’ to check the battery voltage and notify us (via Blynk) when the batteries need recharging. We use our own voltage divider to cover 18650 batteries up to 4.3V on full charge and the accuracy of the analogue port is good enough for this purpose.

As you indicate not accurate enough for Steinhart-Hart stuff though.

1 Like

For measuring battery voltage I think a resistive voltage divider is fine. If you’re instead dealing with high frequencies you’ll get some phase delay. Again, may or may not be OK, but it does limit the general applications. And the biggest issue for me is there is one 1 analog port.

RD7

@costas I know this thread is a little old - I’m assuming the accuracy of A0 on all Wemos have the same issues ? I’m thinking of using an external ADC e.g. ADC1115 which will give me more Analog ports and I assume very good accuracy - do you have any experience with any external Analogue boards ?

Hi @mars,

See below:

Regards

@mars I haven’t used any external ADC boards but if you require several analogue ports then the ADC1115 should be fine.