We got our 2013 Prius just about a year ago, and I ran TRIP A without resetting it for that whole first year. Here are the final numbers:
For everyone not still suffering under the tyrrany of imperial measures, 44.4mpg is around 5.3l/100km and the distance driven is about 12000km.
That means ...
- 260 hours total driving time
- 43 minutes driving time per day
- 21 average miles a day (33km)
- 170 gallons of fuel (640l)
- 2/3 gallon per hour of driving (2.4l/hour)
Getting at 44.4mpg instead of the EPA combined fuel economy of 50mpg means using 20 extra gallons of fuel over the course of the year, 13% more than predicted.
Overall we're happy with the Prius. It's much roomier than the car it replaced and it has better fuel economy. However, I'm a bit sad we didn't get closer to the EPA fuel economy.
The main thing lowering the fuel economy is short winter drives. My drive to and from work is just 2.5 miles per direction, and I often drive a similar distance to and from lunch. In winter, that's too little distance for the car to warm up to the point that it enters the fuel-saving EV mode while stopped at lights. (this kind of driving is even classified as "severe operating conditions" by Toyota: "Repeated trips of less than 5 miles in temperatures below 32 degrees Fahrenheit")
Our summertime fuel economy (also the time of year when we make long driving trips on the highway) is closer to 48mpg.
Windsong B&B where we stayed on the east coast of Tasmania.
I decided it was time to reboot my digitalocean machine after installing a new kernel. Its uptime was:
17:14:28 up 368 days, 19:55, 3 users, load average: 0.29, 0.10, 0.07Since that's a year I suppose that in that time it's cost me about $60, minus some for the referrals I've gotten for posting about them on my blog.
.. I actually had to reboot it twice because I didn't know you had to change the kernel version via the control panel(!) but no harm done.
Anyway, in that time I never noticed any blips in functionality or connectivity, though on a couple of occasions they credited me a few cents for a service interruption.
All in all, it's quite a solid service!
TXRX Labs of Houston opened its doors to LinuxCNC users and developers.
I was there from Friday to Tuesday, and enjoyed the time talking to fellow users and developers.
On the development side, we brainstormed and then started work on what we are calling "lui", a new C API for developing LinuxCNC user interfaces. lui is the first step of an incremental plan to eventually remove NML, or at least make it optional. I also investigated a proposed fix for some long-standing multiple UI fixes, which I think we should incorporate in 2.7 even though it needs further work to support the near-mythical NML-over-TCP connection method.
Seb volunteered to be the release manager for 2.7, we accepted his offer, and he created the 2.7 branch, which should now be considered to be in a stabalization phase.
As far as TXRX's retrofit projects, a bunch of us worked on the "Powerhawk". A fair amount of time was spent chasing problems with the servo motor tuning (causes included ground loops and generating correct simulated tachometer feedback), but we also got all home and limit switches working and started troubleshooting the partially-done tool changer implementation.
On the education side, we did not do as much as we had hoped to do. I had prepared a very introductory talk on writing hal components with comp/halcompile. However, everybody with an interest in writing hal components already knew everything in my presentation, so there was little point in actually giving my talk. Jon Elson did use the Powerhawk as an object lesson in servo tuning.
On the social side, it was fun to hang out with fellow LinuxCNC people, as well as meet and talk to the TXRX locals. Everyone was quite friendly, and I got to give the "elevator pitch" LinuxCNC introduction to a fair number of people. Chris and Roland were great hosts, too, making sure we could come and go at all hours.
I would love to return to TXRX labs for a future LinuxCNC gathering. Hopefully that would include a little more structure (such as setting a schedule for presentations, in case that helps bring in more people who would benefit from them). One interesting idea I heard was getting some simpler (bridgeport-scale) machines to retrofit with LinuxCNC, which would then be given (back) to other hackerspaces when we were done.
(more photos of TXRX labs after the jump)
Update, 2014-10-25: This can be mitigated on the server side. When HTTP headers specify 'Cache-Control: no-transform', Sprint's proxy honors it and doesn't degrade the image before sending it to the phone. In apache, this can be achieved by enabling mod_headers and putting Header add Cache-Control no-transform in an appropriate location. I've done this for the server where my photos come from...
When showing my blog photos on my phone, I noticed that they looked terrible. Shown above is a detail of the original image (not entirely free of JPEG artifacts) and of the same area after it was recompressed by sprint. (zoomed 200%, nearest neighbor scaling)
It turns out that sprint recompresses jpegs and this is documented by sprint, but it's still terrible.
It also affects ting.com users, since they are a sprint reseller. (and I didn't find any ting documentation about this misfeature yet)
This happens both on the phone itself, and to devices tethered via the phone.
Most images aren't mangled quite as badly as this one, but their claim that there's "no user perceptible loss of quality" is bunk.
Here are the jpeg files zipped up, in case you are interested in inspecting them for the jpeg compression details: original-and-recompressed.zip
I know that serving web pages over https is the new hotness; here's another reason to do it, since sprint couldn't rewrite the contents of content served over https.
Original image, converted to png
Sprint-recompressed image, converted to png
Halls Gap Zoo, not far from Horsham.
All older entries
Website Copyright © 2004-2014 Jeff Epler