I’m happy to announce that the osPID is now officially back in stock at Rocket Scream. There have been some improvements to the hardware (usb micro instead of mini, louder buzzer, etc,) but mostly this was about getting a more reliable supply chain in place.
Thanks to everyone for being so patient during this dry spell. The changes we’ve made should insure that moving forward, when you want an osPID you won’t have to wait.
I’ve just uploaded both firmware and front-end updates to github. There have been numerous tweaks and improvements, be here are the high points:
Rather than hard-coding a reflow profile, we went with a more flexible approach. Using 3 different commands (setpoint STEP, setpoint RAMP, input WAIT) you can piece together a sequence that gives you your desired result.
Different profiles are stored as files on the desktop side. One profile at a time may be loaded onto the osPID and executed. The profile is stored on the osPID EEPROM, so loading is only necessary when you wish to change the profile.
IO Card support
The previous version of the firmware was pretty much hard-coded for the digital output card and temperature input card. This firmware breaks out all the IO code into a separate file, where pre-compiler flags let you specify which cards are being used. This should simplify card-swaps and prototype-card usage.
The previous version of the firmware made awful use of the osPID’s resources. It used WAY more RAM than necessary, and only left 5k of free program space. In addition to adding a bunch of new features, the new firmware is much better on RAM usage, and leaves over 9k of free program space. This means that if you have the itch to hack the osPID, there’s actually some room for you to do so.
There’s always more work to be done, but I’m pretty happy with what we’ve managed to accomplish with this revision. As always, let us know if we messed up; everyone will benefit.
Huge thanks go out to Phil, who apart from identifying some early bugs has presented us with our first “in the wild” pictures!
He spent an hour or two the last couple of nights setting up a sous-vide rig: Two immersion heaters, a circulation pump, and a k-type thermocouple.
It’s hard to argue with results my friends. Being an engineer, there’s always a part of me that’s waiting for that huge flaw that I missed, the thing that will make what I did a complete failure. But it has not come to pass. osPID = tasty results. I’m over the moon.
With the first osPIDs making their way to customers, we’ve started receiving our first feedback emails.
The most obvious point made so far is that we were lacking a quick-start guide. I’ve since created a preliminary page for this here. This is a work in progress, but should give you everything you need to get up and running.
The second prominent issue was that the input card wasn’t reading correctly. This is strictly a firmware issue related to the switch from the MAX31855 back to the MAX6675. What this means is that everyone will need to update their firmware. DOH! The quick-start explains how to do this.
There will undoubtedly be more issues as the days go by. PLEASE complain to us. We will fix it and everyone will benefit. The only way we will be great is if we are told when we suck.
Just a quick post to let everyone know that shipping has started. The first units went out today! all boards are re-flowed/assembled, Just need to test, pack, and ship. Here are some pics to tide you over until your osPID arrives:
Things are finally rolling at osPID HQ. All of our parts are either on site or in transit, and production will being as soon as everything arrives.
That’s the good news. The less-good news is that we’ve had to push back our planned ship date. Originally we were planning on shipping this week. Unfortunately we’ve had to push that back to the week of 2/19.
With every delay it’s good to have a scapegoat, and we’ve got one! Maxim Electronics. On the prototype temperature card, we used their MAX6675 thermocouple chip. For the production model, we decided to use their newer (and less expensive) MAX31855 chip.
When we went to order the MAX31855 however, instead of the initially advertised January delivery date, the date had been revised to July. JULY! We checked various suppliers, but this seems to be an issue with Maxim itself.
So, faced with a choice between a 6 month delay and a more expensive chip, we decided to eat the cost and revert the board back to the MAX6675 configuration we had used in the prototype.
During this whole debacle we lost our place in line with the PCB manufacturer and had to re-submit our order. Unfortunately this put us on the other side of Chinese New Year.
And that brings us to today. We want to apologize for both the delay and the chip swap. If you had your heart set on the MAX31855, know that from a financial perspective so did we. We have a board designed and ready for that chip. Once supplies of the are more reliable we will transition to it.
Wow. What an amazing first week-or-so. Hackaday, Adafruit, BoingBoing, and Make. It’s almost too much to ask! Thanks to everyone for the positive feedback.
In the midst of this there is one recurring concern that I wanted to address. Many people seem to be comparing this thing to the $30 PID controllers you can get on ebay. I want to take this opportunity to highlight some of the features that set the osPID apart from the low-end competition.
More Sensor Interfaces
By default, the osPID can read either a K-Type thermocouple or a Thermistor. With more input cards on the way (RTD, Voltage, etc..) this allows you to use the osPID in more situations.
Desktop Configuration / Graphing Application
When configuring and monitoring a PID controller, having a graph in front of you is indispensable. The osPID comes with a free (and Open) java application that allows you to interact with the controller from the desktop. You’ll be hard-pressed to find this with any PID controller, and if you do it’ll cost you.
Settling on the correct P, I, and D parameters can be time consuming. Most expensive PID controllers provide an “autotune” which automatically determines good values. The osPID has this. Many cheap controllers do not.
Open Hardware / Software
If your $30 PID controller breaks, or it doesn’t do something you’d like it to, you’re stuck. The osPID is completely open. All software, hardware plans, and firmware code is freely available to download and modify. If you want it do something different, go for it! If a bug is discovered, it can be fixed and downloaded by everyone.
Initially from me, but ultimately (hopefully) from a community of people that have been there, with this specific controller.
So yes. It costs $85
What we have here isn’t an open knock-off of a $30 PID controller. The osPID has, in many cases, better functionality than even a $200 PID controller. Combine this with an unprecedented level of hackability and community, and I’d say that makes this a pretty good buy. (OF COURSE I would say that, but hopefully you agree.)