ADCInput Issues

[bridge2nowhere]

I'm working on a physical device to keep track of the moons of Krynn for a Dungeons and Dragons game. I ran the example ADCInput (mike test) code, and it worked fine with my potentiometer. When I attempted to add it into my main code, it was giving a value but wasn't responding to changes to the potentiometer. My first thought was some sort of SPI conflict, but after reading the doc, I think I have a buffer/frequency problem. I doubt I need to be reading at 8000hz for a potentiometer, but I'm not sure how to move forward.

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include "Adafruit_ThinkInk.h"
#include <Adafruit_ST7789.h>
#include <ADCInput.h>

#include "font.h"
//Moon_Phases_32
//Redressed_Regular_16
//Redressed_Regular_24

//Knobs////////////////////////////
ADCInput moonPot(29);
#define ENC_CLK 24
#define ENC_DT 25
/////////////////////////////////


//TFT/////////////////////////////
#define TFT_CS        27
#define TFT_RST        28 // Or set to -1 and connect to Arduino RESET pin
#define TFT_DC         26
Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_RST);
/////////////////////////////////


//eInk///////////////////////////
ThinkInk_290_Grayscale4_T5 display(10, -1, 9, 8, -1);
#define COLOR1 EPD_BLACK
#define COLOR2 EPD_LIGHT
#define COLOR3 EPD_DARK
/////////////////////////////////



//Program Mode Mangement///////////////////////
enum class moonMode : uint8_t
{
  Nui, Luni, Soli, Menu
};
moonMode moon = moonMode::Soli;
char* nameOfAddress = "Milord";
///////////////////////////////////////////////


void setup() {
  
  Serial.begin(115200);

  tft.init(240, 240);
  tft.fillScreen(ST77XX_RED);

  moonPot.begin(8000);

  display.begin(THINKINK_MONO);
}

void loop() {
  potValue = moonPot.read();
  Serial.println(potValue);
  if(potValue > 3000) moon = moonMode::Soli;
  else if(potValue < 1000) moon = moonMode::Nui;
  else moon = moonMode::Luni;
  
  //update the callendar and moon phases
  calUpdate();
  
  //write new text to the eink panel
  panelUpdate();
  
  //update the tft with the current moon phase
  moonLightUpdate();
  
  
  delay(1000);
}

[earlephilhower]

Without an MCVE there's not much to go on here

Some general things to check are if any of your other libraries are using hard coded interrupts out DMA channels, effectively breaking the ADC lib. Also, if the disable interrupts for a very long time you could end up overflowing and having the DMA ping pong die. Of course, pin conflicts may also be in play if you're using a pin that's connected to the SPI port those libraries use.

[bridge2nowhere]

Here is an MCVE, I'm relatively new, thank you for your patience. This is lagging about 8 seconds behind.

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_ST7789.h>
#include <ADCInput.h>



ADCInput moonPot(29);

Adafruit_ST7789 tft = Adafruit_ST7789(27, 26, 28);


void setup() {

  Serial.begin(115200);

  tft.init(240, 240);
  tft.fillScreen(ST77XX_RED);

  moonPot.begin(50);
}

void loop() {
  Serial.println(moonPot.read());
  delay(50);

}

[Andy2No]

I'm not familiar with the ADCInput method, but is there a reason you're using an audio buffer to read a pot? Wouldn't analogRead(29) be enough? That returns an immediate value, without any buffering, so there'd be no lag.

In the original example, you were using a pot to choose one of four states, I think. I'd suggest just dividing the range of the analogRead() value into 7 regions, maybe not all the same size, with four valid ranges and three dead bands between them - a new output value should then only be accepted for a reading outside one of the dead bands. Without using dead bands, you could expect to find knob positions where it randomly chooses between either of two values, due to noise.

Possibly what's happening in the MCVE is that you're reading behind the buffer filling, and it's only filling at 50Hz, if I'm understanding that correctly. I'm not clear how big the buffer is, but perhaps you're reading, say, 200 or 256 samples behind the incoming data? That would cause a few seconds lag.

If you want to keep using that method, maybe increasing the sampling rate will reduce the lag time... or specifying a smaller buffer, if that's possible.

[maxgerhardt]

Sampling at 50Hz using moonPot.begin(50); and then only reading every 50ms (which is a frequency of 20Hz, neglecting the serial print) is making it lag behind, yes. Using the ADCInput.h library for reading a potentiometer is overkill, it's meant for sampling audio signals into a buffer continuously using DMA (and consuming it fast :))

Just make

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_ST7789.h>
const int moonPot = 29;

Adafruit_ST7789 tft = Adafruit_ST7789(27, 26, 28);

void setup() {
  Serial.begin(115200);
  tft.init(240, 240);
  tft.fillScreen(ST77XX_RED);
}

void loop() {
  Serial.println(analogRead(moonPot));
  delay(50);
}

[Andy2No]

Did you mean it doesn't respond at all, or just that it's laggy?

delay(1000); gives a one second update period, which will seem very unresponsive. Radio control for models typically uses a 50Hz update rate, which is 20 milliseconds, so that would be delay(20); in your loop, not allowing for how long the other code takes to execute. That's a good rate to aim for, to make it feel interactive. A little slower would seem okay, but one second is too much.

FWIW, the RP2040 ADC inputs are quite noisy and non-linear. You might find you need to add some code to smooth out the response a bit, or maybe consider an external ADC chip or module. There are some good analyses of how they behave, and the Raspberry Pi organisation acknowledged that there's a problem. In theory they can give about 9 bits of resolution, correcting for noise and errors. Maybe there's some library code available to do that, by now.

[bridge2nowhere]

I'm not familiar with the ADCInput method, but is there a reason you're using an audio buffer to read a pot? Wouldn't analogRead(29) be enough? That returns an immediate value, without any buffering, so there'd be no lag.

In the original example, you were using a pot to choose one of four states, I think. I'd suggest just dividing the range of the analogRead() value into 7 regions, maybe not all the same size, with four valid ranges and three dead bands between them - a new output value should then only be accepted for a reading outside one of the dead bands. Without using dead bands, you could expect to find knob positions where it randomly chooses between either of two values, due to noise.

Possibly what's happening in the MCVE is that you're reading behind the buffer filling, and it's only filling at 50Hz, if I'm understanding that correctly. I'm not clear how big the buffer is, but perhaps you're reading, say, 200 or 256 samples behind the incoming data? That would cause a few seconds lag.

If you want to keep using that method, maybe increasing the sampling rate will reduce the lag time... or specifying a smaller buffer, if that's possible.

Somewhere along the way I picked up the nototion that analogRead didn't work and I needed to use the ADCInput library. That worked fine for my application, no buffer needed.

[maxgerhardt]

Great to know, can you mark this answer as the solution?