Anybody can grab a USB TV tuner card and start monitoring the airwaves, but to get into the real meat of radio you’ll need your amateur radio license. Once you have that, the bandwidth really opens up… if you can afford the equipment. However, [spaceneedle] and friends have dramatically lowered the costs while increasing the possibilities of owning a radio by creating this ham radio shield for the Arduino.

The HamShield, is a versatile shield for any standard Arduino that allows it to function like an off-the-shelf radio would, but with a virtually unlimited number of functions. Anything that could be imagined can be programmed into the Arduino for use over the air, including voice and packet applications. The project’s sandbox already includes things like setting up mesh networks, communicating over APRS, setting up repeaters or beacons, monitoring weather stations, and a whole host of other ham radio applications.

HamShield operates on a wide range of frequencies and only uses a 250 mW amplifier. The power draw is small enough that the HamShield team operated it from a small solar panel, making it ideal for people in remote areas. The project is currently gathering funding and has surpassed their goal on Kickstarter, branding itself appropriately as the swiss army of amateur radio. The transceiver seems to be very robust, meaning that the only thing standing in the way of using this tool is simply writing the Arduino code for whatever project you want to do, whether that’s as a police scanner or even just a frequency counter. And if you want to follow along on hackaday.io, the project can be found here.

Arduino user named Muiota shared with us an experimental DIY music project running on Arduino Uno and  solenoids.

Take a look at the video to hear how it sounds:

Adafruit is working on a series of videos that’s basically Sesame Street for electronics. G is for Ground is out, where [Adabot] discovers pipes and lightning rods are connected to ground. Oh, the rhyming. Here’s the rest of the videos so far. We can’t wait for ‘Q is for Reactive Power’.

Think you’re good enough to build an airlock 70 cubic meters in volume that can cycle once every thirty seconds? How about building a 500 mile long steel tube with zero expansion joints across active fault lines? Can you stop a 3 ton vehicle traveling at 700 miles per hour in fifteen seconds? These are the near-impossible engineering challenges demanded of the hyperloop. The fact that no company will pay for this R&D should tell you something, but that doesn’t mean you still can’t contribute.

Calling everyone that isn’t from away. [Paul] lives near Augusta, Maine and can’t find a hackerspace. Augusta is the capital of the state, so there should be a hackerspace nearby. If you’re in the area, go leave a message on his profile.

Last week we found memristors you can buy. A few years ago, [Nyle] found them while hiking. They were crudded up shell casings, and experiments with sulfur and copper produced a memristor-like trace on a curve tracer.

Need a way to organize resistors? Use plastic bags that are the same size as trading cards.

The Arduino is too easy. It must be packaged into a format that is impossible to breadboard. It should be shaped like a banana. Open source? Don’t need that. The pins are incorrectly labelled, and will be different between manufacturing runs.

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.

While getting geared up for geocaching [Folkert van Heusden] decided he didn’t want to get one of those run of the mill GPS modules, and being inspired by steam punk set out and made his own.

Starting with an antique wooden box, and adding an Arduino, GPS module, and LiPo battery to make the brains. The user interface consists of good ‘ole toggle switches and a pair of quad seven segment displays to enter, and check longitude and latitude.

To top off the retro vibe of the machine two analog current meters were repurposed to indicate not only direction, but also distance, which we think is pretty spiffy. Everything was placed in a laser cut wooden control panel, which lend to the old-time feel of the entire project.

Quite a bit of wire and a few sticks of hot glue later and [Folkert] is off and ready for an adventure!

Maker Faires are great places to see some interesting combinations of both art and technology that can be found nowhere else. Where else could you see Robotic Chimps on Scooters, an autonomous machine that creates objects based on the influences that surround it or get your own 3D printed portrait […]

Read more on MAKE

The post Digital Dreamer Offers Up Interactive Story Time Fun appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.

Self-driving cars are in the news almost daily, but they are not exactly in my automotive budget for this decade. Today, that has changed. While this car might be smaller and not capable of giving me a ride, it’s still autonomous and, best of all, it is a project that I […]

Read more on MAKE

The post Self-Driving R/C Car Parks Itself Just Like a Lexus appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.

As more and more of our technology becomes automatic, wireless, invisible, and connected, it simultaneously has a greater potential to slip from our immediate attention. Matt Martin, a Masters student at Auckland University of Technology in New Zealand, is most interested in how technology affects us. He designed “Wearable Beacon,” […]

Read more on MAKE

The post LED Shirt Lights Up When You’re Bombarded by Bluetooth appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.

Today we are updating our website with a new Product Page. It’s been revisited to present you Arduino products within a context of possible applications for your creative projects. If you are beginning to tinker with electronics there’s a series of Entry Level products to make it easier for you to start having fun.

You’ll also find out we retired some products. That means we are not going to produce new official content about them and we are not going to manufacture them anymore in the near future with the same characteristics. But don’t worry, all the documentation we have shared and the forum sections are going to be kept online so you can access them whenever needed.

Why are we retiring some products? Our goal has always been making electronics accessible for anyone, and encourage everybody’s creativity by launching thoroughly tested, supported, and documented products. That’s the reason why we decided to focus our efforts on the most successful boards so that you could have the best experience when using each one of them.

As you may have noticed, we’ve been going through a reorganization of the way we manufacture products at Arduino. We’ve been partnering with market-leading, innovative manufacturers/distributors around the world, like Adafruit and SeeedStudio. The objective is providing locally produced boards to different markets and our partners are not only taking care of manufacturing and distributing the boards, but they also share with us a commitment with the open-source community.

The Arduino project became widespread especially because we invested a lot of energy in nurturing the community, and providing documentation to allow newbies and people with no technical background to tap into the world of interaction design, electronics and coding.

That’s all with for now! Check the new page, discover the upcoming products and choose the right board for your project!

Mike Szczys of Hackaday met Massimo Banzi at Maker Faire Shenzhen and interviewed him about manufacturing Genuino in China, the current and future of Arduino, and how recent events may shape the Open Hardware landscape.

Enjoy the video: