pbo

Do you have an estimate of the efficiency of the DC -> AC -> DC charging system?

That is the principle of a ram air turbine. It's a small wind turbine which can operate as a power generator while the plane is flying.

Redundancy is a well-accepted (at least in aeronautics) way of providing robustness. When designing onboard systems for aircraft, it is not unusual to have a function with a higher level of design assurance which is implemented by a set of similar devices with a lesser level using a majority vote.

See multi-version dissimilar software: https://en.wikipedia.org/wiki/N-version_programming

Furthermore most modern planes are designed to be able to fly with one engine inoperative, even those which have only two engines.

There is a tremendous number of hardware products and industrial systems where the processing is performed on small and cheap components (microcontrollers, digital signal processors).

Of course there exist very complex components in the category of microcontrollers, some of them even offer enough resources to run Linux, but if you stick to the $1-$5 range the specs are very limited.

Here are two examples, the first one costs around $3 and the second one is less than $1.

http://www.ti.com/product/tms320f28027 http://www.atmel.com/devices/attiny85.aspx

I develop on such platforms and even though there is an interesting challenge in programming these tiny processors and optimizing CPU cycles and memory usage all the time, in the long run it becomes quite strenuous because there is only low-level stuff and I miss the expressiveness and flexibility of more abstract languages.

If I recall correctly, Intel tried a few years ago to sell a system-on-chip combining an Atom CPU with a FPGA from Altera. I believe it didn't work very well, especially with regards to communication and synchronization between the two cores.

I second that.

I write assembly for DSPs on a near-daily basis. Up until a few months ago there didn'nt even exist a C compiler for the target architecture.

Even when you write C code for an embedded platform that does have a decent C toolchain, you cannot truly understand what you're doing without spending a lot of time looking at the generated assembly, and writing some of it yourself.

However, this kind of architecture has nothing to do with the x86. RISC, no cache, in most cases no MMU (and rarely any DMA), an extremely simple and straightforward pipeline, etc. I've written assembly for several such architectures, but compared to them I find x86 assembly intimidating.

Even though the work environment is peculiar, the technical contents itself is far from exceptionnal, really.

If you'd like to read more about this kind of systems, this document could be a starting point: http://www.ti.com/lit/ml/slup232/slup232.pdf

It sums up pretty well the stakes and technical challenges with digital power supplies.

Actually I distribute power from the battery to other subsystems, so it's rather far from the ECU.

I wrote firmware (~20kLocs) for a power (electrical) supply that's part of one such power train.

This kind of development is very demanding, because you can't afford to leave any bugs in your program but at the same time you're always shipping late because of tight schedules and often blurry specifications.

On top of that hardware and software development cycles are concurrent, so no target hardware available when you're writing your code.

In these conditions the only way I found to have something that works is to keep it very simple:

    1. Simple algorithms
    2. Simple data structures
    3. Few abstractions
    4. No dynamic memory allocations

Exactly. Since the output is not continuous, the average power remains quite low. This is why you can still power it from regular domestic power :)

It's useful when you have a circuit which needs a high-current burst which is powered from a low current (but high capacity) power source.

One application for this is lasers. I'm part of a team that works on a converter that uses wall power as an input to continuously charge a few dozens ultracaps then empties them all at once to fire very short pulses in the hundreds of kW.

What I find the most impressive about this is that the mechanical engineers have managed to fit this in a 2U rack.

From here, for the past 3 years: https://www.sparkfun.com/products/10822

I was lead tech (and first hire) at a hardware startup which launched two unsuccessful products then ran out of money (despite some seed funding). After that I left.

Revenue and margins yes, but far from break-even.

This looks great. I want to write a DSL to generate low-level code, and it would have involved both C and Lua at some point, so I'll definitely give this a try.

http://maps.stamen.com shows the same kind of map transformations and is also based on OpenStreetMap. The Watercolor style is especially gorgeous in my opinion.

This also shows in how quick you can iterate. The "REPL time" in mechanical engineering has decreased a lot with CAD software but it's still insanely long compared to software development.

I used to work in a lab with a researcher who designed complex mechanical systems with lots of rotating parts made from rare and expensive materials. Everytime he needed even the slightest modification he had to wait for at least three months to have a new part machined.

Small environments also have an influence over the body size of animals. Surprisingly the change does not always occur in the same direction: see Insular Dwarfism and Insular Gigantism.

[1] http://webecoist.momtastic.com/2010/08/09/insular-dwarfism-1...

[2] http://webecoist.momtastic.com/2010/08/02/animal-gigantism-1...

I would love to have a higher-level-than-C language to work with on embedded systems, and Clojure seems good.

However my applications run on systems with very limited resources (and a Harvard-ish architecture, e.g separate data/program memories) and I wonder how far tools like ClojureC could go with regard to these constraints.

This reminds of a fascinating book, The Man Who Mistook His Wife for a Hat by Oliver Sacks.

One of the most interesting stories is about a man who lost his ability to intuitively recognize things and needs to reason about their features to find out what they are.

  This is my shoe, no?
  No, it is not. That is your foot. There is your shoe.
  Ah! I thought that was my foot.

I work at a hardware company - high-current and high-voltage power electronics. Things occasionnaly blow-up, but there have never been any serious consequences, because eveyone has very safe working habits, even the individuals who act like they don't care. Unfortunately this is not always the case for our clients..

Nobody mentioned the Shanzai. The term was explained to me by the founder of a hardware company in Shenzhen. They are small companies that specialize in infringing IP laws and copying consumer electronics products almost as fast as they a released on the market.

See http://news.xinhuanet.com/english/2008-12/30/content_1058293...

I have used 3D printing in two different contexts:

- At a research lab. They had a massive Stratasys which cost around $30,000. They used it all the time for experiment setups; they had a whole workshop with CNC mills, lathes, etc. and the 3D printer was one machine among the others. It was used as much as the others, no less, no more.

- At a hardware startup. We never bought a 3D printer, but we used on-demand 3D printing services (Shapeways, Ponoko, Sculpteo, etc). This allowed us to iterate rather quickly on design matters - we were doing consumer electronics.

For my personal use I don't think I'll buy a 3D printer within the next 5 years.