Show Posts
Pages: 1 ... 7 8 [9] 10 11 ... 27
121  Using Arduino / Audio / Re: Sound gets distored when going thru digital pot on: January 28, 2014, 01:22:58 am
Maybe I'm missing something, but I see a problem with the voltage divider used for input voltage offset in this design.

Here's my take on the voltage divider:  The digital potentiometer's internal resistor - 10K, from the original post - is in parallel with the lower half of the voltage divider.  That makes the divider's DC voltage a lot lower than half of VDD, since the upper resistor is 100K, and the lower resistor figures to be about 9.1K.  That'll be OK as long as the input signal amplitude doesn't go above about .42V peak-to-ground.  If the signal gets bigger than that, the input to the digital potentiometer will be below VSS, outside the operating range.

I think that 10K connected between VDD and the input to the digital potentiometer, and no resistor connected between the potentiometer input and ground, will give a DC voltage of 2.5V.
122  Using Arduino / Programming Questions / Re: Converting char value from client.read() to integer values on: January 27, 2014, 11:44:06 am
You have a lot of good suggestions already.  I'll add one:

Write a program that collects characters from the serial monitor, identifies the terminating character, does atoi() on the result, and prints the resulting integer.  When you get that working, transfer the method to your web-based program.  

Here's what I like about that method:
  • The code will be short.  You can post the whole sketch each time, and we won't have to work with snippets, or wonder if you made some other change in the program that isn't shown.
  • There won't be all that distracting other stuff.
  • You'll be in control of the input.  You'll know what you put in, and you'll see what you get out.  You, and we, won't have to speculate about  what some server is sending you.

[Edit: Added omitted word, "you."]
123  Using Arduino / Programming Questions / Re: Converting char value from client.read() to integer values on: January 26, 2014, 10:30:51 pm
Are you getting these values as text, or as binary integers?  Your code has comments that suggest it's text.  If that's so, you're not getting 56, you're getting "56".  The first is a numerical value, corresponding to 56 decimal, 38 hexadecimal, and 00111000 binary.  The second is a two-byte string, and the values of those bytes are 53 and 54 decimal.

Investigate.  Change this:
Code:
   c = client.read();
    Serial.print(c);
to this:
Code:
   c = client.read();
    Serial.print(c);
    Serial.print(" ");
    Serial.println(c,DEC);
That'll print each character on its own line, along with its decimal representation.  I suspect that you'll find that you're receiving more than one character, and that those characters represent the number that you're looking for.

atoi() expects a pointer to a character array.  It skips any initial whitespace, and then looks for characters in the range '0' ... '9'.  It takes as many as it finds in a row, and interprets those characters as a numerical value.  If you pass it a character, the compiler complains and gives up, because it can't turn a character into a pointer to a character array.  If you pass it the address of the character, it'll compile, but it will keep looking at characters, and keep converting, until it finds a non-decimal character, or a string-ending zero.  I don't think that's what you want.

I think you'll have to collect the characters into a character array, maybe add a string-terminating zero, and then give the array's pointer to atoi(), in order to get the results you hope for.

[Edit: Fix grammar]
124  Using Arduino / Programming Questions / Re: Converting char value from client.read() to integer values on: January 26, 2014, 09:18:59 pm
Can you post a complete sketch? If you don't, you waste time while people ask you to do that. Please post a minimal sketch that demonstrates the problem, as opposed to hundreds of lines of code.


125  Using Arduino / Audio / Re: Sound gets distored when going thru digital pot on: January 26, 2014, 10:31:37 am
Intuitively, I suspect that the digital potentiometer requires that its inputs be between VSS and VDD, while the input signal is bipolar.  When the input signal is lower than VSS, the IC is outside its operating range, and it responds in some non-linear fashion.  I think you hear it most in bassy passages because the bass signal is usually very large compared to higher-frequencies, and the voltage gets further below VSS.

That view is bolstered by this line in the datasheet, found here - http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en531709, page 5, "AC/DC Characteristics:"
Quote
Resistor Terminal Input Voltage Range (Terminals A, B and W)  Min: VSS  Max:VDD
.
To fix it, you'll have to offset the input signals.  Depending on how your amplifier is coupled, you might have to shift the output signals back to bipolar.
126  Using Arduino / Programming Questions / Re: Shortest Path Algorithm Program Error on: January 24, 2014, 12:17:03 am
If you get past the error, I think you'll find that the compilation will still fail, because this program requires more memory than the Pro Mini has available.   It also exceeds the memory of an Uno.

The "invalid conversion" error arises because the program tries to compare two values whose data types aren't compatible:  an element of pathmatrix, type String, and -1, type int.  There's no reasonable way to compare those two things, so the compiler complains and gives up.

This posted version of this program doesn't even compile.  That suggests that there may be other problems with it - well, there's at least one more problem, it takes too much memory.  I'd suggest that you carefully evaluate whether you need Dijkstra's algorithm for your application, and, if you do, learn how to write it yourself, and look for better examples.
127  Using Arduino / Programming Questions / Re: Timer interrupt and analogRead() on: January 23, 2014, 11:11:34 pm
Timer1 can be used to trigger an analog conversion when the timer overflows.  The TimerOne library makes it easy to set up Timer1's overflow interrupt, but it doesn't do anything with the ADC.  Here's a way to use that feature:, using the TimerOne library:
  • Select the ADC input pin you want to use.  You can do that by writing to register ADMUX, and you'll have to be careful to set the REFS0 and REFS1 bits to select the proper analog reference.  Looking at the code for analogRead, it looks like you can select that pin by executing analogRead() on the pin before you start acquiring data.  It looks like the ADC multiplexer is set in that routine and left alone.  If you leave it alone afterward, it shouldn't change.
  • Execute an analogRead(), to get past the extra-long first conversion of the ADC.  That can be the same analogRead() that sets the ADC input pin, if you like.
  • Create and attach a Timer1 interrupt service routine that doesn't do anything.  That ISR's only purpose will be to reset the Timer1 overflow flag, bit TOV1 in register TIFR1.
  • Create an ISR for the ADC that collects the ADC reading, stores it in a golbal variable, sets a global flag, and exits.  ISR's are best that do the least possible amount of work.
  • Enable the ADC, enable its auto-trigger, enable its interrupt, and select Timer1 overflow as the trigger source.  That'll involve writing to the ADC control and status registers ADCSRA and ADCSRB.
  • I'd recommend waiting for the first ADC conversion to complete, by waiting for the flag from the ADC, and then resetting the flag.  You might even want to wait for it to complete two conversions, to be sure that the Timer has fully reacted to the change of its rollover value, and the ADC has synced with it.
  • in loop(), watch the ADC flag.  When it goes active, reset it, process the ADC data, and wait for the next one.
You'll have to be sure to set the Timer1 rollover time high enough to allow for the ADC conversion to complete, and for the ADC ISR to execute afterward.  The Timer1 interrupt will execute while the ADC conversion is going on, so, unless you make it a complex ISR, it shouldn't interfere with reading the ADC.  You should also allow time for the Timer0 overflow ISR to execute, too, since it may be active when the ADC completes its conversion, and the ADC ISR won't execute until that ISR completes.

You can find out how to do all those things in the datasheet, in the descriptions of Timer1 and the ADC.

An alternative is to refrain from enabling the ADC interrupt, don't provide an ADC ISR, and read the ADC and set the flag in the Timer1 ISR.  You still need to consider the relative timing between the ADC and Timer1, since the ADC will write over the result of the last conversion when the new conversion completes.  You'll have an ADC conversion time to let other ISR's complete, respond to the Timer1 overflow interrupt, and read the ADC; after the conversion time elapses, the previous reading will be gone.

The code that Jack Christensen references in Reply #4 manipulates Timer1 directly, without help from the TimerOne library.  I like that better, since it gives you precise control over the Timer1 functions.  You may prefer to let the TimerOne library handle those details for you.
128  Using Arduino / Programming Questions / Re: Shortest Path Algorithm Program Error on: January 23, 2014, 10:00:06 pm
This test
Code:
if(pathMatrix[j][k]==-1)
compares an element of pathmatrix, whose type is String, to the number -1, whose type defaults to int.  I got it to compile by changing that test to this:
Code:
if(pathMatrix[j][k]==String(-1))
I've never used String, so I don't know whether that's valid.

What sort of Arduino are you using for this effort?
129  Using Arduino / Project Guidance / Re: Need a way to detect a voltage drop. on: January 19, 2014, 09:28:01 am
Check the datasheet.  Read about the Analog Comparator, and the interrupt associated with it.  Look at the comparator's speed in the "electrical characteristics" section, and decide if it's fast enough.  If it's not, consider using an external comparator connected to one of the INTX pins.

You don't say anything about what "strictly timed" means in this context.  Maybe you need a response - like an output - within a narrow time window, or maybe you need to know the time that the transition happened quite closely.  If you want to know when something happened, then the Input Capture register associated with Timer1 and the analog comparator will help, since it captures the timer value in hardware, without assistance or response from the program.

... will explain what im working on if needed ...
I'll go out on a limb and say, "needed."  It's hard to tell what will really help you in this application without knowing more about it.
130  Using Arduino / Project Guidance / Re: High current draw, external power supply and grounding guidance on: January 19, 2014, 09:15:10 am
I took the power dissipation of the photo resistors from the spec sheet ... converted to amps and multiplied ...
As has been noted already, the power dissipation you're talking about is from the listing, "Absolute Ratings Maximum," in the datasheet.  That's not how to use the absolute maximum ratings.  They don't describe normal operating conditions for the device.  Instead, they describe the limits at which the device won't be damaged.  I think you intuitively know this:  you saw that the absolute maximum DC voltage is 250V, but you didn't consider operating the sensors at that voltage. 

The onus is on the user to design his circuit so that the absolute maximum ratings aren't exceeded; indeed, the onus is to see that the normally more restrictive "recommended operating conditions" are maintained, but this datasheet doesn't provide that listing.

If you're still concerned about the power requirement of the sensor array, hook up one sensor and resistor and measure the current through them with an ammeter.  You should probably do that test even if you're already convinced.  I wouldn't recommend hooking up a bunch of stuff, against your intuition, on just the say-so of some anonymous guys in an Internet forum.  Please post your results.

I recommend that you bone up on the theory involved in this circuit.  Look up Ohm's law in the Wikipedia.  Google "series resistors" and look for something that explains things understandably.  If you have specific questions, come back to this forum  under "General Electronics."

Finally, asking again:
What are you trying to accomplish?  Please be specific about what your project will do - don't just say something like, "I'm trying to detect light in 48 places."
131  Using Arduino / Project Guidance / Re: High current draw, external power supply and grounding guidance on: January 17, 2014, 04:03:58 pm
Here's how I interpret the schematic and accompanying text:

Each photoresistor is connected to a 10K resistor, and each series combination of the photoresistor and 10K resistor is connected between 5V and ground. 

Have I got that right?

If so, please do the math.  A photoresistor's resistance can be no less than zero.  The resistance of the series combination of a photoresistor and a 10K resistor can be no less than 10K.  The parallel combination of 48 10K resistors is 10,000/48 =~ 208.3 ohms.  Ohm's law says 208.3 Ohms will draw 5/208.3 = 0.024 amps from a 5V supply - 24 mA.  You seem to be measuring over 100 times that much, at 2.5A.

Something's wrong.  Either you meant to say something other than 2.5A in the original post, or something's not hooked up the way you think it is.

Can you illuminate?
132  Using Arduino / Project Guidance / Re: High current draw, external power supply and grounding guidance on: January 17, 2014, 02:04:31 pm
With 48 sensors and a total 2.5 amp load, that averages to over 50 mA per sensor.  If they're powering them at 5V, and it sounds like they are, that corresponds to a resistance of less than 100 ohms, and a power dissipation of over a quarter of a watt per device.   It sounds like you might have these things connected straight across the 5V supply.  

Please tell more:
  • How do you have these things hooked up?  Please be very specific, or post a schematic.
  • What are you trying to accomplish?  Please be specific about what your project will do - don't just say something like, "I'm trying to detect light in 48 places."
[Edit: Fix spelling and formatting]
133  Using Arduino / Audio / Re: a couple questions about FFT/FHT on Arduino on: January 13, 2014, 11:34:04 pm
I found your elephant analogy offensive ...
No offense was intended.  That's a common saying in my part of the United States; I suppose it's less common elsewhere.  A better expression of my intended meaning would be, "The issues involved here are complex, and they would be difficult to explain, or to understand, all at once.  We'll take it a step at a time."

It appears that this code was adapted from this link - http://wiki.openmusiclabs.com/wiki/FHTExample - and that it was transferred largely intact.  The original code operated the ADC in a polled, free-running mode, without any interrupts involved.  Adapting that code to an interrupt-driven application isn't trivial, and adapting it to run the ADC at a frequency that's not one of the prescaler's natural speeds is trickier yet. 

Good luck with your project.







134  Using Arduino / Audio / Re: a couple questions about FFT/FHT on Arduino on: January 13, 2014, 01:45:26 pm
The code (with now correct comments) has been updated and a couple smaller details have been changed ...
Please don't change the substance of posts that have already been answered; it makes it impossible for a later reader to follow the discussion.  See the sticky post, "How to use this forum - please read."  See item #14, which says, among other things,
Quote
Except for adding code tags, please don't modify earlier posts to make corrections. That makes the following posts read strangely. Post the modified code in a new reply.
For example, references to specific frequencies in the follow-up post won't make sense now that you've changed the sample rate to 4 kHz.  I won't complain if you fix spelling or grammar, or decide that you really didn't want to call somebody a "dweeb," and decide to substitute, "respected member of this community."  But it's best to leave the substance as it is.

Quote
You mention at the bottom of your post that there are other 'things not to like'. Could you please expand upon this?
For a start:
  • Variables that are modified in an interrupt service routine (ISR) aren't declared volatile.
  • The ISR is way too long.
  • The ADC is in free-running mode with a conversion every 26 us, but it's only being read every 250 us.
  • The ADC conversions and the readings aren't in sync with one another.

Fixing this program is a metaphorical elephant.  We can't eat it all at once; we'll have to take it a bite at a time.  Read this, Nick Gammon's thorough and clear description of interrupts on the Arduino's processor: http://www.gammon.com.au/forum/?id=11488
135  Using Arduino / Audio / Re: a couple questions about FFT/FHT on Arduino on: January 13, 2014, 12:50:47 am
Tell more.  Your Sallen-Key is presumably a two-pole Butterworth bandpass filter, with corner frequencies at 50 Hz and 1300 Hz.  Is that right?  If so, you can't expect that the filter will completely eliminate signal components that are a little bit outside the passband.  You'll get a rolloff of about 6 dB per octave, so signal components around, say, 2000 Hz won't be reduced by even as much as half, and what remains of them will alias as lower frequencies.  If your filter is a two-pole some-other-kind-of-filter, it still won't be much better than that.

Unless you have some spectacular number of poles, you won't get a sharp cutoff at the corner frequency, anyway.  The Nyquist criterion says that the lowest sample rate required to avoid aliasing is twice the highest frequency with significant content in the input signal.  If there's significant content in the unfiltered signal at or a little above 1.3 kHz, there'll be significant content in the filtered signal, too, and it will alias.  Significance, of course, is in the eye of the beholder - it''ll depend on what you're doing with the results.  And, "a little above" might well mean "between 1.3 kHz and 13 kHz," depending on the sensitivity of the follow-on analysis.

You could quickly check whether this is a source of your difficulty by restoring the original sample frequency, leaving your bandpass filter in place and active, and examining the output of the FHT to see how much content appears outside the nominal passband of the filter.  If it's a significant fraction of what's appearing at the in-band frequencies, aliasing could be the problem, or maybe part of the problem.

Another valuable test would be to restore the sample frequency to the original high speed, and reduce by degrees until the effect becomes noticeable.  That might be the lowest frequency you can operate this rig, without beefing up the bandpass filter.

But, this is all conjecture.  Tell more about your setup.  Do some experiments, and tell about the results, too.

Function pingADC() looks to be used as an interrupt service routine, and the wrapper for that seems to be the TimerOne library.  I've no knowledge of that library, so I can't comment on whether it's been handled correctly.  Intuitively, it appears that the timer is initialized with 250; the library referenced in the Playground shows the argument to the initialization function to be in microseconds, and a 250 us yields a frequency of 4 kHz, rather than the 2.5 kHz referenced in the original post.  The comment says that the period is 0.1 seconds, which is looks to be very wrong wrong.  I'll ask that you try not to misdirect us with out-of-date comments next time.  

So, maybe I can comment on that code a little, but only intuitively.

I'll note that the pingADC() seems unduly long for an interrupt service routine, and that it seems to cell a bunch of FHT functions that are certain to take a disastrously long time for an interrupt service routine.  I'd prefer to see that the ISR note that the ADC buffer is full, and that the data be processed in loop().  It may work OK, since it looks like it doesn't call the long routines until the buffer is full, and running a long program at that time won't mess up data acquisition; it'll mess with other ISR-based stuff, though, like millis(), micros(), and Serial.

There's other stuff not to like.  It can wait.
Pages: 1 ... 7 8 [9] 10 11 ... 27