Beaming service? I don't think so, Tim.

Today, my S5 Note informed me that I needed to update the "Beaming Service for Samsung". At first glance, this looked like bloatware, so I read the description which touted the benefits of "beaming" barcodes. To be honest, I didn't get it, since I've used the Key Ring app beginning with my first Android, the S2 Fascinate. For that matter, why did my phone have multiple beaming services?

The reviews were immensely unhelpful. How can you give a 5-star review to an app, saying it "works perfectly" when you can't open it and see what it does?

More research was required. Fortunately, the Google is strong with this one, and I quickly found a TechCrunch article in which was buried this nugget "barcodes can later be reproduced in the form of infrared flashes". Now we're on to something, because the app description on the Google Play store says "The Beaming Service enables your device to beam (relay) barcodes ... to 1D red laser and image based scanners..." (excess marketing cruft elided) OK, now this is useful. Most 1D scanners cannot read barcodes from phone images, so if your retailer hasn't upgraded to a 2D scanner (which can also read QR codes), the barcodes still have to be entered by hand.


All in all, this appears to be a useful little technology. It's just unfortunate that the vendor can't seem to communicate this succinctly. It's also unfortunate that they chose to call it "beaming" when the same term is used to refer to NFC communication between phones. Confusing, no?

Great! But so many of the reviews mentioned the permissions in their objections. Since this app was pre-installed on my phone, I never had a chance to review them. Let's take a look:

• Contacts: find accounts on the device
• Location: approximate & GPS
• Phone: status & identity
• Other: full network access, run at startup, prevent sleeping, receive Internet data

(For the record, this is from version 1.3.7, released 2016-05-31.)

At this point, I would love to use some choice expletives. Why does an app that relays a barcode via infrared flashes need my account information? Why does it need to know a location? Why does it need network access? If this is simply a driver to expose the barcode flashing technology to other apps, none of these permissions should be required.

Let's take a walk down memory lane to the year 2000 when a little barcode scanner called the CueCat made its appearance. Available for free at Radio Shack, this little device allowed you to scan barcodes in magazine and on commercial products. Those of us with large libraries of music, videos, or books thought it would be useful in finally cataloging our collections. However, suspicions were raised when it was discovered that every barcode scanned could be aggregated by Digital Convergence and connected to identifiable demographic data requested when registering the scanner.

Now I don't have proof that Mobeam is doing the same thing. But the permissions required are suspicious: especially when you consider that this "driver" could collect and report every barcode relayed by any app that uses it.

Perhaps if Mobeam were to limit the requested permissions on this service, I might be tempted to use it. Then again, I hardly use Key Ring anymore: most of the retailers who still have 1D scanners look up my account via phone number because it's easier. For now, this app goes on my disabled list.

Small victories: Configuring the Touchpad Key on an Asus Eee PC 1005HAB

Once upon a time, the realm of Microsoft decreed that Windows XP should be consigned to the dustbins of history. And so it was that my in-laws bequeathed to me an Asus Eee PC 1005HAB. This is the tale of a small victory in rehabilitating this netbook.

I had great success installing Arch Linux and getting a basic LXDE setup in place. However, there was a major irritation: the Synaptics touchpad. I'm an old-school touch typist with large hands and I found myself constantly fighting with the cursor as it leapt around every time I accidentally bumped the touchpad. I installed the acpi-eeepc-generic package from the AUR, but found that many of the settings simply weren't working. It also seemed to me that some of the scripts were overkill, requiring root privileges when they weren't strictly necessary.

Using xev, I made a list of keycodes for all the Fn key combinations. I then began adding keybindings to ~/.config/openbox/lxde-rc.xml. All of them worked EXCEPT the Touchpad Key (and the equivalent Fn F3 combination).

Here's the xev output for the Touchpad Key/Fn F3 keys:
KeyPress event, serial 45, synthetic NO, window 0x2400001,
    root 0x7e, subw 0x0, time 26427246, (106,43), root:(108,437),
    state 0x0, keycode 191 (keysym 0x1008ff81, XF86Tools), same_screen YES,
    XKeysymToKeycode returns keycode: 179
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False
Small victory #1: I realized that I needed to bind to 191 (the original keycode) not XF86Tools.

While I was now able to invoke /etc/acpi/eeepc/acpi-eeepc-generic-toggle-touchpad.sh from the keys, it was slow and required invoking gksudo.

Small victory #2: I discovered that synclient did not require root privileges. I could have the functionality--as long as I didn't care about the aesthetics of turning the LED on and off.

Small victory #3: I realized I could write a small script to toggle the LED which could then safely be invoked via sudo without a password.

So here are the pieces of my solution:

TouchpadKeyLED.sh
#!/bin/bash

# TouchpadKeyLED.sh - Control the state of the Touchpad key LED

# NOTE: This command requires ROOT privileges, however, it is relatively
#   safe because we are only setting a single value in the /sys filesystem

LED_KEY=/sys/devices/platform/eeepc/leds/eeepc\:\:touchpad/brightness

case $1 in
    on | 0 )    STATE=0                     ;;
    off | 1 )   STATE=1                     ;;
    * )         STATE=$((1-$(<$LED_KEY)))   ;;
esac

echo $STATE >$LED_KEY

I'm pretty pleased with the flexibility here. We can pass as an argument either the actual values stored in "brightness" or simply "on" and "off". For any other argument, we toggle the current value by subtracting it from 1.

TouchpadToggle.sh
#!/bin/bash

# TouchpadToggle.sh

# 140428-BaP: Simplified version of acpi-eeepc-generic-toggle-touchpad.sh
#   that doesn't require sudo password prompting
# Based on https://wiki.archlinux.org/index.php/Touchpad_Synaptics

# TouchpadOff values: 0=on, 1=off, 2=only tapping/scrolling are off

# Allow explicit setting of all 3 states, as well as toggling between 0 & 1
#   (By counting "=.*0", we'll return 1 if it's on, otherwise 0)
case $1 in
    on | 0 )    TOGGLE=0    ;;
    off | 1 )   TOGGLE=1    ;;
    2 )         TOGGLE=2    ;;
    * )         TOGGLE=$(synclient -l | grep -c 'TouchpadOff.*=.*0')    ;;
esac

# Because I will almost always have the touchpad off, I want to light the LED
#   whenever the touchpad is active. (The acpi-eeepc-generic-toggle-touchpad.sh
#   script turned the LED on when the touchpad was off, which makes sense for
#   power savings when the touchpad is normally on...)
case $TOGGLE in
    0 ) STATE=0 ;;
    1 ) STATE=1 ;;
    2 ) STATE=0 ;;
esac

synclient TouchpadOff=$TOGGLE
sudo /usr/local/bin/TouchpadKeyLED.sh $STATE

Although I won't use it often, I'm pleased that my solution allows for setting all 3 possible values for "TouchpadOff". The original code only toggled between 0 and 1.

Of course, a more robust solution might cycle through 0, 1, and 2--but I think it's sufficient that I can set 2 if desired.

The next step was to add the following to my /etc/sudoers:

# 140428: Allow anyone to toggle the Touchpad key LED without a password
ALL ALL=(ALL) NOPASSWD: /usr/local/bin/TouchpadKeyLED.sh

For completeness, here's the keybinding from ~/.config/openbox/lxde-rc.xml
    <!-- LH Silver Key & Fn F3 -->
    <keybind key="0xBF">
      <action name="Execute">
        <command>/usr/local/bin/TouchpadToggle.sh</command>
      </action>
    </keybind>

The final piece of my solution was to ensure the touchpad is turned off by default for me:

~/.config/autostart/TouchpadDisable.desktop
[Desktop Entry]
Type=Application
Name=Touchpad Disable
Comment=Disables the Synaptics Touchpad
Exec=/usr/local/bin/TouchpadToggle.sh off
StartupNotify=false
Terminal=false
Hidden=false

Final small victory: I log in, the touchpad is disabled, the keybindings work, and the LED lights.

For now, I plan to keep the acpi-eepc-generic package installed. I want to make sure I've taken a look at all the scripts to see if there are better ways to enable all the functions of this netbook.

One final note: I did a quick proofread--I think I managed to undo any code mangling that occurred while pasting into this blog entry. Use at your own risk.

LVT&R Progress report: Father's Day 2011

In order to maximize my layout space, I've decided to work with hidden tracks. By putting downtown Allentown on a separate level, I can run trolleys through town, over the 8th Street Bridge and continue south. I can hide 3 staging tracks for CNJ, LNE, and Reading trains underneath Allentown, while having the double main line for the LVT&R on the main level, pass under the 8th Street Bridge and reappear on the other side of Alfundo Park. There are a few challenges with this plan:

• Hidden tracks can be a maintenance headache
• If I'm going to loop the trolley, I'll have to do as narrow a radius as possible.
• Keeping the curves smooth as I do the end loop around Alfundo Park

Meanwhile, I've forged ahead with laying roadbed and track. I'm using thinned white glue to adhere both the roadbed and the track. It's strong enough to hold until the ballast is put into place yet easy to remove and realign. (I was going to do this the old fashioned way with nails/spikes, but I've become a big fan of adhesive!)

I've added an industrial spur for the Coplay/Cementon area which will double as my programming track. Rather than spend $25 on a circuit board to control the programming track, I'm using a simple toggle switch. By routing power from the Power Cab Panel to the programming track first, the programming track is always on. The DPDT toggle allows me to cut power to the rest of the layout.

However, yesterday, I failed my saving throw versus Klutz three times.

1. Although I checked the fit of the turnout to the programming track multiple times, when I soldered the lead track, the angle was wrong. I had to cut the track off and add a segment of flex track to avoid wasting the turnout.
2. While waiting for some roadbed and track to dry, I was working on coupler conversions. While removing an old housing, my knife slipped and I cut the truck instead, resulting in a trip to the hobby shop for replacement trucks.
3. After installing my programming toggle on my simple panel, I discovered I had it placed in reverse (as far as the labels on the panel were concerned). (On a slide switch, the connected poles are the ones on the same side as the slide. On a toggle switch I bought, the connected poles are on the opposite side of the direction of the toggle.) So I removed the switch, turned it around and reattached it to the panel--only to tighten so hard that I broke the switch.

So tonight, I spent a bit of time fixing yesterday's klutz failures. Most of the track now laid is attached to the bus and I've tested the controls again. Tomorrow, I'll clear up some of the work area and fit the return curves into place. Hopefully next month I'll be able to either extend to the north or start adding Allentown.

Phase 1 photos are up...

https://picasaweb.google.com/ld.barthel/LVTRPlanningAndProgress

LVT&R: First trip between Allentown & Lehigh Water Gap

Yesterday afternoon, Lehigh Valley EMD F7A #572 made the first trips between Allentown and the Lehigh Water Gap on a test track.

It turned out to take far longer than I expected to get to this point. All my previous layouts had been basic DC wiring, but for this version of the LVT&R, Christine got me an NCE Power Cab. (I had been thinking about DCC this time around, but I was going to postpone the transition for financial reasons. I think she caught me drooling over the InterMountain DCC F7A at the train show. Well, OK, I *did* point it out to her.  But I really started drooling when the the woman put it on the the test track and I heard the built-in sound.) I had done some research on DCC systems and had already read some positive reviews of the NCE Power Cab. But the fact that I could get an expandable entry-level DCC system for only $100 more than a good DC power pack put to rest any thoughts of wiring a new layout for DC first.

Anyway, I had read lots of advice on DCC wiring on the net, including the page at Gateway NMRA. Based on those recommendations, I had purchased 12 AWG wire for the DCC bus. As it turns out, that was too large for the connection to the NCE Power Cab. Plus, somehow I had picked up one spool of stranded and one spool of solid 22 AWG for the feeders. So back out to the stores I went again. At Home Depot I was able to get 16 AWG wire as well as 20 AWG bell wire. I flirted with the idea of using splice taps, but at over $0.70 each, that was going to be too expensive. Instead, I picked up a box of wire nuts to minimize soldering under the layout.

Because I couldn't find clear markings for which bus wire connection was to be red, I decided to do a quick test first. I made a pair of jumpers with a spade connector (which I soldered & crimped) and soldered a pair of feeder wires to a section of flex track. I made the connection to the NCE panel and the terminal block, plugged in the AC adapter and nothing. Sigh. After a bit of checking the continuity with a VOM, I discovered that I had made the black wire wasn't firmly connected at the NCE panel. So I stripped a little bit more off the ends and made sure I had a firm connection at the NCE panel. Not only did my EMD F7A come to life, but I was able to run it the entire length of my test track: over 10 feet of flex and sectional track with only 1 pair of feeders.

By the time Chris came home, I had relocated the feeder wires to beneath the layout, mounted the terminal blocks, reconnected the main bus jumpers and added the first bus section to connect to the feeders via wire nuts. She came downstairs just as #572 was making its first trips between Allentown and the Lehigh Water Gap.

I need to eliminate some bumps where the plywood sections butt against each other before I can begin laying the final sets of track in this section of the layout. Unfortunately, that will have to wait for us to finish relocating some of Chris's things that she doesn't want covered in sawdust.

In the meantime, I can start working on rolling stock. There are a few boxcars to assemble and some Kadee couplers to install. We'll probably make some paper buildings to get a better feel for scenicking. (Allentown is the biggest city in the area I modeling with the LVT&R--it would be a shame for it to not have any buildings because I located the track poorly...

Groundbreaking on the LVT&R!

Yesterday and today I spent some time on the initial "benchwork" for the LVT&R.

Since half of the railroad area is along walls, I'm opting to do shelf benchwork for that portion. Using Rubbermaid's twin track shelving brackets will give me more than enough support, plus it will make adding additional levels or lighting a breeze.

The tracks are now installed for the Allentown-Lehigh Water Gap section of the pike. It turns out that opting for extra support was a good idea: either the studs supporting the drywall in the basement aren't plumb or they don't extend all the way. About 5 of the upper or lower screws are using plastic wall anchors instead of screwing directly into the studs.

Also, in one case, the stud runs too close to the electrical outlet--the outlet cover was directly beneath the track. Since Rubbermaid doesn't make a 60" section of track, I cut one of the 72" sections to fit. (I could have used a 48" section, but that would have interfered with additional shelving (or a fiddle yard below.

I've been taking picture of the work in progress so I have documentation for the NMRA Achievement Program. I'm going to check measurements against my plans and cut the plywood shelving next. Once that's done, I'll get the pictures uploaded to Picasa.

In the future, I may replace this with cookie cutter roadbed to more realistically model the grades of the Lehigh Valley, but for now, simple flat top benchwork will get things moving--namely trains!

The next phase of the benchwork will be to mount twin track on the walls of the Lehigh Water Gap - Mauch Chunk segment of the pike. This will include a lift-out section across the Water Gap (which is literal in this case, since it's the location of the water main for our house.

Time to go back to work!

The National Jukebox

Work on the layout has been delayed while I deal with computer issues. Sigh.

But here's something you'll *really* like. (10 points if you know the source of that line!) I just found out about the Library of Congress' National Jukebox http://www.loc.gov/jukebox/. They have obtained the rights to stream historical recordings from their collection of Victor discs. Best of all, you can create playlists from this collection and share them.

My father was a big fan of John Philip Sousa's marches. You might think that would be enough, but there's far more to my "Sousa heritage". For many years, the Allentown Band was directed by Alburtis Meyers, who had played cornet in Sousa's band. My father insisted that because of that connection, the Allentown Band played Sousa as Sousa intended. Given the musical influence of Meyers in the greater Lehigh Valley (both my dad and my high school musical director studied under Meyers), you could say that Sousa is my musical great-grandfather.

So naturally, when I found that the Library of Congress' collection included recording by Sousa's band, my first playlist simply had to be "Sousa's Band plays Sousa". (Although one of the first tracks I played was a version of Tom Turpin's St. Louis Rag....) I wanted to include the classics (Washington Post, Liberty Bell aka Monty Python, Thunderer and Stars and Stripes Forever) as well as some lesser known works. The first 2 tracks are conducted by Sousa.

This is a wonderful resource that illustrates the true power of the Internet to enrich all our lives.

Although some of these recordings are over a century old, the constant extensions to the copyright period (which only benefit corporations) mean that these treasures are not yet in the public domain. And that makes me a sad panda.