-
Six months old models are not "current" models, this moves really fast. Tried right now that car washer dilemma: Haiku failed miserably; Sonnet had difficulties; Opus almost did it; and Fable did it correctly. The oldest one is Haiku, 11 months old.
Will see in 5 years what future models can do and if magpies finally learnt Python.
-
No that doesn't mean the brain solves problems by brute force at all. The fact the brain can solve problems, using less power, with many orders of magnitude less training data, processing speed and storage, indicates that it is doing something which even the latest AI models can't. Of course this can be overcome to some extent by training, but that means nothing.
Current models struggle with thinking rationally, otherwise they wouldn't suggest silly things such as walking to the car wash to get their car cleaned, as demonstrated by the lawyer in the video below.
Well, one of the key differences between LLMs and the human (or most animal brains) is that the brain can organically grow and change over time, but an LLM is fixed. You can influence some behaviour of an LLM by changing the context and the prompt but the base model remains unaltered. This is how chatbots implement memory. There is ongoing research into models that can alter themselves to implement self-learning but this is a very nascent area.
-
There is the brute force approach which doesn't need much intelligence, then there's the methodical and rational approach which does. My understanding is machine learning does both, but more of the former, than the latter.
My observation is the opposite. Brute forcing does not really work in complex programming task, it's a dead end. The reason why modern AI works in software development is that it's methodological and does a lot of reasoning and most importantly, reads a lot of required context and checks assumptions. It works like good and responsible human developers do, just much faster. The speed and much lower cost allows it to do more of the checking / reasoning before starting - humans usually have to compromise more and lock in with some assumptions simply because of lack of resourcing.
The days of AI doing a random edit are over long (relatively speaking; a year on this field is a long time) ago. -
That is true in some respects. For example ML chess models are better than hard-coded ones, but that doesn't change the fact that ML definitely does have its limitations i.e.being able to figure out whether the sun rises causes a cockral to crow, or the cockral crowing causes the sun to rise, by pure reasoning alone.There is the brute force approach which doesn't need much intelligence, then there's the methodical and rational approach which does. My understanding is machine learning does both, but more of the former, than the latter.
My observation is the opposite. Brute forcing does not really work in complex programming task, it's a dead end. The reason why modern AI works in software development is that it's methodological and does a lot of reasoning and most importantly, reads a lot of required context and checks assumptions. It works like good and responsible human developers do, just much faster. The speed and much lower cost allows it to do more of the checking / reasoning before starting - humans usually have to compromise more and lock in with some assumptions simply because of lack of resourcing.
The days of AI doing a random edit are over long (relatively speaking; a year on this field is a long time) ago. -
Six months old models are not "current" models, this moves really fast. Tried right now that car washer dilemma: Haiku failed miserably; Sonnet had difficulties; Opus almost did it; and Fable did it correctly. The oldest one is Haiku, 11 months old.
It depends on the reasoning effort. Models in non-thinking mode still fail the car wash and laundromat tests most of the time, while models set to high reasoning effort almost never do. Even a 27B parameter model running on your own PC will answer the usual trick questions and brainteasers correctly if you enable reasoning.
It's impossible not to feel sorry for people who saw a model get something wrong last year and formed an opinion that they are now unwilling to let go of. They are literally dumber than their own computers at this point. -
Six months old models are not "current" models, this moves really fast. Tried right now that car washer dilemma: Haiku failed miserably; Sonnet had difficulties; Opus almost did it; and Fable did it correctly. The oldest one is Haiku, 11 months old.
It depends on the reasoning effort. Models in non-thinking mode still fail the car wash and laundromat tests most of the time, while models set to high reasoning effort almost never do. Even a 27B parameter model running on your own PC will answer the usual trick questions and brainteasers correctly if you enable reasoning.
It's impossible not to feel sorry for people who saw a model get something wrong last year and formed an opinion that they are now unwilling to let go of. They are literally dumber than their own computers at this point.
I was one of those people a year-ish ago, never thought AI models would help with coding, decided to do a free trial (back then) of Github Copilot and ... yeah, I changed my mind pretty quickly. These models are genuinely game changing.
I don't think that there's a multi-trillion-dollar industry worth of AI to come, but I could easily see hundred billion dollars kind of scale just from what it does for software engineering.
These models still make... strange and quite "dumb" mistakes... but also school me from day to day, and I'm learning more than I ever did with Google and StackOverflow. -
What I've noticed is that they make fewer strange and dumb mistakes every year (or lately every month), while I make more.
The first couple of time derivatives are what matter in cases like this, not the state of the art at any given moment. -
That's a little harsh. Many of those with outdated opinions just don't use AI often enough to update them.Six months old models are not "current" models, this moves really fast. Tried right now that car washer dilemma: Haiku failed miserably; Sonnet had difficulties; Opus almost did it; and Fable did it correctly. The oldest one is Haiku, 11 months old.
It depends on the reasoning effort. Models in non-thinking mode still fail the car wash and laundromat tests most of the time, while models set to high reasoning effort almost never do. Even a 27B parameter model running on your own PC will answer the usual trick questions and brainteasers correctly if you enable reasoning.
It's impossible not to feel sorry for people who saw a model get something wrong last year and formed an opinion that they are now unwilling to let go of. They are literally dumber than their own computers at this point.I was one of those people a year-ish ago, never thought AI models would help with coding, decided to do a free trial (back then) of Github Copilot and ... yeah, I changed my mind pretty quickly. These models are genuinely game changing.
Of course things change quickly and I will change my opinion accordingly.
I don't think that there's a multi-trillion-dollar industry worth of AI to come, but I could easily see hundred billion dollars kind of scale just from what it does for software engineering.
These models still make... strange and quite "dumb" mistakes... but also school me from day to day, and I'm learning more than I ever did with Google and StackOverflow.
I do think AI is great and that it is genuinely helpful, but I can also see its limitations.
At the moment it isn't something I can use in my current role due to security concerns.
And I don't think I put my point across very well regarding brute force. How many lines of code has a sate of the art model AI model studied, compared to a team of say 10 programmers? I dare say many orders of magnitude more. Could you give a model which has only been trained up to the typical level of education of an above average 18 year old, give it a book on C programming and expect it to solve any real world problems? If so, then I would be genuinely impressed.What I've noticed is that they make fewer strange and dumb mistakes every year (or lately every month), while I make more.
One should also be careful when extrapolating. Very often something will improve slowly, then undergo rapid development before stagnating again.
The first couple of time derivatives are what matter in cases like this, not the state of the art at any given moment. -
Could you give a model which has only been trained up to the typical level of education of an above average 18 year old, give it a book on C programming and expect it to solve any real world problems? If so, then I would be genuinely impressed.
With that specific constraint probably not. But neither will any above average 18 year old when you give them the task to first read and memorize a C book without any access to answer any questions that might arise and no way to actually write any code. And then later ask them to solve a real world problem with only the knowledge they memorized from that book. Even open book will likely not help, since if it is not in there, it will be very hard to come up with anything reasonable, especially if time is constrained.
As for the 10 programmers, a state of the art AI model has been trained on orders of magnitude more data, but it also "knows" orders of magnitude more. Which one is greater, is likely hard to estimate. -
AI models clearly "think" differently to humans. We know this to be true because you have to pre-train models extensively on huge amounts of text to get them to even predict simple English language completions. The model that first started the boom, GPT-3, was 175 billion parameters of 16-bit float, and required at least 500GB of data to train on. But that's because they aren't human brains. We've just solved the problem of pair programming in a different way to billions of years of evolution.
I was one of those people a year-ish ago, never thought AI models would help with coding, decided to do a free trial (back then) of Github Copilot and ... yeah, I changed my mind pretty quickly. These models are genuinely game changing.
Of course things change quickly and I will change my opinion accordingly.
I don't think that there's a multi-trillion-dollar industry worth of AI to come, but I could easily see hundred billion dollars kind of scale just from what it does for software engineering.
These models still make... strange and quite "dumb" mistakes... but also school me from day to day, and I'm learning more than I ever did with Google and StackOverflow.
I do think AI is great and that it is genuinely helpful, but I can also see its limitations.
At the moment it isn't something I can use in my current role due to security concerns.
You can run local models on modern computer hardware. Models like Qwen-3.8-27B for instance are almost as good as older, formerly SOTA models like Claude Sonnet 4.5. They require a PC with 16-32GB of RAM, and a CPU with many threads, or a GPU that supports addressing larger memory pools.
They obviously cannot create security concerns since the model is just a gigantic mathematical vector describing how to transform tokens, and it runs only in your personally controlled environment (llama.cpp, or other environments), so it won't be uploading data to some datacenter somewhere or spying on you - it literally couldn't even if the model designers wanted it to do so.
Many of these models have been trained on distilled outputs of SOTA models. Frontier AI companies love to argue that this is illegal and IP infringement, but the outputs of AI models aren't copyrightable (because no human authorship was involved), and... well, they didn't pay for their training data either, so I think it's rather hypocritical frankly. What is interesting is how capable open models are despite being much smaller than the models they were trained off. There's obvious knowledge limitations, and they can be more prone to hallucination, but in mainstream work (Python, C/C++, that kind of thing) they're easily just as capable as the frontier models, but around 1/50th the size.
-
It depends on the reasoning effort. Models in non-thinking mode still fail the car wash and laundromat tests most of the time, while models set to high reasoning effort almost never do. Even a 27B parameter model running on your own PC will answer the usual trick questions and brainteasers correctly if you enable reasoning.
True.Quotebruce@k3:~/llm_models$ llama-cli -m Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf -t 4 --reasoning on --temp 0.2
Loading model...
▄▄ ▄▄
██ ██
██ ██ ▀▀█▄ ███▄███▄ ▀▀█▄ ▄████ ████▄ ████▄
██ ██ ▄█▀██ ██ ██ ██ ▄█▀██ ██ ██ ██ ██ ██
██ ██ ▀█▄██ ██ ██ ██ ▀█▄██ ██ ▀████ ████▀ ████▀
██ ██
▀▀ ▀▀
build : b1-17ce6aa
model : Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf
modalities : text
available commands:
/exit or Ctrl+C stop or exit
/regen regenerate the last response
/clear clear the chat history
/read <file> add a text file
/glob <pattern> add text files using globbing pattern
> I want to wash my car. The car wash is 50 meters away. Should I walk or drive?
[Start thinking]
Here's a thinking process:
1. **Analyze User Input:**
- Goal: Wash car
- Distance: 50 meters to car wash
- Question: Should I walk or drive?
2. **Identify Key Factors:**
- Distance is very short (50 meters ≈ 164 feet)
- Purpose: Going to a car wash (implies the car needs to be there for washing)
- Practical considerations:
- If you walk, you can't bring the car
- If you drive, you bring the car to the wash
- 50 meters is extremely close - walking is feasible, but driving might be impractical/unnecessary
- Car washes typically require the vehicle to be present
3. **Evaluate Options:**
- *Walk*: You arrive at the car wash, but your car is still at home. You can't wash it. Unless you're going to buy supplies or check hours, but the goal is to wash the car.
- *Drive*: You bring the car to the car wash. Even though it's only 50m, you need the car there to wash it. However, driving 50m might be overkill, but it's the only way to get the car to the wash.
- *Alternative*: Maybe the car wash is mobile? Or maybe you can push the car? (Unlikely/impractical)
- *Practical reality*: At 50 meters, you could technically drive, but it's so close that walking to the car, starting it, and driving 50m is probably more effort than necessary. But you MUST bring the car. So you'd drive it.
4. **Identify Logical Contradiction/Key Insight:**
- The core issue: You can't wash a car that isn't at the car wash. Therefore, you must bring the car. Walking alone won't work. You need to drive (or otherwise transport) the car to the wash.
- At 50 meters, driving is technically possible but might be inefficient. However, it's the only logical choice if the car wash requires the vehicle to be present.
- Could also consider: Is it a self-service car wash where you bring supplies? Even then, you need the car there.
- Maybe the user is being playful or testing logic? I should address it straightforwardly but note the practical aspect.
5. **Formulate Response:**
- Acknowledge the distance (very short)
- Point out the key requirement: The car needs to be at the car wash to be washed
- Explain that walking alone won't work because you can't take the car with you
- Recommend driving (or using the car) to bring it to the wash, even though it's only 50m
- Add practical note: At 50m, it's so close you could probably just drive it over, or if it's a mobile wash, maybe you don't need to go at all
- Keep it clear, logical, and helpful
Draft:
You should drive (or rather, use the car) to bring it to the car wash. Since the car needs to be present to be washed, walking alone won’t work—you can’t take the car with you on foot. Even though 50 meters is very short, you’ll need to drive it over. That said, at that distance, it might be more practical to check if the car wash offers mobile service, or if you can just wash it yourself right where it is!
6. **Self-Correction/Refinement:**
- Is there any scenario where walking makes sense? Only if you're going to buy supplies or check hours, but the stated goal is "wash my car."
- The response correctly identifies the logical necessity.
- Tone is helpful and slightly light but factual.
- Could add: "If you're just checking the car wash or buying supplies, walking is fine—but to actually wash the car, you need it there, so drive it."
- Keep it concise.
Final check matches draft. Ready.✅
[End thinking]
You should **drive the car** to the car wash.
Here's why: The whole point of going to a car wash is to have the vehicle there to be cleaned. Walking alone won't work because you can't take the car with you on foot. Even though 50 meters is extremely short, you'll need to drive it over.
That said, at that distance, it might be more practical to:
- Wash it yourself right where it is (if you have supplies)
- Check if the car wash offers a mobile service that comes to you
- Confirm the car wash is actually open and ready for you
But if your goal is to get the car professionally washed at that location, you'll need to bring it there by driving.
[ Prompt: 17.6 t/s | Generation: 5.3 t/s ]
It took 90 seconds to print all that on my SpacemiT K3 RISC-V board, while using 14W of power.
A bit overboard on the thinking process maybe, but still a minute and a half is not long to wait.
-
Heh; I like that oddly qualified statement used in that process:Quote
Car washes typically require the vehicle to be present
(of course not counting those magical mystical car washes that can wash the car whether it's present or not) -
Heh; I like that oddly qualified statement used in that process:
QuoteCar washes typically require the vehicle to be present
(of course not counting those magical mystical car washes that can wash the car whether it's present or not)
Well, I suppose it's technically true. AI models are good at that kind of reasoning when you look at their chain of thought. You could construct a car wash and never wash a car, and still call it a car wash... although, it might not be a particularly profitable endeavour. Fortunately for Qwen, the other part of the model thought that concept was bonkers and quickly discarded it.
I've noticed this kind of behaviour in other models even without iterative refinement. It suggests more than next-token prediction is happening. For instance, I've had Claude Opus do something like:QuoteYou could do this thing, which can be done by:
[code block]
And that'll solve your problem -- but wait, maybe it won't. Actually, do this instead:
[different code block]
Even though the text output after the chain-of-thought phase, where reasoning happens, is apparently linear next-token-please kind of prediction, the internal backtracking seems to get triggered sometimes and you get this "thought leakage" in the main stream, too.
-
Quote
You could do this thing, which can be done by:
[code block]
And that'll solve your problem -- but wait, maybe it won't. Actually, do this instead:
[different code block]
Even though the text output after the chain-of-thought phase, where reasoning happens, is apparently linear next-token-please kind of prediction, the internal backtracking seems to get triggered sometimes and you get this "thought leakage" in the main stream, too.
No!
That's where I'll continue to fight you on this.
It is not reasoning.
And no, it's not just semantics. -
No!
That's where I'll continue to fight you on this.
It is not reasoning.
And no, it's not just semantics.
OK. What do you call it, if not reasoning? It seems a pretty succint term for what is going on. And it distinguishes the "think" region from the "output" region. Much like people... well, most people... think before they speak or write.
Calling it 'reasoning' doesn't mean I think LLMs think & reason in the same way humans do; that's pretty clearly not the case. -
OK. What do you call it, if not reasoning?
Sadly, you can't argue with someone who doesn't care what's real or what's true.
It doesn't matter how many novel math problems are solved by LLMs, how much original code is written, or how many out-of-distribution benchmarks are saturated... Analog Kid knows better.Heh; I like that oddly qualified statement used in that process: Car washes typically require the vehicle to be present.
The model that gave him that answer is about 1% the size and power of current models, by the way. Notice how far you had to move your own goalposts just to accommodate that. -
Sadly, you can't argue with someone who doesn't care what's real or what's true.
It doesn't matter how many novel math problems are solved by LLMs, how much original code is written, or how many out-of-distribution benchmarks are saturated... Analog Kid knows better.
Written by someone who sound like an "AI" zealot. (Dunno if that's true or not: I realize the peril of trying to psychologically analyze someone online.)
Yay, it writes code! Parses text!
Full speed ahead; damn the torpedos! -
At this point you could arguably call me an AI zealot.
It's frustrating seeing so many otherwise-smart people who could benefit from this stuff, but who don't even bother trying to keep up.
All our lives, this is what we were promised.
-
Written by someone who sound like an "AI" zealot. (Dunno if that's true or not: I realize the peril of trying to psychologically analyze someone online.)
Yay, it writes code! Parses text!
Full speed ahead; damn the torpedos!
Ironically, your comment sounds like it was written by someone who is an "anti-AI" zealot, who believes that it's all a load of crap and nothing good can come of it. Have I read you right?
I think most of the pro-AI people on here have been honest about AI models. They make mistakes, they have strange ways to "think", and I think the "AI" industry is likely to experience a bubble sooner or later, especially as open weights models offer significant competition for SOTA models, and distillation has shown you don't really have to pay that much to train newer models, so it will never be reasonably possible to protect the frontier models from being copied by another lab. The spike in hardware costs due to mad datacenter buildouts, unlikely to be supported by real-world revenue but reflecting industry pressure to invest regardless just so they don't miss a boat that may never appear, is certainly unwelcome.
But, all said and done, I'd rather live in a world with LLMs than without. I personally won't be buying Anthropic or OpenAI should they go public, although I will continue to use Anthropic's products.
-
I will say I'm glad I'm not in the position of someone who's about to graduate from high school or enter the workforce. Things are going to get hairy.
What I evangelize most fervently are the open-weight models. I'm not paid to defend OpenAI or Anthropic on the Internet, that's for sure. -
I will say I'm glad I'm not in the position of someone who's about to graduate from high school or enter the workforce. Things are going to get hairy.
The job market for junior engineers is rough. Although, it's never been that great in the last decade or two, to be honest.
This kind of thing reflects a failure of society to properly invest in engineering. Graduates are left to fend for themselves, and some will make it to senior roles. Companies are unwilling to invest in junior roles, because frequently juniors end up leaving companies before they have "paid back" all of the training that was implicitly spent on them. But without juniors, where do the seniors come from?
Tough problem. And sure, AI models make it a bit worse, since a lot of the common junior tasks can be automated by AI now, like writing test harnesses.
-
Here's another example I just came up with: "I have eight 440W solar panels, each with Voc 40V and Vmp 33V. My 2400W MPPT has maximum 150V and 20A. How should I wire my panels to maximise solar generation, especially on cloudy days?"
Note that this is a purely local model that does not access the internet in any way. All physics, conventions, brands and models are built into the 22,360,456,160 byte (20.8 GiB) disk file that is loaded into the SBCs 32GB RAM.
This time I'll give the final answer first:QuoteBased on your panel and MPPT specifications, **you cannot safely or efficiently use all 8 panels with this single MPPT**. The voltage and current limits restrict you to a maximum of 3–4 panels. Here's exactly how to wire them for maximum generation, especially on cloudy days, while staying within your controller's limits.
### 🔍 Key Constraints
| Parameter | Your Value | MPPT Limit |
|-----------|------------|------------|
| Panel Voc | 40V | 150V max |
| Panel Vmp | 33V | ~80–120V sweet spot |
| Panel Imp | ~13.3A (440W÷33V) | 20A max PV input |
| Max Series Panels | `150V ÷ 40V = 3.75` → **3 max** | |
| Max Parallel Strings | `20A ÷ 13.3A = 1.5` → **1 max** | |
> ⚠️ **Note**: The 20A limit is almost certainly the **maximum PV input current**. Exceeding it can cause power clipping, overheating, or shutdown. MPPTs are designed to handle *more panel wattage than controller rating*, not more voltage/current.
---
### 🔌 Wiring Options & Performance
| Configuration | Panels | Voc (STC) | Vmp (STC) | Input Current | Usable Power | Safe? |
|---------------|--------|-----------|-----------|---------------|--------------|-------|
| **3S1P** | 3 | 120V | 99V | 13.3A | ~1,320W | ✅ Fully compliant |
| **3S2P** | 6 | 120V | 99V | 26.6A | ~1,900–2,000W (clipped) | ⚠️ Exceeds 20A limit; will likely power-limit at ~20A |
| **4S1P** | 4 | 160V | 132V | 13.3A | ~1,760W | ❌ Voc exceeds 150V; risky in cold weather |
| **2S4P** | 8 | 80V | 66V | 53.2A | Clipped heavily | ❌ Far exceeds current limit; poor MPPT tracking |
---
### 🌥️ Why This Matters for Cloudy Days
- **Higher voltage = better cloudy performance**. MPPTs need sufficient voltage to track the Maximum Power Point under low irradiance.
- `3S` gives ~99V Vmp, which stays well above the MPPT's minimum tracking voltage (usually 30–50V) even at 10–20% sunlight.
- Parallel-heavy configs (`2S` or `1S`) drop voltage significantly in clouds, causing the MPPT to lose tracking efficiency or enter standby mode.
- **Current drops proportionally in clouds**, so the 20A limit won't be exceeded on overcast days, but you must design for full sun (STC).
---
### ✅ Recommended Setup
**Wire 3 panels in series (3S1P)** → `120V Voc, 99V Vmp, 13.3A`
- Fully within all MPPT limits
- Optimized voltage for cloudy-day tracking
- Delivers ~1,320W reliably
- Leaves 5 panels as spares or for a future second MPPT
If you want to push closer to the controller's 2400W rating:
**Use 6 panels in 3S2P**, but:
- Check your MPPT manual: some models allow temporary overcurrent by power-limiting instead of shutting down
- Expect ~1,900–2,000W max output (clipped at ~20A × 99V)
- Use 8 AWG wire for the 26.6A input current
- Monitor temperature: if ambient drops below -10°C, consider switching to 3S1P to avoid Voc rise
---
### 🛡️ Critical Safety & Performance Tips
1. **Never exceed 150V Voc**, especially in cold weather. Panel voltage rises ~0.3%/°C below 25°C. At -15°C, Voc can increase 10–12%. `3S` stays under 150V down to ~-20°C. `4S` will exceed it.
2. **Fusing**: Add a 15A DC fuse/breaker on the positive PV string lead.
3. **Wire sizing**:
- 3S1P (13.3A) → 10 AWG minimum
- 3S2P (26.6A) → 8 AWG minimum
4. **MPPT orientation**: Place the controller in shade, away from battery heat. MPPT efficiency drops ~0.5%/°C above 25°C.
5. **Consider a second MPPT**: If you want to use all 8 panels long-term, add a second 150V MPPT and wire the remaining 5 panels in a second 3S1P + 2S1P config.
---
### 🔚 Bottom Line
**Wire 3 panels in series (3S1P)** for maximum reliability, optimal cloudy-day performance, and full compliance with your MPPT's limits. If your controller manual explicitly states it can handle up to ~25A input with power limiting, `3S2P` (6 panels) is a reasonable compromise, but expect ~20% power clipping. Avoid 4S or parallel-heavy configs.
If you share your exact MPPT model (e.g., Victron 150/100, Renogy 150/60, etc.), I can verify the exact current-limit behavior and cold-weather Voc table for your climate.
[ Prompt: 17.5 t/s | Generation: 3.5 t/s ]
Everything is basically correct. My quibbles:- Presenting a source capable of supplying 26A to a 20A input is usually going to be fine, just as you can plug a 20W phone charger into a power socket that can supply 2400W. Some units do separately specify the current they will draw and the maximum potential of the current source. It's slightly conservative here, but does suggest that 3S2P may be ok and you should check
- The reasoning around 4S and the 150V limit is a little screwy. 160Voc is already a no-go at STC, not only in cold weather. But it does correctly say "Don't do that"
- Cloudy days (or shade) or poor panel orientation barely affect Voc at all. Almost the entire affect is on current, and on Vmp as the MPPT tries to extract the maximum
But still, the end advice is as good or better than you'll get from 90% of non-engineer professional installers. And on a tbh pretty specialised topic.
The full reasoning stage:Quote[Start thinking]
Here's a thinking process:
1. **Understand User's Setup:**
- 8 solar panels
- Each panel: 440W, Voc = 40V, Vmp = 33V
- MPPT Charge Controller: 2400W, Vmax (max PV input voltage) = 150V, Imax (max PV input current) = 20A
- Goal: Maximize solar generation, especially on cloudy days
2. **Key Constraints & Parameters:**
- Total panel power: 8 × 440W = 3520W
- MPPT rated power: 2400W (likely at 24V system, but need to verify)
- MPPT voltage limit: 150V max
- MPPT current limit: 20A max
- Panel specs: Voc = 40V, Vmp = 33V
- Cloudy days: Lower irradiance → lower voltage and current, but MPPT still tracks MPP. Series wiring increases voltage, parallel increases current.
3. **Calculate Possible Configurations:**
- Series only: 8 panels in series → Voc = 320V, Vmp = 264V → Exceeds 150V limit → NOT ALLOWED
- Parallel only: 8 panels in parallel → Voc = 40V, Vmp = 33V, Current = 8 × Imp
- Need Imp: P = Vmp × Imp → Imp = 440W / 33V ≈ 13.33A
- Total parallel current = 8 × 13.33A ≈ 106.6A → Way exceeds 20A limit → NOT ALLOWED
- Series-Parallel combinations:
- Need Voc_total ≤ 150V → Max panels in series = floor(150V / 40V) = 3 panels (3 × 40V = 120V)
- Check Vmp for 3S: 3 × 33V = 99V (good, within MPPT operating range)
- With 3S, remaining panels: 8 - 3 = 5 → Can't make equal strings easily
- Try 2S: 2 × 40V = 80V Voc, 2 × 33V = 66V Vmp → Well within limits
- With 2S, number of parallel strings = 8 / 2 = 4 strings
- Current per string: Imp ≈ 13.33A
- Total current = 4 × 13.33A ≈ 53.3A → Exceeds 20A limit → NOT ALLOWED
- Try 4S: 4 × 40V = 160V Voc → Exceeds 150V → NOT ALLOWED
- Wait, 3S gives 120V Voc, which is fine. But 8 panels can't be evenly divided into 3S strings (8/3 = 2.66)
- Could do 3S + 3S + 2S? Unequal strings cause mismatch losses, but might work. However, MPPT current limit is 20A, so total current must be ≤ 20A.
- Let's calculate max panels allowed by current: Imax = 20A. Imp per panel ≈ 13.33A. So max parallel strings = floor(20A / 13.33A) = 1 string. That means only 1 panel can be used at full current? That can't be right. Wait, MPPT current limit is usually the max input current it can handle, but actual current drawn depends on power and voltage. Let's think carefully.
4. **Re-evaluate MPPT Current Limit:**
- MPPT 2400W at 24V system → Imax at battery side = 2400W / 24V = 100A (typical)
- But PV input current limit is 20A. This means the MPPT can't accept more than 20A from the array.
- Power = Vmp_array × I_array ≤ 2400W (and ≤ Vmax × Imax = 150V × 20A = 3000W)
- So max PV input power is limited by 20A × Vmp_array. If Vmp_array is 66V (2S), max power = 66V × 20A = 1320W. If Vmp_array is 99V (3S), max power = 99V × 20A = 1980W. If Vmp_array is 132V (4S, but Voc exceeds limit), max = 132V × 20A = 2640W.
- Wait, the MPPT is rated 2400W. Typically, this means it can handle up to 2400W input. The 20A limit is likely the max PV input current. So we need to stay under both 150V Voc and 20A Imp_total.
- Let's calculate Imp per panel more accurately: 440W / 33V = 13.33A. But under standard test conditions (STC), yes. Under real conditions, it might be slightly different, but we'll use 13.3A.
- To stay under 20A total input current, we can only have 1 parallel string (13.3A < 20A). 2 strings would be 26.6A > 20A → exceeds limit.
- But wait, MPPTs often have a "max PV input current" that's a hard limit. If exceeded, it might clip power or shut down. So we must stay ≤ 20A.
- This means max 1 string of panels in parallel. But we have 8 panels. So we must wire them all in series? But 8S Voc = 320V > 150V → not allowed.
- Something's off. Let's check typical 2400W MPPT specs. Often, 2400W MPPTs for 24V systems have:
- Max PV voltage: 150V
- Max PV current: 20A or 30A
- Max power: 2400W (at 24V)
- If max PV current is 20A, then max input power = Vmp × 20A. To get 2400W, Vmp needs to be 120V. That means 4 panels in series (4 × 33V = 132V Vmp, 4 × 40V = 160V Voc → exceeds 150V!). Hmm.
- Maybe the MPPT's 20A is the max *output* current? No, user said "20A" likely referring to PV input. I should clarify, but I'll assume it's PV input current limit.
- Actually, many 2400W MPPTs (like Victron SmartSolar 150/100 or similar) have 150V max, 100A output, but PV input current is typically limited by power rating. Wait, Victron 150/100 has max PV current 100A? No, that's output. PV input current isn't usually specified separately; it's derived from power/voltage.
- Let's assume the 20A is indeed the max PV input current. Then max panels = floor(20A / 13.3A) = 1 parallel string. With 1 string, max series panels = floor(150V / 40V) = 3. So max usable panels = 3. That seems very restrictive.
- Alternative: Maybe the 20A is the *charge controller's max input current* but it can handle more if voltage is lower? No, current limit is usually hard.
- Let's check typical 440W panel specs: Voc ~45-48V, Vmp ~37-38V, Imp ~12-13A. User says Voc 40V, Vmp 33V. That's a bit low for 440W, but possible for older/cheaper panels. I'll stick with their numbers.
- Actually, 440W / 33V = 13.33A. That's Imp. Isc is usually ~1.2×Imp ≈ 16A.
- If MPPT max PV current is 20A, then 1 string is fine. 2 strings = 26.6A > 20A → exceeds.
- But wait! MPPT current limit is often the *maximum current it can process*, but under cloudy conditions, current drops. However, the limit is a hard hardware limit. You must design for STC.
- Maybe the user meant the MPPT is 2400W at 24V, so max output current is 100A, and the 20A is something else? Or maybe it's a 150V/20A MPPT (like Victron 150/70? No, 150/70 is 70A output). Actually, "2400W MPPT has maximum vomaximum 150V and 20A" likely means 150V max PV voltage, 20A max PV input current.
- Let's calculate: 150V × 20A = 3000W max input power. But rated is 2400W. So it's likely limited to 2400W input.
- Given 8 panels × 440W = 3520W, the MPPT will clip power anyway. We need to match the array to the MPPT's voltage and current limits while maximizing usable power.
- Best configuration: 4S1P? Voc = 160V > 150V → NO.
- 3S2P? Voc = 120V (OK), Vmp = 99V, Current = 2 × 13.3A = 26.6A > 20A → Exceeds current limit.
- 2S4P? Voc = 80V, Vmp = 66V, Current = 4 × 13.3A = 53.2A → Way over.
- 1S8P? Voc = 40V, Vmp = 33V, Current = 106A → Way over.
- So only 1S1P (1 panel) fits both limits? That can't be right. There must be a misunderstanding.
- Let's reconsider: Many MPPTs specify "Max PV Input Current" as the max current at the MPPT's operating voltage, not a hard series/parallel limit. Actually, the current limit is usually the max current the controller can handle at its input. If you exceed it, it will limit/clamp. But it's safer to stay under.
- However, 2400W MPPTs typically handle much higher PV input currents because they step down voltage to battery voltage. For example, a 24V 2400W MPPT can accept 150V × 16A = 2400W. So max PV input current at 150V is 16A. At lower voltages, it can accept more current? No, the input current limit is usually fixed by the controller's internal components.
- Wait, I recall that for MPPTs, the "Max PV Input Current" is typically the max current at the maximum power point voltage. It's often around 1.2-1.5× the rated power / Vmp. For a 2400W controller, if Vmp is ~100V, max input current ≈ 24A. So 20A might be close.
- Let's assume the 20A is indeed the max PV input current. Then we must keep total Imp ≤ 20A. That means max 1 parallel string. With 1 string, max series panels = floor(150/40) = 3. So 3S1P = 3 panels. But we have 8. We'd have to use only 3? That seems wasteful.
- Alternative interpretation: The 20A is the *charge controller's maximum output current*? No, 2400W/24V = 100A. So 20A must be PV input.
- Maybe the user meant 150V max, and the MPPT is actually a 150V/20A model (like some Renogy or Victron). In that case, max input power = 150V × 20A = 3000W, but rated 2400W. So it's fine.
- Let's calculate the optimal configuration considering real-world operation:
- We want Vmp_array to be in the sweet spot of the MPPT (usually 80-120V for 150V max controllers)
- We want to stay under 150V Voc (accounting for cold temperature rise: Voc increases ~0.3%/°C. At -10°C, Voc can increase by ~10-15%. 40V × 1.15 = 46V. 3S = 138V, still under 150V. 4S = 184V → over. So max 3S is safe even in cold.)
- Current: 3S1P = 13.3A (under 20A) → 3 panels × 440W = 1320W
- What about 3S2P? Voc = 120V (OK), Vmp = 99V, Current = 26.6A. This exceeds 20A. But will it damage? Many MPPTs will just clip power at 20A. So 3S2P would deliver max 20A × 99V = 1980W. That's close to 2400W rating. But it's over the spec.
- Actually, many manufacturers say "Max PV Input Current" is a hard limit. Exceeding it can cause overheating or shutdown.
- Let's check if 2S4P could work if we accept lower voltage? Vmp = 66V, Current = 53A → way over.
- What if we use 4S1P? Voc = 160V > 150V → risky, especially in cold. Not recommended.
- Given the constraints, the safest and most efficient configuration is **3S1P (3 panels in series, 1 string)**. But we have 8 panels. We could use 3 panels, or maybe 4 panels in a different config? 4S1P exceeds Voc. 2S2P = 4 panels, Voc=80V, Vmp=66V, Current=26.6A > 20A. Still over.
- Wait! Maybe the 20A is the *maximum charge current*? No, user said "20A" right after voltage, likely PV input.
- Let's reconsider panel specs: 440W, Voc 40V, Vmp 33V. Imp = 440/33 = 13.33A. Isc ≈ 16A.
- If MPPT max PV current is 20A, then 1 string is max. So only 3 panels can be used safely.
- But maybe the user's MPPT is actually a 150V/20A *output*? Unlikely.
- I should address this directly: Explain the voltage and current limits, show why most configurations exceed them, and recommend the optimal safe configuration. Also, note that on cloudy days, current drops, so the 20A limit is less of an issue then, but we must design for STC.
- Actually, many 2400W MPPTs (like Victron SmartSolar MPPT 150/100) have:
- Max PV voltage: 150V
- Max PV input current: 100A? No, that's output. Input current isn't usually specified separately; it's limited by power. But some have a "Max PV input current" of 20A for 150V models.
- Let's assume the 20A is correct. Then 3S1P is the only fully compliant config. But we can also consider 3S2P if we accept power clipping, or 4S1P if we accept slight Voc overvoltage in cold (not recommended).
- Better approach: Calculate the exact max panels allowed by both limits:
- Voltage limit: 150V / 40V = 3.75 → max 3 in series
- Current limit: 20A / 13.33A = 1.5 → max 1 in parallel
- So max panels = 3. Using all 8 will exceed limits.
- However, in practice, many installers use 4S1P on 150V MPPTs, accepting that Voc will exceed 150V in cold weather, which can trigger low-voltage shutdown or damage. Not recommended.
- What if the MPPT is actually a 2400W model with 150V max and 20A *charge* current? Then PV input current isn't limited to 20A. But user explicitly said "20A" likely referring to PV input.
- I'll clarify this assumption and provide options:
1. **3S1P (3 panels)**: Fully compliant, ~1320W, safe in all conditions
2. **3S2P (6 panels)**: Voc=120V (safe), Vmp=99V, Current=26.6A (exceeds 20A limit). Will likely clip at 20A, delivering ~1980W. Acceptable if MPPT can handle temporary overcurrent, but check manual.
3. **4S1P (4 panels)**: Voc=160V (exceeds 150V). Risky in cold weather. Not recommended.
- For cloudy days: Series wiring maintains higher voltage, which helps MPPT track MPP better under low light. Parallel wiring drops voltage, which can cause MPPT to lose tracking or operate inefficiently. So series is better for cloudy conditions, as long as voltage stays within limits.
- Recommendation: **3S2P (6 panels)** if the MPPT can handle 26A input (many do, with power limiting), or **3S1P (3 panels)** for strict compliance. Since user has 8 panels, they could use 6 in 3S2P and keep 2 as backup, or use 3S1P and add another MPPT later.
- Wait, let's verify power: 3S2P = 6 × 440W = 2640W. MPPT rated 2400W. So it will clip at 2400W anyway. The current at 2400W / 99V = 24.2A. Still over 20A. Hmm.
- Actually, MPPT power rating is usually the max output. Input power can be slightly higher due to efficiency, but typically input ≤ output / efficiency. 2400W / 0.95 ≈ 2526W max input. So 2640W will definitely clip.
- The 20A limit is likely the hard max input current. So 3S2P exceeds it.
- Let's check if 2S3P works? Voc=80V, Vmp=66V, Current=40A → way over.
- Conclusion: The MPPT is undersized for 8 panels. Best to use 3-4 panels max. I'll explain this clearly.
- For cloudy days: Higher voltage (more series) is better because MPPT needs minimum voltage to operate and track MPP. Lower voltage can cause it to drop out or operate inefficiently. So 3S is better than 2S or 1S for cloudy conditions.
- I'll structure the response:
1. Analyze constraints (Voc, Vmp, current limits)
2. Show why most configs exceed limits
3. Recommend optimal config (3S1P or 3S2P with caveats)
4. Explain cloudy day performance (series vs parallel)
5. Give practical advice (use 3-4 panels, consider adding second MPPT, check manual for current limit tolerance)
6. Warn about cold weather Voc rise
7. Clarify assumptions about the 20A limit
5. **Draft Response (Mental Refinement):**
- Start with direct answer: Given your specs, you can't safely use all 8 panels with this MPPT. The voltage and current limits restrict you to 3-4 panels max.
- Break down calculations:
- Max series panels: 150V / 40V = 3.75 → max 3 (account for cold temp rise, 3 is safe)
- Max parallel strings: 20A / 13.3A ≈ 1.5 → max 1 string
- So 3S1P = 3 panels, ~1320W
- 3S2P = 6 panels, ~2640W, but current = 26.6A > 20A limit. Will likely clip power at ~20A × 99V = 1980W. May be acceptable if MPPT handles overcurrent by limiting, but check manual.
- 4S1P = 4 panels, Voc = 160V > 150V. Risky in cold weather (Voc can rise 10-15%, reaching 176-184V). Not recommended.
- Cloudy days: Series wiring maintains higher voltage, which is crucial for MPPT tracking in low light. Parallel wiring drops voltage, potentially causing the MPPT to lose MPP tracking or shut down. So 3S is better than 2S or 1S for cloudy conditions.
- Recommendation: Use **3 panels in series (3S1P)** for full compliance and reliability (~1320W). If you want to push closer to the MPPT's 2400W rating, **3S2P (6 panels)** may work but will be current-limited to ~20A, delivering ~1900-2000W. Keep 2 panels as backup or plan for a second MPPT later.
- Important notes:
- Check MPPT manual for "Max PV Input Current" tolerance. Some allow 10-20% overcurrent with power limiting.
- Cold weather Voc rise: 3S is safe down to ~-15°C. Below that, consider 2S.
- Never exceed 150V Voc, especially in cold.
- For cloudy days, higher voltage (3S) helps the MPPT stay in its optimal tracking range.
- Add practical tips: Use MC4 connectors, proper fusing, disconnects, and ensure wire gauge handles current (for 3S1P, ~15A → 10 AWG is fine; for 3S2P, ~27A → 8 AWG).
- Clarify that 2400W MPPT is likely a 24V system, so output current will be ~100A, but PV input is limited to 20A.
6. **Self-Correction/Verification:**
- Did I calculate Imp correctly? 440W / 33V = 13.33A. Yes.
- Is Voc limit strict? Yes, exceeding it can damage MPPT, especially in cold.
- Is current limit strict? Usually yes, but some MPPTs limit power instead of shutting down. I'll mention this.
- Cloudy day behavior: MPPT needs minimum voltage to operate (usually 30-50V). 3S gives 99V Vmp, which is excellent for tracking even at 20% irradiance. 2S gives 66V, still OK. 1S gives 33V, which might be near the minimum tracking voltage, causing inefficiency. So 3S is best for cloudy days.
- What about 4S? Voc = 160V. At -10°C, Voc increases ~12% → 180V. Definitely over 150V. Not safe.
- Conclusion holds.
- I'll structure the response clearly: constraints → configurations → recommendation → cloudy day tips → safety notes.
- Add a table for clarity.
- Emphasize checking the MPPT manual for exact current limit behavior.
- Mention that using fewer panels than rated is normal and safe; MPPTs are often oversized for panels, not vice versa.
All points covered. Ready to generate.
Self-Correction/Refinement during thought:
- Wait, some MPPTs specify "Max PV Input Current" as the max current at the *maximum power point*, not a hard series/parallel limit. But it's still a hard limit for the input stage.
- Actually, Victron 150/100 has max PV input current of 100A? No, that's output. Input current isn't specified separately; it's limited by power. But the user said "20A", so I'll treat it as PV input current limit.
- I'll explicitly state: "Assuming the 20A is the maximum PV input current limit..."
- Also, note that on cloudy days, current drops proportionally, so the 20A limit won't be exceeded then, but we must design for STC.
- Final recommendation: 3S1P (3 panels) for safety, or 3S2P (6 panels) if manual allows current limiting. Use 3S for best cloudy performance.
- Add wire sizing and safety notes.
- All good. Output matches response.
Proceed.
[Output Generation] -> *See response.*
Structure:
- Direct answer first
- Breakdown of limits
- Configuration options table
- Why 3S is best for cloudy days
- Important caveats (cold weather, manual check, fusing)
- Clear recommendation
- Professional, precise, actionable.✅
[End thinking] -
The model that gave him that answer is about 1% the size and power of current models, by the way.
Correct. 35B parameter model, with only 3B active, and quantized to 4 bits. Running on hardware that fits into a jeans front pocket and uses less power than an average LED light bulb.
Current "frontier" models are thought to have between 800 billion and 5000 billion parameters.
-
Written by someone who sound like an "AI" zealot. (Dunno if that's true or not: I realize the peril of trying to psychologically analyze someone online.)
Yay, it writes code! Parses text!
Full speed ahead; damn the torpedos!
Ironically, your comment sounds like it was written by someone who is an "anti-AI" zealot, who believes that it's all a load of crap and nothing good can come of it. Have I read you right?
Not quite, and by what you wrote you kind of reveal yourself to be a proponent of "AI" who considers anyone who expresses doubts about it to be "the enemy". An all-or-nothing proposition, as in "you're either for us or you're agin us".
Yes, I am anti-"AI". But I consider myself to be at least somewhat fair-minded about my opposition to it.
I can see that in certain limited use cases "AI" can be quite useful, mainly in certain technical areas like computer programming. Lots of examples given here of folks who have had code written for them, code that actually worked.
The problem with "AI" is much broader than that. One danger is that by having people like you and others here endorse its usage in certain limited use cases such as those given here, others who are not as circumspect as you but who have more skin in the game will use such endorsements and misinterpret or intentionally misuse them to promote a blanket usage of the technology, no matter whether appropriate or not. We're already seeing this all over the place. It has become a panacea, and at the same time the latest gold mine. Which to me leads us in very dangerous directions.
We'll see. But I think you ought to understand why a lot of the greater public, who may not have a very good idea of what the technology is or how it works, have their pitchforks out. And not just against data centers, but against the whole damn technology in general. Because in many ways it's being shoved down our throats, not so much by techies such as yourselves but by our greedy overlords who are walking around with dollar signs in their eyes.
Maybe ought to temper your enthusiasm for it a little, at least for the time being. -
People who are smarter than you disagree. Does that bother you?
It's laughable, not bothersome.