[boji]

Vbe(on) minimum 580mV?  Am I reading that right?

Obviously it's taking much less to switch on.

[ruffrecords]

Transistors are turned on (saturated) by base current. The actual Vbe depends on the saturated collector current - see the VBe sat entry.

Cheers

Ian

[boji]

Duh. What would I do without you guys eyes-n-brains...Thank you!

I ASSume because they leave the minimum blank, any microcurrent value that will get the leg to show proper voltage will do the do.

[squarewave]

At 5ma you don't need the transistors. And I don't see how you're going to do 55 leds with one micro. You need an LED driver or maybe just an I/O expander if it has enough power (although long runs of clock and data could be an issue). Then just do resistors from supply to each expander output pin with the LED across the output pins. The rest is software. Drive one output high and the other low to get one color and then swap high / low for the other.

For lots of LEDs a mutliplexing IC is really the only sane way to go but it's not clear how that would work with bi-color LEDs.

[boji]

Hi SW! Missed your input!

At 5ma you don't need the transistors. And I don't see how you're going to do 55 leds with one micro.

Well, I've not settled on a led yet. Still believing some may require standard 20mA.  But wow yeah, these particular ones are efficient.  Mega has about 60 available pins, so two of them would suffice.
 Edit:more like ~190 pins without plexn'...

maybe just an I/O expander
it's not clear how that would work with bi-color LEDs.

Now that shift registers have arrived going to try to incorporate some hex inverters to see if I can minimize pincount as you suggest, I'm just not that strong at writing code for IC's. Perhaps the inverters will provide the buffering for leds as well, so to omit the transistors.

[ruffrecords]

Duh. What would I do without you guys eyes-n-brains...Thank you!

I ASSume because they leave the minimum blank, any microcurrent value that will get the leg to show proper voltage will do the do.

What you normally do, when operating a transistor as a switch,  is to ensure the circuit provides sufficient base current to saturate it. For worst case design you assume that when saturated, beta drops to no more than 20. You know the rail voltage, you know Vbe (sat) and the base current required; the rest is just ohms law.

Cheers

Ian

[boji]

Maybe these will fit the bill since they can drive led's:
https://www.ti.com/lit/ds/symlink/pcf8574.pdf?ts=1606793008066

Would need quite a few chained together tho.
Much to learn.

[squarewave]

Yeah that looks like it could work. I2c is nice in this case too because you can just connect up to 8 ICs to a 7 conductor bus and then just select the IC you want to listen to your clock and data by playing the right chord on the 3 address pins. So you would only need 5 microcontroller pins for 8 ICs for a total of 32 bi-color LEDs or 64 regular LEDs. Shielded CAT6 could probably make it a meter or so with the right clock speed and termination resistors.

[boji]

Square or anyone else care to recommend a trusted I2C expander?  PCA9548A  looks like a candidate.

Reason is I found the MCP23017.


Thanks SW for the repeated I2C advocacy.  Hope switching between groups won't be very difficult. I imagine it will be about cycling I2C bus addresses on and off during state changes, much like clock latches.

Shielded CAT6 could probably make it a meter or so with the right clock speed and termination resistors.

yessr. thanks

[boji]

FWIW:  I/O expanders bit shift to select, as will likely I2C multiplexer.  For PCA switching, this function simplifies:

Code: [Select]

void chipselect(uint8_t i) {
  if (i > 7) return;
 
  Wire.beginTransmission(PCA_ADDR_1);  //1 of 8 I2C bus addresses
  Wire.write(1 << i);                  //1 of 8 Pin expander chips on given I2C bus
  Wire.endTransmission(); 
}

So after setup, naming chips, setting pinstates and starting I2C, switch in expanders as needed:

Code: [Select]

chipselect(1); // prep to test leds I/O expander 1
   
  for(int i = 0; i <=15; i++) {
    mcp1.digitalWrite(i, HIGH);
    delay(200);                     
    mcp1.digitalWrite(i, LOW);     
    delay(200);             
}

chipselect(2);//switch and prep

  for(int i = 0; i <=15; i++) {
    mcp2.digitalWrite(i, HIGH);
    delay(200);                     
    mcp2.digitalWrite(i, LOW);     
    delay(200);             
}
And so on, ultimately providing up to 512 available sink/source pins over three wires. Neat!

[squarewave]

I realize you're just fiddling but I cannot stop myself from telling people never use delay(). Even for fiddling don't do it. Delay makes it impossible to do more than one thing at a time. Your code will not be reusable.

Instead, loop continuously and compare the current time to the expiration time of whatever event. When the expiration time is exceeded you process the event and go back to looping.

[boji]

Indeed, thanks SQ!

[boji]

Happy Holidays everyone.  I've seen address assignment of I2C chips done both ways as shown below. Do you have a preference and if so, why? 
Note for B, resistors are left out or included so to define assignment, whereas for A, resistors are included no matter the HEX value.



B in layout:

[boji]

Unless otherwise directed, going to go with B as it seems pretty straightforward.

[abbey road d enfer]

Happy Holidays everyone.  I've seen address assignment of I2C chips done both ways as shown below. Do you have a preference and if so, why? 

I vote for B, since I don't like having Vcc (or Vdd) distributed to too many places without protection.

Note for B, resistors are left out or included so to define assignment, whereas for A, resistors are included no matter the HEX value.

Not necessarily.

[boji]

Thank you Abby. B it is.

Not necessarily.

Think I understand, because Vcc could be 3.3 or perhaps lower in some scenarios.

[boji]

First time digital project, about to send out for PCB's.  If anyone has a free moment, wouldn't mind glancing over the attached skiz in case I missed something obvious? Thank you much!

[boji]

Layout attached. 
I2C resistors / pads used depending on mux bus & 1/4 PCBs.

[squarewave]

I don't see anything obviously wrong but I do have two possibly minor concerns.

One is that it seems to me that part of the benefit of using an I/O expander is that you can put it where the devices you're driving are. But in this case you're going to have potentially long control cables? Just brainstorming here but my first thought would be to make a little daughter board with one I/O expander on it and that can be plugged into a board that has relays or LEDs or whatever. Then just run a little bit of two conductor for the low current I2C control signal.

Or, if you do it the way you have it layed out, what is the ground plane situation? What voltage are the relays? If you have large currents going through those transistors, it might be desirable to have a decent ground plane below (or above) those lines to the transistors with a really good ground wire to DGND running right next to (or loosely twisted around) the relay supply wire. Remember ground follows signal. That is super important here since you're delivering currents out in a distributed fashion.

[boji]

Thanks for feedback SW.

you're going to have potentially long control cables?

Yeah I struggled with this decision but perhaps concerns are unfounded. Figured a bundle of shielded i/o wires are better than having a 'digital' pcb in each bucket (right under unbalanced fader lines) chunking away 24/7.  I agree it would be much simpler to put extenders near the i/o endpoints. Looking for a slimline case to shield pcb's, but finishing is becoming more important than anything at this point. :/

Went so far as to order some I2C balanced extenders to test, but they haven't arrived yet.

Or, if you do it the way you have it layed out, what is the ground plane situation?

5v and Gnd planes included, quite objectively to drain those transistors and pull up button sensing i/o
Cut them out for sake of picture clarity-- oops

might be desirable to have a decent ground plane below (or above) those lines to the transistors with a really good ground wire to DGND running right next to (or loosely twisted around) the relay supply wire.

Yessr.  Pulldown/debouncing circuits for relays are onboard each channel card that supplies 12v, and sinks most of it.  I believe as long as m/c pcb's are tied to console dcom, max draw is 0.6mA @ ~3v per relay cv pin.

I should have put a dotted line around that relay buffer circuit on the previous page, they are already installed in each channel/group cards. The logic pcb only sinks cv, not the whole relay loop.

There are better ways to have implemented this whole thing, that's for sure. Live and learn.

Constant Amplitude Phase Shift EQ

Started by Rogy The Lab

Phase shift networks

Started by StephenGiles The Lab

John Hardy 990 vs. 2520: color or no color?

Started by kevinnyc Drawing Board

Transformer and Amp Color and Overload

Started by AudioHammer The Lab