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.