That escalated quickly. Now, watch Russia

And just like that, we BLEW through 10,000 cases.  I started writing this yesterday morning (Friday). Thursday morning we were at ~9,000 cases. We smashed through 10k, and actually landed at 15k by the time I got lunch yesterday. This morning, we're at almost 20k.  That's some explosive amplification.
https://www.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6

Lower right hand corner is that daily count graph. I actually don't think we can do stats just on the US or a specific state. I'll let the first paragraph above speak for itself. We went up by 50% in 24 hours, doubled in 48 hours... Boom

For you Plague Inc. fans, Madagascar has reported the first three cases (This is not me saying the end is nigh!).  It looks like there are no reported cases in Botswana, Mali, Libya, Yemen, Turkmenistan... I'm going to emphasize the word "Reported" there.

OK, if you look at that map, and zoom out, so you can see the whole world, something sticks out.
Nope...  Not that.  Nope... Not that. Yes, amigo, the ocean is HUGE, and we should go there.

Nope, I'm talking about Russia. Weeks ago it was a bit of a joke that Russia had two cases.  Two cases.  Two cases.  Day in and day out, despite having a fair amount of cross border traffic and a far east border condition that would make Trump shit himself (Hint, Russia says there are ~30,000 Chinese living in the Russian Far East. In reality, pretty much everyone agrees that the number is at least 10x higher). To say that border is porous would be an understatement.

Russia publicly started their quarantine program in February:
https://www.reuters.com/article/us-china-health-russia-evacuation/russians-start-two-week-virus-quarantine-after-return-from-wuhan-idUSKBN1ZZ112
Hey, comrade, look!  TASS:
https://tass.com/society/1117121
I love the headline: Coronavirus can't spread beyond quarantined health camp...
Oooookay!

This Google Search is kind of hysterical:
https://www.google.com/search?q=russian+quarantine+rumors&rlz=1C1CHBF_enUS849US849&sxsrf=ALeKk00HCMISgCWsP-zyJNAJvV6OxhfmYg%3A1584797075244&source=lnt&tbs=cdr%3A1%2Ccd_min%3A3%2F1%2F2020%2Ccd_max%3A1%2F1%2F2020&tbm=
OK, hysterical is the wrong word.  This one is tragic. Imagine finding out you are pregnant, in quarantine, in a country that is denying you exist:
https://apnews.com/0f0d815ef0be8eb6809babd542620ff4
Very interesting, there is literally no mention of the number of people quarantined, sick, or otherwise within Russia.

This article, two weeks later, talks about violently deporting 88 people who were quarantined but violating that quarantine (If you have to conduct a raid to get your deportee, I'm going to classify that as violent. Unfortunately, I have some experience in that. #NeverAgain).
https://www.reuters.com/article/us-china-health-moscow-deportation/russia-to-deport-88-foreigners-for-violating-coronavirus-quarantine-idUSKCN20M252
The article does talk about three Russian nationals receiving treatment, after contracting the 'Rona on a cruise ship, and two recovered Chinese nationals who had previously recovered.

Now, I find it highly implausible that the millions of people in Russia, living with a porous border to the epicenter of the outbreak, have a quantity of cases that you can count on one hand. But perhaps they're subscribing to the theory that if you don't acknowledge the cases they can't hurt you.

All humor aside, denying the problem won't work. Russia may be playing the numbers game, accepting the single digit percentage loss (That's a million people), for a strong image and ability to completely skip the outbreak response. Their population is more isolated than ours, and they'll have a better capability to infringe the rights of that population. It's unpleasant, but a possibility.

Keep an eye on 'em

Brushin' the dust off- Coronavirus is here

Wow.  It's been 6 years since I posted here, and an insane amount has happened. It crushes me a bit, but I'm not going to go into it here (But I should have, and for that, babe, I'm sorry).

But we have some important comments to get out.

First, Coronavirus (COVID-19, Novel Coronavirus) is here. As of this morning, it's in all 50 states. We had a bet going on whether it would be reported in WV first, or Madagascar. WV popped today. If you want an entertaining way to learn about pandemics, I would recommend Plague Inc. available on your app store.
If you're looking for a decent, raw stats visualization of COVID-19 spread:
https://www.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6

If you take a look in the lower right hand corner, you can see that we're in an almost explosive amplification phase of the virus. You can also see that China appears to have done a good job blunting the spread there, which is an interesting topic of disucssion.

OK, the main reason I brushed the dust off this page:
https://www.sciencealert.com/who-recommends-to-avoid-taking-ibuprofen-for-covid-19-symptoms
specifically:
https://www.thelancet.com/journals/lanres/article/PIIS2213-2600(20)30116-8/fulltext


This study was actually released several days ago, but has some good content. The crux is: try to avoid NSAIDs (Ibuprofen, Naproxyn) if you think you may have been exposed to COVID-19. Additionally, as a general rule, you don't want to use aspirin in kids for fever/viral illness due to the risk of Reye's syndrome:
https://www.nhs.uk/conditions/reyes-syndrome/

So, we're primarily looking at acetaminophen (Tylenol) for aches and pains. This comes with an additional warning to keep an eye out for what's in all of your meds.  Acetaminophen is in a ton of cold/flu/cough/allergy medications. Taking too much of it will damage your liver (A particular concern with my family, being the connoisseurs that they are...).

OK, that's the short post for today.  As always, shoot me questions, comments, and concerns. Throw links up to your own sources, when you have them.  Be safe out there.

Let's Talk About Ebola

If you reached this from Facebook, I'll apologize up front.  This isn't an attempt to get blog hits (I don't care about 'em).  The things I'm going to say in this post may sound alarmist, and currently go against the conventional guidance offered by the CDC.  I'm going to have my say, and post my evidence.  I hope you will examine it critically and reach your own conclusions.

If you've reached this post from Facebook, then you probably know a bit about me.  I've been involved with emergency medicine for my entire adult life.  Very early in that career I became involved with WMD/CBRNE response, and with that I've done a fairly involved study of select agents (Including several graduate courses at GMU, in which I maintained very high grades).  I've spent a very large amount of time in "Level A" (self-contained biohazard/HAZMAT suits), and I've even treated patients while wearing these suits.

I'll cut to the chase.

I'm hearing that some agencies are still presenting that Ebola virus cannot be indirectly transmitted (Through aerosols).  Research conducted on non-human primates has pretty solidly proven that Ebola can be effectively transmitted through aerosols.  I'm going to present two quick cases here.

First, a couple of cases of inadvertent transmission of Ebola from test monkeys to separated control monkeys.  The monkeys mentioned in this case were not expected to get Ebola, and were held separate from the test monkeys.  Two of the three control monkeys came down with Ebola and subsequently died.
http://www.ncbi.nlm.nih.gov/pubmed/8551825

Second, an actual experiment designed to see if monkeys could be infected with Ebola through an aerosol route.  In this experiment, doses as low as 400 plaque forming units were aerosolized and delivered to monkeys through a head-only aerosol mask.  Two things are important to note from this study.  First, it was uniformly lethal.  Second, the dosage level is low, really low.  This is not a bug to be trivialized.
http://www.ncbi.nlm.nih.gov/pubmed/7547435

I'd like to call your attention to the skill medical providers that have gotten Ebola while working with these patients (I think we're up to six, as I write this).  None of them can recall an infectious event, with an Ebola patient or not (One of the doctors that was infected with Ebola could not recall working with an Ebola patient.  He was on a Labor and Delivery Ward).  These docs all came down with Ebola, but cannot recall being directly exposed to Ebola.  Please consider that, in light of the two studies above.

We're seeing an explosion of cases in Western Africa, and a rise in lethality (from ~30% to ~50%). This is probably not due to any mutation or increase in base lethality, but instead due to a break down of services. Still, this is an ominous sign, as we're now playing catch-up with this bug in a major city (Monrovia has a population of over 1 million people, as of 2008).  Further, we know that the virus has hit the slums of the city, where no social services were present before the outbreak.

It is reported the Ebola is not infectious until the patient is symptomatic.  Early symptoms include a flu-like syndrome (Fever, body aches, possibly a cough).  The point being that these patients will look just like the majority of your "Feeling Sick" patients.  You are not going to be able to look at an early Ebola patient and magically recognize them as being this sick (They don't all weep blood, is what I'm saying).  Listen for your other clues, travel, degree of fever, fever with any unusual bleeding.  Pay attention to these.

All of that being said, this is a virus, not a magic boojum bug spawned by Satan and coming to kill you.  Conventional US healthcare can care for these patients, if proper isolation protocols are followed.  One of the reasons that Liberia is being hit so hard is because they are under-resourced (even now, they're not getting anywhere near the support that they need).  All of our hospitals should have a literal ton of masks, goggles, and gloves.  Use 'em.  Take it seriously.

Folks on the true front lines (Firefighters, Medics, Police Officers), keep your eye armor with you, and keep some masks in your pocket.  If someone says they're sick, believe them, get them checked out.

Be safe, and take care of each other.  Make sure you're still around tomorrow and the next day.  We're going to need you to continue doing the great deeds that you do.

Video feed from the Pi(es)

I know I went silent for awhile.  New job and more.  Tons more.  I'm getting back to some of the projects, but I'm also taking on a new one.  I need to install some basic security cameras at a facility.  I'd prefer that they work using the network infrastructure (It's not a computing intensive location).  Really cheap IP cameras run around $70, and I'm not looking to pick up another maintenance hobby.

A Raspberry Pi runs $35, and the camera runs $25.  That's essentially an HD IP camera for $60 (I've got an insane number of power supplies lying around the house).  I also already own a Pi and camera to play with.

I bounced over to the Raspberry Pi foundation's website to see what they had to say about the camera.  They have some good tips on getting the camera installed.  However, I hit a couple of snags and couldn't get videos to stream over the network.  It was dinner time and I had to bounce out to have dinner with friends.

A couple of days later, I'm back, and searching around the internet.  I stumbled across Miguel's great post, and started learning a couple of things.  After a little bit of reading, I came across his updated post, which had EVERYTHING I needed to get the little computer streaming over the network.  I needed to do some apt-get update/upgrade between steps 6 and 7.  I also wrote a quick script to start the camera up:

mkdir /tmp/stream
raspistill --nopreview -w 960 -h 540 -q 80 -o /tmp/stream/pic.jpg -tl 10 -t 9999999 -th 0:0:0 &
LD_LIBRARY_PATH=/usr/local/lib mjpg_streamer -i "input_file.so -f /tmp/stream -n pic.jpg" -o "output_http.so -w /usr/local/www"

All this does is make sure the directory exists, then it creates a series of 960x540 JPEG's of quality 80 every 10 milliseconds for 9999999 seconds (I think it's seconds).  The "-th" is a thumbnail configuration, and the "&" tells this script to run in the background (I think).
The next part of the script is one that I'm not sure about.  It streams the JPEG, but I'm not completely sure I understand everything, yet.

I did mess around with the JPEG settings.  I selected the 960x540 image size because all of my monitors are 1080p, at least.  This way I can easily accommodate multiple streams on the same monitor.  I set the time lapse down to 10 milliseconds, but it didn't seem to increase the streamed frame rate.  I put quality at 80 because it was where I could read some text from across the room in my test image.  I finally messed around with all three of these settings to try to improve the frame rate, but with no real success.  It also appears that frame rate is impacted by the amount of light in the image (In theory this makes sense, but we should still be able to get decent lighting/shutter speed without sacrificing frame rates).

Great work, Miguel.  Thanks!

Preliminary Library for the ADXL345 in Python

The new code seems to be working.  I've ordered some more parts from online so that I can actually build these sensors into some real world rigs.

The new code is here, on the Adafruit site.
I'm going to try to keep the top post updated with the new code so people don't have to search through the comments (there aren't too many of them.  This went pretty quickly).  I'm going to try to make the code a little more functional, and include some of the other configuration options offered by the ADXL345.

Right now, the only thing that is really tested and seems to work well is the readAccel() function.  Calling this function will spit out the three accelerometer values (a raw number, not corrected with a gravity coefficient).  With my rig I've been able to get over 100 values per second (I think...  I can't find my scratch pad).
It spits out all three of the values because of the way the ADXL is designed to release data.  If you don't pull all three values, and instead just pull one, the ADXL "over-writes" the other two values in the stack with new data.  I figured it would be easier to just let the coder handle a couple of data values that they don't need, rather than give them an option that might give funky results later if they didn't dive deep into the datasheet.

I need to write my program for handling and graphing the data obtained by the ADXL345 for my project.  I'm probably going to have a buffer (of a user determined size) of values from the ADXL.  When the system detects an event it saves the buffer and continues writing readings until A) a specified amount of time or B) some sort of quiescent period is detected or C) an external "stop" signal is received.  I then want to output the data on a series of graphs showing the acceleration and combined vectors over time.  Again, this will probably be written in Python.  The mature version will hopefully use some sort of real-time display while recording the data.

The ADXL345, Python and Raspberry Pi

I'm working on logging data from the ADXL345 accelerometer for a DIY physics project for a friend of mine (OK, it's for me too because it involves fun physics).  I wasn't able to find a library for running the ADXL345 using Python, so I spent the day building one.

The code is over on Adafruit's forums, and it is very much a work in progress.  I'm reading data from the board and it looks like I'm able to set configuration options pretty easily.  Right now this is very much a hack in progress.  There are parts lying all over the floor, it isn't portable and it isn't easily used.

The problem is that the ADXL reports acceleration using two eight-bit values.  Here's the quick start sheet, here.
The first register uses all 8-bits to report data.  The second register uses four of the bits to report data, the other four are used to report the "sign" of the data (positive or negative).
I can't, for the life of me, figure out how to make this data usable, elegantly.

If it ain't broke...

I've spent weeks trying to figure out how I broke my Raspberry Pi.  Actually... How I broke two of them.

Well, I didn't actually break them.  Just the sensors attached to them.

Well, I didn't actually break them, it's just that they weren't reading correctly.

Here's the story:

I've been working on a couple of I2C sensors to tie into my Raspberry Pi.  The idea is to read the sensors at specific intervals, log the data, and then serve up some nice graphs.  I've been using the BMP085 temperature and pressure sensor, the TSL2561 light sensor, and the TMP102 temperature sensor (All those links go to the Adafruit forums specific to those sensors and the Raspberry Pi).

A group of us were collaborating on the TSL2561 (Hi, csalty!), when I upgraded to the newer version of Adafruit_I2C and the Adafruit_BMP085.  That's where everything went sideways.

I spent days looking at the datasheet and the Adafruit_BMP085 code.  Some of the stuff just doesn't make sense to me.  It doesn't make sense to the point that I wrote the devs saying "This is broken".

It's not, and that's pretty embarrassing.  It really looks like something in the Adafruit_I2C code changed how it pulls the information from the BMP085.  If you're looking for solutions, enable the debug mode, and check your calibration information.  Mine was VERY off using that version of Adafruit_I2C (Impossible temperatures and unstable in nature reading 200 degrees one minute negative 70 the next).  Once I switched some of the functions to the older version, things went well.  The kludge-version of Adafruit_I2C that I'm using is listed here: Modified Adafruit_I2C.py.

I also made a very specific change to the Adafruit_BMP085.py code.  I allowed the code to pass a specified bus number down the "stack" to the I2C code.  By default it does not specify a bus, and will allow the new I2C software to determine which version of the Raspberry Pi is being used, selecting the default GPIO header bus.  This way, all you have to do is call the BMP085.  It will fill in the default address, the default mode, and the default bus.  If you (like me) are using both I2C buses on your Raspberry Pi, then you MUST specify when you are using the "non-standard" bus.  The way the Adafruit_I2C.py code is written, it will only look for the version of the board and assign the "default" bus.  It has no way of knowing which bus you want to use.

I also set up the BMP085 code to pass the debug state down the code stack.  I figure if you're interested in debugging the BMP085, you're also going to be interested in debugging what is happening with the I2C code.  As part of the BMP085 calibration data, I also set it up to print out which I2C bus is being specified.

I need to make these changes to the TSL2561 code and the TMP102 code.  Both of these sensors appeared to be working just fine with the new Adafruit_I2C.py code (I've checked to make sure).

I've changed my project a little bit.  Now I'm running two parallel sets of sensors on the two different buses.  Each bus has a TSL2561 and a BMP085 sensor.  I'm logging the temperature, light level, and pressure every sixty seconds or so.  I'm manually able to generate all kinds of charts, but for right now I'm going to keep it manual.  I'll let the system run while I'm at work this week (four days), and if everything looks OK, I'll work on re-writing the webpage code.

Two I2C buses on the Raspberry Pi

I'm hoping this post can clear up some mis-information regarding the two I2C buses on the Raspberry Pi Model B rev 2.

In the upper left hand corner of the board you can see the GPIO header.  Below that is the P5 header footprint, a 2x4 series of vias.  You won't see the P5 label until you flip the board over.

Now, there are some folks that will tell you the only way to get to the second I2C bus is to access the camera S5 header (or the S2 header).  That would involve some incredible soldering work, or a socket.  I don't have the socket, and my hands aren't good enough to solder at that pitch.

However, I can solder that P5 header.  The unfortunate thing is that the P5 header is really close to the GPIO header.  Using the P5 header while using Lady Ada's Pi Cobbler header may be problematic.  I took some long headers and soldered them in place, at a slight angle.

I used a 2x5 socket on the header, and spaced it with a penny (between the 2x5 socket and the ribbon cable).

The process is actually pretty easy.  If you're a novice solderer you shouldn't be too daunted by this task.  Hey, the Pi itself is $35.  It's OK.

Once you get that done, you need to run some code.  I'll post the Python 3.x code in a bit.  Here's a link to the original code.  All that needs to be done for the Python 3.x code is to change the print statements to print() functions.  Here's the link to the RaspberryPi.org forums, where bgreat posted the code:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=33092

In hindsight, I should have looked at putting a 2x4 socket there.  I'm just not sure that I have any.

Parallelism in Hacking

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.

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.

A quiet thought over here in my corner of the internet

As healers we find ourselves plunged in the misery and sorrow of others.  We take great pride and pleasure in our work.  Not from the misery and sorrow, but from the alleviation of infirmity.  Not just in body, but most of all in spirit.  It is there that our own pain can find relief.

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

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.

Ultrasound Phantoms: War were declared

The ultrasound phantoms work.  They have a few limitations, but for certain applications, these cheap DIY phantoms are going to be far superior to expensive commercial phantoms.  In fact, part of their DIY nature makes them inherently superior.  Creating a phantom for a special purpose, such as vessel cannulation, foreign body identification, or needle procedures, is simple.

One of the big issues that has come up is bacterial/fungal growth on the phantom.  This should be expected, as the phantom is constructed of gelatin and sugar-free psyllium.  The system is essentially a giant petri dish.  I needed to find a way to inhibit microbial growth.  Not just inhibit, but stop.  Completely and totally.

I lucked out in a couple of ways.  I tried mixing some bleach into the material when it was on the stovetop.  The mixture foamed up a fair amount.  This wasn't a big issue with the first two layers, as pouring the next layer seemed to dissolve the previously settled foam.  The final layer settled with a very large amount of foam.  This foam is a random mixture of air and gelatin, and almost completely sono-opaque.

This is the external surface of the simulant, and represented a major problem for the phantom.  It was impossible to image past this interfering layer.  I tried scraping the surface foam off, but to no avail.
I spent three shifts at the hospital trying to find a way to make the system workable.  At this point I had intentionally inoculated the surface with dust and dirt to attempt encourage microbial growth. At the three day point, no growth, but no apparent solution.

Ending my shift one morning, I had my "Eureka" moment.  One of the workmen was removing floor tiles by heating them with a propane torch.  Between my broken Spanish and his broken English, I was able to convey that I wanted to borrow his propane torch.  I quickly heated the surface of the phantom, melting the top foam layer.  It liquified and appeared to completely remove the foam layer.

I waited ten anxious minutes, visibly bouncing.  I placed the ultrasound transducer and was rewarded with two easily visible vessel simulants.  Cannulation was almost exactly the same (the new material seems somewhat more friable).

Six weeks later, the phantom was still visibly free of microbial growth (I don't have the patience or material to actually test for microbial growth beyond naked eye visualization).

I'm stuck at the next step.  I'm either casting a human arm and making a mould, or I'm developing some method to snake the vessels through the simulant to increase the difficulty in cannulation.

Overdue Updates

For my one reader (Thanks Mom!) I know the updates for the Ultrasound Phantoms are overdue. There is progress. Unfortunately, you don't get to read about it today.

 A couple of months ago I read about this cool new computer, the Raspberry Pi. As far as I know, they've only shipped the model B board, which is $35. That money gets you a Linux computer that is slightly bigger than a credit card. You need to supply a keyboard, SD card, and that's really it. If you want to run a Windows-like GUI, you'll want to have a mouse as well. It's got a couple of dozen general purpose I/O pins to let you build in your own gadgets and stuff (Read a pushbutton, blink an LED, etc).

 The board supports at least half a dozen types of Linux. I went with the Adafruit Occidentalis build. It's build off of Debian Linux, with some added extras, This incorporates libraries for SPI, I2C, One Wire, and WiFi built right into the distro. Couple this with the already included Python (Version 2.7 and Version 3.2) and you have a junior hacker's dream.

 I'll reiterate: $35. I had everything else lying around the house (SD card, spare keyboard and spare mouse). I have a computer that will hook up to pretty much any video display I'll run into. It supports HDMI 1080p right out of the box. It plays nice audio. It surfs the web (slowly, sometimes). For less than the price of a copy of Windows, a new video game, or a tank of gas (holy crap! Yeah, and I drive a Prius).

 It's Linux. For some people that will be a deal breaker (Again, less than the cost of...). I'm having to relearn a fair amount. I used Linux a couple of times, years ago. I had a Linux box once, to toy around with. I had a dual boot netbook where I utilized Ubuntu to run some network diagnostics.

This time around, I'm really focusing on the command line interactions. The little gizmo is decent with the GUI but it does slow down a fair amount at times. However, this thing screams from the command line.

 I'm re-discovering Python as well. I learned 2.7 during college (Thank you, Dan Fleck. You got me excited about programming, and changed my life). It looks like there is a serious attempt to use Python 3 in the Raspberry Pi world.

 I wrote a quick utility to poll the Adafruit Pi Cobbler pin-breakout board. Eventually I want to get the pin states over a network.

import RPi.GPIO as io 

io.setmode(io.BOARD) 

for i in range (26): 

     try: 

          io.setup(i,io.IN,pull_up_down=io.PUD_UP) 

     except: 

          continue 

     try:

                    print(io.input(i),i)
               except:
                   
                    print('invalid pin ')
                    print(i)
          print('Complete')

I'm running the program over SSH, so I guess, technically, I'm checking the pin state over the network.

It's important to note:
First, you have to run the program with superuser permissions (sudo).
Second, the program numbers the pins differently than the pins are numbered on the Adafruit breakout. Third, you probably need to be REALLY careful with this code. It attempts to mess with all of the pins, some of which aren't GPIO pins. So far, it doesn't seem to have bothered anything.

I'm waiting for some more parts so that I can start messing around with I2C sensors. Eventually I want to build an environmental monitoring system.

DIY Ultrasound Phantoms: Recipes, Part 1

I'm now on the fourth generation homemade ultrasound phantom. The recipe is pretty simple and low cost. I'm using store bought Knox gelatin, generic sugar-free psyllium fiber (Metamucil), and vein simulators (5mm Penrose drains). Before I link to the articles I used, I'm going to shoot the authors a quick email (The idea of using the above recipe is not my original idea). Right now I'm building the phantoms in cheap, flat food containers (ultra cheap tupperware clones). Each phantom is currently constructed of three "pours". Each pour uses the following recipe: 250-300cc's of boiling water 3 packets of Knox gelatin 1-2 tablespoons of sugar free psyllium fiber With the water at a boil, add the packets of Knox gelatin slowly. Some will probably clump up (This isn't a big deal. I'll go into that in a bit). While adding the gelatin, watch the boil, as it may boil over. Stir continuously. Once the gelatin is added, slowly add the psyllium fiber, again watching carefully and stirring continuously. If the mixture clumps a little bit, don't worry too much. If you are looking to create a relatively clear ultrasound phantom, pour the mixture into the mold (in my case, the cheap food storage container) through a strainer. This will catch most of the lumps. If you are looking to create a "Dirty" looking phantom, leave the clumps in. These clumps will sonographically appear as areas of varying tissue density. These inclusions mimic the appearance of real tissue. Our goal (at my hospital) is to create a better arm simulation for US guided IV insertion techniques. These inclusion bodies mimic scar tissue, varying tissue densities/types, and present a sonographic picture that is not as "cut and dried" as other vascular simulators. The cheap food containers that I am using hold 3-4 gelatin "pours". I have been using three pours for my prototypes. After each pour, I'm allowing the gelatin to firm up in the fridge for two hours, before pouring the next layer. After the first pour has firmed up, but before pouring the second pour, I'm putting down two penrose drains, filled with water/saline, to simulate vessels. One of the vessels I'm overfilling/pressurizing with 30% more fluid, to simulate an artery. My vessel simulators occasionally leak, so I'm not having tremendous success with the arterial simulation. Still, with the slight pressurization, the vessel does have a slightly different appearance when visualized sonographically. This is a practice, that once perfected, will enable students to differentiate between arteries and veins. I'm working on a method to create an automated pulse, so that the vessel is maintained under pressure and appears to pulsate.

DIY Ultrasound Phantoms

I've got a lot of projects kicking around. This one kinda got pushed to the front because one of my colleagues said "We need to be able to perform this skill, but we don't have the resources to develop our techniques". Ordinarily, this would warrant some kind of project, slow and methodical like. However, I'm now one of the guys that responsible for fixing problems like this. It's not just an issue, it's "my" issue. The glove was thrown down, so to speak. The issue is that we need to place IV (intravenous) lines in our patients. It seems pretty simple: you come to the ER, sick/broken/in pain, and we need to take care of you. One of the ways that we address this is by starting an IV line and drawing blood. If you are going to do either of those things, you can do them both (in theory). Most of the time, this is a simple matter of getting a skilled provider, with the right equipment, to the bedside. Veins are typically pretty easy to find (it helps if you have sensitive fingertips, not sensitive eyes), and then it's just a matter of a quick poke. The complicating factor is the condition of the patient. Some folks don't have great veins (for that matter, some folks don't have shallow veins, demonstrated sonographically). If you can't find a shallow vein, you need to find a deep one. Beyond a few millimeters, you simply can't feel a deep vein. You need some way to visualize those deep veins. Enter in the bedside ultrasound system. We use these during traumas to examine patients for internal bleeding. Occasionally we use it to check on pregnant women and the health of the fetus. Other than that (this comprises maybe an hour or two a day, at most) our bedside sono units are dormant. They're like any other medical imager: not cheap. A couple of docs figured out that we can use these things to visualize deeper veins (and arteries). From there it was a simple trick to guide an angiocath (an IV needle) into one of these veins. It's a pretty cool solution. It's not as invasive as a PICC Line (Peripherally Inserted Central Catheter), or other central line (subclavian, femoral, etc), and it's more comfortable than a jugular line. It's also a guided solution. No blind sticking, and you can see the structures in the patient's arm to avoid complications (inadvertent arterial puncture). However, it's also a bigger deal than a simple IV stick. You're taking an angiocath that you would normally poke a couple of millimeters down, and going 10-20 millimeters down into someone's arm. You're asking more of your patient. More to the point, if all you have done, to date, is a standard IV placement, you're asking a lot of yourself. I know that the folks that I work with care for their patients. Or they're crazy. No one would work under these conditions (low pay, constant threat of bodily harm, verbally abusive clients, incredible work loads) for years. They all seem highly functional, so I'm going to stick with "Compassionate". I think my colleagues generally care for their patients, like they would care for their own family. So it's a lot to ask them to jam a needle two to three inches into someone's arm, using a technique they're uncertain of. In fact, it's just wrong. We have ultrasound simulators, called phantoms, that we borrow from the medical school. They're around $300-$400 dollars, and they're simple blocks of gel (silicone? dunno) with vessels suspended within them. The sonographic image looks pretty nice: a couple of straight vessels a couple of centimeters deep. It's not what a patient's arm looks like: vessels that are all over the place, twisting and turning, with various inclusions scattered through the arm. We needed to come up with a way to transition from the perfection of the standard ultrasound phantom to the reality of patient care. Oh yeah, one more thing: No budget. Solutions will start in the next post. (I'm going to try out a cliffhanger ending for this one)

Solar Buoy

My family has a place in Georgian Bay, Lake Huron.


It's remote, and fairly primitive. The entire area is solid rock, occasionally covered by scrub brush and pine forests. The area itself is a deep lake broken by numerous islands. Occasionally a spire of rock is completely surrounded by deep water.

Marking these rocks is a completely DIY effort. Some islands in the area have fairly decent markers.

Our island is not one of them. The vast majority of our markers are empty 1 liter to 1 gallon bottles, with rope. I don't know if they're weighted or actually secured to the obstructions they mark. They seem to stay in place, despite the hard freeze that occurs every year.

Some of these markers are small enough that they're virtually invisible during daylight glare. Forget about trying to see them at night. It's just not going to happen.

For many of the visitors, this isn't a problem. They know the waters like the back of their hand. These folks tear through the area at top speed, and some could possibly do it blindfolded and survive.

I, on the other hand, am not that daring yet. I think I'm a pretty good boater, but I definitely lean on the side of caution. There are times when I'll put someone in the bow of the boat to warn of unmarked obstructions.

I've been going to the island routinely for four years now. One of the things that strikes me is the pure beauty and nature of the area. Anything man-made is the exception to the rule, and it is very easy to keep a "Green-Mind" while I'm up there. I decided my first year to make my Islander Projects as green as possible.

While in Canada, we saw some cheap solar garden lights (Less than $3 at WalMart). We picked one up to mark the path to our camp from the opposite side of the island (we do a fair amount of late night partying). Looking at the light started the ball rolling for a solution to marking shoal hazards around the island.

I wanted a cheap, solar powered solution, with the ability to program the (potentially multi-colored) light pattern. In terms of buoy, I wanted a 4-6" PVC pipe, with a solar collector on top, a battery, and a BlinkM LED in a sealed enclosure.


I hit Home Depot yesterday, and grabbed one of these guys:

Mine was just under $10... Your mileage may vary.

I disassembled and opened everything up as much as I could. The whole thing is basically a solar array, a 3.2V Lithium Battery, and a circuit board. I wasn't able to figure out how to completely disassemble the unit to get at the pieces-parts I wanted, so I grabbed my Dremel.

I cut the sucker:

If you cut along this line, you will miss the circuit board while still preserving the reflector and lens assembly. Take caution to avoid the wires. I then did an additional cut to create a channel to free the wire from the upper connection hole. This allowed me to get the circuit board removed, and I was left with a small, intact system comprised of a solar cell, circuit board and LED's, and the battery.

I fired up the soldering iron and removed the LED's. Thankfully the LED's all use the same ground and power lines. I didn't want to spend too much time figuring the circuit out (later, ok?). I marked which side of the LED's were notched (in the top view of the board, the sharpie scribble in the bottom of the picture is supposed to be an "N").

I then cut one of my breadboard wires in half, so I would have two easy female sockets to supply to my BlinkM.

The images are from the ThingM website and SparkFun.

There are a bunch of cool things about the BlinkM LED module. First, the cost is pretty low at ~$13. The next is the form factor. These things are pretty small. Third is the well integrated multi-color LED, with the stand-alone microprocessor to control it. You can program the LED patterns, and then just supply power. The system will blink, fade and change color, however you have programmed it.

All of this makes it perfect for this project. The cheapie solar array, battery and board will store power, and then supply power to the LED's when the light level goes down. From there, the BlinkM just does it's thing. ThingM has even provided a very easy graphical programming tool for the BlinkM's

I used the breadboard wire to connect the power to the solar array, so that I could easily remove the BlinkM to program it. Once it is programmed, I just hook the power up to the board. The "notched" side of the LED's is the negative feed. You can see in the circuit board picture (Picture #3) above how I soldered the wire (again, you do have some options here).

I tried the system out, last night, and it lasted all night. I didn't really do a formal test of the charging time versus discharge time, but the LED was blinking away this morning after being in the dark for 12 hours.

I need to figure out how to mount this thing. Clear four inch PVC pipe is hideously expensive. I think I'm going to look for a clear Pelican case or Otter Box. That still remains to be seen. I also want to work a switch into the BlinkM connections so that I can re-program these things if I need to.
Finally, I'm going to get a $3 solar light from Home Depot, and compare that one. If I can get the same (or similar) performance for less cost, I'm all for it.

There is one possible upgrade, and that is to a BlinkM MaxM. These things put out an insane amount of light, but I think I'd need to upgrade the power. As it stands, this thing is completely kit-bashed, with no real original circuitry on my part. I think I would have to actually do some circuitry work to get a BlinkM MaxM running off of a solar charged battery.

Costs:

Malibu Solar Powered Flood Light $10 Home Depot
BlinkM Module $13 SparkFun Electronics

Enclosure: TBA

Open Source Wine Rack

I don't get to drink a lot of wine in my own house.

I'm poor.

That doesn't mean I don't like to drink wine. Far from it. I love wine.
Initially, I hit upon the perfect wine drinker's racket: Family
My father and my sister are both wine drinkers. More to the point, they're getting better and better at being connoisseurs. They're getting really good at picking wines.

So, do the math:
I like wine - I'm poor + (Sister + Father like wine * (Good at Wine)) = Profit!

Well, ok, not profit. Drunkards never profit (or so I'm told). But I'm certainly better off than I am without.

My parents are splitting up and they're having to sell their house. I won't get in to the massive insane bummer that this is (It's huge).
However, the silver lining is that we had to empty the basement.
Which is where the wine was kept.

As a result I received a couple of boxes of wine, and no where to keep them. I looked for a wine rack:
http://www.amazon.com/J-K-Adams-MWR-40-Hardwood-40-Bottle/dp/B00028X32M/ref=sr_1_4?ie=UTF8&qid=1311212774&sr=8-4

Ninety dollars???? Are you insane? I'm poor! I just need to keep my wine off the floor (You can cry over spilt wine).

I went to Home Depot and bought $15 worth of wood. No tools.

It actually took me longer to do the calculations than to actually make the wine rack. I needed a wine rack that could hold small bottles securely, but still manage to hold the big bottles of ripple that we occasionally get. The bottle diameters range from 2.75" to 3.75".

I bought several 3/8th inch wooden dowels, and a bunch of 2"x2"x8' non-treated (dry) wood. After some quick math and experimentation, I found that I needed to cut the wood as follows:

Dowels 3.75"
2"x2"s 12"

On all four vertexes of the 2x2 I drilled 3/8th inch holes one inch from the ends (a total of 8 holes). I marked the 3/8th inch drill bit one half inch away from the tip (the real tip) with a Sharpie marker, and drilled the vertexes until the mark just disappeared.

Two parts. That's it.

Some caveats: A table saw really helps. Cutting the wood took no time.
A drill press really helps. My drill press is pretty crappy. It has a fair amount of shimmy to it, making it difficult to drill precise holes. It still really helped.

I made a jig to drill the wood. Drilling the vertex of a 2x2 is a difficult proposition. Cutting a short section of 2x2 from vertex to vertex gave me two pieces of wood. Putting those two pieces on to a thin piece of plywood, next to each other, and gluing them, gave me a sturdy method for holding the wood as I drilled into the edge.

However, the slightly variable hole axis was planned into the build. I knew my drill press wasn't up to drilling the exact same hole, over and over. With the holes drilled to the exact same size as the dowels, there would ordinarily be some looseness to the fit of the dowels in the holes. But with the holes being at a slightly different angle in each of the 2x2's, the dowels locked right into place when the rack was put together.

I did glue the wine rack together. It might have held together without doing this, but there are some pretty nice bottles of wine on the rack. At least one collectible bottle, and one bottle with a lead sealed cork (yeah, lead sealed). I really didn't want to risk a break with these bottles, as I really feel that they belong to my family.

Build time was quick. The current wine rack holds 24 bottles of wine. It cost $15 to make, and is easily expandable. I'm probably going to double to quadruple the size of it. The materials are cheap, and I could easily stain it to match my eventual house.

I wrote about this because of the low part count (two), and the fact that anyone could do this, if they just considered the math behind the build. Well, I did the math for you (follow the directions above, and you can have the same wine rack).

WiFi Sniper Rifle

I'm working an insane amount. Between the hospital and school, it doesn't leave much time. I stuff that time with the consulting work, and efforts on a new project to make a fair amount of money.

This post is about none of that.

One of my classes last semester was Wireless Network Security. It seemed to me that like many security problems, this was one of access. To top it off, because many people (and still some organizations) use shoddy security, if you can just get access, you are on the network. I've sat in a couple of dining rooms and offices showing clients how quickly their network can be compromised by not using their security tools correctly.

I'm also getting ready to go on vacation in the wilds of Canada. I'll be honest, I like my internet to be readily available, wherever I go. The last time I was there, we had some issues with signal and antenna aiming. I've been thinking about that problem ever since.

I had some parts lying around the house. Specifically for this project I used only a couple of real parts:
1x 802.11 2.4GHz "25dBi" antenna (Supposedly it works on 5GHz as well, I haven't tried)
1x 802.11n MIMO USB adapter, with two removable antennas
1x AR-15 Lower Receiver with handle (Airsoft Surplus, no modifications needed)
1x Removable stock
1x Cheap Bushnell Scope w/mounts
1x Short length of P-rail to mount the scope

I also used some PVC piping (1 inch, I think) to act as a pillar for the antenna, lower receiver and scope to attach to. I made a small acrylic block and secured it to the PVC pipe as a connection point between the PVC and the lower receiver. Various screws, nuts and some scrap wood were used (The scrap wood was planed to fit in the butt of the PVC, to further secure the PVC to the lower receiver. Another plug was fit to secure the pistol grip to the lower receiver).

I sent a picture to a friend of mine. I think I need to do this with all of my kit-bashes from now on. In the past he's typically been working next to me, when I do these things. He frequently says things like "Are you sure you want to....", or "Hey man, that's not real smart....", or "Is something burning?"
In short, he's the safety cut-out for many of my projects (Despite the fact that he literally has an entire self-inflicted injury category named after him).

His first reaction "Dude! (He's 37 or something) Dude! Is that a railgun?"

So I disappointed my best friend, but again, he probably saved me some grief by showing me a big problem.

This thing looks just like a firearm. More to the point, it's a scary firearm that will make everyone twitch if they see it. Not exactly the kind of thing you want to hang out with on a hill, and point at random dwellings to get an idea of its range.

Now, as an aiming device, this thing is going to be great. I'll be able to visualize my target antenna, and then slowly move the system around to get the best signal. However, I already recognize the difficulty of typing while shouldering the "rifle".

To combat that (and the scary pointing issue), I'm working on a tripod mount for the antenna and PVC assembly. Once the signal is established, I can disassemble the stock and lower receiver around the antenna/PVC assembly, which are secured using a stable tripod.

This is going to work really well in the Wilds of Canada (It sounds cooler when I capitalize it), and at home, I probably won't need the extreme range features of the whole build. I may look at a method of just securing a hand grip directly to the PVC. Then it's going to look like I'm aiming a giant linear antenna, instead of a railgun.