Jump to content


  • Content count

  • Joined

  • Last visited

About ayilm1

  • Rank
    InsanelyMac Protégé
  1. I'm not really clear on the specifics of your application but I can clarify the difference between an operational amplifier and a rectifier. At the bare minimum, they both operate on semiconductor junctions, though I'm sure you're already familiar with this. But that's where the similarities end. The op-amp does exactly what it suggests; it amplifies a small input signal to a larger one using a secondary (or auxiliary) input. They're packaged all fancy into an IC but underneath all the plastic, it's merely a common emitter transistor amplifier. Hence why it's a semiconductor system. The output will look exactly the same as the input, but amplified and inverted. The bridge rectifier on the other hand produces a vastly different output. Your input (in this case an audio signal) after being processed by the rectifier will be exactly the same (with a loss of about 0.7v from the peak-peak voltage) but everything will be the absolute value of its counter part. As you probably know, sound travels in waves and can be therefore be modelled by the humble sine function. Alterations in pitch are simply increasing/decreasing frequencies and changing volume is easily represented by the amplitude of the wave. An AC signal is also modelled by sine waves, and bridge rectifiers are the first simple piece of circuitry that mains power is passed through on its way to becoming a steady DC output. So as you can imagine, sound waves being passed through a bridge rectifier will simply be the same as what went in, but everything will be positive. I said earlier that op-amps just amplify the input signal. Well, I kind of lied. Since they are also semiconductors at the core, they can also be used to rectify signals. The only difference is, they will rectify as a half wave rectifier would (i.e. Only the positive domain of the signal is preserved and the negative is clipped). In order to operate in this manner, the circuit will need to be biased towards either saturation or cut-off, but not completely. Just enough to clip the negative/positive domain of the input signal. If you want the VU to react to changes in magnitude across both domains (i.e both the positive and negative), the transistor rectifier isn't of much use, since half the waveform will be scrapped. The bridge rectifier on the other hand will give you a both positive and negative domains as a single positive magnitude. The only problem you face with the rectifier is audio output signals are typically around 0.5V peak to peak. A diode requires about 0.7V (or 1.4V peak to peak) to even turn on! So the rectifier's useless as well. However, using the op amp, you can amplify the audio signal to a level that suits your VU. You will need to determine what input voltage the VU meters need to be excited and work back from there. If they say require 0.25V to output a reading, that would mean an input signal requirement of 0.5V peak-peak. However the 0.5V only applies if the VU has a rectifier built in. If it doesn't, I'd assume it only operates on input magnitude (which is more likely). Ergo, you would only need an input voltage of 0.25V (say). To produce an output of this magnitude from the bridge rectifier, you will need to consider the operating voltage of the diodes 0.7V. Since a bridge rectifier has 4 diodes in total, only 2 of which are operating at any given point. They will take a toll of 1.4V from the input signal. Now since the output from the rectifier is rectified (duh) and the input is sinusoidal, you will need a 1.65V (i.e. 0.25V+1.4V) amplitude on the signal, or 3.3V peak-peak. If your audio output on the PC is only 0.5V peak-peak (again, I'm ball-parking values for convenience), the amplification will need to be 6.6V/V (math: 3.3V/0.5V). This is the gain you will need to produce with the op-amp and will depend on the IC you purchase. If it produces too much on the output, you could always use a voltage divider to fine tune it prior to rectification. Also, don't worry about the output being inverted, since it will be rectified anyway. To help clarify this is how your circuit should be set up: Input signal (PC output) -> op-amp -> rectifier -> VU
  2. Add a power resource wake to your H_EC device.
  3. You don't have hardware acceleration working. Fix it and they'll show up.
  4. ayilm1

    Second sleep problem

    Never mind, fixed it. See here. http://www.tonymacx86.com/mountain-lion-laptop-support/80882-guide-mountain-lion-installation-samsung-np550p5c.html
  5. ayilm1

    Need Help Enabling Brightness Control

    At least do some research before answering... No, it does not use "DSDT modification on the fly". What does that even mean? ACPI tables CANNOT be modified "on the fly." They are loaded at startup and a restart is require for changes to take effect. Shades is also universal binary. If you knew what you were talking about, you'd know that ACPI is unique to Intel only. IBM used a completely different approach. So yes OP, unfortunately you had it right, it only changes the colour. My machine has the same problem, only the difference with mine is the brightness stays at max until the slider is fully turned down. Then the backlight switches off. This did give me some hope that the backlight is controlled through the EC. I originally thought that the existence of AMW0 (Windows Management Instrumentation) in my DSDT made an impact, but I have another system with it that only required PNLF to get backlight control going. That was a faulty assumption to begin with since RW-Everything clearly showed the registers changing when I fiddled with the slider under Windows. At the moment, I'm combing through the Q and GPE methods to see if there are differences. I'll post my findings.
  6. ayilm1

    Second sleep problem

    Interestingly enough, I have the same problem on my Samsung machine. First sleep is deep and the power LED turns off. Wake takes a few pushes of the button. On the second sleep, the LED remains on, fans turn off as normal but start up again after 2-3 minutes. One push of the power button brings the display back. In both cases, the system log reports the power button as being the wake reason (PWRB) which is expected. Both sleep causes are the same (5, which I believe implies it was user initiated) and there are no preceding wake reasons on the second sleep cycle. I've already eliminated the sleepimage in /var/vm as being the cause since forcing it to regenerate by deleting it after the initial sleep doesn't fix the problem. I didn't think it would anyway since the sleepimage is only ever utilised to recover from an unexpected shutdown (only on real Macs as far as I'm aware). That being said, I tried forcing sleepimage to be used by starting with ForceWake=Yes but this did not remedy the problem. At the moment I'm focussing on _WAK. I do however get the growing feeling that the cause is outside the scope of the OS since the kernel is unaware that the machine wakes up mid sleep (since it detects PWRB as the wake reason every time). We'll see though, too early to say at the moment.