- It could, if the sampling and tracking cause the ripple to alias into the sensed signal. MPPT is basically a correlation function evaluated in real time; anything that correlates to the test signal, accidentally or otherwise, goes into it. Presumably you'll apply adequate filtering, and/or sampling at a slower (and preferably orthogonal) frequency, and/or a test signal that is in turn orthogonal to sampling or switching frequencies, to avoid this.
(I'm assuming by "algorithm" you intend this to be a digital solution, so I'm invoking the standard DSP stuff: sampling, aliasing, Nyquist reconstruction, etc.)
For example, if switching is 10kHz, sampling is 10kHz, and they're not phase locked, then the exact timing of the two can drift, and sometimes sample on a peak, sometimes on a valley. This introduces a DC error to the sampled signal. (Which isn't a problem in and of itself, because it's not necessarily correlated to the MPPT test signal.)
For another example, suppose switching is 10kHz, sampling is 9.9kHz, and MPPT test signal is 100Hz. The samples will sometimes land on the peaks, sometimes valleys, and this will not happen randomly, but changing smoothly over time, in fact at 100Hz. Which will show up as a signal to the MPPTer, leading to an error on par with the amount of ripple.
A good plan is to sample at such a rate where you can get reasonable coverage over the ripple; higher is always safe, so, sampling at 100kHz say gets 10 samples for every 10kHz switching cycle, and these can be averaged together for a reasonably stable reading at a lower (decimated) sample rate. If you don't have such high sample rates available, then a fraction is fine, too, preferably one that covers the switching cycles in equivalent time: for example an 9kHz rate picks a sample from each cycle, 10% further ahead each time, and entirely skipping over 1 in 10 cycles. Averaging these together and decimating, gets a 1kHz sample rate with similar statistics as the first case -- assuming the switching waveform is consistent and stable between cycles, of course!
Either example would be a fine candidate for an MPPT testing with say a square wave at, at most, a modest fraction of the final sample rate (after decimation if applicable, or bandwidth (lowpass cutoff rate) in general). So, for 1kHz decimation, getting every other sample as tracking signal would be a bit tight, but say 3 low, 3 high, would be fine. So, less than 1/4 or 1/6 say. I suppose it should be an even fraction, too, so you don't accidentally try and split a rising/falling edge in the middle; but this concern also goes away if a more general waveform is used (line a sine wave, and correlating to that directly -- the digital equivalent of using a balanced mixer instead of a synchronous switch for RF detection).
Or you could use something even more general and (hopefully) immune to expected kinds of interference, like a code sequence correlator, etc. (That's horrendously overkill for such an application, but is merely a natural extension of the method.)
Anyway...
- If you need a permanent connection, and the terminal block for some reason isn't adequate, sure, it can be desoldered, wires placed in the holes, and soldered once again. Mind strain relief: soldered wires are notoriously prone to fatigue. The screw terminals are probably better in this regard, used with stranded wire, preferably with a ferrule crimped around.
As for my comment about the converter -- anticipating a future question about that, study current mode control first. Most texts introduce SMPS as, "hey did you know, when you PWM a voltage, you can reduce its average value?" Like, big deal, no one needs to worry about dynamics, ever, right?... The trouble is this: in most SMPS, the inductor current is a free variable, meaning it can take on most any value, independently, if not specifically accounted for by the control. This might seem irrelevant, or helpful -- it has to match the load current eventually, so if it's shooting up or down a bit to get there, maybe it's kinda, just like that? The problem is, the switching transistor/diode can only handle so much current, and fail in not very much time (potentially 100s µs) when that rating is exceeded. A control designed specifically -- and primarily -- to control that current, completely solves this possible mortality.
Once you have current mode control, adjust the current setpoint as needed for whatever end: if regulating voltage, add an error amp to do just that. If regulating input power, or MPPT, add an error amp (and whatever else i.e. MPPT stimulus + detector) on that. You can do both (indeed, probably should, in this case?) by using a wired-OR connection with diodes from the various error amp outputs, into the current setpoint node.
Maybe it's not actually so important for PV, where the source itself is intrinsically limited -- but it still depends, because just the capacitors on input or output can easily store enough energy to destroy transistors, if that energy happens to be used very wrongly for just an instant.
This also goes hand in hand with a caution about digital controls: preferably, solve the cycle-by-cycle behavior in analog, use a controller IC if you must -- indeed, that would be preferred. (And now you don't have to use ploddingly low switching frequencies; 100s kHz are reasonable.) Merely vary the setpoint with a DAC, while monitoring process variables with an ADC. The analog system is intrinsically safe from digital failures -- at worst, the MCU crashing leaves the DAC pegged at full scale, and perhaps a hardware timeout detects the MCU's hung and shuts everything down gracefully. The absolute worst idea is simply slamming gate drivers and an inverter onto an MCU's GPIOs: anything could accidentally set all pins active, and SSST..BANG, there go all the transistors. Good luck debugging that!
