PTB210 at s1 was working up until 2020-04-12,15:23:03, except of course for periods when s1 was probably dead. There are a few messages after that, until 202-04-16,01:29:11, and then they stop. As of the swap of the s9 DSM, nothing has been received from the PTB.
The PTB was set for 7E1, so I've tried connecting to it on s9 with minicom in 7E1, but there is still no response. Maybe a blown fuse, or maybe the PTB itself is dead. The data messages received in 7E1 mode are recoverable with some code changes to NIDAS.
When Leila swapped the s9 DSM for s1, I discovered the disdrometer messages were broken. The quick summary is that the eeprom got erased, leading to these questions. The details follow.
- Can we take up this problem with Ott Hydromet?
- Any clues as to what could be causing the Parsivel2 to lose it's memory?
- Is voltage or current supply borderline for reliable operation?
It looks like the first data file at setup for s1 is s1_20200325_120000.dat. Disdrometer was working as of 2020-03-25,17:49:13. I'm guessing the site was setup that day, and for whatever reason the disdrometer data messages start there, without the boot messages. Probably the time was not synchronized until then.
The messages appeared to be fine, including reporting the serial number 450620:
It booted up again 2020-03-26,01:35:11, for reasons unknown. It reported one good message, then started rebooting and reporting "POWERSUPPLY TEST FAILED !!!".
Eventually it starts repeating the messages "ERROR: No Valid Serial Number found !!!" and "ERROR: No Valid Hardware info found !!!".
It keeps reporting the "No Valid Hardware info" messages until 2020-03-27,01:50, then some noise, then nothing until 20:13, when it starts reporting the default messages with the serial number of XXXXXXXX:
There are still some reboot messages later on and more error messages, so it's not like the disdrometer is stabilized again but just missing eeprom. Either way it's in a broken state, and I don't think this is the only one to have had this kind of problem.
For the moment, I have modified the NIDAS config to parse the messages but skip the serial number field. However, that is not a fix since the whole configuration of the data messages has been lost, and we don't know if losing the hardware info and any other eeprom settings makes the data useless.
A week ago, Leila and Charles visited Site 1 to find the DSM inop. For simplicity sake, this past Sunday (4/26) I had them replace the S1 DSM with the unused S9 DSM. Nothing was swapped between the two, so S9 has it's original cell modem and SD card.
eth0- 192.168.1.209 (DSM address)
eth1- 184.108.40.206 (cell modem address)
Just a quick note that s8 has routinely seen winds >20 m/s, with the highest 5-min average of 27 m/s on 17 Mar.
s15 is the next windiest, up to 17 m/s, though I suspect that s17 would have been high as well if it were being recorded.
The pattern is not surprising, though the magnitudes are rather high for what ISFS normally sees.
It seems that the s8 CSAT sometimes misses these events – is this the high-wind-speed-error that Sean saw several years ago?
Still in idling mode after being pulled from set-up last month for COVID.
s1 - Barometer not reporting (configuration?). Station only comes up when batteries fully charged. (Had worked ok initially after setup.). Sometimes, files are not opened. Most of the time the time stamp is bad.
P.S. Site was visited by Leila and Charles on 18 Apr. They replaced batteries and Victron, which brought power up to DSM and sensors, but DSM still hasn't come up. This suggests either a fault or wrong setting (mode 4 instead of mode 3?) of the old Victron. Dan things the next step is a DSM change, but the DSM was swaged closed so the PIs couldn't get into the box. A DSM issue is odd, though, since it was working last week.
s3 - TRH died in rain on 6 Apr. Otherwise ok
s4 - ok
s8 - EC150 never installed. GPS not receiving most messages as of 14 Mar(!). (At that time, about 13 Mar 23:30 nsat drops from 10 to 7, then further drops to 0 about 14 Mar 02:30.) Otherwise ok
s10 - ok
s14 - Mote data never worked properly, last data on 3 Apr. Cable from DSM to mote found to have water during site visit by PIs on 11 Apr, but didn't have spare. Barometer highly intermittent (but Pirga ok). Otherwise, ok.
s15 - ok
s17 - Site pretty much never worked. Just a few hours of data early on. Last data 26 Mar. From log snapshot taken when station was last up, seemed to be a DSM USB issue.