Testing Six Hundred Fish

December 14, 2013 by Brian Benchoff 16 Comments

fish

That’s the best and most obtuse title you’ll ever see for a Hackaday post, but surprisingly it’s pretty accurate. [Bob] over at the Sector67 hackerspace took part in a 111-day accelerator program in Shenzhen last year to improve his manufacturing skills. He’s just about ready to release his first product, a Bluetooth device that connects to an ice fishing tip-up. The blog for the device recounts the challenges of taking a project from a circuit to a finished product, and illustrates the difference between building something with an Arduino and selling thousands of devices.

The circuit boards for BlueTipz come in panels of eight, but what’s the best way to populate and solder five thousand devices in a reasonably short amount of time? [Bob] hired a few students from the local college to help him out in assembling all these devices. The plastic enclosures were made at a local plastics manufacturer, but the molds were made in China. The manufacturer needed to modify the molds a bit, but after a few days, [Bob] had five thousand enclosures ready to stuff full of electronics.

With the devices assembled, it’s time for programming, and that means building a programmer. [Bob] put all the guts for the device into a plastic box and 3D-printed a mount for the bare BlueTipz board. Put a board on the mount, press a button, and the tech now has a functioning device in his hands.

Besides manufacturing, there’s also a whole lot of testing that went into the design of BlueTipz. Because this is a device for ice fishing—a cold and potentially windy operating environment—[Bob] built a test rig in a freezer. The test rig triggers the device’s sensor, waits two minutes (the amount of time it would take for an ice fisherman to check the tip-up) and resets. They claim the battery life is good for 600 fish, and with this testing rig they were able to verify their calculated battery life with real-world data: without actually catching six hundred fish, of course.

Not only does [Bob] have a good bit of product development under his belt, he was also kind enough to go over the stuff everyday electronic design just doesn’t cover. Developing a product is something you can only learn by doing, and we’re glad [Bob] chose to share his experiences with us.

Reverse Engineering Serial Ports

December 14, 2013 by Phillip Ryals 13 Comments

Can you spot the serial port in the pic above? You can probably see the potential pads, but how do you figure out which ones to connect to? [Craig] over at devttys0 put together an excellent tutorial on how to find serial ports. Using some extreme close-ups, [Craig] guides us through his thought process as he examines a board. He discusses some of the basics every hobbyist should know, such as how to make an educated guess about which ports are ground and VCC. He also explains the process to guessing the transmit/receive pins, although that is less straightforward.

Once you’ve identified the pins, you need to actually communicate with the device. Although there’s no easy way to guess the data, parity, and stop bits except for using the standard 8N1 and hoping for the best, [Craig] simplifies the process a bit with some software that helps to quickly identify the baud rate. Hopefully you’ll share [Craig’s] good fortune if you reach this point, greeted by boot messages that allow you further access.

Developed On Hackaday: Setting Up The Project’s Infrastructure

December 13, 2013 by Mathieu Stephan 22 Comments

We’re pretty sure that most of our readers already know it by now, but we’ll tell you anyway: the Hackaday community (writers and readers) is currently developing an offline password keeper. In the first post of our first DoH series, we introduced the project and called for contributors. In the comments section, we received very interesting feedback as well as many feature suggestions that we detailed in our second write-up. Finally, we organized a poll that allowed everyone to vote on the project’s name.

The results came in: the project’s name will be mooltipass. We originally had thought of ‘multipass’ but [asheets] informed us that Apple and Canon had both applied for this trademark. [Omegacs] then suggested ‘mooltipass’ as an alternative, which we loved even more. A few days ago we set up a google group which is already very active.

An often under-estimated side of a community driven project is its infrastructure and management. (How) can you manage dozens of motivated individuals from all over the globe to work on a common project? How can you keep the community informed of its latest developments?

Continue reading “Developed On Hackaday: Setting Up The Project’s Infrastructure” →

Developed On Hackaday: First Feedback From Users

December 9, 2013 by Mathieu Stephan 54 Comments

Holy cr*p guys… we were amazed by the quantity of positive feedback that was left in the comments section of our last article. We have been featured by Slashdot ! We got plenty of project name suggestions, therefore we organized a poll located at the end of this post to let you decide which one is best. I also received many emails from people eager to start contributing to this offline password keeper project. If you missed the call and want to get involved, it’s still not too late. You can get in touch with me @ mathieu[at]hackaday[dot]com. So far, we have many beta testers, several software developers, one security assessor and a few firmware developers. Next step is to create a mailing list and a Hackaday forum category once the project’s name has been chosen.

Obviously, the very first post of our “Developed On Hackaday” series was to gauge your initial reactions to this ‘new’ project. Notice here the double quotes, as when someone has a new idea there usually are only two possibilities that may explain why it doesn’t exist in the market yet: either it is completely stupid or people are already working on it. In our case, it seems we are in the second category as many readers mentioned they wanted to work/were working/had worked on a similar product. As we’re selfish, we offered them to contribute to this new device.

To ensure that all of our readers are on the same page as to how the device will work we embedded a simple block diagram after the break, as well as a list of all new functionalities that we want to implement given the feedback we received. So keep reading to see what the future holds, as well as to vote on this new project’s name…

Continue reading “Developed On Hackaday: First Feedback From Users” →

Developed On Hackaday: Let’s Build Some Hardware!

December 6, 2013 by Mathieu Stephan 142 Comments

We’re pretty sure that most of you already know that a few months ago Hackaday was bought by SupplyFrame, who therefore became our new evil overlords. We do hope you’ve noticed that they’re actually quite nice, and in their divine goodness they recently gave the go-ahead on this series called Developed on Hackaday.

A new project will be made by the Hackaday staff & community and will hopefully be brought to the consumer market. For those who don’t have the time/experience to get involved in this adventure, we want to show and document what it takes to bring an idea to the marketable product stage. For the others, we would like to involve you in the design/development process as much as possible. Obviously, this project will be open source hardware/software. This time around, the hardware will mainly be developed by yours truly. You may already know me from the whistled platform (currently sold on Tindie) or from all the different projects described on my website, which makes this new adventure far from being my first rodeo.

What’s in it for the contributors? During all the steps of this project, we’ll offer many rewards as well as hand-soldered first prototypes of the device so you can start playing/testing it. Nothing is set in stone so every suggestion is welcome. Should we make a Kickstarter-like campaign to manufacture the final product, we’ll only do so once our prototype is final, our partners are chosen and all details of the production process are set and confirmed. In that case, we will just need to gather the required funds to make the device a reality. What are we going to build? Keep reading to find out.

Continue reading “Developed On Hackaday: Let’s Build Some Hardware!” →

Using Ultrasonic Sensors To Measure And Log Oil Tank Levels

December 4, 2013 by Mathieu Stephan 52 Comments

[Mike] lives in a temperate rainforest in Alaska (we figured from his website’s name) and uses a 570 gallon oil tank to supply his furnace. Until now, he had no way of knowing how much oil was left in the tank and what his daily usage was. As he didn’t find any commercial product that could do what he wanted, he designed his own solution. In his write-up, [Mike] started by listing all the different sensors he had considered to measure the oil level and finally opted for an ultrasonic sensor. In his opinion, this kind of sensor is the best compromise between cost, ease of use, range and precision for his application. The precise chosen model was the ping))) bought from our favorite auction website for around $2.5.

[Mike] built the custom enclosure that you can see in the picture above using PVC parts. Enclosed are the ultrasonic sensor, a temperature sensor and an LED indicating the power status. On the other side of the CAT5 cable can be found an Arduino compatible board with an XBee shield and a 9V battery. Using another XBee shield and its USB adapter board, [Mike] can now wirelessly access the tank oil level log from his computer.

Easy Capacitive Touch Sensors In Eagle

December 4, 2013 by Brian Benchoff 18 Comments

board

Capacitive sensing libraries for the Arduino and just about every other microcontroller platform have been around for ages now, but if you’d like to put a slightly complex cap sense pad in a PCB without a lot of work, you’re kind of out of luck. Not only do you need a proper education in how capacitors work, but a custom cap sense pad also requires some advanced knowledge of your preferred PCB layout program.

The folks over at PatternAgents have just the solution for this problem. They created an Eagle library of touch widgets that includes everything from buttons, linear and radial sliders, touchpads, and a whole lot more.

The simplest cap sense pad is just a filled polygon on the top layer of a board, but this simple setup isn’t ideal if you want to use Eagle’s autorouter. By playing with the restrict layers in Eagle, PatternAgents were able to create easy cap sense buttons that will work perfectly, without the problems of the autorouter placing traces willy-nilly.

There are more than enough parts to replicate a whole lot of touch interfaces – buttons can easily be made into a smallish keyboard, and the radial touch sensor will emulate the ‘wheel’ interface on an iPod. Very cool stuff, and we can’t wait to see these in a few more boards.