This week I used the laser to cut some holes in my enclosures to make way for switches, light pipes, etc. My previous attempts pre-hackerspace (with a dremel) were.. rough.
There had to be a better way! The big problem with using the laser was jigging the case in the laser in such a way that I could reliably and repeatedly cut in the perfect spot. After a few attempts I found a solution.
First I exported my front board dimension and mill holes from Eagle using run -> dxf.ulp, opened it in our laser program, mirrored it and adjusted some holes and sizes.
I grabbed a square piece of stock and dropped up the in the upper corner of the laser and homed the laser head. Now, by lasering that outline on my stock, I can take it out of the machine and put it back in the same place every time.
I can also match the PCB up over the top of the etch.
And, finally, since the PCB is designed to fit the case perfectly, I can just drop the case on top of the PCB.
Wonderful. I could still use a method to cut cleaner on the other 4 sides, but for now Im happy doing a little bit of clean up work and having my cuts be entirely though the case.
Colin loaned me his Pebble until he gets back into town next month and I haven’t seen anyone else in our circle review it, so here goes.
Who Needs the Time?
First some setup. I don’t wear watches and almost never have. Its a modality I think underutilized and one I’ve still intend to design for, but the truth is I haven’t found anything with enough value to wear on my wrist over the 31 years of my life.
Thus I was incredibly surprised to find that after even ONE day of Pebble usage, I felt naked without it.
Fit, Finish, Setup
First the boring stuff. I’ve found the watch to be very pleasant I’m proud to wear it on my wrist daily. It does slightly rotate off my wrist which I find annoying, but perhaps this could be solved with a new or longer watch band. Further I’ve found the build quality to be pretty good. Theres a slight rainbow-ing on the screen apparently due to the glue process, but I can live with it.
It was extremely easy to set up. I’m sad to report that as usual the locked down iOS ecosystem loses out on the majority of the notifications, only receiving phone calls, texts, and music information and control. Even though it sounds limiting, thats actually enough for me to recommend the pebble with just those few notifications. However, I went the extra mile and used my jailbreak to full push notifications which I highly recommend.
Music
It turns out Music is one of my favorite features. I listen to podcasts constantly and people typically approach me have to wait for me to dig into iPhone menus in order to pause my audio. With the watch, I found I actually kept my screen on the music control app, rather than the watch, and could, with one button press, pause and play my music. Handy!
Vibration alert
What REALLY surprised me about the watch, however, was how blown away I was by the vibrator in the watch. Most people know that I’ve been doing research and development in haptics for several years now. I obviously understand the benefits of haptics and am somewhat biased, but I was curious to see what I’d think of the real world implementation.
I immediately found it incredibly freeing. As we all know phantom vibrations have completely poisoned the haptics well when it comes to our phones. We can’t leave them on vibrate because in the back of our mind we know that is as good as turning them off.
With vibration on my wrist I found I didn’t worry about missing anything on my phone and I was happy to silence it permanently. I also loved using vibration as my alarm. I hate alarms and they don’t tend to even wake me up so adding vibration to my wrist really was a fun and new way to wake up. It should be noted that Pebble actually deals with alarms in its own OS, not in iOS, but besides this setback I found alarms easy enough to set and delete.
I did, however, find one big problem with using the watch as an alarm.
Battery Life
I’m sorry to report I’m getting only two days under typical use. Im not sure if thats backlight, vibration or bluetooth communication issues, but I’m ready to sacrifice something, ANYTHING, in order to get more battery life. They may be able to patch some of this in, but its definitely the weak point of the system.
This is worsened by the need for a proprietary magnetic charger cable. I have to keep yet one more cable, or more likely I don’t have the cable I need and theres a useless monolith tied to my wrist all day.
Wrap up
In conclusion if I have anything negative to say about the Pebble is I feel they may have done too much, which is not surprising the way it was scope creep developed in public. Battery life seems to be suffering, charging suffers presumably due to the need to get water proofing at X feet deep, etc etc. Maybe eventually we’ll be able to disable some of the software based features in order to save battery life, but right now we’re stuck.
That is we’re stuck with a device which can’t call anything other than incredible. I can’t image what I’m going to do when I have to give it back to Colin.
Recently for a client project I needed to read credit card data to an Arduino. It didn’t seem like it would be too hard or expensive since square gives out readers by the handful for free. I was only mildly familiar with the technology so I turned to wikipedia who told me the data is stored on Looks like track 1, format b.
A quick search on Sparkfun for an existing solution found their offerings to be HUGE and expensive! We wanted to embed some solution in a phone size package. Why is square able to make them so small and give them out free? Thus began my journey to destroy every card reader out there.
SQUARE
First a little googling led to a teardown of the original square reader. I still tore mine apart anyway and found the same thing they found. The reader is literally a tapehead positioned perfectly to hit track 1, nothing more! Not even an amp! Basically they did as much in software as they possibly could. Good job!
We wouldn’t be using a phone jack in our solution and wouldn’t have much processing power for cleaning the signal, but we spent some time trying to amp the signal and read the data. The signal was clearly evident and ampable, but our timeline didn’t include reinventing card readers.
In my research I found that Square had actually updated their model to add encryption. The update was touted for security, but I have trouble believing someone could man in the middle your headphone jack. A much more likely reason is using encryption to lock out the rise of the copycat mobile payment solutions like Intuit and Paypal. And of course to stop people like me from tracking down and repurposing handfuls of them.
We surveyed our friends and found one of them in the wild to crack open. Sure enough theres now a coin cell battery and TI micro in there and the signal is nonsense.
INTUIT (circle)
The first Intuit reader I took apart was THEIR v1 as well.
It used a e42407bj from Magchip and a f1936 from Microchip that seemed to either be for encryption. Some digging from my partner Tim turned up a similar part at IDTech that was very close to what we had which showed it actually output serial! Clearly they were simply in a rush to get to market and repurposed some existing silicon. Pricey for them, good for us.
I tried to locate more readers for cheap, but they were on their v2 now.
When I finally tracked one down and tore it apart they’d transitioned off the Magchip chip for a custom solution with encryption :(
So close!!!
The PAYPAL (triangle)
The Triangle is the most beautiful device of the bunch. The front cover is actually removable — presumably for rebranding? The case, however, is impossible to get open. You can see my hacksaw damage in the photo above.
Inside it looks a lot like these other second gen readers though with a ton more passive components. We’ve got a 8L151G ST Micro and an op amp package 6l04ste from Microchip. Presumably reading the signal and encrypting it for their app.
Again it makes this device not at all hackable and shows nobody going into this business at this point is going to leave their devices open any more.
MAGTEK
At this point Tim just looked up magchip readers and we found another company called Magtek. It turns out they actually have a fully implemented chip and tape head solution that outputs RS232. They’re something like $15-25 in low qty which meant if we were doing anything other than a functional prototype they’d be no good, but they would fit our custom solution just fine. We were able to successfully implement the Magtek solution with no real problems and were very happy with the responsiveness. Sadly I didn’t write the code, so if you want to see it please hassle Tim into posting the code he wrote so you can benefit from our work too!
If you’ll remember from previous posts my wishlist was to upload thumbnails(which should be available in metadata) instead of full images, do that in descending order from time shot so that if we have an internet outage we don’t get behind, and probably do that in batches so we only use the wifi for some small amount of time out of lets say an hour.
Over Christmas break Zach Giles brought down his Flu Card we’ve been wanting to play with. We were hoping this little Eye-Fi clone, running linux, would allow us to make smarter upload decisions allowing us to do live uploads from the GoPro.
What we were able to do was exactly that and more—Check out Zach’s first post to see what and how we did.
Now the bad news. The Flu Card doesn’t start the linux partition properly on the Go Pro 3 when in timelapse mode. Single shot seems to work ok, but thats not what our current technology is using. Timelapse works fine on the Hero2, but we get less than half battery life there and were expecting probably a 50% reduction in battery due to wireless meaning the only feasible place to do this is on the Hero3.
We picked up the Hero3 to test with our current mods. Our understanding is this is basically the Hero2 in new packaging, though about half as deep and with an advertised battery life claim of something like 8 hours! We put it to the test with our boards one photo a minute, and got 28 hours of battery life! For reference I was getting ~18 hours on the Hero1 at one photo a minute. The only downfall of the new design is it uses a microsd card, which stops us from using the eyefi which is currently only sold in an SD format. A bunch of googling brought me to the KZ-B19-065, an SD to MicroSD converter which I found for sale on ebay. Sadly, the Gopro either doesn’t love the added resistance of the traces, or it just doesnt settle into the slot the same as a typical SD card. Ive had it work for hours at a time and I’ve also had it crap out after one photo.
The new camera allowed Colin to take another crack at the design and put more than an hour into it this time. He also sourced some lanyard material and quick clasps so we have some nice custom lanyards! The result is gorgeous and Ive already gotten several compliments on it.
We now have geotagged photos and our uploads occur automatically at the end of the day via ftp! Thanks EyeFi!
————-
I bought the new EyeFI pro x2 today mainly because it supports FTP and wifi geotagging. We figured we might be able to get some of these features ‘free’ without designing them into our board right this minute.
Ideally it would be fun to have live shots of us as we go through our day, a lot like our hackerspace cam were you can see whats up with everyone at the lab.
In our testing it still takes at least 30 seconds and often more like 45 to get a single shot uploaded. I’ve found I can upload 0-3 photos within a minute depending on network congestion. However, the EyeFI does successfully get SSID data for geotag within our usual ~8 seconds on period! Note: The geo tagging happens at the server side where they appear to use skyhook. They add your GPS exif data and send it on to whatever service you’ve configured, ftp, flickr,etc. so you have to ‘upload’ it to get the exif data.
We want to avoid being on more than a minute, because the GoPro will take another photo because its intervalometer mode were (which takes a photo a max of once every 60 sec when you turn the camera on— we just turn it off)
The next problem is we would have to be on wifi at all times. Sadly the EyeFI uploads OLDEST first, which means if we miss an upload window we’ll get further and further behind in our uploading. If we could get the EyeFI to upload the NEWEST we could sidestep that issue until charge time.
One option to maintain wifi all day is tethering to a data plan, but we’re looking at 1.5GB data a day generally. I’m already a heavy data user getting throttled so that probably won’t work. Ideally it would be best if we could upload thumbnails throughout the day and do a full dump at night, but again not an option with the EyeFI, nor does the GoPro generate thumbnails (except maybe in exif data?). There are other EyeFI style cards nowadays. Specifically we’re looking into the FLU card which runs some kind of embedded linux with scripts, perhaps we can control more there?
But for now, were just going save to the EyeFI all day (probably with some battery hit while it scans for SSIDs) and at the end of the day plug the card into the pc allowing uploads and tagging to occur all night while we sleep (though limiting our ability to cam our sleep).
Recently my hetero life partner Colin Ho and I turned a Go Pro Hero into a lifelogger camera. I’ve wanted to do life logging forever but never got my stuff together so when Colin brought in the camera in and made the challenge, I was in.
Take a look at Colin’s post, but basically, we pulled some code, schematics and a pinout from this guy and set to implementing it all in one night at our hackerspace HeatSync Labs. I laid out the board in Eagle and etched it Colin did up all the mechanical designs (laser and 3d printed). The only speciality part we needed was an iPhone connector which, since this is a hackerspace, we had stashed around ;) The result is hosted on Our Git.
Colin has been using the camera for ~3 weeks while traveling and Ive been using it for about a week. In my tests at approximately 2 pictures per minute I’m getting 18h hour battery life on a used old Go Pro Hero.
The daylight results are awesome. The camera placement with the fish eye lens is perfect. Im picking up conversation partners, meals, a great view of my laptop, phone, and any projects I’m hacking on.
The only problem is blurriness in ~50% of shots. Basically without knowing if the shot is being taken we’re not staying still. We may want to turn on the Go Pro’s audible beep again, or do something light or haptic based to notify of the impending shot, but theres an argument for not changing my life or becoming aware of when shots are being taken.
The real drawback so far has been the low light response which is TERRIBLE. Blurriness probably goes up over 75% especially if theres ANY motion. For a worst case scenario I took it out to a nightclub (where I drank and danced way too much for photos anyway) and only got maybe ten usable photos out of a thousand!
This was an average GOOD shot! Still, I got ten awesome photos I wouldn’t have had otherwise.
To get around this I’m going to up my shot rate and expect to throw away half of my photos. Related: Anyone seen anything to detect and rate photos based on focus?
Take a look at more results over at my flickrnew server!
Of note, the Hero 3 was just announced. It is half thickness from the Hero 2 and can do eight hours on intervalometer so we may just be able to use that camera out of the box without external modification. However, there may still be a reason for us to add some buttons and lights to make the hero a frendlyier life cam. We’re certainly happy enough with the results to keep playing!
Recently some people at our hackerspace HeatSync Labs asked for me to update them on The State of Body Computing. This is a topic I love and try to follow closely and am even working on several products aimed at this market. Specifically I see the Body Modification community as the most promising vector to Body Computing — at least until doctors and the FDA will talk to us (right).
I vastly prefer to stay positive and have some sort of rally action but as I kept researching, writing and re-writing my talk I found myself somewhat disappointed. In my research I ran across a video I forgotten about—Quinn Norton’s 23C3 talk on Body Modification. Re-watching it surprised me as to how little has changed since 2006.
In the end I decided my call to action would be to right this sad state of affairs by compelling body moders and hackers to work together.
Of note, right after I finished done speaking a friend emailed me Shannon from BME Zine’s interview over at IO9. To put words in his mouth he said weve got great interest right now in functional body modification, but we need to get everyone together and talking. Vindication!
For my ongoing Arduino watch project, we want to be able to do frequency detection in order to blink an led to bass hits.
There are a few Fast Fourier Transforms that have been written on Arduino including this one and this one. However, I needed my library to run on 8mhz clock along with whatever sampling rate change that would introduce. All the libraries I found were extremely optimized or poorly written with no abstraction so that I found it easier to start from scratch than attempt to use them.
So I set about figuring out how to implement something myself. I quickly learned about something called the Goertzel algorithm for when you actually only need to find a single frequency, vs a whole range, allowing all the savings you would expect from that. I found a few generic implementations of that as well on wikipedia and EEtimes but nothing specifically for Arduino. I tried implementing the generalized version on wikipedia but had lots of trouble with datatypes and my ability to properly debug on Arduino hardware. The EE times implementation’s link was broken but some google-fu found it the demo code. It was written in C that I could compile on my laptop and get sane results. Then I could move it to Arduino slowly while maintaining those sane results. With this method I was able to keep everything working as I transitioned the code to a full Goertzel Arduino library.
I’m looking for feedback on how it should be implemented. Should it do the sample, or work on your existing array of samples? Is there an easier way to expose N and target frequency, perhaps some calculation or default? Let me know!
This was an average GOOD shot! Still, I got ten awesome photos I wouldn’t have had otherwise.