THIS PAGE IS DEPRICATED!
Please see the new SEMS Project Page
Power
- What are the requirements for a full system?
- What is the failure mode when power is lost?
- The primary power source is a solar panel (SP20). The solar panel and wall power are used as input to a relay. The solar panel is also the control line of the relay. When the solar panel is producing power, the relay connects the solar panel to the charger/regulator (CH100). When the solar panel is not producing power, the relay connects wall power to the CH100. The CH100 charges a backup battery and powers the datalogger (CR1000) when it is receiving power. If both the solar panel and wall power are not supplying power, the CH100 uses the backup battery to power the CR1000. The backup battery should last at least over night. If the backup battery is fully drained, the CR1000 will no longer operate.
- Does the system fully recover when power is reconnected?
- Yes, I have tested this by switching off the CH100, effectively disconnecting all power input to the CR1000. Switching back on resumes operation.
- How will it link to the survival cell idea?
Maintenance/Reliability
-
How easy will it be to clean the sensors? They could be high up if on a
mast. Also on FTS we tend to suffer from particulates on the wetness
sensor meaning it needs cleaning every two months or so.
-
How robust is the campbell kit? For comparison, other than cleaning on
FTS there have been no failures on the vaisala system on FTN/S in about
11 years of combined operation.
- The equipment will be tested for reliability at Sedgwick (IZA).
Control
-
Will there be a hardwired "close" signal to cover the case of sofware errors / data corruption?
- The CR1000 supports programmable digital I/O that can be used as a hardwired signal. This will only be used when the software system has failed. If the CR1000 is dead, the software is unable to do its job, and the hardwired signal will show that it is not safe to open an enclosure.
-
On the data side, I dont know much about the pub/sub side of things,
but I would vote with all data passed back and made available to the
control system and let that make the open/close decisions. This may/not conflict with the hardwired close signal.
- SEMS will make open/close decisions and publish that data (possibly into the pub/sub environment). The idea is to keep open/close logic in one place so in the future we are not wondering what system made an errant decision to prevent the enclosure from opening based on its own internal thresholds.
- The SEMS software decision will not conflict with a hardwired signal. The state of the CR1000 digital I/O line can flow into the software, and the software will most likely want to respect that. But if the software is functioning, it is in control. The next question might be, "How does the enclosure system know the SEMS software is functioning?"
-
How will the loggernet software be integrated with the rest of the software?
- I am not clear on what this question is asking. The LoggerNet software really just makes the DataLogger data available inside the server, opening up more interfaces rather than interfacing directly with the CR1000. So the LoggerNet software is actually quite integral to the system.
-
What other software may be required, eg for trending. Even if it
something we end up writing then lets get it down on paper now rather
than being a bolt on afterwards.
- I have built a Django front-end on the SEMS database that simply makes the data available in a nice web production system. I have not looked into trending software, but I would hope there are existing packages to take advantage of. Since this is more of a "nice-to-have", I am pushing it to the back burner.
