Random Ridiculosities and Experiments

Here's a plausibly-interesting and tangentially-related finding:

"Transient Voltage Suppressor" arrays, apparently often found in ethernet to protect against things like ESD and whatnot, might just do the job for fast-switching high-current freewheeling diodes...

E.G. http://media.digikey.com/pdf/Data Sheets/Bourns PDFs/CDNBS08-PLC03-3.3.pdf

There's also a 7400-series chip that does-so for data-buses, claims 200mA max at some pulse-duration, plausibly if the pulses are short (with fast PWM?) then maybe they could handle even the surges from a motor driven at 2A...?

So, I might be checking my old ethernet cards for these things, as individual Schottky diodes might be somewhat harder to locate on my old PCBs in quantities.

Though, I've thoughts on whether freewheeling diodes are actually necessary with a linear-amp (and my system's expected loads)... more on that in a bit.

-------------

I bought the 4-channel audio-amps mentioned/linked in a previous log. Sale Ends Today! $5 for *14* 4-channel audio-amps! Throw in that set of rotary-tool PCB bits I've been eyeing, for $4-off, and it's a pretty good order... kinda like [plausibly] 14 4-motor driver-chips for $1 ;)

For motor-driving, these TA8251AH's may be a little bit more difficult to interface than the TDA1510's I've been experimenting with... The TDA1510's have inverting AND non-inverting inputs, typical of op-amps, and used (so far) as more like a comparator. The TA8251AH's have a single input for each channel, which might mean the bias-point needs more consideration. Both chips are single-supply, and I don't (yet) know what the input to the TA8251AH is expecting... It might be biased at 1/2 V+, so at 12V (for the motors) that'd mean they'd need something like 7V for "on" and 5V for "off" (in the PWM-sense). From a uC...? I've got a few ideas... Maybe a buffer chip with Open-Collector outputs inbetween... Or a simple transistor+pull-up resistor... Maybe a voltage-divider between the uC output and V+ (and a diode?) could do something... haven't worked that out yet. It's also *plausible* these are biased around an entirely different voltage, being that they're most-likely *intended* to be AC-coupled... We'll see when they get here. Here's some other plausibilities: *maybe* the "standby" pin could be used for PWM, all channels tied together for one high-current output...? Another plausibility is use of the AUX amplifier, which claims it can be directly connected to a uC (though, still, likely through an AC-coupling capacitor, right? Documentation's sparse...).

Also the TA8251AH uses *one* input for *both* outputs, much more like a typical H-bridge chip used for motor-driving... This could be a blessing, few pins to control, but as far as I can think it requires locked-antiphase (where 50% PWM would result in no motion). Not a problem, but a consideration.

-----------------

Gotta get back to experimenting!

(Update: Adding useful resource links and theory on not needing to bias, using op-amps as comparators for simplification. Also, stay-tuned for the actual results with a motor, and some potentially interesting side-effects I hadn't expected!).

During my last experiments with a Class-D (PWM/switching) amplifier as a motor-driver, I somehow completely forgot that I once ordered 10 Linear Audio-Amps (Class-B/AB?) with exactly that experiment in-mind (well, with a linear audio-amp)...

And, oddly, it still hadn't come to my attention that I had this tube of linear-audio-amps until I almost pressed "Order" on these: http://www.goldmine-elec-products.com/prodinfo.asp?number=G15382B TA8251AH.

Yep, until Tuesday, that's *14* 4-channel Bridge-Tied-Load audio-amps for $5. Almost impossible to pass-up... If these linear-audio-amp experiments as motor-drivers works, each of these chips could potentially handle *4* DC motors (or maybe even two bipolar steppers?).

It's really hard for me to convince myself not to place that order... but $10-minimum + shipping means something more like $20, which I can't really justify right now, especially when I have a tube of amps to experiment with.

Some Technical comparisons:

TDA1510 (Mine)

• Single-supply
• 24W BTL
• ONE BTL output
• Has inverted and non-inverted inputs for BOTH half-bridges (essentially two high-power op-amps)
• Nice internal pseudo-diagram, but some undocumented pins to fight with...
• Optional bootstrap capacitor inputs

TA8251AH

• Single-supply
• "30W BTL"
• "x 4ch" (that's 4 BTL outputs!)
• Has a single non-inverted input for each BTL output (fixed gain)
• (nice .1in spacing, with a tiny bit of bending!)
• Kinda sparse documentation, but simple-enough "black-box" I/O...
• No bootstrapping necessary

I first wired-up my CA2002/TDA2002 (single-output) amplifier as a quick-experiment... (5 pins, not too complex to interface)... The results were pretty decent. I have two of these, so moving up to a BTL experiment would be easy... But that's when I remembered my TDA1510's, which aren't much more complex (interface-wise) than two TDA2002's...

Again, the results are pretty decent... There's some oddities at certain switching-frequencies/duty-cycles that I can't quite wrap my head around, and they definitely heat up faster than my LMD18200 (MOSFET-based DC-Motor H-Bridge), but the idea seems doable. (Not too different than my results with the L9947, so might drive these audio-amps with PDM rather'n PWM).

So, trying to figure out where these oddities are coming from, now I'm learning about what a Class-B(/AB?) Push-Pull amplifier does... And maybe even *why* they're not (typically) used for motor-control... (Though, I have seen notes stating that they are *sometimes*, so there's that!). This seems like a great resource for the general idea of Class-B amps (discussed more, below): http://engineering.sdsu.edu/~johnston/ME204/Lecture_Notes/Transistors.pdf, check out starting 'round page 23. And this one's a great resource on motor-driving which even has a section on Class-B amps used as motor-drivers: http://hades.mech.northwestern.edu/images/8/84/ProjectW2011.pdf.

Linear amps are sometimes used in motor control when analog control signals and a bipolar power supply are available, and power dissipation and heat are not a concern. ...
You can use a commercial audio amplifier to drive a DC motor...

(One of the few resources I could find that actually said that straight-out!)

But note, I don't see any reason why two single-supply audio-amps couldn't be used in BTL like an H-Bridge, with the exception that input-biasing is maybe a bit more difficult... And note, the quote above comes from a section which discusses using the *linear* aspect to drive the motor with a varying DC voltage (rather'n PWM)... Still haven't seen a resource regarding using PWM with linear-amps... And that's a key-factor that makes these experiments more-easily doable... Theoretically, alls you have to do is make sure the non-inverting input is higher than the inverting input for a full-railed positive output, and vice-versa for a full-railed ground-output. Potentially, no biasing necessary... Treat those op-amps like comparators... (This is the theory I'm basing my explorations on, here).

Another thing, this TDA1510 has "bootstrap" capacitor inputs, much like the Class-D amp experiments from before... But this guy doesn't *require* them, so I'm looking into what "bootstrapping" does with a BJT-circuit (I thought they were for driving N-Channel MOSFETs on the high-side, but I guess "bootstrapping" is a general-purpose kinda all-encompassing term).

Anyways, the highlight (re: bootstrapping), so far, is this document: http://www.learnabout-electronics.org/Downloads/amplifiers-module-05.pdf

I could just be tired, but its explanation is boggling my mind... I mean, it's just mind-blowing, or something. And doesn't seem to match most of the other explanations I've seen... or is coming at it from a completely different approach, or something.

I *think* the end-result is that bootstrapping doesn't really apply to my case... I'm pretty convinced that I'll be using these in full-on/full-off/rail-to-rail mode, something like PWM... Oddly, even though I've seen mention of linear-amps just like these being used for motor-control, most seem to imply using them as *analog* amplifiers. This kinda boggles my mind, as well. Wouldn't the benefits of PWM (nearly full-on/full-off output, and thus less time spent in the "linear" region where the transistor acts as a resistor, wasting power as heat) work just as well in a case like this, even with push-pull configuration where the emitters are tied together...?

Here, I think, I'm mixing up a couple concepts (again, I'm kinda tired). Bootstrapping seems to be ideally-suited for AC input, and (except for the case where I'm running at 100% duty-cycle), that's pretty much exactly what PWM would look like... So, I dunno. It doesn't seem *necessary* right now, in my experiments, but it might help to clean up some of those "oddities" I mentioned, earlier... And, really, since bootstrapping isn't available in most linear-amplifiers I've looked at, these experiments are more general-purpose if I ignore it. Though, it is a learning-experience.

Anyways, onto some of the oddities:

(This is from the TDA2002)

First, obviously, rise/fall times differ (this might be where bootstrapping could cause an improvement?). Further, the delay from falling input to falling output vs rising input to rising output also differ...

Neither of these are huge concerns, as far as driving a motor... Though it might be wise to lower the switching-frequency so less time is spent transitioning (where the transistors are acting like large-value resistors and creating heat... right?)

Now for what I consider a danged-interesting observation... Check out those edges on the output...

There's a *very* distinct "stepping" going on! I can't explain it. Look at the falling-edge, it looks like it's pixellated. And, though it's hard to see in this photo, the rising-edge is even more distinctly-pixellated. Weird.

No friggin' clue what could be causing that... my 'scope was *definitely* in analog-mode at that point.

(TODO: Does the TDA1510 do this, as well...? Does this happen when loaded, as well?)

We're looking at ~2-5us transitions, here... from one rail to the other. This is *way* faster than an audio-amp is *expected* to deal with... Some *vague* idea it might have something to do with "crossover distortion," when the output toggles from being pushed vs. pulled (from the upper to the lower transistor).

The following is *total* hypothesizing, in the moment, based on my likely misunderstanding of dang-near everything... Keep that in mind.

Output Stage ("Single-Ended"):
                V+
                 ^
                 |
                /
              |/
          .---| 
          |   |\
          |     v (NPN Emitter)
          |      |
  IN >----+      +---------------> OUT
from some |      |
*internal*|     /
amplifier |   |v (PNP Emitter)
          '---| 
              |\
                \
                 |
                 |
                 V
                V-

(interesting finding: NPN: "Not Pointed iN" PNP: "Point iN Please")

(Note: This is NOT half an "H-Bridge" as typically used to drive a motor with PWM, this is a portion of a *linear amplifier* circuit).

(This is assuming we've got a split/dual power-supply... my chip is single-supply, but that's slightly harder to think about).

So, (it seems) crossover-distortion is generally associated with input voltages around -0.7V to +0.7V, where the signal "crosses over" the ground-rail.

In that range, *neither* transistor is turned-on (because of the Base-Emitter voltage of ~0.7V). (Note, also, this portion of a push-pull amplifier amplifies *current*, not voltage. When the input is positive, the NPN transistor is turned on, the output tries to maintain the Base-Emitter voltage, so the output voltage is *roughly* 1-to-1 with the input (minus VBE)).

OK, that makes sense to me...

(Note also, typically they insert a slight but constant voltage-difference between the NPN transistor's base and the PNP's to try to minimize crossover-distortion... At that point, both transistors are on, but one only weakly... dunno whether this audio-amp has that, but it would seem surprising if many don't...).

Now, what if there was a capacitor on the output...?

Then crossover-distortion wouldn't occur at -0.7V to +0.7V input voltage, but would occur when the input voltage *minus the output voltage* is somewhere between -0.7V to +0.7V. The capacitor is charged to some level, say 5V, but the input has switched to -5V... The lower transistor is turned on because the input voltage is lower than the output-voltage, current flows through its emitter to its base. Then....

The capacitor discharges until the...

No, we've got to consider the source of the "input" voltage going into this "output stage"... The source of that input-voltage is a *voltage* amplifier... That voltage-amplifier is likely not push-pull, but more like a "common emitter" amplifier...

(Wikipedia)

The key being: The output of this stage is pulled-up by a resistor... It has to overcome internal capacitances, etc. So, by nearly-instantly changing the *whole circuit's* input voltage, the output of the internal voltage-amplifier might be a bit slowed (again, maybe bootstrapping would help here?).

So, then, we have a slew-rate(?) of the internal-amplifier, which might actually be slower than that of the output-amplifier(?).

Then, again, the output amplifier's lower-transistor would turn on, the external capacitive-load might be at 5V, the input to that amplifier might decrease to, say, 4V, the capacitor is briefly shorted to ground through the lower-transistor, until (quite quickly, in comparison to the slew-rate of the internal amplifier) the external capacitor reaches something like 4.5V... at this point the internal amplifier's output has fallen to something like 3.9V, but that's not low enough to keep the transistor on, so the lower transistor is turned-off. The internal amplifier drops slowly a bit more, down to 3.8V, the transistor turns on, the capacitor discharges to 4.3V, the transistor turns off... There's something there that might make some sense, maybe... Plausibly this requires a bit of internal inductance, or internal resistance, as well...?

I'm losing my thought-train...

A couple observations from the 'scope trace:

1) The falling-edge is much quicker... that'd make sense with-regards-to the idea that the internal amplifier is a NPN common-emitter amplifier. The transistor being capable of depleting internal capacitances' charges quicker than the pull-up resistor.

2) The "pixels" on the rising-edge *almost* look like they're occurring at .7V intervals...? I count 18 "blips" over 12... = .67V per step... INTERESTING.

---------------------

Stay tuned for actual results... They're functional but... interesting. Also, thoughts on plausibly *not* needing freewheeling diodes with a Class-B amp?

If you haven't figured it out yet, I'm not particularly good at analog circuitry... But that doesn't prevent me from being interested in its potential uses!

An ongoing "thing" has been: what can be done with hard-disks...? And, another ongoing-thing has been: how can I actually *see* the data on a hard-disk...?

Something like that, anyways.

I've checked for datasheets on nearly every read-head-amplifier chip I've found from nearly every hard disk I've taken apart for as long as I can remember, with no luck... until recently.

So here we've got a chip marked:

VTC 100

VM355830FVSL

9714 AN

I can't recall *exactly* what I searched for, this time, that resulted in a match... But it was probably "VM355830"

There's a pretty thorough data-sheet on this guy's family, woot!

No idea *what* I'll do with it, but it's nice to know I finally have something that'll convert those *tiny* magnetic signals into something I can see with my 'scope...

One interesting discovery: This chip has a "Servo Mode" which writes the same data to every read/write head... I *think* this is for positioning the voice-coil... and, if so, then that suggests there's a certain data-pattern written to each "platter" in order to detect the position of the read/write head...

I haven't quite pieced it together... This particular voice-coil is attached to three r/w heads. (Why wouldn't they put a fourth on the other side of that second platter...?).

Then, does that mean that one platter contains a "servo" pattern, and the other platters are used for data *in that same track*, or does it mean that all platters are written with a servo-pattern, and the data is written *slightly off* from it... (kinda like a CD, maybe?). Or does it mean the "servo" pattern is written to all platters, then data is written *over* it in some sort of pattern that assures it's always toggling even if the data itself is all zeros...?

The second case is a bit elusive... If the data is written in a track *slightly* off from the servo-pattern, how does the servo keep on that non-servo-marked track? It looks to me like the r/w heads are all two wires apiece, so it's not like there's one sensor slightly off that's used for servoing and another that's used for R/W...

I dunno. Anyways, it's an interesting thing nonetheless.

Today's fixation: Can a Linear Feedback Shift Register be used to perform arithmetic...?

I can't seem to find anything on the matter via search-fu...

But here's a general idea: They're typically used for pseudo-random number generation... whose repeatability is quite low... They're also used for CRC generation/detection. So, if I understand correctly (and I *really* don't... these things are total black-magic to me), there're some cases where ... no I'm totally off, here.

I was thinking there might be some correlation with the idea that for any 4-bit number in, there might be a configuration such that a different 4-bit number would come out. Somehow I equated this to: any two 4-bit numbers in would result in a *different* 5-bit number coming out... and that's what addition does... But that's totally absurd. Then, if it wasn't absurd, the idea would be that it's only a small step from a 5-bit number to a lookup-table, which might save a couple instructions when performing such an operation on huge blocks of data.

Yeah, this whole venture seems utterly ridiculous right now... but it did make sense earlier today. I didn't plan on doing *addition,* I was contemplating using LFSRs to do something even simpler... *comparison*. And, yeah, that's pretty much exactly what they're used for, in the case of CRCs, right?

So, the *original* idea was: I have a memory-block filled with sample-data... And I want to use DMA to run through that entire data block and indicate all samples that equal a certain value, outputting (to a pin(s) on a port) a 0 for not-equal samples, and outputting a 1 for equal samples.

The *very* first idea was to output the raw sample-data, then just feed it through a simple bit of logic... I think @Yann Guidon / YGDES has a favorite 74-series chip for this purpose... And, for this case, I don't think the LUT flash-method we'd discussed would be fast enough.

Then I thought about the Configurable-logic blocks on PIC16's, but apparently they don't have 'em on PIC32's.

Then I started looking into the DMA controller (something I *barely* grasp) and noticed that there's a CRC-generator/LFSR block that can be injected into the process... And, yahknow, it's plausible simple comparisons could be handled via LFSR.

So, in reality, this actual mind-experiment, no matter how it turns out, probably won't be used for my original idea... I was thinking of ways to render stored samples on a raster-drawn screen using DMA without having to load points into a frame-buffer. Even if the LFSR block can be manipulated into giving 1 or 0 for whether the line being drawn corresponds to the value in the samples, I'd still have to do some processing for drawing e.g. two channels simultaneously, coloring, etc...

But, who knows... And it definitely seems to me that DMA with built-in LFSR could be useful for some sort of repeated-processing of huge blocks of data, besides CRC calculation or random-number generation...

I think I'm done with this experiment, for now...

One last photo before I go... This is the "rub-on" etch-resist I used for the really fine-pitched parts of the PCB layout...

This stuff's amazingly easy to work with, you just rub a ball-point pen over the parts you want transferred until they peel off the plastic (very noticeable, as it goes from black to gray). Then use the backing material to rub it in to the copper-clad a little more thoroughly.

You can see the rows I used a lot of; the .1in pads with a trace inbetween. That part would've been difficult with my fat-tipped marker.

I have no idea how old this stuff is, it's barely sticking to the backing anymore, and has probably collected some dust/dirt over the years, still seems to have worked nearly perfectly!

(See the last log for difficulties I'm experiencing using this as a DC motor-driver...)

This is a board designed very-heavily based on the example in the datasheet for this TDA7490 Class-D audio amplifier... Modified for .1in spacing and a few other things useful for my testing-needs... jumpers for switching between BTL and single-ended mode, jumpers for DC-coupled vs AC-coupled input vs Potentiometer-voltage-divider input... Also needed to keep in mind having traces on top

In an earlier log-entry I showed the PCB drawing I did in software before-hand... Here's the latest...

The vast-majority of this PCB was hand-drawn with a permanent-marker (handy to have those predrilled holes on a grid for matching front-to-back!). But some of the really tight spacing (traces between pins) was handled with rub-on etch-resist stencils(?).

I think this might be the first PCB I've etched in over a decade(?!) Was a lot easier than I remembered, and was surprised at how much resolution you can get with little more than a permanent marker!

So, it works, it works with a DC input and I can vary the speed/direction of the motor by adjusting a potentiometer-voltage-divider... But it seems to be overheating (or something) causing it to go into "mute" mode briefly from time-to-time. (see the last log for ramblings on the matter).

I've been having some difficulty, I'll get to that in a second, but something *just now* occurred to me:

So I'm using it in NON-Bridge-Tied-Load method aka "Single-Ended" mode--wherein one output swings positive and negative WRT ground--with the intention of driving two motors...

I wonder if doing-so results in larger noise than using a full H-Bridge... With a full H-bridge we've got two outputs in "differential" mode... They're (almost) always opposite each other in polarity. Twisting the motor's wires would cause quite a bit of cancellation of the noise, right? Kinda like an ethernet cable, MIDI, or LVDS. But in single-ended mode, we've got one side connected to ground and the other side switching between positive and negative. Sure, the *current* has to flow back on ground, and current is what causes EMI (or at least magnetic), right? But something about this speaks to me of "more noisy". Not sure. Not that I've *noticed* an issue with it, yet.

-----------

The other issue was discussed a bit in the previous log-entry... The "Standby/Mute" input is doing something strange... (wherein we may visit one of the potential unknowns I kinda vaguely foresaw: are these chips' being designed for AC signals going to cause problems running a DC motor?).

The datasheet is *really* vague about what this pin does, just like the vast-majority of the chip's functions. As far as I understood, it's an input. It takes something like 5V to run normally, somewhere between 0 and 5V results in Mute (which presents itself as the PWM output running at 50% duty-cycle), and 0V results in Standby (which presents itself as PWM being disabled completely).

So the problem is, sometimes the standby/mute "input" *drops* quite-quickly (almost immediate) to the "Mute" level, the motor stops, then the "input" seems to release and the pull-up resistor and filter-capacitor result in its rising back to the "normal" mode in a fraction of a second. Sometimes this happens repeatedly, other times it just happens once or twice every few seconds.

So, my theory is that the mute/standby "input" is actually *also* tied to an internal transistor which pulls it into the mute-voltage-range via the "protection" circuitry. Which protection feature is triggering...? I have no idea. Thermally: it's occurring even when the chip is only hand-warm, and adding a fan doesn't seem to have a reliably-noticeable effect. But the triggering is quick (and releases quickly), so maybe the internal temp is much higher briefly). Overvoltage? Maybe the edges are spiking...? I don't see it on the 'scope. Though, now that I think about it I do remember seeing *quite a bit* of overshoot (nearly double the source-voltage!) in earlier tests (at the time I was using really long test-leads, now the motor's wired directly to the terminal-blocks with only a few inches of wire, which are twisted...). ACTUALLY (I'll revisit that). The third protection-circuit is over-current... I don't think that's the case, the meter was measuring only 150mA in earlier tests, and even when I stall the motor, it's only a little over an amp, the over-current threshold is something like 4A.

"ACTUALLY" Just occurred to me while writing this... Now that I think about it, I vaguely remember not having noticed this problem when I was running it at +/-12V, but when I tried to run it at ~+/-21V (my bench-supply's limit) I vaguely remember some unknown untested oddities (maybe this!) that I didn't explore too thoroughly. The thing's rated for something like 25V, and if I remember correctly, at 12V I was seeing nearly 25V peaks, so at 25V then maybe it's peaking way past the over-voltage threshold. (For the latest tests I've been running it off a different supply at +/- 18.5V).

That's probably the friggin' answer... Friggin' days of experimenting later. But, still, I don't *see* that overshoot on my 'scope like I did before. Huh. Well, to experiment.

On another tangent: The "potential unknown I vaguely-foresaw" before starting this experiment was something along the lines of... Audio-amps are designed for *audio* signals, which are inherently AC. So, it's quite-likely the chip isn't designed for DC input/output, especially those at the rails... E.G. Certainly "clipping" occurs in audio, so "railed" signals are probably expected to occur, but not expected to stay at those levels for very long durations. This rationale (again *vague* in my mind, especially up to this point) seemed to me to apply to *analog*/*linear* amplifiers more-so than switching/Class-D amplifiers since, for one thing, "DC 0V" output on this class-D amp results in 50% duty-cycle... So, even with no signal/mute the output is still switching full-swing between rails... So I guess I thought maybe a switching amplifier might be less susceptible to the potential problem. Again, it's all vague and likely even wrong, but audio-amps' being designed for AC signals was something I thought *might* have an effect on whether they could be used for DC output... (Especially one where it might be run at one of the rails).

And, lo-and-behold, there appears to be such a circumstance. And now I'm forgetting what it was, I'll have to reread above... But one prime example is this amp's "Bootstrap" inputs... A capacitor is tied between each output and a corresponding "bootstrap" input(?). The datasheet doesn't specify exactly what these do, but my guess is they're used in a charge-pump used to drive the high-side(?) internal MOSFETs. The end-result, as I see it, is the system doesn't actually output full-on or full-reverse (100% duty-cycle or 0% duty-cycle). I'm not sure where the limit is, but with my rough testing, the maximum is not really even close to 100% (or 0%) duty-cycle. Further, as it approaches 100%/0% the PWM frequency seems to drop to 1/2 or 1/3... That's fine for the *output*/load, but what's happening with those bootstrap inputs...?

I think, further, the load has an effect on the ability to "bootstrap" properly under those conditions... There's a feedback loop, like on an op-amp amplification circuit, so as the load increases (e.g. loading the motor's shaft) the "op-amp" attempts to maintain the same (average) output-voltage... So whereas it was already running at something near the limit of probably something like 90% duty-cycle, now the load has increased such that it would attempt to increase the duty-cycle plausibly to the point where it can no longer keep those bootstrap caps charged... On an audio input, this wouldn't be a problem, because the signal wouldn't be "clipping" for that long, but on a motor which is loaded, it may ride at this state long enough to cause trouble. (That said, I've used DC motor-driver H-Bridge chips that have similarly-wired bootstrap caps... surely used them at 100% PWM for long-durations without noticing a problem, and they don't mention pulsed-input/output as a requirement, so where does that fit into this logic?).

Then there was something else weird about the mute/standby input... connecting it directly to 5V without a capacitor seemed to cause random "booting"... (after that 'bootstrap ramble' I think I get why). I thought maybe I could get away with tying the mute/standby input to "on" with a lower-value resistor and ignoring the rest of its circuitry so it wouldn't be suceptible to noise from the rest of the circuitry... (This was before I realized that "input" probably has an internal transistor tied to it for protection...). So, E.G. with that pin tied high and with the same DC input (resulting in the motor spinning) sometimes the motor would spin upon power-up, and other times it wouldn't spin at all, despite the mute/standby pin being pulled to 5V. In the cases where it won't spin, I tried pulling the input low (standby) and releasing it to be pulled-up via 5V pull-up resistor with no effect. I thought maybe it was edge-triggered or something, but that didn't seem to be the case. However, if I connected the capacitor (briefly) between the mute/standby input and ground, that would almost always cause the motor to spin... This one boggled my mind until I wrote all that rambling about bootstrapping... My new theory is that it has to go through "mute" (which is somewhere between 0V and 5V, between standby and on, on the mute/standby input) *to* bootstrap... Mute, again, causes 50% PWM duty-cycle, which would likely allow for bootstrap capacitor-charging which might not happen otherwise.

Alright, so do we have a solution....?

One problem is the maximum duty-cycle... So it doesn't output 100% of the supply voltage... does it matter? Not really, though being somewhat "artificially" limited is a bit irritating, power-supplies of these voltages/currents aren't in high-supply 'round here, and the motors are rated for 24V. OK, so use BTL mode, and a single motor... doable, but a *lot* of circuitry (and power-supplies) for a single motor-driver. But, doable.

One problem is the (now determined likely?) case where voltage-spiking is causing overvoltage protection... This might be fixable with an L/C filter, as recommended for a *speaker*... This one I'm not sure about, but it's worth a try... That L/C filter would filter out the input *to* the speaker, rather than the output of the amplifier, no? But that spiking *might* be from the motor's windings... I can't quite wrap my head around that one... I did measure diodes on the outputs of the amplifier between +VCC and -VCC, so that should take care of flyback-voltages, right? Weird.

And the bootstraping ramblings... if it doesn't work at near-100% PWM for "long" durations that could be a problem, especially since we're already artifically-limited in our output voltage... Since a varying load varies the duty-cycle, that might mean an even more conservative "artificial" limit on the maximum output voltage... or maybe careful watching of the output signal via the microcontroller...

(wait, how does that make sense, again...? Why would varying the load change the output-voltage...? It's PWM, the on-resistance is minimal... what am I thinking or not thinking?)

I have some pics, why aren't (amn't?) I uploading 'em?

Alright! It looks like it's a go (see previous log).

Briefly-recapped, I've a Class-D Audio Amplifier chip that I wanted to try out as a DC Motor Driver. Why not, eh?

Finally finished the PCB-etching and soldering process, and It Works! ish.

There seems to be a weird glitch where the Mute/Standby pin is getting triggered randomly. I can see it with a 'scope, so it must be shoddy wiring somewhere.

Otherwise, as ridiculous as it is, (a lot of pins, a lot of R/C circuits, weird-value higher-than-my-normal-voltage caps, dual-supply, analog inputs, nevermind being designed as an *audio* amplifier...) it seems to be a fine motor-driver.

Some oddities: While 120mA max quiescent current (for the entire chip) doesn't sound like much when talking about switching 4Amps on each channel, remember it's running at (up to) +/- 25V. The docs aren't particularly clear about where that Q-Current is coming from, nor going, but we might be talking upwards of 2-3W (!?), without a load.

Then there's three built-in voltage-regulators "for internal use" at +5V, -5V, and 10V... I chose to tap off the +/-5V to drive a couple potentiometer-voltage-dividers as a DC input for speed/direction testing... Tried to limit them a bit, but had a limited supply of suitable pots, and the input-resistance is a mere 30kohms, so I'm drawing around 15mA on each pot, through what might well be *linear* voltage-regulators, dropping down to 10V from up to 50V... that might dissipate a bit of heat, too.

Anyways, suffice to say, even with a motor running at a measly 150mA at maximum-output (and even when the output is at 50% duty-cycle = no motor movement) the chip is producing a bit of heat. OTOH, stalling the motor bumps it up to about 1.5A, and with some quick-tests that hasn't seemed to cause a noticeable heat-increase...

At first I thought it had to do with all-that switching (200kHz, 50% duty-cycle = off)... The ringing at the edges is *gigantic* (nearly double the supply voltage). Looked into the recommended L/C filters for audio-amps, but all the info I've found so far suggests that the filter doesn't actually reduce the loading on the driver (and may actually increase it?)... (see TI app-notes: sloa023, and sloa119b). And, really, direct-connection of a DC-motor to a high-frequency switching (PWM) H-bridge is pretty common, in my experience... And here we're talking *much higher* frequencies than I'm used to (with the same sorts of motors), so the inductance in the motor should be even better-suited for this, right? (TODO: what was that project, here on .io, where the guy had tiny robot with a DC-motor that didn't have enough inductance, so he added series inductors?). Anyways, I didn't bother with L/C, but did try a series-inductor just to see what'd happen, the result at the chip's output was little change. The output of the inductor, though, of course made for a much more "analog" voltage going into the motor... which I guess has the effect of essentially showing what the voltage would look like somewhere inside the motor-windings, if it didn't have a series-inductor.

Anyways, scrapped the output-filters, added a clip-on heatsink with thermal-paste and it seems fine.

That was a much longer update than I'd planned... I'll throw up some pics and stuff later.

Acquired a bunch of TDA7490 Class-D audio-amplifiers from The Electronic Goldmine for a great price a while back with the intention of trying them out as DC-motor drivers...

A bit ridiculous, but who knows.

Now I'm in need of a semi-permanent DC-motor driver for another project, and so-far all my latest are merely breadboarded, so I thought I'd try it out.

A few things:

• The pin-spacing is smaller than .1in (or even .05in), I managed to bend one out to two rows of .1in spacing, but it's quite a stretch. The second one is three rows.
• It requires a split-supply... +-10V to +-25V, so I figure I'll use two old laptop power-supplies at 19V 3.5A apiece, removing their mutual connection to earth-ground.
• It can do either two channels (stereo) WRT ground (single-ended) at 25W apiece, or one channel in Bridge-Tied-Load mode at 50W. My original intention was to use BTL, since that'd make for an H-Bridge, but now I don't see that that's necessary. Since it's split-supply, a single half-bridge and "Locked-Antiphase PWM" should do the job, right? Also calculated that the motor's using right around 24W at 12V, and don't really intend on using it much beyond that, so with PWM, single-ended should do the job.
• It takes in *analog*, obviously... I figure I'll use a uC PWM pin, and a low-pass R/C filter.
• Its input is most-likely +-, and calculated (from the reported gain) to be around 1V p-p (typical audio line-level, right?), so I figure I'll use a couple voltage-dividers in series. The first will bring it down from 0-3.6V to something like 0-2V, the second will be attached to the negative-rail, so it'll pull that 0-1V to something more like -0.75-+0.75V. I haven't really done the math, except as a proof-of-concept, since I don't *really* know the input-specs of the amplifier. I'll probably just throw in two potentiometers, one for scaling, the other for offset.
• It's designed for *AC* input... (via AC-coupling capacitor). This is one of the more-questionable aspects... Who knows what its "0" bias-point is...? Is it *actually* at 0V? MAYBE: since I'm planning to use less than its maximum output-power (12V of 19V -> 63%) and since I'm planning to use locked-antiphase (50%PWM duty-cycle = 0 power -> 63%power -> ~80%PWM duty-cycle?)... and *maybe* the thing can actually respond to higher-than-audible frequency-inputs (it has ~200kHz PWM output!)... Then *maybe* I can get away with directly inputting the uC's PWM and plausibly even disregard the gain in-hardware, send it "rail-to-rail"... hmmm (new idea, as of this writing).
• It uses a *lot* of support-circuitry compared to most dedicated motor-H-Bridge chips, including *several* R/C filters, and L/C filters as well.... Nevermind *4* 2200uF 25V capacitors (large!).

There's probably more I'm forgetting...

Either way, that last bullet-point is a bit annoying as far as using this chip as a motor driver in *several* projects... This'll probably end up being a one-off. So I decided that even if this doesn't work as a motor-driver, I could make use of it as a... *cough* audio-amplifier *cough*. So I decided to make a somewhat general-purpose board for experimenting that'll also be usable as it was intended.

The beginnings of which are shown in the image, above...

I usually do point-to-point hand-wiring for one-off things like this, ("infinite" layers for "traces"!), but I'm running low on solderable-breadboard of that size... And this'll be somewhat permanent one way or another, so why not try my hand at PCB-etching again (it's been over a decade!). I haven't any laser-printer toner in my possession, and my laser isn't yet attached to a reliable 2-axis system (seriously, @johnowhitaker figured out how to laser(verb) toner directly onto a PCB, brilliant, and definitely in my TODOs once I have my 2-axis system running!). and I don't have a laser-printer for toner-transferring, so I'm trying the "old" method of PCB-etching... traces drawn by-hand.

I tried to hand-draw the thing on paper before laying it out, but it's a little bit difficult for several reasons, so I ended up drawing it in a regular ol' PCB program (gEDA PCB)...

This layout is *highly* derived from the example in the datasheet, but of course modified for my multi-purpose experiments, and a few other things.

The Copper-Clad board I decided to use is *pre-drilled* at .1in spacing, so that's kinda handy and kinda not. It definitely makes layout a bit more complicated... Nevermind all the pins needing to be .1in (which, again, the chip isn't), there's also a bit of work to be done to assure that traces don't go through holes and get cut in the process. A few other things, as well... Also some consideration as to how to solder on both-sides things that mount right-atop the board, like the big-ass capacitors and the terminal-blocks (as opposed to having leads that stick a little above it, like resistors and ceramic-caps).

This project would've been done several days ago if I'da done it point-to-point on a breadboard. But now I'm *finally* on to transferring (by hand) from the PCB-layout in software to the copper-clad board (again, shown in the first picture).

Some of the really skinny traces and traces-between-pads will be difficult with a permanent-marker, but I long-ago acquired a bunch of stuff from a robo-hacker friend who went guitarist, including a bunch of these press-on/rub-on "dry transfers" from RadioShack that should handle the really tight spots.

The latest delay is that my permanent-marker-traces bridged a little bit in a few places, and I accidentally drew a crossover of one trace, so I need to figure out how to clean those up... worst-case-scenario I'll etch then fix it up with a razor-knife or dremmel, but I'd like to clear it up before etching (I figure there'll probably be a few non-pen-related issues in the etching-process, anyhow... better to alleviate as many as possible from the start!)... So I'm thinking either a cotton-swab and some alcohol, or maybe a toothpick... both of which might just result in spreading it 'round. Alternatively, maybe just *scrape* the ink off those areas...

This was supposed to be finished *days* ago... the project I'm doing this for has been in-the-works and thus non-functional for far too long!

(The project this is for is the first axis of a large modular 3-axis system... hopefully usable for several purposes including a lathe, a mill, a [PCB] router, laser-table, and (with this first axis) a drill-press, The mechanics of the first axis are functional. The "drill-press" idea includes a second motor which will be used-as/attached-to the lever... A feedback-loop between the two motors (and encoders) will, hopefully, allow for force-feedback despite the significant gearing-down of the axis-motor. Another new experiment...

I've got a few-years-old WiFi doodad and, believe it or not, Google seems to imply no-one has hacked it yet.

Weird.

Spent most of the day looking into it, and ironically, it's running Linux already. Redhat, it seems. Found a few test-points and sure-'nough two are for a serial-port and the kernel's already routed to 'em, and once that's wired-up logging in as root is pretty-durn-simple.

So, actually, it's a 4G-Hotspot... and it's kinda weird.

First I found the processor, which is clearly marked "ARM" despite there being no info on it except a whitepaper on the 'web. That whitepaper claims it's dual-core, but I'm almost certain Linux is only running on one core (what's the other doing?). The thing is, it seems to be detecting a slightly older model of the CPU (that musta been single-core?). So, there's that. I have yet to find a (open-source-hacked) router based on this chip, but have found several based on the one it's detecting.

Then there's the wifi aspect... Apparently this thing has *two* WiFi devices, and, again, only *one* is implemented in software. Though, Linux detects them both, only one is actually configured. And looking at the board, it seems both are clearly *physically installed*. Some of the commented-out configuration options suggest that it might've originally been designed for a "guest" access-point (over 4G?!)

Oh, and the screen's kinda fun... It's a color graphical LCD with both an SPI and parallel-RGB interface. Would be great for something like an AVR project (and, in fact, it is included with an Atmel Dev-Kit). It seems, oddly, that the screen is handled entirely by an application and wired-up only with SPI... There's a framebuffer device (fb0), but it doesn't seem to be used for anything, and would it actually send the right SPI commands to the display if it was? It almost seems like fb0 is a dummy-device.

So, I've been looking into hacking it for my needs... My "network" is currently wired-only, and my desktop's old wifi card is weaker than my phone's... So it's a bit weird to use a 4G-Hotspot as nothing more than a WiFi Router (and USB NIC), but that may well be how I'll end up using it.

Coupled with my Pentium-150 laptop with PCMCIA WiFi card (and hard-disk that didn't spin-up until I dropped it), and VNC, I think I might finally get to sit on the couch and surf the web or maybe even work on a software project again, and on a reasonable-sized screen and a keyboard, to boot! :)

(Repairing my PowerBook G4's GPU is daunting... I've tried a couple old iBooks with the same problem and made 'em worse. I've got the idea down, preheat the bottom of the board, be more careful about it being perfectly stationary through the whole process, cool it slowly, a few other things... the most-daunting aspect is all those blasted screws which've been out of it for over a year, now. Still sitting on their heads in the original layout on a cookie-sheet in my cupboard... Will I remember which are the *bare minimum* to reassemble the thing *just to test* whether it worked? ...among other things. VNC on a P150 is starting to sound quite doable in comparison).

...Heh, and I thought I'd have to install openWRT or DD-WRT or something, and since this machine/CPU hasn't been documented-as-hacked, I figured I'd have to figure out how to detect the CPU core, the memory/IO mappings, how to compile new firmware, send it over JTAG, and more... Now, it almost looks like I can just change a couple configuration-files...?! Shoulda done this *ages* ago. Anyways, not there yet, have to figure out *which* configuration files to change. There are about four copies of each one in various locations on the various partitions. And the ones I've looked at, so far, don't seem to have the options I'm looking for.

Also, it's pretty locked-down, as far as being able to export/import files... SSH and Telnet aren't even installed, it seems... The only thing I've found so-far is Curl... (and, oddly, support for a wide-range of SCSI CD-ROM drives?! As far as I can tell, it doesn't even have USB-HID support!). Not sure if what I'm going-for *can* be done with the supplied applications... and don't (yet) know enough about the various ARM cores and Linux incarnations to know whether I can just cross-compile an application to a target that doesn't have header-files, etc.

UPDATE: I think I found my answer on that one... maybe not kernel modules (yet), but surely applications.