I'm programming the back lights for a toy car using Arduino. What happens is that if I initiate something like the brake (which turns on all the LEDs), all the LEDs turn on right away but don't turn off right away. When I remove the signal from the LEDs, it takes maybe 5 seconds for the LEDs to actually turn off. Basically there is some kind of a lag or delay. Is there a fix for this?
If you have a serial.write/read then that can cause delays. So perhaps that's one reason. A second reason is, it takes a few moments for the power to drain out of the LED (more likely reason). Is there a some component connected between the ground pin of the LED to the ground rail? Try connecting the negative pin of the LED directly to the ground. That should fix it.
Related
So I am using a Step Motor 28BYJ-48 and while turning the LEDS will light up. Now the problem that I'm having is, that the LED labeled D won't turn off.
My ESP is going into deepsleep to save battery and to improve that, it would be really nice if the LED would be off too.
I am using the CheapStepper library.
When I manually restart the ESP, all LED's are off.
Maybe I have to end the Cheapstepper class or something?
Thanks in advance!
The leds indicate the polarity of the stepper phases. The only way to turn off all leds is to turn off the motor.
CheapStepper library provides a function for this. void CheapStepper::off()
I was writing some simple code involving a tilt ball switch, but it didn't end up working right. I messed around with the inputs and outputs and eventually I learned that when I put my fingers near the input pin, the built-in led lit up. I didn't even have to touch anything. Are the input pins just really sensitive to an electric or magnetic field in my fingers?
Here is the code that I was running: 1
When the led built-in was lighting up I only had the Arduino hooked up to a power source. The most logical thing that I can come up with (which is probably wrong) is that my fingers are magnetized which creates a magnetic flux which induces a current. So basically I'm Magneto until somebody tells me what is actually happening.
I'm not qualified to answer whether or not you are Magneto.
As for the Arduino, try adding a resistor between Pin 8 and Ground.
That should help to drain the phantom signal that your mutant powers are generating.
I have a GSM shield V2 for Arduino, and I want some buzzer to make some noise when there is an incoming call. At this link http://www.thaieasyelec.net/archives/Manual/M10_HD_V1.00.pdf page 44 I found that by connecting a simple transistor and a buzzer to the actual "buzzer" pin I should be able to produce sound. I tried and that does not work as expected, all I get is noise from the GND of the shield, that typical GSM noise that everyone know of.
I also tried to connect another arduino as to analog read the buzzer signal, but I get nothing that look like a ringing tone.
Has anyone any idea? Did I forget to setup some things software wise? So far it seems that the buzzer behaviour is completely unrelated to anything code wise, there is just that "buzzer" pin, and that's it, nothing more to set up.
Any help would be much appreciated !
Cheers
Here's a great beeper/alarm part I've used in a couple of recent projects. It is loud but can be muffled. It's self-driving, so all you have to do it supply it enough current at its rated voltage, like through a transistor or Darlington. It has a wide voltage range, and runs great from 3.3V up to 20, So it's ideal for microcontroller projects at 3.3V or 5V. No need to fiddle with timers or PWM to make it beep. Try out this great part.. Drive it from any output pin to a small-signal transistor with a beta of 50 or better and you'll be good to go. Turn output pin on, it starts. Turn output pin off, it stops. I made mine "chirp" like the alarm on a car security system. Easiest thing in the world.
I have an Arduino starter set, which came with both an active and a passive buzzer. Unfortunately, I can't seem to know which is which. All I know is that one is a little longer than the other one, on which I can see the green circuit board underneath.
An active buzzer generates the sound itself. You basically just turn it on or off.
A passive buzzer needs a signal source that provides the sound signal.
To find out which is which you can measure the resistance between both leads. If it is a few Ohms its the passive one, higher values indicate an active one.
Also the active one will have it's own circuitry (the pcb you can see) and will therefor be probably bigger.
But I guess your arduino package comes with a parts list that should give you all information you need?
"Programatically" speaking:
Active Buzzer: using a simple digitalWrite(buzzerPin, HIGH) will turn the beep on, once it has a internal oscillator.
Passive Buzzer: you need to use Tone() function in order to make it beep. Once it has no internal oscillator you need to use Tone() function to create the frequency it will oscillate. Check the Tone() reference page to learn how to use it, but is quite simple, you just need to enter as parameter pin and frequency like Tone(3, 440), will generate a 440Hz on passive buzzer hooked up to pin 3.
To stop a active buzzer you need to use digitalWrite(buzzerPin, LOW), while with a passive buzzer you need to use noTone(passiveBuzzerPin).
How to distinguish passive buzzer and active buzzer?
There are several ways to distinguish passive buzzer and active buzzer.
The most simple method is to watch their different appearances.If you can see a drive board,it is passive buzzer.If the buzzer is completely covered by black adhesive,it is active buzzer.
https://www.keliking.com/Differences-Between-Passive-Buzzer-and-Active-Buzzer-id570060.html
They come in all shapes and sizes, so don't assume "long" means one thing or another. The passive buzzer has only a small piezo on the module's PCB. An active buzzer will have a couple other small components on the pcb, like an amp and resistor(s).
In the Freenove Arduino kit that i bought, the passive buzzer is the one with the green on the bottom and the active is the one without, and is slightly taller with varied hights of the pins
Physical distinction between the two.
Slight disclaimer first. . . the buzzers I have are from one of those 27 piece sensor kits. For me it was an extra buy from "30 Days Lost In Space". After my pieces all got mixed together, I've decided to lay them all out & know what each one does. Yours may be different
Here's what I observed. If you have the connections down and the buzzer away from you so you're looking at the back of the board There are solder points. The upper left solder point is filled on the active buzzer. note don't count the larger mounting hole on the very edge. In the photo, I've highlighted the filled solder hole on the active buzzer.
highlighted solder point on active buzzer -- left vs passive buzzer -- right
I had this same question, which led me here. The other answers were helpful in and of themselves, but I noticed the difference after testing, and hopefully someday this may help someone else who may be new, as I am now.
I've been at arduino just shy of 2 weeks.
I have an Arduino Mega connected to a 6 axis robotic arm. All 6 interrupts are attached to encoders (one encoder pin on an interrupt, the other on a vanilla digital input). The interrupts are handled with this code:
void readEncoder1(){
//encoders is a 2d array, where the first d is the axis, and the two pin numbers
//first pin is on an interrupt (CHANGE), and second is a standard digital in
if (digitalRead(encoders[0][0]) == digitalRead(encoders[0][1])) {
positions[0]++;
} else {
positions[0]--;
}
if(servoEnable){
updatePositions(); //// compares positions[] to targets[] and adjusts motor speed accordingly
}
}
This is designed to keep the arm locked at a certain position- if the arduino detects that the position of the motor is off by a certain threshold, it updates the power going to the motor to keep the arm in position.
The problem is this, then -- if two or three (or more) axis are under load (requiring constant updating to stay in position) or they are moving, the Arduino will stop receiving intact commands on Serial input, several characters will be dropped. The interrupts are obviously running quite quickly, and for some reason this is causing commands to become corrupted. Is there any way around this? Architecturally, am I doing this right? My main instinct is to call updatePositions() in the main run loop at, say, 100 ms intervals, will this significantly reduce interrupt overhead? I guess what my question boils down to is how do I get reliable serial commands into the Arduino even if all 6 encoders are pulsing away?
Quadrature encoders were designed to be read by hardware counters. Pulse rates are generally high with the motor running at full speed. One megahertz is not unusual. The higher the number of pulses, the better the servo loop works and the more accurate you can position the motor.
Doing this is in software with a low-power cpu is, well, challenging. It will fall apart when the ISR takes longer than the interval between pulses. You'll lose pulses and thus position. Especially bad because there is no way you can detect this error condition. And that this loss happens when the robot is moving fast, the worst case condition to lose control.
You absolutely cannot afford to update the servo loop in the interrupt handler so get rid of that first. Keep the ISR to the bare minimum, only count the position and nothing else. The servo loop should be separate, driven by a timer interrupt or tick. You cannot properly control a robot with a 100 msec servo update unless it is big an sluggish, this needs to be a handful of milliseconds at most to get smooth acceleration and stable feedback.
There's a limited amount of wisdom in spending forty bucks to control thousands of dollars worth of robot hardware. Not being able to keep up in the servo loop is something you can detect, shut it down when the position error builds up too much. There's nothing you can do about losing pulses, that's a wreck. Get the hardware counters.
First rule of embedded systems:
Do as little as possible in interrupts.
In your case, just update the positions in the interrupt and run your position/speed control loop in the background or at a lower priority.
Aside: I assume you are aware that you are "losing" encoder pulses as you don't have an interrupt on one of the channels?
Also, interrupt-driven encoder-analysis is very noise-prone. If you get a noise pulse, you'll likely only see an interrupt for one of the edges as they'll be too close together to process both.
A more robust way is to use a state machine which watches all 4 transitions, but that requires either interrupts on both edges of both channels, or polling fast enough to not miss anything up the to rate you are expecting to see.