FRS Channel Expansion

If you are in USA and fan of walkie-talkie (aka FRS) radios, you can look forward to the additional 8 channels and higher allowed output power.

It used to be that FRS (Family Radio Service) had 14 channels shared with GMRS (General Mobile Radio Service) and GMRS had additional 8 to boost. With the new rules FRS and GMRS share all the 22 channels and their only difference remains allowed output power and bandwidth (25 vs 12.5 kHz). You can check RadioReference’s handy chart.

Additional notable change is how licencing is handled - gone are double purpose FRS/GMRS radios where the only difference was honesty of user. With the new rules FRS cannot be combined with GPRS in the same radio. Thus you won’t be able to boost power in FRS radios by just a change in settings. That will also make enforcing 12.5 kHz bandwidth more easier and it will make interfacing between FRS and GPRS much more annoying for inexperienced user.

While I am really pleased by expansion of FRS channels to what every radio on market already supported, I am sad that 12.5 kHz restriction remained when equivalent GMRS channels are 25 kHz. Why the hell not allow the same bandwidth?

In any case, these changes are mostly good and improvements are just codifying what people have been doing anyhow. Only if they could drop GMRS licence altogether… :)

Shimming Lumix Battery

Due to various first-world problems, my wife and I ended up with two different Panasonic cameras. I use quite interesting LX100 while she strongly prefers FZ300 and zoom it brings.

FZ300 uses lithium-ion DMW-BLC12 battery (7.2 V, 1200 mAh, 36.0 x 48.0 x 16.8 mm) and comes with DE-A79 battery charger. My LX100 is a bit smaller and uses DMW-BLG10 battery (7.2 V, 1025 mAh, 37.0 x 42.0 x 14.1 mm) coming with a smaller DE-A99 charger. As you can see from measurement, it is not the same battery. And no, neither charger is designed to be universal.

However, pinout and voltage is the same on both and you can sort of get smaller LX100 battery into FZ300 charger. Unfortunately, as battery is shorter, it doesn’t stay in nor it charges. Only if I could find common house-hold item that could bridge that 6 millimeter gap in length…

Well, it ends up that 4.5 mm of USB connector is just enough for flexible pins on charger to make contact with battery. And my old SanDisk USB drive fits just right.

Lazy<T>

Quite often in singleton classes you might find yourself doing the standard plumbing code like this:

private static MyClass _current = new MyClass();

public static MyClass Current {
    get { return _current; }
}

or a bit simpler with C# 7:

public static MyClass Current = new MyClass();

If class is a bit heavier (e.g. using lots of memory) you might do it lazily with a lock:

private static MyClass _current;

public static MyClass Current {
    get {
        lock(SyncRoot) {
            if (_current == null) { _current = new MyClass(); }
            return _current;
        }
    }
}

What almost never gets any love is Lazy construct known from .NET Framework 4:

private static Lazy<MyClass> _current = new Lazy<MyClass>();

public static MyClass Current {
    get { return _current.Value; }
}

This will initialize class on the first access, it is tread safe by default, and you can even use custom initializer if needed, e.g.:

private static Lazy<MyClass> _current = new Lazy<MyClass>(() =&gt; new MyClass(42));

public static MyClass Current {
    get { return _current.Value; }
}

Exactly what doctor prescribed. :)

PS: And stop using double-check locking.

Average Number of Lighted Segments on 7-Segment Display

For a project I am doing with kids we decided to use 3-digit 7-segment display. As we intended to video the project (eventually), it was easy to make decision that we’re gonna drive every digit fully - no multiplexing. Not only that simplifies programming logic but it also makes display rock steady during video - no flickering here.

However, with so many pins to drive, I got a bit scared about maximum power consumption MCU would need to deal with. Assuming we go with 10 mA per LED, what is actually the maximum current we’ll need?

The easy answer is 7x10 = 70 mA per digit, bringing it to 210 mA total. Assuming all digits are fully on (we haven’t used decimal point - otherwise it would be 8) we would indeed need that much current. However, realistically, are we always going to have number 8 on display?

For this purpose, we’ve gone and created a table - how many segments we actually use for each digit:

As you can see, the most common result ended up 5 segments being lighted. This tells we actually can usually count on 150 mA of precious current needed.

But wait, since our project will count from 0 to 255, we actually won’t have all our digits on all of the time. We need to calculate how many segments we actually have lighted for numbers that we need. An eternity in Excel later we’ve found that median current needed (assuming random distribution) was 120 mA. Maximum was 180 mA (darn 208!) and minimum was 20 mA.

While 180 mA is not trivial, it is definitely less than 210 mA we originally had to count.

My Most Favorite C# 7 Features

With Visual Studio 2017 out and C# 7 in the wild we got a couple of new features. After using them for a while, here are my favorites.

Out Variables The change here is subtle and many would call it inconsequential but I love. Out variables can finally be declared inline instead of pre-declaring them above parsing statement. This small change makes code flow much smoother and, in my opinion, makes all the difference. For example, note the difference between these two code fragments:

int count;
if (int.TryParse(text, out count) && (count > 1)) {
    //do something with count
}

if (int.TryParse(text, out **var** count) && (count > 1)) {
    //do something with count
}

For rare cases when you don’t care about result you can also use underscore (_) character:

if (int.TryParse(text, out **var _**)) {
    //do something
}

Throw Expressions If you are creating classes for public consumption, quite often a big part of your code is boilerplate argument verification and throwing of exceptions. You can now merge usage of that argument with null coalescing or ternary operators. Again, nothing huge but makes code a bit more to the point:

if (text == null) { throw new ArgumentNullException(nameof(text), "Text cannot be null."); }
this.Text = text;

if (number >= 2) { thrown new ArgumentOutOfRange(nameof(number), "Number must be 2 or more."); }
this.Number = number;

this.Text = text ?? **throw new ArgumentNullException(nameof(text), "Value cannot be null.")**;
this.Number = (number >= 2) ? number : **throw new ArgumentOutOfRange(nameof(number), "Number must be 2 or more.")**;

Is Expressions Another change that seems small but it really improves code is just another style of as operator and it will probably cause its demise. It is a syntax candy allowing for inline variable declaration and a bit more readable code:

var comboBox = sender as ComboBox;
if (comboBox != null) {
    //do something with comboBox
}

if (sender is **ComboBox comboBox**) {
    /do something with comboBox
}

Local Functions And lastly, there are local functions. Again, these are nothing you couldn’t do before. I don’t think they are going to be used often most of the time. However, when you parse stuff or deal with state machines, they do come in handy as they do capture local variables.

Wish list

The only thing I still desire in C# as compared to other languages are enum methods. It is not a big thing but it would remove a whole set of helper methods and similar plumbing.