XAircraft Pilot Lamp Accessory Hack

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

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

Sorry to hear that the Pilot Lamp died. These sort of unexpected events can really be frustrating!

- Thomas

jevermeister · Post by **jevermeister** » Wed Aug 15, 2012 9:46 am

I wonder what is broken,
the speaker is very silent, but the whole module is still working, patterns are blinking and buzzing correctly...

Hamburger · Post by **Hamburger** » Wed Aug 15, 2012 9:57 am

the speaker itself maybe?

KeesvR · Post by **KeesvR** » Wed Aug 15, 2012 12:41 pm

Got my Pilotlamp yesterday

I hope you find a way to go on with your good work.

Maybe I wanna donate you a new one. :mrgreen:

jevermeister · Post by **jevermeister** » Wed Aug 15, 2012 12:50 pm

http://ncopters.blogspot.com ->Paypal button "Spenden"
But beware, it is pretty rusty cause noone used it :-(

Nils

KeesvR · Post by **KeesvR** » Wed Aug 15, 2012 1:00 pm

Oke, you've got it. :mrgreen:

http://www.ebay.com/itm/ws/eBayISAPI.dl ... 1054020131
I got this one in 10 days.

The code from 2 hours ago, is it working anyway?

I just came here to look for some improvements on this.

jevermeister · Post by **jevermeister** » Wed Aug 15, 2012 1:49 pm

I uploades a new revision of the ndroiid version today.
i will upload the same code without my config.h changes this evening.
it is working as best as possible with the current signal generation.

thank you for the donation

nils

KeesvR · Post by **KeesvR** » Wed Aug 15, 2012 2:57 pm

Is it possible to place a complete zipped version, its easier for me.

jevermeister · Post by **jevermeister** » Wed Aug 15, 2012 9:07 pm

sorry svn is not working right now. cannot commit or upload.

jevermeister · Post by **jevermeister** » Thu Aug 16, 2012 10:24 pm

Problem solved.
I updated the SVN to the final beta:

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

I also uploaded a Zip File:

https://dl.dropbox.com/u/9886652/MultiWii_2_1_PLbeta.zip

KeesvR · Post by **KeesvR** » Fri Aug 17, 2012 3:08 pm

Thanks Nils, I'm gonna try it.

Tazzy · Post by **Tazzy** » Tue Sep 11, 2012 6:04 pm

I really like this pilot lamp on my quad and hexa i hope it can get in the sharpcode ....

doughboy · Post by **doughboy** » Sat Sep 29, 2012 8:21 pm

is this feature not in the main shared code?

I just got my pilot lamp. smaller than I expected

jevermeister · Post by **jevermeister** » Sun Sep 30, 2012 12:51 am

Due to the fact that the current communication of the lamp is very laggy and depends on cycletime I did not dare to commit it. I will have a look an hambirgers cycletime fix and think about it. I think Alex and the community should decide. I will contac alex.

doughboy · Post by **doughboy** » Sun Sep 30, 2012 1:03 am

I dd the merge and it works fine. I only have gyro+accel and my cycle time is around 2500-2600 only. Cycle time increased to 2800-2900 with pilot lamp. Does the cycle time get too high with more components like GPS, Baro, etc.?

jevermeister · Post by **jevermeister** » Sun Sep 30, 2012 9:17 am

I had serious problems with serial gps. The lamp did weird stuff like beeping forever.
Please contact alexinparis and ask for his opinion on that.

Alexinparis · Post by **Alexinparis** » Sun Sep 30, 2012 6:29 pm

I think the way to control this device is not clean.
It should be interrupt based to be independent from cycle time.
But as long as it doesn't interfere with other code (via a proper #define, and not a single bit dif when not defined) you can integrate it if you want.

jevermeister · Post by **jevermeister** » Sun Sep 30, 2012 9:20 pm

I tried different approaches but the current "hack" is the only one that does not intercere with the code. I thougt about using pwm output but I am not into that subject and I believe pwm outputs are to rare for that. We need an output that will keep its cycle stable.any ideas

doughboy · Post by **doughboy** » Mon Oct 01, 2012 6:31 pm

as far as using interrupts, timer0 is available if using quad for promini (I only looked at promini code since I have atmega328). I think there is one counter left if you have a quad + servo for camera stab.
is the control signal based on frequency and not pulse width?

jevermeister · Post by **jevermeister** » Mon Oct 01, 2012 6:49 pm

You have to send three full periods of a given frequency to trigger a function of the lamp. I have to admit,that I am not good enough to code that with timer or counters.
The current solution does that with a for, and this is affected by cycletime. Please have a lool at alarms.ino on my branch. It is very simple. Every aspect of the lamp has its specific frequency.

Nils