XAircraft Pilot Lamp Accessory Hack

mr.rc-cam · Post by **mr.rc-cam** » Mon Jun 04, 2012 8:17 pm

I recently came across the XAircraft Pilot Lamp accessory ($10 LED/Buzzer) and thought it would be an interesting candidate for the MWC. Unfortunately I don't own an XAircraft to reverse engineer and I can't find any communication protocol information on it. Given the simple 3-wire connection, I assume it uses a serial communication method. Has anyone here dug into it? If so, please share what you know.

Demo video showing the Pilot Lamp in action:
http://www.youtube.com/watch?v=z-nKSD-eHsQ

Another Demo Video:
http://vimeo.com/28593248

mr.rc-cam · Post by **mr.rc-cam** » Mon Jun 18, 2012 8:33 pm

I received the Pilot Lamp device today and took a peek at the circuitry. It uses a STC11F01 MCU (8051 core). The communication signal on its 3-wire cable is not connected to the MCU's RxD pin. Instead it is uses INT1. So this suggests that the serial protocol is probably not common RS-232. Not that this is a big deal, but worth noting.

I don't have an XAircraft control board to connect to it. So at this point I'll need some luck to reverse-engineer the communication protocol.

mr.rc-cam · Post by **mr.rc-cam** » Tue Jun 19, 2012 12:31 am

I was able to control the buzzer and lights using a Function/Signal (frequency) generator. I don't expect my findings represent the official communication protocol, but my clumsy solution works.

The control waveform should be symmetrical and it can be idle when not writing/changing new states, but at least three complete waveform cycles are needed for each LED or Buzzer update. The control frequencies are as follows:
RED LED ON : 1000Hz
RED LED OFF: 850Hz
BLU LED ON : 1600Hz
BLU LED OFF: 1300Hz
GRN LED ON : 4500Hz
GRN LED OFF: 2600Hz
BUZZER ON : 725Hz
BUZZER OFF: 625Hz

Next on the list is to add some code to the MWC to activate the LED's and Buzzer. I will post the details here when I have something to share.

- Thomas

mr.rc-cam · Post by **mr.rc-cam** » Wed Jun 20, 2012 1:09 am

I wrote some preliminary MWC code to control the three LED's and buzzer. I'll post the sample code soon; In the meantime, here is a YouTube demo of my test code that sequences the three LED's and beeps the buzzer:

http://youtu.be/-QNeVQitJDs?hd=1

By the way, the buzzer is loud! For bench testing I've stuffed a piece of sponge in the buzzer's speaker hole to help make the noise tolerable. So this noisy fellow would be ideal to use as a lost model finder.

- Thomas

mr.rc-cam · Post by **mr.rc-cam** » Wed Jun 20, 2012 10:58 pm

Attached is the basic code that is needed to control Pilot Lamp's three LEDs and buzzer. It is a pde file that is added to your MWC source code folder. You can rename it with the .ino extension if that is how you roll.

You simply plug the Pilot Lamp's 3-wire cable into MultiWiiCopter's Buzzer port (configured for Arduino pin D8 in the provided code). Then to turn on an LED you would do something like this:

Code: Select all

 PilotLamp(PL_GRN_ON);

Controlling the LED's is up to your desires; just add the PilotLamp() function where you want it. But to get you started, the buzzer code is already handled for you. All you have to do is comment out these two defines in file def.h
// #define BUZZERPIN_ON PORTB |= 1;
// #define BUZZERPIN_OFF PORTB &= ~1;

and replace with

Code: Select all

#define    BUZZERPIN_ON PilotLamp(PL_BZR_ON);
#define    BUZZERPIN_OFF PilotLamp(PL_BZR_OFF);

You will need to add these new defines to your def.h file:

Code: Select all

#define    PL_INIT   0
#define    PL_GRN_ON    111    // 4500Hz
#define    PL_GRN_OFF   192    // 2600Hz
#define    PL_BLU_ON    312    // 1600Hz
#define    PL_BLU_OFF   385    // 1300Hz
#define    PL_RED_ON    500    // 1000Hz
#define    PL_RED_OFF   588    // 850Hz
#define    PL_BZR_ON    689    // 725Hz
#define    PL_BZR_OFF   800    // 625Hz
#define    PL_PIN_ON    PORTB |= 1;
#define    PL_PIN_OFF   PORTB &= ~1;

And finally, you will need to initialize the function one time by adding this line of code to the main setup() function, perhaps right after configureReceiver():

Code: Select all

PilotLamp(PL_INIT);

As a parting comment, my gut feeling is that my communication method is an exploit rather than the official protocol. So if one of you fine fellows has a chance to reverse-engineer the communication protocol on your XAircraft controller then please report your findings here. I'd love to know if I got close to how they are doing it.

- Thomas

haydent · Post by **haydent** » Thu Jun 21, 2012 4:46 am

excellent work, thanks !

jevermeister · Post by **jevermeister** » Thu Jun 21, 2012 7:17 am

Hi,
this is very interesting.
Very good work mate!

I have some basic understanding questions:

The device is controlled via PWM?

So is it possible to blink two LEDs and beep the buzzer!?
Or can we only operate one aspect at a time?

Nils

jevermeister · Post by **jevermeister** » Thu Jun 21, 2012 7:18 am

Oh and by the way:
If this thing makes it into the MWC trunk:

Please add you code as an optional part to buzzer.ino - I believe it fits there ;-)

Nils

mr.rc-cam · Post by **mr.rc-cam** » Thu Jun 21, 2012 8:15 am

The device is controlled via PWM?

I had only partial success with PWM (results were not consistent). The protocol that worked reliably for me is based on a symmetrical frequency burst as described in post #3.

So is it possible to blink two LEDs and beep the buzzer!?

You can have any combination of LED / buzzer patterns that you want. For example, you can turn on the Red and Blue LED's (both on at the same time) by doing this:

Code: Select all

PilotLamp(PL_GRN_OFF);
PilotLamp(PL_RED_ON);
PilotLamp(PL_BLU_ON);
// These devices will remain on until YOU send the codes to turn them off.

Please add you code as an optional part to buzzer.ino - I believe it fits there

Seems like a cozy place to put it. But I would recommend renaming buzzer.ino to something like alert.ino. But more importantly, before anyone commits the Pilot Lamp code as a permanent MWC option I think it should be tested on several different MWC platforms.

- Thomas

jevermeister · Post by **jevermeister** » Thu Jun 21, 2012 8:29 am

Hi,
thank you for the update.

I will definetily get me one of the pilot lamps.
I saw there are two versions, one with housing and one without.
I want my buzzer placed in one of the pilons - as far away from the mag as possible ;-)

Nils

ps.:
looking forward to a supercool startup blink pattern ;-)

mr.rc-cam · Post by **mr.rc-cam** » Thu Jun 21, 2012 5:18 pm

I saw there are two versions, one with housing and one without.

I recommend the one with the attractive plastic case. It only adds a couple grams of weight and it looks better than the shrink wrap version. And of course you can always remove the case (4 screws) and shrink wrap it yourself if you later decide to go with the ghetto look.

- Thomas

jevermeister · Post by **jevermeister** » Thu Jun 21, 2012 7:35 pm

ghetto look...
lol

Tazzy · Post by **Tazzy** » Tue Jul 17, 2012 11:57 am

I did get one of these and it works good, hope we can implement it in the main code as an accessory.
Three good leds AND a loud buzzer on same wire is excellent !

// Tazzy

mr.rc-cam · Post by **mr.rc-cam** » Tue Jul 17, 2012 5:18 pm

Has anyone tried out the code examples I posted? If so, is it working for you?

- Thomas

jevermeister · Post by **jevermeister** » Tue Jul 17, 2012 6:42 pm

I am implementing it as we speak, my pilot lamp is still underway but the code is already integrated into buzzer.ino.
I will put it into shared trunk as soon as I tested it,
I implemented some blink patterns.

Nils

mr.rc-cam · Post by **mr.rc-cam** » Tue Jul 17, 2012 8:42 pm

I will put it into shared trunk as soon as I tested it

Thanks for doing that.

It would be a very good idea for an X-Aircraft FC owner to reverse-engineer the actual protocol (a few minutes with a digital scope or logic analyzer would be needed). My Pilot Lamp driver is a best-guess effort so verifying their protocol would ensure that no surprises come up.

- Thomas

Tazzy · Post by **Tazzy** » Wed Jul 18, 2012 12:29 am

mr.rc-cam wrote:Has anyone tried out the code examples I posted? If so, is it working for you?

- Thomas

I have tested it on new 2.1 and it works but im not a coder so i dont dare to change alot.
Buzzer works fine and i only added grn led indicator after the init calibration.

jevermeister: THANK YOU !!! Tell me if you need some help to test it .....

// Tazzy

mr.rc-cam · Post by **mr.rc-cam** » Wed Jul 18, 2012 4:03 am

Buzzer works fine and i only added grn led indicator after the init calibration.

Thanks for the feedback. It's good to hear the basic Pilot Lamp code works for you.

- Thomas

Tazzy · Post by **Tazzy** » Wed Jul 18, 2012 2:14 pm

mr.rc-cam wrote:
Buzzer works fine and i only added grn led indicator after the init calibration.

Thanks for the feedback. It's good to hear the basic Pilot Lamp code works for you.

- Thomas

Thomas thanks for your work on this

i will also follow your multiwii > er9x telemetry it will be real interested

because i have all set up except the position ....

/7 Tazzy

Hamburger · Post by **Hamburger** » Wed Jul 18, 2012 8:52 pm

jevermeister wrote:I am implementing it as we speak, my pilot lamp is still underway but the code is already integrated into buzzer.ino.
I will put it into shared trunk as soon as I tested it,
I implemented some blink patterns.

Nils

While you are at it
Will you combine the led flasher code with the buzzer code? Sounds like one of the rare chamces to reduce number of files.

jevermeister · Post by **jevermeister** » Wed Jul 18, 2012 8:57 pm

Hi,
I will have to contact alex about that.We have a policy about that.
But I would be happy to merge them into a new file.

Btw. every Buzzer sound has to be managed by buzzer.h.

nils

Tazzy · Post by **Tazzy** » Wed Jul 18, 2012 10:03 pm

Hamburger wrote:
jevermeister wrote:I am implementing it as we speak, my pilot lamp is still underway but the code is already integrated into buzzer.ino.
I will put it into shared trunk as soon as I tested it,
I implemented some blink patterns.

Nils

While you are at it
Will you combine the led flasher code with the buzzer code? Sounds like one of the rare chamces to reduce number of files.

That sounds natural when the pilotlamp also have indicator/status lamps.

// Tazzy

Hamburger · Post by **Hamburger** » Wed Jul 18, 2012 10:05 pm

From the led flaaher thread it seems people struggle woth missing documentation for
Fumctionality
Pin usage
Does that code do amythimg not possible with the buZer/alarm output

Tazzy · Post by **Tazzy** » Wed Jul 18, 2012 10:13 pm

Hamburger wrote:From the led flaaher thread it seems people struggle woth missing documentation for
Fumctionality
Pin usage
Does that code do amythimg not possible with the buZer/alarm output

I'm not a led flasher user but what i can see it triggs some output pins that is relayed with a transistor that power the leds so thats sounds like it is usal iO.
The pilotlamp is activated with different frequens signals that start and stops the different functions so that is not the same .... but both is indicators that was my thought

// Tazzy

Hamburger · Post by **Hamburger** » Wed Jul 18, 2012 10:27 pm

Right. Just like buzzer?

Alexinparis · Post by **Alexinparis** » Thu Jul 19, 2012 11:48 pm

I would say the buzzer.ino is the good place for this code.
And it can probably share the same checkbox as ledflasher.

jevermeister · Post by **jevermeister** » Thu Jul 26, 2012 7:48 am

So the pilotlamp is here.
I coded some warning patterns and made the defines for all three boards. I want to test the implementation over the weekend.I need some volunteers for pro mini and pro micro and mega boards that test if it works.

I am struggling with alarm patters right now.

Nils
ps.: I will upload a branch today and let you guys know

mr.rc-cam · Post by **mr.rc-cam** » Thu Jul 26, 2012 3:48 pm

That is excellent news. I'm deep in another project at the moment so I won't be able to try your code for several days.

- Thomas

jevermeister · Post by **jevermeister** » Mon Jul 30, 2012 6:49 pm

Hi there,
I just uploaded the code to my branch of the google code SVN repository:

http://code.google.com/p/multiwii/source/browse/#svn%2Fbranches%2Fjevermeister%2FMWC%202.1%20PilotLamp%20Beta%2FMultiWii_2_1

This code is based on the stock MultiWii 2.1, so you have to make your changes as usual in config.h.

There is a new define in config.h now:

Code: Select all

    
#define PILOTLAMP
#if defined(PILOTLAMP)
   #define BUZZER
#endif

So if you define the PilotLamp the standard Buzzer code is activated and rerouted to the pilotlamp buzzer.

The pilotlamp is now doing the following:

I am looking for new pattern ideas. Feel free to make suggestions.
I renamed buzzer.ino into alarms.into and merged it with led.ino.
Because I only have a mega board I could not verify the code working for Pro Mini or Micro/Mongoose and D8Buzzer.
However all the above configurations are coded and *should* work. Please report back if it is or is not working for your configuration.

Nils

mr.rc-cam · Post by **mr.rc-cam** » Mon Jul 30, 2012 7:54 pm

Thanks for publishing the dev code. I will try it out but I don't have a subversion client to download from the SVN. What is a trusted client utility that I can use to get your files?

- Thomas

jevermeister · Post by **jevermeister** » Mon Jul 30, 2012 9:43 pm

I use a svn client called "tortoise svn" it is easy to understand and handy.

mr.rc-cam · Post by **mr.rc-cam** » Tue Jul 31, 2012 1:37 am

Thanks for the recommendation. But Tortoise SVN integrates into Explorer, which is something I want to avoid. I tried a standalone client and could not get it to work. So as time permits, I will use the clumsy download method and get all your files that way. I sure miss the old days when source files were just zipped-up for a simple brainless download.

- Thomas

jevermeister · Post by **jevermeister** » Tue Jul 31, 2012 4:54 am

shall i zip them for u?

mr.rc-cam · Post by **mr.rc-cam** » Tue Jul 31, 2012 5:23 am

shall i zip them for u?

That would be awesome. Thanks!

- Thomas

jevermeister · Post by **jevermeister** » Tue Jul 31, 2012 9:09 pm

Hi,
just uploaded it:

https://multiwii.googlecode.com/svn/bra ... eister/MWC 2.1 PilotLamp Beta

mr.rc-cam · Post by **mr.rc-cam** » Wed Aug 01, 2012 2:19 am

The link is broken, but that's not a big deal. However, when I go to the SVN to download the zip I get this error:
"This file is not plain text (only UTF-8 and Latin-1 text encodings are currently supported). "

Rather than continue to pester you, when I have the time I will manually download the various files from the SVN using the raw file mode.

- Thomas

mr.rc-cam · Post by **mr.rc-cam** » Wed Aug 01, 2012 4:37 am

I installed the dev code and did some preliminary tests on my Pro Mini based X4 frame. I ran into two major issues that I did not have time to debug (too many other projects at the moment, so my time here is limited).
1. Cannot arm via the sticks. This is not the usual calibration or stick end point issue.
2. I cannot compile with the I2C_GPS code. If I do, the compiler reports errors.

Test Results:
No lights: Everything is OK and copter is unarmed: Works.
Red LED blinking fast: Failsafe landing active: Seems to work. But the Green LED continues to blink too. Is that intended?
Red LED blinking slow: No TX Signal found: Works.
Blue LED blinking fast: No GPS fix: Not tested, GPS code won't compile.
Blue LED blinking slow: GPS RTH or PH is active: Not tested, GPS code won't compile.
Green LED blinking fast: Armed in Acro Mode: Does not work.
Green LED blinking slow: Armed in hover mode: Not tested, Don't know what hover mode is. My Green LED blinks slow regardless of Acro or Level Mode.
LED Sequence Green/Blue/Red: Buzzer via TX-Aux is activated. If you mean "BEEPER" mode, then this does not work.

Some comments:
The low voltage battery beeps and light alerts are missing. I think they are an important feature for the Pilot Lamp.

- Thomas

jevermeister · Post by **jevermeister** » Wed Aug 01, 2012 7:47 am

Hi,
if you right click on the link you can download the zip file directly.

Thank you for the feedback.
1. you have to define arm/disarm via sticks in the config.h
2. I don't know anything about the GPS code - sorry.

About the results:
If the failsafe landing is active, it is also in Level mode so the green LED should pulsate slowly - that is intended

BLinking of the LED in Acro or Level mode:
In level mode the green LED is blinking 0,5Hz (1sec ON, 1 sec OFF)
in acro mode, the LED is blinking in 1HZ (0,5sec ON, 0,5sec OFF)
Maybe the difference is not big enough?

If you activate the beeper mode (activate the beeper via aux channel), the sequence should be started.

Low Voltage battery beeps are unchanged, you rerouted the signals to the pilotlamp, so the vbat beepber codes are using the pilotlamp now.
Did you activate vbat and set the limits?

Nils

ps.: What board are you using, if you are using a arduino mini my defines seem to work ;-)

mr.rc-cam · Post by **mr.rc-cam** » Wed Aug 01, 2012 4:33 pm

if you right click on the link you can download the zip file directly.

I had tried that and what was downloaded was a html file instead of the zip file set. But this morning I found the solution. The trick is to click the zipped file's name (which takes you to a new page) and then click the "View raw file" link and choose "Save File."

1. you have to define arm/disarm via sticks in the config.h

That is unexpected. This must be something relatively new since the previous releases I've used all had stick arming enabled by default. So this "problem" is solved.

BLinking of the LED in Acro or Level mode:
In level mode the green LED is blinking 0,5Hz (1sec ON, 1 sec OFF)
in acro mode, the LED is blinking in 1HZ (0,5sec ON, 0,5sec OFF)
Maybe the difference is not big enough?

I checked again and I do see the small timing difference, so it is working. I would recommend that Level mode be solid green and Acro mode be slow blink green.

If you activate the beeper mode (activate the beeper via aux channel), the sequence should be started.

Not sure why I had problems last night, but I checked again and it is working. But I noticed two bugs.
1. If beeper box mode is enabled, but not active, then when the MWC is booted the blue LED is on after initialization.
2. If I activate the beeper mode, then turn it off while the blue LED is on, it will remain on.

Low Voltage battery beeps are unchanged, you rerouted the signals to the pilotlamp, so the vbat beepber codes are using the pilotlamp now.
Did you activate vbat and set the limits?=

Looked into it this morning. My problem was due to using a 2S pack for these tests (I didn't want the motors to spin up). I had to reduce the NO_VBAT define to 0 in order to get the low battery beep alert. So it is working.

BTW, my Arduino board is the Sparkfun Pro Mini.

I'm far behind in some other higher priority projects, so it is difficult for me to find the time to do more Pilot Lamp testing. Hopefully others will chime in to assist in the dev validation. The Pilot Lamp gadget is really a nice accessory for the MWC and the low cost makes it an easy decision to buy.

- Thomas

jevermeister · Post by **jevermeister** » Wed Aug 01, 2012 9:10 pm

Hi,
thank you for that feedback.
Since you are using the Pro Mini, I can sys it works for Mega and Pro Mini.

I reviewed the code and tweaked some parts:
- The acromode blinking is now faster.
- There was a bug regarding the blue led, it was not turned off properly, I did not notice that, since I am using a GPS, so it is blinking all the time ;-)

I uploaded a fixed alarms.ino, so if you find some time, you can try the changes.

Nils
p.s.: Maybe I can integrate the code into the trunk next week

jevermeister · Post by **jevermeister** » Tue Aug 07, 2012 11:49 am

Hi,
I think we have a problem with this code:

Code: Select all

for (i=0;i<4;i++) {                                // Create the freq signal to activate Pilot Lamp.
              PL_PIN_ON;
              delayMicroseconds(device);
              PL_PIN_OFF;
              delayMicroseconds(device);
          }

If the cycle time fluctuates, I have a fluctuating signal of the buzzer and the led to, the right frequencies are not used anymoe.
Is there a different way to create the signal!?

mr.rc-cam · Post by **mr.rc-cam** » Tue Aug 07, 2012 5:40 pm

If you mean the LED on/off timing or beeper on/off cadence changes due to cycle-time, then the issue should not be related to this particular code.

This code generates a short waveform to trigger the Pilot Lamp. It can be affected by too many hardware interrupts (which would depend on the model's configuration). If you see a difference in behavior due to the interrupt usage then it could be a difficult issue to solve.

- Thomas

jevermeister · Post by **jevermeister** » Thu Aug 09, 2012 8:18 am

Hi,

I am searching for the reason, the Beeping and blinking gets out of sync and sometimes hickups when the cycletimes rises,

I will try to check with my buzzer today and see if it is my control code or the pilot lamp what is affected by this.

I have a question regarding your code:

Code: Select all

  void PilotLamp(uint16_t device){
      uint8_t i;
      static union pl_reg mode;
      if(device == PL_INIT) {                            // Initialize the Pilot Lamp.
          mode.pl_ctrl_all = 0x00;                       // Reset all LED and Buzzer status states.
          for (i=0;i<4;i++) {                            // Create the required freq waveforms to control the various modes.
              PL_PIN_ON;
              delayMicroseconds(PL_GRN_OFF);
              PL_PIN_OFF;
              delayMicroseconds(PL_GRN_OFF);
              PL_PIN_ON;
              delayMicroseconds(PL_BLU_OFF);
              PL_PIN_OFF;
              delayMicroseconds(PL_BLU_OFF);
              PL_PIN_ON;
              delayMicroseconds(PL_RED_OFF);
              PL_PIN_OFF;
              delayMicroseconds(PL_RED_OFF);
              PL_PIN_ON;
              delayMicroseconds(PL_BZR_OFF);
              PL_PIN_OFF;
              delayMicroseconds(PL_BZR_OFF);              
          }
      }
      else {                                                  // Check to see if the new state request is different than the current state.
          if(device==PL_GRN_OFF && mode.ctrl.grn==1) {
              mode.ctrl.grn = 0;
          }
          else if(device==PL_GRN_ON && mode.ctrl.grn==0) {
              mode.ctrl.grn = 1;
          }
          else if(device==PL_BLU_OFF && mode.ctrl.blu==1) {
              mode.ctrl.blu = 0;
          }
          else if(device==PL_BLU_ON && mode.ctrl.blu==0) {
              mode.ctrl.blu = 1;
          }
          else if(device==PL_RED_OFF && mode.ctrl.red==1) {
              mode.ctrl.red = 0;
          }
          else if(device==PL_RED_ON && mode.ctrl.red==0) {
              mode.ctrl.red = 1;
          }
          else if(device==PL_BZR_OFF && mode.ctrl.bzr==1) {
              mode.ctrl.bzr = 0;
          }
          else if(device==PL_BZR_ON && mode.ctrl.bzr==0) {
              mode.ctrl.bzr = 1;
          }
          else {                                             // No state changes
              PL_PIN_OFF;
              return;                                       // Skip signal generation.
          }
          for (i=0;i<4;i++) {                                // Create the freq signal to activate Pilot Lamp.
              PL_PIN_ON;
              delayMicroseconds(device);
              PL_PIN_OFF;
              delayMicroseconds(device);
          }
      }      
      return;
  }

Why are you doing this four times?

Code: Select all

          for (i=0;i<4;i++) {                                // Create the freq signal to activate Pilot Lamp.
              PL_PIN_ON;
              delayMicroseconds(device);
              PL_PIN_OFF;
              delayMicroseconds(device);
          }
      }      
      return;
  }

Can you explain me, cause I don't get it ;-)

Nils

mr.rc-cam · Post by **mr.rc-cam** » Thu Aug 09, 2012 7:13 pm

The code generates a squarewave signal that is four cycles long. This was found to be the minimum required cycle count.

The waveform is software bit-banged. This will require MWC cycle time. It is important to minimize the Pilot Lamp activity so that the cycle time is not inflated. For example, if you send the command to turn off the Buzzer, which is the worst case scenario, it will require 6.4mS of cycle time to do that, which is a lot. However, generating the various waveforms will not be an issue if you do it occasionally. But if you do it too often then you will see nasty cycle times whenever the Pilot Lamp waveform is created. And if this is too severe it can affect flight behavior.

To help reduce impacts to the cycle time the Pilot Lamp code will determine if the device's command is a repeat of a prior request, and if so it will ignore the new request. But beyond that, it is up to your code to schedule the commands so that you do not overwhelm the cycle times by generating the waveforms too often. It would be wise for your code to spread out (buffer) the device commands so that only one command is sent, then skip several PID cycles before sending the next device command. And so on.

I'm not sure what you are experiencing, but maybe the information above will help you solve it. Perhaps there is a logic error in your Pilot Lamp device scheduling and it is being called too often. So watch/listen and if you see rapid Pilot Lamp activity then that is a sign that the code is being overly optimistic. Less is best.

I changed the Pilot Lamp code to make it more obvious on how it works. There's a now a separate waveform function called gen_pl_freq(). Although this does not reduce the cycle time, it is more logical (and easier to digest) approach. So please incorporate these changes:

Code: Select all

#if defined(PILOTLAMP)
//   ****************************************************************
//   *                    XAircraft Pilot Lamp                      *
//   *    LED & Buzzer Device for use with MultiWiiCopter.          *
//   *             by Thomas Black / mr.rc-cam                      *
//   *                  Org: June-19-2012                           *
//   *                  Upd: August-09-2012                         *
//   *                  Made in USA :)                              *
//   ****************************************************************
//
// Need help using this code? Please see http://www.multiwii.com/forum/viewtopic.php?f=6&t=1794
//
// *********************************************************************************************************************
//
// These routines for XAircraft's Pilot Lamp LED/Buzzer module are preliminary functions that may
// change after additional reverse-engineering of the XAircraft communication protocol is performed.
//
// *********************************************************************************************************************

union pl_reg {
    struct {
        unsigned grn: 1;
        unsigned blu: 1;
        unsigned red: 1;
        unsigned bzr: 1;
    } ctrl;
    uint8_t pl_ctrl_all;
};

// *********************************************************************************************************************
// PilotLamp() is called with the PL_XX parameter (see below). In order to prevent unneccessary
// increases in IMU cycle time, the bit-bang freq control waveform is only generated if the device (LED or buzzer) 
// state update is different from the previous state.
// Available device parameters are:
//    PL_INIT { MUST be called once in main sketch setup() }
//    PL_GRN_ON, PL_GRN_OFF { Green LED control }
//    PL_BLU_ON, PL_BLU_OFF { Blue  LED control }
//    PL_RED_ON, PL_RED_OFF { Red   LED control }
//    PL_BZR_ON, PL_BZR_OFF { Buzzer control }
//
void PilotLamp(uint16_t device)
{
    uint8_t i;
    static union pl_reg mode;
    
    if(device == PL_INIT) {                             // Initialize the Pilot Lamp State Table, turn off LEDs and Buzzer.
        mode.pl_ctrl_all = 0x00;                        // Reset all LED and Buzzer status states.
        gen_pl_freq(PL_GRN_OFF);                        // Turn off Green LED.
        gen_pl_freq(PL_BLU_OFF);                        // Turn off Blue LED.
        gen_pl_freq(PL_RED_OFF);                        // Turn off Red LED.
        gen_pl_freq(PL_BZR_OFF);                        // Turn off Buzzer.
    }
    else {                                              // Check to see if the new state request is different than the current state.
        if(device==PL_GRN_OFF && mode.ctrl.grn==1) {
            mode.ctrl.grn = 0;
        }
        else if(device==PL_GRN_ON && mode.ctrl.grn==0) {
            mode.ctrl.grn = 1;
        }
        else if(device==PL_BLU_OFF && mode.ctrl.blu==1) {
            mode.ctrl.blu = 0;
        }
        else if(device==PL_BLU_ON && mode.ctrl.blu==0) {
            mode.ctrl.blu = 1;
        }
        else if(device==PL_RED_OFF && mode.ctrl.red==1) {
            mode.ctrl.red = 0;
        }
        else if(device==PL_RED_ON && mode.ctrl.red==0) {
            mode.ctrl.red = 1;
        }
        else if(device==PL_BZR_OFF && mode.ctrl.bzr==1) {
            mode.ctrl.bzr = 0;
        }
        else if(device==PL_BZR_ON && mode.ctrl.bzr==0) {
            mode.ctrl.bzr = 1;
        }
        else {                                          // No state changes
            PL_PIN_OFF;
            return;                                     // Skip signal generation.
        }
        
        gen_pl_freq(device);                            // Send waveform to Pilot Lamp.
    }
    
    return;
}


// *****************************************************************************************************************
// Create the freq signal to activate Pilot Lamp. This is a bit-bang operation.
void gen_pl_freq(uint16_t device)
{
    uint8_t i;
    
    for (i=0;i<4;i++) {                                // Four waveforms are required. 
        PL_PIN_ON;
        delayMicroseconds(device);
        PL_PIN_OFF;
        delayMicroseconds(device);
    }
    
    return;
}

// *****************************************************************************************************************
// PilotLampTest() can be used to troubleshoot the LED/Buzzer module. Place it in the main loop and you 
// should see the three LED's sequence in order with a periodic short beep.
void PilotLampTest(void)
{
     static uint8_t cam1 = 0;
     static uint8_t cam2 = 0;
     static uint8_t state = 0;
     
     if(cam1++ > 40) {                                // Update rate is perhaps 2Hz, but will vary.
         cam1 = 0;
         if(cam2++ > 20 && state==1) {                // Periodically beep the buzzer (every few seconds).
             cam2 = 0;
             PilotLamp(PL_BZR_ON);
             delay(200);                              // Brute force delay is needed because main loop will immediately turn off buzzer.
         }
         else {
             switch(state) {                          // Light-chase Cycle the LED's.
                 case 0:
                     state++;
                     PilotLamp(PL_BZR_OFF);
                     break;
                 case 1:
                     state++;
                     PilotLamp(PL_GRN_ON);
                     break;
                 case 2:
                     state++;
                     PilotLamp(PL_GRN_OFF);
                     PilotLamp(PL_BLU_ON);
                     break;
                 case 3:
                     state++;
                     PilotLamp(PL_BLU_OFF);
                     PilotLamp(PL_RED_ON);
                     break;
                 case 4:
                     state = 0;
                     PilotLamp(PL_RED_OFF);
                     break;
             }
        }             
     }
  
    return;
}

// *********************************************************************************************************************
#endif

jevermeister · Post by **jevermeister** » Thu Aug 09, 2012 8:18 pm

thanks for the detailed instructions.
I just tested my issue with my piezo buzzer, and I do not have that problem using the buzzer.

I will read your psot in detail tomorrow, ebcause I am onto code review right now.
Just wanted you to know, that my buzzer works fine and the pilot light buzzer does not.

Perhaps you can checkout my alst commit - maybe yous ee some msitake I made.

I call the pilot lights buzzer directly by BUZZER_ON /BUZZER_OFF

Nils

ps.: Will add your changes asap

jevermeister · Post by **jevermeister** » Thu Aug 09, 2012 8:31 pm

Okay,
I call some fast beeping pattern with small pauses between two beeps, so these 6.5ms are quite a lot.

I think I will have to rethink the patterns...

Nils

mr.rc-cam · Post by **mr.rc-cam** » Thu Aug 09, 2012 10:14 pm

I suggest minimizing any patterns and try to stick with static indications where possible. For example:
Steady Green: Level Mode.
Steady Yellow: Acro Mode.
Steady Red: Failsafe or lost signal.
Slow Red Blink: Disarmed.
Slow Beep: Battery Low
Single short beep: An AUX Switch was activated/deactivated
... and so on.

Remember, every time you send a new Pilot Lamp device command it will impose additional cycle-time for that loop's instance. So if you want fancy LED and/or Beep patterns then use them sparingly and with slow cadence. I'm not saying you can't use a pattern, but don't go wild and try to emulate a machine gun. ):

And do not send multiple device commands during the same short period. Remember, less is best.

- Thomas

jevermeister · Post by **jevermeister** » Thu Aug 09, 2012 10:42 pm

Hi Thomas,

what a bummer.
I had a lot of fancy patterns and blinks done...
I will overthink your tips and will propably rearrange everything.

First I will log my cycletimes with gps wit eosbandi's tool and try too see the difference.

Nils

EDIT: Wouldn't it be possible to use a free hardware PWM output and use it with frequency modulation?

jevermeister · Post by **jevermeister** » Mon Aug 13, 2012 8:22 pm

Hi,

I tried everything in the past days. If the cycletime rises or fluctuates, the PilotLamp becomes unusable and erradic. I was unable to solve this issue.

The signal generation should be solved differently.
Is there a free timer left? we should generate the frequencies in background with a timer if possible.

Nils

jevermeister · Post by **jevermeister** » Tue Aug 14, 2012 9:53 pm

OK, thats it for me, I killed my PilotLamp today. I accidently laoded normal buzzer code while testing the cycletimes and now the Piezo Buzzer is very faint and is useless.

I searched arduino forums and tried solutions with tone() and timers but nothing helps. Right now the pilotlamp code is not suitable for multiwii.
even slow patterns or single beeps get havoc while using gps or gui.

I will leave the branch of the code on server but will not commit it into the trunk because of the problems with cycletime.

Sorry guys, but unless someone donates me a new pilotlamp there will be no more development from me. :-(

Nils