classic resetting during day

[dbcollen]

My classic 250 is resetting during the day, it did it multiple times yesterday, Ryan you can you look at my data https://www.mymidnite.com/?q=user/121 and see the kwh reset in the afternoon. The classic runs diversion, waste not high, -.2v width 3  and when it resets it never makes it to float. my batteries are staying in bulk/abs for well over 4 hrs/day instead of the 2 hrs that I have them set at. They are using lots of water with the long abs time. the classic has the latest prod firmware in it.

Thanks

Dustin.

[boB]

Dustin, the Classic is resetting while in absorb ??

What is the battery voltage, input voltage and approximate output power or current when it is in absorb and resetting ??

boB

PS   approximate values are fine...

[boB]

Dustin, can you please email Ryan on this.

We would like to try and get this unit to try and replicate your reset reset reset restttttting problem.

Thanks !

boB

[dbcollen]

boB,

All the data you requested is on mymidnite, 9-12 (which is actually 9-11 data) is a good example, it reset 4 times that day. power from that array is usually around 550w it seems to reset randomly I don't see any pattern.

[boB]

boB,

All the data you requested is on mymidnite, 9-12 (which is actually 9-11 data) is a good example, it reset 4 times that day. power from that array is usually around 550w it seems to reset randomly I don't see any pattern.

yes, Ryan showed me the graph.  I think he has been in contact with you about possibly swapping
that one out.  It might help us to figure your problem out as we have a hard time re-creating
this problem here.

Thanks !
boB

[RossW]

  It might help us to figure your problem out as we have a hard time re-creating
this problem here.

Bob, you will recall I was having identical problems.
Mine have stopped. Completely. Totally.

The network connections, equipment, data polling, firmware etc are unchanged.
There are two other things that HAVE changed however.

1. The size of the array I have connected (down from 3.6KW to 500W)
2. The work-around for the controller failure. You will recall we removed R57 (?)
    AND (perhaps more importantly) set it back to old legacy mode.

Have you had anyone else with these odd during-the-day resets try legacy mode and see if the problems go away?

If nothing else, it may point to where in the code the issue might be lurking??

(PS: we really must get back to fixing my classic, the days are getting longer, it'll be nice to have the unit functioning properly again)

[boB]

  It might help us to figure your problem out as we have a hard time re-creating
this problem here.

Bob, you will recall I was having identical problems.
Mine have stopped. Completely. Totally.

The network connections, equipment, data polling, firmware etc are unchanged.
There are two other things that HAVE changed however.

1. The size of the array I have connected (down from 3.6KW to 500W)
2. The work-around for the controller failure. You will recall we removed R57 (?)
    AND (perhaps more importantly) set it back to old legacy mode.

Have you had anyone else with these odd during-the-day resets try legacy mode and see if the problems go away?

If nothing else, it may point to where in the code the issue might be lurking??

(PS: we really must get back to fixing my classic, the days are getting longer, it'll be nice to have the unit functioning properly again)

Right !  Lower power and slower sweep.  Less surging.   This is why I want to look closer at the Aux supply.

Maybe if I have you just clip out some more parts !      Actually, sometimes that is the solution.

OK, so, your R57 problem though is because there is a bad circuit on your power board so we will
have to work on that.  I will work with Ryan and Mat and see what the best way is that
we can get that going.   Board replacement or something since you are on the underside of
the planet.

boB

[RossW]

Right !  Lower power and slower sweep.  Less surging.   This is why I want to look closer at the Aux supply.

So you're thinking it's in effect a POR or (if the classic processor board has it) brownout detection?
But since the battery volts are not dropping, it can't be that... and I'd expect the problem to be far worse with only 500 watts of PV compared to 3600.

I guess what was in my mind was seeing if simply changing to "legacy mode" on another similarly affected system made the problem "go away", if that might help narrow down the possible cause.

OK, so, your R57 problem though is because there is a bad circuit on your power board so we will
have to work on that.  I will work with Ryan and Mat and see what the best way is that
we can get that going.   Board replacement or something since you are on the underside of
the planet.

That'd be great.

[TomW]

I had to jump in on  this discussion. I have wondered (and maybe mentioned in IRC) that I thought it might be power throughput related.

When I had them they seemed to only occur at high power times and seemed to involve the Local App running at same time? "High Power" being about 1500 watts into 24 nominal volts max on Solar and perhaps 2 KW Max on the Wind but very rare.

I still see communication lockups requiring a reboot also apparently during high power throughput? Perhaps something involved with that is causing loss of power to other areas of the circuitry? Assuming (yeah I know what that does) there is a common power buss for internal circuitry from the battery perhaps high current flows disrupt the smooth DC they expect and perhaps require?

I really should keep notes on these things as I tend to reset to get things running again and forget the details. Luckily, or by design, the Classic keeps on chugging away doing what it is ultimately supposed to do.

I am doing some unusual things like accessing registers with Ross' script from a Pi before and a Linksys Slug now after the Raspbian OS ARM PI seemed to be part of the comms lockups.  Still seeing some comms lockups on the Ubuntu OS ARM Slug but not once using an Ubuntu OS X86 laptop awhile before trying the Slug. Maybe the ARM processor's ethernet handling is the issue with the PI and Slug? I tend to be a lightning rod for odd equipment behavior. A jinx if you will. I digress.

I see 2 distinct but separate symptoms here with what appears to be a common cause? I would be looking at areas of the system that are common to communications and tracking the KWH? But I haven't done any serious troubleshooting in a decade plus.

Just some observations and opinion on this issue.

Tom

[dbcollen]

mine is in legacy mode, since I took out half the array and now the Imp is below batt volts. it now sweeps to about 1v below batt volts (boost) and locks in there.

[zoneblue]

I still see communication lockups requiring a reboot also apparently during high power throughput?
... Still seeing some comms lockups on the Ubuntu OS ARM Slug but not once using an Ubuntu OS X86 laptop awhile before trying the Slug. Maybe the ARM processor's ethernet handling is the issue with the PI and Slug?

I dont know if ross mentioned it, but i figured out that the comms problem is directly related to cpu load. If can you get rid of all the unnecessary loads on the arm board, the problem goes away. I think what happens is that newmodbus is forced to run so slowly by a congested system that the classic locks the connection up somehow. I want to say this is a bug in the classic, but it can be avoided by keeping the load average down. Take a look at uptime see what it says. These arm boards only draw 1W, which means trying to run full blown linux on them is actually a fairly big ask.

Also can you describe your exact setup. How much cable do you run betw the classic and the rPi? what happens after newmodbus, post processing etc? xserver anything like will be a problem.

[TomW]

I dont know if ross mentioned it, but i figured out that the comms problem is directly related to cpu load. If can you get rid of all the unnecessary loads on the arm board, the problem goes away. I think what happens is that newmodbus is forced to run so slowly by a congested system that the classic locks the connection up somehow. I want to say this is a bug in the classic, but it can be avoided by keeping the load average down. Take a look at uptime see what it says. These arm boards only draw 1W, which means trying to run full blown linux on them is actually a fairly big ask.

Also can you describe your exact setup. How much cable do you run betw the classic and the rPi? what happens after newmodbus, post processing etc? xserver anything like will be a problem.

Blue;

Yes, Ross mentioned this but it is definitely NOT what I am seeing.

I tried it on an otherwise "unoccupied" Pi and it happened anyway. I have tried so many things it is not even remotely amusing.

No long runs of Cat5, there is a switch in the network. The Pi was "closer" than the laptop that had no problems.

I am still semi convinced the Classic is the choke point for several reported issues. Particularly the lockups and this arse pain of resets. I am leaning towards power starvation on circuits but without even a block diagram to go from there is no way I can say for sure from here. Chasing incompatible routers, long cables or other odd "maybes" just sidesteps  some basic flaw that manifests itself in several ways and is probably related to multiple problems? Or not.

I just have about given up on communicating with the Classic locally which is the main reason I (and others) want the Classic in the first place.  Cutesie pages on the internet is all well and good for folks that travel away from home a lot but not for us here.

I am not going to start using Windows so I can run a supported version of Adobe AIR or buy more hardware so I can monitor the Classic without using the internet and mymidnite which is not exactly rock solid on reliability for me, either.

Anyway, it is late Saturday night / early Sunday Morning  so if this makes no sense I blame that.

Just from here, now.

Tom

[Halfcrazy]

Tom there is a really nice block diagram or more of a schematic for the classic. I will see if I can dig it up and post it. So on your units has the resetting gone away with the newer firmware and you are having communications issues?

I think most likely what we need is a list of issues and we will stop everything and put lots of brain power on this and see what we can do. There was a change to the aux power supply a ways back maybe 2-3000 serial that was supposed to help with idle draw some. Let me see if I have an old one here and "IF" I can update it and I will send it to you Tom and see if it acts better?


Ryan

[TomW]

Ryan;

My units are SN 1871 on solar (which seems to be the one with the majority of communication lockouts) and 7805 on wind both 150's both with an MNGP.

I think my resets have gone away, at least I have not caught  one since I changed routers. There were FW updates at the same time so "what" made them appear to cease is a hard call.

My communications lockups are still there occasionally.They seem to be rPi related but I had seen them when no rPi was in the loop. Several FW revisions have occurred and I did not keep notes. And now that I decided to document better I haven't seen one. ;=<>

Ross can probably extract the times they occurred from our logs. So far his only access to an rPi has been via ssh to one of my units.

Did I ever mention I am a jinx on electronics?

If stuff can survive use by me then it is probably pretty bullet proof!

Ok, on to specifics.

If it either resets or locks up on communications happen what data should I write down before I use the old geek universal fix of power cycling? I believe the MNGP is still responding at those times so I can get some info that way.

Be nice to actually pin this down to one device.

I am not completely dedicated to the rPi but it is what I have for low power computing. If it is a hardware incompatibility with certain peripheral gear then the fix is "don't use that gear" so if the rPi is a bad choice I can move on. Ross had some interesting details on what happened when these communication issues came up and they implied the rPi was tossing a chksum error on the data as near as I can recall. Others seem to be using the rPi with no issues so that kind of made me think it was not the rPi?

I can do whatever is needed to help sort this out. I go slow but usually in a forward direction.

Its Sunday, shouldn't you be playing with the kids? 

Tom

[Halfcrazy]

Ok so it sort of sounds like it is the other way around from what I had in mind. The older one is the misfit. Hm I assume you are gathering info on the Pi over TCP/IP not serial right? Maybe an idiots guide on how to run that software here on my Pi may be in the works?

Ryan