Archives for posts with tag: sensors

I firmly believe that every job is easier with the proper tool. Often times, when troubleshooting an issue with one of my hobby robotics projects, the proper tool is an oscilloscope. However, my hobbyist budget doesn’t allow for the purchase of a full-feature benchtop digital ‘scope. I also don’t use it often enough to justify spending a lot of money on a ‘scope. Admittedly, I also don’t know enough about all of the intricate details of fully utilizing all of the capabilities of a ‘scope. Therefore, the best solution for me is one of the many brands of inexpensive ‘scopes which rely on a PC (usually a notebook) for the display and the data capture. Through my employer I was able to get my hands on a BitScope. In this article I’d like to describe the ‘scope and my experience with it.

First off, the BitScope is shipped from Australia so they don’t generally show up overnight, just in case you require instant gratification from your electronics purchases. This ‘scope arrived in about a week, none the worse for wear.

The reason I selected this particular ‘scope was, first and foremost, because it’s officially supported in both the Linux and the Windows environments. I’m a Linux user but my employer is an all-Windows shop.

I ordered a model BS325. The back of the unit I received appears in this photo:

Image

This brought me to the first wrinkle. The sticker makes it seem like I received a BS326N. I extracted the board from the metal case (which is very easy to do and a nice part of the design) and looked closely at the board itself.

Image

The board is clearly labeled “BS325N” but the sticker on one of the modules clearly states “BS326N”. At this point I assumed those two model numbers are equivalent.

As I mentioned earlier, this unit only has an Ethernet interface. BitScope also includes a crossover cable, for a direct connection between the ‘scope and my notebook computer. Herein I encountered the next wrinkle.

I attached the crossover cable to the ‘scope and my Windows notebook. The Data LED lit solid but not the Link LED. I moved the cable to my Linux notebook but saw the same behavior. Through some more experimentation, I’ve since determined that the labels on the LEDs are switched: The LED labeled “Data” is actually the “Link” LED. Again, not really a big deal.

The next thing to do was to actually configure and try the software. BitScope includes a CD with the software for Linux, Macintosh and Windows. Seeing this warmed my heart. I installed the software on my Windows notebook and my Linux notebook. Then I attempted to connect the software to the ‘scope. Yes, next wrinkle.

The page in the included paper manual looks like this:

Image

Since I had ordered a BS325N, the board said BS325N and the stickers said BS326N, I assumed I should use the factory IP address for the BS325N. Nope. The IP address actually assigned to the ‘scope was 192.168.1.73, the one listed for the BS310N. Once again, not a big deal.

I did manage to start the software, connect it to the ‘scope and query the ‘scope. The Windows software identifies the ‘scope as a “BS032600”, by the way. I made a few simple tests and played with the software a bit. I tried the same simple tests on my Linux notebook, but the bitscope-dso software complains and then aborts.

I’m still satisfied with the ‘scope and happy to have it. Obviously, their manufacturing quality control needs some improvement but it’s not keeping me from using the tool. I had also contacted BitScope Technical Support when I was looking at the lack of Link issue. It took them almost two days to respond and I was disappointed to receive the all-too-common Technical Support response. Essentially, I was told “This is almost certainly your problem. Check your firewall and network configuration”. The Technical Support staff apparently either didn’t read my note or doesn’t understand networking issues.

Next, I plan to use the ‘scope to troubleshoot some actual conditions in my lab. I’ll provide some more details on how the device worked for me.

Advertisements

I live in a building with five other units. This building has a shared source of hot water. This single, shared source has a 120 gallon reservoir and supplies all of the hot water for the kitchens, dishwashers, clothes washers, bathrooms, showers and bathtubs in the building. On a recurring basis, occupants are complaining about the water not being hot enough or being simply not heated at all. Being an engineer and an environmentalist (and a bit of a curmudgeon) I decided to look closer at the situation.

The water supply to the building is from the municipal source. It is heated by a gas-fired unit, separate from the reservoir. As mentioned earlier, the reservoir has a 120 gallon capacity. The system also has a pump which keeps heated water circulating through the entire building, regardless of a demand. This recirculation pump runs non-stop.

I thought the way to understand the system was to measure the water temperature at various points and to measure the flow of water. I found a water flow meter from Badger Meter  to measure the flow. I used 1-Wire temperature sensors to measure the temperature and a LinkUSB device to collect the data from the 1-Wire devices. I used a LabJack U12 to capture the flow data from the meter. All of this data was collected by an old notebook computer which I attached to a sheet of plywood and then hung on the basement wall.

The Badger Meter was used to measure the total volume of water flowing through the water heating system. I installed it on the cold input, instead of the hot output, in order to stay within the operating temperature range of the meter.

The 1-Wire devices were used to measure the temperature of the system at various points. I didn’t want to actually penetrate any of the plumbing, in order to avoid creating leaks. Since all of the plumbing for the system consists of copper tubing, I used heat sink compound and electrical tape to attache the sensors directly to the plumbing. I used a total of six sensors, at the following locations:

  1. the ambient air temperature surrounding the system
  2. the heated water output from the reservoir
  3. the recirculation loop return
  4. the municipal supply
  5. the flow into the heating unit
  6. the flow out of the heating unit and into the reservoir

The last and possibly most important piece of this entire system was the software which I used to collect and process all of the data. I wanted to accomplish several things:

  1. understand how the system worked and how the temperatures were related to each other
  2. understand how much water we used on average
  3. send advance notice of an impending hot water shortage
  4. record sudden large increases in consumption
  5. confirm or deny an actual outage
  6. understand the conditions leading up to an outage

The software which collected and processed all of the data was rrdtool and a program which I wrote in Python. This software captured the sensor data every 60 seconds, archived and processed it. If measurements exceeded thresholds, an E-mail message was sent to interested parties.

I’ll describe the specific details of the system in the next article. I was surprised, and a bit disgusted, by what I learned about the usage of hot water in my building.