A recent company move has left [kigster] and his 35 coworkers in a frustrating situation. Their new building only has two single occupancy bathrooms. To make matters worse, the bathrooms are located on two different floors. Heading to one bathroom, finding it occupied, then running upstairs to find the second bathroom also occupied became an all to common and frustrating occurrence at the office.
It was obvious the office needed some sort of bathroom occupancy monitoring system – much like those available on commercial aircraft. [kigster] asked for a budget of about $200 to build such a system. His request was quickly granted it by office management. They must have been on their way to the bathroom at the time.
[kigster] began work on BORAT: Bathroom Occupancy Remote Awareness Technology. The initial problem was detecting bathroom occupancy. The easiest method would be to use door locks with embedded switches, much those used in aircraft. Unfortunately, modifying or changing the locks in a rented office space is a big no-no. Several other human detection systems were suggested and rejected. The final solution was a hybrid. Sonar, Passive Infrared (PIR), and light sensors work in concert to detect if a person is in the bathroom. While we think the final “observer unit” is rather cool looking, we’re sure unsuspecting visitors to the office may be wondering why a two eyed robot is staring at them on the throne.
The display side of the system was easy. The entire system communicates with the venerable nRF24L01+ radio modules, so the display just needed a radio module, an arduino, and a way of displaying bathroom status. Two LED matrices took care of that issue.
We really like this hack. Not only is it a great use of technology to solve a common problem, but it’s also an open source system. BORAT’s source code is available on [kigster’s] github.
Want to know more about BORAT? Kigster is answering questions over on his thread in the Arduino subreddit.
If you want to take a photograph with a professional look, proper lighting is going to be critical. [Richard] has been using a commercial lighting solution in his studio. His Lencarta UltraPro 300 studio strobes provide adequate lighting and also have the ability to have various settings adjusted remotely. A single remote can control different lights setting each to its own parameters. [Richard] likes to automate as much as possible in his studio, so he thought that maybe he would be able to reverse engineer the remote control so he can more easily control his lighting.
[Richard] started by opening up the remote and taking a look at the radio circuitry. He discovered the circuit uses a nRF24L01+ chip. He had previously picked up a couple of these on eBay, so his first thought was to just promiscuously snoop on the communications over the air. Unfortunately the chips can only listen in on up to six addresses at a time, and with a 40-bit address, this approach may have taken a while.
Not one to give up easily, [Richard] chose a new method of attack. First, he knew that the radio chip communicates to a master microcontroller via SPI. Second, he knew that the radio chip had no built-in memory. Therefore, the microcontroller must save the address in its own memory and then send it to the radio chip via the SPI bus. [Richard] figured if he could snoop on the SPI bus, he could find the address of the remote. With that information, he would be able to build another radio circuit to listen in over the air.
Using an Open Logic Sniffer, [Richard] was able to capture some of the SPI communications. Then, using the datasheet as a reference, he was able to isolate the communications that stored information int the radio chip’s address register. This same technique was used to decipher the radio channel. There was a bit more trial and error involved, as [Richard] later discovered that there were a few other important registers. He also discovered that the remote changed the address when actually transmitting data, so he had to update his receiver code to reflect this.
The receiver was built using another nRF24L01+ chip and an Arduino. Once the address and other registers were configured properly, [Richard’s] custom radio was able to pick up the radio commands being sent from the lighting remote. All [Richard] had to do at this point was press each button and record the communications data which resulted. The Arduino code for the receiver is available on the project page.
[Richard] took it an extra step and wrote his own library to talk to the flashes. He has made his library available on github for anyone who is interested.
We’re sure that some of our readers are familiar with the difficult task that debugging/sniffing nRF24L01+ communications can be. Well, [Ivo] developed a sniffing platform based on an Arduino Uno, a single nRF24L01+ module and a computer running the popular network protocol analyzer Wireshark (part1, part2, part3 of his write-up).
As these very cheap modules don’t include a promiscuous mode to listen to all frames being sent on a particular channel, [Ivo] uses for his application a variation of [Travis Goodspeed]’s technique to sniff Enhance Shockburst messages. In short, it consists in setting a shorter than usual address, setting a fix payload length and deactivating the CRC feature. The Arduino Uno connected to the nRF24L01+ is therefore in charge of forwarding the sniffed frames to the computer. An application that [Ivo] wrote parses the received data and forwards it to wireshark, on which can be set various filters to only display the information you’re interested in.
With The Hackaday Prize, you’re not just limited to one entry. Of course it would be better to devote your time and efforts to only one project if you’re competing for a trip to space, but if you’re [Necromant], you might be working on two highly related project that are both good enough for The Hackaday Prize
[Necromant]’s first project is rf24boot, an over-the-air bootloader using the very cheap and very popular NRF24L01 2.4GHz wireless module. There have been many, many projects that add wireless bootloading to microcontrollers using XBees and the NRF24, but [Necromant] is doing something different with this project: he’s building in support for a wide variety of microcontrollers, that include the STM32, MSP430, PIC32, 8051, and of course AVR chips for that ever so popular Arduino compatibility.
The support of multiple microcontroller platforms is a result of [Necromant]’s other entry to The Hackaday Prize, Antares, the Linux kernel-like build system for microcontrollers. The idea behind Antares is to separate the writing of code from microcontrollers away from compiling and burning. Think of it as a giant makefile on steroids that works with everything, that also includes a few libraries for common projects.
Supported platforms for Antares include the popular aforementioned targets, and allow you to use any IDE you could possibly desire. emacs? Sure. Eclipse? Right on. Arduino? You’re a masochist. For a really great overview of Antares you can check out the Readme, or the post we did a year or so ago.
It’s all very cool stuff, and very easy to see the potential of what [Necromant]’s working on. Combining the two together, it’s almost a complete system for developing that Internet of Things we’ve been hearing about – uploading code to simple AVRs for simple sensors, and deploying significantly more complex code for your ARM-powered dishwasher or microwave.
[Sven337] just blogged about a gas consumption monitoring setup he finished not long ago. As his gas meter was located outside his apartment and nowhere near any electrical outlet, a battery-powered platform that could wirelessly send the current consumption data to his Raspberry Pi was required. His final solution therefore consists of a JeeNode coupled with the well known nRF24L01+ wireless transmitter, powered by 3 supposedly dead alkaline batteries.
[Sven337] carefully looked at the different techniques available to read the data from his meter. At first he had thought of using a reflective sensor to detect the number 6 which (in France at least) is designed to reflect light very well. He then finally settled for a magnetic based solution, as the Actaris G4 gas meter has a small depression intended for magnetic sensors. The PCB you see in the picture above therefore has a reed sensor and a debug LED. The four wires go to a plastic enclosure containing the JeeNode, a couple of LEDs and a reset switch. Using another nRF24L01, the Raspberry Pi finally receives the pulse count and reports it to an eeePC which takes care of the storage and graphing.
[Necromant] wrote a library to flash his microcontroller over an RF link using an NRF24L01 wireless communication module. The NRF24L01 is a cheap RF module that can be easily integrated into many microcontroller projects. Though there are Arduino libraries for driving the NRF24L01, [Necromat] decided to make a port of one with no Arduino dependencies.
The resulting bootloader fits into 4K of
RAM flash with packet loss and recovery along with user-configurable hardware or software SPI. Programming speeds are not the highest, but [ NecromatNecromant] believes this to be a property of the VUSB rather than the transfer rate from the NRF24L01 or the target microcontroller.
To program the target AVR chip, [
NecromatNecromant] used another NRF24L01 module connected to his uISP dongle over USB. Using a custom tool to interface with the uISP, the target board can be programmed in a similar fashion as avrdude. Check out the code for the ISP dongle and the AVR bootloader on his GitHub page.
[Ralph] wasn’t satisfied with the required 5 control pins to drive his nrf24l01+ transceiver module, so he used this circuit needing just 3 pin using an ATtiny85.
One of the key components was to effectively drive the chip select (CSN) line from the clock (SCK) line. The nrf24l01+ needs the CSN line to transition from high to low on the beginning of a communication. [Ralph] put the SCK line behind a diode, put a capacitor in parallel with the CSN line and altered the arduino-nrf24l01 library to encode extra delays for the clock line. This allowed the CSN line to be driven by the SCK line. Subsequent line transitions during transmission happen too fast to charge the capacitor, leaving the CSN line in a low state.
After tying the chip enable line high and dropping the 5V power line to 1.9-3.6V across a red LED, [Ralph] had an ATtiny85 controlling a nrf24l01+ module.
Though deceptively simple, a very cool hack that opens up a couple more lines on the ATtiny85.