...
Tom's documentation of the serial number/serial port relation for the medium spaced array 2, https://wiki.ucar.edu/x/OYWgAQ, agrees with the above serial port to serial number relation.
SteveO's entry for array4the narrow array, https://wiki.ucar.edu/x/W4CqAQ, also agrees with the above.
In setting up these arrays, care was presumably taken to get the cabling right, so that we're also confident of the mapping from serial port to location during those configurations.The archive will contain the results of the rserial sessions that were done to show the sonic serial numbers, and this can be used to confirm the sensor id to serial number mapping. These serial number messages, by sensor id will be available soon.
Possible Cross-cabling in Wide Array
In log entry https://wiki.ucar.edu/x/tBR_AQ, Tom used rserial to record the sonic serial numbers at each serial port for the wide array, and noted the following results:
...
The XML specifies what sensor id is assigned by the DSM to each sample received on a serial port. It is likely that the mapping of I believe the XML was checked at that time, and it contained the intended mapping from serial port to sensor id in the XML was correct, matching the intended configuration. Assuming so, it then seems . So at that time it appeared that the actual relation between sensor id and location on the wide array was as follows:
...
If the above relation of sensor id to location is was true, then our data processing, which used the intended configuration, assigned wrong location suffixes to the data from those sonics for the wide array.
...
First, the serial number to sensor id relation can be read from the data archive, since the rserial output is archived. Assuming Tom progressed through the serial ports in order, they show the serial number sequence to be 744, 745, 376, and not 745, 376, 744. The sensor ids are also in time order, 2040, 2050, 2060:
...
The serial number messages from the archive of the wide array are shown here, with their sample times:
date time UTC | sensor id | serial number |
2008 06 29 |
---|
...
22:30:34.0640 |
---|
...
2,2040 | SN0744 | |
---|---|---|
2008 06 29 22:33:09.7736 |
...
2,2050 | SN0745 | |
---|---|---|
2008 06 29 22:34:38.8956 |
...
2,2060 | SN0376 |
---|
Assuming Tom progressed through the serial ports in order, they show the serial number sequence to be 744, 745, 376, and not 745, 376, 744. The sensor ids are also in time order: 2040, 2050, 2060, and the mapping of sensor id to serial number matches the intended configuration, and not the crossed configuration.
Perhaps two mistakes were made which cancelled each other: cross-cabling, and making the wrong complement association between serial port and sensor id in the XML? Or perhaps the XML on the DSM was corrected to match the cabling shortly after the wide array started, and then corrected back for array2the medium spaced array? Both seem unlikely. The sequence of the above serial numbers suggest that neither of the above occurred, and that the serial ports were recorded incorrectly in Tom's log message.
I (Gordon) also do not believe that the The sensor ids were have not been altered in the archive after it was recorded, since the modification times of the files have been preserved and match the original recording times.
Steve Oncley also looked at data during dust devil events from these sonics during the wide array, and the spacial continuity of the relative wind directions indicate that the sonics were in the intended configuration.
...
The data is a bit noisy during the wide array, but it seems quite certain that the relation of serial number to sensor id did not change:
Serial Number vs Sensor ID History
For all sonics connected to downwind1, here is the serial number information in the archive:
date time UTC | sensor id | serial number | presumed location | notes |
2008 06 29 21:43:30.5690 | 2,2010 | SN0853 | 1b |
|
---|---|---|---|---|
2008 06 29 21:44:06.8606 | 2,2010 | SN0853 | 1b |
|
2008 06 29 21:49:02.5737 | 2,2020 | SN1117 | 2b |
|
2008 06 29 21:52:02.6381 | 2,2020 | SN1117 | 2b |
|
2008 06 29 21:53:49.3434 | 2,2030 | SN0800 | 3b |
|
2008 06 29 22:30:34.0640 | 2,2040 | SN0744 | 4b |
|
2008 06 29 22:33:09.7736 | 2,2050 | SN0745 | 5b |
|
2008 06 29 22:34:38.8956 | 2,2060 | SN0376 | 6b |
|
2008 06 29 22:36:25.1529 | 2,2010 | SN0853 | 1b |
|
2008 06 29 22:37:50.2269 | 2,2020 | SN1117 | 2b |
|
2008 06 29 22:38:16.8077 | 2,2030 | SN0800 | 3b |
|
2008 06 29 22:46:31.9746 | 2,3030 | SN0738 | 3t |
|
2008 06 29 22:48:33.8801 | 2,3040 | SN0856 | 4t |
|
2008 06 29 22:49:30.2804 | 2,3050 | SN0712 | 5t |
|
2008 06 29 22:50:11.3536 | 2,3060 | SN0672 | 6t |
|
|
|
|
|
|
2008 07 19 18:59:35.9615 | 2,2010 | SN0853 | 1b |
|
2008 07 19 19:01:06.9888 | 2,2030 | SN0800 | 3b |
|
2008 07 19 19:03:07.5053 | 2,2040 | SN0744 | 4b |
|
2008 07 19 19:04:48.1197 | 2,2050 | SN0745 | 5b |
|
2008 07 19 19:07:07.0574 | 2,3030 | SN0738 | 3t |
|
2008 07 19 19:09:16.3050 | 2,3030 | SN0738 | 3t |
|
2008 07 19 19:10:44.4320 | 2,3040 | SN0856 | 4t |
|
2008 07 19 19:11:40.2070 | 2,3050 | SN0712 | 5t |
|
2008 07 19 23:22:39.9607 | 2,2020 | SN0741 | 2b | sonic was replaced |
2008 07 21 16:49:07.5003 | 2,2060 | SN0376 | 6b |
|
2008 07 21 16:49:58.4540 | 2,3060 | SN0672 | 6t |
|
|
|
|
|
|
2008 08 11 22:56:47.7955 | 2,2010 | SN0853 | 1b |
|
2008 08 11 22:57:46.2450 | 2,2020 | SN0741 | 2b |
|
2008 08 11 22:58:11.5836 | 2,2030 | SN0800 | 3b |
|
2008 08 11 22:58:39.3355 | 2,2040 | SN0744 | 4b |
|
2008 08 11 22:59:02.7667 | 2,2050 | SN0745 | 5b |
|
2008 08 11 23:00:23.5102 | 2,2060 | SN0376 | 6b |
|
2008 08 11 23:00:47.0487 | 2,3030 | SN0738 | 3t |
|
2008 08 11 23:01:29.3204 | 2,3040 | SN0856 | 4t |
|
2008 08 11 23:02:29.9896 | 2,3060 | SN0672 | 6t |
|