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.  

ArduinoArtCircuit.png

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
 pinMode(GEAR_SW, INPUT_PULLUP);
 pinMode(CANOPY_SW, INPUT_PULLUP);
 pinMode(LB_SW, INPUT_PULLUP);
 
 pinMode(SILENCE_SW, INPUT_PULLUP);
 
 // configure output pins for output.
 pinMode(ALARM_OUT, OUTPUT);
 
 pinMode(GEAR_IND, OUTPUT);
 pinMode(CANOPY_IND, OUTPUT);
 pinMode(LB_IND, OUTPUT);
 pinMode(MASTER_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.

(This article with changes ended up in Kitplanes Magazine)

Thursday, August 13, 2015

Garage Project Update

I completed this a couple months ago. I just didn't get to posting it. Check out the other posting if you want to know what this is updating.  Of course, I updated the GUI, so it isn't just "Big Door", "Little Door" and made the app a little more robust. It remembers the last Bluetooth device, so pairing is a little more automatic. The change to the GUI allows users to click on the door they want open, and it opens. Someday, I may put in sensors so the GUI could show the current state of the doors (so when I go to bed, I can look, and know if I left any doors open). The app inventor project is at this link.



 I re-did the wiring in the garage as well. I used to have a spiderweb in the ceiling with droopy wires from the access door to the openers. Who ever installed the openers or the wiring must have run out of staples, and there were like 3 for the two openers. Now all the wiring goes through the attic, with the central wiring on a barrier strip.

The sketch I didn't change, but I noticed I didn't upload that either. I'll give that a go as well. The sketch isn't doing anything really complex. It is still based on ardudroid.


/*
 PROJECT: Garage 
 PROGRAMMER: T Brusehaver
 DATE: May 31, 2015
 FILE: garage.ino
 LICENSE: Public domain
*/

#define START_CMD_CHAR '*'
#define END_CMD_CHAR '#'
#define DIV_CMD_CHAR '|'
#define CMD_DIGITALWRITE 10
#define CMD_ANALOGWRITE 11
#define CMD_TEXT 12
#define CMD_READ_ARDUDROID 13
#define MAX_COMMAND 20  // max command number code. used for error checking.
#define MIN_COMMAND 10  // minimum command number code. used for error checking. 
#define IN_STRING_LENGHT 40
#define MAX_ANALOGWRITE 255
#define PIN_HIGH 3
#define PIN_LOW 2

String inText;

void setup() {
  Serial.begin(9600);
  Serial.println("Garage By T. Brusehaver (2015)");
  Serial.flush();
}

void loop()
{
  Serial.flush();
  int ard_command = 0;
  int pin_num = 0;
  int pin_value = 0;

  char get_char = ' ';  //read serial

  // wait for incoming data
  if (Serial.available() < 1) return; // if serial empty, return to loop().

  // parse incoming command start flag 
  get_char = Serial.read();
  if (get_char != START_CMD_CHAR) return; // if no command start flag, return to loop().

  // parse incoming command type
  ard_command = Serial.parseInt(); // read the command
  
  // parse incoming pin# and value  
  pin_num = Serial.parseInt(); // read the pin
  pin_value = Serial.parseInt();  // read the value
  
  Serial.print("Ard_command ");
  Serial.print(ard_command);
  Serial.print("  Pin=");
  Serial.print(pin_num);
  Serial.print("  Val=");
  Serial.println(pin_value);

  // 1) GET TEXT COMMAND FROM ARDUDROID
  if (ard_command == CMD_TEXT){   
    inText =""; //clears variable for new input   
    while (Serial.available())  {
      char c = Serial.read();  //gets one byte from serial buffer
      delay(5);
      if (c == END_CMD_CHAR) { // if we the complete string has been read
        // add your code here
        break;
      }              
      else {
        if (c !=  DIV_CMD_CHAR) {
          inText += c; 
          delay(5);
        }
      }
    }
  }

  // 2) GET digitalWrite DATA FROM ARDUDROID
  if (ard_command == CMD_DIGITALWRITE){  
    if (pin_value == PIN_LOW) pin_value = LOW;
    else if (pin_value == PIN_HIGH) pin_value = HIGH;
    else return; // error in pin value. return. 
    set_digitalwrite( pin_num,  pin_value);  // Uncomment this function if you wish to use 
    return;  // return from start of loop()
  }

  // 3) GET analogWrite DATA FROM ARDUDROID
  if (ard_command == CMD_ANALOGWRITE) {  
    analogWrite(  pin_num, pin_value ); 
    // add your code here
    return;  // Done. return to loop();
  }

  // 4) SEND DATA TO ARDUDROID
  if (ard_command == CMD_READ_ARDUDROID) { 
    // char send_to_android[] = "Place your text here." ;
    // Serial.println(send_to_android);   // Example: Sending text
    Serial.print(" Analog 0 = "); 
    Serial.println(analogRead(A0));  // Example: Read and send Analog pin value to Arduino
    return;  // Done. return to loop();
  }
}

// 2a) select the requested pin# for DigitalWrite action
void set_digitalwrite(int pin_num, int pin_value)
{
  switch (pin_num) {
  case 13:
    pinMode(13, OUTPUT);
    digitalWrite(13, pin_value);  
    // add your code here      
    break;
  case 12:
    pinMode(12, OUTPUT);
    digitalWrite(12, pin_value);   
    // add your code here       
    break;
  case 11:
    pinMode(11, OUTPUT);
    digitalWrite(11, pin_value);         
    // add your code here 
    break;
  case 10:
    pinMode(10, OUTPUT);
    digitalWrite(10, pin_value);         
    // add your code here 
    break;
  case 9:
    pinMode(9, OUTPUT);
    digitalWrite(9, pin_value);         
    // add your code here 
    break;
  case 8:
    pinMode(8, OUTPUT);
    //digitalWrite(8, pin_value);
    // add your code here 
    digitalWrite(8, HIGH);   // sets the LED on
    delay(1000);                  // waits for a second
    digitalWrite(8, LOW);    // sets the LED off
    break;
  case 7:
    pinMode(7, OUTPUT);
    //digitalWrite(7, pin_value);         
    // add your code here 
    digitalWrite(7, HIGH);   // sets the LED on
    delay(1000);                  // waits for a second
    digitalWrite(7, LOW);    // sets the LED off
    break;
  case 6:
    pinMode(6, OUTPUT);
    digitalWrite(6, pin_value);         
    // add your code here 
    break;
  case 5:
    pinMode(5, OUTPUT);
    digitalWrite(5, pin_value); 
    // add your code here       
    break;
  case 4:
    pinMode(4, OUTPUT);
    digitalWrite(4, pin_value);         
    // add your code here 
    break;
  case 3:
    pinMode(3, OUTPUT);
    digitalWrite(3, pin_value);         
    // add your code here 
    break;
  case 2:
    pinMode(2, OUTPUT);
    digitalWrite(2, pin_value); 
    // add your code here       
    break;      
    // default: 
    // if nothing else matches, do the default
    // default is optional
  } 
}

The relays are connected to the Arduino using an NPN transistor. One relay each on pins 7 and 8. The power supply is my old Motorola Razr charger (mini USB). The HC05 is connected using the TX and RX serial pins, so they need to be disconnected if connecting to the USB port to program the Arduino. Also Have a look at the Ardudriod page for the resistors and 3.3V connection. (Don't try 5V and don't forget the resistor on the RX pin). Remember the module is receiving on RX but sending to the TX pin.

There have been a few things I don't like about it, but overall it is serving it's purpose. Pairing basic HC05 modules with and Arduino isn't as quick or automatic as I'd like it to be. Of course, sometimes the signal is going through an aluminium door on the way to the module, so I can't blame anything but circumstances.

If you are thinking of trying this yourself, I recommend it. If nothing else, this is a good place to start.



Sunday, May 31, 2015

More Garage Stuff

I was once distracted by a silly garage project. Then I moved, and now I have another garage project. This one is similar to the Engine Monitor I keep promising to build. Heck this whole project is about me learning, and sharing those lessons so others may benefit from them.


I have a house with a 3 car garage. It isn't huge, there are two doors, one small, and one large. I know on the large side we can't put our two cars in, and open the car doors. There are still two doors, each with their own openers. The remote controls in the cars work great, but you need two, if you want to open both doors. Yes, I know they sell learning controls that will open both, but what about when you just want to open the door when not in the car? I have tools and such in the garage, and sometimes I need something, and the car may be in the garage.

I always have my phone in my pocket. Is there a way to have the phone talk to the opener? Not the stock openers, only a special opener. Well I have a bunch of Arduino stuff, and a phone that talks bluetooth, can they be connected? Well, sure they can. Again I experimented using the ArduDroid an Arduino Mega and a Bluetooth shield. Nothing to it, that all worked great. Then I moved on to a 6 pin HC-05 module and the mega, and that worked as well. The HC-05 isn't any bigger than a Arduino Nano, so I tried that. That worked as well.

Once I had all the Arduino hardware working, it was time to do something quick with the Android. The ArduDriod has an OK interface, but I wanted something that looked like it belong. I didn't want to do a full blown app, so I looked at my options. I ended up choosing App Inventor. It is probably as much work as writing an app, since I had a lot to learn, but I was able to learn the app inventor and as a result I have an app that will open and close the garage.


There are 3 buttons and a label. The buttons cause the relay corresponding to the door labeled to close for about a second. I have the project available if anyone would want it. It was done using app inventor 2. The protocol stillis the ArduDroid protocol, so I had a sketch I could start with.

If you want to try it, let me know, I'll share what I have.



Sunday, April 26, 2015

Google ADS/B

There are reports that Google will be building a UAT that will be low cost. At first one might think, why would google be building something like that for aircraft. Google wants to do drones like Amazon. Maybe for deliveries, maybe something else. To get any aircraft in the Class B or C airspace where the drones would operate, they would need to be ADS/B capable, just like all other aircraft.

The articles specifically mention ADS/B out. This would make sense for selling to other aircraft. For use on a UAS or Drone, the only thing that makes sense if ADS/B in and out. How else will the UAS determine where the other aircraft is. Out will tell the other aircraft (and ATC). In will tell the drone where the other aircraft are.

If someone can put together a low cost ADS/B system it would be Google. They have the engineering teams to do it, and the bank account to fund the development. UAS systems, are smaller than manned aircraft, so the ADS/B radios they will need will need to be small, lightweight and use low power. This could be good.

ADS/B will help aircraft sense and avoid each other. Drones flying in swarms will be possible. Drones avoiding manned aircraft should be easier. Manned aircraft missing drones will be easier also.

There is an old joke about air traffic controllers are there to minimize noise, ever hear the noise when aircraft bump into each other? Aircraft of all sizes will need to help keep the noise down. Drones running into each other can be bad for the people walking down the sidewalk.

These ADS/B radios for the drones could also be used for light aircraft. There are still plenty of aircraft without electrical systems flying. Having the ability to put a small, lightweight, low power UAT in a light aircraft should make them capable of using the class B and C airspace they may be excluded from. I don't know what the FAA is going to do about waivers for the no radio aircraft. They are capable of avoiding each other, and most larger aircraft. It will be difficult to see what the record will be in UAS vs Pilot Eyeballs in the sense and avoid arena without UAT.

I've suggested it before, and hope it comes to fruition. I'd love to test out one of these UAT devices on my airplane.


Thursday, April 16, 2015

Android Mirror

Over most of he last year I have been hearing about "Android Auto". Android Auto is supposed to be a smart head unit for your car. By smart head unit, it will use your phone for the brains but the controls will appear on the car display. Big buttons in easy reach, helping drivers keep their eyes on the road. It is a smart idea. It won't be available for a few more months though.

I've seen head units running Android on ebay for most of the last year, as well. I keep thinking that I would get one. These units were $130-$180 last fall, but now they are over $200. It is weird, I've seen an Ouku unit that looks the same, if it is running WinCE it is about $100, but put android on it and it cost $250.  Other brands are similar, the WinCE unit is about half the price as the Android loaded device. The reviews on these head units make them seem not quite ready for average users. The commands are complicated, and loading apps is hit and miss.




Then I saw a unique device. A rear view mirror with about a third of the glass reserved for an LCD display. Some of these are running Android. It seemed curious, because, again it keeps the eyes looking forward, and provides useful information. The fun part is, they are only about $100, well within my lets try it budget.

Some of the advertised features include, dash camera records out the window based on pressing a button, or G forces. (good for presenting the insurance company evidence that person did cut you off), rear view camera included, GPS stereo speakers, bluetooth and an FM transmitter.

The blob hanging from the mirror is the forward dash cam. This can be turned up to 350degrees for recording inside the car as well as out the front. I find out the front is probably the best place to point it. There are microphones in the mirror to pick up in the car sounds. The recordings have both sound and video.

Unboxing








The box is a fine, kind of modern magnet clasp unit, with an over wrapper. Inside there is a vacuformed holder for the mirror, and underneath are the extra cables. Cables included a car adapter, GPS antenna, a USB OTG cable and the rear view camera. There is a minimal manual included.





The mirror has a series of buttons and jacks around it. There are the normal power and volume buttons, as well as a physical back button, camera button and another button that I don't know what it does. The jacks are labeled, (but wrong; the labeled headphone jack is the GPS antenna jack). The power jack is a mini-USB connector. To get the rear view camera to a usable location, will take some work to run the wire.

Powering it up




I pressed the power button, and it started with an Android robot, then switched to a lens with a moving road. Once the android environment is going, the voice says "Application Started, Have a Nice Trip". I plugged in the car adapter, since I didn't know the state of the battery. The LED on the adapter didn't light up, no amount of twisting or wiggling it would make that turn on. Eventually I found out this adapter was defective. I wanted to keep my dual USB adapter in my car anyway, so I found another USB A to mini cable, and it was charging.



The initial display is a strange GUI menu thing. It seems to make sense and probably kinda easy to keep eyes on the road. The dash cam is still the predominant menu selection, the maps are at the top, FM transmitter, in the next column is the clock, an audio player, and a gallery for the videos. The lower center selection is the Android system selection, allowing access to the android app selection.

The built in apps include Google Play, along with calculator, settings, and the custom apps, GUI, and dash cam. There is a GPS tester app,  and just a couple other apps. The Google Play store started as an older app, but does get an update shortly after a bit. The start-up seemed a little slow, but I think it was updating various apps and services.

Once I turned on WiFi, it was able to connect to my home internet from the driveway. I downloaded the Google Maps app, and a podcast app. I found the maps app will need full time WiFi connections. I tried to download the Nokia Maps app, but didn't find it. The Nokia Maps app will contain offline maps and directions. I downloaded some other app, that seems to work. With the GPS plugged in, it seems to work very well.

The GPS will also allow setting the time. The GPS is very accurate time, and should be used whenever possible. (see this post to know how GPS use time to know where it is).

The FM transmitter seems very straightforward. There is an on/off icon in the upper left. When turned on, the frequency arrows and volume settings become active. The FM transmitter relies on the USB cable for an antenna, so if the unit isn't charging, it won't let the FM transmitter turn on. Sometimes the transmitter UI shows it is on, and all, but the radio doesn't receive anything. The only thing I have seen will fix this is waiting a little while and try again.

There are built in speakers, and they are almost loud enough to use while driving. They are no very Hi-Fi, very tinny. Actually the FM transmitter is a little toward the tinny side as well, music doesn't have much bass.

The specs are odd. Not bad, but not what one might expect out of a tablet or phone. The battery is only 800ma. 800ma isn't bad, since the unit needs to be plugged into the car to use the FM transmitter. There is no LTE or other phone radios, it would be handy, but not needed with a little planning. I have been downloading podcasts evenings and that is keeping things full. The processor isn't working too hard just doing video or audio, and of course isn't very powerful. Switching between apps is slow, but while driving, I don't switch much.

There is an SD card slot. The videos are saved to the SD card. The video seems to be recording always, but not saved unless you press a button. I showed up at work the other day, and there some turkeys in the parking lot. I tried to record them, so I pressed the record. When I played the video back, it actually started probably a minute before I actually pressed record. I think that is planned, for the accident recording.

The display is not bad, except at night because it is bright, there doesn't seem to be an auto dim. Leaving the display on, during the day doesn't seem to be an issue, and I am still able to see behind me in the mirror. The mirror itself isn't as bright at the stock mirror, probably because the whole glass has the same reflective as the display area. At night it is important to turn off the display. The first button on the left is the power, and is easy to manage.

In the mornings I press the power button, and press play on the podcast app. The podcasts start where I left off last night, then I press power to stop turn off the display. When I get to work, I press power, the pause in  podcast app, and power.  Occasionally I have to set the state this way or that if I want to use another feature. The audio player app in the GUI will usually let me use those controls to run the podcast player.

I will be honest, and was ready to return the whole mess the first couple days I had it. There were a few items that just seemed that I wasn't going to be able to make simple. Once I stopped playing with it, and just doing the fun basic stuff it works just fine.  

About Device: (from about tablet in settings)
Model Number:  SoftwinerCvr
Android Version: 4.0.4
Baseband version: v2.0
Kernel version: 3.0.8
Build number: crane_cvr-eng 4.0.4 IMM76D 20140819 test-keys

I think it is a good first try. Room for improvement, but there is a lot here. If the software is updated, I think this could be a popular item.

Another review here.