The number of resets and timing of the resets are configurable. The current implementation is on a per module basis but I'm considering the possibility of per port as well. On May 10, 2015 5:13 PM, "George Skorup (Cyber Broadcasting)" < [email protected]> wrote:
> Awesome. Not sure if my three reset attempts idea makes sense. I'm just > worried about something like a SS blowing and the PDU sitting there > resetting the port(s) endlessly. I imagine that's probably not good for the > electronic breaker thingamajig. > > What I have observed with the WB SS's is a nearby lightning strike will > set them off and the fuse blows. Replace the fuse and everything is usually > good to go again. If feel better that the SS did something and probably > saved the radio and/or router/switch port from taking a surge. OTOH, I have > seen them actually blow completely (saving the gear most of the time) and > obviously the fuse pops. Get to the site and replace the fuse only to have > it pop again. That's when I know something else is wrong. :( > > On 5/10/2015 5:01 PM, Forrest Christian (List Account) wrote: > > All of the modules which have overcurrent trip are going to get this > functionality. > > Timing: > > The base unit firmware is getting a (hopefully) final release based on the > current code. This code is ready and just needs to be packaged for > release. This final release fixes a issue where the base unit Ethernet > locks up, causing a software deadlock followed by a watchdog reboot. The > trigger is bad packets being received, usually as a result of a duplex > mismatch. > > Once that is done, there will be a early adopter chain released for both > the base unit and expansion modules. There are added capabilities being > added to the system which makes the auto reset functionality much easier to > implement. For example, the expansion modules will be keeping track of the > length of time since the last change, which equates to the time since the > last trip. This information will be available via the web and via snmp. > The code we have written for this also includes the auto reset > functionality. This actually isn't that far out as most of it is done, we > just ended up needing to track down this other bug once we were able to > reproduce it in house, and then backport it to the current release without > all the new experimental stuff in it. > On May 10, 2015 12:53 PM, "George Skorup (Cyber Broadcasting)" < > [email protected]> wrote: > >> Question for Forrest. I know it was talked about in the past to have an >> auto-reset when a port goes into over-current trip for the SyncInjectors. >> What about the PDU module? >> >> I'm working on some stuff that's going to be far away, so the PDU in >> place of fuse blocks makes total sense, but it would be even more awesome >> if any tripped outputs could reset themselves after 5-10 seconds. Not sure >> if this is possible, but maybe like three reset attempts and it gives up >> would be pretty cool too. >> > >
