Category: hardware

Link + notes: Configuration of APC UPS in Ubuntu

The APC PowerChute utility will only run in Windows, but if you are running Ubuntu Linux (or some variation thereof) you can have pretty much the same thing by following the instructions in this article:

Configuration of APC UPS in Ubuntu (Tech-Niche)

The article suggests you install gapcmon but you probably don’t need to do that, because Ubuntu already includes a Power Statistics utility that works well enough for most users.

If you have problems getting it to work, make sure the USB cable is plugged into the correct jack on the UPS (with some models it’s easy to plug it into a network cable jack by mistake). From the command prompt issue the command lsusb and it will tell you what is connected to your USB ports — you should see an entry for “American Power Conversion Uninterruptible Power Supply” if the cable is correctly connected.

Notes on using HDHomeRun recorder under Ubuntu for lowest CPU usage when recording from HDHomeRun device

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Sometimes I write articles for others, but sometimes I use this blog just to post a collection of notes on something I had a need to do.  This is one of the latter type.  You are welcome to look, and if it helps anyone else, great, but it’s not a full, step-by-step, “here’s how to do it” article, and I definitely do not advise you to just blindly emulate what I did, since there are probably more elegant ways to do this. This was one of those “I just want to get the thing working” type projects, and I must say that it works very well, at least for me.

HDHomeRun recorder is a simple Python script that will record specific channels based on a pre-established schedule.  It is less CPU intensive (and in my opinion, much easier to set up) than some of the other ways to do this, such as Myth TV.  But it is more limited — in particular the current script will only record from a single tuner, and there’s no GUI at all.  Everything is done in script and configuration files.

Here’s what I did:

Using  apt-get or Synaptic, install the following:  hdhomerun-config-gui, hdhomerun-config, libhdhomerun1, python-pip:
sudo apt-get install hdhomerun-config-gui hdhomerun-config libhdhomerun1 python-pip

Install apscheduler:
sudo pip install apscheduler

EDIT (for newer version mentioned by Fred C. in the comments): Then go to this page and click the ZIP button to download a ZIP file containing HDHomeRun recorder.  Unzip it into a subdirectory off of your user directory (I named the subdirectory HDHomeRun_Recorder on my system) — you should get several files and a scripts directory, which contains a couple more files. At this point you might want to check the ownership and permissions of the files — in particular make sure the .py files are executable. Do NOT follow the instructions in the README file; they are for an older version of the software. You may want to read the file, particularly if you have a WDTV Live media player, but the INSTALL section needs updating.

You then need to modify a couple of the files.  This is a bit tricky because what might seem the obvious way to do it won’t work (unless you apply my fix mentioned below).  So here is what you need to do:

(Read through this before actually doing anything, it may save you some effort!)

First, modify config-file.  There are three things you need to change here.  First you need to change this line as shown:

hdhomerun_config = /usr/bin/hdhomerun_config

This assumes the hdhomerun_config program is in /usr/bin, which it will be if you installed it using apt-get or Synaptic.  Next, you need to modify the tuners line to show the correct tuner IDs for your HDHomeRun — you can discover these using the HDHomeRun Configuration utility, if you don’t already know them.  And, you need to replace the entries in the channelmap section with your local channels.  You can run the hdhomerun_setup.py program (run it with no arguments and it will tell you what arguments it needs) and it will show you a list of channels (note it takes a few minutes to run, so be patient), and it appears as if it produces an entire config-file for you, but it doesn’t (keep reading before you do anything, there’s a fix for this below that you might want to try).  So look at the list of channels it outputs and then change each line to match the format you see in the included config-file.  For example, let’s say you see:

35.1   = 11   3   WGVU-11
35.2   = 11   4   WGVU-11
35.3   = 11   5   WGVU-11
35.4   = 11   6   WGVU-11
0 = 11 9 (control)
0 = 11 10 (control)

What that needs to be changed to in config-file is:

35.1 = 8vsb:11, 3       ; WGVU-11
35.2 = 8vsb:11, 4       ; WGVU-11
35.3 = 8vsb:11, 5       ; WGVU-11
35.4 = 8vsb:11, 6       ; WGVU-11

I have no clue why the hdhomerun_setup.py program doesn’t produce the correct output, it just doesn’t. I tried fixing it to produce the correct output (despite the fact that Python is a very incoherent language to me), and think I have it, so if you want to try my fix to hdhomerun_setup.py, the code is at the end of this article.

Second, you need to modify schedule-file. This is an example schedule file, and you just modify the entries with programs you like to record.

When you run the python script, I found that you need to actually be in its directory, and also that when you run it, it will seem like nothing is happening. And the command prompt won’t come back either, so you may want to initially run it using screen:

screen ./hdhomerun_recorder.py

You can use Control-A followed by D to detach from the process. To check that it started and everything is working okay, check logfile (in the same directory as the hdhomerun_recorder.py program). I found that the following could be used to kill the process:

pkill -f “python ./hdhomerun_recorder.py”

I made a bash shell script that looks like this:

#!/bin/bash
export USER=yourusername
pkill -f “python ./hdhomerun_recorder.py”
cd HDHomeRun_Recorder
./hdhomerun_recorder.py &

I can run this script to restart the Python script (in case I make a change to the schedule) and I can also add it to my startup items to start the script after a reboot (the pkill is ignored in that case).

Note: If you need a way to determine the channels in your area and don’t want to run hdhomerun_setup.py, see hdhomeruntoolbox, but note that the .strm files it produces are not in the correct format for XBMC (in case you are using XBMC, and if you are and you know anything about Java, maybe you want to grab a Java Decompiler and see if you can fix the output). However, after it runs, the information you will need for each channel in HDHomeRun recorder will be in a file named scan_tuner1.txt in the (hidden) .hdhomerun directory. When you look in that file, you will see sections for each working channel that contain information such as this:

SCANNING: 201000000 (us-bcast:11)
LOCK: 8vsb (ss=100 snq=91 seq=100)
TSID: 0x05E7
PROGRAM 3: 35.1 WGVU-11
PROGRAM 4: 35.2 WGVU-11
PROGRAM 5: 35.3 WGVU-11
PROGRAM 6: 35.4 WGVU-11
PROGRAM 9: 0 (control)
PROGRAM 10: 0 (control)

In config-file, the above would translate to something like this:

35.1 = 8vsb:11, 3 ; WGVU-11
35.2 = 8vsb:11, 4 ; WGVU-11
35.3 = 8vsb:11, 5 ; WGVU-11
35.4 = 8vsb:11, 6 ; WGVU-11

Note that stations will not always have the real channel numbers after the callsign, so the real channel number actually comes from the (us-bcast:11) in this case.

Setting up config-file is probably the hardest (not actually hard, but maybe tedious) part, if you can’t get my modifications to the hdhomerun_setup.py script (below) to work, but remember that you only need to add the channels from which you might want to record programming, not every channel available. Remember to restart the Python script if you change the schedule, but of course you DON’T want to do that while it’s recording programming!

I should add that since HDHomeRun recorder is a Python script, it’s probably possible to make it run under operating systems other than Ubuntu, but I just haven’t attempted to do that.

Here are my changes for hdhomerun_setup.py, that should cause it to print out usable lines that replace the existing lines in config-file (you will have to copy and paste them; it does NOT overwrite config-file). Note that there will only be one tuner shown on the tuners line, so you should add your additional tuners if you want to use them For example, if you have a HDHomeRun Dual, and this script prints out tuners = 10ABCDEF:0 you should add the second tuner so that the line is tuners = 10ABCDEF:0, 10ABCDEF:1 (with comma and space separating the two).

#!/usr/bin/env python

def channel_iter(file):
    for line in file:
        if line.startswith("SCANNING: "):
            channel = line.split()[2].strip('()')
            channel = channel.split(':')[1]
        elif line.startswith("LOCK: "):
            modulation = line.split()[1]
        elif line.startswith("PROGRAM "):
            (PROGRAM, subchannel, vchannel, name) = line.split(None, 3)
            subchannel = subchannel.rstrip(':')
            name = name.strip()     # remove new line
            name = name.replace(' ', '-')
            yield (vchannel, modulation, channel, subchannel, name)

def channel_info(hdhomerun_config, device_id, tuner):
    import subprocess
    import tempfile

    f = tempfile.TemporaryFile()
    cmd = [hdhomerun_config, device_id, "scan", "/tuner%d" % tuner]
    p = subprocess.Popen(cmd, stdout=f)
    p.wait()
    f.seek(0)
    return list(channel_iter(f))

def main():
    import sys, os, os.path

    usage = ("usagde: %s path-to-hdhomerun-config device-id tuner-number"
             % sys.argv[0])
    if len(sys.argv) != 4:
        sys.exit(usage)
    hdhomerun_config = sys.argv[1]
    device_id = sys.argv[2]
    tuner = int(sys.argv[3])
    if not os.path.exists(hdhomerun_config):
        sys.exit("%s doesn't exist, aborting!")
    if not os.path.isfile(hdhomerun_config):
        sys.exit("%s is not a regular file, aborting!")
    if not os.access(hdhomerun_config, os.X_OK):
        sys.exit("%s doesn't have execute permission set, aborting!")

    chan_info = channel_info(hdhomerun_config, device_id, tuner)
    if not len(chan_info):
        sys.exit("couldn't find any channels, quitting!")

    print("[global]")
    print("logfile = logfile")
    print("media_dir = media")
    print("schedule_file = schedule-file")
    print("hdhomerun_config = %s" % hdhomerun_config)
    print("tuners = %s:%s" % (device_id, tuner))
    print("[channelmap]")
    print("# virtual-channel = physical-channel program-number name-of-program")
    for (vchannel, modulation, channel, subchannel, name) in chan_info:
        line = "%s = %s:%s, %s t; %s" % (vchannel, modulation, channel, subchannel, name)
        if vchannel != '0':
            print(line)

if __name__ == '__main__':
    main()

Yes, you can run FusionPBX and FreeSWITCH on a Raspberry Pi

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

By now most technically inclined folks have heard of the Raspberry Pi, the small $35 computer that can do big things. If you are going to buy one, just make sure you get one of the newer models with 512 MB of memory, rather than an older model with only 256 MB.

But, you may wonder, can I run a decent PBX system (one that won’t get in my way and treat me like a blithering idiot while I’m attempting to configure it) on a computer this small? Well, it turns out that people are doing just that:

The following guide is a relatively easy way to install FusionPBX and FreeSWITCH with the Ubuntu/Debian script.

Raspberry Pi Script (FusionPBX Wiki)

EDIT April, 2017: For a newer method see this DSLReports thread.

It should be obvious that you’ll probably find this easier if you know a bit about the Raspberry Pi first (Google it) but if you want a reliable and configurable PBX, and you think you have the skills to follow these instructions and make it work, I’d definitely give it a try. Besides, for home users, it’s a lot easier to justify a separate computer just to handle your phone calls if it’s small, cheap, and unobtrusive, and has low power consumption.

Logitech C910 Webcam (Logitech Webcam Software) crashing on Mac OS X 10.7

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This falls into the category of “notes I am posting for myself so I don’t lose them”.  A Logitech C910 Webcam works under Mac OS X (more or less — some users have had more success than others), but the Logitech Webcam Software is buggy and Logitech seems to be in no big hurry to fix it, as can be attested to by the many posts in their Webcams forum complaining about problems using the device with a Mac.  I followed all the instructions in this thread (which was actually for OS X 10.6 but I was grasping at straws) but nothing helped – after I uninstalled and reinstalled the Webcam software, it would run fine ONCE and then after that, every time I’d try to run it again, it would crash immediately after opening.  This was not always the case, but perhaps something was broken during an upgrade.

I figured out that if I go into /Users/username/Library/Preferences/ and remove the files com.logishrd.LWS.plist and com.logishrd.LWS.plist.lockfile it would then not crash on the next run attempt.  So, Logitech’s software is buggy because the mere presence of these files should not cause the software to crash.  Note this is with the lws220.dmg software so if they ever release a newer version it just might fix the problem.

I suppose you could write an AppleScript to delete the two offending files and then launch the Logitech Webcam Software, but I have not got around to that yet (I An Not A Programmer).  My question is, why doesn’t Logitech fix their damn software instead of leaving OS X users hanging, waiting for a solution? People have been complaining about these issues for at least a year and a half now!

How to find the right spot to place a satellite dish

 

Important
This is an edited version of a post (actually two posts combined) that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Really stupid way to install a satellite dish

Quite some time back, I had read an article on The Consumerist site (“DirecTV Contractor: No, We Won’t Fix Our Botched Installation“) and in particular, the comments left by readers of the article, several of which come to the same conclusion that I came to a long time ago: There is no way any installer is going to care about your home the way you do. They don’t have to live in your home for many years, but you do. They don’t have to put up with a crappy looking install, or leaks or water damage to your home, or insects or rodents finding a new route up from your crawl space or basement – you do.

Nowadays you have broadband, cable and satellite installers that just don’t seem to care. In some cases the results can be tragic, in other cases just costly and/or inconvenient. It’s as though some companies just hire anyone, give them minimal training, and don’t even think to instruct them in basic courtesy. If I ran one of these companies, I’d hang signs in employee areas saying things like, “Please respect your customer – treat their home as if you had to live there for the next quarter century” (but then again, that may not work if you have an installer that couldn’t care less about his own home).

One thing that constantly amazes me about satellite installs is that installers put the dish on the roof. In any place that gets snow, that is an absolutely idiotic thing to do. Let me say this again: If the installation company wants to mount a satellite dish on your roof, they are a bunch of idiots (with one exception)! Now why would I say that? Because, unlike terrestrial television signals, you do NOT get any appreciable signal gain by mounting a satellite dish high off the ground. I have seen satellite dishes mounted at ground level that work just fine, at least until they get a pile of snow in front of them. There is only one good reason to mount a dish on a roof, and that’s where you need the additional height to get a clear signal over the top of trees in a neighbor’s yard (in which case you may simply be buying time until the trees get larger), or to clear some other obstruction such as an adjacent tall building. It’s very rare that the additional height actually makes a difference, but it’s not totally unheard of, particularly when a neighbor’s trees are involved.

At the very least, dishes should be mounted under the eaves in a location where snow or ice will not slide down the roof onto them, if such a location is available. For a great many people, perhaps even a majority, the ideal mounting option for a satellite dish is on a metal pole stuck into the ground, a few feet away from the side of the house (or further away if necessary to get a clear signal), where the dish is about five to six feet above ground level. This is high enough that the signal won’t be interrupted by people or animals walking nearby, but low enough that should snow accumulate in the dish, it can be easily brushed off with a broom. Who wants to climb up onto a roof to brush snow off of a dish?

But installers hate putting a dish on a metal pole because they have to make two trips: The first is to dig the hole, insert the metal pole, insert a piece of plastic pipe or tubing so you can run the cable out through the concrete and keep it underground (to avoid damage from lawn mowers, etc.), mix and pour three or four bags of concrete, level the metal pole in the concrete, and then keep the pole perfectly level while the concrete sets. You may note that I keep saying metal pole. You can buy a 10 foot long galvanized steel pipe at most home improvement stores that works great for the purpose. But some homeowners have tried using a treated wood pole – that’s a big mistake, because even though the pole won’t rot, it will warp and twist, and soon your signal disappears. On the second trip (after the concrete dries), the installer then has to install and aim the dish. Obviously it’s a lot faster and easier to just attach the dish to the roof or the eaves, and get it all done in one trip, and what do they care if it causes a leak or rots the wood?

Now you may be thinking that this is a reason to just get cable, but cable installers aren’t much better. They may not drill holes in your roof, but when drilling down through the floor they tend to drill holes four to six inches away from the wall instead of right next to it, and often they have no idea what’s below where they are drilling. It’s not uncommon for them to take out telephone wiring or (more rarely) electrical wiring, or to hit a water or sewer pipe with their drills. And they sure don’t seem to care about appearance sometimes – it’s not as though they make any effort to conceal that big, black wire, even when they could easily do so. As an example, drive around any manufactured housing development (a.k.a. mobile home park) and you will see cable wires running along the side of the home, when there is no reason those wires could not have gone through the floor and underneath the home – except that the installer would have had to pop off a couple pieces of skirting and used some fish tape to do it right.

The moral of this story is, if you value your home and you are the least bit handy, do your own installations. If necessary, have the dish installation company come out and show you the best location for a dish in your yard, and have them leave the dish with you. Buy the pole and the concrete and set the pole yourself (be sure to keep it level!). If you don’t feel you are handy enough to do this, then shadow the installer and if he is about to do anything you don’t like, stop him! You can try to keep it friendly (suggestion: try to get him to tell you stories about the poor installations he’s encountered on his job that have been done by other installers; that may have the effect of encouraging him to do better than they did) but in the end, remember that you will be living in the home and if he causes roof leaks, or leaves holes where the elements can penetrate or insects or rodents can enter, you will be living with the result – and you may not find the damage until the statue of limitations is long past, so you’ll be the one that has to pay for the repairs. If you rent, the landlord may take the damage off of your security deposit (particularly if you never gave prior notification that the install was taking place).

As an aside, I just love the television commercials where the cable companies try to claim that they are more reliable than the satellite companies – the fact is, if the service is installed properly you will have very little trouble with satellite TV (you may lose signal for five or ten minutes during a torrential rain, but even that can be pretty much avoided if you use a slightly larger dish). On the other hand, what cable television subscriber would tell you that their cable service never goes out (or stays out for five to ten minutes at most when it does go out)? Snow accumulation in dishes isn’t as big a problem as you might think, but if you get a really sticky snow it can accumulate on the dish and potentially drop the signal below a usable level, which is a good reason to keep the dish low enough to the ground that a swipe or two with a broom resolves that problem.

Let’s touch on some of the specific problems with the roof-mount method of installation:

  1. Unlike terrestrial television signals, you do NOT get any appreciable signal gain by mounting a satellite dish high off the ground.  A Geosynchronous satellite is 22,236 miles above the earth’s equator.  Do you really think getting it an extra 10 or 15 feet above the ground is going to make any difference, unless you are doing so to avoid a specific obstruction in the path of the signal?  The only valid reason to mount a dish high is if you absolutely need to do it clear a ground-based obstruction, which is rarely the case.
  2. The dish is like a sail against the forces of wind, and also can be moved by ice dams and heavy snow, which means that over time the lag bolts used to screw it into the roof will loosen and allow water to penetrate.  Unless there is treated plywood under there (something almost never used on a roof), the wood will then start to rot, allowing even MORE water to penetrate. That, in turn, will lead to more rot and eventually to roof leaks.  By the time it happens, good luck locating the original installer and trying to hold him responsible.
  3. At least in the picture above, the wire does not appear to be stapled to the roof, but some installers will haul out the staple gun and have at your roof.  That’s even more opportunity for water penetration and eventual leaks.
  4. The wire is going over the eaves at exactly the place you might see ice dams build up in northern climates.  Get a heavy enough chunk of ice frozen around the wire, add a warm day and the forces of gravity, and you may find the wire snapped or detached from the dish.  If you are really lucky the dish and the LNB’s at the end of the arm won’t be damaged, or moved out of position.
  5. In a typical northern winter, there will be days where the dish gets full of snow, and that blocks the signal.  Trust me, you are not going to want to have to get a ladder out every time it snows just so you can sweep off the dish.  You can buy a heated dish to avoid this problem, but then you’re wasting electricity on the days you don’t need it just to avoid a problem on the days you do.
  6. And let’s not forget that you have an ugly wire running down the side of your house, which may or may not be attached in a semi-neat manner, depending on how lazy/incompetent the installer was.
A much better idea: Satellite dish mounted on metal pole in concrete
A much better idea: Satellite dish mounted on metal pole in concrete

Now as I said above, ground installation is often the best, though few installers will offer that option. But here’s the rub with ground installations:  The lower you go, the more likely you are to get interference from nearby ground-based obstructions, such as buildings, other man-made structures, and trees.  If the trees are on your property there is often the chainsaw solution, but most reasonable people have at least a few reservations about cutting down a healthy tree that’s been alive longer than they have just to get a television signal, plus the tree may be on a neighbor’s property, in which case that option probably isn’t open to you, unless you have an exceptionally good relationship with your neighbor.  It’s better to try to find an existing spot in your yard where there will not be any interference with the signal, but that can be pretty difficult EXCEPT during about two weeks out of the year, one in the spring and one in the fall.

When I was searching for information that might help me explain this, I came across this post on the SatelliteGuys.US Forum that explains it better than I could:

Solar outage time is here again-great time to reposition dishes!

That post explains the procedure, and has a link to a program you can run in a DOS emulator to calculate solar outage times in your area (it also has a link to an online calculator, but that has moved here).  I have tried running that program in Boxer under OS X and it seems to work great, despite its age.  I think you could also run it under something like DOSEMU on a Linux-based machine, or as the article suggests, from a DOS prompt on a Windows-based machine (don’t know if newer versions of Windows still allow that but if not, someone’s probably come up with a way to run DOS programs in newer versions of Windows).

The point is that on a certain day at a certain time (the date and time will vary depending on your latitude and longitude) the sun will be right behind the satellite you want to receive.  All you have to do is make sure that your dish will be in a spot that’s in full sunlight at that time — the further from any shadows cast by buildings, trees, etc. the better — and you are golden, at least for that satellite.  If your dish has multiple LNB’s, then you need to find a spot that’s in full sunlight at all times that the sun is behind one of the satellites.  For U.S. dish owners, that means you’ll have to check at three different times during the morning or afternoon, depending on whether you are using the eastern arc or the western arc of your provider, and try to find a spot that’s in full sunlight at all three times.  If no such spot exists in your yard, keep in mind that you do have the option to set up a separate dish and pole for each satellite you want to receive — you don’t have to use the three-in-one combo dish (I will also note that individual dishes are much easier to aim at the satellites, especially for the homeowner that has little or no experience in aiming a dish, but of course some people just don’t want three dishes if they can get by with only one).

If the exact date isn’t convenient for you, you can try a day or two earlier or later.  Remember that in the springtime, if you are earlier, the sun will be lower in the sky than the satellite so you want to beware of shadows near the top of the dish.  Conversely, if you are late on the date, the sun will be higher in the sky than the satellite, so it’s shadows nearer the bottom of the dish that will be closer than they appear.  In the fall, it’s just the reverse – the sun is higher in the sky prior to the exact date, and lower in the sky on the dates following. Sometimes you can’t do it on the exact date because the weather doesn’t cooperate, but usually being a day or two early or late doesn’t affect the result that much.  Where you don’t want to be early or late is with the time.  The sun moves a full degree in the sky in just four minutes (I didn’t believe it either, but check it with a calculator – it’s true!) and that’s quite a huge distance when you are trying to check the position of the shadow of an object that may be several yards/meters away.

Remember that in spring the trees usually don’t have leaves on them yet, so a small shadow from a branch now can mean a full obstruction of the signal to your dish once the leaves appear.  Also, branches get heavier and move in the wind more with leaves on them, so don’t cut it too close – preferably you want your dish in the middle of a nice BIG sunny spot, not a small opening in the trees (unless you only want to watch TV when it’s not windy).  And finally, remember that your dish won’t be on the ground — note the suggestion in the linked article to use a tall stick and a paper plate or pie tin to help make sure the dish itself will be in the sunny area, not just the bottom of the pole.

Sure, you could pay for a professional satellite site survey, but the sun will do it for you for free twice a year, so why not take advantage of it?

EDIT: I’ve found the following article, which includes even more suggestions for finding a spot for a dish that has a clear view of the satellites:
Why certain days in the fall and spring are great times to go out and look at your satellite dishes

Why do Western Digital hard drive power supplies leak so much AC voltage?

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

We recently changed out a case on a computer power supply.  The new case is metal whereas the old one was plastic, and as I was plugging in a USB cable from a USB hub I got a shock.  Not only that, when I accidentally touched it to the bottom of the computer’s case, the computer power supply completely shut down and would not restart until I physically removed the power cord and plugged it back in.  Since this hub had worked just fine with the old case, it led me to wonder what the issue was.  I put a voltmeter on the shell of the USB cable and measured about 50 volts AC to ground!

To make a long story short, I have four external USB drives plugged into that hub and they are all Western Digital. Every single external hard drive had AC voltage on its USB cable shell (when disconnected from the hub), whereas no other devices had more than a volt or two.

That led me to disconnect the power supplies from each of the hard drives, at which point I made a, um, shocking discovery!

I measured the voltage from the power supply DC plugs to ground.  For this test I plugged them into an outlet on a totally different circuit from the one I plug my computers into, since a friend has suggested that the outlets might be miswired (hot and neutral reversed).  I tested for that possibility and that was not the case, but it was still easier to take them out to the kitchen for this test.  I photographed the results for three of them but a fourth gave similar results.  I’m sorry that the pictures are a bit blurry but if I’d used flash it would have washed out the LED display so the exposure times were a bit longer than I would have liked, given that my hand isn’t all that steady.

Western Digita Power Supply #1 - 44 volts leakage

Western Digita Power Supply #2 - 57 volts leakage

Western Digita Power Supply #3 - 44 volts leakage

EDIT: For a few hours after I first posted this, I had image duplicated as . Sorry about that.

A few observations I noted while testing the voltage:

It didn’t matter which way the AC plug was inserted into the socket – the voltage was the same or very nearly the same (within a couple of volts) either way.

It didn’t matter whether I measured to the center or the shell of the DC plug – the voltage was exactly the same either way (this makes me think the leakage might be through a capacitor or capacitors, since otherwise there would be a DC short).

Whatever voltage I measured at the power supply found its way to the USB plug shell once the power supply was connected to the hard drive.

I measured this on FOUR different power supplies, all ones that came with Western Digital hard drives of various sizes. On three I got the 44 volt reading and on one I got 57 volts.

If it were just one or two power supplies doing this, I’d suspect a flaw in that power supply. But since every single one of them is doing it, I have to think it is something inherent in the design of the switching power supplies used with external hard drives. For some reason this never caused any problem with my old computer or case but this new one (new case) can get really strange if you connect or disconnect the USB hub while it is running and the power cable is connected. I just hate the fact that there is this much stray AC but it must be a problem specific to the hard drive power supplies so I don’t think there is anything I can do about it.

I don’t know of any way to correct this problem, or even if it really is a problem. But I REALLY don’t like it!

By the way, I don’t mean to impugn Western Digital specifically, it’s just that right now all four of the external drives connected to this particular computer are WD’s.  I do NOT know whether or not this problem affects power supplies that come with other makes of hard drives (if anyone wants to test yours and post the results in a comment, I’d appreciate it, but please don’t unless you have worked with electricity enough to know how to do the test safely, since I will not be responsible if you fry yourself or your equipment because you didn’t know how to do the test!).

How to isolate a second router from the rest of your local network

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

I was recently asked how to solve a particular problem and I came up with what I think is an interesting solution, especially given my overall rather limited knowledge of networking.  The issue was this: In the home in question, they have cable broadband and a router that feeds jacks throughout the house.  For security reasons, the homeowner never installed any kind of wireless networking (even though his primary router supports it, he keeps it turned off).  Also his primary router is down in the basement.

Recently he got his wife a Motorola XOOM table computer and wouldn’t you know, it requires Wi-Fi access to connect to the Internet.  In order to extend the range, and so that he or his wife could easily turn off the Wi-Fi when the XOOM isn’t in use, he bought a second Wi-Fi router and put it upstairs.  Note that this router is connected BEHIND the original router in the basement.  In other words, the sequence of connection is as follows:

Cable Modem —> Basement (Primary) Router —> Upstairs (Wi-Fi) Router —> Tablet Computer

Now, as I said, he is very security conscious.  So the question he asked me is, if someone managed to break into his Wi-Fi, is there a way to set it up so that they could ONLY get to the Internet, and not to any other system on his local network.  I said I didn’t know, but to first try accessing other machines on his network (the ones that had web interfaces, anyway) from the XOOM.  Turned out that he could do so without any problem.  Because the Wi-Fi router used a different network segment from the original (addresses in the 192.168.2.x range, whereas the original router handed out address in the 192.168.0.x range), as far as anything connected to the Wi-Fi router was concerned, anything on the primary router might as well have been on the Internet (please forgive the non-technical explanation, I’m probably missing several technical details here, but that’s the gist of the problem).

I didn’t think it would be a good idea to try to make the Wi-Fi router use the same address space for both WAN and LAN, and while I could assign it a static IP address on the WAN side, it had to be able to reach the router/gateway at 192.168.0.1.  So here is what we did.

On the PRIMARY router, we took a look at the LAN settings and found that its DHCP server was assigning addresses starting at 192.168.0.2.  We changed that to start at 192.168.0.5 (probably could have used 192.168.0.4 in retrospect).

This way, we could change the WAN address of the Wi-Fi router to use a STATIC IP address of 192.168.0.2, and (this is the important part) a NETMASK of 255.255.255.252.

This means that as far as the Wi-Fi router is concerned, there are only four valid IP addresses in the 192.168.0.x range:

192.168.0.0 (not used)
192.168.0.1 (primary router/gateway)
192.168.0.2 (Wi-Fi router)
192.168.0.3 (Reserved for “broadcast” as far as Wi-Fi router is concerned)

One thing to remember is that after changing the DHCP assignment on the PRIMARY router is that computers already using IP address 192.168.0.2 and 192.168.0.3 will not automatically vacate those addresses until their DHCP lease comes up for renewal.  So if you change the second router’s WAN address to 192.168.0.2, it may not actually be able to connect until the computer or device currently on 192.168.0.2 “loses its lease”.  Rebooting the primary router may help, but in some cases you may have to track down the computer with the conflicting address and shut it off, or if you know how, renew its IP address assignment (this can usually be done from within the network settings panel).  Eventually, though, it should work, and at that point you should find that devices connected to the secondary router cannot connect to any addresses in the 192.168.0.x range outside the three mentioned above, which means they won’t be able to “see” anything else on your network that’s been assigned a DHCP address.

This tip falls into the category of “it worked in this particular situation, but I don’t guarantee it will work for you”.  So if you try this, be sure to test to make sure that the other machines on your primary network are actually unreachable from the secondary router.

Now let the comments begin, telling me how there’s a better way to do this, or why it won’t work, or something to that effect…

ASRock Vision 3D or other Home Theater PC and "Sparklies"

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Just a quick note that may save someone a lot of frustration.  This problem was observed with an ASRock Vision 3D system but could affect other HTPC’s as well.

If you are getting single-color (probably red) “sparklies” (pinpoints of light that don’t belong) in certain scenes, or when viewing certain static images, it may NOT be a software problem.  It seems that on certain systems the HDMI output may be running a little “hot” (not referring to temperature, but rather output levels) and may be overdriving the HDMI input of a connected TV.  To the best of my knowledge, there is absolutely nothing you can do to fix this in software – it’s a hardware problem, perhaps a hardware defect.

But what you can try is attenuating the HDMI signal just a bit.  If you have a HDMI switch (preferably an unamplified one), try making the connection through that instead of directly to the TV.  In at least one case, that solved the problem.  Or, if you have a very long but unamplified HDMI cable handy, you could try that (remember, any additional amplification of the signal will probably only make the problem worse!).

And if you found this article by searching on “ASRock Vision 3D”, I will just say that in my opinion, it’s not worth the price they are currently getting for it.  It’s kind of a hassle to get it working under Ubuntu Linux, and although it costs about two to three times as much as, say, an Acer Asprie Revo, you don’t get two to three times the performance (in my admittedly subjective evaluation), and you might get the HDMI output issue mentioned here.  Whether it works any better under Windows I wouldn’t know – even at the price they charge they don’t supply a copy of Windows, so we opted to use Ubuntu, which worked fine back when we set up the Acer Aspire Revo’s (if we were doing it today, we’d probably choose Linux Mint instead).  In my personal opinion, you might be a lot happier with something else unless you are a real Linux geek and don’t mind tinkering until you can get everything working right, or perhaps if you plan to splurge for a copy of Windows — again, can’t say if that would work any better.

Why your brand new router may cause your VoIP to stop working

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
I quote directly from Voip-Info.org:

Many of today’s commercial routers implement SIP ALG (Application-level gateway), coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers’ ALG implementations are wrong and break SIP.

The article goes on to explain why the implementation is broken, and how to disable it in several brands of routers.  Certain VoIP adapter manufacturers also recommend disabling this feature if you are having problems with SIP registration, not being able to receive a call or one-way audio.  But note that this issue can affect any type of SIP-based communications, regardless of hardware or software used.

EDIT (May, 2018): For information on another issue that may cause problems when you switch routers, see this DSLReports thread: SIP registration times.

Mini-review of Sangoma U100 USBfxo device

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in June, 2010.

I recently had the experience of trying to help someone make a Sangoma USBfxo device (model U100) work on a server that runs FreePBX and Asterisk. The advertised features of this device are as follows:

  • Dual FXO ports
  • Easy installation, no need to open up computer to install PCI/PCIe card
  • Supports up to 2 simultaneous calls
  • Compact plastic enclosure
  • Low power consumption, takes power from USB bus
  • USB 2.0 compliant (compatible with USB 1.1)

The first thing I would note is that although you don’t have to open up the computer, it’s definitely not “plug and play.” At the very least you have to install driver software, and on an Asterisk server you will also need to install and configure DADHI or ZAPTEL (unless this has already been done). Depending on your level of expertise, this might be easy, or quite daunting. I would certainly take issue with the claim of “easy installation” although I can understand how a true Linux geek might consider it a walk in the park. It wasn’t so much that there were any major hitches in the installation as that it was time consuming and required quite a bit of mental effort to figure out what needed to be done — someone who has just set up a PBX using a “load and go” distribution like Elastix, PBX in a Flash, AsteriskNOW, Trixbox, etc. might not find it all that easy to get this thing working.

The major issue we had was with the performance. We initially discovered that it was “clipping” speech severely, causing audio artifacts that are difficult to describe in print, but unpleasant to hear. We got in touch with Sangoma customer support and finally traced the problem to the built in hardware echo cancellation. By disabling the hardware echo cancellation, the speech was clear, but of course we then had mild echo. Enabling echo cancellation in Zaptel fixed that on a temporary basis, but about a week later Sangoma customer support e-mailed us and suggested that we try OSLEC, the open source echo canceler. We might have actually done that had we not discovered another issue in the meantime, that made us decide we didn’t want to mess with this unit anymore.

This new issue was that initially, it did not pick up incoming caller ID on incoming calls. We discovered that this could be fixed by changing the gain settings in Zaptel, but even when we did that it still wasn’t 100% reliable (I’d say it worked about 90% of the time). And, the downside of that was that we had to reduce the incoming gain, so that it was harder to hear callers.

We’ve used Sipura SPA-3000’s before for this same function, although they are only single line units (they have one FXS port and one FXO port) and have never had any of these issues. The main reason we tried the USBfxo was because we wanted two FXO ports, and also liked the idea that it was powered off the USB cable, and didn’t require us to have yet another device with a “wall wart” to plug in. But the difficulties with Caller ID, volume levels, and the fact that Sangoma had apparently given up on getting the hardware echo cancellation to work without distorting the audio led us to get frustrated with this device fairly quickly. The non-techies that had to make and receive calls that went through this device were not very understanding of the issues, especially since the SPA-3000’s (now superseded by the Linksys SPA-3102, which is essentially an updated version of the Sipura SPA-3000) had always worked much more reliably. We finally gave in and found another Sipura SPA-3000 on eBay and put it into service, and within a relatively short time (part of which was spent locating and installing updated firmware) it was working like a champ. Unlike the Sangoma, it detects the Caller ID 100% of the time, and we can tweak the transmit and receive gain to comfortable levels.

My personal opinion is that Sangoma should be ashamed to put their name on the USBfxo.  The hardware echo cancellation, in a word, sucks.  And one of the big reasons you’d buy a brand like Sangoma in the first place is because of the supposedly superior echo cancellation.  Echo cancellation is supposed to cancel echo, not make it sound like your words are clipped.  My guess is that the hardware echo cancellation is far too aggressive and they don’t give you any way to “tune” it — you can either enable or disable it, but that’s all.  The USBfxo is a great idea, but it needs to go back to the drawing board. Sangoma’s motto (shown on their Wiki pages, etc.) is “Because it must work!”, but apparently that motto does not imply that it must work well!

Also, a note to Sangoma customer service — next time a customer is dropping hints that they’d like you to take your defective unit back and send a replacement, you might want to be a bit more responsive to that request. We were willing to work with you up to a point but the message came through loud and clear that you really didn’t want to replace this dog of a device unless you absolutely had to.  We didn’t sign up to be beta testers, we just wanted the damn thing to work. Given Sangoma’s (perhaps undeserved) reputation we really thought you’d be more agreeable to making sure that we got a unit that worked, not making us try a bunch of different things and then ultimately told to try OSLEC, effectively giving up hope that the hardware echo cancellation would ever work properly.

Another suggestion to Sangoma (or any other manufacturer that may be listening) — most of us who did not cut our teeth on Linux would probably prefer not to have to mess with ZAPTEL or DADHI.  The nice thing about the Linksys/Sipura devices is that they sit out on the network and appear as just another SIP-based device, and in FreePBX you configure them pretty much as you would any other SIP trunk.  I’m not saying that installing any of these devices is the proverbial “piece of cake”, especially if you have never done it before, but when you have to start installing and configuring drivers, that goes outside of the realm of what I would consider easy to install. What someone really needs to come out with is an inexpensive four to six-port SIP based FXO device that sits out on your local network, like the SPA-3000/3102.

If you are in need of one or two FXO ports for your Asterisk server, my advice would be to first try one or two Sipura SPA-3000 or Linksys SPA-3102 devices (following these instructions if you are a FreePBX user) — if those do not work the way you’d like, you can always resell them on eBay and then try a more expensive solution.  If your server doesn’t have card slots (as is increasingly the case, as users turn to small computers like the Acer Aspire Revo to use as small, power-efficient PBX’s) then your choices are limited to external devices such as the aformentioned units. However, if your system can accept internal cards, then you can buy cards that provide FXO ports from several manufacturers, including Digium and Sangoma (if you need eight or more FXO ports than I believe there are other external options, but they are quite a bit more pricey and I have not really investigated them, so I won’t comment on them at this point.  However, if any manufacturer would care to send a review sample, I’d be more than happy to give it a try!). 😉

The one caveat I will add is that not every device will work on every line.  If you have a very long line from a traditional telephone company, your requirements (and experience with a particular device) may be quite different from someone who is sitting 500 feet from the central office, or someone who’s trying to take the output of a cable company’s VoIP adapter and pipe it over to the FXO card or device using twenty feet of copper wire. Just because the Sipura devices have worked better for us does not mean they will for you. I’m guessing that some people have purchased the exact same Sangoma device that we tried and were able to get it working well enough for their needs, but I just cannot recommend this device — at least not until Sangoma fixes the echo cancellation, and makes it read the incoming Caller ID reliably 100% of the time, preferably without having to change the incoming gain in DADHI or ZAPTEL.

EDIT: For more comments/opinions on this device (and on this review), see this thread on the PBX in a Flash forum.

Recent Posts

Recent Comments

Archives

Categories

Meta

GiottoPress by Enrique Chavez