Mysterious Combustion
My Mosquito Magnet Defender has been unreliable in so many ways, most of which I have fixed. However, a remaining issue has me stumped. After a period of normal operation which could last an hour or days, the combustion temperature inexplicably rises a bit, then falls to around 70-80°C. Prior observations found that the trap does not catch any mosquitos running at those low temperatures, but does catch thousands at its normal temperature of 110-120°C.
Yesterday, after the trap failed, I experimented a bit with the Add-On controller commands to see if I could recover, and if I could trigger this misbehavior.
The Mosquito Magnet Defender IOT Add-On reports about 19 different measurements or parameters once per second. See Status Report. The most important of them are displayed in the above graph (click to see larger), which displays almost a full day’s operation. The most important value is the combustion temperature measured by the thermistor (top trace), which is glued to a thermally-insulated rod of metal that is inserted into the combustion exhaust after the catalytic converter. This rod takes several seconds to conduct heat from inside to the thermistor. Both the original controller and the Add-On make all their decisions based on the measured temperature and elapsed time.
The graph shows a combustion start up with the temperature rising to 120°C, peaking at 123°C, then dropping to 80°C. It worked normally for only about 10 minutes. After checking the trap, I restarted it at 14:47 and it ran until 17:26 when it did the same thing. Thoroughly irritated, I ran a series of tests to see how the trap could be recovered, and what might trigger the problem (see below). At 22:26, I used gas off and ignition on commands to successfully restart combustion, which ran normally until 23:33 when it peaked and dropped again. It ran in this state until the temperature cooled below 70°C, which was the programmed low temperature limit. The trap then entered a fault condition, where it stayed until 9:04 the next morning, when I used the web page to reboot it. I set the under and over temperature limits to 40°C and 161°C in preparation for even more testing later.
(Click to see larger.) During the testing, I turned on the igniter for 99 seconds, then turned off the gas for 5 seconds to exercise the valve, perhaps flex the regulator, or disturb some weird combustion mode. That was successful in restarting the trap, which reached 115°C. I then experimented with stopping the gas for 5, 9, 15, 20, and lastly 30 seconds. While the gas was off, the temperature held steady, which is to be expected because of the thermal inertia of the temperature probe bar. After the gas came back on, the temperature still held steady, which implies that something is hot enough to reignite the propane, or that combustion never stopped. However, after the 30 second interruption, the temperature started to rise after about 25 seconds, climbing to 140°C and beyond, at which point the controller detected an over temperature condition, and restarted the cycle, which turns off the gas and cools the chamber to the start temperature. I don’t know how high the temperature might have gone without that intervention by the software. At 18:48 I gave an MMlow command to restart the ignition, and the trap recovered going down to 84°C then back up to 112°C, where it stayed until 19:45, where it peaked and dropped again.
Perhaps the trap should let the temperature rise even higher at which point the combustion weirdness mode might correct itself. However, the NodeMCU has a certain rated temperature range, and I don’t want to get too close to the high temperature limit. However, these recent field failures showed only a very modest 2-3°C temperature increase before dropping, so the over temperature limit was not a factor here.
The 30 second gas shutoff experiment yielded unexpected results that mirror the phenomena seen in the past. How could shutting off the gas flow, then restoring it, cause this to happen? Perhaps there is some funny combustion mode that causes the propane to burn inside the catalyst cylinder instead of the front chamber, putting the hot part of the flame on the thermistor probe. Or maybe the flame is just burning hotter somehow. But how and why?
How can I figure this out? What sort of instrumentation do I need? I cannot just open the chamber and look in. Before installing another 5 or so temperature probes, defacing the trap, I should to eliminate other possible causes. The most obvious cause might be a problem with the gas feed from the ancient regulator. Of course, replacing the regulator would be the obvious step here, but the catch is that the original Mosquito Magnet regulator is an adjustable low pressure regulator, and I do not have the specs for it. The low pressure regulators I can find today are fixed pressure at 11 water column inches. This may be Ok, or maybe not. So now I need a way to measure low gas pressures 1) to see what the original regulator does, and 2) to measure the pressure during operation. My sports gauge is fine for basketballs and footballs, but not sensitive enough to measure 11 wci (1 psi = ~27 wci).
So I ordered some parts, in particular a barometric gauge which will measure absolute pressure. I haven’t bothered to check whether it will be sensitive enough, or too sensitive, because I am working from the hobbyist perspective of “what I can get” rather than “what I must have.” I can hardly wait to mount this device in some sort of sealed bag or balloon, attach it to the trap’s Schrader valve (dangerous!), run wires into the controller, and add additional software to measure and report the pressure. Wish me luck, or at least, a speedy recovery!
Additional Software
So now we want to add a pressure sensor? And what about the helpful propane tank weighing device? And the alive mosquito detector? And the Real time clock? And real pulse width modulation for the fan, perhaps to control combustion temperature? All of these functions take RAM memory, which is very limited on the Add-On’s NodeMCU Lua environment.
The good news is that, as a result of the Add-On Construction Details project, I have finally tried using the new so-called “LFS” system for running Lua code from the flash memory instead of RAM, and the results have been amazingly good. The current software running on the new system has ~35kb of free RAM where it has only ~11kb on the old. These are very small numbers, but the NodeMCU is a very small system. It feels like such a victory, it overshadows the problems in my Defender, at least for the moment. The new system is so much better, it makes up for the trouble it took to set up my own Lua environment build system, although that was not really necessary, as I could have used on-line tools to accomplish the same result. But now, I have the conceit that I am a master of my own destiny, which is good to have now and again.
All this means, the construction details wiki page needs more updating, and the progress percentage should be reduced, but of course that never really happens, and is part of the reason why the last 10% of a project takes nearly forever.