Android App Updated & Uploaded
I tracked down the source of my Download % complete issue. Turns out it was an “order of precedence” issue. When calculating the % complete, I divided an integer value by a bigger integer value and multiplied by 100.0 – well, since the division operator occurred first, I was always getting 0 * 100.0. As soon as I changed the code to say 100.0 * downloadedTotal / totalFileSize – everything worked just fine.
I also made a small tweak to show sensors that had a downloaded data file but were not currently represented on the device as either a connected sensor or a remote (device) data file. The user can download a data file to the phone, then delete both the config and data file on the device. Before the tweak, the local data file wouldn’t show up at all – now it is displayed as “(local only)” in the list.
When looking around online I happened upon AChartEngine, a graphing library for Android that seemed relatively simple and powerful. I started thinking about how awesome it would be to quickly plot the data from my phone rather than pushing it to the PC, bringing it up in Excel, and plotting it within that application. As it turns out, it only took about an hour of fiddling (mostly formatting) to get a result I am very pleased with. As you can see from the screenshot, it will plot however much data is in the data file, and even breaks it into sections depending on the name the sensor has assigned to it at the time. This means you can easily and visually distinguish the various batches for a given sensor.
Because of the “(local only)” tweak I made, this also means that you don’t have to be connected to the device to display a sensor’s last downloaded data file. I don’t know how often that is going to be required, but I suppose at least when I am somewhere and want to explain the application to someone I could at least show the plotting capability.
The source code for my Android application has been uploaded to my OneDrive. It’s not perfect or pretty, but it gets the job done. I suspect I will end up writing more Android apps in the future, although I will likely do so in a different IDE – I really despise Eclipse. It crashes frequently, and is extremely temperamental.
Generation 1 Project Completions
As anticipated, my main boards for the temperature monitoring circuit came in from OshPark.com last week. The same night they arrived, I soldered a board together and hooked it up to the LCD screen and other circuit bits – and nothing displayed at all. After swallowing down a brief moment of complete panic, I deduced that I must have somehow messed up the pin 3 wiring in my schematic and PCB. When I reviewed the design, my fears were confirmed. I had tied the resistor to the 5V rail instead of GND, which meant there was basically no current flowing through that PCB pin. I decided to desolder the side incorrectly going to 5V and rather deftly (not really) rigged it into the solder pool for pin 1, which is a GND.
The updated schematic and PCB on my SkyDrive folder is now corrected. I also realized I should add some silk screening for the OneWire buses so it is clear which side is the 5V/Power side and which is GND, so that update is included as well.
One everything was working as expected, I loaded the components into the aluminum project box and mounted it on the wall next to my lagering fridge. I bounded upstairs to connect up the computer and test the Windows application I wrote (shown in the previous post)… and then spent several hours fighting with the Bluetooth. Finally I got the bright idea to go down and try to connect with my phone while standing next to the device – and it worked perfectly. Additional research revealed two key points:
- I had used a RN42XV modem, which is only a class 2 device and has maximum ranges of 7-10 meters when unobstructed by subflooring, joists, etc. There is a class 1 version, RN41XV, which has a much more powerful transmitter and greater distance… which is probably what I should have used.
- A metal enclosure (like my fancy project box) is apparently a totally AWESOME way to completely dampen the effective range of a lower power Bluetooth transmitter
My short-term solution while waiting for the class 1 to arrive was to run the transmitter outside the project box. It’s ugly – but it works. I can connect and download data to my PC now.
On another front I also basically wrapped up my Android application development. It’s not as sophisticated as the Windows application, but it doesn’t need to be. It performs the basic functions of connecting to the device:
- listing out the sensor information,
- allows for the name and frequency values to be updated, and
- the data files can be downloaded.
For someone who had never written an Android application before, and for whom it had been nearly 18 years since I wrote any Java code (the Comp Sci object-oriented design class senior year I took as an “elective”… and made all the CS majors wonder what the hell a Chemical Engineer was doing in there…) I think it turned out pretty well.
One aspect I don’t have working the way I want is displaying the % complete while downloading – basically the BluetoothSocket hangs the user interface thread while it is downloading and the %s never update until it is over and a “download complete” message pops up… but I’ll get there. I intend on posting that code on my SkyDrive as well when it is cleaned up enough.
Windows Application and LCD Bezel
I buckled down and hammered out a first generation Windows application to communicate with the Temperature Monitoring device. It’s not the prettiest, but at this point I was more interested in getting functionality working than pimping out the user interface. It connects to the device, retrieves the current device time and sensor / file settings, and allows me to change the settings as required. Basically the screenshot below shows the sum total of it (except the other menu items).
I coded it so you can either append or replace the data file locally, and you can also set it to remove the data file from the device once it is downloaded. I imagine someone would typically either append and delete OR replace and not delete – but other combinations are possible. Once the files are downloaded to the interface-configurable directory, you can either open them as a text file, or use your spreadsheet program of choice (like MS Excel) to plot out the data.
I also took some time to cut out the enclosure box face plate and fit it with the LCD and bezel, as well as the switch that turns the LCD backlight on and off, and a LED holder for the power indicator.
At this point I am pretty much just waiting for my main board PCBs to come in from OshPark. I am expecting them to arrive sometime in the next week, and will post again once I’ve got everything put together.
I have consolidated all of my code and designs into a single directory on my SkyDrive. If you are interested in any of this you are welcome to it.
Sensor Bus PCB Implementation
I began the process to implement my temperature monitoring circuit by breaking out the sensor plug board into its own PCB. This seemed to make alot of sense, as the board would be butted up against one of the enclosure’s faceplates.
It also allowed me to test out a larger implementation of my 3.5mm stereo plug idea for the DS18B20 temperature sensors. The schematic, shown here, is extremely simple and is essentially the 3 active pins for 4 3.5mm stereo plug jacks ganged together with a corresponding header pin. Once the schematic was worked out, creating the PCB was extremely easy.
I placed 4 of the jacks on each board, which is about the upper limit for the number of sensors I wanted on a single OneWire bus. Alot of reading (and some experimentation) proved to me that there is a point where too many sensors on the OneWire bus causes the whole thing to stop working – it seems related to the overall length of the sensor wire and the resistance or impedance associated with that. I am not an Electrical Engineer, so the exact cause eludes me – but I seemed to be OK so long as I had 4 or less sensors on a bus.
Once the board file was layed out in Eagle, I uploaded the design to OshPark.com and they sent it off to their fabricator to be produced. I think the 3 copies of the interface board cost me about $15, $5 of which were shipping. After a very short wait (less than 10 days), the manufactured circuit boards arrived in the mail, exactly as the OshPark renderers had depicted them.
A few minutes with the soldering iron and minor assembly with some stackable standoffs, and I had assembled interface boards to test with the prototype circuit (in place of the DS18B20s that were just plugged into the breadboard).
They worked perfectly. I plugged sensors into each of the 8 jacks, and they all registered / displayed temperatures as expected. The next step was to mount this bus (as well as some power circuitry) into the faceplate for the enclosure. I wish I could say that all of my drill holes were perfectly placed and spaced, but I’d be lying. I got the job done with a titanium step bit, but I would not characterize some of the spacings to be “snug”. It’s really hard to keep the drill from wandering when you don’t have a drill press. At any rate, the pictures below show the enclosure with the 8 sensor plugs (5 of them have sensors plugged in), the DC power jack, and the power switch.
The main board has been ordered from OshPark, and hopefully I’ll get it in a couple of weeks. I had to go through a couple iterations to have the LCD, main board, and auxiliary boards (like the MicroSD board) all oriented properly within the enclosure. I’ll post more on the main board once it comes in. For now:
- The Eagle files for the sensor bus can be found here on my public OneDrive.
- The latest version of the Arduino code is here on my OneDrive.
Temperature Monitoring Prototyping is Winding Down
Today I wrapped up prototyping activities for my bluetooth carboy temperature monitoring system. As a somewhat last minute decision I added a local LCD display that cycles through and shows the last values for each sensor and when the reading was taken. I realized it would be kind of dumb to require sitting at the PC or logging in with a smartphone to see what the current temperature readings are, especially when you are down next to the carboys while they are fermenting. There happened to be a little bit of extra memory and several digital pins left unused on the Arduino, so squeezing in the LiquidCrystal code was not too much of a problem. To see it in action, check out the video below.
The Arduino program code was re-written from almost the ground up to allow the sample frequency and “friendly name” to be configured for each sensor individually and to log the sample data in individual files. The sketch / code is available here on my OneDrive. It currently lacks sufficient comments / documentation, but I’ll get to that soon (provided I don’t need to do additional tweaks).
One of the issues I have been concerned about is creation of the temperature sensors. I have many of the TO92 package DS18B20 temperature sensors laying around, but having to solder them to 3 conductor wire, make them semi-waterproof, and connect them reliably to the main unit had me worried. I found several places online to purchase them in waterproof packages with wire attached, but typically they were >$10/ea, which is pretty steep for just 6 feet of wire. After some digging around online I happened upon these awesome waterproof DS18B20 sensors from YourDuino.com, and their 10m brothers. At $4/ea and $8/ea respectively, they are much more affordable than the state-side alternatives, even after DHL shipping from China. I’ve tested most and every single one has performed as expected.
Next I had to find a thermowell that would fit the sensors with their waterproof stainless probe. These were smaller in diameter than the other waterproof ones I saw online, but they still didn’t fit in the thermowell I purchased several years back from MoreBeer.com. This is frustrating because I paid $25 for a (useless) piece of equipment, and the size probe that would fit would have to be tiny… so back to the internet I went in search of alternatives. I scored big. I stumbled into these from Brewers Hardware, which not only have a larger internal diameter, but are higher quality and less than half the price. I still need to take a trip to the local homebrew store and pick up some undrilled carboy stoppers to use with them, but that will be a very small investment. The picture to the left shows a comparison, with the MoreBeer thermowell on the right and the Brewer’s Hardware ones on the left. I must say this is the first area that MoreBeer has really let me down – most of my equipment has been purchased from them.
I settled on using 3.5mm audio plugs for the connection between the device and the sensors. They are impossible to connect backwards, and support a 3 conductor wire which is exactly what the DS18B20s need. I purchased some inexpensive 3.5mm plugs from SparkFun.com which seem to work perfectly. The picture to the left shows how I chose to connect things – VCC at the tip, signal on the middle ring, and GND at the back.
I’ve assembled 5 of the cables – basically all the plugs I ordered – and they all seem to work, at lengths of 1m all the way up to 10m. I’ve labeled them with their unique address on pieces of painters tape (for now) so I can easily tell which sensors go into which carboys, once I get everything pulled together.
Next steps are to work up a printed PCB and get it manufactured by OshPark.com while the programming undergoes some stress testing. Then I assemble everything and fit it into the awesome project box I got for it. I also need to write a PC-side interface to configure the sensors and download the data files. Currently the only means for doing that is through a Bluetooth terminal application or connecting a USB COM bridge directly to the Arduino. The screenshot below shows output after sending a “c” command to get the current configuration settings for all sensors, and the “d2E61” command to download the data file for the “Cherry Lambic” sensor. You will notice that there were several samples taken before the “Cherry Lambic” name shows up – this will allow me to separate data from subsequent batches if I reuse a sensor.
I am very pleased with how this project is shaping up – it may be one of my favorites so far.
Bluetooth success
After much fiddling (and more than a little cursing) I managed to figure out my Bluetooth issues. Part of the issue was my lack of understanding about how the SPP COM ports worked, and part of it has to do with some hardware weirdness I am still trying to work through. I still have issues that appear to stem from programs not properly disconnecting, which results in the Bluetooth connection “hanging”, and I have to power cycle the Bluetooth module before it will allow a new connection. I think also think that either the USB Bluetooth dongle I have plugged into the PC is crappy, or the drivers are.
Out of curiosity I figured I would check to see if my phone would connect to the Arduino via Bluetooth. To my delight I was able to download a terminal program (SENA BTerm) and got it to connect. The terminal route is admittedly about as low-tech as it gets, but if you were sitting on your couch and wanted to see what temperature your fermenter are at, it could be handy. I may even attempt my first Android app… maybe. The screenshot to the left shows an example.
I am currently in the process of completely rewriting the Arduino code to allow the sensors to have different rates and to store their data in separate data files. That effort has demonstrated that I have forgotten more about programming in C than I care to admit – particularly when it comes to arrays and pointers. Working with the Netduino in a higher level language (.NET) on a platform with plenty of space has made me acutely aware of how limited the memory is on the Arduino Pro Mini, and how hard memory management used to be… but it is coming back to me slowly.
I also finally got around to kegging the 15 gallons of Pale Ale I brewed a few weeks back with a friend. I think I am all set to ride out the summer and start brewing again in the fall… and by then I will hopefully have my fermenter temperature monitoring project done!
Wireless Fermenter Temperature Monitoring (Part 2)
Today I spent a good amount of time tinkering with the components for my wireless fermenter temperature design – perhaps to the detriment of everything else I was supposed to be doing, but that’s how it usually goes for me. I’ll hammer and hammer and hammer on something until I either am frustrated beyond coping or I have it to a place I am happy with. I think I am finally at that “happy” point, for now.
As things turned out, my intended path of using the 3.3V Arduino Pro Mini wasn’t working due to the one critical detail I mentioned almost as an afterthought in my previous post… the need to integrate a Real-Time Clock (RTC) into the mix so I could accurately timestamp the data. There are quite a few RTCs out there, but very few that both work at 3.3V and are reasonably priced. The DS1307 can send its signals at 3.3V, but it has to be powered by 5V – which left me either having to have a dedicated 5V bus for just the DS1307 and bringing in a 3.3V regulator circuit, or just swapping everything out to 5V. Both the SD card breakout board and my Bluetooth breakout down-convert to 3.3V, so it was the easier path to just replace the Pro Mini with it’s 5V brother.
After many hours of fiddling and cursing, and countless uploads from the Arduino IDE – My serial output looks pretty good. I’ve got several “commands” from the PC to the Arduino working as well. Currently implemented are:
- s – Sends all data in the datalog
- sd – Sends all data in the datalog and purges it (erases it) from the SD card
- f – Forces the Arduino to take a sample immediately
- r – sets the sample rate, such as “r300” for every 300 seconds
- t – sets the clock time, such as “t20140712220000” for 12-Jul-14 11pm
The sample rate is stored and retrieved from non-volatile RAM in the DS1307, so it should survive power-downs / power-up cycles just fine. I need to find some 3V coin cell holders and integrate a battery backup for the DS1307 so the time information isn’t lost as well.
Where is the Bluetooth stuff? Yeah, I know. Remember my previous statement about hammering on something until I can’t cope with the frustration? That’s what happened first thing this morning. After about an hour of getting absolutely nowhere with it, I decided to bypass the Bluetooth and get to the good stuff shown above. Essentially I can’t get the stupid Bluetooth module to behave like a wireless serial port yet. I can pair it with the PC Bluetooth dongle, and it seems like I can even get it into config mode, but nothing comes back on the terminal window to tell me the configuration is working. I have little doubt it is from something I am doing wrong… and I will return to battle with it some other day. All the data is stored as a text file as well, so right now you could also pop out the MicroSD card and plug it into the PC and read the file directly, if you wanted.
My next step will probably be implementing the PC-side interface. It’ll be a relatively simple custom-tailored VB.NET application that allows you to connect to the Arduino, download the datalog file, and set the time and sample interval. Once I’ve got the Bluetooth stuff figured out all that can happen wirelessly without any real change in the code.
Until next time…
Wireless Fermenter Temperature Monitoring (Part 1)
Several months back a friend who knows I tinker in this nerdy electronics stuff asked me if I could develop something to help him monitor and log fermenter temperatures. My off-the-cuff answer was “of course, lemme think on it and I’ll get back to you”. At the time I was pulling BrewzNET 2.0 together and devoted most of my energy to getting that project completed… so the fermenter temperature thing was put on the back burner. Every once in a while I’d put enough thought into it to ask him some additional meaningful questions, or add my own wants/wishes to the list, and ended up with a rough requirements list:
- Better than 10 bit temperature resolution
- A new reading every 5 minutes or so
- Ability to either store data until a PC is connected, or store data on removable media, or send the data to the PC wirelessly
- Expandable to more than one fermenter
- Must fit in the thermowell with another sensor
Unfortunately that last one nearly killed the project (at least for my friend), because I have very limited options when it comes to temperature sensors. I decided this was something I wanted for my own homebrewing setup, so I’ve continued on hoping that once I’ve got a design put together he may still be interested in it.
My tentative plan is as follows:
- Use the Arduino Mini Pro 3.3V as the microcontroller platform
- Use DS18B20 one-wire temperature sensors
- Attempt to send the data to a PC using a Bluetooth module (if paired)
- Store the data locally on a microSD card regardless of whether the device is paired or not
Why these particular components?
- The 3.3V Arduino Pro Mini is the obvious choice as all of the other components require 3.3V power, and using a 5V microcontroller would mean oodles of level-switching as well as a second power regulator to step the 5V down to 3.3V – It makes more sense to run everything on 3.3V.
- The DS18B20 sensor makes the most sense in this application. It’s digital which allows longer wire runs than an analog sensor and I do not have to worry about significant signal degradation / resistance losses. It works just fine at 3.3V. It also has a better resolution than the typical 10-bit analog devices. You can also put multiple devices on the same one wire bus, which means it is expandable.
- Bluetooth seemed to make more sense than other wireless technologies, like an Xbee, because it is really just a 2-device connection – the PC and the temperature logger. My understanding is that Bluetooth is also a relatively robust protocol for sending data – it must be considering all the devices out there that use it.
- The MicroSD card seems like “extra”, but after thinking about my own experience with PCs and trying to log data to them, I realized redundancy is always a good thing. Our PC seems to lock up / crash with a greater frequency than I would like, and depending on the power settings it could be in “sleep” mode and miss data. Very few people have their PCs running 24/7, so while a Windows service could capture the communications and data “behind the scenes”, that strategy only works if the PC is running (and running reliably).
I am still trying to figure out if I need a RTC (real-time clock) like a DS1307 to pair date & time with the temperature readings. Setting the clock becomes the issue, if so… Maybe it sets the clock when the Bluetooth pairing with the PC occurs? I just don’t know yet.
This morning I was successful in putting together a basic circuit with four DS18B20s and read their data. The Arduino program was pretty easy since I just tweaked the example sketch that comes with the OneWire library, so someone else had already done the heavy lifting. The example program was comprehensive enough to support multiple sensors, so all I changed was some of the serial output and the 1-wire bus pin. The screenshot shows the four different devices (and their hexadecimal addresses), the raw data for each, and the data converted into Celsius and Fahrenheit readings.
The sensors are all configured to run off “parasite power” which means the data line charges them up when readings are not being taken, and only two wires will be required for each sensor – a ground (going to the two outer sensor pins) and a data line (the middle pin). I am going to experiment with different gauges of wire and try to get it as thin as possible in the hope that my friend will be able to use this sensor, even with his big Ranco temp controller sensor shoved in there.
The next stage will probably take the most time – getting the Bluetooth communications set up and the MicroSD card interface working. Both of these areas are brand new to me so I’ll have a learning curve to slog my way up. Fortunately the MicroSD card breakout has an excellent tutorial associated with it, and the Bluetooth COM stuff seems pretty straight-forward. I wanted to play with the Bluetooth stuff prior to posting but unfortunately the Bluetooth adapter that serves as the PC interface side has gone missing. Hopefully it will turn up soon.
White Labs Schwag Commeth – part 2
Today my beautiful wife greated me in a snazzy White Labs hoodie and a big ol’ mug of Shocktop Honeycrisp with the White Labs logo printed on it. I think she likes her goodies. 🙂
In addition I received my White Labs t-shirt, which looks great and will likely become standard uniform attire during my all-grain brewing classes at HowDoYouBrew.
I like this customer club thing. It’s silly, but I do. Yay White Labs!
White Labs Schwag Commeth – Part 1
Free Yeast!
That hopefully means that the other stuff we ordered (glassware, a hoodie, a golf shirt, etc.) will be arriving over the coming weeks.
Woot woot! Customer Club!
Sever Brews / BrewzNET 
You must be logged in to post a comment.