Beautiful weather has finally arrived in the Pacific Northwest and I’ve been taking advantage of it as often as I have time. One thing about living where it’s grey and rainy for so much of the year, it really almost forces me to go outside and be active when it’s nice out. I’ve been riding my bike around, and wanted an easy way to keep track of my stats like speed, distance, which trails I was riding and altitude. Turns out there’s a free and easy way that integrates well with Android: Google My Tracks
My Tracks uses your phone’s GPS to record your position and plots it on a map, where you can upload it to Google Maps or export your track as an industry-standard KML file for analysis in another application.
You get a print out of your statistics at the end, and can optionally insert markers with interval statistics on a custom schedule. The app has been around for a few years but has become much easier to use lately. My last ride was 12.9 miles long at an average moving speed of 7.5 miles per hour:
Total distance: 20.78 km (12.9 mi)
Total time: 2:56:35
Moving time: 1:43:56
Average speed: 7.06 km/h (4.4 mi/h)
Average moving speed: 11.99 km/h (7.5 mi/h)
Max speed: 34.62 km/h (21.5 mi/h)
Average pace: 8.50 min/km (13.7 min/mi)
Average moving pace: 5.00 min/km (8.1 min/mi)
Min pace: 1.73 min/km (2.8 min/mi)
Max elevation: 179 m (589 ft)
Min elevation: 93 m (304 ft)
Elevation gain: 984 m (3228 ft)
Max grade: 12 %
Min grade: -17 %
Recorded: 5/26/2012 12:21 PM
The application also integrates with a Polar brand heart rate monitor over Bluetooth to record heart rate statistics along with the other information. I don’t have that option yet, but plan to add it fairly soon. This is a great free app that everyone should know about. It’s not just useful for mapping a trail, either – you could use it to mark where you left your car, see where you’ve been in an amusement park, or record the location of interesting landmarks you see while wandering around the city. Check it out!
I tend to stay away from political commentary on my blog, but this is too important not to talk about. The PROTECT IP act currently the subject of hearings in Washington, D.C. is set up for a fast-track to pass. Testimony from the technology industry is being prohibited in the committee, so technologists and infrastructure companies aren’t being allowed to have any say in the bill that will effectively set up the “Great Firewall of America” and allow Hollywood to become the ultimate arbiters of what content isn’t allowed to be posted online, backed up by the Department of Homeland Security. Unless the possibility of spending five years in Federal prison because you posted a video of yourself singing a cover of a pop song to YouTube is something you enjoy, it’s time to take action.
Send this form letter, or write your Congressman a personal message. Don’t let the Government, in partnership with the entertainment industry, execute a power grab possibly exceeded only by the PATRIOT act.
Yesterday, Google officially rolled out the “much anticipated” (by them, perhaps) revisions to Google Reader which removed most of its compelling functionality and added integration with their social network Google+.
We hope you’ll like the new Reader (and Google+) as much as we do, but we understand that some of you may not. Retiring Reader’s sharing features wasn’t a decision that we made lightly, but in the end, it helps us focus on fewer areas, and build an even better experience across all of Google.
I’ll start off with the glaringly obvious usability features. The first one, of course, was best expressed by an anonymous Internet comment that it “looks like a browser with the stylesheets turned off”. It’s mostly white, with a handful of navigation buttons around the top, and an excessive amount of whitespace. The navigation buttons have been rearranged and are in a row along the top, where the previous and next item buttons were previously at the bottom, and the new code doesn’t prefetch as well or scroll as smoothly. Result? It takes a lot longer to get through items. This is a big problem if you use Reader like I do. I skim the contents of about 250 feeds every day, for between 1000 and 2000 news items, but only spend time reading the most interesting ones. It’s taking me between 2-4x as long to get through my unread items as it did previously.
The worst issue, though, is that it’s removed the social functionality from Reader and forces you to use Google+ for your news item discussion. The discussion about this fact seems to center about the fact that it’s not obvious about how to share your new items, to the point where former Google Reader product manager Brian Shih trashes the new revision:
“It’s as if whoever made the update did so without ever actually using the product to, you know, read something. Reader is a product built to consume information, quickly. We designed it to be very good at that one thing. G+ is an experience built around browsing (similar to Facebook) and socializing. Taking the UI paradigm for G+ and mashing it onto Reader without any apparent regard for the underlying function is awful and it shows,” says Brian.
Google, of course, attempts to counter this argument but completely misses the mark. They released a nice blog post showing how to share an item more easily, because it’s a bit non-obvious.
The fundamental flaw, though, isn’t that it’s more challenging to share an article. The real flaw is that it’s now 100% more difficult to actually have a social discussion about the articles you’ve shared.
“Old” Google Reader had a convenient view of showing who was in your sharing circle and highlighting comments they’d made, seen in this WebProNews screenshot:
“New” Reader completely lacks any commenting functionality built in. This means you need to visit 2 different web sites to have a discussion. One web site to read and share the content, and another web site to talk about it with your friends. That’s a 100% increase in the number of steps needed to have a discussion. Trying to make reading the news more social by making it more difficult to have a conversation about the items, is extremely counter-intuitive at best. Mostly, though, it just reinforces what Brian Shih said above: that they don’t know what they’re doing.
Reader Comment threads were something I looked forward to every day. They’ve been effectively eliminated from my life at this point. Many of the people following my Reader feed specifically preferred not to sign up for Google+, and even the ones who are “users” of Google+ use it in the sense they log in once a week to see how little content there is and feel better about not using it.
I’m not surprised they’ve taken this approach to drive new traffic to Google+ – it’s been in a pretty sharp decline since it was released. They just waited too long between announcing it, and opening it to the public, combined with the fact that it makes a lot of people nervous to have one company with complete access to e-mail, web search behavior, photos and social networking all in one place. Facebook is enough of a privacy nightmare, being specifically designed to break European data protection laws (things we don’t have in the United States) but at least they can’t read my e-mail, too.
I really think this is the end of my time on Reader. Many of the people I previously talked to, just won’t be signing up for Google+ to continue using it. I have no reason to use Reader in Google+ if I don’t have anyone to talk to, and my Reader shares have always been restricted to a very close-knit, hand selected group of people. Now I’m looking for an open-source replacement we can migrate to on an open server. If anyone knows of one, let me know.
Goodbye, Google Reader. We’ll all miss you. And I don’t think Google is going to learn anything from this experience, either.
September was a good month for projects. I accomplished all the things I set out to do and more:
- I’ve finished the Hornyphon radio for my customer
- Repaired and began using the Hallicrafters
- Got the broken ViewSonic monitor going again
- and put lighting effects on my coffee table out of spare parts.
In addition to writing once in a while, I read a lot of blogs. They’re about a quarter political, a good bunch of news, about a quarter are photo feeds, and the rest are life interest and hobbies.
One of the more interesting ones is “Art of Manliness” which runs all manner of short and frequently humorous how-tos on topics like shaving with a straight razor, catching a horse, fixing things on your car, you get the picture. They recently put up a great article about re-purposing a broken antique radio into an external speaker for an MP3 player.
When I encounter a broken antique radio, my first instinct is to fix it up and add an input for the iPod but sometimes they’re just too far gone to save or aren’t valuable enough to spend a dozen or more hours repairing. In that case, tapping into the radio’s volume control and re-using its existing speaker is a good alternative and is usually a reversible modification. A lot of purists might complain about ruining an antique to make this repair, but it’s a reversible modification and let’s face it – fixing the radio up well enough to receive a signal and then using an AM transmitter isn’t going to sound nearly as good most of the time, anyway.
Around WW2, they changed how antique radio speakers work. Before then, speakers were electrodynamic using a field coil instead of a magnet. Since they have no magnetic field if they’re not fully powered by a very high voltage, they won’t play sound – you need a permanent magnet speaker. I mentioned this to the author and he updated the copy of the page to reflect this important information that might have resulted in a lot of disappointment for someone who used the wrong type without knowing:
Important Note: Commenter J.W. Koebel brought to our attention that if you want to use the radio’s original speaker like we do in this project , the speaker needs to be a permanent magnet speaker. Radios from about the mid-1940s and on should have permanent magnet speakers. Earlier radios used electrodynamic speakers. Our amp won’t work with electrodynamic speakers.
How do you know if your old-time radio has permanent magnet speakers? Check the back of the speaker. If it has 2 or 3 wires going to the speaker, it’s a permanent magnet speaker.
Better-known gadget blog Lifehacker picked up the story, and devoted about 1/4 of their summary article’s copy to that same warning.
Two caveats: Make sure your vintage radio is not terribly valuable before you take it apart and also make sure the speaker in the old radio is a permanent magnetic speaker and not an earlier electrodynamic speaker that won’t work with the new amp. If 2 or 3 wires are connected to the speaker, it’s a permanent magnetic speaker.
That’s pretty cool. I didn’t think much of it at the time, but I’m glad some of my advice will help fellow hobbyists have a successful project. (Also, this is my blog’s 100th post!)
Long distances apart can make it tough to keep up friendships, and while the Internet has helped with this through the advent of e-mail, instant messaging and video conferencing like Skype none of these mediums can accurately duplicate the experience of being able to quickly ask and see “What’s going on?” to a friend or colleague across great distance.
E-mail is a bit too asynchronous. Instant messaging suffers the same problem, along with the lack of visual feedback and a frequently too small text window. Skype calls go the other direction, they’re slightly too synchronous: it’s not possible to automate them, and they use more bandwidth than something more laid back really needs to be successful. What’s missing is a passive solution to let people passively – and pervasively – interact with others with video feedback.
Enter the “Digital Window”. Originally conceived a year or two ago, the idea is simple: a panel mounted in a visible location connected to a camera which shows a passive viewing portal into another space via a similar device located elsewhere. Glance out the window into a previously authenticated friend or colleague’s space and see what they’re up to, and start a conversation if it’s interesting. Time not spent in front of the computer is often when some of the most interesting projects take place and if nobody knows they’re happening, it’s impossible to collaborate and seek feedback.
The idea became reality with some minor revisions when a software developer friend recently got married – what better gift than writing a video conferencing appliance on dedicated hardware using nothing but off-the-shelf components? I collaborated with another member of our group across the country to make the system a reality, and we bootstrapped it from the ground up using it to help continue its own development once some basics were in place.
The wedding gift, our implementation of the digital window, consists of the client-side appliances: two Asus netbooks running Windows XP, configured to automatically begin broadcasting via their internal webcams using Windows Media Encoder 9, and load the Viewer application in a web browser. The viewer application itself is a web page hosted on the streaming server itself, a simple automatically-refreshing container loading a set of borderless Windows Media Player controls to display the streams. The viewer code is self-refreshing and requires no maintenance.
Windows Media Encoder 9 was somewhat difficult to find as it’s no longer officially supported, but it’s still available from Softpedia. Its replacement is the Windows Expressions Encoder, a commercial product with a free version, but it’s a heavier package and the Asus netbooks don’t need to waste cycles running a bigger application than necessary.
When the system first launches, it automatically launches a Visual Basic script via a shortcut in the Startup folder. Through some trial and error, we learned we needed to set the shortcut to launch the script minimized to avoid popping up a command prompt window over the output. The script then sets up an Internet Explorer window, the Viewer application, and launches Windows Media Encoder. The script can be found below, with some identifying information removed for security reasons – you’ll need to fill in your own URLs to use this code if you’re going to clone our setup yourself.
On Error Resume next Set WshShell = WScript.CreateObject("WScript.Shell") Set objIE = CreateObject("InternetExplorer.Application") Set sHTMLTitle = "Viewer Application" Return = WshShell.Run("Custom.wme") 'Set this to the location of the .WME profile you created in Windows Media Encoder WSCript.Sleep(60000) 'Sleep to let the encoder load - it does a lot of stuff on start-up. objIE.StatusBar = 1 objIE.Toolbar = 1 objIE.Width = 1024 objIE.Height = 600 objIE.Left = 0 objIE.Top = 0 objIE.Visible = 1 objIE.Navigate "Viewer Application URL" ' Wait for IE to finish loading before continuing. Do While objIE.Busy: Loop Do While objIE.ReadyState <> 4: Loop WScript.Sleep(5000) Set EncoderAgent = CreateObject("WMEncAgt.WMEncoderAgent", "127.0.0.1") ' Grab the running encoder via the WMEncoderAgent. Set Encoder = EncoderAgent.GetEncoder(EncoderAgent.EncoderNamesCollection.Item(0)) Encoder.Start ' Begin Streaming WshShell.AppActivate("Viewer Application") 'Activate different possible titles of the window. WshShell.AppActivate("Internet Explorer") 'Depends on the local system's configuration what IE is titled...covers possibilities. WshShell.AppActivate("Windows Internet Explorer") While 1=1 'Watchdog Select Case Encoder.RunState Case 5 '"STOPPED" State WScript.Sleep 2500 Encoder.Start WScript.Sleep 2500 WshShell.AppActivate("Viewer Application") WshShell.AppActivate("Internet Explorer") WshShell.AppActivate("Windows Internet Explorer") WshShell.AppActivate("Site URL Goes Here in Titlebar") WshShell.AppActivate("Site URL Goes Here in Titlebar - Viewer Application") WScript.Sleep 100 End Select Err.Clear WScript.Sleep 1000 Wend
The script isn’t incredibly complicated. We’ve settled on using AppActivate commands because the programmatic pressing of the “Start Encoding” button in the watchdog loop causes Windows Media Encoder to pop to the foreground over the viewer, blocking the window – not what we want to happen. The AppActivate pops the viewer back to the foreground where it belongs
To make the system more robust and appliance-like, the system checks to see whether the encoder is active and if it’s not (due to a network drop or other connection error) to reconnect. The Asus netbooks have a webcam driver that likes to act up after a few days running, so we’ve configured them to reboot automatically at around 3AM every day. They’re configured to come online fully automatically, so this restart is seamless.
The result came out better than expected: by simply monitoring the encoder’s state and disabling popup error messages, the system is robust enough to overcome non-critical driver errors, client-side network drops, and even reconnect automatically if the server is taken offline due to connectivity or maintenance. It’s expandable, too: viewer can be transparently updated with new features (as it’s a web browser, after all) and new clients can be added limited only by your screen’s area. It’s also possible to create different viewer interfaces depending on the device – a flat panel monitor, a large TV or a netbook. The initial startup page could become a landing page, redirecting the viewer clients to pages based on their HTTP request, User-Agent, IP, or another mechanism.
The first time the system is configured, you must create a new Session in Windows Media Encoder and save it to a file on your hard drive. The Session contains the source, destination, security and formatting information for the stream. We’re streaming video only right now, although audio streaming may come in a later version. Unfortunately, a profile must be created for each system manually, as it contains information about the specific driver and device that will be used.
The Encoder session is configured in Push mode – connecting to the server directly, instead of the server connecting to the encoder. This allows the appliance to work from behind nearly all firewalls, and is an additional security feature as the encoder controlling the camera cannot be accessed from outside the network, so it’s not possible for an unauthorized party to tap into the video feed. Additional security (authentication and IP range) is provided on the server.
Finally, we’re streaming 320×240 at 4 FPS, ~100Kb/s. CBR was chosen due to its simplicity, as it’s less taxing on the Celeron and Atom CPUs in the netbooks – and although being labeled as constant, when the camera is pointed at an unchanging scene without much color the bandwidth really does drop down, for example if the camera is pointed at a wall, it’s shutter is closed, etc. This might seem low, but it’s designed to be highly portable and we had to keep screen resolution concerns in mind. The quality is quite acceptable for casual use as we’ve designed it.
It’s pretty simple and can be expanded or modified as needed.
On the server side, the viewer code and stream brokering is handled by Streaming Media Services running on Windows Server 2008 R2. The streaming is hosted on a business-class connection with a 5Mb/s upstream, which is more than sufficient for current and future applications: the incoming bandwidth scales linearly with the number of clients, and while the outgoing bandwidth scales as the square of the connected clients this issue is mitigated by controlling the encoder settings to use only approximately 100Kb/s per stream. Our four-encoder system uses only 400Kb/s downstream bandwidth and 1.6Mb/s upstream – it will scale transparently to around 12 clients before becoming bottlenecked on the connection, or around 8 clients with higher resolution and audio.