Show Posts
Pages: [1] 2 3 ... 8
1  Forum 2005-2010 (read only) / Troubleshooting / Re: Help needed for interfacing a car with Arduino on: May 12, 2009, 05:36:37 pm
Again, without more details about your sensors, I can only give generic pointers.

Speed and RPM will be in the form of a pulse train. But the amplitude of the pulses will be near 12 volts, so you will still need to limit these signals to 5 volts, even though you are only interested in the frequency and not the amplitude.
Damage to your Arduino could result if you do not do this.



If you have a sensor giving 'spurious' values (without any actual input), it is most often caused by leaving an input 'floating'.

A high impedance input (such as the Arduinos) can, and will, respond to stray signals, such as the AC power field and radio frequencies... or even the capacitance of your hand.

It is general practice to connect the input to ground through a rather high value resistor... much higher than the output impedance of the sensor, but well below the impedance of the input. This will help prevent these 'spurious' readings.

For example, suppose that your fuel level sensor is connected to the Arduino analog 0.
A typical fuel level sensor has an output impedance of much less than 500 ohms.
While the input impedance of the Ardunio analog input is specified to be around 100 million ohms.
So you might connect a resistor, from analog 0 of your Arduino to ground, of 68000 ohms resistance.
Then, in the case no sensor is present, this will ensure that the analog input is 'pulled down' to 0 volts, yet will not contribute any detectable error when the sensor is actually connected.

If you are 'bench testing', use a potentiometer, of the same impedance as your sensor, to simulate the 'real world' signal. In the case of the fuel level sensor, a 500 ohm or even 1000 ohm pot would probably work OK.



In the case where 'real' values are shown as whole numbers, this usually happens when an integer variable is used, where a float value should be used instead.


One more bit of friendly advice.

In your original post you stated that you wanted to test the program itself first, and then work with the sensors.

Might I suggest that you try it the other way around?

Write test programs for your sensors, one at a time until you are certain of your understanding of the sensor and code.

After you have confidence in the individual items, then integrate them into a whole program.

In this way you make your problem space smaller. 'Divide and Conquer!'.
2  Forum 2005-2010 (read only) / Troubleshooting / Re: Help needed for interfacing a car with Arduino on: May 08, 2009, 07:27:54 am
Without some more information about the project, I can only offer generic advice.

There are several things you must keep in mind when interfacing with vehicular equipment...


That 12 volt power supply, IS NOT 12 VOLTS. In a healthy car, the voltage can range from 9 to 15 volts, and if there is a problem with battery, alternator, or voltage regulator you can just toss out any random number between 0 and 50. Protect your Arduino!

That 12 volt power supply IS NOISY! And that noise is all over the spectrum. You must filter the signals well.


The standard sensors are ratiometric... their output is a percentage of power supply voltage. You can't count on, for example, 8 volts out of the oil pressure sensor equalling 40 psi all the time.

And, since they are ratiometric, you can't connect them directly to your 5 or 3 volts Arduino. You need to scale the signal down.


The environmental conditions are terrible. Temperatures from way below freezing, to nearly boiling, are very common occurances. Humidity from bone dry to dripping wet. And vibration. Did I mention vibration?  Vehicles move. Seal, secure, and ventilate!


To scale and filter, use a voltage divider along with a capacitor to ground.

For a 5 volt Arduino, a 240 ohm resistor in series with a 120 ohm resistor is a good choice, in most cases. This will scale a 15 volt signal down to 5 volts. Use the the best precision resistors, with the lowest temperature coefficient, that you can buy, beg, borrow or steal.

Include a capacitor in parallel with that 120 ohm resistor. The value depends on how often you must sample the signal, but as a point of reference start with .1 uF capacitors.


3  Forum 2005-2010 (read only) / Troubleshooting / Re: Maximum analogRead() poll rate? on: January 19, 2010, 08:12:59 pm
The first conversion after reset, and the first conversion after switching ADC channels, takes almost twice as long as following conversions.

One reason for this is simply to allow multiplexer switching transients time to settle.

The Arduinos default conversion time is about 112 microseconds (just measured it on a 16 mhz Duemilanove).



Side note:

I believe a previous commentator assumed that Arduino uses a 'trick' commonly used by hardware that lacks dedicated ADC.

Integrating ADCs have a conversion time directly dependent on the signal magnitude.

A Successive Approximation ADC (such as used in the Arduino) has a conversion time independent of the signal magnitude.

4  Forum 2005-2010 (read only) / Troubleshooting / Re: Cant find USB port in serial ports!? on: November 02, 2009, 09:06:13 pm
I have found that this problem often occurs when a manufacturer provides a 'customized' USB driver for a device, without similarly 'customizing' the USB chip they use.

Case in point. Promethean boards (similar to Smart Boards, i.e. huge wall mounted digitizer tablets) use an FTDI USB-Serial chip, and they provide a customized driver.

But, they do not program in their own Vendor ID into the FTDI chip. Actually, they do not HAVE their own VID   (Perhaps they do not have the $1500 it takes to get one?)

Upshot is...  their driver takes control of any 'factory' FTDI chip... they ignorantly (or arrogantly) assume that if it's and FTDI chip, then it must be a Promethean board, and their driver takes control.

(To be fair, the latest version of their driver will release the endpoint after a very long time, but this behavior has been causing all sorts of problems for a lot of folks.)

I may be able to help if you will PM me.



5  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Lcd 2x16 Hd44780 init on Power on on: November 02, 2009, 10:40:06 pm
The IDe version 17 is indeed correct, in as much as it correctly waits for a Hitachi 44780 to complete its power up sequence, and then correctly initializes the display.

Logically and temporally correct.

For a Hitachi HD44780.

The problem is all these 'clones' of the HD44780 that are being marketed. Many, if not most, just aren't up to snuff.
In particular they don't complete their powerup sequence nearly as quickly as the 'real deal'.

This is not a problem with the library. It just needs to be made clear that the library targets a genuine, Hitachi, HD44780, and use with any other chip may require timing adjustments.

I have used the (newest, IDE v 17) library with at least a couple dozen displays that were clones... and on all but a couple I had to add additional time for them to power up. Eventually I just got in the habit of calling delay(1000) before 'begin()'.

I have seen this complaint  crop up a lot on these forums. The only real answer is to let people know they may need to add more time before trying to communicate with their particular display.

Another problem I have seen with some displays is that they 'forget' that they are in 4 bit mode if they are not 'exercised' for a while.

The first one drove me absolutely nuts! I was convinced there was a power problem, dropouts or spikes.
I put it on a lab power supply and put a 50 Mhz rate storage scope across the power leads. Never saw a glitch, but after idling a while, the next attempt to write would cause either garbage or a blank display.

So I experimented with delays. Count up, print(count,DEC), delay(n). When the delay reached about 700 seconds, glitch city.

So now I always put in an idle function, and reset 4 bit mode after 1 minute of inactivity. Between the initial 1 second delay and the inactivity timer, it seems to have 'fixed' the problem... (knocking on wood).
6  Forum 2005-2010 (read only) / Syntax & Programs / Re: Extended Ascii via serial.print ? on: January 15, 2010, 05:58:45 pm
In 'Standard' ASCII, the maximum character code is 127 (hex ff)

The definition of 'Extended' ASCII depends on who is extending it... in other words there really is no one single code you can use for the degree symbol.
7  Forum 2005-2010 (read only) / Syntax & Programs / Re: How fast can I use PID? Should I use it at all? on: October 10, 2009, 08:54:50 am
Not sure about this given what little information was in the post, but it sounds like a PID control won't be of much help.


Are you trying to maintain a consistent tension? If so, a simple slip clutch will work much better.
8  Forum 2005-2010 (read only) / Syntax & Programs / Re: Process Control Interface on: May 27, 2009, 07:01:59 am
Google for Ladder Logic Language. It's the defacto standard, and one of the first things a process control tech learns.
9  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing a Senseair K22 Co2 NDIR Sensor via PWM on: November 03, 2009, 08:14:17 am
900 PPM may seem high in relation to the mean atmospheric level.
 
But indoors, PPMs from 800 to 1000 are common.

As a matter of fact, guidelines for HVAC systems indicate that a PPM of 850 in an office is just about right!

You won't know for sure if it is reading high until you calibrate it.
10  Forum 2005-2010 (read only) / Interfacing / Re: Interfacing a Senseair K22 Co2 NDIR Sensor via PWM on: November 02, 2009, 05:59:02 pm
According to the spec sheet the minimum PWM output is 350 PPM... just about the amount your sketch is off by.

At 350 PPM  the pulse width is 177,000 uSec. This is the minimum pulse width, what we call the devices 'zero point'.

The 'gain' of the device is 500 uSec  per PPM.

So the correct loop algorithm would be something like the following...

Code:
void loop(){
 unsigned long ppm; // adding for clarity

 duration = pulseIn(pin, HIGH); // get the raw reading
 ppm = duration - 177000UL; // subtract the 'zero point'
 ppm /= 500UL; // divide by the gain
 ppm += 350UL; // add the zero point back in

 Serial.print("  PPM Co2: ");
 Serial.print(ppm,DEC);
 Serial.print("  Raw Sensor: ");
 Serial.println(duration,DEC);
}

Lets do the math for the minimum and maximum the device can handle.

At 350 PPM the duration is 177000 uSec.
177000 - 177000 = 0 (uSec over minimum)
0 / 500 = 0 (PPM over minimum of 350)
0 + 350 = 350 (PPM)

At 2000 PPM the duration is 1002000 uSec
002000 - 177000 = 825000 (uSec over minimum)
825000 / 500 = 1650 (PPM over minimum of 350)
1650 + 350 = 2000 (PPM)
11  Forum 2005-2010 (read only) / Interfacing / Re: Wiznet repeated connections on: December 17, 2009, 07:02:29 pm
The short answer is... yes.

The long answer is... maybe.

A TCP connection will eventually time out if there is no activity. So the trick is to ensure that you keep the connection active.

That begs the question... "how long does it take for a TCP connection to time out?"

That's where 'maybe' comes in... because there is no standard for timeout.

==================================

As a rule of thumb, sending data every second will avoid almost all timeouts.

12  Forum 2005-2010 (read only) / Interfacing / Re: Relay and LCD Issue on: November 03, 2009, 02:20:29 pm
The data sheets unfortunate choice of label for ULN pin 9 seems to be causing confusion.
Pin 9 is where all the diode anodes are connected together... thus the label 'diode common'.

Pin 9 should be connected to +5 volts of the relay board, not to ground.
13  Forum 2005-2010 (read only) / Interfacing / Re: Relay and LCD Issue on: October 30, 2009, 01:24:38 pm
BE SURE to include the ULNs diode COMMON pin!

The ULN driver chip has a 'free-wheeling' diode for each transistor. The purpose of these diodes are to protect the transistor from high voltage spikes when switching inductive loads... such as relays. All these diodes are connected together at pin 9, which is supposed to be connected to, in this case, the relay positive supply.

As for the grounds, it sounds like you have 'daisy chained' grounds. It might be OK, or you might get strange, intermittent problems.

Better would be to run 3 separate ground leads...

     from the Arduino to the external supply ground,
     from the distribution board to the external supply ground,
     and from the relay board to the external supply ground.

Use 22 awg wire or bigger (bigger is better).
14  Forum 2005-2010 (read only) / Interfacing / Re: Relay and LCD Issue on: October 29, 2009, 02:18:36 pm
The relays are where the bulk of the power is being used.
Even a 'sensitive' type relay can consume 40 ~ 50 mA.
With 16 of them on simultaneously, you're drawing 640 mA.

I would modify your design to power just the relays from the external supply, and everything else from the Arduino supply. This can be done safely since the ULN2003 is an open collector design, and is probably an easy modification. As a side effect this will inhibit any switching noise from the relays from getting into the rest of the system.

    Isolate the relay bank positive supply from the rest of the distribution board. BE SURE to include the ULNs diode COMMON pin!

    Connect the ground of the distribution board, the ground of the external supply, and the Arduino ground together, at one AND ONLY one point.

    Connect the external supplies positive terminal to the relay bank positive supply.

Everything should work OK at that point.
15  Forum 2005-2010 (read only) / Interfacing / Don't look now, but your power supply is drooping. on: October 26, 2009, 02:32:05 pm
The Arduino can only provide about 500 mA running off USB.
Even using an external supply, it can only provide about 800 mA.

Pages: [1] 2 3 ... 8