Union of Concerned Scientists members have the opportunity to participate in conference calls and webinars on topical issues. A webinar on July 22nd presented Climate 2030: A National Blueprint for a Clean Energy Economy which "shows how the U.S. can achieve deep cuts in global warming emissions while saving consumers and businesses money by implementing a comprehensive suite of climate, energy, and transportation policies." The analysis is the result of a two-year study involving a multi-disciplinary team at UCS combined with a rigorous external peer review process. The charts, an audio recording of the presentation and an executive summary can be downloaded from http://www.ucsusa.org/about/ucs-climate-2030-blueprint.html.
The presentation showed how emissions reductions in various sectors between now and 2030 will allow the USA to reach its 2050 emissions reduction goal of 80% from 2005 levels. The bulk of the reductions (57%) will occur in the electricity sector (20% from residential, 23% from commercial and 14% from industrial) with transportation contributing another 16%. A key finding was that consumers and businesses across the USA would save money in spite of higher costs due to the carbon cap-and-trade legislation, due to reduced energy usage through efficiency.
The study suggested that a significant reduction in carbon emissions from electricity could be achieved by 2030 through efficiency savings, combined with a shift from coal to wind, solar, biomass and geothermal. Combined heat and power would increase while the contribution from hydro and nuclear power would stay roughly flat. A similar trend was seen for transportation, with avoided emissions the largest contribution followed by lower emissions from light-duty vehicles. Alternative fuels would increase four-fold, with the largest growth in cellulosic fuels, early growth in corn-based ethanol followed by a decline after 2022, small growth in electricity or hydrogen, and a slight decline in natural gas. Although the contribution of electricity or hydrogen-powered vehicles appears small, it still represents 20% penetration in the light-duty market by 2030.
The analysis was based on a comprehensive and coordinated set of policies affecting:
- carbon emissions directly through cap-and-trade
- industry and building standards
- a shift to renewable energy generation
- increased efficiency in the transportation sector, smart-growth policies and per-mile fees
UCS is running the 2009 Science Idol: The Scientific Integrity Editorial Cartoon Contest, a humorous look at the serious issue of political interference in science. You can vote for your favorite cartoon, enter to win a free calendar, sign-up for UCS newsletters and also become a member. UCS has recently being offering members a series of webinars on climate change and clean energy. UCS regularly provides the public with opportunities to take action to influence government and business leaders.
The two SheevaPlug 'plug computers' I described in Rogers Rocket Mobile Internet Service - Automation arrived last week. The good news is that both are working fine and detected the 3G modem. The bad news is that the pre-installed Ubuntu 9.04 system does not include the required drivers. I will need to read up on how to add the drivers to the current kernel or install a different kernel package. Fortunately, there is an active PlugComputer Community to speed up my education.
Since the onboard flash is only 512MB, I picked up two 8GB SDHC Class 6 flash cards, moved the root file system and then followed the New Plugger How To setup instructions. So far, the only issue I had was getting sudo working (the executable did not have the right permissions). Running off the SDHC card gives me the flexibility of booting from the onboard flash if I need to recover from configuration issues or want make a backup of the SDHC card.
Once I get a kernel that supports the Rogers 3G modem, the next step is to install the Shorewall firewall, ObjectREXX to support the automation and OpenVPN to get around the VoIP problem. The second SheevaPlug will be used as a development machine and also as a file and backup server. Updates to follow.
All posts in this series:
- Rogers Rocket Mobile Internet Service - SheevaPlug
- Rogers Rocket Mobile Internet Service - Voice over IP
- Rogers Rocket Mobile Internet Service - A Lesson in Assumptions
- Rogers Rocket Mobile Internet Service - Automation
- Rogers Rocket Mobile Internet Service - Multi-PC Setup
- Rural Internet - Rogers Rocket Mobile Internet Service
I had signed up for a Voice over IP (VoIP) service from IGONET while still on the satellite Internet service. Although I was able to dial out and receive inbound calls, the high latency impacted voice quality. An attempt to set up a three-way call ended in total failure. Nevertheless, I kept the service since it provided me a 'travelling Toronto' number anywhere I had my laptop and a decent Internet connection.
I was pleasantly surprised when the VoIP service connected over the RocketStick. Initial testing looked very promising - I could both make and receive VoIP calls that sounded as good as my landline. A few days later, I noticed that the VoiceMail indicator on my handset was flashing. Neither my landline nor VoIP had any voicemail pending. I called into my VoIP number to leave a voicemail that I could then delete and clear the indicator. Unfortunately, the VoIP call neither connected nor rang through to voicemail. It appeared that inbound traffic from IGONET was being lost within 6 to 10 minutes of the VoIP appliance registering with IGONET.
IGONET Technical Support provided me with documentation on configuring 'port forwarding' on any software or hardware routers I controlled. These routers implement Network Address Translation, allowing multiple device behind the routers to 'hide' behind a single Internet-facing IP address. In addition to simplifying the network configuration, it also provides a degree of security. The router 'remembers' the return path for any traffic outbound to the Internet. It does not know which device behind the router should receive unsolicited inbound traffic from the Internet and drops it. Port Forwarding gets around this problem.
Unfortunately, Port Forwarding did not resolve the problem. More to the point, it would not have been effective since my Linux software router is not directly visible to the Internet - the 3G modem is connected to Rogers over a private network and I had no means of getting Rogers to include the Port Forwarding rules on their boundary router.
Line traces and simplifying the configuration to the bare minimum showed that both Rogers and my software router were properly routing inbound traffic to the VoIP appliance. The appliance regularly sent out 'keepalive' packets that should cause routers along the path to the IGONET services to 'remember' the return path. It was possible that a router had 'aged out' the routing information because the IGONET services normally did not acknowledge these keepalive packets. However, I had seen cases where IGONET had sent a 'ring' request to the VoIP appliance but the 'cancel ring' request that IGONET sent when I hung up my landline never arrived.
On a hunch, I first reproduced the problem with a software VoIP client on my laptop. I had previously set up an OpenVPN service to a server in the US for situations where overly aggressive firewalls were blocking traffic such as outbound e-mail or VoIP. When I tested VoIP over the OpenVPN tunnel, the VoIP service did not fail.
The next step was enabling the OpenVPN tunnel on the Linux server. This proved to be harder than I had expected, since the traffic from the VoIP appliance was originating from a network external to the server. The OpenVPN document covers this situation but does not fully explain all the details. Basically, OpenVPN needed to replicate the Linux server network configuration on the OpenVPN server, requiring OpenVPN configuration and firewall changes.
The good news is that the VoIP service has been rock-solid. Even if the RocketStick service needs to be restarted, the OpenVPN tunnel re-establishes itself automatically and the VoIP appliance re-registers with IGONET. Voice quality is still reasonably, although the longer path and OpenVPN overheads are noticeable.
IGONET has been very helpful in trying to get VoIP. Rogers has so far claimed that the Rocket Mobile Internet Service is not intended for VoIP applications. After escalation, I was advised that purchasing a public IP for an additional $10/month might help. I have not had a chance to test this theory.
All posts in this series:
- Rogers Rocket Mobile Internet Service - SheevaPlug
- Rogers Rocket Mobile Internet Service - Voice over IP
- Rogers Rocket Mobile Internet Service - A Lesson in Assumptions
- Rogers Rocket Mobile Internet Service - Automation
- Rogers Rocket Mobile Internet Service - Multi-PC Setup
- Rural Internet - Rogers Rocket Mobile Internet Service
USB extension cables are limited to 15', due to the nature of the USB protocol. The Cables Unlimited USB to CAT5 extension cable theoretically allows me to locate the 3G modem 150' away. However, Linux was periodically reporting the error:
hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
To diagnose this problem, I replaced the USB/CAT5 cable with a 15' USB extension cable last week. Later that day, the Internet connection became increasingly unstable, sometimes staying up for only a few minutes at a time. The problem appeared to have corrected itself by next morning, but then returned with a vengeance. Plugging the 3G modem directly into my laptop suggested that there might be some carrier issues, although nothing as severe as I had been experiencing.
Plugging the USB extension cable directly into the server significantly improved reliability. I suspected a problem with the Arduino power controller and started to systematically remove components until I finally jumpered the USB leads and powered off the power controller completely. Almost anything I did seemed to improve reliability, but not enough.
In hindsight, the problem proved to be embarrassingly obvious. I had not been able to find USB male and female connectors that would plug into the Arduino proto board, so I had cut into a 3' USB extension cable and wired it into the power controller. Even without the power controller, the 15' USB cable was connected to an 11" tri-tip cable that provides additional power for the 3G modem. The power controller increased the overall cable length to 19'. Whenever data volumes increased, errors would occur until the modem disconnected from the port.
It is easy to get caught up in the process of problem determination, especially with intermittent problems where changes unrelated to the root case can see to be effective. Literally 'taking a step back' to assess the situation would likely have reduced the time it took me to resolve the problem.
All posts in this series:
- Rogers Rocket Mobile Internet Service - SheevaPlug
- Rogers Rocket Mobile Internet Service - Voice over IP
- Rogers Rocket Mobile Internet Service - A Lesson in Assumptions
- Rogers Rocket Mobile Internet Service - Automation
- Rogers Rocket Mobile Internet Service - Multi-PC Setup
- Rural Internet - Rogers Rocket Mobile Internet Service
Both the Novatel and ZTE modems suffer from periodic connection loss, either because the modem disconnects or Internet servers do not respond. In most cases, the Linux wvdial command automatically detects this condition and re-establishes the connection. I developed automation written in REXX that would first check if Google was PINGable. If not, the code would check for the following conditions, log all errors and take corrective action.
- Is the modem connected?
- Does the Linux ppp0 interface to the modem exist?
- Is there an IP address associated with ppp0?
- Is wvdial running?
The Arduino has a USB port (left right corner) that provides power and a PC link used to upload the Arduino program and read Arduino status information. Using instructions in the Arduino and Linux TTY forum allowed the automation on the Linux side to send commands to the Arduino which would then open the power relay for five seconds.
Unfortunately, although everything worked fine from Windows, the Arduino responded erratically under Linux. It turns out that opening the serial port from Linux caused the Arduino to reset - a known problem that had various workarounds involving modifications to the Arduino. Rado provided a software solution that solved the problem cleanly, allowing me to communicate with the Arduino using the Linux echo command. The automation has worked flawlessly for several weeks.
All posts in this series:
- Rogers Rocket Mobile Internet Service - SheevaPlug
- Rogers Rocket Mobile Internet Service - Voice over IP
- Rogers Rocket Mobile Internet Service - A Lesson in Assumptions
- Rogers Rocket Mobile Internet Service - Automation
- Rogers Rocket Mobile Internet Service - Multi-PC Setup
- Rural Internet - Rogers Rocket Mobile Internet Service
The RocketStick is a USB 3G wireless modem intended to connect a single PC to the Rogers Mobile Internet Service. I could have set up a Windows PC as an Internet gateway, but the software provided with the modem would have made it difficult to develop monitoring and connect management automation. Also, it would allow me to move the 3G modem outside the house to improve signal strength which is reduced due to the aluminum roof.
I built an Ubuntu 8.10 server using an ancient desktop PC. The first problem is that these 3G modems implement the ZeroCD feature, where the device initially presents itself as a flash drive. The Windows installation software disables the ZeroCD and allows the device to connect as a modem. The usb_modeswitch software provides similar functionality on Linux. On older versions of Linux, the 3G modem was supported by the usbserial driver which could not handle the full bandwidth of the modem. However, Ubuntu 8.10 provides the option driver which is much faster.
After configuring and testing the modem on Vista, I was able to establish a connection on Linux using the wvdial command with a minimal configuration. The dhcp3-server code allowed the server to support dynamic IPs for devices connected on the Ethernet port. A Shorewall firewall provided security and routing. The final configuration included a Sipura VoIP appliance and a Linksys WRT54G wireless router.
The first 3G modem (a Novatel Ovation MC950D) provided decent bandwidth but was not particularly reliable. About once a day, the modem would 'freeze' and not respond to the server. Attempts to reset the USB port from software were unsuccessful. With the help of the Ubuntu community and especially George Vita, I was able to convince Rogers to replace the modem. George also helped disable ZeroCD on the replacement ZTE MF636 by using HyperTerm to send the modem the AT+ZCDRUN=8 command.
The ZTE modem is a bit faster and also more reliable than the Novatel, but still periodically freezes - but that is a story for the next post.
Passive USB cables are limited to 15'. I have tested a Cables Unlimited USB Over Cat5E Extender which supports up to 150' of cable. Although it works, it appears to reset the USB port periodically. If the SheevaPlug proves to be reliable, I plan to locate it in the attic with a 15' USB cable to the modem and second 15' USB cable providing access to the serial port if problem determination is required.
All posts in this series:
- Rogers Rocket Mobile Internet Service - SheevaPlug
- Rogers Rocket Mobile Internet Service - Voice over IP
- Rogers Rocket Mobile Internet Service - A Lesson in Assumptions
- Rogers Rocket Mobile Internet Service - Automation
- Rogers Rocket Mobile Internet Service - Multi-PC Setup
- Rural Internet - Rogers Rocket Mobile Internet Service
One of the joys of living in a rural area are the limited options for high speed Internet. I have no access to cable or DSL. Bell and Rogers provide Internet over microwave (WiMax) from towers in the Newmarket area, but the signal peters about two kilometres west of my house. To the east is a high speed Internet wasteland.
The only option has been satellite Internet, a costly service that provides limited bandwidth with high latency (the round-trip time to web servers). The service was good for the first year, acceptable in the second but increasingly unreliable in the third. I discovered that I was regularly running afoul of the 'Fair Access Policy' that reduced my bandwidth by 90% if I downloaded more than 55MB or uploaded more than 5MB in an hour.
I stumbled on the Rogers Rocket Mobile Internet Service that uses the 3G cellphone technology introduced to support smartphones and other mobile devices. Intended for mobile users, the helps fill in some of the high speed Internet coverage gaps as shown in the yellow areas of the southern Ontario coverage map. Be warned - EDGE connectivity (the red areas) is significantly slower than the HSUPA service, with a maximum download speed of 287 kbps.
The costs are steep: a 5GB/month plan is $88 plus tax, and additional traffic is charged at $30/GB. However, the overall monthly bill is capped at $108, which is only slightly more than what I was paying for the satellite service. Testing so far has been positive. The bandwidth is no worse than the satellite service and often better. Latency is much better so web browsing seems 'snappier'.
There have been challenges. The RocketStick is a USB modem, intended for a single PC. The connection will fail intermittently but re-connecting usually resolves the problem quickly. However, sometimes the USB modem appears to hang and needs to be physically power-cycled. The most technically challenging problem has been getting Voice over IP working. The solutions will be the subject of subsequent posts.
All posts in this series:
- Rogers Rocket Mobile Internet Service - SheevaPlug
- Rogers Rocket Mobile Internet Service - Voice over IP
- Rogers Rocket Mobile Internet Service - A Lesson in Assumptions
- Rogers Rocket Mobile Internet Service - Automation
- Rogers Rocket Mobile Internet Service - Multi-PC Setup
- Rural Internet - Rogers Rocket Mobile Internet Service
I have recently had some less than positive experiences with 'customer service', recently another way of 'adding insult to injury'. Letters go unanswered and staff are often poorly trained, unaware of their company's products or services and unable to answer even simple questions. And then there are the voice response systems, designed to make sure blood pressure quickly reaches critical levels before finally allowing us to escape from the maze, only to have the human ask us for the same information that we had already laboriously keyed in.
There are exceptions. I was recently reminded that good service can be simplicity itself. I regularly order from Dark City Coffee, a Toronto firm that custom roasts a wide variety of coffee to your taste and delivers to your door via courier (within the GTA). The process is straightforward: call a number and leave a message. New customers receive a return call so that the staff determine the customer's coffee preferences. Existing customers can just leave their order.
Consistency is an important part of good customer service. Although I usually order late in the day and live in a rural area at the northern limit of Dark City's delivery area, the package arrives like clockwork two days later. Only once was an order lost - a quick phone call solved the problem.
Dark City Coffee is a relatively small company and does not require sophisticated systems behind the scenes. However, even large companies could benefit from the morale of the story: the best service is simple, responsive, consistent and high quality.
