“There goes the neighborhood” isn’t a phrase to be thrown about lightly, but when they build a police station next door to your house, you know things are about to get noisy. Just how bad it’ll be is perhaps a bit subjective, with pleas for relief likely to fall on deaf ears unless you’ve got firm documentation like that provided by this automated noise detection system.

OK, let’s face it — even with objective proof there’s likely nothing that [Christopher Cooper] is going to do about the new crop of sirens going off in his neighborhood. Emergencies require a speedy response, after all, and sirens are perhaps just the price that we pay to live close to each other. That doesn’t mean there’s no reason to monitor the neighborhood noise, though, so [Christopher] got to work. The system uses an Arduino BLE Sense module to detect neighborhood noises and Edge Impulse to classify the sounds. An ESP32 does most of the heavy lifting, including running the UI on a nice little TFT touchscreen.

When a siren-like sound is detected, the sensor records the event and tries to classify the type of siren — fire, police, or ambulance. You can also manually classify sounds the system fails to understand, and export a summary of events to an SD card. If your neighborhood noise problems tend more to barking dogs or early-morning leaf blowers, no problem — you can easily train different models.

While we can’t say that this will help keep the peace in his neighborhood, we really like the way this one came out. We’ve seen the BLE Sense and Edge Impulse team up before, too, for everything from tuning a bike suspension to calming a nervous dog.

If you’ve laid hands on a retro analog TV, have the restoration bug, and you plan to make the final project at least somewhat period-correct, you face a bit of a conundrum: what are you going to watch? Sure, you can serve up just about any content digitally these days, but some programs just don’t feel right on an old TV. And even if you do get suitably retro programming, streaming isn’t quite the same as the experience of tuning your way through the somewhat meager selections as we did back in the analog days.

But don’t worry — this Raspberry Pi TV simulator can make your streaming experience just like the analog TV experience of yore. It comes to us from [Rodrigo], who found a slightly abused 5″ black-and-white portable TV that was just right for the modification. The battery compartment underneath the set made the perfect place to mount a Pi, which takes care of streaming a variety of old movies and shorts. The position of the original tuning potentiometer is read by an Arduino, which tells the Pi which “channel” you’re currently tuned to.

Composite video is fed from the Pi’s output right into the TV’s video input, and the image quality is just about what you’d expect. But for our money, the thing that really sells this is the use of a relay to switch the TV’s tuner back into the circuit for a short bit between channel changes. This gives a realistic burst of static and snow, just like we endured in the old days. Hats off to [Rodrigo] for capturing everything that was awful about TV back in the day — Mesa of Lost Women, indeed! — but still managing to make it look good.

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

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

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

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

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):

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

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.

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.

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!