Tuesday, September 23, 2014

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.

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.

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.

Wednesday, October 9, 2013

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!

Sunday, April 28, 2013

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.

Saturday, April 20, 2013

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.

Sunday, March 31, 2013

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.

Sunday, February 24, 2013

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:

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

Friday, January 11, 2013

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.