I had something similar happen in one of my ESP8266 projects (also running MicroPython). What I wound up doing was, every five wall clock minutes (maybe a bit sooner than that, for your case) I had my firmware do a local_networks = wifi.scan() just to exercise the wifi functionality. If that failed I have the code do gc.collect() followed by sys.exit(1), which causes the 8266 to reboot automatically.
Do you have any idea, what’s causing the issue? Is it specifically the scanning part that’s relevant here? I’m starting/stopping wifi each minute, so the chip shouldn’t just idle around all the time.
No, I don’t. My best informed guess is that the wifi connection’s state machine gets stuck once in a while, it misses a couple of packets, and then sits there doing nothing. So, by kicking it a little it doesn’t get a chance to freeze up.
I “kind of” solved at least parts of the problem by simply not turning wifi off. It’s more stable than before, but not stable as such.
Edit: I played around a bit and I think the problem is somewhere in the power supply. My workbench PC can drive the board just fine for hours, just plug it into the USB port, connect serial monitor and let it do its thing. However, if I’m plugging it into my router or a usb power supply, it stops working after a while again.
My theory is, that the PSU/router thinks the device is dead, because it draws too little power? That would explain, why not shutting down wifi improves the stability - it draws more power.
Now, that is just my naive theory, I’m not entirely sure, how to validate it. Maybe I’ll just add a useless busy-loop to increase power draw or add some power consuming components.
Perhaps slightly adjust your logic a little and see what it does.
Read from the sensors first, then enable and connect to wifi, send the data, then disconnect. That would reduce the maximum power draw as only one function is active at once.
Small edit: I have a MagTag ESP32 board with circuitpython that can’t read onewire devices while the wifi is active. Whether that’s because of supply instabilities when wifi is transmitting, or interrupt conflicts, or just plain poor programming in the onewire drivers or the wifi drivers, I don’t know. But reading the devices first and then connecting to wifi and sending the data afterwards works.
Hmm I’m not sure of the pin drive currents on the Pico, but can you power the sensors off a pin? At least then you can programmatically power cycle them if you need to.
The Pico also has a watchdog, you could set it up to give it a reboot if things don’t respond in time. It doesn’t solve the issues of course but at least it gets it back to a workable state. And if the watchdog fails, or it works but there’s still no USB serial, then that would point towards power instabilities or somesuch.
can you power the sensors off a pin? At least then you can programmatically power cycle them if you need to.
Not really, at least I wouldn’t really know how. The sensor needs +3V, GND and two data pins, and the pico only has one 3V out, that seems to connect directly to the voltage regulator. I guess, I could try to use a GPIO pin as a switchable 3V out, but that seems rather hacky.
The Pico also has a watchdog, you could set it up to give it a reboot if things don’t respond in time. It doesn’t solve the issues of course but at least it gets it back to a workable state
Unfortunately, a simple machine.reset() seems not to be enough. I didn’t use “real” watchdogs, but what a Java dev knows: try/catch. I wrapped the entire loop in a try/except block and simply call machine.reset() if something goes wrong. That does work sometimes, but not always. Of course the possibilities are a) some exception isn’t getting caught b) there is some electronic issue, maybe the SPI interface to the DHT is “stuck” or not properly reset. I can resolve the problems by completely disconnecting the device for a while from power.
Do you have a pull up on the DHT20? If not that could explain the reliability issues. 4.7k is needed according to the datasheet.
Not too familiar with the RPi Pico but you might need to disable the internal pull ups if you do that but they are likely too weak so I wouldn’t rely on them.
To avoid signal conflicts, the microprocessor (MCU) must only drive SDA and SCL at low level. An external pull-up resistor (for example: 4.7kΩ) is required to pull the signal to a high level. The pull-up resistor has been included in the I/O circuit of the DHT20 microprocessor.
This sounds to me like it’s already present in the package? I also haven’t seen any tutorial using any resistors (though that may be just an “error” made by all of them to keep it simple).
Yeah on that specific board it looks like it’s included . I was just going from experience. I just wired such a sensor to an Arduino the other day and I was having problems without the pull up. I was seeing garbled data packets on the data line.
edit: you can easily confirm this by measuring the resistance between VCC and Data on the sensor.
You could connect the LEDs in 5 strings of 6 parallel LEDs, each string with it’s own 100 ohm resistor. You will need a significant amount of voltage for that, at lest 7x the threshold voltage of the LEDs
AA batteries can supply plenty current, the question is for how long.
You need about 1.3 Watt for 30 LEDs (I’m assuming 15 mA, 3V). A rechargable AA battery has about 2.4 Wh according to Wikipedia, so 6 AA batteries will last you 2.4Wh * 6 / 1.3W = 11 hours.
I have no idea how curing works, but 1.3 Watt feels very low. That amount of power is fine for visual lighting, or for signals (turn on a TV), but energy wise it’s very little.
Do you have a datasheet/part number for the LEDs, or at least a picture and diameter?
Because battery voltage reduces over time, the LEDs will get dimmer as the battery drains fairly quickly. If possible, running it off a mains plugpack (e.g.12V like for a router or external hard drive) would be good.
An example UV LED has a forward voltage of nominally 3.7V. Two in series on a 12 (8x1.5V) supply gives us 12V-(2x3.7V) =4.6V to drop across the resistor. We want ~15mA, so need a very roughly (V/I =R) 4.6V/0.015A=300 ohm resistor.
When the battery is nearly discharged, at 1.1V/cell it will be 8.8V, giving 1.4V across the resistor and V/R=I 1.4V/300ohm= 4.7mA.
So you would connect each pair of LEDs as:
BAT+ RES +LED- +LED- -BAT all in series. Like this.
You’ll need another 10 300 ohm resistors for 15 total, one per pair of LEDs.
You can get small project enclosures to put them in. Some PVC pipe and end caps could also work.
I would probably just use some good quality, adhesive heat shrink if they are out of the way though.
Adding on to this line of thinking, maybe a thin plastic tube and epoxy to encase it with the solder joints. (Bonus points for using thermal epoxy, since it is a resistor after all.)
I have seen Bigclive on YouTube encase resistors and a diode rectifier in standard epoxy for use in lighting, so heat probably won’t be an issue now that I think of it.
To fool the computer into not throwing an airbag light and disabling all the airbags. I have an early 00s car that swings double duty as street car and track car and when I pull the driver’s seat out for a race seat, the airbag light shows up. Then I go through a rigamarole to reset the light once everything is swapped and plugged in again. It’s a common mod, but just people usually cut up the harness. I’d like to keep things neat and tidy so I bought the seat side of the harness and want to cut the plug off, solder on the resistor and plug it in.
I think the limitation is my own knowledge of this LEDC library. When I run it with the frequency value of 25,000 it doesn’t output anything on my GPIO pin that I can detect with my multimeter.
I’m reading the docs and it seems capable of running up into the MHz range although at higher frequencies the duty cycle resolution is reduced. Although I wouldn’t expect most multimeters to detect a frequency that high, anything should pick up the voltage.
Do you get an error on the serial monitor? It should report if the frequency/duty-cycle range you’re requesting isn’t possible.
E (196) ledc: requested frequency and duty resolution cannot be achieved, try reducing freq_hz or duty_resolution. div_param=128
Caps are definitely the first thing to try. To add on, the higher your frequency, the smaller caps you’ll need. At 10kHz you’ll need around 200uF of decoupling but at 50kHz you’d only need around 40uF. The smaller capacitance means you can find caps with better ESR, or just fit into a smaller space in general.
The drawback of higher frequency is that you’ll be charging and discharging the gate of the MOSFET more often, which could mean heating it up and hitting thermal limits quicker. There’s also a tradeoff within the MOSFET itself between low on-resistance and lower required gate charge - for slow switching you can find a FET with low Rds and high gate charge since youd be switching less often, but for very high frequency applications the amount of energy you put into charging and discharging the FET (mostly since the FET will spend a longer time in its linear region) can outweigh the savings of the lower resistance. Yay tradeoffs!
Thanks for typing this up! This helps me understand a lot more about what is going on.
I may have purchased too large of cap for the first try: 470uF. I bought it online so still waiting for arrival. I’ll get some in the 40uF to 200uF range for more testing
470uf should be fine - bigger is almost always better, except if you sacrifice higher ESR for it in an application that requires lower ESR. It’s pretty common to combine a large cap with higher ESR (like an Electrolytic or tantalum) with low ESR ceramic caps. That way the large cap can handle the high speed bulk C while the smaller cap can handle the high speed stuff and switching edges.
Did you make sure the cap you picked out was rated for the voltage you are working with? For hobbyist stuff it’s usually a good idea to heavily derate voltages, to avoid blowing things up. For example, if I was working with a 24V power supply, I wouldn’t nab a 25V cap; I would spring for a 35V (or even a 50V if I’m feeling particularly paranoid). You’ll see derating like this commonly in commercial applications, and extremely frequently in military/aerospace applications.
As a rule of thumb you should always derate by at least 20%, then increase to 100% depending on how much ripple or switching the cap will see. For this application I’d probably want to derate to at least 50%
Not too sure about the vacuum effects, I suspect the electrolytics wouldn’t last long as they are built to handle a certain pressure then pop to vent in a controlled manner in the event of failure. The positive pressure under operation is also likely to inject liquid refrigerant into the components and into layers of the PCB and such, that cant be good for any of it, that would definitely kill capacitors by displacing and or dissolving the electrolyte fluid.
As for the longer term, I know that pretty much all of the phase change fluids you would likely use act as pretty strong solvents in their liquid states, so I doubt the hardware would survive terribly long.
There are immersion cooled computer systems using an inert liquid like Perfluoro(2-methyl-3-pentanone) but that is a different process to phase change refrigeration.
-i live in the country, power outages happen, I cannot reliably prevent things from turning on all at once.
-my other mixers make noise when turned on, but they are not loud enough to kill speakers; even so I do try to turn things on in the proper order. This one is dangerously exceptional and won’t be used if this can’t be fixed.
There are timing relays for under $50 that can delay the power to the amps for a few seconds. You just need to buy a 230V model (for input and switch) that has the current capacity for your sound system.
Based on the experience I gathered in repair cafes:
Some old power switches generate an arc (spark?) when flipping them. Cleaning their insides with an "electrical contact cleaner" spray can sometimes help.
Defective electrochemical capacitors do NOT always swell or leak. If it is worth it swap them all for new ones (We sometimes desolder what we think are good ones from dead appliances to be re-used).
All domestic appliances around here (France) have an "anti surge" (?) capacitor soldered just after the power cable and power switch. If I understand it correctly, its job is to prevent a "parasitic" current spike to travel back on the domestic electric network when the equipment is switched on. That's the one I would replace in priority to see if it fixes your problem.
Disclaimer : I have no degree in electronics / electrical installations. Take what is above with a grain a salt as I might be dead wrong.
Always unplug the appliance from the mains before tinkering and discharge ALL the capacitors which are on the 110 V /220 V side of the electronics before touching the PCB on which they are soldered.
Good luck with your repair. It would be nice and helpful if you have a chance to post some pictures :)
askelectronics
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.