Show Posts
Pages: 1 ... 7 8 [9] 10 11 ... 22
121  Using Arduino / Project Guidance / Re: help on basic programmation on: August 24, 2013, 03:18:37 pm
As an exercise, this might be interesting; as a permanent installation, it's dangerous.  Sooner or later, some creature's hand, arm or head will be sticking through the window when the sequence starts, with possibly disastrous results.  That might be you, a child, or a pet.

if (something_in_window) {
  if ( (something == child) || (something == my_dog) ) {
    digitalWrite(LT_WINDOW_UP_RELAY, HIGH);  // Stop motor
  else {
    if (something == adult_human) {
      shout("Look out!");  // Trigger audible alarm

Please reconsider whether you want to implement this.
122  Using Arduino / Programming Questions / Re: Problem with timer interrupts and analog comparator on: August 23, 2013, 07:27:55 am
If you have verbose output turned on, it does mention ISR errors
Indeed.  I find it in 1.0.5.  I can't get it to show up in 1.5.2. 

Better let everyone know the right answer, eh?
I think it's something that ends in "-ong."  Or maybe "-illa?"
123  Using Arduino / Programming Questions / Re: Problem with timer interrupts and analog comparator on: August 22, 2013, 11:44:48 pm
... guess that both spellings are defined, but only one substitutes the correct value.
My tests don't support that notion.  I used this as the Timer1 overflow ISR:
ISR(TIMER1_OVF_vect) {
  asm volatile (
    "neg   %[ctr]"           "\n\t"
    "subi  %[ctr], 1"        "\n\t"
    "neg   %[ctr]"           "\n\t"
    :   [ctr] "=&r" (ctr)
    :  "[ctr]"      (ctr)
  flag = (ctr == 0);
Timer 1 was set to normal mode, no prescaler, overflow interrupt enabled.  loop() printed a short message whenever it saw flag nonzero.  ctr and flag were volatile uint8_t's.  The purpose of the peculiar assembler code was to get a couple of "neg" instructions into the disassembled output, to make it easy to find this ISR in the assembler listing.  The output was as expected - a message at roughly 1 per second.  "neg" instructions bracketing a "subi r24, 1" appeared in the assembler listing, as expected.  The ISR was 58 bytes long.  I'm happy to post all the code if anyone wants it, but the ISR was the only interesting part.

Changing the ISR definition to this -
ISR(Melbourne) {
- in honor of our friend Nick, yielded a long string of initialization messages as output, suggesting repeated resets.  The Timer1 interrupt vector contained a jump to a "jmp 0" instruction, with the notation, "<__bad_interrupt>", the same code and notation that appears for all the other interrupts for which there's no ISR.  That's not surprising, since nothing in the code suggested that the ISR was for Timer1 overflow.  The only interrupts with real jump instructions were Timer0 overflow, and two USART interrupts.  There were no "neg" instructions in the assembler listing, suggesting that the ISR didn't get into the program at all.  The sketch size was 58 bytes less than the correct version, suggesting that the ISR was simply omitted.

I tried naming the ISR "Sydney" and "Canberra."  It took me three tries to get the capital of Australia right, but the results were all the same:  no hint of the ISR in the code, and a smaller sketch size by 58 bytes.  The IDE never mentioned it, even after I asked it to be verbose about both compiling and uploading.  It does hiccup on special characters and spaces, though, making me suspect that it wants something that would be a legal variable name.

It seems unlikely that major Australian cities are defined somewhere.  It looks like anything that will pass muster as a variable name will get past the compiler, but only the correct names will generate ISR's in the code.

I hesitate to call this a bug without input from experts.  Defining an ISR may tell the compiler to expect an external something-or-other that never materializes, and this behavior may be proper under the standards.  A warning message at compile time might be a spiritual act of mercy, though, considering the challenges of troubleshooting ISR's even when they're named correctly.
124  Using Arduino / Programming Questions / Re: Problem with timer interrupts and analog comparator on: August 22, 2013, 11:35:07 pm
I'm happy to say it's working now!
Glad to hear that it almost works.  If you haven't changed other things in the code, I suspect that it doesn't do this:
... the fan remains on while the temperature is high because the analog comparator keeps tripping and resetting the timer variable.
That sounds like you want the timer variable to stay at its original setting until the temperature falls below the reference level, and then start timing out.  That means that the fan will run until the temperature drops below the setpoint, and then run for an additional period determined by the potentiometer setting.  I don't think that the program you posted, corrected as you describe, will do that.
125  Using Arduino / Programming Questions / Re: Problem with timer interrupts and analog comparator on: August 22, 2013, 01:56:06 pm
You are quite right, I can't believe I missed that.
Possibly you haven't made exactly this error yourself, and possibly you haven't done it a dozen times.  If not, then I have the advantage of you in this game.

Do we know why there's no error message for misnaming an ISR?
126  Using Arduino / Programming Questions / Re: Problem with timer interrupts and analog comparator on: August 21, 2013, 10:32:37 pm
This line will cause trouble:
ISR(Timer1_COMPA_vect) {
The compiler doesn't seem to recognize the mixed-case identification of Timer1, but it never mentions it.  Instead, it puts a jump instruction to location 0, the reset vector, in the interrupt table at the TIMER1 COMPA location, as if there were no ISR defined for it.  In my experience, a misidentified ISR name will cause unexpected results, but it won't trigger an error message.

This will work better:
As I understand it, the proper name for an ISR is the case-sensitive name shown in the "Reset and Interrupt Vectors in ATmega328 and ATmega328P" table in the data sheet, with underline characters substituted for any spaces, followed by these characters:  _vect  

Using some Serial.print()'s while a sketch is under development will help you see what's going on.  Serial.print()ing an initialization message will make repeated resets obvious.  When I add these two lines to your sketch -
- the initialization message repeats.
127  Using Arduino / Project Guidance / Re: Can Arduino output 20kHz PWM with varying duty cycle? on: August 21, 2013, 02:50:01 pm
Do you think Arduino Uno is enough as my interface?

Which Arduino?  I think it would be challenging on the Uno.  The Mega, with its plethora of 16-bit timers, offers more attractive options. 

Let's probe.

Safety first:
  • Do you intend to control a motor? If so, what will it be doing?
  • What's the operating voltage?
  • How much power do you intend to deliver?

If your intent is, say, to operate a 25 horsepower fan at 480V, that makes for high voltages, and a lot of available energy.  It's unlikely that you'll get the output right on the first try.  I can envision a bright flash with flying chunks of hot metal, and it's a disturbing image.  I secretly hope that you've located a 12V, 3 watt, three-phase motor for experiments; IGBT's, as opposed to MOSFET's, make me think that you want to control an industrial-sized gizmo.

So tell us:  How will you preserve yourself, the structure you work in, and its other occupants, while you carry out this project?

  • What are you hoping to accomplish by reading analog values?  This statement
    ... two analog inputs that can read 20kHz signal as feedback loop
    isn't particularly clear.  I suspect that you want to read an AC power-frequency-ish voltage and maybe a current from somewhere.  If you're hoping to identify, say, RMS values of voltage and current from harmonic-rich analog inputs, the calculation burden might be more than the horse can pull.  Can you clarify your analog requirements?
  • What's the source of the 20 kHz requirement?  Looking at Toshiba's industrial VFD's, I find a bunch of them adjustable from 0.5 to 16 kHz, but nothing as fast at 20 kHz.  As Nick notes, 20 kHz is an unwieldy PWM frequency for the Uno.
  • What have you tried so far?

Here's a link to a senior project report from an electrical engineering student at California Polytechnic:  I think that the CalPoly project is different from the one you contemplate, but not completely different.
128  Using Arduino / Project Guidance / Re: Can Arduino output 20kHz PWM with varying duty cycle? on: August 20, 2013, 08:51:57 am
I think that you're developing a variable-voltage, variable-frequency, three phase power supply, akin to a variable-frequency drive for a motor.  Is that what you're working on?

129  Using Arduino / Programming Questions / Re: Toggling a Lightswitch on: August 19, 2013, 05:14:38 pm
If you're having trouble seeing what's happening, I'd recommend adding some Serial.print() statements.  I'll suggest printing a message each time turnOn() or turnOff() is entered, and each time the button is found low.  I'll suggest that those messages state the value of lightSwitch, too.  You'll learn a lot about what's going on in the program.

You may want to reexamine your servo angles, too.  It looks like both deflections are in the same direction from the neutral position, which doesn't sound right for a toggle switch.
130  Using Arduino / Project Guidance / Re: Data compression in my code on: August 16, 2013, 09:27:43 pm
It looks like 1 degree of latitude at the equator is 111,319 meters but only about 7 meters near the poles.
... 1 degree of equatorial latitude (111 km) is already a lot smaller than 1 degree of longitude (6,356 km) ...
A degree of latitude is everywhere the same: about 60 nautical miles, about 111 kilometers.
A degree of longitude is the same size = ~ 111 kilometers - at the equator, shrinking to zero at the poles.  6,356 kilometers looks more like a radian of longitude at the equator.
131  Using Arduino / Audio / Re: selective call system with musical notes. on: August 16, 2013, 09:05:22 am
In your first sketch, the tone-playing code is in loop(), and it's called when the button's pressed.  In the second sketch, the tone-playing code is in setup(), and it's called once at startup, but never called thereafter.

If your ultimate vision for this project can tolerate locking the program for the two-second delay, a solution would be to move the tone-playing code to a function, and call it from setup() for confirmation, and from loop() for operation.  Otherwise, you might want to use the "blink-without-delay" technique, establishing the time for the next action - turning the tone on or off, and operating the relay - monitoring the current time in loop, and executing the proper action when the time hits that value.
132  Using Arduino / General Electronics / Re: Data over power ... on: August 14, 2013, 03:18:15 pm
If the serial out was at, say 2.5 volts. That would cause both transistors to turn on wouldn't it?
If the serial pin is high-impedance, the pin voltage is about 2.5V.  Base currents are roughly (2.5V - 0.7V)/10000 = 0.18 mA.  Figuring hFE at 110, the smallest value shown in the Fairchild datasheets for either transistor, the collector current is close to 2 mA for each transistor, if the circuit could supply it.  It can't, though, because the only DC path for the current is through the 4K7 resistor, which will only carry a little over 1 mA at 5V.  So, both transistors saturate.  The gate voltage on T3 is nearly 5V, VGS is close to zero, and T3 is off; the gate voltage is nearly 0V on T4, VGS is the same, and it's off, too.  So, if the pin is set as input, a milliamp is wasted between the two BJT's, but the circuit is safe.  

There'll be no power to the remote devices, though.  That may not be an issue: ATMega328P datasheet says, "When the USART Transmitter is enabled, this pin is configured as an output regardless of the value of DDD1."  If it's an output, it's either close to 0V or close to 5V, and it's high in the idle state.  Worst case, if Serial.begin() were omitted, the pin might be an input, and the remotes would be unpowered, but the output circuit wouldn't burst into flame.
133  Using Arduino / General Electronics / Re: Data over power ... on: August 14, 2013, 10:31:12 am
Caveat:  FET's aren't really my area of expertise.  The superior man reaches his own conclusion.

From the datasheets, T3 turns on when VGS is below about -4V, and T4 turns on when VGS is above about 3V.

With the serial pin high, T1 is off and T2 is on.  T2 collector voltage is low.  VGS for T3 is -5V, and close to zero for T4.  T3 is on, and T4 is off.  Output is high.
With the serial pin low, T1 is on, T2 off.  T1 collector voltage is high.  VGS for T3 is close to zero, and 5V for T4.  T3 is off, and T4 is on.  Output is low.

The 4K7 resistor between the gates slows gate charging on the active FET, so that it turns on more slowly than the inactive FET, preventing them from both being on simultaneously.  It's likely that you'll see a short period when the output is open-circuited after the serial pin switches, and that may be why the output doesn't look as good as you'd hope.  With this circuit, turn-on time will certainly be limited by the 4K7 gate resistor, and that will limit the switching rate that you can use.   The datasheets suggest that the effect will be more pronounced when the output switches from low to high.  

134  Using Arduino / Programming Questions / Re: Improving FHT resolution on: August 13, 2013, 09:53:02 am
You can try parabolic interpolation.  The theory is that the continuous Fourier transform of the input signal looks like a parabola near a peak; the practice is to locate a peak among three adjacent frequency bins, fit a parabola to the magnitudes at those bins, and estimate the location of the vertex.  Here's a link that describes how to do it:

Alternatively, you could give up on the digital Fourier transform, and use autocorrelation instead.  Here's a scholarly paper that describes autocorrelation and the YIN algorithm for frequency estimation:  

Here's a link to an Arduino-based guitar tuner project, using the YIN algorithm, that looks to be very much like the one you're attempting:

Edit: fixed link
135  Using Arduino / Programming Questions / Re: Trying to compare data: error: invalid use of void expression on: August 04, 2013, 10:46:27 pm
I can't find any syntax docs on the puthex() function.
You can find all there is to know about puthex() in nfc.h and nfc.cpp.  It's defined in those files.  That's where I looked, using this the library link at this url:
Would this be the correct way?
I'd bet that it's not.  The first line sets a character variable equal to a pointer; I can't see that you'll get the results you expect.

I can't determine whether any particular approach is the "correct way."  I don't understand your code, I'm not familiar with the NFC library, and I don't even know what you hope to accomplish.  I surmise that you want to compare two things in this code.  Only you know what they are.  Ask yourself:  What are you trying to compare to what?  That will take you a long way toward figuring out how to do it.
Pages: 1 ... 7 8 [9] 10 11 ... 22