Teensy Joystick with digital and analog grounds. Tried external power supply, no Joy.

A

AMaraklov

Active member
What I'm trying to do is get a joystick with 3 analog pedals, X, Y, Z to read as well as all 6 buttons and so forth. It's a lot of amperage for a Teensy as each pedal is a 5K pot, when I hooked this up it immediately shut down, if I removed the pots or connected only one pot it worked.

So I cut the trace for 5V, and then I ran an external adjustable 5v power supply to the teensy. I had the analog return hooked up the teensy and the teensy's ground hooked to the power supply's ground, the teensy overheated after about 30 sec.

So since the power supply has 3x 5V sources and 3x grounds, I used 2 sources and 2 grounds, 1x 5v for the teensy and 1x 5v for the 5k Pots (In parallel). With the variable arm to go into the teensy's analog pins A0-A2.

This seems to give no real readable values... 1023 across 2 pots, and some wild values for the third (slider)... everything from 100-900 but no sequential or consistent values.

In this scenario, how should this be wired? What am I missing and is 3x 5k pots, +9 buttons that much to handle?
 
Last edited:
Warning I am a retired Programmer say take any of my EE related answers with a grain of salt

What I have done in past is to look at the resistance of the pots and see what the min/max values are and if they get down near zero then...

I do something like this crude diagram:

+3v
|
Fixed Resistor
|
Pot/slider --- Analog pin
|
gnd

Or I might put the resistor after pot before gnd...

And then there will always be resistance. As for the values of the resistor, It will probably depend on range of pot...
You might plus some values into resistor divider calculator to see what works for you: https://ohmslawcalculator.com/voltage-divider-calculator
 
The pots are 5k for like 270-350 degrees, and I'm using 1/4-1/8 of that or less as the gas pedals only move the pot 45-90 degrees... so right now I have it where it's about 0 ohms 20 ohms at rest and then about 600-100 ohms at full deflection, that's why I need a teensy, as if I use a arcade controller I'll never get full deflection out of it. So with the teensy I can add a multiplier to get the PC to think it's a valid 0-100% joystick value.

The issue as I perceive it isn't about a base resistance, but about the fact that I've departed from the USB connection for power, and am wondering how that impacts the functionality of the A-D converter if it doesn't share a common ground... or the analog ground.

But I understand what you're getting at, and I appreciate the help, I just don't think it will resolve my problem.
 
AMaraklov said:
In this scenario, how should this be wired? What am I missing and is 3x 5k pots, +9 buttons that much to handle?
Click to expand...

@AMaraklov:

You didn't say which Teensy you're using (else I simply missed it). Only some of the Teensy models are 5V tolerant. On the remainder, the maximum you can apply to the input pins is 3.3V. Hopefully, you haven't exceeded the tolerance on your particular model.

Mark J Culross
KD5RXT
 
Sorry yeah I forgot that detail, it's a 3.2 so 5v tolerant.. otherwise it wouldn't be functioning anymore, I made that mistake a while back, but in the opposite direction, buying sensor components that needed 5v and I had to supply them separately, and then just running the data cables back to the teensy, which is why I thought this would work similarly, where I provide 5v and ground to the pots and then just read the return voltage. But somehow that's not working, and I wonder if its something to do with my understanding of the principals on how the teensy reads analog voltages, as in it has to provide the input, and the ground to understand the return value, or that I made a mistake in my wiring.

-AM

P.S. So even though I've joined the forums, I've been using teensy boards since 2014 or so... so it's not my first project but somehow I couldn't find a thread which explained how to setup two sources of power one for the sensor voltage and one for the teensy.
 
So as is typical in any situation where I'm stumped I was looking at several culminating circumstances.
For One one of the positive wires on the analog side was touching the analog ground causing a short, but only when certain stresses were on the positive wire for one of the strands to go over causing the short, hence I didn't catch it as this was not the case on the bench only when in circuit. Also calculating max current draw for 3x 5k Ohm Pots at max was 3milliamps @ 5v so negligible. One of the pots had been shorted (melted) so we're talking 10's to 100's of Megaohms which was another problem. Once those were cured, I found that for some reason once of the digital quadrature signals was causing the analog readings of the pots to jiggle back and forth so I installed 2 diodes one for analog and one for digital so I can make sure there's no cross talk... I haven't proven out the diodes yet, but we'll see what happens tomorrow. Thanks for sticking with me, I hope this helps someone else troubleshoot.
 
So I'm back at it... I get this odd issue... this one I've isolated down several ways...
I have 3 Mouse Axes that I need to worry about... X,Y,and Z I know why Z? Well it's complicated I need 3 "Spinner" Type controls, and Mice typically have 3 axis when you think about it, X,Y naturally and then the scroll wheel is 3... So I'm using 3 encoders...
Code: 
/* 3 Mouse Axis Encoder Profile

*/
#include <Encoder.h>


Encoder encRed(0,1);
Encoder encYellow(2,3);
Encoder encBlue(4,5);

// Mouse Sensetivity for all 3 axis as it's presumed you're using the same type of encoders
static int multiplier = 1;

void setup() {
  // you can print to the serial monitor while the joystick is active!
  Serial.begin(9600);

}

//Set Default Movement Values for mouse axis
long positionRed  = -999;
long positionYellow = -999;
long positionBlue = -999;

//Encoder History
int newRedEnc, newYellowEnc, newBlueEnc;
int oldRedEnc, oldYellowEnc, oldBlueEnc;

void loop() {
  // Read The Encoders
  
  newRedEnc = encRed.read()*multiplier;
  newYellowEnc = encYellow.read()*multiplier;
  newBlueEnc = encBlue.read()*multiplier;
  Serial.println(newBlueEnc);

  // Update Mouse position(s) if it's changed
  if ((newRedEnc - oldRedEnc) != 0){
    Mouse.move(newRedEnc - oldRedEnc, 0);    
  }
  if ((newYellowEnc - oldYellowEnc) != 0){
    Mouse.move(0, newYellowEnc - oldYellowEnc);    
  }
  if ((newBlueEnc - oldBlueEnc) != 0){
    Mouse.scroll( newBlueEnc - oldBlueEnc);    
  }
     
  // a brief delay, so this runs "only" 200 times per second
  delay(2);

  oldRedEnc = newRedEnc;
  oldYellowEnc = newYellowEnc;
  oldBlueEnc = newBlueEnc;
  
}

The net result is that X,and Y get passed on very quickly and are buttery smooth, yet the Scroll Wheel seems to be buffered or something it lags behind, and tends to jump over values in an attempt to catch up.
I have tried a teensy 4.1 as I understood that teensy 3.2 has some limitation on the number of encoders it can support. I tried with just one encoder connected as not to overload the bus, or get erronious events, no change. I also went on to QuadratureEncoder.h tried that, but the issue there is I'd need to get something to then give me relative counters, as I can't find an example that takes the quadrature signal 1,0 or -1,0 and gives me a signal, maybe I need to chase that down,to look at the data stream and see if I get 1 then 0 or 0 then 1 and increment my own counter appropriately. I guess I got spoiled with Encoder.Read() to get me the values I'm looking for...
Either way I don't see any issues in the Encoder.Read() function, as when I log them I get sequential numbers, difficult to test on a log if they're buffered or not, but they seem consistent. The issue seems in the mouse implementation, as I think the behavior in Mouse.Scroll() seems to be different than Mouse.Move(). So even if I use QuadratureEncoder.h I'd have issues passing that along.

Any pointers or suggestions would be appreciated.
 
So Looking into QuadEncoder.h I found something odd...

With this code:

Code: 
// http://www.pjrc.com/teensy/td_libs_Encoder.html
//
//This example code is in the public domain.
//

#include "QuadEncoder.h"
int pullup = 1; // Weather or not to use a pullup resistor

// Change these pin numbers to the pins connected to your encoder.
// Allowable encoder pins:
// 0, 1, 2, 3, 4, 5, 7, 30, 31 and 33
// Encoder on channel 1 of 4 available
// Phase A (pin0), PhaseB(pin1), 
QuadEncoder knobA(1, 0, 1, pullup);
// Encoder on channel 2 of 4 available
//Phase A (pin2), PhaseB(pin3), Pullups Req(0)
QuadEncoder knobB(2, 2, 3, pullup);
//
QuadEncoder knobC(3, 4, 5, pullup);
//   avoid using pins with LEDs attached

void setup() {
 Serial.begin(9600);
 Serial.println("TwoKnobs Encoder Test:");
 /* Initialize Encoder/knobLeft. */
 knobA.setInitConfig();
 //Optional filter setup
 knobA.EncConfig.filterCount = 5;
 knobA.EncConfig.filterSamplePeriod = 255;
 knobA.init();
 /* Initialize Encoder/knobRight. */
 knobB.setInitConfig();
 knobB.EncConfig.filterCount = 5;
 knobB.EncConfig.filterSamplePeriod = 255;
 knobB.init();

 knobC.setInitConfig();
 knobC.EncConfig.filterCount = 5;
 knobC.EncConfig.filterSamplePeriod = 255;
 knobC.init();
}

long positionA  = -999;
long positionB = -999;
long positionC = -999;

void loop() {
 long newA, newB, newC;
 newA = knobA.read();
 newB = knobB.read();
 newC = knobC.read();
 if (newA != positionA || newB != positionB || newC != positionC) {
   Serial.print(" A = ");
   Serial.print(newA);
   Serial.print(", B = ");
   Serial.print(newB);
   Serial.print(", C = ");
   Serial.print(newC);
   Serial.println();
   positionA = newA;
   positionB = newB;
   positionC = newC;
 }
}

I get this result when I change the leads from pins 0 & 1 to 2 & 3 I'm not sure if I need to configure the Pins to something like interrupts when I set them up... as they're identical setups...

Code: 
A = 0, B = -1, C = 1720
 A = 0, B = 0, C = 1720
 A = 0, B = -1, C = 1720
 A = 0, B = 0, C = 1720
 A = 0, B = -1, C = 1720
 A = 0, B = 0, C = 1720
 A = 0, B = -1, C = 1720
 A = 0, B = 0, C = 1720
 A = 1, B = 0, C = 1719
 A = 1, B = 0, C = 1720
 A = 0, B = 0, C = 1720
 A = 0, B = 0, C = 1719
 A = 1, B = 0, C = 1719

It's very odd, as when I use pins 4&5 I get 0-1 on A and Values on C, and when I use pins 2&3I get just the middle value...
They all share the same 5v and ground pins... but I'm not making progress... checked my code, but maybe I'm cross eyed now and I can't see my mistake
 
Last edited:
So the odd values were because I had a open lead on one of the encoders and didn't realize it, so when you see just one side go off -1 or 1 and 0, you don't have both leads firing.
Also I didn't see that pin 0 and 5 share a signal, so I had to move 5 to pin 7, so my current setup is 0-1 2-3 4-7 for the three encoders...
Something is still off no matter what encoder I use or if I use Teensy 3.2 or 4.1 when I pipe the encoder into the mouse wheel I get odd behavior in the application, each one is looking for a steering wheel, and X and Y mouse axis are working fine, and then when I use the mouse wheel for the third axis I get stuttering where the input is either behind, and or jumping values... especially when moved quickly. I still don't think Teensy's mouse libraries are implemented the same on all 3 axis... and at extreme speeds they jump. I tried multiplying the values down by 90% to see if I could see it in a slower version. Then it hardly Moves, at 50% it still exhibits this odd behavior. I'm at the point where I may just need to use another teensy and assign it just 1 axis... as I can't make it work with the mouse implementation as written.
 
You must log in or register to reply here.
Back
Top