This page is a cheat sheet for the DSMs deployed with ISS for Perdigao, but most of it is general information which applies to any DSM. Two of the sites have a DSM.
|SODAR||dsm-sodar||192.1681.206||GPS, WXT (RS232 on ttyUSB3), Lufft (RS485 on ttyUSB1)|
The user account on a DSM is 'daq', ask Gary for the password. So you can ssh to a DSM like so:
The DSM at the sounding site will be on the Ubiquiti tower network, so it can be reached from any host on that network. The SODAR DSM is connected to the Internet over a cell modem, so it can only be reached remotely through the SSH tunnel. To log into it directly, you have to be at the site and either on the TP-Link wifi or plugged into the ethernet switch in the DSM. Add the excerpt below to your ssh config file to use 'ssh dsm-sodar' to connect to it:
Checking DSM Data
There are a few ways to check on the WXT data, so I'll just give examples of all of them. For reference, the WXT is plugged into port 3 of the SODAR DSM, which is device /dev/ttyUSB3.
Monitor serial data directly with rserial
Use the 'rs' script to tap the serial stream directly through NIDAS. The rserial program will print the messages received from the WXT while nidas still keeps recording the data.
Run data_stats on the real-time stream
The DSM has a shortcut for the data_stats program called ds. By default the data_stats program connects to the real-time sample stream provided by the main dsm process, so it can be a convenient way to see which ports are receiving data and at what rates. It just keeps collecting samples until it is interrupted with Control-C. So it is not so useful with low-rate data, because you must wait until at least one sample should have been received to know if that sensor is working. You don't know if a one-minute sensor is sending messages unless you wait a full minute. If there is no line for a port in the output, then no samples were received on that port. If there is, then the line includes the dsm and sample ID, and those can be used to inspect the processed measurements with the data_dump command.
Show sample stats for the latest raw data file
NIDAS records the sensor data to a raw data file on the USB flash disk. While NIDAS is running, the disk is mounted on /media/usbdisk, and the data files are written to /media/usbdisk/projects/Perdigao/raw_data. So the command below uses the data_stats program to print sample statistics on all the sensors recorded in that data file:
The above shows that only the GPS messages are being received, at a rate of 2 Hz, with the most recent at 22:33. data_stats also gives the DSM and raw sample IDs for each sensor, so for the GPS messages the DSM ID is 5 and the sample ID is 10.
Dump individual messages
The data_dump program dumps individual messages from each sensor. Knowing the IDs given in data_stats, this command dumps all the WXT messages (ID 30) from the latest data file. Probably this would be piped into a pager like 'less':
data_dump can also be used to dump samples immediately, as they are received by NIDAS, by tapping into a default network sample stream provided by NIDAS. Since this is real-time, nothing will be shown until a sample is received, so you have to wait for a minute before knowing that a 1-minute sample stream is not working.
If you want to see all the sensors from data_dump, use '-i -1,-1', or data_dump -i '*,*', just remember to quote the asterisks.
Check that data files are recording
The lsu script to report the space available on the flash disk and also the last 10 data files. Run that script and check that the most recent data file corresponds to the current time.
Note this doesn't indicate whether all the sensors are being recorded, only that at least one sensor has been recorded to disk recently.
Check time synchronization
The DSM should get its time from the GPS messages, synchronized to the PPS signal. The chronyd program manages the system time and keeps it in sync with GPS. So there are a couple things to check: GPS messages are being recorded and GPS is locked, and that chrony is working and synchronized.
cs is an alias for 'chronyc sources'. Use 'cs -v' to dump an explanation of the fields along with the stats:
The asterisk in the PPS0 line is the most important, followed by the measured offset between GPS and system time inside the brackets. Typically it will be on the order of microseconds, as above where the offset is 1.21 microseconds.
rs G uses the rserial program to tap the GPS messages being recorded by NIDAS.
The important part is the 'A' in the GPRMC line, meaning the time in that sentence is 'valid', whereas V indicates invalid.
Checking the DSM Configuration
The DSM data acquisition is configured with a NIDAS XML file. The XML contains a node for the particular dsm, where the hostname of the dsm matches the name in the dsm element. For example, below is the SODAR dsm entry. It may not match exactly what's on the DSM, depending on when the DSM was last updated. Also, the XML configuration file on the DSM may only contain an excerpt of the full configuration file, whatever is necessary to run on just that DSM.
The outermost <site> element contains a single DSM, which will usually be the case for ISS deployments. The <dsm> element has name dsm-sodar, and that matches the hostname of the DSM assigned to the sodar site. Then there are three sensors specified to be recorded by this DSM: GPS, LUFFT, and WXT510. Each of those names is a reference to a more complete <sensor> definition elsewhere, either earlier in the XML file or in a separate XML file called sensor_catalog.xml. The elements above only specify the device to which the sensor is attached, and the sensor ID required by NIDAS to differentiate samples from different sensors. The device names /dev/ttyUSB1 and /dev/ttyUSB3 correspond to ports 1 and 3 on the Raspberry Pi DSMs. Search for the LUFFT sensor reference to find out the rest of the configuration, such as the expected baud rate and other settings for serial sensors.
ISFS Man Page
There is a man page, 'man isfs'. It lists these shortcuts and a few others. Usually it is possible to get more detailed usage information by running the command without any arguments or by passing the -h option.