One of my concerns is that my solder mask is so far away from all the pads and holes. On this board, you can see how each side of the TQFP44 part (U1) has no solder mask in between pads. Many of the pads easily lift off the substrate when touched with the soldering iron.

Here’s an example of a board where the mask seems to go all the way onto the pads (and between them):

Obviously, I have some spacing set a certain way in Osmond, but I don’t know if that’s required, or if I should be doing things differently.

The wing above is the red one in this photo. The new wing is the black one:

The new wing will use an E-flight Power 32 motor, shown here on the test stand:

New UAV Parts

I had a flurry of buying activity this weekend, after seeing the new wing. The thing is huge: 2.1 m. I decided to build one, too. The wing it self will take the longest to arrive, some time next week, but I ordered everything else in the mean time, which should arrive before the weekend.

Here’s the list of stuff:

From: Anton S. [mailto:xxx@yyy.com]
Sent: Monday, August 29, 2011 9:42 AM
To: dept@yyyy.com
Subject: Anton WFH Today

There was a shooting Saturday night in SF where my car was parked. When I was walking to my car I got hit by a ricochet bullet. Luckily it hit the side of my neck and didn’t enter the body (just a flesh wound). I am fully functional, but my neck is a little sore. Working from home today.

Related local news links
http://www.ktvu.com/news/29005645/detail.html
http://www.sfexaminer.com/blogs/law-and-disorder/2011/08/two-wounded-san-francisco-soma-shooting-early-sunday-morning

-Anton

Here’s the worst bit of science so far. The research team developed a Predator-like drone that flies a swarm formation, creating rain clouds (the drones are called SERIFs, but I don’t remember the exact acronym). The first test run of the swarm of 2000 drones is initially successful, causing the expected rain. But soon, violent, brief storms begin to form in the surrounding areas, accompanied by dramatic drops in temperature, and icy tornadoes. Anyone caught a tornado is instantly frozen. And that’s not the bad science. Read on.

The team brings in Charlie, a former scientist (now a science calamity fiction author) to “think outside the box”. The principal investigator is Joanne. Other scientists include Damon, Gary, and Phil. Here’s the dialogue from the scene, with the worst parts in italics.

What kills me is that it’s not necessary to create such bullshit. Movies are better when they’re more believable, and “science” movies like this have to be on their best behavior when creating their disasters.

Anyway, enough procrastinating. Project time!

Overall, I quite like it. My only other car is a 1995 Acura Integra GS-R that I bought new. It was a basic car, but well engineered, and very fun to drive.

The LEAF is a huge step up in luxury. Much quieter, about a thousand more airbags, computerized, cool. It has a range of about 100 miles, which is fine for my daily commute. It’s smooth, and has excellent fit and finish. The traction motor control is excellent. It has a really cool backup camera that draws lines predicting where you’ll go based on steering angle input. It has an excellent Bluetooth hands-free system, and it can play music directly off my iPhone via A2DP.

The computer systems leave a lot to be desired, though. I don’t think they’re generally any worse than those of other cars, but now that I own one, I see lots of places where they really failed to create a great product. I’ll write an article about that later.

The problem boiled down to the fact that the ChibiOS ARM port (specifically, the ARM7 port, but it’s probably true for most ports) isn’t properly executing the constructors for statically (globally) allocated class objects. To clean up the other post, I moved the troubleshooting material to this post.

Note: I’ve discussed this with the author of ChibiOS, and he hopes to resolve the issue in ChibiOS version 2.3.2.

When any object with a vtable pointer is allocated on the stack (i.e. at run time), it works. But when it is allocated as a global variable, the vtable pointer is NULL. Here’s the test code and output:

As you can see, the constructor isn’t getting called, (and vtable initialization isn’t happening) for the statically-allocated object f, but does get called for object g, allocated on the stack.

This is a GCC issue. It needs to call static ctors (and dtors, theoretically), but it’s failing to do so. It could be a mis-configured build of the toolchain, or a bug in the run-time library, or something else along those lines.

Thoughts While Troubleshooting

It currently fails on ARM (on an AT91SAM7X). The symptom is typical of exceeding the allocated stack space: the processor appears to reset (that is, it re-starts execution from the start of code).

There are two failure modes: in the first, it fails in ThreadEntry(), where the the thread context is cast to a pointer to the BaseThread class, and the virtual entry() method is called, executing the CThread subclass’ implementation. If I remove the call to entry() and just implement some code directly in ThreadEntry(), it works fine.

The second failure mode has to do with what I put in the modified ThreadEntry(). Although it executes, subsequent execution later in the program fails (by failure, it is meant that the processor appears to reset).

At this point, I’m not sure what is wrong. Code seems well-enough aligned, when the GCC .map file is examined. The self/this pointer in ThreadEntry() has the correct value. I’ve tried with very large stacks to ensure I’m not overrunning the stack. I’ve tried a non-template class hierarchy to be sure virtual method dispatch works correctly (it does).

I’m going to try twiddling some outputs on the MCU (instead of calling the stdlib routines I have been). Without JTAG debugging, it’s going to be difficult to figure this out.

I wrote a CThread class (so named to avoid conflict with the OS Thread object) that wraps the allocation of the thread working area and OS thread creation. To do this, CThread is a template class, parameterizing the stack size. Clients subclass CThread and implement the virtual msg_t entry() method.

Note: If you’re looking for the description of what goes wrong when the compiler fails to properly initialize static C++ object instances, I moved that material to a new post, Trouble with Static C++ Constructors in ChibiOS/ARM.

ChibiOS Threads

In ChibiOS, to create a thread, you allocate the thread working area with a macro provided by the OS, and call chThdCreateStatic():

The last parameter to chThdCreateStatic() is passed into the thread’s entry point. We use it later to pass a reference to the thread class.

As soon as chThdCreateStatic() is called, the thread begins executing. ChibiOS provides numerous synchronization primitives, but we won’t get into those here.

CThread Class

The idea with the CThread wrapper is to provide a class to be subclassed to tidy up the creation of a thread. It would be used like this:

And the implementation:

Finally, the thread is allocated as a global (as before), and started:

Considerably tidier, isn’t it?

Pulling this off requires two classes: A non-template BaseThread class that provides the basic thread functionality, and the CThread template class that derives from it. Note that I do this to try to avoid redundant code generation, which can probably be done using partial specialization or a smart compiler, but I wasn’t sure how much luck I would have. The approach does result in a an extra member variable in the base class: the working area size from construction to be used when the thread is started.

BaseThread::entry() should be pure virtual, but I had link errors on AVR with that.

Here’s the complete implementation.

CThread.h:

And the implementation:

What you see above is a little messier than it could be, given a number of issues I ran into while developing it, and concerns about code bloat. But it works reasonably well.

Several months ago I wrote about a problem with a Measurement Specialties barometric pressure sensor. I had come to the conclusion that either the sensor was faulty, or I had damaged it during installation on the board. I kept putting off desoldering it, partly because it’s a challenging part to solder, and partly because I only had two spares, and they’re expensive; I didn’t want it to be faulty.

Well, late last night I got the bug to look at it again. The data sheet shows the calculations that need to be made to get a calibrated result, and shows “typical values” for each of the six factory calibration parameters, uncalibrated pressure and temperature measurements, and each step of the process. It never dawned on me that those values might all be part of one measurement and calculation operation.

So I wrote a small app on the Mac that used the same calculation code that was on the sensor board, but put in the example values instead. Sure enough, the result I got did not match, and I started looking into the intermediate results. I noticed one of those was exactly double the example value, and that got me looking at the implementation of the equation. Looking very closely at the data sheet, I started re-writing the equations. Turns out, the code I had found on their site was incorrect, and the code I wrote based solely on the data sheet worked correctly.

For reference, here is C/C++ code that works. mC1 through mC6 are the calibration parameters from the device ROM. mRawTemperature and mRawPressure are the raw sensor readings. mTemperature and mPressure are the final, calibrated result. Temperature is in degrees Celcius * 100, so you have to divide the result by 100 to get the temperature. Pressure is in millibars * 100, so do a similar division to get mb.

This sensor should prove to be very accurate, and will give us the balloon’s pressure altitude, as well as the temperature inside the insulated payload box. It’s only real drawback is a lower pressure limit of 10 mbar, corresponding to an altitude of about 26 km (~85 kft). We’re hoping to go past 30 km (~100 kft). Hopefully the GPS will be a good backup.

The problem with this idea is that it requires the second to be redefined. To be sure, there are other problems, too, like how do you convince six billion people to change their notion of what seconds, minutes, and hours are?

But changing the length of a second means changing a lot of scientific constants, and that’s a pretty serious undertaking. It would be better to start with the existing unit of a second (which, incidentally, is a metric unit), and build on top of that.

So, let’s put aside the actual labels we’ll give each of these units, and let’s keep a second a second. Now let’s put 100 seconds in a minute, 100 minutes in an hour, and that gives us 8.64 hours in a day. That’s not a very nice, round number. How important is it that it be a “nice” number, though?

On Earth, the average day is 86,400 seconds long. On Mars, the average day (sol) is 88,775 seconds. In our decimal time units, that would be 8.86 hours. On Earth’s moon, a day is 2,551,443 seconds long, or 255.1 hours (are you starting to see the advantage of decimal time?). Obviously, as our species spreads out to other celestial bodies, having an even number of hours in the day everywhere will impossible, because not all days will be the same duration.

So, let’s compare some other durations:

Yuck! The problem with decimal time based on the existing second is that there are no conveniently-sized units for most day-to-day human activity.

The quarter-hour, or 15 minutes, is 900 seconds. That’s nearly 1000 seconds, so perhaps the kilosecond would be a convenient unit. Ten kiloseconds would be a little over 2 h 45 m traditional, so maybe we’re on to something here.

I’ve rounded the kilosecond times for the activities, because their durations aren’t very precise to begin with. It seems like the kilosecond could be a fairly convenient unit, after all.

Now we just need to find good names for these decimal units. Seconds are fine, but the rest need new names that are easy to say, abbreviate acceptably to unit labels, and don’t sound cheesy (the old Battlestar Galactica used “centons,” and I never did figure out how much time that represented).

We might also ponder how one writes decimal time. Traditionally, in the U.S. and other parts of the world (but definitely not all!), a time of day (or duration) is written as double-digit numerals separated by colons: 12:37:58. Decimal time can be written much more simply, as decimal hours in the day: 4.548. Now, imagine you want to add (in traditional units) 4 minutes and 22 seconds to 12:37:58. Try it. It sucks. But adding 262 seconds to 4.548 decimal hours is much easier: 4.548 h + 0.0262 h = 4.574 h.

It may seem weird, but if you grow up with these units, and everything around you uses them, they’d be obvious, and the units we use today would seem strange.

Sources

Metric time. (2011, February 17). In Wikipedia, The Free Encyclopedia. Retrieved 05:51, March 27, 2011, from http://en.wikipedia.org/w/index.php?title=Metric_time&oldid=414432996

Timekeeping on Mars. (2011, January 15). In Wikipedia, The Free Encyclopedia. Retrieved 05:52, March 27, 2011, from http://en.wikipedia.org/w/index.php?title=Timekeeping_on_Mars&oldid=408111863.

Lunar day. (2011, March 17). In Wikipedia, The Free Encyclopedia. Retrieved 05:53, March 27, 2011, from http://en.wikipedia.org/w/index.php?title=Lunar_day&oldid=419235268.