Hanging out at one side of the Atmel booth at Maker Faire was [Pamungkas Sumasta] who was showing off his Arduino cellphone called Phoenard. We really like the form-factor but its hackability is where it really shines. [Sumasta] showed off the menu system which is quite snappy and makes it simple for you to add your own applications. Software isn’t the only thing you can customize, as there’s a connector at the bottom of the phone. He showed off a breadboard attachment which was hosting LEDs of various colors. Their intensity can be altered using a simple slider app on the touchscreen. But there’s more power if want it. Also on exhibit was a self-balancing robot body which has a connector at the top for the phone.
[Walter] created the entropy library for AVRs for a reliable source of true random numbers. It works by using the watchdog timer’s natural jitter; not fast by any means but most sources of entropy aren’t that fast anyway. By sampling a whole lot of AVR chips and doing a few statistical tests, it turns out this library is actually a pretty good source of randomness, at least as good as a pair of dice.
The circuit itself uses two 8×8 LED matrices from Adafruit, an Arduino, and a pair of buttons. The supported modes are 2d6, 2d4, 2d8, 2d10, 1d12, 1d20, a deck of cards, a single hex number, a single 8-bit binary number, or an eight character alphanumeric password. It’s more than enough for D&D or when you really need an unguessable password. Video demo below.
You’d be hard pressed to find a public restroom that wasn’t packed full of hands free technology these days. From the toilets to the sinks and paper towel dispensers, hands free tech is everywhere in modern public restrooms.
The idea is to cut down on the spread of germs. However, as we all know too well, this technology is not perfect. We’ve all gone from sink to sink in search of one that actually worked. Most of us have waved our hands wildly in the air to get a paper towel dispenser to dispense, creating new kung-fu moves in the process. IR simply has its limitations.
What if there was a better way? Check out [Ackerley] and [Lydia’s] work on gesture recognition using ultrasound. Such technology is cheap and could easily be implemented in countless applications where hands free control of our world is desired. Indeed, the free market has already been developing this technology for use in smart phones and tablets.
Where a video camera will use upwards of 1 watt of power to record video, an ultrasound device will use only micro watts. IR can still be used to detect gestures, as in this gesture based security lock, but lacks the resolution that can be obtained by ultrasound. So let us delve deep into the details of [Ackerley] and [Lydia’s] ultrasound version of a gesture recognizer, so that we might understand just how it all works, and you too can implement your own ultrasound gesture recognition system.
Atmel has just announced a new product line: SmartConnect. This moves beyond the point-to-point nature of WiFi Direct, and enables connections to standard access points. The SmartConnect series is designed for embedding in low cost devices that need to connect to a network.
The first devices in the SmartConnect line will be modules based on two chips: an Atmel SAMD21 Cortex-M0+ microcontroller and an Ozmo 3000 WiFi System on Chip. There’s also an on-board antenna and RF shielding can. It’s a drop in WiFi module, which is certified by the FCC. You can hook up your microcontroller to this device over SPI, and have a fully certified design that supports WiFi.
There’s two ways to use the module. The first is as an add-on, which is similar to existing modules. A host microcontroller communicates with the module over SPI and utilizes its command set. The second method uses the module as a standalone device, with application code running on the internal SAMD21 microcontroller. Atmel has said that the standalone option will only be available on a case to case basis, but we’re hoping this opens up to everyone. If the Arduino toolchain could target this microcontroller, it could be a great development platform for cheap WiFi devices.
At first glance, this module looks very similar to other WiFi modules, including the CC3000 which we’ve discussed in the past. However there are some notable differences. One major feature is the built in support for TLS and HTTPS, which makes it easier to build devices with secure connections. This is critical when deploying devices that are connected over the internet.
Atmel is claiming improvements in power management as well. The module can run straight from a battery at 1.8 V to 3.3 V without external regulation, and has a deep sleep current of 5 nA. Obviously the operating power will be much higher, but this will greatly assist devices that sporadically connect to the internet. They also hinted at the pricing, saying the modules will come close to halving the current price of similar WiFi solutions. SmartConnect is targeting a launch date of June 15, so we hope to learn more this summer.
We’re always excited to see better connectivity solutions. If Atmel comes through with a device allowing for cheaper and more secure WiFi modules, it will be a great part for building Internet of Things devices. With a projected 50 billion IoT devices by 2020, we expect to see a lot of progress in this space from silicon companies trying to grab market share.
We don’t know if this will come as a surprise to the regular Hackaday reader, but a whole bunch of Atmel microcontrollers have a very cool feature hidden away in their datasheets. Most of them – everything from the ATMega 168, 328, 32u4, to the ATtiny85 and 84 have a temperature sensor right on the chip. [Connor] did a little bit of research on this sensor and came up with a little bit of code that spits out the core temperature of these Atmel chips over the serial port.
The temperature sensor on these Atmel chips is accessed by writing a code – ‘100111’ for the Mega32u4 and ‘100010’ for the tiny84, for example – into the ADMUX register on the chip. According to the datasheet, the returned temperature is accurate to +- 10°C, but that can be easily calibrated by holding an ice cube (in a plastic bag, of course) up to the chip.
With a little more code, [Connor] is able to output the temperature of the microcontroller core over a serial port. In testing, his chip started out at 20°C and reached equilibrium at 24°C after about a minute. Pretty neat, and could be used as a temperature sensor for a project in a pinch.
The advent of the Arduino brought the world of microcontrollers to hobbyists, students, and artist the world over. Right now we’re in the midst of a new expansion in hobbyist electronics with the Raspberry Pi, but we can’t expect everyone to stay in the comfortable, complex, and power-hungry world of Linux forever, can we? Eventually all those tinkerers will want to program a microcontroller, and if they already have a Raspberry Pi, why not use that?
[Kevin] wanted to turn his Raspi into an AVR development workstation, without using any external programmers. He decided to use the Raspi’s SPI port to talk to an AVR microcontroller and was able to make the electrical connections with just a few bits of wire an a handful of resistors.
For the software, [Kevin] added support for SPI to avrdude, available on his git. Theoretically, this should work with any AVR microcontroller with the most popular ATMegas and ATtinys we’ve come to love. It doesn’t support the very weird chips that use TPI programming, but it’s still extremely useful.
The chip is used in a secure RFID system. The chip is added to the mix to do the heavy lifting required when using encryption. [Adam] grabbed a couple of open source libraries to put it to the test. The firmware is locked down pretty tight, but his explorations into the content of the RAM yield a treasure trove of bits. After investigating the sample code for the chip he’s shocked to learn that it uses RAM to store the keys at one point. The rest of his journey has him dumping the data and sifting through it until he gets to the “Master Diversification Key”. That’s the big daddy which will let him decrypt any of the tags used.
He reported his findings to Atmel in September of 2011. Their response is that they have no way of protecting RAM from exploit. [Adam] asserts that the problem is that the sample software wasn’t designed with the vulnerability of RAM in mind. The keys should never be stored there specifically because it is vulnerable to being dumped from a running system.