I think per module is good enough, but I wouldn't complain about having
a per port setting.
On 5/10/2015 7:46 PM, Forrest Christian (List Account) wrote:
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] <mailto:[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] <mailto:[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.
