I spent yesterday morning working on the datalogger, specifically making it WiFi capable. This morning, I slept in, made my coffee and checked the news. Over on Hackaday, Jose has created an Arduino/Pi/WiFi/X-Bee environmental monitor. He's got his own webspace, uc4fun, where he's hosting the notes on his project. A lot more professional looking than mine.
He's essentially doing my project (If he knows I exist, he's shaking his head saying "That guy's doing MY project"). However, he's doing it in a completely different fashion, which is awesome. I think he's using a mix of I2C sensors (he's using the TMP102 and the BMP085) and a Sparkfun humidity sensor (Dude! New Product Friday.... 'cuse me while I go browse...).
I think he went with the doubled up microprocessor approach because it allows him to use the ADC's on the Arduino. So far, I've been severely limited in the sensors I can use on my build because I'm only using I2C and binary digital sensors. His complexity gets him some serious advantages, but is also one of the main things I want to avoid (He's probably writing code for both the Arduino and the Pi. That'll give me headaches). I sent him a message on the Hackaday board asking why he made the choices he did. Looking at his build and presentation, he's going to have some good answers.
I definitely wanted to avoid the multiple radio links. Given my history with RF links, I'd like to keep that as simple as possible.
As I'm moving closer and closer to medical school, I seem to be doing less and less medicine. From helping build a local bar as a volunteer (a worthy cause, in my book), to hack-building cool gadgets. I'm picking up bizarre skill sets left and right. This is adding to the already diverse skill sets I had acquired on my previous jobs. I'll detail my rants, raves and experiences here.
Showing posts with label Equipment. Show all posts
Showing posts with label Equipment. Show all posts
Friday, January 11, 2013
Parallelism in Hacking
Labels:
BMP085,
Builds,
Computers,
DIY,
Equipment,
Hackaday,
Hacks,
I2C,
logger,
logging,
node,
project,
Python,
Raspberry Pi,
sensors,
Sparkfun,
tech,
techniques,
Technology,
TMP102
Sunday, December 16, 2012
Integrating the TMP102 sensor with the datalogger, and I2C bus lengths
The TMP102 is an I2C sensor available on a breakout board from Sparkfun TMP102. It's pretty cheap, under $10. It will actually allow you to have multiple sensors on the same I2C bus just by jumpering an address pin.
I'm working on creating a software module to decode the output from the sensor. So far it isn't straight forward, at least for an amateur. If I understand correctly, the sensor reports the readings in a backwards fashion. I'm not sure I've decoded the output correctly, but I'm close. Once I get that ironed out, I'll post the code up.
I started playing with I2C bus lengths. I heard that the practical length was less than a meter. I've got around a 2-3 meter CAT-5 cable set up running the TMP102. It's dangling outside the window, inside a tupperware container, and appears to be working just fine. I'm using Sparkfun RJ-45 Jacks and breakout boards. It adds a couple of bucks to the cost of the project, but it makes for great modularity. It's also going to let me do some cable run tests. Eventually I'll post those up as well.
I modified the jacks and breakout boards slightly. In place of a simple header, I used Arduino 8-pin stackable headers. That way, I can easily add a second sensor (or more) at the cable end, while still being able to easily breadboard it. So far it's working great.
The goal with this setup is to have two sets of environmental sensors. One on the Raspberry Pi itself, and the other just slightly remote from the Raspberry Pi. This sensor set could be outside a window, inside a terrarium/fish tank, inside a science project (fermenter? soil analyzer? hot water heater?), all kinds of possibilities.
If I can make the software scale-able, anyone could add all kinds of sensors to the system and have it easily recordable. The only drawback would be writing new sensor drivers for each set of sensors. That's where I'm having a fair amount of difficulty now.
It looks like I was wrong when I figured out the size of the data files. Right now, the datafiles appear to be much smaller, despite my cramming more information into them (Temp1, Temp2, Pressure, Motion Sensor, Time, Log Level). I think I want to change the logging system even further so that it creates a better record of values. Right now I'm saving a string for each sensor cycle with just the sensor values. The software is written so that it assumes a certain value is in a certain order in the string. That's great, as long as no one else is adding sensors to the system, and you only look a certain way.
I'm wondering if I can create a log with each sensor cycle recording a dictionary. Then I could easily write code to examine which sensors were polled for each sensor cycle. I could easily pull all the sensor values, or some of the sensor values. I could have some sensors polled more often than others.
I need to grab a second Raspberry Pi, and start thinking about how to pull all the sensors nodes together, into one easy to read display.
I'm working on creating a software module to decode the output from the sensor. So far it isn't straight forward, at least for an amateur. If I understand correctly, the sensor reports the readings in a backwards fashion. I'm not sure I've decoded the output correctly, but I'm close. Once I get that ironed out, I'll post the code up.
I started playing with I2C bus lengths. I heard that the practical length was less than a meter. I've got around a 2-3 meter CAT-5 cable set up running the TMP102. It's dangling outside the window, inside a tupperware container, and appears to be working just fine. I'm using Sparkfun RJ-45 Jacks and breakout boards. It adds a couple of bucks to the cost of the project, but it makes for great modularity. It's also going to let me do some cable run tests. Eventually I'll post those up as well.
I modified the jacks and breakout boards slightly. In place of a simple header, I used Arduino 8-pin stackable headers. That way, I can easily add a second sensor (or more) at the cable end, while still being able to easily breadboard it. So far it's working great.
The goal with this setup is to have two sets of environmental sensors. One on the Raspberry Pi itself, and the other just slightly remote from the Raspberry Pi. This sensor set could be outside a window, inside a terrarium/fish tank, inside a science project (fermenter? soil analyzer? hot water heater?), all kinds of possibilities.
If I can make the software scale-able, anyone could add all kinds of sensors to the system and have it easily recordable. The only drawback would be writing new sensor drivers for each set of sensors. That's where I'm having a fair amount of difficulty now.
It looks like I was wrong when I figured out the size of the data files. Right now, the datafiles appear to be much smaller, despite my cramming more information into them (Temp1, Temp2, Pressure, Motion Sensor, Time, Log Level). I think I want to change the logging system even further so that it creates a better record of values. Right now I'm saving a string for each sensor cycle with just the sensor values. The software is written so that it assumes a certain value is in a certain order in the string. That's great, as long as no one else is adding sensors to the system, and you only look a certain way.
I'm wondering if I can create a log with each sensor cycle recording a dictionary. Then I could easily write code to examine which sensors were polled for each sensor cycle. I could easily pull all the sensor values, or some of the sensor values. I could have some sensors polled more often than others.
I need to grab a second Raspberry Pi, and start thinking about how to pull all the sensors nodes together, into one easy to read display.
Monday, December 3, 2012
GPIO Pins on the Adafruit Pi Cobbler
I posted the code for the program I used over in the Adafruit Forums: Raspberry Pi Home Datalogger (new window)
I'm cleaning the project up a little bit. I'm trying to make the code "nicer" and easier to follow (I should comment my code.... one of these days). I switched the code that runs the programs over time to a system that checks the time every second, executing specified code at the top of the minute (Poll the temperature and pressure sensors), and at the top of the hour. It works, but my system utilization never drops below 60%, and is frequently at 97%. I may have to go back to having the system "sleep" in between sensor checks. I think that's a bad way to do it, but I'd like to look at having these little nodes be battery and/or solar powered.
I messed around with the RPIO program I was screwing around with. I wanted to see which RPIO reported pins correlated with which pins labeled on the Cobbler T-Plate.
The chart is repeated over on the Adafruit forums, in the comments section of the code.
Cobbler RPIO
#4------ 7
#17----- 11
#18 -----12
#21 -----V1 13
#22 -----15
#23 -----16
#24 -----18
#25 -----22
#27 -----V2 13
I'm cleaning the project up a little bit. I'm trying to make the code "nicer" and easier to follow (I should comment my code.... one of these days). I switched the code that runs the programs over time to a system that checks the time every second, executing specified code at the top of the minute (Poll the temperature and pressure sensors), and at the top of the hour. It works, but my system utilization never drops below 60%, and is frequently at 97%. I may have to go back to having the system "sleep" in between sensor checks. I think that's a bad way to do it, but I'd like to look at having these little nodes be battery and/or solar powered.
I messed around with the RPIO program I was screwing around with. I wanted to see which RPIO reported pins correlated with which pins labeled on the Cobbler T-Plate.
The chart is repeated over on the Adafruit forums, in the comments section of the code.
Cobbler RPIO
#4------ 7
#17----- 11
#18 -----12
#21 -----V1 13
#22 -----15
#23 -----16
#24 -----18
#25 -----22
#27 -----V2 13
Labels:
Adafruit,
Equipment,
GPIO,
Hacks,
Linux,
logger,
logging,
node,
project,
Python,
Raspberry Pi,
Security,
sensors,
tech,
Technology
Monday, November 19, 2012
Raspberry Pi Home Datalogger
I've wanted to do something like this since I first started playing with microprocessors. The idea of an inexpensive, distributed sensor network throughout the house is really cool. In Hollywood we always see someone sitting at their computer console accessing their security system. It's typically a wire-frame display with sensors all over the place. They're getting all kinds of data, and even providing the occasional remote output (displays, lights or sirens, etc).
The $35 Raspberry Pi is almost the ideal basis for this kind of sensor network. It runs a (relatively) well developed Linux distribution. It has two USB ports, runs on 5v, sports an ethernet port, and will support almost any video display out there. More importantly, it has several exposed general purpose I/O pins and supports I2C.
I'm using Lady Ada's Occidentalis distro. So far it has been incredibly stable (though it swaps between video outputs if I cut power to the system). I'm using this distro because there are examples using Python to access the various GPIO's and the I2C.
My previous post detailed some of my earlier experiments with the system. Since then, I have worked on building a series of programs to access a BMP085 board attached to the I2C bus. I haven't done much with Python in quite awhile, so I'm fairly rusty and lacking a definite style.
I finished a series of programs last night that check the sensor, log the sensor data to a logfile and update a webpage, and a simple program to automate the whole process. Currently I've got the sensor being checked and logged every minute. The logger program is using the Python Logging module. I'm recording the event level (I'm generating a warning if the temperature reaches 30c), the epoch time (to facilitate graphing later), and the temperature and pressure (I don't care about the altitude). Using epoch time versus Python's asctime also saves some memory. The log files are between 1.8 and 18 megabytes per day (one measurement per minute). This yields recordings between 50-500 days per gigabyte. I'm not sure why there is such an insane difference between "Total Size of Files" and "Size on Disk". Given that it's close to an order of magnitude, I need to address that at some point.
I'm looking to increase the number of sensors on the board. I'm playing around with a GY-80 board that I got off of eBay some time ago. It includes the BMP085 sensor, plus an IMU/Gyro component with a compass. It was about $20. I'm wondering if the resolution is tight enough to work as a seismograph, though I'll have to increase the polling rate to something much higher than once a minute. Luckily, with the processing power of the Raspberry Pi, I could poll the sensor very quickly, analyze the data locally, and only report data that was relevant. This idea is going to be an add on after some of the other to-do list is achieved.
A big thank you to the write of the Giuseppe Urso Blog. He's found the datasheets for all of the components on this board (I think). The ebay seller has not been able to provide good information for me.
Things to do:
I want to improve the webpage. Right now it's a simple Apache text page that shows the temperature and pressure, along with the system time of the latest measurement (actual time, not epoch time).
I want more sensors. I'd like a light and motion sensor (again, we're trying to get close to that Hollywood sensor system). It would be great to incorporate a smoke/carbon monoxide/gas sensor into this build. A networked, web-enabled hazard detector would be incredible. I've already got a couple of sensors for this. To get them to work, I need to grab something that will let me add analog to digital feeds to the board (perhaps this?).
I really think I'd like to incorporate a second temperature sensor. I'd like my first sensor node to be located just inside the front door. Running a cable outside to a sensor (MPL115A2) would be pretty easy, and would give me the ability to log the weather outside compared to the environment inside. The capability would also be nice if Angel decides to start working with herps again. This would allow us to monitor the inside and outside of the tank.
The webpage needs serious work. I'd like to be able to generate graphs of the data, on the fly (click on the parameter, and it brings up a graph of the last hour. Click on that graph it shows the last 12 hours. Click on that, it shows the last day. Week, month, year, etc). My skills with Python are not up to the task yet. Hell, my skills with HTML are essentially non-existent (My webpages in the past have all used Dreamweaver). I need to see if I can merge the two, and someone get the Python code to play nicely with a Dreamweaver generated page.
Automated alerts. We'll go back to the Hollywood example for this one: When the bad guys are breaking in, I need the network to tell my cellphone (or bring up an alert on my computer). A more practical concept: When the house gets too hot, I need to be told. When the house is on fire, I need to be screamed at.
I want to keep the cost down. The average cost, per node, should be less than $100. At this price point, folks can afford to pick up a couple of nodes to watch their doors. As they like it more, they could grab additional nodes for other rooms in the house (I want to be able to control my small home theater system using my cellphone and an IR equipped node).
Webcam support. The Pi has two USB ports. Once the node is developed, there is no reason to have the USB ports in use. A web cam is a cheap (I saw a couple for under $10 the other day) way to gain tremendous amounts of information about a locale. Even if the camera is only used to snap stills to send to a remote site (or just log locally) the idea has tremendous value. As it stands, I haven't even tried hooking up a camera to the USB ports.
Free and open code. An idea like this is only as usable as the guy making everything. I'm not an engineer or computer scientist. If I could get a couple of those guys interested in the project, they'd be able to do incredible things with it. More to the point, they'd see ideas that I'd never even consider. This project, as an open source project, has real potential. I'm going to work on setting up a GitHub account, and making my code public (I'll warn you, it's ugly code).
I'll post up more as I get it.
Late edit: I'm starting to look at Lady Ada's Raspberry Pi WebIDE. I spent the afternoon/evening learning BitBucket, and now I've got a BitBucket account with the code on it (PiLog). I may not be doing things correctly, so the repository may be a little bizarre over the next couple of days. The code that was loaded tonight was tested to work, though your mileage may vary.
The $35 Raspberry Pi is almost the ideal basis for this kind of sensor network. It runs a (relatively) well developed Linux distribution. It has two USB ports, runs on 5v, sports an ethernet port, and will support almost any video display out there. More importantly, it has several exposed general purpose I/O pins and supports I2C.
I'm using Lady Ada's Occidentalis distro. So far it has been incredibly stable (though it swaps between video outputs if I cut power to the system). I'm using this distro because there are examples using Python to access the various GPIO's and the I2C.
My previous post detailed some of my earlier experiments with the system. Since then, I have worked on building a series of programs to access a BMP085 board attached to the I2C bus. I haven't done much with Python in quite awhile, so I'm fairly rusty and lacking a definite style.
I finished a series of programs last night that check the sensor, log the sensor data to a logfile and update a webpage, and a simple program to automate the whole process. Currently I've got the sensor being checked and logged every minute. The logger program is using the Python Logging module. I'm recording the event level (I'm generating a warning if the temperature reaches 30c), the epoch time (to facilitate graphing later), and the temperature and pressure (I don't care about the altitude). Using epoch time versus Python's asctime also saves some memory. The log files are between 1.8 and 18 megabytes per day (one measurement per minute). This yields recordings between 50-500 days per gigabyte. I'm not sure why there is such an insane difference between "Total Size of Files" and "Size on Disk". Given that it's close to an order of magnitude, I need to address that at some point.
I'm looking to increase the number of sensors on the board. I'm playing around with a GY-80 board that I got off of eBay some time ago. It includes the BMP085 sensor, plus an IMU/Gyro component with a compass. It was about $20. I'm wondering if the resolution is tight enough to work as a seismograph, though I'll have to increase the polling rate to something much higher than once a minute. Luckily, with the processing power of the Raspberry Pi, I could poll the sensor very quickly, analyze the data locally, and only report data that was relevant. This idea is going to be an add on after some of the other to-do list is achieved.
A big thank you to the write of the Giuseppe Urso Blog. He's found the datasheets for all of the components on this board (I think). The ebay seller has not been able to provide good information for me.
Things to do:
I want to improve the webpage. Right now it's a simple Apache text page that shows the temperature and pressure, along with the system time of the latest measurement (actual time, not epoch time).
I want more sensors. I'd like a light and motion sensor (again, we're trying to get close to that Hollywood sensor system). It would be great to incorporate a smoke/carbon monoxide/gas sensor into this build. A networked, web-enabled hazard detector would be incredible. I've already got a couple of sensors for this. To get them to work, I need to grab something that will let me add analog to digital feeds to the board (perhaps this?).
I really think I'd like to incorporate a second temperature sensor. I'd like my first sensor node to be located just inside the front door. Running a cable outside to a sensor (MPL115A2) would be pretty easy, and would give me the ability to log the weather outside compared to the environment inside. The capability would also be nice if Angel decides to start working with herps again. This would allow us to monitor the inside and outside of the tank.
The webpage needs serious work. I'd like to be able to generate graphs of the data, on the fly (click on the parameter, and it brings up a graph of the last hour. Click on that graph it shows the last 12 hours. Click on that, it shows the last day. Week, month, year, etc). My skills with Python are not up to the task yet. Hell, my skills with HTML are essentially non-existent (My webpages in the past have all used Dreamweaver). I need to see if I can merge the two, and someone get the Python code to play nicely with a Dreamweaver generated page.
Automated alerts. We'll go back to the Hollywood example for this one: When the bad guys are breaking in, I need the network to tell my cellphone (or bring up an alert on my computer). A more practical concept: When the house gets too hot, I need to be told. When the house is on fire, I need to be screamed at.
I want to keep the cost down. The average cost, per node, should be less than $100. At this price point, folks can afford to pick up a couple of nodes to watch their doors. As they like it more, they could grab additional nodes for other rooms in the house (I want to be able to control my small home theater system using my cellphone and an IR equipped node).
Webcam support. The Pi has two USB ports. Once the node is developed, there is no reason to have the USB ports in use. A web cam is a cheap (I saw a couple for under $10 the other day) way to gain tremendous amounts of information about a locale. Even if the camera is only used to snap stills to send to a remote site (or just log locally) the idea has tremendous value. As it stands, I haven't even tried hooking up a camera to the USB ports.
Free and open code. An idea like this is only as usable as the guy making everything. I'm not an engineer or computer scientist. If I could get a couple of those guys interested in the project, they'd be able to do incredible things with it. More to the point, they'd see ideas that I'd never even consider. This project, as an open source project, has real potential. I'm going to work on setting up a GitHub account, and making my code public (I'll warn you, it's ugly code).
I'll post up more as I get it.
Late edit: I'm starting to look at Lady Ada's Raspberry Pi WebIDE. I spent the afternoon/evening learning BitBucket, and now I've got a BitBucket account with the code on it (PiLog). I may not be doing things correctly, so the repository may be a little bizarre over the next couple of days. The code that was loaded tonight was tested to work, though your mileage may vary.
Friday, March 5, 2010
5 Days to Go
The date is rapidly approaching. I spent the morning upgrading my father's computer, and the afternoon finding the equipment I needed.
The folks at Casual Adventure (http://www.casualadventure.com/) have been incredible. This deployment is very different from any that I have done before, but it is right up their alley. Lightweight, quality gear, and they have the expertise to help you select the right tools for the job.
It was interesting. While I was there, a gentleman was looking for a new pack. He already had a pack purchased from another store, but it was uncomfortable, and didn't seem to fit right. The staff offered to help him set the pack up correctly. He declined, saying that it had been setup before. The staff offered to help him pick out a new pack. He declined, stating that his current pack was cheaper.
The staff was very pleasant and polite, even as he became more and more antagonistic. I was pretty surprised at the lengths that they went to, to try and help this man out. In every case, he preferred his problems over solutions. You aren't going to be able to make everyone happy, all the time.
I really valued their input. The staff there are all big time outdoorsmen (and women!), with a very wide variety of experiences. They're very quick to use each other's expertise to help out their clients. I've been using them for years, but for minor purchases, or critical parts (these folks seem to be able to find anything). This was the first time I needed to be kitted out for something like this. It's incredibly reassuring to know that someone in the shop had been in an environment like Haiti before, and has had experience with all of the equipment I purchased.
As I was leaving, I started checking off my pre-deployment checklist. It ended with my old prayer, "Please god, don't let me screw up." Familiar to all of us. I know I've heard it muttered many times past, either in the ER, outside the door before a warrant service, or before throwing the switch on a multi-thousand dollar custom computer, it's a very familiar mantra.
This is a big leap. I've never deployed solo. It's going to be easier because I'll start in a relatively supported location. However, Port au Prince is going to be tough. I've got a couple of leads for organizations there, but much of the work is going to happen with boots on the ground. These uncertainties are what make me nervous.
On the bright side, it's date night! My girlfriend and I are going to grab a nice dinner, and check out Alice in Wonderland. Then tomorrow we're going to go see the horses before meeting some friends for a 30th birthday. We'll close the weekend by going out to see a bunch of my family. I'm glad this final weekend is going to be filled with everything I want.
On a final note, I'm pleased to hear that my friend's book, They Fought for Each other, is kicking serious ass on the Amazon Top Seller's List. Kelly Kennedy is an incredibly fascinating lady, and I can't wait to get my hands on the book. Unfortunately it's going to have to wait till I get back. No where to stash it in my pack.
Subscribe to:
Posts (Atom)