ESP8266 – DHT11 issue

I have recently run into issues with the DHT11. It turns out that the issue is the time that a call to pinMode takes in the DHT11 library. In a small program pinMode returns as fast as 2.5-5 microseconds. In my large program it can take as long as 37 microseconds!!! This causes the code to overrun the timing at the start of the sequence when telling the DHT11 to start sending data. A call to expectPulse(LOW) finds that the line has already gone high and returns 0 immediately. The mainline code interprets this as a timeout (which also returns 0 from expectPulse()).

My initial response was to edit the code to change some of the timings but it was hard to make it correct for both the small program (fast execution) and large program (slow).

However, I recently discovered that the ESP8266 has fast instruction RAM (IRAM) and slower flash storage. I suspected that the routines are being pushed out of IRAM & consequently slowing down quite badly. So I modified the DHT.CPP to include a directive to ensure that the two timing critical routines (DHT::read and DHT::expectPulse) were both run from IRAM…

CODE: SELECT ALLboolean __attribute__((section(".iram.text"))) DHT::read(bool force) { ...
and
uint32_t __attribute__((section(".iram.text"))) DHT::expectPulse(bool level) {...

So far, no more problems! :)

 

Post-script to my previous post – Whilst the code above does seem to fix the problems with the DHT11, it doesn’t restore the timing of the pinMode function to the fastest that I’ve seen (2.5 microseconds). It takes it down to about 16 microseconds which is fast enough to fix the problem.

I’m not entirely sure why pinMode is so slow, except that I’m using the paho PubSub client and the slow down is definitely connected with subscribing to topics. Whether this pushes some code out of the fast memory, or if there is some interaction going on, I don’t know. But if I remove all but one subscription call – 2.5 microseconds again!!

Odd.

I have been running an ESP8266-01 with a DHT11 for several weeks continuously with no problems, using teh library with the 3rd option DHT dht(DHTPIN, DHTTYPE, 15); but not sure if that made a difference.
Now I am trying to use a DHT11 on a Wemos D1.
Did nt use the 3rd option so just DHT dht(DHTPIN, DHTTYPE);
That worked without problems till I started adding to the program, making it slightly bigger. Then most of my readings failed (someone else in this thread described that too). It is OK in the first reading after start, but then the majority fails. Adding parameter ’15’ did not make a difference. When I run the slightly smaller program again…. works like a charm, bigger one doesnt

JayEmSydney wrote:……

However, I recently discovered that the ESP8266 has fast instruction RAM (IRAM) and slower flash storage. I suspected that the routines are being pushed out of IRAM & consequently slowing down quite badly. So I modified the DHT.CPP to include a directive to ensure that the two timing critical routines (DHT::read and DHT::expectPulse) were both run from IRAM…

CODE: SELECT ALLboolean __attribute__((section(".iram.text"))) DHT::read(bool force) { ...
and
uint32_t __attribute__((section(".iram.text"))) DHT::expectPulse(bool level) {...

So far, no more problems! :)

That helped indeed a lot. Before maybe 1 out of 50 readings would NOT generate a failed to read error, and after your change about 1 out of 20 WOULD generate an error. Still not ideal, but a lot better

– See more at: http://www.esp8266.com/viewtopic.php?f=32&t=4210&p=57237#p57237

ESP8266 – DHT11 issue was last modified: July 13th, 2017 by Jovan Stosic

hard reset (un-plug USB on Wemos D1) reboots into configuration mode · Issue #64 · marvinroger/homie-esp8266 · GitHub

…but clicking the reset button on the D1 boots back into normal mode. Is this expected behaviour? Tried with two different D1s, same thing.

As soon as I unplug the USB cable and re-connect, the device goes back into configuration mode.

@marvinroger

Owner

This is not an expected behavior. I guess the USB is connected to a computer, can you try with a charger?
@jpmens

Contributor

@sumnerboy12 I’ve just checked for you with the Homie version I’m running (Github pull pre 1.3.0): works as advertised, i.e. I can cold-boot (also via USB) and device starts publishing.
@jpmens

Contributor

@sumnerboy12 it just occurs to me that I didn’t configure via WiFi, instead preferring to write the config directly to the file system. (Note the commented SPIFFS.format() which you might need to uncomment.)

https://gist.github.com/jpmens/d674114400c1dd7ba169403afb7d1ea1

@marvinroger

Owner

@jpmens if configuring via the API is successful, then the FS is in the exact same state as if it was written directly during flash or using your sketch, so this should not be the issue here.
@marvinroger

Owner

Can you also post the debug output on the Serial monitor? There should be a message like ✖ Cannot mount filesystem.
@dholmen

I’ve had the same problem with at least one of my NodeMCU’s. There are no error messages in the serial monitor, it just looks like a normal config mode boot.
@sumnerboy12

Yes same here – there is nothing appearing on serial when it reboots
into configuration mode. I will need to have more of a play this
evening, but it is good to know this is not expected behaviour. I will
endeavour to do some more digging and report back here.

On 15/04/2016 9:00 AM, dholmen wrote:

I’ve had the same problem with at least one of my NodeMCU’s. There are
no error messages in the serial monitor, it just looks like a normal
config mode boot.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#64 (comment)

@marvinroger

Owner

The configuration mode is started when the Config.load() method returns false. If you look at the sources, you will see that everywhere false is returned, there is a log message, I don’t see any codepath where this would not be the case. I might be wrong!
@sumnerboy12

after some debugging with @jpmens we discovered this was caused by Windows it seems – as soon as I unplug/re-plug the Wemo into my Windows laptop it resets the device back into config mode – if I flash the Wemo, un-plug and plug into a wall wart, it boots up fine. This can be repeated with no issues.

As soon as I plug the Wemo back into my Windows laptop, it is reset and reverts back to config mode.

Very odd, but I don’t think this is a Homie issue so I will close this issue.

@jpmens

Contributor

I’m confident @marvinroger knows a tonne more about these devices than we do, and can maybe say whether he’s encountered similar resets with Windows and/or whether it’s a known Windows driver issue.
@marvinroger

Owner

WeMos D1 boards embed a CH340G USB serial chip. I have a NodeMCU v2, which embeds a CP2102 chip, and I had this problem once or twice, so it is way more stable.

Maybe try to install this driver, if not already done. I am sorry, I can’t help more on this! But yes, definitely not an Homie issue.

@sumnerboy12

updating to that driver seems to have resolved it – thanks a million @marvinroger!!!
@marvinroger

Owner

Awesome! You’re welcome!
@DavidStacer

I had this problem too on a Wemos D1-mini. Updating the driver did not solve it.

To diagnose this and see all the message, I connected up another USB serial port adapter. Then connected the RX from the second serial board to the D1-mini TX pin and tied GND to the serial board. I then used Termite terminal program to monitor the serial traffic.

I changed the default Homie baud rate to 74880 – that is ESP8266 default boot baud rate. This allowed me to see the ESP8266 boot up messages too.

Now I could see all of the messages. When I pulled the main D1-mini USB cable and plugged back in, the majority of the time I would see:
• SSL: no
• OTA
• Enabled: no
Flagged for reset by pin
Device is in a resettable state
Configuration erased
↻ Rebooting in config mode

My theory:
When pinMode(this->_interface->reset.triggerPin, INPUT_PULLUP); is executed, the onboard D1-mini USB Serial adapter may not let the GPIO0 pin go high right a way. If you look on the D1-mini schematic, the RTS is connected to the GPIO0 pin via resister and NPN transistor. I’m speculating that the PC driver needs to give it a command to change (high or low don’t know which).

Placing a delay(50); after the Homie.setup() and before the Homie.loop(); seemed to solve the problem too but I didn’t like that as a solution.

Looking much deeper into the bounce code for the switch I found the default state is set to 0 meaning the switch is closed – requesting configuration mode. In Bounce::attach I changed it to be state=1; as the default.

I have cycled the D1-mini with the USB cable many times and it seems to have fixed the problem of going into configuration mode without pressing and holding the switch.

@marvinroger

Owner

@DavidStacer so what can I do at Homie’s level? There is no way to programmatically set the default value of the state in Bounce2. So changing this line to state = 1; fixes the issue for you?

Maybe I can add this in the in troubleshooting in the docs?

@DavidStacer

Changing that line did fix it for me because Bounce attach() sets the default to 0 but 1 would be a better default for this application.

When _handleReset call is made to _resetDebuncer.read() it just returns the current Bounce::read() value. The current state is still low because update() has only been called one time, so we really are not getting a debounced reading but just the initial reading.

I think its hard to fix in Homie but maybe don’t call the _resetDebuncer.read() until the DEFAULT_RESET_TIME has passed since boot up but that is just another way of delaying. I guess we are delaying the time before getting the switch value vs. holding up the rest of the program.

I will test out that idea and see if it works.

@clough42

Contributor

I was having a similar problem and came across this issue. The solution wasn’t immediately clear, so I’m summarizing to help others who also get here and are confused:

If your WeMos D1 Mini loses its configuration when you plug it into your computer with USB, it is probably erroneously detecting the RTS/DTS wiring in the WeMos as a request to reset and delete the configuration.

You can disable the reset trigger completely with Homie.disableResetTrigger() and it will stop deleting the config. If you want the reset trigger behavior, you may be able to move it to another pin. I have not attempted this.

@NikosVlagoidis

I have the same problem but only whenever i plug it on my power bank. the problem occurred after many uses of the power bank. any thoughts?
@NikosVlagoidis

actually Homie.disableResetTrigger() worked for my pc the first time but now does not work anywhere and i don’t know what to do

Source: hard reset (un-plug USB on Wemos D1) reboots into configuration mode · Issue #64 · marvinroger/homie-esp8266 · GitHub

hard reset (un-plug USB on Wemos D1) reboots into configuration mode · Issue #64 · marvinroger/homie-esp8266 · GitHub was last modified: July 13th, 2017 by Jovan Stosic

glTF

glTF (GL Transmission Format) is a runtime asset delivery format for GL APIsWebGLOpenGL ES, and OpenGL developed by the Khronos Group 3D Formats Working Group and first announced at HTML5DevConf 2016. glTF is an efficient, interoperable asset delivery format that compresses the size of 3D scenes and models, and minimizes runtime processing by applications using WebGL and other APIs. glTF also defines a common publishing format for 3D content tools and services.
https://en.m.wikipedia.org/wiki/GlTF

glTF was last modified: September 25th, 2017 by Jovan Stosic

Suspicion (1941)

Directed by Alfred Hitchcock. With Cary Grant, Joan Fontaine, Cedric Hardwicke, Nigel Bruce. A shy young heiress marries a charming gentleman, and soon begins to suspect he is planning to murder her.

Source: Suspicion (1941) – IMDb

Suspicion (1941) was last modified: September 25th, 2017 by Jovan Stosic

Understanding Metering and Metering Modes

Understanding Metering and Metering Modes

Every modern DSLR has something called “Metering Mode”, also known as “Camera Metering”, “Exposure Metering” or simply “Metering”. Knowing how metering works and what each of the metering modes does is important in photography, because it helps photographers control their exposure with minimum effort and take better pictures in unusual lighting situations. In this understanding metering modes article, I will explain what metering is, how it works and how you can use it for your digital photography.

When I got my first DSLR (Nikon D80), one of my frustrations was that some images would come out too bright or too dark. I had no idea how to fix it, until one day, when I learned about camera metering modes.

1) What is Metering?

Metering is how your camera determines what the correct shutter speed and aperture should be, depending on the amount of light that goes into the camera and the sensitivity of the sensor. Back in the old days of photography, cameras were not equipped with a light “meter”, which is a sensor that measures the amount and intensity of light. Photographers had to use hand-held light meters to determine the optimal exposure. Obviously, because the work was shot on film, they could not preview or see the results immediately, which is why they religiously relied on those light meters.

Today, every DSLR has an integrated light meter that automatically measures the reflected light and determines the optimal exposure. The most common metering modes in digital cameras today are:

  1. Matrix Metering (Nikon), also known as Evaluative Metering (Canon)
  2. Center-weighted Metering
  3. Spot Metering

Some Canon EOS models also offer “Partial Metering”, which is similar to Spot Metering, except the covered area is larger (approximately 8% of the viewfinder area near the center vs 3.5% in Spot Metering).

You can see the camera meter in action when you shoot in Manual Mode – look inside the viewfinder and you will see bars going left or right, with a zero in the middle, as illustrated below.

Nikon Viewfinder

If you point your camera at a very bright area, the bars will go to “+” side, indicating that there is too much light for the current exposure settings. If you point your camera at a very dark area, the bars will go to the “-” side, indicating that there is not enough light. You would then need to increase or decrease your shutter speed to get to “0”, which is the optimal exposure, according to your camera meter.

A camera meter is not only useful for just the Manual Mode – when you choose another mode such as Aperture Priority, Shutter Priority or Program Mode, the camera automatically adjusts the settings based on what it reads from the meter.

1.1) Problems with Metering

Camera meters work great when the scene is lit evenly. However, it gets problematic and challenging for light meters to determine the exposure, when there are objects with different light levels and intensities. For example, if you are taking a picture of the blue sky with no clouds or sun in the frame, the image will be correctly exposed, because there is just one light level to deal with. The job gets a little harder if you add a few clouds into the image – the meter now needs to evaluate the brightness of the clouds versus the brightness of the sky and try to determine the optimal exposure. As a result, the camera meter might brighten up the sky a little bit in order to properly expose the white clouds – otherwise, the clouds would look too white or “overexposed”.

What would happen if you added a big mountain into the scene? Now the camera meter would see that there is a large object that is much darker (relative to the clouds and the sky), and it would try to come up with something in the middle, so that the mountain is properly exposed as well. By default, the camera meter looks at the light levels in the entire frame and tries to come up with an exposure that balances the bright and the dark areas of the image.

2) Matrix / Evaluative Metering

Matrix Metering or Evaluative Metering mode is the default metering mode on most DSLRs. It works similarly to the above example by dividing the entire frame into multiple “zones”, which are then all analyzed on individual basis for light and dark tones. One of the key factors (in addition to color, distance, subjects, highlights, etc) that affects matrix metering, is where the camera focus point is set to. After reading information from all individual zones, the metering system looks at where you focused within the frame and marks it more important than all other zones. There are many other variables used in the equation, which differ from manufacturer to manufacturer. Nikon, for example, also compares image data to a database of thousands of pictures for exposure calculation.

Matrix Metering

You should use this mode for most of your photography, since it will generally do a pretty good job in determining the correct exposure. I leave my camera metering mode on matrix metering for most of my photography needs, including landscape and portrait photography.

3) Center-weighted Metering

Using the whole frame for determining the correct exposure is not always desirable. What if you are trying to take a headshot of a person with the sun behind? This is where center-weighted metering comes in handy. Center-weighted Metering evaluates the light in the middle of the frame and its surroundings and ignores the corners. Compared to Matrix Metering, Center-weighted Metering does not look at the focus point you select and only evaluates the middle area of the image.

Center-weighted Metering

Use this mode when you want the camera to prioritize the middle of the frame, which works great for close-up portraits and relatively large subjects that are in the middle of the frame. For example, if you were taking a headshot of a person with the sun behind him/her, then this mode would expose the face of the person correctly, even though everything else would probably get heavily overexposed.

4) Spot Metering

Spot Metering only evaluates the light around your focus point and ignores everything else. It evaluates a single zone/cell and calculates exposure based on that single area, nothing else. I personally use this mode a lot for my bird photography, because the birds mostly occupy a small area of the frame and I need to make sure that I expose them properly, whether the background is bright or dark. Because the light is evaluated where I place my focus point, I could get an accurate exposure on the bird even when the bird is in the corner of the frame. Also, if you were taking a picture of a person with the sun behind but they occupied a small part of the frame, it is best to use the spot metering mode instead. When your subjects do not take much of the space, using Matrix or Center-weighted metering modes would most likely result in a silhouette, if the subject was back-lit. Spot metering works great for back-lit subjects like that.

Spot Metering

Another good example of using spot metering is when photographing the Moon. Because the moon would take up a small portion of the frame and the sky is completely dark around it, it is best to use Spot metering – that way, we are only looking at the light level coming from the moon and nothing else.

Some DSLRs like the Canon 1D/1Ds are capable of multi-spot metering, which basically allows choosing multiple spots to measure light and come up with an average value for a good exposure.

5) How to Change Camera Metering Mode

Unfortunately, this varies not only from manufacturer to manufacturer, but also from model to model. On the Nikon D5500, for example, it is done through the menu setting (Info button). On professional cameras such as the Nikon D810 and Nikon D5, there is a separate button on the top left dial for camera metering. Changing metering on Canon cameras also varies from model to model, but generally it is done through a key combination (“Set” button), camera menu or a dedicated metering button close to the top LCD.

Source: https://photographylife.com/understanding-metering-modes

Understanding Metering and Metering Modes was last modified: September 10th, 2017 by Jovan Stosic