Posts with «noise» label

Arduino motor control problems!

Hey guys,

I'm having trouble regarding motor control in a project I'm working on.

It uses an ATMega328 DIP package on a PCB. The motors I'm using are small coreless motors and I'm trying to control them using Si2302ds N-MOS FETs. For the power supply I'm using a 3.7V(4.2V on full charge) Lipo. I've tested this setup on a promini before and the motors turned on and off just fine.

read more

Let's Make Robots 26 Oct 12:06
arduino  avr  motor  noise  power supply  

Arduino motor control problems!

 

Update 06/11/2016

Hey guys,

I sort of got the motor working. Adding a small resistance(about 2-3ohms) in series with the motor seemed to stop the Atmega reseting whenever Pin 3 was pulled HIGH (still don't know for sure what was causing this!). I'll still continue t troubleshoot this problem and completely figure out what exaclty was causing the Atmega to reset, since the resistor is not a permanent solution (wasteful energy loss). I'm really grateful for the huge amount of help from here guys!! Thanks alot! :)

Cheers!

read more

Let's Make Robots 26 Oct 12:06
arduino  avr  motor  noise  power supply  

Arduino motor control problems!

 

Update 06/11/2016

Hey guys,

I sort of got the motor working. Adding a small resistance(about 2-3ohms) in series with the motor seemed to stop the Atmega reseting whenever Pin 3 was pulled HIGH (still don't know for sure what was causing this!). I'll still continue t troubleshoot this problem and completely figure out what exaclty was causing the Atmega to reset, since the resistor is not a permanent solution (wasteful energy loss). I'm really grateful for the huge amount of help from here guys!! Thanks alot! :)

Cheers!

read more

Let's Make Robots 26 Oct 12:06
arduino  avr  motor  noise  power supply  

Arduino motor control problems!

 

Update 06/11/2016

Hey guys,

I sort of got the motor working. Adding a small resistance(about 2-3ohms) in series with the motor seemed to stop the Atmega reseting whenever Pin 3 was pulled HIGH (still don't know for sure what was causing this!). I'll still continue t troubleshoot this problem and completely figure out what exaclty was causing the Atmega to reset, since the resistor is not a permanent solution (wasteful energy loss). I'm really grateful for the huge amount of help from here guys!! Thanks alot! :)

Cheers!

read more

Let's Make Robots 26 Oct 12:06
arduino  avr  motor  noise  power supply  

Improving PteroDAQ

For the past couple of years, I’ve been using the PteroDAQ data acquisition system that my son wrote for the KL25Z board (a second-generation system, replacing the earlier Arduino Data Logger he wrote).  He has been working on and off on a multi-platform version of PteroDAQ for over a year, and I finally asked him to hand the project over to me to complete, as I want it much more than he does (he’d prefer to spend his time working on new products for his start-up company, Futuristic Lights).

It has been a while since he worked on the code, and it was inadequately documented, so we’ve been spending some time together just digging into the code to figure out the interfaces, which I’ve been adding comments and docstrings to, so that I can debug the code.  Other than the lack of documentation, the code is fairly well written, so figuring out what is going on is not too bad (except in the GUI built using tkinter—like all GUI code, it is a complicated mess, because the APIs for building GUIs are a complicated mess).

The man goal of his multi-platform code was to support Arduino ATMega-based boards and the KL25Z board, while making it relatively easy to add more boards in future.  The Arduino code is compiled and downloaded by the standard Arduino IDE, while the KL25Z board code is compiled and downloaded with the MBED online compiler.  He has set up the software with appropriate #ifdef checks, so that the same code files can be compiled for either architecture.  The knowledge of what features are available on each board and how to request them is stored in one module of the python program that runs on the host computer.  As part of the cleaning up, we’ve been moving some of the code around to make sure that all the board-specific stuff is in that file, with a fairly clean interface.

He believed that he had gotten the new version working on the Arduino boards, but not on the KL25Z board.  It turned out that was almost true—I got the system working with the Leonardo board (which uses USB communication and has a weird way to get reset) almost immediately, but had to do a number of little bug fixes to get it working with other Arduino boards (which use UART protocol and a different way of resetting). It turned out that the system also worked with the KL25Z after those bug fixes, so he was very close to having it ready to turn over to me.

One of the first things I did was to time how fast the boards would run with the new code—the hope was that the cleaner implementation would have less overhead and so support a higher sampling rate.  Initial results on the Arduino boards were good, but quite disappointing on the KL25Z boards, which use a faster processor and so should be able to support much higher speeds.  We tracked the problem down to the very high per-packet overhead of the USB packets in the mbed-provided USBSerial code.  (He had tried writing his own USB stack for bare-metal ARM, but had never gotten it to work, so we were using the mbed code despite its high overhead.)

There was a simple fix for the speed problem: we stopped sending single-character packets and started using the ability of the MBED code (and the Arduino code for the Leonardo) to send multi-character packets.  With this change, we got much better sampling rates (approximate max rate):

channels Leonardo Uno/Duemilanove/Redboard KL25Z 32x avg KL25Z, 1x avg
0  13kHz  4.5kHz  8.2kHz
1 analog  5kHz  2.7kHz  5.5kHz  8.1kHz
2 analog  3kHz  1.9kHz  3kHz  8.1kHz
7 digital  6.5kHz  3.4kHz  8.2kHz

It is interesting that the Leonardo (a much slower processor) manages to get a higher data rate than the KL25Z when sending just time stamps.  I think that I can get another factor of 3 or 4 speed on the KL25Z by flushing the packets less often, though, so I’ll try that.

By flushing only when needed, I managed to improve the KL25Z performance to

channels KL25Z 32x avg KL25Z, 1x avg
0  17kHz
1 analog  6.3kHz  10kHz ??
2 analog  3.3kHz

Things get a bit hard to measure above 10kHz, because the board runs successfully for several hundred thousand samples, then I start losing characters and getting bad packets. The failure mode using my son’s faster Linux box is different: we lose full packets when going too fast—which is what PteroDAQ is supposed to do—and the speed at which the failure starts happening is much higher (maybe 23kHz). In other words, what I’m seeing now are the limitations of the Python program on my old MacBook Pro. It does bother me that the Mac seems to be quietly dropping characters when the Python program can’t clear the USB serial input fast enough.

The KL25Z slows down when doing the 32x hardware averaging, because the analog-to-digital conversion is slow—particularly when doing 32× hardware averaging.  I think that we’ve currently set things up for a 6MHz  ADC clock, with short sampling times, which means that a single-ended 32× 16-bit conversion takes around 134µs and the sampling rate is limited by the conversion times (differential measurements are slower, around 182µs).

There is a problem in the current version of the code, in that interrupts that take longer to service than the interrupt time result in PteroDAQ lying about its sampling rate.  I can fix this on the KL25Z by using a separate timer, but the Arduino boards have rather limited timer resources, and we may just have to live with it on them.  At least I should add an error flag that indicates when the sampling rate is higher than board can handle.

We had a lot of trouble yesterday with using the bandgap reference to set the voltage levels.  It turns out that on the Arduino boards, the bandgap channel is a very high impedance, and it takes many conversion times before the conversion settles to the final value (nominally 1.1V).  Switching channels and then reading the bandgap is nearly useless—the MUX has to be left on the bandgap for a long time before reading the value means anything.  If you read several bandgap values in quick succession, you can see the values decaying gradually from the value of the previously read channel to the 1.1V reference.

The bandgap on the KL25Z is not such a high-impedance source, but there is some strange behavior when reading it with only 1× averaging—some values seem not to occur and the ds.  I recorded several thousand measurements with 1×, 4×, 8×, 16×, and 32× averaging:

The unaveraged (1×) reading seems to be somewhat higher than any of the hardware-averaged ones.

I was curious about how the noise reduced on further averaging, and what the distribution was for each of the averaging levels. I plotted log histograms (using kernel-density estimates of the probability density function: gaussian_kde from the scipy python package) of the PteroDAQ-measured bandgap voltages.  The PteroDAQ is not really calibrated—the voltage reference is read 64 times with 32× averaging and the average of those 64 values taken to be 1V,  but the data sheet says that the  bandgap could be as much as 3% off (that’s better than the 10% error allowed on the ATMega chips).

Without averaging, there is a curious pattern of missing values, which may be even more visible in the rug plot at the bottom than in the log histogram.

The smoothed log-histogram doesn’t show the clumping of values that is more visible in the rug plot.

With eight averages, the distribution begins to look normal, but there is still clumping of values.

With 16 averages, things look pretty good, but mode is a bit offset from the mean still.

Averaging 32 values seems to have gotten an almost normal distribution.

Interestingly, though the range of values reduces with each successive averaging, the standard deviation does not drop as much as I would have expected (namely, that averaging 32 values would reduce the standard deviation to about 18% the standard deviation of a single value). Actually, I knew ahead of time that I wouldn’t see that much reduction, since the data sheet shows the effective number of bits only increasing by 0.75 bits from 4× t0 32×, while an 8-fold increase in independent reads would be an increase in effective number of bits of 1.5 bits.  The problem, of course, is that the hardware averaging is of reads one right after another, in which the noise is pretty highly correlated.

I think that the sweet spot for averaging is the 4× level—almost as clean as 32×, but 8 times faster.  More averaging improves the shape of the distribution a little, but doesn’t reduce the standard deviation by very much.  Of course, if one has a low-frequency signal with high-frequency noise, then heavier averaging might be worthwhile, but it would probably be better to sample faster with the 4× hardware averaging, and use a digital filter to remove the higher frequencies.

The weird distribution of values for the single read is not a property of the bandgap reference, but of the converter.  I made a voltage divider with a couple of resistors to get a voltage that was a fixed ratio of the supply voltage (so should give a constant reading), and saw a similar weird distribution of values:

The distribution of single reads is far from a normal noise distribution, with fat tails on the distribution and clumping of values.

 

With 32× sampling, the mean is 1.31556 and the standard deviation 5.038E-04, with an excellent fit to a Gaussian distribution.


Filed under: Circuits course, Data acquisition Tagged: Arduino, histograms, KL25Z, noise, PteroDAQ, sampling frequency

MacGyvered Optoisolator is a Great Introduction

Sometimes the best way to learn about a technology is to just build something yourself. That’s what [Dan] did with his DIY optoisolator. The purpose of an optoisolator is to allow two electrical systems to communicate with each other without being electrically connected. Many times this is done to prevent noise from one circuit from bleeding over into another.

[Dan] built his incredibly simple optoisolator using just a toilet paper tube, some aluminum foil, an LED, and a photo cell. The electrical components are mounted inside of the tube and the ends of the tube are sealed with foil. That’s all there is to it. To test the circuit, he configured an Arduino to send PWM signals to the LED inside the tube at various pulse widths. He then measured the resistance on the other side and graphed the resulting data. The result is a curve that shows the LED affects the sensor pretty drastically at first, but then gets less and less effective as the frequency of the signal increases.

[Dan] then had some more fun with his project by testing it on a simple temperature controller circuit. An Arduino reads a temperature sensor and if the temperature rises above a certain value, it turns on a fan to cool the sensor off again. [Dan] first graphed the sensor data with no fan hooked up. He only used ambient air to cool things down. The resulting graph is a pretty smooth curve. Next he hooked the fan up and tried again. This time the graph went all kinds of crazy. Every time the fan turned on, it created a bunch of electrical noise that prevented the Arduino from getting an accurate analog reading of the temperature sensor.

The third test was to remove the motor circuit and move it to its own bread board. The only thing connecting the Arduino circuit to the fan was a wire for the PWM signal and also a common ground. This smoothed out the graph but it was still a bit… lumpy. The final test was to isolate the fan circuit from the temperature sensor and see if it helped the situation. [Dan] hooked up his optoisolator and tried again. This time the graph was nice and smooth, just like the original graph.

While this technology is certainly not new or exciting, it’s always great to see someone learning by doing. What’s more is [Dan] has made all of his schematics and code readily available so others can try the same experiment and learn it for themselves.


Filed under: Arduino Hacks

Noise pollution tit for tat uses the Baha Boys as a weapon

Here [Matthew Br] explains the situation he’s in with the neighbors that share this wall of his apartment. When they listen to music they like it loud and so he gets to ‘enjoy’ the experience as well. But he can’t ignore it any longer, and has decided to use a sound volume detector to blast some tunes right back at them.

He taped a microphone to the wall and wired it up to his Arduino. It monitors incoming sound and, using an adjustable threshold, it will trigger when the neighbors are too loud. We think he was wise to include some time filtering that makes sure the loud noises are sustained and not just the result of someone bumping into the wall. When the system does detect loud music for a sustained period it triggers [Matthew's] own CD player to pump out Who Let the Dogs Out? by the Baha Boys. It will play for a period of time, then shut off to listen and see if the neighbors are still rowdy.

He documents an actual run in the latter half of the clip after the break. We sure hope he’s living in a building with just two units, otherwise this will drive the rest of the neighbors batty as well!


Filed under: digital audio hacks