Hacking an AUX Port for a Google Home Mini

Even if you don’t want to add an AUX audio output port to your Google Home Mini, you’ll still want to see a pair of videos from [SnekTek]. After all, you’ll eventually want to open it up, and putting it over some boiling water might not have been your first idea. You can see both videos, below.

However, he did want to add an AUX port. The biggest challenge was finding a place to put the connector. Even after identifying a likely spot, a bolt interfered with the case closing and so he removed it. The one bolt didn’t seem to bother the final result.

Electrically, he found that to keep the AUX out to about 1V, he needed a reduction in voltage. Two small resistors put right in the speaker line took care of that. Although, be sure to watch the second video if you plan to recreate this hack since the value of the resistors changed.

Truthfully, the AUX jack part isn’t nearly as interesting as opening the thing up, although we have to admit, we wouldn’t mind putting a BlueTooth adapter in that plug to stream to a big speaker that isn’t cast-enabled. However, we have noticed it is getting harder and harder to break into consumer electronics, and you never know when you’ll need to get into one of these to hack, repair, or cannibalize.

With the cheaper mini version of the Google smart device, we expect to see more hacks for it. We’ve seen some creative mash ups and, of course, you can always roll your own hardware.

Filed under: google hacks

from Hackaday Click Here for full article

This Coin Cell Can Move That Train!

[Mike Rigsby] has moved a train with a coin cell. A CR2477 cell to be exact, which is to say one of the slightly more chunky examples, and the train in question isn’t the full size variety but a model railroad surrounding a Christmas tree, but nevertheless, the train moved.

A coin cell on its own will not move a model locomotive designed to run on twelve volts. So [Mark] used a boost converter to turn three volts into twelve. The coin cell has a high internal resistance, though, so first the coin cell was discharged into a couple of supercapacitors which would feed the boost converter. As his supercaps were charging, he meticulously logged the voltage over time, and found that the first one took 18 hours to charge while the second required 51 hours.

This is important and useful data for entrants to our Coin Cell Challenge, several of whom are also going for a supercap approach to provide a one-off power boost. We suspect though that he might have drawn a little more from the cell, had he selected a dedicated supercap charger circuit.

 

Filed under: Toy Hacks

from Hackaday Click Here for full article

Using Gmail with OAUTH2 in Linux and on an ESP8266

One of the tasks I dread is configuring a web server to send email correctly via Gmail. The simplest way of sending emails is SMTP, and there are a number of scripts out there that provide a simple method to send mail that way with a minimum of configuration. There’s even PHP mail(), although it’s less than reliable.

Out of the box, Gmail requires OAUTH2 for authentication and to share user data, which has the major advantage of not requiring that you store your username and password in the application that requires access to your account. While they have an ‘allow less secure apps’ option that allows SMTP access for legacy products like Microsoft Outlook, it just doesn’t seem like the right way forward. Google documents how to interact with their API with OAUTH2, so why not just use that instead of putting my username and password in plaintext in a bunch of prototypes and test scripts?

Those are the thoughts that run through my head every time this comes up for a project, and each time I’ve somehow forgotten the steps to do it, also forgotten to write it down, and end up wasting quite a bit of time due to my own foolishness. As penance, I’ve decided to document the process and share it with all of you, and then also make it work on an ESP8266 board running the Arduino development environment.

Before we continue, now would be a good time for a non-technical refresher on how OAUTH works. The main differences between OAUTH and OAUTH2 are that the latter requires HTTPS, and the access tokens that allow an application to use specific services in a user account have an expiry.

To use Gmail with OAUTH2, we will need to start with five things: An application registered in the Google APIs, its client ID and client secret, a computer running LAMP (a by-the-hour VPS works just fine here), and a domain name that points to it.

Registering an application with Google API is easy. Go to the Google API console, log in, create a new project, and enter it. Enable the Gmail API; it should be suggested on the front page.


With the project created and the Gmail API enabled, the dashboard should look something like this

Then click on ‘credentials’ on the sidebar, create credentials, and finally ‘create OAUTH Client ID’. Before you can continue, you need to create a consent screen. The only entry you really need to fill out at this time is ‘Product Name Shown to Users’.

After saving that form, select ‘Web Application’ as your application type. Note the field called ‘Authorized redirect URIs’, we’ll return to it later. It’s important that it be correctly set for us to be able to receive a refresh token later on in this process.

For now, just press ‘Create’. A pop-up will display containing your Client ID and Client secret. You’ll need them soon, so best to copy/paste them into a local file on your computer for now.

Next, we will use those two pieces of data to request an access token and refresh token. We may as well accomplish two things at the same time here by installing the popular PHP email sender called PHPMailer on our web server. It includes a tool to request an OAUTH2 access/refresh token as well as being easily capable of sending a quick test email. To install it, we’ll use the Composer PHP dependency management tool:

$sudo apt-get install composer

Then we should navigate to our web-accessible directory, in my case /var/www/html, and install a few PHP scripts. Note that this should not be done as root, so create another user if needed and give them access to the directory:

$composer require phpmailer/phpmailer
$composer require league/oauth2-client
$composer require league/oauth2-google

Now enter the directory vendor/phpmailer/phpmailer. There will be a script called get_oauth_token.php. Move this script up three directories into the directory you just ran the ‘composer’ commands from. The location of this script as seen from the web needs to be entered into the ‘Authorized redirect URIs’ field of the Google API that we saw earlier. In this case it would have been http://ift.tt/2j5Mb34. Public IP addresses will not work, this is why a domain name pointed to your web server is a requirement.

Now, open get_oauth_token.php in a text editor and paste in your Client ID and Client Secret where needed. Don’t try to run the script locally, it will fail. Open up a web browser on any computer, and navigate to the URL you entered as the ‘Authorized redirect URI’. Then select Google from the list of email services – at this point if it worked you will be asked to log in and then authorize the unverified application, under ‘Advanced’ under the warning prompt, at which point you will finally receive a refresh token. If you only want an access token for some reason you’ll have to edit the script to echo it back.

If that didn’t work, there are two common reasons: a wrong redirect URI or the script cannot find its dependencies. In the former case, the error message from Google will tell you the script URL as it sees it, and you can use that information to update the redirect URI in the Google API Console to fix the issue. For the latter, check your apache error log, probably located in /var/log/apache2/error.log, to see what dependency is not being found. You might see something like this:

PHP Warning: require(vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/mydomain/get_oauth_token.php on line 59, referer: http://ift.tt/2zdiAxk

If you have received your refresh token, congratulations: the painful part is over. You can just go to the PHPMailer Github page and fill out their OAUTH2 example (gmail_xoauth.phps), and it ought to just work. If all you needed to do is send mail from a project on your VPS, you’re more or less ready to move on to more interesting parts of your project:

$email = 'someone@gmail.com';
$clientId = 'RANDOMCHARS-----duv1n2.apps.googleusercontent.com';
$clientSecret = 'RANDOMCHARS-----lGyjPcRtvP';
//Obtained by configuring and running get_oauth_token.php
//after setting up an app in Google Developer Console.
$refreshToken = 'RANDOMCHARS-----DWxgOvPT003r-yFUV49TQYag7_Aod7y0';

Remember to clean up any unnecessary scripts that contain your refresh token and other sensitive data before continuing.

ESP8266: We Don’t Need No Stinking Servers

Now what if we wanted to use these tokens to send email directly from project on a Raspberry Pi without needing a server in the middle? It turns out that once we have the client ID, client secret, and refresh token, we no longer require the server and domain name we’ve been using so far, and a mail-sending application, e.g. PHPMailer, can be installed on a computer anywhere with Internet access as long as it is configured with those values.

Things get a little more complicated when we try to do this on an ESP8266. OAUTH2 requires that we use SSL, and access tokens regularly expire and need to be refreshed. Thankfully, [jalmeroth] generously wrote a proof-of-concept and published it on GitHub. If provided with an access token, it can access your Gmail account and use it to send an email. It can also directly update/get data from Google Sheets, but I didn’t test this. However, if the access token was expired, it couldn’t detect that, although it did include working code to actually request a new token, but not parse it out and use it.

In an attempt to add to the functionality of that proof of concept, I forked the project and made a few changes. First, I changed to order of operations in the code to make it check if the current access token was valid before doing anything else. Second, Google API was responding ‘400 Bad Request’ if the access token was invalid, and everything but ‘200 OK’ responses were being filtered out by the code. Finally, I wrote a couple of JSON parsers that check the reason for the ‘400 Bad Request’ and extract and use the access token returned by Google API when a new one is requested.

It works, but it’s hardly reliable – not surprising considering I’ve never really used the Arduino platform before. Notably, the SHA1 fingerprint for Google API fails often. Checking from my local machine, the SHA1 fingerprint varies between two signatures there too. It would be fairly easy to check for either of them, or just keep trying, but I’d rather understand what’s going on first. (Is it just a CDN or something else?) Or perhaps I should rewrite the whole application in Lua where I’m more competent.

A fun little application built on the above was to place a button on my office that sends an email to my phone. I don’t want people to contact me at that email address frivolously, but do want to know immediately if someone is waiting outside my office. The big red button is for normal requests, but urgent requests require lockpicking. If it’s urgent it better also be interesting.

Finally, did you know that Hackaday provides an API for accessing hackaday.io? It uses the simpler OAUTH (not OAUTH2) authentication, so should be more straightforward than the above to implement on the ESP8266. Have any of you used it?

Filed under: Arduino Hacks, google hacks, how-to, Original Art

from Hackaday Click Here for full article

Friday Hack Chat: Eagle One Year Later

Way back in June of 2016, Autodesk acquired Cadsoft, and with it EagleCAD, the popular PCB design software. There were plans for some features that should have been in Eagle two decades ago, and right now Autodesk is rolling out an impressive list of features that include UX improvements, integration with MCAD and Fusion360, and push and shove routing.

Six months into the new age of Eagle, Autodesk announced they would be changing their licensing models to a subscription service. Where you could pay less than $100 once and hold onto version 6.0 forever, now you’re required to pay $15 every month for your copy of Eagle. Yes, there’s still a free, educational version, but this change to a subscription model caused much consternation in the community when announced.

For this week’s Hack Chat, we’re going to be talking about Eagle, one year in. Our guest for this Hack Chat is Matt Berggren, director of Autodesk Circuits, hardware engineer, and technologist that has been working on bringing electronic design to everyone. We’ll be asking Matt all about Eagle, with questions including:

  • What new features are in the latest edition of Eagle?
  • What’s on the Eagle wishlist?
  • What technical challenges arise when designing new features?
  • Where can a beginner find resources for designing PCBs in Eagle?

Join the chat to hear about new features in Eagle, how things are holding up for Eagle under new ownership, and how exactly the new subscription model for Eagle is going. We’re looking for questions from the community, so if you have a question for Matt or the rest of the Eagle team, put it on the Hack Chat event page.

If you’re wondering about how Altium and KiCad are holding up, or have any questions about these PCB design tools, don’t worry: we’re going to have Hack Chats with these engineers in the new year.

join-hack-chat

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat is going down on noon, PST, Friday, December 15th. Time Zones got you down? Here’s a handy count down 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.

Filed under: Hackaday Columns

from Hackaday Click Here for full article

The Zombie Rises Again: Drone Registration Is Back

It’s a trope of horror movies that demonic foes always return. No sooner has the bad guy been dissolved in a withering hail of holy water in the denoeument of the first movie, than some foolish child in a white dress at the start of the next is queuing up to re-animate it with a careless drop of blood or something. If parents in later installments of popular movie franchises would only keep an eye on their darn kids, it would save everybody a whole lot of time!

The relevant passage can be found in section 1092(d) of the National Defense Authorization Act, on page 329 of the mammoth PDF containing the full text, and reads as follows:

(d) RESTORATION OF RULES FOR REGISTRATION AND MARKING OF UNMANNED AIRCRAFT
.—The rules adopted by the Administrator
of the Federal Aviation Administration in the matter of registration
and marking requirements for small unmanned aircraft (FAA-2015-
7396; published on December 16, 2015) that were vacated by the
United States Court of Appeals for the District of Columbia Circuit
in Taylor v. Huerta (No. 15-1495; decided on May 19, 2017) shall
be restored to effect on the date of enactment of this Act.

This appears to reverse the earlier decision of the court, but does not specify whether there has been any modification to the requirements to prevent their being struck down once more by the same angle of attack. In particular, it doesn’t change any of the language in the FAA Modernization Act of 2012, which specifically prevents the Agency from regulating hobby model aircraft, and was the basis of Taylor v. Huerta. Maybe they are just hoping that hobby flyers get fatigued?

We took a look at the registration system before it was struck down, and found its rules to be unusually simple to understand when compared to other aviation rulings, even if it seemed to have little basis in empirical evidence. It bears a resemblance to similar measures in other parts of the world, with its 250 g weight limit for unregistered machines. It will be interesting both from a legal standpoint to see whether any fresh challenges to this zombie law emerge in the courts, and from a technical standpoint to see what advances emerge from Shenzhen as the manufacturers pour all their expertise into a 250 g class of aircraft.

Thanks [ArduinoEnigma] for the tip.

Filed under: drone hacks, News

from Hackaday Click Here for full article

Truly Terrible Dimensioned Drawings

I’m in the planning stages of a side project for Hackaday right now. It’s nothing too impressive, but this is a project that will involve a lot of electromechanical parts. This project is going to need a lot of panel mount 1/8″ jacks and sockets, vertical mount DIN 5 connectors, pots, switches, and other carefully crafted bits of metal. Mouser and Digikey are great for nearly every other type of electrical component, but when it comes to these sorts of electromechanical components, your best move is usually to look at AliExpress or DealExtreme, finding something close to what you need, and buying a few hundred. Is this the best move for a manufacturable product? No, but we’re only building a few hundred of these things.

I have been browsing my usual Internet haunts in the search for the right bits of stamped brass and injection molded plastic for this project, and have come to a remarkable conclusion. Engineers, apparently, have no idea how to dimension drawings. Drafting has been a core competency for engineers from the dawn of time until AutoCAD was invented, and now we’re finally reaping the reward: It’s now rare to find a usable dimensioned drawing on the Internet.

This post is going to be half rant, half explanation of what is wrong with a few of the dimensioned drawings I’ve found recently. Consider this an example of what not to do.  There is no reason for the state of engineering drawing to be this bad.


Example One: It Gets Worse The More You Look At It

This first example comes from Bitches Love My Switches, an unfortunately-named storefront, but one that does have a lot of neat switches and jacks with a warehouse on the East Coast with quick shipping. If you want some jellybean parts for guitar pedals and associated audiophilia, it’s a nice place to know. This store doesn’t manufacture their own switches, and with that comes the problem of datasheets and dimension drawings. These drawings were made by a random engineer somewhere, and this person has no training in dimensioned drawings.

Let’s work through a design problem using the dimension drawing shown above. This is a PCB-mounted, switch, that is meant to have a nut holding it down to a panel. Think of it as a PCB standoff, only it’s a switch. This switch can be used as a mechanical, structural part of an enclosure.

To design anything using this switch, you need to know the height of every part of this switch, from where it attaches to the PCB, to where the nut will screw on. You need to know the height of the switch body. This dimension is completely absent in this drawing, making the drawing absolutely useless. The dimension you need to design anything using this switch is absent. But this drawing gets worse.

What if you wanted to know the height of the ‘toggle’ that physically moves in this switch. It’s labeled in the drawing as 9.5 mm, but this dimension is useless at best, and wrong with even the most liberal interpretation. Why? Because the toggle pivots. The tip of this toggle moves in an arc, and the tip will be ‘longer’ in the middle of its swing than it is in either of its latched positions. A real dimensioned drawing would include the 9.5 mm dimension and the angle of the toggle in the latched position so you can figure out the actual maximum height of the switch.

Want to hate this drawing even more? Sure thing. What sized nut goes on the threaded portion? Exactly. This isn’t a swing at the store selling these switches, but it is indicative of some terrible practices across the entire electronics industry. Somehow or another, everyone forgot how to create useful dimensioned drawings.


Example Two: All Loudspeaker Manufacturers Meet at Bohemian Grove

The project I’m working on will also need a speaker. The general specs are a 3-4 inch diameter speaker that can handle five Watts. I’m not looking for quality here, but I am looking for something I can design an enclosure for before I order it.

A speaker is a remarkably simple device. There’s a coil and a magnet, two terminals, a paper cone, and a metal flange with four holes around the perimeter of this flange, offset ninety degrees from each other. Nearly every generic loudspeaker will follow this prototype, and if you’re building an enclosure for a speaker, there are really only three things you need to know: the diameter of the hole you need to cut out, the depth of the speaker, and how far apart the screw holes on the flange are. I only need three dimensions here. I’m a simple man. I’m also extremely disappointed.


Mounting information for Celestion’s AN2075 loudspeaker. Guess what’s missing?

Celestion is a very highly regarded manufacturer of loudspeakers. They’ve been around for ninety years, they created the first metal-dome tweeter, and produce what is said to be the standard in guitar amp speakers. If you’re in the loudspeaker industry, Celestion is where you want to be. Surely they can come up with datasheets and tech specs that would be useful, right? Think again. Their AN2075 loudspeaker lists the overall depth of the speaker, the cut-out diameter, and the overall size of the of the speaker. How far apart are the mounting holes? Screw you, that’s how far apart they are. This isn’t even ‘drafting’ or ‘engineering drawing’. This is just incomplete information.


One of the better drawings of speaker dimensions on AliExpress

Celestion is not alone. Take a look at AliExpress. If you’re looking for small, cheap speakers that can handle ten or fifteen Watts, you have thousands of choices. Virtually none of them will have the relevant information on their product pages. Yes, you’ll usually get the dimensions of the flange, and you might get how deep the speaker actually is. You will rarely find where to put the screw holes on your project enclosure.

I’m not one to believe conspiracies. People are just too self-interested to be part of a cabal of evil bent on distorting the truth or ruling people. It’s the media theory of Chomsky versus Žižek; self-interest rules all. People are too stupid to organize. This may be the best evidence yet that conspiracies exist. There must be a conspiracy between loudspeaker manufactures. None of them have dimensions of where the holes should go.


Example Three: Jacks

This project will also make use of DIN 5 connectors (but not as MIDI jacks), and these must be panel mount connectors. Nearly every DIN 5 connector you’ll see on Mouser or Digikey is a right angle connector. That is to say, you solder the connector to the board, and the DIN 5 connector comes out at a right angle to the PCB. This isn’t what I want — I want a connector sticking straight up out of a board. Yes, these connectors exist, but again we’re left with incomplete dimensioned drawings, like the one I found on AliExpress below:


First, take a look at the photograph of the part. It’s what you would expect for a DIN 5 connector. There are five pins, and an additional grounding pin for the shield of the connector, just like every other DIN 5 connector on the planet. Take a look at the drawing. It’s actually not bad, and even gives me a preferred PCB footprint for five of the pins. But what about that grounding pin? It is absent on the dimensioned drawing. If you buy a thousand of these and run them through an assembly line, you’ll quickly find you have to snip off all the grounding pins before populating them into boards. The data is just missing, and you’re a fool if you engineer something directly from the drawings. You should be able to engineer something from the drawings, and this panel mount DIN 5 connector is a terrible product.


Any University That Has Dropped Their Drafting Class Is Doing A Disservice To Their Students

Since time immemorial until the late 90s and early 2000s, engineering drawing and drafting was a required course for all engineers. This is the class with T-squares and triangles and a hidden emphasis on developing fine motor control through lettering. Only a week or two of this class was devoted to dimensioned drawings, but this week is vital to all engineers. Your drawings are useless unless someone else can use them, and you can’t do that without properly dimensioned drawings.

I don’t know why I keep running into truly terrible dimensioned drawings. This is a required skill for all engineers, regardless if they’re educated in China, England, or the US. Yet it’s nonexistent everywhere except for the McMaster Carr catalog.

If you’d like to learn about how to make dimensioned drawings, I’d suggest picking up [French]’s Engineering Drawing. Yes, the book is 100 years old, but what it teaches hasn’t changed in 200 years. This is how the draftsmen for the Apollo Lunar Module learned how to draw. Yes, lettering is hard if you don’t have the right pencils and have underdeveloped fine motor control, but we’re using computers now anyway. Read this book, learn how to properly dimension drawings, and stop annoying engineers who are trying to build stuff.

Filed under: Engineering, Featured, Original Art, Rants

from Hackaday Click Here for full article

ADSL Robustness Verified By Running Over Wet String

A core part of the hacker mentality is the desire to test limits: trying out ideas to see if something interesting, informative, and/or entertaining comes out of it. Some employees of Andrews & Arnold (a UK network provider) applied this mentality towards connecting their ADSL test equipment to some unlikely materials. The verdict of experiment: yes, ADSL works over wet string.

ADSL itself is something of an ingenious hack, carrying data over decades-old telephone wires designed only for voice. ADSL accomplished this in part through robust error correction measures keeping the bytes flowing through lines that were not originally designed for ADSL frequencies. The flow of bytes may slow over bad lines, but they will keep moving.

How bad? In this case, a pair of strings dampened with salty water. But there are limits: the same type of string dampened with just plain water was not enough to carry ADSL.

The pictures of the test setup also spoke volumes. They ran the wet string across a space that looked much like every hacker workspace, salt water dripping on the industrial carpet. Experimenting and learning right where you are, using what you have on hand, are hallmarks of hacker resourcefulness. Fancy laboratory not required.

Thanks to [chris] and [Spencer] for the tips.

Filed under: Network Hacks

from Hackaday Click Here for full article

CNC’d MacBook Breathes Easy

Sick of his 2011 Macbook kicking its fans into overdrive every time the temperatures started to climb, [Arthur] decided to go with the nuclear option and cut some ventilation holes into the bottom of the machine’s aluminum case. But it just so happens that he had the patience and proper tools for the job, and the final result looks good enough that you might wonder why Apple didn’t do this to begin with.

After disassembling the machine, [Arthur] used double-sided tape and a block of scrap wood to secure the Macbook’s case to the CNC, and cut out some very slick looking vents over where the internal CPU cooler sits. With the addition of some fine mesh he found on McMaster-Carr, foreign objects (and fingers) are prevented from getting into the Mac and messing up all that Cupertino engineering.

[Arthur] tells us that the internal temperature of his Macbook would hit as high as 102 °C (~215 °F) under load before his modification, which certainly doesn’t sound like something we’d want sitting in our laps. With the addition of his vents however, he’s now seeing an idle temperature of 45 °C to 60 °C, and a max of 82 °C.

In the end, [Arthur] is happy with the results of his modification, but he’d change a few things if he was to do it again. He’s somewhat concerned about the fact that the mesh he used for the grill isn’t non-conductive (he’s using shims of card stock internally to make sure it doesn’t touch anything inside), and he’d prefer the peace of mind of having used epoxy to secure it all together rather than super-glue. That said, it works and hasn’t fallen apart yet; basically the hallmarks of a successful hack.

It’s worth noting that [Arthur] is not the first person to struggle with the Macbook’s propensity for cooking itself alive. A few years back we covered another user who added vents to their Macbook, but not before they were forced to reflow the whole board because some of the solder joints gave up in the heat.

Filed under: cnc hacks, computer hacks, Mac Hacks

from Hackaday Click Here for full article

Building A Drone That (Almost) Follows You Home

There’s a great deal of research happening around the topic of autonomous vehicles of all creeds and colours. [Ryan] decided this was an interesting field, and took on an autonomous drone as his final project at Cornell University.

The main idea was to create a drone that could autonomously follow a target which provided GPS data for the drone to follow. [Ryan] planned to implement this by having a smartphone provide GPS coordinates to the drone over WiFi, allowing the drone to track the user.

As this was  a university project, he had to take a very carefully considered approach to the build. Given likely constraints on both money and time, he identified that the crux of the project was to develop the autonomous part of the drone, not the drone itself. Thus, off-the-shelf parts were selected to swiftly put together a drone platform that would serve as a test bed for his autonomous brain.

The write up is in-depth and shares all the gritty details of getting the various subsystems of the drone talking together. He also shares issues that were faced with altitude control – without any sensors to determine altitude, it wasn’t possible to keep the drone at a level height. This unfortunately complicated things and meant that he didn’t get to complete the drone’s following algorithm. Such roadblocks are highly common in time-limited university projects, though their educational value cannot be understated. Overall, while the project may not have met its final goals, it was obviously an excellent learning experience, and one which has taught him plenty about working with drones and the related electronics.

For another take on autonomous flight, check out this high-speed AI racing drone.

Filed under: drone hacks

from Hackaday Click Here for full article

Will Hack For Espresso

[Avidan Ross] has an unyielding passion for coffee. Brewing a proper espresso is more than measuring fluid ounces, and to that end, his office’s current espresso machine was not making the cut. What’s a maker to do but enlist his skills to brew some high-tech coffee.

For a proper espresso, the mass of the grounds and the brewed output need to be precisely measured. So, the office La Marzocco GS3 has been transformed into a closed-loop espresso machine with a Particle Photon and an Acaia Lunar waterproof scale at its heart.

On the software side, to run the ‘smart brew’ function a make espresso button press is emulated, and the mass of the brewed espresso is constantly measured. Once the argument’s ‘target output mass’ is reached the firmware shuts off the machine. Brew time is then reported, allowing [Ross] or others to adjust the grind of the espresso beans to fine-tune to the recipe.

The next step is to phase out the human element of adjusting the grind — luckily there are some perfectly hackable solutions there. Fine espresso will fuel that endeavour in the meantime!

[Via Medium]

Filed under: home hacks, Microcontrollers

from Hackaday Click Here for full article

1 2 3 28