Saturday, September 3, 2016

Becoming an Embedded Programmer

Some people want to be embedded software engineers. Not everyone is cut out for doing web pages, an making the page a little more blue (it happened to me when I was confused, early 2000's). No, some people like to get data in the raw, and make it something that people will use.

I've been hiring for the company I work for, doing interviews for the last year. It has been tough sledding trying to find young people out of school, and people with years of experience to understand what embedded systems can be. Some think, raw hardware, no operating system. Some others think once you have the OS, why not make it all web based. Others don't want to do Linux, and think the system ought to be Windows based.

The company I work for writes software for a Linux based embedded system. Most of the projects are reading data from some hardware device, quickly transforming it, and maybe jamming it back into another hardware device, or writing he values to a hard disk, or NVRAM. Data synchronization is paramount, it doesn't work to get something a few seconds from now mixed up with data that is happening now. Sometimes we need to keep two input sources in sync (IE audio and video), so two threads need to know when to start and finish.

Getting a Rasberry Pi or something similar (IE Orange Pi) is a great start. For the cost of a couple cups of coffee (or only one, depending on where you buy things) you can get an embedded system. The Pi systems are Linux based, and allow writing code right on the device. The Pi's also allow developing on desktop systems, cross compiling for the hardware.

One thing the Pi's all seem to have is rich AV capabilities. All seem to have HDMI out, along with audio in and out. Many folks use the Pi systems as desktop systems, all on their own. Most of a Linux system is available, including X windows, and desktop type programs (word processors, spreadsheets and browsers).

As a developer, play with one of these Pi systems, and use it as a data collector system. Go ahead, connect something to the GPIO pins. It could be an LM34 chip measure the temperature of the garage or something. Fire up a web server an built some Perl or Python to display he last 36 hours of temperature. Tada, you have become an embedded programmer.

Examples... Well give me a couple days. Do you want to collect the stuff you need? There is a service called Hackerboxes that will send you random projects every month to build. For September 2016, they have an OrangePi kit. I am downloading a desktop image while typing this in. Compressed the desktop is 540MB.

Keeping thing in sync, use mutexes and semaphores. If you don't know what they are, read on the web. They are a great tool to allow multiple threads to stay in sync, and keep the data correct and useful. If you code in Java, read about wait and notify Java.lang.object. If you use C or Perl look at posix threads.

It is cheap, and you can be an embedded programmer in no time.

Sunday, February 7, 2016

What Could Have Been

Radio Shack is no more. I am both sad, and not surprised. I got my start with Radio Shack components, 80 in One kits, and Forest Mims books. I relied on Radio Shack for resistors, and my introduction to Integrated Circuits. They didn't have everything, but they had most of what I needed through college building computers and robots. If I needed some wire, or a 15k 1/4watt resistor at 8pm on a Thursday, Radio Shack was the answer.

Tandy wire and cable made some wonderful coax and other wire. The RG-58 was really nice, and available both with a braided center core and with a solid center core. Of course they sold connectors to go with it. Asking a clerk for help, they happily would cut custom lengths, or suggest pre-made cables.

Somewhere along they way, Radio Shack changed. After college many things were in flux. The computers that people built at home were no longer chips (yes, Radio Shack sold 8085, and 8080 CPU's plus others), but were boards. PC's that people built were now plug together boards. Radio Shack only sold some expansion boards, and pre-assembled computers.

Radios changed as well. Fewer and fewer people were buying component stereos, and self installing car stereos. I am sure the sales at Radio Shack declined during the late 80s and early 90s. To compensate, Radio Shack expanded into television sales, and other consumer electronics. Eventually Radio Shack was getting heavily into the cell phone sales for all the carriers.

Expansion of the consumer electronics area caused the reduction in the component floor space. The clerks didn't want to waste their time selling 10uf capacitors when a customer wanted a new cell phone. The knowledge of the staff was on the decline. I've heard stories about EE students that wanted to work at Radio Shack were actively discouraged because they might spend too much time helping with components.

The last couple of years, the president of Radio Shack was really making an effort to "fix" the decline of the brand. There were engagements with hackaday and other hobbiest web communities, The communities were slightly hostile, but most of the ideas were too little too late. The brand was bought by Sprint in 2015, and most of the stores have closed.

What Could Radio Shack Have Been?

I've been going to Micro Center for a bunch of years. They mostly were the place to get reasonably priced PC's. They had all the accessories, boards, power supplies cases, and cables. Their prices are good, for a retail operation. They had a closeout section that often had some amazing deals.

PC prices have plunged. When a PC or laptop used to cost $1000-1500 in the early 2000's, now a modern PC or laptop only cost $300-500. The gaming systems are not making as much money, it seems, and the book sales are almost non-existent. The shelves are still full of accessory boards, CPU's cases and power supplies.

Micro Center has expanded into the hobby space. They have a very large selection of Arduino boards and accessories. The Rasberry Pi selection is equally full. The prices are as good as mail order as well. At Christmas time, they had Rasberry Pi Zero boards for $5, but were sold out quickly. The aisles were full when I went there yesterday. I don't have any insight to the income this is generating, but people are buying the the hobby electronics, and I will continue to.

What if Radio Shack had followed the hobbyist trends? Well Radio Shack did sell Arduino boards toward the end. The prices were very high (I think I remember looking at an Uno for about $24). It was something I couldn't justify. What if they had kept the prices better? With the mall space rent as high as it is, they might have gone out of business sooner. Hard to say.

Do you think, if Radio Shack had done a better job with hobby electronics, they'd still be around?

Sunday, January 17, 2016

Something Similar

My ideas are not unique. Someone else built an engine monitor using some hardware and an Android tablet. The engine monitor box is built by Skylab, and is called a Flybox. The app is in the playstore called Aircraft Instrument Panel.

It is more for ultralights, microlights and LSA's that have only a two cylinder motor. It has:

  • Airspeed (pitot)
  • Altitude (Barometric)
  • Vertical speed (calculated from barometric altitude change)
  • Engine RPM
  • Oil Pressure
  • 2 CHT
  • 2 EGT
  • Oil and Water temperature
  • Fuel computer
  • Battery voltage
  • Total flight hours

It would be nice if the 2 EGT's could be converted to 2 more CHT's (and maybe it can, I haven't looked yet). I posted a question on their facebook page. 

It looks based on their facebook page, they allow other users to help develop this system. Fly is fun is integrating with them as well. It shows at least for now there is a vibrant community around this system. 

Thursday, January 7, 2016

ADS-B compliance, You Can Get a Loan For That

Do your homework, but sure, you can get a loan to install ADS-B right now. Congress just passed a bill that will allow government guarantees on loans for money used in GA ADS-B upgrades. The scheme er plan is called "NextGen GA Fund". The idea is, if you don't have the cash now to upgrade your airplane, just borrow some, and you will be ADS-B compliant sooner rather than later.

Just for fun, I filled out the application. It took maybe 10 minutes, and today I got a note showing I was approved! I can get a loan for $10,000 to equip my Cozy with some new avionics. What would $10,000 cover? Well it wasn't a total magic number. I've been thinking of the MGL smart panels since I started building my airplane. The 8.5" iEFIS would be a wonderful thing to replace the 6 pack in my airplane.

iEFIS Explorer

Their web page says $6000 for the main package, including engine monitor, attitude heading reference and their encoder output box for the transponder. To make this ADS-B out compliant I still need either a UAT or a Mode-S transponder. I'll choose the UAT, since I got this cool display that will allow me to see traffic and weather. The NavWorx for experimentals box was about $700 a year ago, but today it is $1300, which isn't horrible still. That would leave me about $2500 still to go. The MGL panel has remote com and transponder capabilities, and MGL sells com radios and transponders that would connect to that as well, for about $2500 (well $1050 for a com, and $1550 for a transponder). Not bad for $10000.

That upgrade would make my plane pretty sweet. Go fast, ready for the future, and still only have to pay about $320/month.  None of this pricing includes the wiring that would have to go in, or the installation. The installation in my plane, since I am the manufacturer, can be done by me. I can charge myself 50cents an hour if I want. I don't want to be all polly-anna but I could do a lot with ten grand.

If you have a certified plane, I am guessing something similar would be about $30,000, since installation wouldn't be free, and certified equipment would need to be purchased.

(this is where I want to put in a record scratch sound)

Wait a minute, 300 a month for 36 months, that is $10,800. I don't need to put in these avionics yet, I got almost 4 years to go. What if I put away 300 a month for 3 years and wait to see what is available then. I should also look into what I can get a load from my bank for. Probably at better or equal terms than these folks are offering.

There is nothing wrong with waiting 3 years. If it doesn't take a whole year to install all this, my plane will still be compliant in 2020. Avionics are getting better, and cheaper every year. Surely something will break loose and this whole mess will be affordable.

(If you don't know much about paying for airplanes, some airplanes can be bought for under $20,000. Putting $10,000 into an instrument panel for a $20,000 airplane won't increase he value of the aircraft much, certainly not $10K. It is a bad investment. My airplane cost a little more than $20K to build maybe twice that much, even still $10K in the panel won't help the value too much. If I did this it would be for my pleasure. Affordable is still relative, but airplane owners are not all rich people.)

I am sure there are some bankers and others who think this is needed. To me it is some PAC wasting congresses time. The could be working on PBOR2 or funding the FAA or something useful. More and more the congress get the prize for doing something, but not anything useful. (sorry about going political).

Friday, November 27, 2015

Time To Give Up on 8 Bits?

While we were sleeping in, Thanksgiving in the US, the Raspberry Pi folks released a new Pi. The Pi Zero is only $5. This is an amazing board, with 32bits of CPU, 512K of RAM and all the ports people would like, GPIO, HDMI and USB. It supports micro-sd for mass storage.

While the Arduino eco-system is in great shape, is there a reason to stick with an 8 bit CPU for most projects? The Uno and other boards start at over $25. Sure, you can get the boards cheaper on eBay and other Chinese importers.

The Arduino boards are perfect for many projects. If there is a simple input and output situation the Arduino is perfect for these situations. My garage door project is an example. The Bluetooth input, and the relay output makes the Arduino the simple interface.

There are other boards similar to the Rasberry Pi. The C.H.I.P is a $9 computer that has all the same IO as the Raspberry PI, but also has WiFi and Bluetooth built in. The C.H.I.P is still pre-order, but should be available soon.

The big deal with the 32bit processors like the Raspberry PI is it runs Linux (or Windows). That means development can happen on the board or cross compiled (more than likely cross compiled). It also means there are many debug tools available from GDB and tcpdump to a ssh console. The 32bit processors run quicker so other inputs (IE video) are more capable.

I've been planning on putting a 32bit board (waiting for my C.H.I.P) on my robot all fall. The robot will have an Arduino on it for sensor monitoring and motor control. The goal is the two processors will talk to each other and allow the 32bit processor handle thing at a high level, where the Arduino will be doing all the low level work.The 32bit chip can also run R.O.S.

There is a place for 8 bit processors, but more and more it is easy to pass them by.

Tuesday, November 17, 2015

Form Over Function

I know I have railed against this before, but it seems to be getting worse. My examples are Android specific in this blog, not because they are the worst, but because I am most familiar with these apps. Microsoft has and continues to do it, along with Apple and most other software companies. Putting the looks of an app ahead of it's functionality is a disservice to the users.

There certainly is a place for consistent user interfaces. It is really nice that most apps have a file menu, edit menu and view and ... usually ending with help. It makes switching between apps pretty straight forward. Then Microsoft went to the "Ribbon" look and took all that away.  Some people say it improved their productivity, and I might argue it does, for the people who stick to a few apps. Most people though, use multiple apps all day doing this or that.

I am a long time Emacs user. Forever and ever people have been telling me that it is hard to learn, so they stick to whatever editor they like. Right, Emacs is really hard to learn, but after 20 years, I know it too well, and can't teach it. All the commands are muscle memory, I usually don't even know what keys I am pressing. The keys are grouped, so there is consistency when going from one group to another. I am really fast at using emacs, and I credit that for giving me the edge when I get work done quicker than others might.

The trouble comes when people take perfectly fine apps and try to apply another paradigm to them. Microsoft did it with the ribbon. I am sure it helps people who use Word all day long, but for people who switch between Word and Project and Acrobat, it is frustrating. Occasional users will find unfamiliar UIs confusing no matter how hard people say they are easier. Windows 8 might have been a fine UI if it was the first UI anyone had tried to use. People who had been using every other UI since about 1980 will find Windows 8 home screen jarring.

In the last year or two Android has tried to get all apps to use the Material Design concept. Apps that were working fine in their own look and feel are suddenly changing to the new Material design look. The look I don't much care for, but also the functions that an app may have had are suddenly gone. Sometimes it is spacing, sometimes it is a misinterpretation of the design language, sometimes it is some unknown reason.

A perfect example of this was the Google Calendar. It was a really nice app, and then is got "Materialed". In the first iteration, there was no longer a month view, and weeks were chopped off at 5 days. They added a summary view, where the appointments that are happening soonest would show in a list. The summary view is common in some calendars, so this was a nice addition. Missing the weekends or the month view was really frustrating. Eventually weeks became 7 days, and months could be viewed, but by then I and many others had switched to Sunshine calendar or aCalendar and never looked back. It damaged Google's reputation.

Android developers are encouraged to make their apps follow the Material design language. This guide changes occasionally, so tracking the latest guidelines can add work for a small time developer. Some of the guidelines aren't clear, or there are questions how some guidance applies to a certain paradigm. One app may feel the guidance says do function X this way, where a competitor feels the guidance says to the same function another way.

I find the floating buttons are in the way many times. The circle + in gmail is in the way more often than I care for. I find other apps that use floating buttons are equally in the way. There are ways to do things different, but the Material design guidance doesn't mention them.

Colors and Such

There are many studies on Human Computer Interaction (HCI) that offer clear recommendations on color. Many apps are getting it wrong, but people claim the apps are "beautiful". Again, there are ways to make an app "beautiful" and functional.  The Material design guide follows most of the HCI recommendations, but the words do not.

A big thing is I've been told forever in UI design is avoid saturated colors. Back in the early days with 8 and 16 bit screens, the colors were limited. There were only a handful of colors, and to convey information, they needed to be done as best we could. Sometimes older interfaces look primitive or cartoon like. With fewer colors, the choice included many saturated colors. Today, we have millions of colors to choose from, and we can convey more information using more of them.

What is a "saturated" color, and why should they be avoided?

Looking at a color wheel, the saturated colors are the ones on the outside.
Looking at the wheel from farther away, the eye can see little triangles at the numbers. The colors are different through these triangles. The colors are indistinguishable when placed near each other. Placing a color in the 6 area next to a color in the 3 will certainly contrast, but that would be very jarring. Moving in from the edge a little, maybe 20% of the way in from the edge, the colors are less saturated, and the colors are more distinguishable. Selecting 2 greens in this area will likely be visible to the eye, and allow the users to distinguish between information presented using these colors.

There are theories about how to mix colors, using complementary and analogous colors. Following these theories can prevent users from feeling their eyes are assaulted. There are ways to use colors to set moods and to convey a sense of importance to information.  

There are tools on the web for selecting colors to provide the right look. Many of the tools will put the basics there, and offer the chance to blend them to get the unique look desired. 

Changing UIs

The best way to change what users like is to do it gradually. Never remove a feature. Emacs is a great example. Moden Emacs UI's include the familiar File menu, Edit Menu, ... ending with help. All the keyboard commands still work, and I can turn off the tool bar to get more edit space on my screen. All of the macros are available, and there are more, some I discover new. Adding functions is a good thing, but don't force the users to use them. The users know their tool/app and use it their way, maybe not the way it was designed, but certainly in a way that suits them 

The user looks at an application as a tool. They have a problem and they need a solution. If your tool doesn't meet their needs, they will find another tool that does suit it. Maybe Excel wasn't intended to be a word processor, but some people will insist on using it to edit blocks of text. Let the user find the tool that suits them.

What is your favorite tool that someone has destroyed making it "better"?

Monday, August 31, 2015

Arduino Annunciator Panel

When I built my airplane, I installed switches to monitor the critical items like gear position, canopy and landing brake. I always intended to build an annunciator panel, but was unhappy with the plans design.
Building a flexible annunciator panel can be very complex. If the panel is to handle various inputs for multiple displays (IE throttle position for spoilers and gear warning) sometimes the wiring will
require diodes, and other schemes to keep the warnings coherent.

Adding a simple processor in the middle may make many complex systems easier. While in the past microprocessors were quite complex to install and program. For the hobbyist market there are many choices to make adding a processor to any system easier. One of the most basic hobbyist processor boards available is the Aurduino.  


In the Cozy as in most aircraft, there are certain situations the pilot must try to avoid to get the best performance out of the aircraft. The nose gear should be extended before landing, the canopy should be latched before taking off, and the landing brake (spoiler) should be retracted before adding power to the engine. There are 4 sensors that will be used in this panel, the throttle position, the gear up, the landing brake up and the canopy latched switches.

The Cozy plans suggest putting in a microswitch in for the throttle position. This is one way to do it, but using the Arduino, a potentiometer can be used to get both the throttle open and throttle
closed indications, as well as anything in between. The microswitches are used for the other sensors because they allow less exact mounting than any other switch. The plans make no provision for a landing brake sensor, because the plans have a manual landing brake and the actuator handle is an obvious indicator.

When my Cozy was built, all the switches were installed, and the wiring for the switches was run to a barrier strip near the panel. The barrier strip allows changing what is on either side without drastically affecting the opposite side. Replacing the plans circuit with a microprocessor based system is easily done.
There will be two main alarms, both a bright LED and an audio alarm will be available. Human factors research has shown a dark cockpit will allow the most use out of annunciator panel. The panel will be dark and quiet until the pilot needs to handle something. There will be individual indicators of what system is not normal, besides the master warning.
A push button is added to the annunciator panel to quiet the alarm for a period of time. I've chosen 5 seconds for the silence time. Sometimes  during testing and maneuvering, the aircraft will be in a configuration where an alarm may display, but the pilot is OK with the situation. Silencing the alarm will be OK, the master alarm light will continue to display.

When wiring sensors sometimes it seems like a good idea to run power to the switches causing them to switch 12 or 24V on to the panel, but this adds complexity. Any power run through the aircraft should be fused. When wiring switches to a microprocessor it is best to have the switches control a ground signal. The processor can have a local  voltage on board, that will be switched off when the switch closes to  ground. In a metal aircraft where the fuselage is ground, switching  grounds can simplify the wiring since the ground wires will not have to be run to the switch.

Using software to light indicators will allow the greatest flexibility. The software can monitor individual pins of input and react by changing the state on other pins. The inputs can be combined to provide the most accurate output.
The Arduino has many inputs. Looking at the schematic, all the switches are connected to digital inputs, and the potentiometer is connected to an analog input. The potentiometer is like a volume
control, not set to any particular voltage, so it will measure the voltage at the time it is read (many times a second).

There will need to be a dedicated 12V power supplied to the processor from the aircraft. It will probably be best to dedicate a 1A fuse to this circuit to protect the wires leading to the processor. Nothing on the board will require more than about 1amp of power.

The wires to the switches can be very light. Simple 22-30 gauge wire will work fine, keep the weight down and be easier to work with. Give the wires some slack near the switches in case the switches come loose, to minimize wire breakage.

The throttle position indicator can be either near the carburetor or near the throttle knob. It must be mounted and actuated in such a way as to not interfere with the throttle setting, if something comes loose. For my aircraft, I mounted it near the instrument panel connected to the throttle knob using a small piece of music wire from the hobby store.

The indicators are simple Light Emitting Diodes (LEDs). LEDs in many ways act like light bulbs, but have a couple critical differences. Lightbulbs can be connected to the power source either way, and they will light. LEDs have to be connected such that the power will flow the the proper direction, connecting them backwards won't damage them, but they won't light up. The other difference, LEDs must be current limited, without that, the LEDs will send too much current through and be very bright for a brief period of time, and never light again. The current limiter is a simple resistor, and for this project we will use a 1000ohm (brown-black-red) resistor.

The audio alert could be the same one from the plans. I chose a Soberton Inc WST-1205S buzzer available from Digi-Key. These buzzers are small, but are very loud.

I built a fixture to do the development of this system. The airplane is a short drive away, but it is cold working in the hangar, so I have this fixture with all the switches, knobs, audio alert and LEDs. The orientation is similar to the aircraft, and I have the switches and LEDs labeled.

Programming an Arduino is done on a laptop or desktop computer. The Integrated Development Environment (IDE) allows the programs to be entered in a C or Java like language, and saved on the disk. An earlier post, I did an intro to Arduino programming. The programs are loaded on the processor using a USB jack. Once loaded on the Arduino, the program will run every time power is added to the processor. Removing the power will not erase the processors memory.

Arduino programs are called sketches. The IDE supports building sketches that can be loaded from the disk, edited and compiled for loading on the processor. The microprocessor on the Arduino board doesn't read the text of the sketch. Compiling the text in the IDE converts the text of the sketch into the bytes the processor will use as instructions to do what the sketch says to do.
The program for this annunciator panel is straight forward. The setup function sets all the input and output pins as they need to be. The digital inputs are the pins where the switches are connected and the digital output are the pins where the LEDs are connected. The names
assigned to the pins are convenient for people reading the program, the computer really doesn't care what names are assigned.

void setup(){
 //configure input pins as an input and enable the internal pull-up resistor
 // configure output pins for output.
 pinMode(LB_IND, OUTPUT);

The loop part of the sketch will read the switches and throttle position sensor. The loop function will call the display function to compare the settings and try to set the lights to the appropriate values. The green lights will indicate the "out of normal" device. Gear down, landing brake and canopy open are out of normal for cruise flight.

* Read all the switches and call the display function
void loop(){
 //read the switch value into a variable
 int gearVal = digitalRead(GEAR_SW);
 int canopyVal = digitalRead(CANOPY_SW);
 int landBrakeVal = digitalRead(LB_SW);
 int silenceVal = digitalRead(SILENCE_SW);
 int throttleVal = analogRead(THROTTLE_IN);
  display(gearVal, canopyVal, landBrakeVal, throttleVal, silenceVal);

The Master Warning will happen using some more involved logic. When the gear switch is up, and the throttle position is closed, the alarm state is set.  When the Throttle position is set to takeoff power and the landing brake is down or the canopy is open the alarm state is set.

* check the logic to see if there is a master warning to display
* returns 1 if the master warning should be set.
int isAlertState(int gearVal, int canopyVal, int lbVal, int throttleVal)
 int alert = 0;
 // throttle closed, and landing gear up
 if ((throttleVal <= THROTTLE_CLOSED) && (!gearVal)) {
   alert = 1;
 // throttle max and canopy not closed, and landing brake not up
 if ((throttleVal >= THROTTLE_MAX) && (canopyVal) && (lbVal)) {
   alert = 1;
return alert;

The display function will set the green LEDs indicating the current "out of normal" setting. The isAlertState is called to see if the master warning should be turned on. Some logic is called to cause the buzzer to sound. The buzzer is modulated to make a more obnoxious sound. The logic for the silence uses the time library. The code will check what time the buzzer will stop
sounding when the silence button is pressed. When the silence button was released the silencedAt value will be set. When 5 seconds have elapsed beyond the silencedAt time, the buzzer will continue.

* Process all the logic, to allow displaying LEDs in proper state, and
* handle master alarm state, including sound.
void display(int gearVal, int canopyVal, int lbVal, int throttleVal, int silenceVal)
 int alert = 0;
 // gap is the cycle time for the tone. state is the tone state.
 static int gap=0;
 static int state=LOW;
 // silenced at is the time the alarm was silenced at.
 static time_t silencedAt=0;
  // Keep in mind the pullup means the pushbutton's
 // logic is inverted. It goes HIGH when it's open,
 // and LOW when it's pressed.:
 digitalWrite(GEAR_IND, gearVal);
 digitalWrite(CANOPY_IND, canopyVal);
 digitalWrite(LB_IND, lbVal);
 // The silence button is open normally. Logic is reversed.
 if (!silenceVal) {
   silencedAt = now();
 alert = isAlertState(gearVal, canopyVal, lbVal, throttleVal);
 // output the master alarm status
 if (alert) {
   digitalWrite(MASTER_IND, HIGH);
   // generate a tone
   if (gap++ == 4) {
     state = !state;
     gap = 0;
   if (now() > silencedAt + 5) {
     digitalWrite(ALARM_OUT, state);
 } else {
   digitalWrite(MASTER_IND, LOW);
   digitalWrite(ALARM_OUT, LOW);

The logic for the master warning is in its own functions. The logic can be minimized to make debugging easier. The state setting is separate from the alert indications.

Various testing schemes can be added if desired. Calling specific functions in specific order allows testing only the landing brake or the gear warning systems as needed to insure the system is working as desired.

With the system installed, the aircraft is much safer. You should continue to use your checklist, this is only designed to help if you forget. Using the Arduino, allows a more flexible system. There is plenty of expansion  in the software, and plenty of pins available to make an even more flexible system.