Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 22
61  Using Arduino / General Electronics / Re: Arduino max current on: February 06, 2011, 02:45:57 pm
Hi,

I have a simple question...

How much of current i can get from arduino mega if is connected to pc?

Thank Koudy

From what on the Arduino mega?

From the 5V connector, from one pin, or from all pins combined?

!c
62  Using Arduino / General Electronics / Re: Splitting an Opto-Coupled Connection on: February 06, 2011, 12:31:37 pm
Me to as I've been using logic levels rather than just looking at the state of the transistors, ie on of off.

So your last circuit will work I think, even without the pull up resistors. As long as the OK1 transistor is driven hard enough to drive a LED.

______
Rob


Yeah, it got my head all turned around - but it's looking pretty clear now.  I think you're on to something with the transistor's ability to handle that much power - the maximum dissipation is 150mW, and at 1.1v/20mA that's 176mW for 8 LEDs. I'd run them lower, but experience has proven problems with the triggered devices when I run the NTE3086's this low! (Too much voltage drop for some of them, the best performance from the left-hand side with a wide range of triggered devices has been running @ 30mA.)

So, now the only trick is to get enough power flowing through there... Much easier problem, I think =)

!c

EDIT: N/M the above - fully within power spec- recalling there are two transistors input, that means 4x LED per transistor, or 132mW @ 1.1V/30mA.
63  Using Arduino / General Electronics / Re: Splitting an Opto-Coupled Connection on: February 05, 2011, 10:00:06 pm
The 1.5V comes from a single AAA battery cell (not shown)

Here is the datasheet for the NOR chip CD74AC02: http://focus.ti.com/lit/ds/symlink/cd74ac02.pdf  -- it works with Vcc from 1.5->5V

The LED in the NTE3086 has a typical voltage of 1.1V @ 20mA.  And the VCE saturation voltage is 0.2-0.4V at 16mA for IF, so well within the 1.5V supply voltage.

These being the only IC's in the circuit (this is just a splitter device, to replicate from 2 outputs to 8 - I'm only showing 2 outputs for simplicity's sake), should have no issue running from a single AAA cell.  My only real concern is the value of R1/2 being too high to register a proper high signal at IC1x - that's easy to solve by reducing the value though.

I want the C+Es on the outputs to be in the exact same state as the C+E's on the input.  I just want to replicate the status of the two outputs into 8 outputs.

The function table for the NOR indicates that if either input is HIGH, it outputs a LOW signal - this means that in drawing 1, by default it is outputting a LOW signal when OK1/1's LED is not engaged, because the OK1/1's Collector is pulled HIGH.  Thus, when LED OK1/1 is off, the following is the state of the function table:

IN1    IN2    OUT
H       L*      L

* IN2 is tied to GND, so is always low.  If that is the case, and the output of the NOR is connected to the cathode with the anode tied directly to 1.5V, would that not result in the LED being on on OK2/1 when OK1/1's LED is off?  (I.e. allowing voltage to flow from A to K because K is biased low?)

I can't seem to figure out how I've gotten that wrong?  Is that not the function of an NOR, and is that not the state of the IC1C when OK1/1 LED is not engaged? Or is the pull-up too weak?

Your table #1 also seems to be wrong to me (it presumes an inverter when I have an NOR):

-----LED OK1 TRANS -----INV----- LED OK2 TRANS -----
hi    on            on      lo           hi    off           off      hi

It should be:

-----LED OK1 TRANS -----NOR----- LED OK2 TRANS -----
hi    on            on      lo           hi    off           off     off

Even simplifying it to use an inverter like below, we still have the cathode low on OK2/1 when the base is NOT energized on OK1/1 - as the input is pulled high by default, thus would not the LED on OK2/1 be energized in this state, and therefor energizing the base on OK2/1, resulting in an inverted state between the input and the output?



I'm pretty thoroughly convinced that I can make it work now, with an NOR connected between the anode and the collector.

To be honest though, I'm starting to think there isn't a need for either an NOR nor an inverter!  The following seems to make perfect sense to me:



It seems like I've made things way over-complicated and just confused myself along the process, if what I said earlier holds true, then this must also - given that I can completely prevent the anode from ever being pulled to 0V, it should never have a reverse current condition?


!c
64  Using Arduino / General Electronics / Re: Interfacing with OPTO isolator TTL on: February 05, 2011, 05:06:13 pm
Quote
However, the arduino pins can only supply 40mA,

No. The arduino will get fried if you try to pull more than 40mA from it. It is very easy to do this.
...

You should not take more than 30mA in any good design.

The 1K series resistor is too high, you should use something between 200 to 500 ohms.

(I'll make sure to add the words "safely, briefly" next time I say that.)

To be in-spec with the data sheet (1.2-1.4V at 20mA), that should be closer to 200 than 500, otherwise you're still going to have issues.  At 500, you're getting close to the min CTR.

!c
65  Using Arduino / General Electronics / Re: Splitting an Opto-Coupled Connection on: February 05, 2011, 04:07:42 pm
Hmm, switching to the cathode on OK2 just seems to invert our logic entirely, and an NOR or inverter don't work at all - remember the emitter is shared between both left-hand side OK's, meaning I can't look at the emitter for which one is triggered, and I'm trying to follow the collector instead - to see if it is sent to ground by pulling it up gently...

Using an inverter or NOR on the cathode actually creates the inverse logic you mention, see:



Note, it is now turning on the right OKs (OK2/1 and OK2/2) whenever OK1's are not triggered.  (Unless I'm missing something completely fundamental here!)

Now, by switching back to the anode, the original image looks much more correct with the following changes -- but the presumption I have here is that the transistor in OK would behave in such a way as to make it appear that the collector is connected to ground, and there wouldn't be so much resistance within the transistor that I would still follow the path to 1.5V (I'll admit, transistors aren't my strong suit - I can follow calculations and instructions, but my understanding depth of them is fairly shallow):



That is to say, when the LED in OK1/x is not triggered, both the collectors will be pulled high, which will cause both NOR's to output 0.  However, bringing the LED on OK1/2 high will cause pin 11 on IC1D to go low, and make IC1D output 1, while IC1C still outputs 0, right?

!c

EDIT: I think I've answered my own question here - it's an NPN transistor, so, the electrons do in fact flow from Emitter to Collector, and therefor this design should work fine.

66  Using Arduino / General Electronics / Re: Splitting an Opto-Coupled Connection on: February 05, 2011, 12:51:47 pm
Maybe, but they are drawn as NAND gates. Anyway as you say you can just use an inverter.

Whoops - you're right.  No idea why that part in Eagle has the wrong symbol -- I just grabbed the first NOR device I saw... (Or maybe I was just moving too fast and accidentally grabbed an NAND device =)

Quote
When you say to sink current through the OK2 LEDs, are you meaning that I should simply connect the Collector of the triggering device to the Cathode of the OK's that go out to the triggered device?
No, that will invert the signal as well I think. The way it's drawn at present (and assuming an inverter) you get the following logic levels

-----OK1-----INV-----OK2-----
hi           lo          hi          lo

So we start with a HI and end with a LOW, it's inverted.

However if the inverter OP is connected to the OK2 cathode and the anode (with resistor) to +v the OK2 LED is affectively adding another invertion so end to end we're right.[/quote]

Thanks, I'll try that out!

!c

[/quote]
67  Using Arduino / General Electronics / Re: Interfacing with OPTO isolator TTL on: February 05, 2011, 12:26:55 pm
Some obvious problems:

* Is the device using inverted TTL?  Why are you bringing RX low when the other side brings that pin high? (Hint: connect RX to the Emitter and +5V to the Collector, but keep your pull-up in place.  You will most likely need an appropriate current limiting resistor for the Collector on the OK.)
* Where is 1KOhm calculated for the TX resistor?  The max forward voltage of the led is 1.5V, the max forward current is 50mA, therefore: (5-1.5)/0.05 = 70 Ohms.  However, the arduino pins can only supply 40mA, so drop it down to 35 or so - (5-1.5)/0.035 = 100 Ohms.


!c

68  Using Arduino / General Electronics / Re: Splitting an Opto-Coupled Connection on: February 05, 2011, 11:30:23 am
So you just need to pass two signals? Apart from the fact that those NAND gates would never have worked with 1 input tied low I think this is OK (assuming DUP3 is the GND for the device and DUP1,2 have pull up resistors) except there's a signal inversion. I think if you sink current to the OK2 LEDs the signal is correct all the way through.

Rob,

Yes - I need to take these two signals and duplicate them out to 4+ devices.  So that they are largely all sharing the same input from the same output device, but my primary issue is the shared common line between the two signals, w/o it, I would simply use them as-is, that is, run the outputs (E->A) directly to the opto-couplers on the right side, but with only one common line, I have to differentiate which was actually triggered, and simply running the emitter to the anode doesn't work, b/c I don't know which collector was the one to be connected (or, it even could be both at the same time!).

They are NOR gates (neither input high).  But, you are correct that DUP3 is 0V and DUP1-2 are +V, I can only presume how the triggered device handles those -- more than likely they are pulled-up I/O pins, and they trigger when shorted to 0V, and I was thinking I could replicate this sort of behavior through this simple circuit.

When you say to sink current through the OK2 LEDs, are you meaning that I should simply connect the Collector of the triggering device to the Cathode of the OK's that go out to the triggered device?  I'm a little confused by the statement...

Thanks!

!c
69  Using Arduino / General Electronics / Re: Splitting an Opto-Coupled Connection on: February 04, 2011, 10:16:35 pm
You are missing limiting resistors. You'll blow the led's on the optos in the targeted device without them.

The circuit between the two runs at 1.5V, which also happens to be the forward voltage of the OK's - (the right side OK's are actually in my circuit, the left side are in the output device) should I still add limiting resistors?

!c
70  Using Arduino / General Electronics / Splitting an Opto-Coupled Connection on: February 04, 2011, 07:53:42 pm
This may seem like a confusion question, and it's one that would have an obvious answer -- if there were one more wire provided, but I'm wracking my brain on this and feeling dumber for it =)

Assume that I have a device that has two opto-coupled outputs, but the standard wiring for the device it controls has only three wires: two which are +V and one which is 0V

Assume that both the output device and the triggered device (the one taking input) are black boxes to me -- I only know which leads are +V and which one is 0V.  (And, of course, what voltage +V is...)

I want to be able to use the output from the device to synchronously trigger multiple triggered devices. However, I want to retain complete isolation between each triggered device, because each may operate at different voltages. Presume that my OK's are fully in spec for the voltage range on both sides.

My problem is that there are only three wires used in the normal communication, so I'm trying to find a way to trigger the right opto-coupler outputs when receiving the right input - but the fact that the GND is the shared wire and not the +V is giving me difficulty with the right wiring of the opto-couplers.  Obviously, if I connect either trigger on my output OK's to the output device's 0V line, I've got issues as I can't differentiate which +V was actually activated.

My question is, can I use two NOR gates to detect if the specified trigger lines have been connected to 0V in the following fashion, to trigger the right output line?  If not, is there a way that would be most effective given the above constraints?



Thanks in advance!

!c

EDIT: I realize after looking at the above diagram, that I could just use a NOT gate instead of an NOR, but the question remains have I missed something obvious here?  I don't have the gates handy to test with, and would not like to waste money and time buying them if they obviously wouldn't work =)
71  Forum 2005-2010 (read only) / Troubleshooting / Re: MsTimer2 and Atmega328P on: March 19, 2009, 09:54:45 pm
D'oh!

I saw my mistake right after posting this =)

The or was added to the incorrect line there (but on the correct line everywhere else!).  It should've been on the one:

Code:
#if defined (__AVR_ATmega168__) || defined (__AVR_ATmega48__) || defined (__AVR_ATmega88__)  || defined (__AVR_ATmega328P__)

!c
72  Forum 2005-2010 (read only) / Troubleshooting / MsTimer2 and Atmega328P on: March 19, 2009, 09:50:14 pm
Hi all, I'm hoping someone can help me w/ this one.  I recently got a new Duemilanova, that came with the Atmega328 instead of the 168.  I upgraded to Arduino-0014 as well.

Everything seems to be fine, except that I can't get the MsTimer2 library to work.  I attempted to change the following from:

Code:
#elif defined (__AVR_ATmega128__)
      TIMSK &= ~(1<<TOIE2);
      TCCR2 &= ~((1<<WGM21) | (1<<WGM20));
      TIMSK &= ~(1<<OCIE2);
      
      if ((F_CPU >= 1000000UL) && (F_CPU <= 16000000UL)) {      // prescaler set to 64
            TCCR2 |= ((1<<CS21) | (1<<CS20));
            TCCR2 &= ~(1<<CS22);
            prescaler = 64.0;
      } else if (F_CPU < 1000000UL) {      // prescaler set to 8
            TCCR2 |= (1<<CS21);
            TCCR2 &= ~((1<<CS22) | (1<<CS20));
            prescaler = 8.0;
      } else { // F_CPU > 16Mhz, prescaler set to 256
            TCCR2 |= (1<<CS22);
            TCCR2 &= ~((1<<CS21) | (1<<CS20));
            prescaler = 256.0;

To:

Code:
 // addition here
#elif defined (__AVR_ATmega128__) || defined (__AVR_ATmega328P__)
      TIMSK &= ~(1<<TOIE2);
      TCCR2 &= ~((1<<WGM21) | (1<<WGM20));
      TIMSK &= ~(1<<OCIE2);
      
      if ((F_CPU >= 1000000UL) && (F_CPU <= 16000000UL)) {      // prescaler set to 64
            TCCR2 |= ((1<<CS21) | (1<<CS20));
            TCCR2 &= ~(1<<CS22);
            prescaler = 64.0;
      } else if (F_CPU < 1000000UL) {      // prescaler set to 8
            TCCR2 |= (1<<CS21);
            TCCR2 &= ~((1<<CS22) | (1<<CS20));
            prescaler = 8.0;
      } else { // F_CPU > 16Mhz, prescaler set to 256
            TCCR2 |= (1<<CS22);
            TCCR2 &= ~((1<<CS21) | (1<<CS20));
            prescaler = 256.0;


However, that results in a compile error:

Code:
MsTimer2.cpp: In function 'void MsTimer2::set(long unsigned int, void (*)())':
MsTimer2.cpp:80: error: 'TIMSK' was not declared in this scope
MsTimer2.cpp:81: error: 'TCCR2' was not declared in this scope
MsTimer2.cpp:82: error: 'OCIE2' was not declared in this scope


Any ideas on what I need to do to upgrade this library to support the atmega368p?

Thanks!

!c
73  Forum 2005-2010 (read only) / Troubleshooting / Re: Analog Sample Rate on: December 19, 2008, 04:39:45 pm
Kind of a silly question, but it makes me wonder nonetheless - if you draw a circle showing where the pot position was, and now is...

Why do you care if you miss samples?  If you're moving clockwise, for example, and your last reading was at 100, and you're now at 120 - you can safely assume you passed through 110 to get there.  (And if someone rotated it all the way around CCW in a mS, you're screwed either way =)

Why not just "fill in the blanks" and not have to worry so much about "real-time awareness"?

!c

Edit: it's kind of like those bar graph visualizers on a stereo EQ - they're not "actually" in real-time, they just appear to be that way.
74  Forum 2005-2010 (read only) / Troubleshooting / Re: eeprom memory resetting on: December 17, 2008, 07:15:37 pm
halley:

I would love to never have to write the following in a sketch again:

void eeprom_write(byte val);
void eeprom_write(int val);
void eeprom_write(long val);

*grin*

!c
75  Forum 2005-2010 (read only) / Troubleshooting / Re: Passing PGM_P into functions on: August 26, 2008, 12:17:47 pm
How could you put a variable into flash memory and at the same time have it available in SRAM?

I'm no expert in C/C++, but I'm fairly certain that the same variable cannot co-exist in both flash and SRAM (as it would have to, in your example.  You told it to initialize a variable, and make sure it goes into flash, but also have it available in SRAM to your function.)

To quote the documentation: "Using PROGMEM is also a two-step procedure. After getting the data into Flash memory, it requires special methods (functions), also defined in the pgmspace.h library, to read the data from program memory back into SRAM, so we can do something useful with it."


It also seems unnecessary to define two locations in flash for the same data.

Just get one function to extract the string you want into a buffer, and then pass the buffer around.

!c


Pages: 1 ... 3 4 [5] 6 7 ... 22