Hey all i am working on a small project where i have three switched that are led lit according to which button is pushed. then i am trying to read a potentiometer using the analog input. what i have found by using the graph in arduino ide is that the pwm is directly influenceing the reading.
When my code first starts up it pulses all three then based on which button that is pushed it only pulses that button.
Using averaging i can get it down to a variance of 3 to 6. the problem is that i only want to output a variable when the pot is moved. Currently using a Hysteresis out put to only out put a variable update if it is above or below 4. It is working ok.
So far i have tried capacitors in a couple spots which helped. Am i expecting to much and should be happy with what i have or is there something i am missing that could improve the performance.
It would help to see a circuit diagram and particularly your code (in code tags please).
Your subject talks about "npn" but the main description never mentions anything like that. You talk about PWM but where, what pins, controlling what? And a variance of 3 to 6 what? What is the "variable" and where do you want to output it to ?
I'd like to help but I'm sorry, I have no real idea what you're talking about.
sorry guys, posted from my phone, as soon as i get home i will upload a schematic.
I would love to post my code... only concern is i have been yelled at, OK scolded, actually just plain told i would get no support because of what i am trying to accomplish... So if you can over look the name of certain variables i can post as is, or else i can modify it to be more... generic?
It was under my question about processing power of a mega. Though i will be honest i wasn't much offended by it, but over on the mbed forum was much worse... i just don't want to be getting my self in trouble.
I guess dangerous is a matter of opinion, some people jump out of planes for fun. The safety protocols i plan on having in place will allow the system to operate with a faulty module or will shut everything down in the event of a malfunction in the motor driver device. Also the reason why there is prototyping, small and moving to something large when proved viable.
Hey as for Arduino being reliable, i have a kureig water filler setup that has been running for almost 2 year never hiccuped once...
Oh and btw this is something different though still dealing with boats lol.
You are right i am not an expert in hardware development or software, but I get safety. I do safety everyday when i am building off-road ad-dons for vehicles.
This is why i am here asking questions, yes i do get it is still the internet and everything should still be taken with a bit of common sense. (i know that is a whole argument in its self)
I get comparing between a motor control system and a water filling system is not the same thing. Everything will break, and if you plan for this then you are a step ahead. Going knowing it will fail and plan for it when developing safety protocols.
First of all i never said it was failure proof, all i meant was that i feel it is not an unstable platform to work with.
Have you ever had a throttle cable stick on a car causing an engine to go full throttle when it was running, had to fix one on a customers vehicle.
Have you ever had a clutch fail, not being able to disengage the engine from the transmission, had to fix one.
Have you ever had a drive line snap in half on a jeep, had to fix that plus the aftermath of the drive-line spinning and braking both rear brake lines.
Have you ever had an ECM fail on a car leaving you stranded on the side of the road.
Have you ever snapped a pit man arm on your truck, leaving you with no steering not being able to control your truck. (this happened to me personal last week, and got luck it broke at a stop light)
I am just trying to point out everything will fail no matter how well it is planned for.
If it would help i could out line the safety protocols that i plan on implementing first before i receive any help?
tinman13kup:
Maybe you should do a little more maintenance, or get better vehicles. None of what you stated started off as inadequate.
Tinman you are very right. All of those examples were caused by either lack of maintenance or modification and used in a way not how they were originally designed, all by customers except the pit-man arm which was mine. still trying to figure out how i broke a 3inch cast piece of steel :o .
But like i said all of them were fixed, the best example was the jeep where adding a skid plate and a drive line hoop he hasn't had any problems since and if he does break another drive-line bashing off rocks it wont take out his brake lines this time.
Delta_G:
But you don't see any passenger cars out there running drive by wire for anything aside from throttle control because even the big boys at the automakers can't get them good enough t pass NTSA. Safety protocols or not, doing dangerous things is still dangerous. It is impossible for you to anticipate any possible failure so it is impossible to say that you've accounted for them all.
I would like to mention mega squirt, should look that up started as a 8bit chip, the latest development was in 2010 using a MC9S12XEP100 and that is used to run engines that could over fuel and create a fiery death....
I feel that we have gotten a bit off topic... i am sorry. i attached a pdf of my current schematic sorry it is kind hard to read slapped it together really quick. so you can see what i am working with.
const int fwButton = A2;
const int ntButton = A3;
const int rvButton = A4;
const int fwLed = 2;
const int ntLed = 3;
const int rvLed = 4;
const int bz = 8;
int brightness = 0;
int fadeAmt = 20;
const long fadeInt = 100;
int fwState = 0;
int ntState = 0;
int rvState = 0;
int shiftState = 0;
//THROTTLE CALL OUTS
const int numReadings = 20;
int readThrottle1[numReadings];
//int readThrottle2[numReadings;
int throttle1Index = 0;
//int throttle2Index = 0;
int throttle1Total = 0;
//int throttle2Total = 0;
int throttle1Average = 0;
//int throttle2Average = 0;
const int throttle1Source = A0;
//const int throttle2Source = A1;
int throttle1 = 0;
//int throttle2 = 0;
int Oldthrottle1 = 0;
//int Oldthrottle2 = 0;
unsigned long previousMillis = 0;
unsigned long currentMillis = 0;
void setup() {
Serial.begin(9600);
pinMode(bz, OUTPUT);
pinMode(fwButton, INPUT);
//pinMode(ntButton, INPUT);
pinMode(rvButton, INPUT);
pinMode(fwLed, OUTPUT);
//pinMode(ntLed, OUTPUT);
pinMode(rvLed, OUTPUT);
for (int thisReading = 0; thisReading < numReadings; thisReading++) {
readThrottle1[thisReading] = 0;
}
beep(50);
beep(50);
beep(50);
}
void loop() {
fwState = digitalRead(fwButton);
ntState = digitalRead(ntButton);
rvState = digitalRead(rvButton);
// throttle1 = analogRead(throttle1Source);
// throttle2 = analogRead(throttle2Source);
if (fwState == 1 && rvState == 0 && ntState == 0) {
shiftState = 1;
analogWrite(bz, 100);
}
if (fwState == 0 && rvState == 0 && ntState == 1) {
shiftState = 2;
analogWrite(bz, 100);
}
if (fwState == 0 && rvState == 1 && ntState == 0) {
shiftState = 3;
analogWrite(bz, 100);
}
if (fwState == 0 && rvState == 0 && ntState == 0) {
analogWrite(bz, 0);
}
// subtract the last reading:
throttle1Total = throttle1Total - readThrottle1[throttle1Index];
// read from the sensor:
readThrottle1[throttle1Index] = analogRead(throttle1Source);
// add the reading to the total:
throttle1Total = throttle1Total + readThrottle1[throttle1Index];
// advance to the next position in the array:
throttle1Index = throttle1Index + 1;
// if we're at the end of the array...
if (throttle1Index >= numReadings) {
// ...wrap around to the beginning:
throttle1Index = 0;
}
// calculate the average:
throttle1Average = throttle1Total / numReadings;
// send it to the computer as ASCII digits
//Serial.println(throttle1Average);
if (throttle1Average > Oldthrottle1 + 4 || throttle1Average < Oldthrottle1 - 4 ) {
Serial.println(throttle1Average);
Oldthrottle1 = throttle1Average;
}
fade();
}
void beep(unsigned char delayms) {
analogWrite(bz, 100); // Almost any value can be used except 0 and 255
delay(delayms); // wait for a delayms ms
analogWrite(bz, 0); // 0 turns it off
delay(delayms); // wait for a delayms ms
}
void fade() {
currentMillis = millis();
if (currentMillis - previousMillis >= fadeInt) {
previousMillis = currentMillis;
brightness = brightness + fadeAmt;
if (brightness <= 0 || brightness >= 255) {
fadeAmt = -fadeAmt;
}
if (shiftState == 0) {
analogWrite(fwLed, brightness);
analogWrite(ntLed, brightness);
analogWrite(rvLed, brightness);
}
if (shiftState == 1) {
analogWrite(fwLed, brightness);
analogWrite(ntLed, 25);
analogWrite(rvLed, 25);
}
if (shiftState == 2) {
analogWrite(ntLed, brightness);
analogWrite(fwLed, 25);
analogWrite(rvLed, 25);
}
if (shiftState == 3) {
analogWrite(rvLed, brightness);
analogWrite(ntLed, 25);
analogWrite(fwLed, 25);
}
}
}
So i hooked up my scope to the circuit, i am finding about a 31.4 to 90ish mV noise on the analog input to the arduino.
I am wondering if the problem is more power supply related, i am not seeing the pattern i thought i saw related to the pwm. Any ideas how to clean that up any more?
Also something else that i noticed was the sizeable spike coming from the due pwm output once and a while. should i be concerned? i am but not sure if i should be.
The Due's analog stuff is poor and the Due is pretty noisy with its on-board DC-DC converter. If you want
decent analog performance a separate ADC/DAC interface on a quiet board with linear regulators
is very worth considering. Besides the Due's only 3.3V for the ADC and the DAC doesn't even
cover the whole of the 0..3.3V range so its essentially useless for most things.
You can of course avoid analog by using a rotary encoder, not a pot. You can even get
hermetically sealed versions that use a magnetic sensing encoder chip.
I personally wouldn't give a standard pot more than a week in a salty marine environment before it
misbehaves... Its the harshest environment for electronics outside of the van-Allen belts!
MarkT:
You can of course avoid analog by using a rotary encoder, not a pot. You can even get
hermetically sealed versions that use a magnetic sensing encoder chip.
I personally wouldn't give a standard pot more than a week in a salty marine environment before it
misbehaves... Its the harshest environment for electronics outside of the van-Allen belts!
I actually originally was going to use a Marine TPS sensor of a newer fuel injection engine, what i have found most are spring loaded potentiometers. The spring loaded part will make it hard to test with. Now i will say they more then likely much better quality potentiometer, but this is what lead me to the idea of using a dual potentiometer and data checking it against itself.
I think for this first design i will stick with what i have, as this is only for theory testing on a bench.
Though i will definitely take a look at an encoder, though if i go this route i will have to add a zeroing switch and would probably also add a max throttle switch so i can perform sanity checks on data before out put.
Oh and i will be ordering a external ADC for continued testing for now.
Delta_G:
What? Do something sensible based on real experience and knowledge about engineering? No, this OP isn't concerned with that. He's got a "safety protocol".
Thanks for asking about safety protocols.
Just a quick outline of what i am planning on doing, is 4 modules all communicating on a can-bus line.
Throttle control - only responsible for reading three buttons to determine direction of motion and a poteniometer for speed control of the motor.
Motor control - only responsible for speed control of the motor
Main ECU - Used to coordinate data and out put to a touch screen
Power shut down- literally just a can bus controlled relay
All the modules will be able to cross communicate. My theory behind this would be to allow for example the throttle unit to fail, but still be able to control the motor using the touch screen. Or if there was a failure say to the can-bus line itself all the units would sense that there is a problem and be able to shut them self down safely.
Like i said just a quick out line, i think i will start another thread over in the projects forum so i can extend this some more.
Thanks for asking about safety.
Obviously Delta you just can't figure out there is this thing called prototyping, got start some where. Maybe the problem is you talk to a lot of people on this forum that plain do not know what they are doing, and there fore you have this attitude that every one is stupid and planing on doing stupid things.
At this point i would like to ask that if you have feeling about this project that makes you uncomfortable in helping, then please refrain from posting your negative attitude about this project. I am open to constructive criticism but at this point i just feel as though you are just trying to harass me.
MarkT, question for you what are your thoughts on a rotary magnetic encoder like magnetic encoder chip looks like it a really good candidate. It would be something that could be buried in epoxy during more finalized versions to completely seal it.
Since this would be for a throttle lever it will only be able to make a sweep of about 130* realistically. At 0.0879º = 4096 positions per revolution would give me 1479 steps for 130*. I think that would be a pretty good resolution.
The device also has internal error checking, so if the magnet was to fall off it will not update.
It also will provide an absolute position per 360* which i like for the fact that when first booted it would know where the handle is and be able to prevent direction control if the handle is in any other position then zero throttle.
