Merging modern software development with electrons and metal
Random header image... Refresh for more!

The End of WiMax: What I Did

Since Sprint turned off WiMax last November, I had to make a change.  LTE was one choice.  I’ve done some LTE testing; with newer MiFi units such as the ZTE Z915 device it can be faster than DSL with excellent voice quality for VoIP.

But LTE performance is still much more variable than DSL or Cable Internet, while the cost is comparable to DSL/Cable, and more than WiMax.  With WiMax, I could go cheap, fast, and limited (10G for ~$20/month) with FreedomPop or cheap, slow, and unlimited with Clear (~$35/month).  Average LTE rates are around $40/month for 5GB at decent speeds.

My choice is LMI.net’s PHLO+, which is around $51-$55/month (including all the annoying taxes) for unlimited DSL as fast as you can get, and an analog phone line (I didn’t want the analog phone line, because it’s the reason for all the taxes, but I didn’t have a choice).  It is very similar to Sonic.net’s Fusion service, but since I had already had good experiences with LMI as a previous DSL customer I went with LMI.

I also liked that LMI was open to bringing or buying your own modem, while Sonic emphasizes rental.  So after discussing which modems LMI preferred, I bought a Smart RG SR510N for ~$20 from eBay.  The Smart RG  has worked perfectly so far.  I highly recommend both companies; Sonic does have its advantages, such as more service options (FTTN, FTTH).

My peak speeds are about 18Mbps down and 1.25Mbps or so up using my favorite speed test from DSLReports.

Since PHLO+ comes with a full featured POTS phone line, I bought a ObiLine for my Obi 202.  Some people complain about echoing on the ObiLine; I have noticed occasional echoing but overall the quality has been acceptable.  However, I found I didn’t like how it handles incoming calls forwarded from Google Voice.  (To be fair, I haven’t tried much troubleshooting on these issues, but since I’m happy with my setup, that’s a low priority).

Some other service changes from my last update:

  • I dropped Anveo.  Anveo still has excellent rates for E911 service and unlimited person DID (incoming phone numbers), but I wanted CNAM and didn’t care about Anveo’s features such as advanced call flow.
  • I ported the Anveo number to Ring.to, which was quick, easy, and free.  I’m not using that number a lot, but I value it so it’s a good match for Ring.to with their new usage restrictions (but since Ring.to is free, no complaints from me).
  • I dropped VestaLink after my contract ran out.  VL did work well for me, and since they offered a great deal for a 2-year pre-pay I thought about renewing, but I don’t need it now, and it’s hard to commit to 2 years to a company that isn’t actively looking for new customers.
  • I added CallCentric’s free New York DID, which includes CNAM (Caller ID name lookup).  It’s working well so far, and I’m fine with paying $1.50/month to CC for E911 service.
  • I played around a bit with VoIP.ms; right now I’m not actively using it, but there’s a good chance I will in the future.  I also thought about trying out CircleNet, but decided against it because they don’t offer California DIDs.

So my current Obi 202 setup is:

  • Callcentric DID for primary incoming calls.  Both Google Voice and Ring.to forward to CallCentric, which provides CNAM.
  • Google Voice is the primary line for outgoing calls.
  • Localphone is the backup line for outgoing calls (so I have two outgoing lines).
  • The Obiline (LMI analog line) is used for 911, and backup.
  • One Service Provider is currently empty; I might put VoIP.ms back in here.

The system is working well enough, but my “I’ll do it someday list” includes:

  • Different ring tones for different incoming lines.
  • Automatic switch over (ring on one phone first, switch to second if first line is busy).
  • Maybe add a PBX such as Asterisk.

I know it’s not that hard to do these things, but they just aren’t a high priority.

 

April 29, 2016   3 Comments

DSL Internet Speeds Vary A Lot

I’ve recently moved back to DSL since WiMax is going away.  I’ll have some more notes about my DSL service in the future, but today it’s all about how much my apparent DSL speed can vary, based on running a variety of speed tests.

So what makes my “rated” DSL speed (as rated by a speed test site) vary?  Factors include:

  • The speed test site used; I saw definite differences (in Mbits/sec) between DSL Reports, SpeedOf.Me, and Ookla’s SpeedTest.net.  I decided to standardize on DSL Reports’s speed test (partly because of this)
  • All upload speeds were roughly the same, around 1.25Mb/sec
  • The fastest download speed was direct Ethernet connection to SmartRG SR510N modem: ~18Mbps down (Asus T100TA, USB 3.0 1G Ethernet adapter)
  • Using the SR510N’s WiFi connection, the T100TA speeds varied between 10-15Mb/sec
  • However, when I tried an old but still usable Acer A500 Android 4.0 tablet with the modem’s WiFi, speeds dropped to ~3.0 Mb/sec with a weak wireless signal, and ~8 Mb/sec with a good signal.
  • The A500’s speed with my longer range but slower Netgear WNR1000 via a set of Netgear 85Mb/sec Netgear powerline modems is pretty consistent at ~6 Mb/sec; the T100TA clocks in at 7Mb/sec.  I suspect the bottleneck is the powerline modem.
  • Speeds seem pretty consistent over time when I hold the other variables (test used, PC used, connection used) constant.

BTW, my T-Mobile 4G LTE MiFi can get similar or better speeds.  Its results vary dramatically with the signal type (LTE is much better than HSPDA, and EDGE is painful); typical download range seems to be around 8-18 Mb/sec, and upload around 1-6 MBb/sec.  However, despite the good raw numbers for LTE, VoIP quality is typically much better over DSL (partly because DSL still has much better ping times).  And, of course, there are no affordable LTE options for large amounts of data, while my DSL is unlimited.

September 29, 2015   No Comments

My .NET Notes and Books

I’ve done a fair amount of VB.NET and C# .NET development.  So here are some notes about .NET development techniques along with comments about the  .NET books I own.

Languages

C# is deservedly the most popular .NET languages.  Although some tasks such as COM interoperability are easier in VB.NET, overall I strongly prefer C#.  C# has a more coherent syntax and better support for cutting edge programming techniques such as functional programming.

It’s worth considering the other .NET languages, especially in combination with C#.  However, you also have to consider whether the advantages (such as clearer code and quicker development) out way the disadvantages (such as most programmers not knowing the language).  For example, I’m very tempted to F# at work, but won’t, because it’s not very likely anyone else who might have to maintain my code will know F#.

Microsoft is now putting more emphasis on C++, is pushing functional programming with F# and new C# features, and has basically dropped its support of dynamic languages such as IronPython and IronRuby.  However, these projects are still alive, and can make a lot of sense: for example, adding scripting to easily customize your base software for different customer requirements.

Beginning C#

I learned C# basics using Programming C# 4th Edition, 2005, by Jesse Liberty.  I’d say it’s a good book; reviews for later versions are mixed.  However, depending on where you’re starting from, there are probably better books.

Advanced C#

C# In Depth by Jon Skeet is a superb advanced book on C#.  I have the second edition, and am very impressed with its coverage of C#’s evolution, and its explanations of how and why to use these new features.

This book illustrates one of the biggest advantages of mainstream software development: excellent advanced books.  There are no PLC programming books comparable to C# In Depth.

.NET Development

I bought Juval Lowy’s Programming .NET Components, Second Edition, many years ago for half price at Fry’s.  It sat around until I needed to handle asynchronous programming, send .NET events, use Remoting, and handle some concurrency.  The book is a bit dated, but recently I’ve been referring to it constantly, and appreciate the well written explanations and the author’s tips based on his experience.

Programming .NET Components has chapters on component-oriented programming essentials, interface-based programming, lifecycle management, versioning, events, asynchronous calls, multithreading and concurrency, serialization, remoting, context and interception, and security.  So it covers a lot of useful areas, but its age shows: for example, there’s no coverage of WCF (Windows Communication Framework) or newer approaches to concurrency.

Microsoft classifies Remoting as a legacy technology: it won’t disappear (heck, COM/DCOM is still around), but won’t be actively developed.  I looked at using WCF, but decided its advantages didn’t matter to me, and that it was considerably more complex than Remoting.

I’ve looked into some of the newer .NET technologies but haven’t had a reason to use them yet, including:

  • The Task Parallel Library (TPL) – Microsoft’s preferred way of handling concurrency in .NET 4.0 and higher.
  • The Concurrency and Coordination Runtime (CCR) – originally shipped with the Microsoft Robotic Studio, but can be used for non-robotic applications.
  • Reactive Extensions (Rx) – intended to simplify asynchronous and event driven programs.  It uses cool advanced programming techniques.

My current applications don’t benefit from massive amounts of parallelism, so right now the TPL and CCR don’t offer any major benefits.  I do have some event driven programs, which I suspect could really benefit if rewritten using Reactive Extensions.

GUIs and Programming

Most developers use GUI designers to create the user interface; Visual Studio has a good designer.  Using a designer is easy, initially requires less code, provides instant feedback on the GUI’s look, and provides pixel level control.  However, most designer-created GUIs don’t scale well, don’t handle modifying the user interface at run time, and require a lot of work every time you want to change something.

Another approach is to create the GUI in code.  This was pretty tough in the old days of straight Windows or MFC — there’s a good reason VB became so popular.  However, when I did a project using Python and tkinter, I didn’t have a choice, since tkinter doesn’t have a designer.

Instead, you use layout managers to tell the GUI how to automatically place the controls (e.g. grid, vertical pack, horizontal pack).  Java has similar methods.  Initially, WinForms did not, but later versions added layout managers, although I doubt they’ve been used a lot.

The advantages are that you can make the GUI much more flexible: scalable, adding controls at run time or based on a table or configuration file, and such.  On the flip side, there’s more work up front, you don’t have the same level of layout control, and you do spend a lot of time running the GUI just to tweak the layout.

A third approach is to use a declarative GUI, where you can define the GUI’s elements by declaring them in a configuration file.  (Side note: Windows Installer uses a similar declarative approach.)  WPF (Windows Presentation Foundation) supports declarative GUIs using XAML files.  You can also create WPF GUI’s using a designer (including Microsoft’s stand alone designer, Expression) or using code.

As my readers from Kickdrive.de have pointed out, the well regarded Qt GUI library now supports declarative GUIs.  However, Qt is not well supported in the .NET world although there are bindings such as Qyoto and Qt4Dotnet (which hasn’t been updated in a while).

I’m currently still using WinForms, but that’s because of the project’s requirements.

DSLs and Meta-Programming

DSLs are domain specific languages; in other words, special purpose programming languages made for a specific use, not general usage.  The advantage is that DSLs can be tailored to match the needs of the domain users, not those of programmers.   Then there are DSLs for developers, such as easyb, a story verification framework using a DSL written in Groovy.  Take a look at easyb in action — it’s very different from C# or Java.

There’s at least one book on creating DSLs in .NET: DSLs in Boo by Ayende Rahien.  I don’t own it yet, but I’ll probably add a used copy to my next Amazon order.

Metaprogramming is programs that write or manipulate programs.  Metaprogramming is impossible in ladder logic and many other languages; it’s easiest in dynamic languages such as IronPython.  At its best, metaprogramming can add a lot of flexibility and eliminate huge swaths of boilerplate code.  At its worst, metaprogramming can make spaghetti code look good, so it should be used with care.

I wrote a settings module with metaprogramming; to add a settings variable, I just added its specification (name, type, etc) to a table, and the Python code could automatically load and save the variable, add it to the settings dialog, and add it to the settings object — pretty cool, and a lot less work than doing all that by hand.

Functional Programming

Functional programming has attracted a lot of attention recently, partly because it can ease the pain of parallel programming.  I’m not a total convert, but I do like to use some functional techniques, and have been learning more.  I have three books on functional programming using .NET:

  • Functional Programming in C# by Oliver Sturm– a good book with clear explanations of how to do various functional techniques in C#.  If you’re looking for an introduction to functional programming, look elsewhere.  But if you want to use functional programming in C#, get it.
  • Programming F# by Chris Smith.  I have the first edition, and I’ve done a quick first read — it’s a  good book, and F# is an intriguing and very powerful language.
  • Real World Functional Programming With Examples in F# and C# by Tomas Petricek with Jon Skeet.  I haven’t read it yet, but it looks very interesting: at a glance, it’s chock full of practical examples.

F# is pretty far above ladder logic.  I wouldn’t recommend it as the control language for a high speed packaging line, but it can easily handle data manipulation tasks that would be impossible in ladder logic.

Testing and Development

As I’ve mentioned before, The Art of Unit Testing by Roy Osherove is an excellent book, well written and filled with practical advice.  I recently bought Test Driven Development in .NET by James Newkirk and Alexei Vorontsov; the review are good but I haven’t read it yet.  Applying unit testing is a bit harder with automation: I can see how I could apply it to communications code, but not to motion code.

IronPython In Action by Michael Ford and Christian Muirhead is worth considering, even if you don’t plan on using IronPython as your main language, because it can show you some different approaches with its chapters on unit testing, metaprogramming, WPF, and scripting.

Communities

One big difference between mainstream software development (such as Java, .NET, and C/C++) and automation development is that on automation side, development is vendor driven, while the mainstream development community has drive a lot of advances such agile development, lean development, unit testing, Test Driven Development (TDD), Behavior Driven Development (BDD), continuous integration, distributed version control (git, mercurial), refactoring, design patterns, and DSLs.

July 17, 2013   1 Comment

Ooma Quirks

Overall, I’m still pretty happy with our Ooma system.  However, I have run into a few quirks:

  • If you want to use call screening (where you can hear the caller leaving a message on the answering machine), you either have to pay for Ooma Premier or put an answering machine on Ooma’s output phone line and set it to answer before Ooma’s answering machine.
  • If you have a regular phone line connected to the Ooma, Ooma will use it when calling out all local calls, not just for 911 emergency calls.  This can be a problem if you’re on a metered local plan and make enough local calls.
  • Apparently, this option can be changed, but Ooma won’t make the change anymore.
  • However, everyone on the forums recommends totally splitting your lines: Ooma connected to Internet only, local phone line connected to a different phone.  You do get extra features for free this way, for example, caller ID.
  • Ooma occasionally changes their web interface around.  For example, the connection tone option (Ooma plays a special sound when the connection is made) has been removed.

Some final Ooma notes:

  • The Ooma forums are pretty useful.
  • Broadband options are a pain.  For example, here in Silicon Valley, dry loop DSL costs about the same as DSL + metered local phone service: $40/month or so versus about $41/month ($22 + $19; unlimited local is ~$27).  Cable internet without cable TV isn’t any better.  Clear isn’t a good option unless  I could bundle home + mobile, but their coverage doesn’t work for me.
  • So for right now, I’m sticking with DSL at home + metered phone, with the Ooma and local phones separate: the Ooma is connected to a cordless phone (plus maybe later an answering machine if Caller ID doesn’t work well for call screening), and the phone line is connected to a different cordless phone/answering machine.

October 21, 2011   No Comments