opgenorth.net

.22LR Ammo Evaluation - Sterling Cross

Fri, 26 Apr 2019 14:39:00 +0000

Over the past couple of years there has been a surge of interest in .22 Rimfire in Canada (at least from my perspective). Arguably, it could be traced to the start of Project Mapleseed back in 2017, which then spawned the Canadian Rimfire Precision Series in 2018, and now this year the Outlaw Rimfire Precision Series. My friends south of the border have Project Appleseed and the National Rimfire League. As you can see, plenty of opportunity to participate/compete with the humble .22LR cartridge.

Prior to this I had always assumed that all .22LR ammunition was the same - it didn’t matter what brand you used they all performed the same. I’ve come to learn that this isn’t the truth. Much like their centre-fire big brothers, .22LR rifles have their own personalities and will shoot better with some brands of ammo than other. Don’t assume that the cheap ammo will always shoot poorly in a given rifle. Likewise, it’s entirely possible that expensive match grade ammo will perform poorly in your rifle. The best method (and probably the most fun) is to try out different brands and see what works best.

The first brand of .22LR I decided to check out was from Sterling Cross. This is available from Canada Ammo. In went to my indoor range at 40 yards with a brick and fired a few groups to see how it performed. The rifle in question was a stock Remington Model 597 and a Bushnell AR-22 (the older version). The ammunition seemed to group okay:

However, there is very little ballistic information available for this brand of .22LR. The box has the muzzle velocity printed on the outside as 1130fps, and that is about it. I wanted a bit more information so that I could build a drop-chart, and so I went to an outdoor range with a chronograph to do some testing at 50m.

Ballistic nerds will appreciate that environmental conditions have a significant impact on ammunition and the calculation of the BC. Here is the environmental information that I recorded on that day:

	Imperial	Metric
Altitude:	2490 feet	758 metres
Temperature:	59 F	15 C
Air Pressure:	26.961 inHg	913 mb
Humidity:	51%	—

The wind was pretty brutal. It was typically about 5mph with prolonged gusts around 10mph. The highest wind I observed was 22mph. In general, the wind seemed to come in from about the 10:30 to 11:00 direction.

I gathered some velocity measurements on about 40 rounds I fired. My chorograph captured the velocity of the projectiles at several points between 0 to 50 yards. (Yes, I know I’m mixing systems of measure here; it’s an imperfect world but at least I’m not making you do to the math). Without boring you on the velocities that were recorded, here’s what I observed:

	Imperial	Metric
Average Velocity:	1103 fps	336 m/s
Highest Velocity:	1155 fps	352 m/s
Lowest Velocity:	1014 fps	309 m/s
Extreme Spread:	140 fps	42.7 m/s
Std. Dev:	23.5 fps	7.16 m/s

Punching all the above values into the online JBM BC calculator, and we arrive at the following two BC values:

BC Model	Value
G1	0.140
G7	0.074

The .22 projectile seems more like the G1 reference projectile, so I stuck with that value to calculate a drop chart. I did this once with Strelok Pro, and then again with Applied Ballistics. Here’s the results (in MOA) for my rifle:

Metres	Strelok Pro	Applied Ballistics
25	- 0.50	0.50
36	- 1.00	-0.75
50	0.00	0.00
75	+ 3.25	+ 3.25
100	+ 7.00	+ 7.25
125	+11.50	+11.50
150	+16.25	+16.25
175	+21.25	+21.25
200	+26.50	+26.75
225	+32.00	+32.25
250	+37.75	+38.25
275	+43.75	+44.50
300	+50.00	+50.75
325	+56.50	+57.25

It’s comforting to me that Strelok and Applied Ballistics have very similar values (theortical they may be). The next step for me is to head out and actually test these values in the Real World at 100m, 150m, 200m, and (time permitting) 300m.

Reforming Brass: From One Cartridge to Another

Mon, 01 Oct 2018 14:39:00 +0000

The 8mm Mauser (7.92x57mm) round, in it’s current incarnation, has been around since 1903. It is a improvement of the original 7.92x57mm cartridge that was developed in 1888 by Peter Paul Mauser. Arguably, 8mm Mauser has been one of the world’s most popular cartridges, having seen significant military and civilian use over the past 100+ year. It also influenced the design of many of today’s cartridges, such as .30-06.

Finding good 8mm Mauser ammunition (in Canada at least) is becoming harder. The glut of military surplus rifles and ammunition for this cartridge is long over, and there are more modern cartridges which have gained a significant following.

The solution to the scarcity of 8mm Mauser is to hand load your own ammunition. Generally speaking all of the components necessary for reloading 8mm Mauser are common enough that a competent hand loader need not worry about having a supply of 8mm Mauser on hand.

Lately this seems to have changed (in Canada at least). The availability of 8mm Mauser brass seems to be drying up – it’s hard to find on the range (leftover by those who do shoot this cartridge), and buying commercial brass can be expensive.

One option available to the hand loader is to reform brass from another cartridge to 8mm Mauser. Note that while I’m talking about 8mm Mauser, these principles can apply to pretty much any cartridge; for example reforming .223 brass to 300BLK.

Reforming Brass

Forming brass isn’t as bad as it sounds. Brass is a soft metal, and can be easily shaped without using to much specialized equipment or force. Not all brass cartridges can be reformed to 8mm Mauser. As a general rule of thumb, anything that is a derivative of 8mm Mauser and is as long or longer that the 8mm Mauser case can be reformed. A good example would be .30-06 Springfield or .270 Winchester. Both are very common hunting cartridges in North America.

This picture shows the brass and reloading dies that I use to reform:

From left to right:

Original .270 Winchester brass.
Redding Form & Trim die for 8mm Mauser.
.270 Winchester after the reforming die.
Reformed .270 Winchester, after a rough cut to remove excess material.
8mm Mauser full length resizing die.
Reformed .270 Winchester brass, after full length resizing.
New piece of 8mm Mauser brass: trimmed to 2.230”, chamfered, deburred, and annealled.

Collecting tools and components

The first step is to collect the necessary materials and tools. In my case I gathered up:

A bunch of .270 Winchester brass, donated to me by a fellow at the range who had the foresight to collect his brass and the generosity to give it to me.
Lee Precision Resizing Lube.
Redding Form and Trim Die for 8mm Mauser (SKU 749-003-765WB). RCBS also makes trim die. Some people will just run their brass through a full length resizing die. I this case, I opted to use a reforming die.
Hack saw.
8mm Mauser full length resizing die.
Tools to trim, chamfer, and deburr brass.
A good friend who knows how to anneal.

The process

Once I had everything, it was necessary to prep the brass. I tumbled it to clean it up, and then lubed each case. So far, nothing different for reloading any metallic cartridge.

I took each piece of brass, and ran it through the reforming die. I didn’t lower the ram of the reloading press immediately, I left it up:

With the ram all the way up, I used my trusty hacksaw to trim away the excess material from the case:

After performing this rough cut on each piece of brass, I’d lower the ram, take the brass out, and quicking inspect the mouth of the case to make sure there weren’t any significant burrs around the mouth of the cartridge. Any burrs should be removed before proceeding on to the next step.

After reforming and making the rough cut, I pressed the brass through my full length resizing die. I didn’t find it necessary to lube the case a second time. Note that if there are excessive burrs on the case of the mouth, the full length sizer may mangle the piece of brass, rendering it useless.

Finally I would trim the brass to the SAAMI spec for 8mm Mauser, and then deburr it. It is recommended to trim the case to 2.230”, and the maximum length of the case must not exceed 2.240”. This diagram shows the SAAMI spec for 7.92x57mm (dimensions are in millimetres):

Afterwards, I had the brass annealled. This is necessary because the steps involved with reforming and resizing the brass will result in it being “work hardened”. This means that the brass has become brittle and hard as a result of the forces being used to reshape it. The case necks will quickly crack due to the pressure generated when the cartridge is fired.

At this point, I can have prepped brass, ready for the process of being primed, charged with gunpowder, and being topped off with a projectile.

Ballistics of the Norinco 7.62x51

Tue, 16 May 2017 00:14:00 +0000

After an amateur attempt at trying to calculate the BC of the Norinco 7.62x39mm ammunition, I thought I would do the same thing with Norinco’s 7.62x51mm ammo. As one would expect, this stuff is fairly inexpensive as well, running aroun $0.50/round. I don’t think this is “precision ammo”, but it works well enough in my M-305 rifle.

First off, I pulled one bullet apart, and weight it. The projecticle itself weight 146.1 grains, so I guess this is supposed to be 147gr ammo. I measured ~ 42.0 grains of “mystery gun powder”.

First some environmental data that I recorded while I was at the range (or looked up on Google Maps) earlier this week:

	Imperial	Metric
Altitude:	2490 feet	758 metres
Temperature:	47 F	8 C
Air Pressure:	27.07899 inHg	917 mb

Humidity: 77%

Next, after firing 19 (well, it was 20, but only 19 shots were recorded by my chronograph) rounds through my M-305, I collected the following information:

	Imperial	Metric
Average Velocity:	2670 fps	814 m/s
Highest Velocity:	2731 fps	832 m/s
Lowest Velocity:	2621 fps	799 m/s
Extreme Spread:	109 fps	33.1 m/s
Std. Dev:	27 fps	8.34 m/s

I’ll omit the velocities from the flight of the bullet, we’ve got enough boring numbers. So running these numbers through the JBM BC calculator and we get the following two BC values:

BC Model	Value
G1	0.351
G7	0.176

Ballistics of the Norinco 7.62x39

Sun, 07 May 2017 01:10:00 +0000

On of the great things about 7.62x39mm rifles (like the SKS) is that (for the time being) ammo is fairly inexpensive. A fellow who keeps his eye open for a deal can find 7.62x39mm in the range of $0.16CAD (for corrosive) to $0.30CAD (for non-corrosive) ammo. Of course being surplus ammo, finding ballistics data on this ammunition can be a bit of a trick. Granted, the 7.62x39 cartridge isn’t exactly a “precision” round, but intellectual curiousity had me wondering what the ballistic coefficient (BC) of this Norinco ammo was.

Given the right inputs, it is possible to calculate the BC for a given round. The tricky thing is that you need the velocity of the projectile at two points along the path of the bullet. This requirement makes it somewhat difficult (if not impossible) for the layman to perform his own amateur calculations.

Luckily, technology has improved a bit, and now the tools are available to track the velocity of a projectile. So, what does a middle-age guy do on a Friday night? Why he analyzes the data from his previous trip to the range and tries to figure out what the BC of this surplus ammo is.

(For the curious, I used the BC Calculator available from JBM Ballistics website)

First some environmental data that I recorded while I was at the range (or looked up on Google Maps) earlier this week:

	Imperial	Metric
Altitude:	2490 feet	758 metres
Temperature:	61 F	16 C
Air Pressure:	29.58 inHg	1001.6 mb

Humidity: 31%

Next, after firing 20 rounds through my SKS, here is the ballistic data from the rounds that were discharged:

	Imperial	Metric
Average Velocity:	2450.63 fps	746.95 m/s
Highest Velocity:	2483.85 fps	757.08 m/s
Lowest Velocity:	2421.29 fps	738.01 m/s
Extreme Spread:	62.56 fps	19.07 m/s
Std. Dev:	12.74 fps	3.88 m/s

I’ll omit the velocities from the flight of the bullet, we’ve got enough boring numbers. So running these numbers through the JBM BC calculator and we get the following two BC values:

BC Model	Value
G1	0.266
G7	0.131

Comparing these BC values to commercial ammo, and we can see that Tula has a G1 BC of 0.306 and that Hornady has a BC of 0.295.

Hope this information is useful to someone else out there.

Don't Let Crud, Corruption, and Communism Kill Your Smart Watch

Fri, 25 Sep 2015 03:45:32 +0000

I have a Samsung Gear Live. One day, all of sudden, it wouldn’t turn on after I had it charging in it’s little charging dock. I thought the problem was with the watch, and Google the symptoms led me to one of two conclusions:

The watch was defective, and I should send it back under warranty.
I could fix the problem by taking the watch apart, disconnecting the battery for a minute, and then reconnecting the battery. Or something like that.

I was a bit dismayed that for a device not even a year old that these were my options. I was mulling over the options, and I flipped the watch over to see what tools I would need to take the watch apart (who doesn’t like disassembling electronics), when I notice that the contact points on the watch were filthy (as one the NCOs on my infantry course used to say when inspecting rifles – “crud, corruption, and communism”). You can see the contacts for the charging dock right in the picture below:

I figured cleaning these contact points was easier than taking the watch apart and quicker than sending the watch back, so I grabbed an eraser and gave the contacts a quick scrub. I plugged the watch back into the charging cradle, and all of a sudden it started charging again.

I’ve had to do this a couple of times now. I recently found out that some erasers may leave a thin film of residue that may attract dirt. There are a couple of options available:

Rubbing alcohol and a Q-Tip. One fellow I work with will clean the back of his watch every week with this.
CAIG Deoxit. Another co-worker with an electronics background suggested Deoxit by Caig. Put a bit on a Q-Tip, and then clean away. This product will not only clean the contacts and remove oxidation but will leave behind a thin layer to help prevent oxidation.

Anybody else experienced this problem with their watch? What solutions did you use?

Getting Started with Data Binding in Android

Tue, 15 Sep 2015 03:45:32 +0000

(Note: This is an updated version of a post from June, 2015)

In May, 2015 at Google announced a data binding library for Android. The data binding library is currently in beta, so things might change and make what I am saying here irrelevant/obsolete. When in doubt, consult the official documentation.

It’s long overdue – developers no longer have to come up with their own schemes for displaying or retrieving data from their views. With two-way data binding, it’s possible to remove a lot of redundant boilerplate code from the activities and fragments that make up an application.

There were several steps/phases when I went through while I was learning this. Here’s what I did:

Just a warning - Android data binding is still a beta product, so as such things may or may not work when they should, and the documentation may or may not be accurate.

The source code for this sample is up on Github.

Add data binding to Android Studio – This is a one time thing, a couple of lines in some Gradle files.
Create a POJO for the binding – You don’t necessarily want to bind to a domain object. Arguable it’s a cleaner design to have another class with responsiblity of data binding (and maybe some validation too). Model-View-ViewModel is an excellent pattern in this regard.
Update the layout file – We help the data binding library out by adding some meta-data/markup to our layout files.
Update the activity to declare the data binding – This will tell the data binding library how to connect the views to the POJO.

Adding Data Binding to Your Project

First off, make sure you’re running Android Studio 1.3 or higher. As long as you’re keeping current with the Android Studio

Next I had to edit the project’s build.gradle file, my dependencies section looks like this:

dependencies {
    classpath 'com.android.tools.build:gradle:1.3.1'
    // TODO: when the final verison of dataBinder is release, change this to use a version number.
    classpath 'com.android.databinding:dataBinder:1.+'
}

After that, I updated the build.gradle for the app module. The first two line in the file are:

apply plugin: 'com.android.application'
apply plugin: 'com.android.databinding'

That’s pretty much about it. Now that our project is aware of data binding, let’s see about the code and UI changes I had to make.

Using Data Binding

From here, you might be best off reading Google’s docs on data binding, just to get a feel for how things work. If you’re familiar with data binding in XAML (say WPF or Xamarin.Forms), you might notice some simularities.

(Allow me digress a bit and offer this piece of advice again: think twice about binding directly to your data model. This is a perfect opportunity to bring some Model-View-ViewModel goodness into your Android application. I’m not going to talk to much about MVVM though.)

Updating the Source Code

To keep my UI as code free as possible, I abstracted much of the data binding logic into the following class (his isn’t all the code, just the parts relevant for this example):

public class PhonewordViewModel extends BaseObservable {
    private boolean mIsTranslated = false;
    private String mPhoneNumber = "";
    private String mPhoneWord = "";
    private String mCallButtonText = "Call";

    @Bindable
    public String getPhoneNumber() {
        return mPhoneNumber;
    }

    @Bindable
    public String getCallButtonText() {
        return mCallButtonText;
    }

    @Bindable
    public boolean getIsTranslated() {
        return mIsTranslated;
    }

    @Bindable
    public String getPhoneWord() {
        return mPhoneWord;
    }


    public void setPhoneWord(String phoneWord) {
        mPhoneWord = phoneWord;
        onTranslate(null);

    }

    public void onTranslate(View v) {
        mPhoneNumber = toNumber(mPhoneWord);

        if (TextUtils.isEmpty(mPhoneNumber)) {
            mCallButtonText = "Call";
            mIsTranslated = false;
        } else {
            mIsTranslated = true;
            mCallButtonText = "Call " + mPhoneNumber + "?";
        }
        notifyPropertyChanged(net.opgenorth.phoneword.BR.phoneNumber);
        notifyPropertyChanged(net.opgenorth.phoneword.BR.isTranslated);
        notifyPropertyChanged(net.opgenorth.phoneword.BR.callButtonText);
    }
}

Here I’ve encapsulated logic into a view class that subclasses BaseObservable. Subclassing isn’t mandatory – a naked POJO will work too. However, BaseObservable provides the infrastructure for setting up the data binding; the POJO can notify registered listeners as values change. As well, POJO’s should be kept as dumb as possible.

Notice that the getters are adorned with the @Bindable annotation - this identifies how the listeners should retrieve values from the properties.

It’s the responsibility of the bound class to notify clients when a property has changed. You can see this happening with the use of notifyPropertyChanged. This causes a signal to be raised to listeners; this is how they find out the name has changed.

The BR class is generated by the data binding library. It is to data binding what the R class is to layout files. Each POJO field or method adorned with @Bindable will have a constant declared in the BR class at compile time corresponding to the name. So, getPhoneNumber() becomes BR.phoneNumber.

With the code out of the way, it’s time to update the layout.

Update the XML Layout

There were a couple of changes that I needed to make to my existing layout for things to work:

Declare some variables in my layout.
Identify properties on the various widgets that will be bound to the variable declared above.
Establish the data binding in the Activity.

Android’s data binding requires that <layout> be the root element of the layout. My old layout started with a <LinearLayout>. It’s also necessary to add a <data/> section that will declare variables and the classes that will be bound to.

Declare A Variable

We need to declare a variable that the data binding framework can… bind too. I had to add a <data> element with a child <variable> element that names the variable and identifies the type Android should use for the binding:

<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">

		<data>
        <variable
            name="phonewordVM"
            type="net.opgenorth.phoneword.PhonewordViewModel" />
    </data>

    <!-- my old layout is here, but omitted for clarity -->

</layout>

This declares a variable phonewordVM that I can use inside my layout file.

Notice that the xmlns:app="http://schemas.android.com/apk/res-auto" will automatically drag local namespaces into your XML. This helps you out a bit because you don’t have to explicitly declare all the namespaces in layout file.

Declare the Bindings in the Layout

Next, I need to set up the binding. In this example, all I want to do is to bind setName()/getName() in my POJO to an EditText. This little XML snippet shows the binding in action:

<EditText
		android:id="@+id/phoneword_text"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:layout_marginLeft="10dp"
		android:layout_marginRight="10dp"
		android:hint="@string/phoneword_label_text"
		android:text="@{phonewordVM.phoneWord}"
		tools:ignore="TextFields" />

Notice the syntax to declare the binding: @{phonewordVM.phoneWord}. This binds the EditText to setPhoneWord/getPhoneWord in PhonewordViewModel. With this in place, the last thing to do is to setup the data binding in the activity.

Establish the Data Binding

Finally, setting up the data binding. This is a very minimal amount of code. We no longer have to first get a reference to a view, access properties on the view, and then manually transfer the value of that view to some domain object or variable in our application.

Below is a snippet from the fragment:

public class MainActivityFragment extends Fragment {

    private PhonewordViewModel mPhonewordViewModel;
    private FragmentMainBinding mBinding;

    public MainActivityFragment() {
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        mPhonewordViewModel = new PhonewordViewModel();

        mBinding = DataBindingUtil.inflate(inflater, R.layout.fragment_main, container, false);
        mBinding.setPhonewordVM(mPhonewordViewModel);
        View v = mBinding.getRoot();

        mBinding.callButton.setOnClickListener(
                new View.OnClickListener() {
                    @Override
                    public void onClick(View v) {
                        final Intent callIntent = new Intent(Intent.ACTION_CALL);
                        AlertDialog.Builder alertDialogBuilder = new AlertDialog.Builder(getActivity());
                        alertDialogBuilder
                                .setMessage(mBinding.callButton.getText())
                                .setNeutralButton(R.string.call_button_text, new DialogInterface.OnClickListener() {
                                    @Override
                                    public void onClick(DialogInterface dialog, int which) {
                                        callIntent.setData(Uri.parse("tel:" + mPhonewordViewModel.getPhoneNumber()));
                                        PhonewordUtils.savePhoneword(getActivity(), mPhonewordViewModel.getPhoneWord());
                                        startActivity(callIntent);
                                    }
                                })
                                .setNegativeButton(R.string.cancel_text, new DialogInterface.OnClickListener() {
                                    @Override
                                    public void onClick(DialogInterface dialog, int which) {
                                        // Nothing to do here.
                                    }
                                })
                                .show();
                    }
                }
        );


        mBinding.translateButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                mPhonewordViewModel.setPhoneWord(mBinding.phonewordText.getText().toString());
                mPhonewordViewModel.translatePhoneWord();
            }
        });

        return v;
    }
}

There are a couple of key things to notice here. First, observe that the fragment inflates a view called fragment_main.xml. The data binding library generates the code of a class called FragmentMainBinding. The name of the binding class is derived from the name of the layout file, with the work Binding appended to it.

Once the binding is instantiated, I tell it what object to bind to. The data binding library created a setter called setPhonewordVM – this is because we declared the variable phonewordVM in our layout file above.

Another interesting thing is that the code for the fragment does not use findViewById or hold a reference to any of the views layout. That is because the FragmentMainBinding has those references. So, for example, if I want to get the value of an EditText with the id +@id/phonewordText, then mBinding.phonewordText.getText() will do the trick.

I set the OnClickListener for the buttons in a very traditional way. In theory, the data binding library should allow to bind event listeners to methods on a view model. However, I have’t been able to get that to work yet. Hopefully I’ll have more luck next version of the data binding library (and/or an update to the docs for the data binding library)

Sie Sind Fertig

With all this, data binding has been accomplished. It may seem like a lot of code, and perhaps it is for such a trivial example. Where the true power of this comes into play is when you want to write tests for your code. Two way data binding lays the framework for the Model-View-View Model pattern, which in turn helps you create a loosely coupled app that is easier to test.

Wiring Up a Nest

Fri, 04 Sep 2015 10:55:00 +0000

This weekend I finally broke down and installed a Nest thermostat in my house. They have a nice compatibility wizard which does a pretty good job of showing you how to wire up your Nest based on the wires you can see in your existing thermostat. There were two gotchas that their wiring diagram didn’t cover. Here is a picture of the old thermostat (a Rodgers-White):

Notice that there were two W wires. I’m not to sure what is up with that, I suspect that that one wire leads up to the humidifier. I ended up splicing the two wires together with a marette, and then connecting the spliced wire to the W connection on the Nest. This was not documented anywhere on the Nest website.
The other thing that the Rc post on the thermostat was jumpered over to the Rh post. All I had to do here is remove the jumper and just plug the wire into the Rh connection on my Nest. This issue was documented on the Nest website.

All in all, the process was quick and easy. Now to see if the Nest actually makes a difference in my energy bill.

Containers Explained for the Novice

Wed, 02 Sep 2015 16:26:00 +0000

Over at the WesternDev “consortium” a random discussion broke out about containers: what are they, how are they different from virtual machines, and how do they work. While no means a “container expert”, I have dabbled a bit and sought to add some clarity to the discussion. It seems that I made enough sense and so thought I would summarize the dicussion here.

The whole idea behind containers is to isolate an application in a known environment. This helps prevent strange interactions with other software or libraries installed as well. I think Docker has the best, concise description of what containers are:

Containers running on a single machine all share the same operating system kernel so they start instantly and make more efficient use of RAM.

and

… containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.

So, while both containers and virtual machines provide isolation, they differ in how they do it. VM’s will emulate the hardware; each VM thinks it’s a computer with it’s own CPU’s, RAM, hard disk, kernel, etc. This isolation is provided by the virtualization host which runs on the hardware.

Containers, on the other hand, have a “host” that uses some kernel extensions to isolate software, but otherwise everything is running on the hardware. Containers share the host computer’s RAM, CPUs, and even the kernel, however each container is secluded from the others and the host operating system. Because of this, containers can startup much faster and appear to be more responsive – they don’t have to talk to a middle man to get access to the hardware.

Most modern Linux distros ship with somee extensions to support containers out of the box, so, in theory, you can just dive right and start creating containers without having to do anything extra on Linux.

In practice it’s easier to use something like Docker to create and manage your containers. Docker also provides a way to share containers via DockerHub. You search DockerHub for something you need, like say Mono, and then you grab the Dockerfile (a recipe that tells Docker how to build the container), and away you go. Alternately, you can create your own custom Docker images based on an existing Dockerfile. It’s kind of like subclassing a container, if you will.

My First QuadCopter

Tue, 21 Jul 2015 16:51:00 +0000

Just recently I acquired a new quadcopter – a WL Toys 959. Total cost to me was about $75.00 and I ordered from Amazon.ca. I picked this because of the low cost and the fact that it came with camera that can do both photo and video and it was relatively inexpensive.

First attempts at flying the quadcopter proved somewhat crash prone, so I ended up reading the manual and checking out some YouTube vidoes on quadcopter flight. Most informative was this YouTube video on Vortex Ring State and how to deal with it (thanks to colleague Joel Martinez for the tip). I have a video of my first flight – it’s nothing fancy I just wanted to take off, hover, and then land.

The batteries last about 10 minutes, which I guess is typical for a quadcopter. I will have to order a few more batteries from Amazon.

The camera itself mounts to the bottom of the quadcopter, but it never seems to want to stay there. I used a piece of scotch tape to help keep the camera attached to the quadcopter. You turn on video by pressing the silver button to the left of the antenna, but you have no way of know if the camera is on or off except by looking at the bottom of the camera. If it is recording then there will be a read blinking light. For some odd reason I don’t seem to be able to take any video at the moment. I did manage to take one video – the quadcopter is taking off, hovering, and then landing. Nothing fancy at the moment.

Reloading 8mm Mauser

Sat, 04 Jul 2015 03:36:32 +0000

8mm Mauser is a great round, problem is that in North America it’s not always easy to find good 8x57mm ammunition. When you do manage to find it, it tends to bit a bit expensive, > $1.00/round. Here is where hand loading pays itself off. I used to handload my own 8x57mm, however I stopped for a few years and now I can’t seem to find my old load data. This isn’t a horrible thing as it means I get to go to the range to test out new recipes.

For the first pass, I happened to have a bunch of 150gr bullets. This is a touch light for an 8mm bullet, but it’s all I had at the moment.

Bullet:	150gr Sierra Pro Hunter
Trim Length:	2.23"
Primer:	Winchester Large Rifle
C.O.A.L.:	3.04"

For the first pass, I loaded up three 10 round batches with different powder charges:

Load #1	Load #2	Load #3
48.5gr IMR 4064	47.6gr IMR 4064	49.0gr IMR 4064

I didn’t measure velocities at this time, I just wanted to see how the various loads would group. I’ll update this blog post with the pictures of the groups later.