Friday Hack Chat: How Do You Collaborate With Hardware?

February 7, 2018 by Brian Benchoff 6 Comments

The world of Open Source software is built on collaboration. In one corner of the world, someone can fix a bug in a piece of software, and push it up to the gits. In another part of the world, someone else can put that fix into the next release, and soon everyone has newer, better software. The Internet, or the ability to rapidly transmit text and binary files, has made this all possible.

Hardware is another story. There’s a financial barrier to entry. Not only do you need a meter and a good iron, you’re probably going to need oscilloscopes, logic analyzers, and a bunch of other expensive tools. You’ll need to buy your BOM. If you’re using a PIC, it might be a good idea to buy the good compiler. Hardware is hard and expensive, and all those software devs who complain don’t know what they’re talking about. Collaborating on hardware is much more difficult than pushing some code up to the cloud.

For this week’s Hack Chat, we’re going to be talking about collaborating on hardware projects. This is a deep dive on how to make collaboration with physical objects work, and this week we’re going to be learning from some of the best.

Our guests for this week’s Hack Chat are Pete Dokter and Toni Klopfenstein of SparkFun Electronics. Pete is formerly the Director of Engineering at SparkFun and now the Brand Ambassador for SparkFun Electronics. He hosts the According to Pete video series expounding on various engineering principles and seriously needs a silverburst Les Paul and a Sunn Model T. Toni is currently the product development manager at SparkFun. She’s served on the Open Source Hardware Association Board and participates in the Open Hardware Summit yearly. In her free time, she spends fifty weeks out of the year finding dust in her art and electronics projects.

During this chat, we’re going to be discussing what makes a collaborative hardware project, how to make distributed development work for your team, and the limits of what you can do with several hardware engineers separated by thousands of miles. This is a hard problem, much harder than a distributed team of software engineers, and a fantastic discussion for all.

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat is going down Friday, February 9th at noon, Pacific time. Time Zones got you down? Here’s a handy countdown timer!

Click that speech bubble to the left, and you’ll be taken directly to the Hack Chat group on Hackaday.io.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Discrete Pong Project Goes Big, Adds A Player

February 7, 2018 by Dan Maloney 13 Comments

Some projects just take on a life of their own. What started as a pleasant diversion or a simple challenge becomes an obsession, and the next thing you know you’ve built a two-player color Pong game with audio completely from discrete components.

If this one seems familiar, it’s because we were dazzled by its first incarnation last year. As impressive as version 1.0 was, all the more so since it was built using the Manhattan method and seemingly over the course of a weekend, it did have its limitations. [GK] has been refining his design ever since and keeping accurate track of the process, to the tune of 22 pages on the EEVblog forum. We haven’t pored through it all yet, but the state of the project now is certainly worth a look. The original X-Y output to an oscilloscope was swapped out to composite video for a monitor, in both mono and color. This version also allows two people to play head-to-head instead of just battling the machine. It looks like [GK] had to add a couple of blocks worth of real estate to his Manhattan board to accommodate the changes, and he tidied the wiring significantly while he was at it.

It’s a project that keeps on giving, so feast your eyes and learn. We suspect [GK] doesn’t have any plans to finish this soon, but if he does, we can’t wait to see what’s next.

Thanks to [David Gustafik] for reminding us to check back on this one.

Locally Sourced: PLA Adhesive

February 7, 2018 by Tom Nardi 61 Comments

When I first started getting into 3D printed projects that would require final assembly from multiple parts, I wanted to make sure I had an adhesive that would really hold up. I couldn’t imagine anything worse than spending 10’s of hours printing and assembling something, only to have it fall apart because my adhesive wasn’t up to the task. So I spent a lot of time trolling 3D printing message boards and communities trying to find the best way of gluing PLA. It should come as no surprise that, like everything else in the world, there are a ridiculous number of opinions on the subject.

If you’re printing with ABS, the general wisdom is that solvent welding with acetone is the best bet. You put some acetone on the printed parts, rub them together, and the plastic fuses together. This happens because the ABS melts slightly when exposed to the acetone, so they end up essentially melding into one piece. This sounded like exactly what I wanted, but unfortunately, acetone doesn’t have this same effect on PLA.

After some more research I found people suggesting Weld-On #16, an acrylic adhesive that will actually melt PLA. A little of this applied to the parts, they said, and you can solvent weld PLA just like acetone on ABS. Sure enough, the stuff works great and I’ve used it to put together nearly everything I’ve printed in PLA over the last few years. Only problem is, this stuff is a bit nasty, takes 24 hours to fully cure, and nobody has it locally.

So as an experiment I thought I’d take a look at a few adhesives sold at the local big box retailer and see if I couldn’t find something comparable. Do I need to keep ordering this nasty goop online every time, or can I pick something up off the shelf? More to the point, is solvent welding PLA really any better than just gluing it?

Continue reading “Locally Sourced: PLA Adhesive” →

Debugging An Arduino With An Arduino

February 7, 2018 by Tom Nardi 15 Comments

As every Hackaday reader knows, and tells us at every opportunity in the comments, adding an Arduino to your project instantly makes it twice as cool. But what if, in the course of adding an Arduino to your project, you run into a problem and need to debug the code? What if you could use a second Arduino to debug the first? That would bring your project up to two Arduinos, instantly making it four times as awesome as before you started! Who could say no to such exponential gains?

Not [Wayne Holder], that’s for sure. He writes in to let us know about a project he’s been working on for a while that allows you to debug the execution of code on an Arduino with a second Arduino. In fact, the target chip could even be another AVR series microcontroller such as a the ATTiny85. With his software you can single-step through the code, view and modify values in memory, set breakpoints, and even disassemble the code. Not everything is working fully yet, but what he has so far is very impressive.

The trick is exploiting a feature known as “debugWIRE” that’s included in many AVR microcontrollers. Unfortunately documentation on this feature is hard to come by, but with some work [Wayne] has managed to figure out how most of it works and create an Arduino Sketch that lets the user interact with the target chip using a simple menu system over the serial monitor, similar to the Bus Pirate.

[Wayne] goes into plenty of detail on his site and in the video included after the break, showing many of the functions he’s got working so far in his software against an ATTiny85. If you spend a lot of time working on AVR projects, this looks like something you might want to keep installed on an Arduino in your tool bag for the future.

Debugging microcontroller projects can be a huge time saver when your code starts running on real hardware, but often takes some hacking to get working.

Continue reading “Debugging An Arduino With An Arduino” →

DARPA Enlisting Nemo And Dory To Find You

February 7, 2018 by Roger Cheng 9 Comments

The ocean is a hostile environment for man-made equipment, no matter its purpose. Whether commercial fishing, scientific research, or military operations, salt water is constantly working to break them all down. The ocean is also home to organisms well-adapted to their environment so DARPA is curious if we can leverage their innate ability to survive. The Persistent Aquatic Living Sensors (yes, our ocean PALS) program is asking for creative ideas on how to use sea life to monitor ocean activity.

Its basic idea is simple: everyday business of life in the ocean are occasionally interrupted by a ship, a submarine, or some other human activity. If this interruption can be inferred from sea life response, getting that data could be much less expensive than building sensors to monitor such activity directly. Everyone who applies to this research program will have the chance to present their own ideas on how to turn this idea into reality.

The program announced it will “study natural and modified organisms” (emphasis ours.) Keeping an open mind to bio-engineering ideas will be interesting, but adding biohacking to the equation also adds to the list of potential problems. While PALS will keep its research within contained facilities, any future military deployment obviously will not. Successful developments in this area will certainly raise eyebrows and face resistance against moving beyond the lab.

But such possibilities are still far away in a future that many never arrive, as is common with DARPA initiatives. Very recently we talked about their interest in brain stimulation and we’ve been fascinated by many DARPA initiatives before that. If PALS takes off, their living sensor nodes might end up face to face with the open-source underwater glider project that won this year’s Hackaday prize.

[via Engadget]