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.
Inkjet printers are a dime a dozen. You probably have taken old printers apart to scavenge parts like motors, pulleys, belts, switches, linear rods, power supply, etc. These parts are easy to reuse in other projects, unlike the controller portion of the printer which not as easy to make use of. [Blaupause] has done something very interesting, and it probably ranks in the ‘extreme difficulty’ category for most tinkerers. He has taken the front panel off an otherwise non-working Canon Pixma inkjet printer and has figured out a way to interface with it.
The front panel of this printer has the standard buttons that you would find on any ole printer, but the Pixmas also has a small LCD screen. [Blaupause] has written a library for the Olimexino microcontroller that can communicate with and make use of the repurposed front panel. And the neat part of this project is that the front panel’s on-board processor does the heavy lifting when it comes to displaying images on the LCD screen or checking button states which frees up your microcontroller to do whatever else. Right now, the LCD screen can display bitmaps and supports image transparency. The library can not display video as of yet, but that option is being worked on.
[Blaupause] makes all his hard work available to the public on the project’s Sourceforge page. In addition to the library, he also includes printer panel pinouts and detailed information on how to communicate with the buttons and LCD screen. Video after the break…
To prevent data corruption when using multiple SPI devices on the same bus, care must be taken to ensure that they are only accessed from within the main loop, or from the interrupt routine, never both. Data corruption can happen when one device is chip selected in the main loop, and then during that transfer an interrupt occurs, chip selecting another device. The original device now gets incorrect data.
For the last several weeks, [Paul] has been working on a new Arduino SPI library, to solve these types of conflicts. In the above scenario, the new library will generate a blocking SPI transaction, thus allowing the first main loop SPI transfer to complete, before attempting the second transfer. This is illustrated in the picture above, the blue trace rising edge is when the interrupt occurred, during the green trace chip select. The best part, it only affects SPI, your other interrupts will still happen on time. No servo jitter!
This is just one of the new library features, check out the link above for the rest. [Paul] sums it up best: “protects your SPI access from other interrupt-based libraries, and guarantees correct setting while you use the SPI bus”.
[Davide Gironi] shows us how to implement a sensorless brushless DC motor controller (sensorless BLDC) using an ATmega8 microcontroller. In order to control a BLDC motor you need to know its rotational sequence position and speed so you can calculate and apply the correct current phase sequence to the motor windings at just the right time.
Simply said, sensorless BLDC means you’re not using a purpose built sensor to determine the motor’s position and speed, however, you are sensing the motor’s sequence position using the back EMF signal coming from one of motor’s coils that is not currently receiving power. When this back EMF signal crosses zero voltage a microcontroller can calculate the rotational speed and when to switch to the next power sequence. This technique is not good for position control motors but is great for continuous motors like computer fans and drives were the slightly reduced wiring costs make this type of BLDC control favored.
You know when you see something like this it’s just going to be awesome, and we weren’t disappointed by our first impression. [Davide Gironi] built a brushless motor controller from the ground up using an ATmega8 as the brain. If you want to understand every aspect of a subject this is how to do it. Lucky for us he explains what each portion of the prototype does.
Brushless motors have no brushes in them (duh). But what does that really mean? In order to spin the motor a very carefully crafted signal is sent through the motor coils in the stationary portion (called the stator), producing a magnetic field that pushes against permanent magnets in the rotor. A big part of crafting that signal is knowing the position of the rotor. This is often accomplished with Hall Effect sensors, but can also be performed without them by measuring the back EMF in the coils not currently being driven. The AVR-GCC compatible library which [Davide] put together can be tweaked to work with either setup.
Get a good look at the system in action after the break.
You may know your way around the registers of that favorite microcontroller, but at some point you’ll also need to wield some ninja-level math skills to manage arrays of data on a small device. [Scott Daniels] has some help for you in this arena. He explains how to manage statistical calculations on your collected data without eating up all the RAM. The library which he made available is targeted for the Arduino. But the concepts, which he explains quite well, should be easy to port to your preferred hardware.
The situation he outlines in the beginning his post is data collected from a sensor, but acted upon by the collection device (as opposed to a data logger where you dump the saved numbers and use a computer for the heavy lifting). This can take the form of a touch sensor, which are known for having a lot of noise when looking at individual readings. But since [Scott] is using the Mean and Standard Deviation to keep running totals of collected data over time it is also very useful for applications like building your own home heating thermostat.
For those that grabbed one of these TM1638 UI boards you can now easily use it with your Stellaris Launchpad. [Dan O] took it upon himself to publish an ARM library for the UI board.
There’s not a lot of new stuff to talk about here. We’ve already seen this being driven by an FPGA. [Dan] also links to both an Arduino and an MSP430 library for the board. The one thing that is good to know is that the board seems to run fine from the 3.3V supplied by the Stellaris Launchpad.
The ARM chip has four different hardware SPI modules which could have been used to drive this display. But [Dan] opted to bit bang instead. This give him more flexibility, like easily changing the pin mapping and foregoing the need for external components. All it takes is direct connections from three I/O pins which are used for clock, data in, and data out. We’ve embedded the obligatory demo video after the break.