Potential bug, OLED with Spektrum Sat?

[Arakon]

I have a mini quad with MWii 2.3 (not sure about the exact revision, half a year old) on a selfbuilt Pro Mini based FC, which is using an Orange Spektrum satellite. Works absolutely great, up until you enter config mode for the OLED by stick combo. The stick combo works, the config menu is triggered on the OLED, but the controls stop responding then. If I use a standard RX, control works fine.

[Hamburger]

No. Not related. I have 3 copters with combo of sat and i2c display working fine.
With sat I find it is difficult to reach endpoints. Check in gui and tweak your tx endpoints to get close to 1000 and 2000.

[Plüschi]

Cat1 did report the same issue in this thread:
viewtopic.php?f=8&t=5490

I dont have an OLED so i cant verify.

I think it has to do with the calling sequence, readSpektrum(); likes to be called periodically every 1 to 5 ms, while readRawRC(chan) should only be called if spekFrameDone flag is set. spekFrameDone means data is ready. Same for sumd and sbus receivers.

[Arakon]

The end points are set up properly (although I did have to go up to 144% for throttle to reach 2000. Maybe some scaling would help? On the KK board, I only had to go to a max of 115% on any channel to hit 100% each direction). Telemetry switching is working with sat, so I can see the endpoints on the display. It's only the settings that stop responding to input as soon as you enter them with a sat.

[Cat 1]

I can confirm that I saw this same bug with SumD receiver integration on a 328 board... Never did find a solution but my workaround was to limit the number of serial input channels to 5 and it got better... Still not perfect though.. ODD behaviour when OLED is attached... Flies perfect though.

[Plüschi]

I did order an oled from banggood to check this problem. Arrived today. I did store it somewhere

and I CANT FIND IT ANY MORE ! Fuuuuuu.... WTF did i store that ?

[Hamburger]

I did order an oled from banggood to check this problem. Arrived today. I did store it somewhere

May I suggest next time before ordering oled to check out the digole displays - those come with onboard character set and in different sizes; plus MWii supported

[Plüschi]

Next time i will consider a digole.

I did find my OLED again. I had stored it in the FPV bin

Original code doesent seem to work. I did add a delay and some code and now it works. For me its glitch-free, i dont see the glitches reported by Cat1.

LCD.cpp, configurationLoop(),
instead of

Code: Select all

#if defined(SPEKTRUM)
      readRawRC(1); delay(44); // For digital receivers like Spektrum, SBUS, and Serial, ....
#endif

i use

Code: Select all

    #if defined(SPEKTRUM) || defined(SBUS) || defined(SUMD)
      delay(10);
    #endif
    #if defined(SPEKTRUM)
      if (spekFrameFlags == 0x01) readSpektrum(); 
    #endif
    #if defined(SBUS)
      if (spekFrameFlags == 0x01) readSBus();
    #endif
    #if defined(SUMD)
      if (spekFrameFlags == 0x01) readSumD();
    #endif

Edit:
The problem seems to be the 60ms delay for the oled in ConfigRefresh().
readSBus(); or similar wants to be called every few ms. 60ms is to slow.

The problem can be avoided by doing the whole lcd check / write stuff only every 60ms, while doing the readSBus(); or SerialRead() stuff full speed.
For this delete the delay(60) from ConfigRefresh() and change the loop as follows:

Code: Select all

  while (LCD == 1) 
  {
    #if defined(SPEKTRUM)
      if (spekFrameFlags == 0x01) readSpektrum(); 
    #endif
    #if defined(SBUS)
      if (spekFrameFlags == 0x01) readSBus();
    #endif
    #if defined(SUMD)
      if (spekFrameFlags == 0x01) readSumD();
    #endif
    #if defined(LCD_TEXTSTAR) || defined(LCD_VT100) || defined(LCD_TTY) // textstar, vt100 and tty can send keys
      key = ( SerialAvailable(LCD_SERIAL_PORT) ? SerialRead(LCD_SERIAL_PORT) : 0 );
    #endif
    #ifdef LCD_CONF_DEBUG
      delay(1000);
      if (key == LCD_MENU_NEXT) key=LCD_VALUE_UP; else key = LCD_MENU_NEXT;
    #endif

    actTime = millis();    
    if (actTime >= nextTime)
    {
      nextTime = actTime + 60;   
      if (refreshLCD) {
        ConfigRefresh(p);
        refreshLCD = 0;
      }    
      for (i = ROLL; i <= THROTTLE; i++) {uint16_t Tmp = readRawRC(i); lcdStickState[i] = (Tmp < MINCHECK) | ((Tmp > MAXCHECK) << 1);};  
      
      if (IsMid(YAW) && IsMid(PITCH) && IsMid(ROLL)) allow_exit = 1; 
      if (key == LCD_MENU_SAVE_EXIT || (IsLow(YAW) && IsHigh(PITCH) && allow_exit))   LCD = 0; // save and exit
      else if (key == LCD_MENU_ABORT || (IsHigh(YAW) && IsHigh(PITCH) && allow_exit)) LCD = 2;// exit without save: eeprom has only 100.000 write cycles
      else if (key == LCD_MENU_NEXT || (IsLow(PITCH) && IsMid(YAW))) { //switch config param with pitch
        refreshLCD = 1; p++; if (p>PARAMMAX) p = 0;
      } else if (key == LCD_MENU_PREV || (IsHigh(PITCH) && IsMid(YAW))) {
        refreshLCD = 1; p--; if (p == 0xFF) p = PARAMMAX;
      } else if (key == LCD_VALUE_DOWN || (IsLow(ROLL))) { //+ or - param with low and high roll
        refreshLCD = 1;
        lcd_param_def_t* deft = (lcd_param_def_t*)pgm_read_word(&(lcd_param_ptr_table[(p * 3) + 2]));
        deft->type->inc((void*)pgm_read_word(&(lcd_param_ptr_table[(p * 3) + 1])), -(IsHigh(THROTTLE) ? 10: 1) * deft->increment);
        if (p == 0) conf.pid[PITCH].P8 = conf.pid[ROLL].P8;
      } else if (key == LCD_VALUE_UP || (IsHigh(ROLL))) {
        refreshLCD = 1;
        lcd_param_def_t* deft = (lcd_param_def_t*)pgm_read_word(&(lcd_param_ptr_table[(p * 3) + 2]));
        deft->type->inc((void*)pgm_read_word(&(lcd_param_ptr_table[(p * 3) + 1])), +(IsHigh(THROTTLE) ? 10 : 1) * deft->increment);
        if (p == 0) conf.pid[PITCH].P8 = conf.pid[ROLL].P8;
      }
    } // time
  } // while (LCD == 1)

And .. this OLED stuff is NICE !

[Plüschi]

Unluckily and "as usual" no one of the devs gives a crap about correcting this bug.

[Alexinparis]

"as usual" you missed one update.
https://code.google.com/p/multiwii/source/detail?r=1720
The proof I care

Reading the begening of your code, I see: readSpektrum(), readSBus(), readSumD() which are no more used.
So your code probably solve some aspects regarding timing (I've no way to check personnaly, I don't use serial rx type) but no way to integrate something based on obsolete code.