I'm impressed that you finally got this working properly; great job! I know that you've been struggling to get the hardware and the software working properly and together, so it's all the more exciting to see the whole system working. Did you make a decision on the cost vs. power tradeoff for BJTs versus MOSFETs? I'm a bit confused at the display being too dim without a delay, because the average time each LED is lit should still work out to be roughly the same. It would just refresh the LEDs more often.

The reason for the delay I want to assume is due to using the transistors instead of a MOSFET. I feel that its taking to long for the transistor to saturate and get all the current to the leds. I have also decided to go with MOSFETs just because it will be drawing 2.5As a row and I would feel safer having parts that I know are built for that. I went with a smd version of the MOSFETS on the old circuitry.


Pictures of schematics for peer review.



GPA* are being used as LED Drivers.
Both MCP23017's should be hooked up over spi.
Usb is a copy from an old untested schematic >.>
Other then that just want to make sure nothing jumps out wrong like a messed up pullup/down

You certainly could be using slow transistors, from what you described, or did you switch to the 2N3904 BJTs that we discussed? It would be a good idea to try some MOSFETs for comparison, if you can.

You're better off using P-channel FETs than the N-channel ones you've got there, since it looks like you're doing high-side switching. N-channel will introduce a diode drop across itself (well.. kind of) and be less efficient than an equivalent P-channel setup would be.

Hmm I should look into that as it will also negate the need for me to require inverting the outputs before I push them to the I/O pins. Back to digikey for part sourcing! (oh and google for learning about P-channel fet setups)


So for using a P-channel setup I would Use pullups/the I/O pins to pull the gates high (3.3v) so they are off by default and when I want turn them on pull them low with the micro controller pins? My only worry is the pins on the MCP are rated to sink 20ma. I have no idea how much I should expect to need to sink...tho that's what math is for :/

EDIT:
http://www.fairchildsemi.com/ds/FD/FDD4243.pdf

http://www.diodes.com/datasheets/DMP6180SK3.pdf

Both of those look like they should work based off the specs of the N-Channel MOSFET. Though its all conjecture at this point I am only vaguely understanding how MOSFETS work at this point it think.

Yes, basically you can treat a P-channel FET the same way as an N-channel device but with inverted gate polarity (active-low).

As above, inverted polarity. "Off" is high and "on" is low, but nothing else changes.

I can't tell what your gates are doing exactly on the schematic above, but it looks like you didn't have any pulldowns on that either -you should. Otherwise the default hi-z state on your I/Os will leave them floating and free to bound around anywhere.

That's not really relevant. You're driving the gate, which acts like a capacitor, and gate capacitance of both FETs you quoted there is on the order of nanofarads. You might want to put some series resistors on the gate lines to reduce inrush current when switching, but it's probably not a major concern.

The I/O expander module Power on reset sets them to Input so I should put pulldowns/ups on them (I did so in my schematic above) As well as added resistors for the inrush of current you were talking about.


My gates above are taking vcc in the source and pushing that to drain. They are running the Rows of leds. The gates have 100kohm pull downs on them as well as 100ohm resistors between my I/O expander's pins and the gates them selves.

So awesome I shall flip them to P-Channel types then, which seems to be a good idea software wise anyway. With the n-p-n transistors I am using at the moment I need to invert my pin-outs its kinda annoying.

Any thought on which of those 2 fets would be better? They both seemed acceptable to me.

I'd probably prefer the FDD4243 a bit more, since it exhibits slightly lower r_DS(on). On the other hand, the threshold voltage on the DMP6180SK3 is a bit lower, which gives you more headroom. Might just be a good idea to pick the cheaper one, since they're very similar devices.

update parts ordered soldered and wired in

So built assembed and tested that board. It fails.

So I ended up getting mosfets that will not work at the voltage I am supplying (Or there is something worse wrong ). Oops. Lesson of the day we learned how to actually read mosfet data sheets and now have a new candidate for a mosfet to use.
Requirements.
~1A Continuous Drain
2.5V Or lower Vgs
P-Channel Enhancement Mode Mosfet.

https://www.fairchildsemi.com/datasheets/ND/NDS332P.pdf

EEs got any thoughts?

What's your supply voltage and which FETs did you end up getting? Reading the thread history it looks like things should work, so I assume what you've said previously doesn't correspond to current reality.

I think what happened was My supply voltage is actually 3.3V not 5v like I had thought.

You think, or it is 3.3V rather than 5V?

You didn't say what FETs you have either, so I'm going to assume for now that you got the FDD4243s, with V_th specified to be in the range [-1.4,-3].

The MCP23017 specifies maximum low-level output of 0.6V on its GPIO ports, so if your supply voltage is indeed 3.3V it will probably still work unless you got FETs with particularly high thresholds (typical threshold is -1.6V for the FDD4243).

I phrased that wrong. I think what happened is I got my numbers messed up. My Supply voltage is 3.3v.

And if that is the case I wonder where I am losing that voltage....

See the problem I am having which I thought was my MOSFETS is when I hook my circuit up my voltage drops from 3.3v to 1.6V and I honestly have no idea where that is going.

So you're loading down the digital supply with something. I can't speculate on why that is without up-to-date schematics and information on how this thing is being powered.

So third attempt at posting cause I keep forgetting to hit submit.

Tari and I got on a videochat and talked some things out, went over my schematic, and the hardware some. We found out that I was overloading my SparkCore's power supply by trying to drive the Mosfets from its power supply. To fix this we changed them over from being held low with pulldowns to being held high from the external power supply with a pullup resistor (This board has more and more cut traces and solder joints on it day to day ). Now that that is done it works like a charm. Has some flashing issues due to the WiFi communications being a blocking call, Maybe interrupts or something can fix that but time shall tell.

Nice work debugging that issue, Tari and geekboy! Powering the MOSFETs from the Spark Core's power supply definitely sounds problematic, given that I assume the MOSFETs are what drive those LEDs, so it's good that you managed to figure out that that's what was going on. What's next for this project? Do you plan to clean up the code for publication and do a writeup, or do you have more on the software side of things that you still want to do?

Just to clarify I was powering the gates via the spark's power supply. The issue was they were not able to supply enough power to fight the pull downs on the gates. Causing the issue.

A large amount of software needs to be written soon but there will be a writeup as well as a blogpost + github for the code.

Software wise I need to implement a whole slew of graphics routines and setup a double buffer just incase there is lag or something idk. I need to look Into interrupts for rendering the display to try to reduce flickering. Currently the wifi routines provided by the spark core team can block for a little to long and cause the panel to flash nothing to bad.

There is one other idea floating around. It may rival partymode

so yeah gravy biscuits steak.

That's pretty fun! Any planned uses for it now that it's operational?