Monitoring your Gas Consumption with a JeeNode and a nRF24L01+

[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.

Meet Lynx, a (costly) Offline Password Keeper

Maybe because he didn’t want to wait for the Mooltipass to be produced, [davidhend] built himself his own offline password keeper, named Lynx.

It is based around an Arduino Pro 328, a 2.8″ TFT touch screen, an RFID card reader, an FTDI basic breakout and finally a li-ion battery. Lynx is therefore self-powered and uses an RFID card to later read the XOR-encrypted passwords located in a SD card. A USB serial connection is used to send the passwords to the computer, which also charges the battery. The current BoM cost is around $220 but we’re quite sure it can be made for much cheaper when not using pre-made boards. Looking at the official GitHub repository tells us that the XOR key is stored inside the microcontroller and that Lynx checks the RFID card code to allow encryption/decryption.

On a side note, we recently published a FAQ on the official Mooltipass GitHub. You’re welcome to let us know what questions we may have forgotten.

GEVCU – an Open Generalized Electric Vehicle Control Unit

At Hackaday we’re very happy to see the increasing number of open hardware devices that appear everyday on the internet, and we’re also quite thrilled about open-source electric cars. Pictured above is the GEVCU, an open source electric vehicle control unit (or ECU). It is in charge of processing different inputs (throttle position, brake pressure, vehicle sensors) then send the appropriate control commands to electric motor controllers (aka inverters) via CAN bus messages or digital / PWM signals.

The project started back in December 2012 and was originally based on an Arduino Due. Since then, the GEVCU went through several revisions and ultimately a complete custom board was produced, while still keeping the Cortex M3 ATSAM3X8E from the Due. As you may have guessed, the board also includes a Wifi transceiver so users may adjust the ECU parameters via a web based platform. All resources may be downloaded from the official GitHub.

Listening to Electromagnetic Interference with a RTLSDR Dongle

Being curious by nature, [Marios] decided to see what kind of radio-frequency emissions may be generated by an Arduino connected to a simple breadboard wire, and more importantly try to pick them up using a RTLSDR dongle. Electromagnetic interferences are disturbances that affect electrical circuits due to either electromagnetic induction or electromagnetic radiation. Before going into the market, all electrical devices are thoroughly checked for unwanted electromagnetic emissions so they usually aren’t obvious suspects when such problems arise.

Using the Arduino embedded PWM controller in fast PWM mode and by manipulating the duty cycle, he actually managed to create a primitive form of amplitude modulation and was able to transfer a very simple audible signal at several frequencies up to 1.75GHz. Embedded after the break here is video of the system at work.

As a side note, did you know that during the solar storm of 1859 the EMI were so strong that the telegraph operators received several shocks? Pipelines maintenance systems also have to be aware of such events, that can lead sensors to provide inaccurate results.

[Read more...]

Developed on Hackaday: Security and Arduino Compatibility

2013-12_Developed_on_Hackaday

Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.

Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.

Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.

What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.

Cordwood Puzzle Kit Without Instructions

Cordwoodcircuit.agr

What you see above is a cordwood circuit, an interesting circuit construction technique from before the days of integrated circuits. The circuit consists of two circuit boards arranged parallel to each other with components holding them apart. This was, for its day, the densest circuit construction technique, used in everything from late 50s aerospace tech to huge computers that filled rooms.

The folks over at Boldport have a love for interesting PCBs and are apparently aficionados of antiquated tech, leading them to create their own cordwood circuit. Here’s the best part: it’s a kit, without assembly instructions.

The cordwood puzzle assembles into a bunch of LEDs that will light up when power is applied. Not much, but there’s a few FETs in there that allow you to control them all individually with a microcontroller. The real fun is trying to assemble the kit: both sides of the cordwood circuit are identical, meaning there’s going to be holes that aren’t meant to be filled, components that will need to be soldered, and most likely a bit of swearing.

Still, this is an exceptionally small circuit for something using this construction technique. If you know of a denser and more modern cordwood circuit out there, leave a note in the comments. If you want to know what the kit looks like when it’s built, [Phil Wright] has your back.

Developed on Hackaday: Coding Conventions and GitHub Pull Requests

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

main(void)
{
    if (foo)
    {
        functionCall();
    }
    else
    {
        foo = 0;
        anotherFunctionCall();
    }
}
- 79 characters line length as a soft requirement
- 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.