Gussy

I bought an original Thinkpad X1 at the start of the year and after using it since then I have to say the biggest problem it has is the battery. It's more like a large capacitor than a battery, something to keep itself powered while your run between power outlets. It is actually quite disappointing when the sole reason you buy an ultra-thin "ultraboook" is for mobility and portability, but you have to stay tethered to a power outlet.

It's great to see that they have addressed this issue in the X1 Carbon. Engadget suggests a 3:30 battery life for the original X1 which seems about right, so I trust their measured battery life of 5:07 to be pretty close. I presume real world usage will be even better than the extra 1:07 from the original X1, as moving to the matte screen should mean a lower display brightness, since you're not fighting the reflectiveness of the corning gorilla glass.

The second biggest issue I have had is one of quality. My first X1 was RMA'd for faulty mouse buttons and wireless antenna right after I opened the box, and the second one I received reported incorrect battery capacity, had dead pixels centre screen and some other hardware faults which escape me. Thankfully I was able to salvage a completely working X1 out of the two (original and replacement), returning to Lenovo a very broken, but brand new Thinkpad.

Despite the carbon fixing my number one issue of battery life, I'm still not sure if I would upgrade to it, given then chance. I originally bought this Thinkpad X1 because it was supposed to be a Thinkpad, something that was nearly bulletproof and would withstand the abuse of travel and the outdoors. Lenovo has lost my trust in Thinkpads for now, but hopefully this X1 Carbon is better than the original.

I'm also from Australia and I could list at least a dozen places I would buy an Arduino from, before using your website that's less than a month old, and provides no contact details.

This blatant advertising is poor form.

From the retrieval times they are giving, it seems plausible that they could be only booting the servers 5 or 6 times a day, to run the upload and retrieval jobs stored in a buffer system of sorts. Having the servers turned off for the majority of the time would same an immense amount of power, although I wonder about the wear on drives spinning up and down compared to being always on.

Any other theories on how this works on the backend while still being profitable?

I completely agree, this kind of presentation is so great to see!

This is one of the hard problems open source hardware has at the moment. The community is just now realising its existence, so hopefully there will be more so us working on solving it soon.

Without going into too much depth (which probably warrants a whole article of it's own), the problem is that once you have designed something electronic and built a few, actually manufacturing more than a handful of PCBs (>10) not only becomes a whole different ball game, but requires a completely different skill-set to actually pull off well.

I find how this is now all playing out to be quite interesting, and a little amusing:

A few years back when there was really only one prominent open source UAV system (Paparazzi), nearly everyone was focused on turning (fixed-wing) radio-controlled planes into hobby UAVs. Back then we didn't have gyros or accelerometers, we used thermopiles to detect the heat difference between warm ground and the cold atmosphere on four axis. This worked well until it became night time or started raining, and required a baseline calibration before most flights.

When projects like OpenPilot and Ardupilot (aka. DIYDrones/3DRobotics) first started to appear they were focused on building UAV systems for planes with this same technology, multi-rotor vehicles where only just on the radar at that stage. They were expensive and to be frank, not very good at flying stable. Then game consoles like the Wii came along and over the next few years gyros and accelerometers started to become much cheaper.

OpenPilot and DIYDrones/3DRobotics initially started out developing with these new gyros and accelerometers in planes, but it wasn't really the right platform as planes tend to me more costly and fragile in a crash, which is inevitable when developing with these new technologies. OpenPilot initially started to adapt their system to multi-rotors (aka. quadcopters) as a way of quickly testing new code and new algorithms for planes. Unlike planes we could even now test code indoors.

Quad-copters started out as a utility, to lift heavy items or as a test-bed for fixed-win UAV algorithms. From there they have now become the first class citizen in the world of open source and hobby UAV projects.

I think this is all really just starting to ramp up. The hardware we need to build these systems is pretty much all there, it can get faster, smaller and cheaper but innovation there is nearing a plateau. On the other hand, I think software is still very much in it's infancy. There is still a long way to go in making these systems reliable and repeatable, and most importantly user friendly. We have progressed from having to re-compile under linux to change one PID setting value, but the barrier to entry is still quite high on the technical side of things.

Disclaimer: Co-Founder of the OpenPilot project.

Chris would be talking about the new MPU9150 from Invensense: http://www.invensense.com/mems/gyro/mpu9150.html

Pricing isn't public yet but you can get an idea by looking at the 6-axis products.

As someone pointed out in the comments these processors require DDR3 memory, which is only available (currently) in BGA packages. This means you can't quite use a soldering iron to build your own small computer, yet.

The real advantage here is not the savings in the soldering soldering but the savings in PCB complexity and cost. A small BGA with a few hundred pins will need at least 6 or more layers to be able to "break-out" all the pins from underneath the chip. With the TQFP package, all the pins are already at the edge of the chip, so it's possible to use a 4 layer PCB.

It's an exciting time when more people can have access build thing using this level of hardware. Now the next thing we need is decent documentation to go with these chips.

From one of my Linode 512's in Fremont I get 89.0MB/s running the "test" in this blog post.

Sent you an email, maybe I can help you out :)

ST has a very nice "Standard Peripheries Library" for their STM32 ARM Cortex M3 line which abstracts all the bit and register manipulation away in a very elegant manner. Atmel has the "AVR Software Framework" which I have heard good things about but haven't used it myself.

Nearly all the chip manufacturers I know of have some sort of framework/library for their Cortex M3 line (which is what is in the new Arduino).

The reason it doesn't get used for serious or complex projects is simply because of it's lack of capabilities. The big one is debugging and this is a huge reason for why you won't see EEs using these at their day jobs. Electronic engineers are accustomed to being able to step through code, watch variables and all the other niceties that in-circuit debugging offers. With Arduino you lose all of this, your flying blind with maybe a flashing LED or a serial output to help you out. Who knows how you will detect elusive bugs like out-of-bound array errors. The time you gain with some nice wrapper functions and libraries you will quickly lose when trying to debug a complex project. Features wise, you can do things most of the more advanced features which require bit manipulation of the AVRs registers like interrupts, timers, etc. with Arduino. Though at that point the lines are so blurred because half your code is AVR-GCC and half is Arduino. Why don't we see the simple consumer products using Arduinos? I don't know for sure but it's most likely because something simple is just as quick to code without the Arduino libraries.

Atmel and most other micro suppliers are now coming out with their own "frameworks" these days, which are similar to Arduino in providing libraries for common tasks with a similar level of abstraction to Arduino, without the loss of the higher level functionality like debugging. These are a lot more attractive to EEs than Arduino is.

It will be interesting to see how this changes over the next 5 or so years. By then most of the young engineers who grew up with Arduino or were even introduced to electronics with Arduino will have graduated University and will be working in the industry. It will be interesting to see the effects that this generation of new engineers have.

It's a huge shame that none of the existing ARM Cortex M3 Arduino-like platforms (Maple, Corduino etc.) ever took off. While this is mostly likely because of the projects not being officially endorsed by Arduino, it does also make you wonder if there is actually a demand for this higher level of capability. I have a bad feeling that offering a much more powerful Arduino will only result in people writing more inefficient code.

Moving into ARM territory was always inevitable for Arduino, it has just taken a little longer than it should have, because Atmel were a little behind the curve in getting their Cortex M3 offerings onto the table. What does surprise me is that it has taken this long for Atmel to step in and offer some support to Arduino.

It depends what you mean by industry.

No reasonably qualified electronic engineer would use the Arduino platform in a commercial design. Most managers would laugh at any EE who suggested such a thing. I am not aware of any mass produced (consumer, not hobbyist) product or device which uses the Arduino platform. In the industry of fashion and art (which I know very little about) many makers/creators/designers are incorporating Arduinos into art installations and fashion items, although from what I understand these are mostly one-off items.

Slightly better coverage here; http://www.smh.com.au/technology/security/evil-the-hacker-re...