| 39 | |
| 40 | |
| 41 | things one can detect.. maybe.. |
| 42 | - pulse stretching (return pulse longer than laser pulse |
| 43 | - slopes |
| 44 | - low vegetation (ie. may need to adjust "ground" peak downwards a little) |
| 45 | - indication of biomass by evaluating area under peak |
| 46 | - better vertical resolution/distinction of objects |
| 47 | |
| 48 | angle of laser may make a difference (flat ground at nadir is a slope at edge of fov, or cutting through vegetation) |
| 49 | |
| 50 | |
| 51 | |
| 52 | where did gain come from in waveform viewer |
| 53 | - volts= digitized value * gain + offset |
| 54 | - not agc gain, this is a fixed amplication on the waveform board |
| 55 | - value is 0.017290626 |
| 56 | - offset is also hardcoded, value is 0 |
| 57 | - system digitises from 0 to 4.something volts |
| 58 | - gives you volts as received at the waveform board, after AGC applied, etc - probably only useful for engineering team |
| 59 | |
| 60 | |
| 61 | ops changes: various.. relevantish ones to us are |
| 62 | - hardware is now licensed (ie. turns into a paperweight if expires) |
| 63 | - automatic bit mode at start and end of fcms session |
| 64 | - moving to ethernet comms rather than rs232 |
| 65 | |
| 66 | |
| 67 | * Nothing has changed for the AGC/mainboard of the ALS so the raw laser .SCN files will be the same as before. |
| 68 | * Extra files will be created that contain the waveform data. Waveform files (.LWV) will be in the raw_wfd directory, SCN files in the raw_laser directory. |
| 69 | * Waveform files have A or B in filename depending on which data board (A or B) acquired it. When processing both files are taken together. |
| 70 | * The digitiser starts recording from the first returned peak for the number of required samples (256/128 @ 1ns or 256/128/64 @ 2ns) |
| 71 | * If first return is noise (cloud/seagull) then the digitiser will start recording there and not at the target. |
| 72 | * measured heights / distances for different sampling rates: |
| 73 | |
| 74 | || Sample rate || equivalent height || |
| 75 | || 256 @ 1ns || 38.4m || |
| 76 | || 128 @ 1ns || 19.2m || |
| 77 | || 256 @ 2ns || 76.8m || |
| 78 | || 128 @ 2ns || 38.4m || |
| 79 | || 64 @ 2ns || 19.2m || |
| 80 | * the data rate is approximately 160GB/hr at full rate (256samples / 1ns). |
| 81 | * Benefits of full waveform |
| 82 | * Better idea of the nature of the return e.g. tree canopy height is more accurate than from 1 discrete point |
| 83 | * Extraction of points from the waveform missed by the discrete measuring |
| 84 | * (a future benefit) pulse stretching at swath edges compared to nadir: indicating sloped terrain, improved classification |
| 85 | * Maximum rate of acquiring digitised full waveform data is 120KHz. If a higher rate is used then the waveform data will record for every other emitted pulse. But the SCN files will still be recorded at the high rate. |
| 86 | * Pulse length (sampling rate) should be chosen based on the maximum height of targets in the area. E.G. if all low lying targets then there is no point using 256 samples at 1 ns - better to use 128 at 1 ns. |
| 87 | * No changes to the calibration flights except to collect FW data. Only change to the processing is to find the timing offset between FW and discrete points. |
| 88 | * Pre-trigger - like a buffer zone to record digitised samples before the first return. Default is 5m. |
| 89 | * Waveform and discrete data use different scalers for the intensity values and so will result in different intensities. |
| 90 | * AGC is constant for a pulse - so the same value is used for the entire waveform |
| 91 | * There is a slight delay between SCN files and waveform files being recorded (< 1 second). This may result in first few points not having waveform data. |
| 92 | |
| 93 | == Software == |
| 94 | |
| 95 | * ALSPP outputs in LAS 1.3 (type 4?) format which supports full waveform data (and also LAS 1.0) |
| 96 | * To output in LAS v1.0 you must also select "LAS file with time stamp" in output options else no files will be output |
| 97 | * ALSPP takes 10 times as long to process the data to produce a LAS file when using FWD |
| 98 | * Includes a simple waveform viewer |
| 99 | * Displays waveform and discrete points |
| 100 | * There is a "constant" timing offset between the waveform and discrete points - thought to be due to processing time. This should be removed at calibration |
| 101 | * In waveviewer "Ret point loc" is the discrete return time (from emit to receive) for the first return |
| 102 | * intensity is the value for each discrete return |
| 103 | * LASHistoViewer is useful for viewing stats of LAS file. Can also "drag and drop" Flightline_log into it to see info and stats together. |
| 104 | * New version of Terrascan capable of displaying full waveform data and "creating extra" points from the waveform |
| 105 | |
95 | | |
96 | | |
97 | | RCD changes |
98 | | - uses full CCD instead of cut down area |
99 | | - 7162x5389 -> 7212x5408, 7012x5208 after geometric enhancement |
100 | | - see presentation for depressing readout location on old setup |
101 | | - change to SSD |
102 | | - new workflow software |
103 | | - file renaming to flightline/project naming from fcms |
104 | | - distortion removal, shutter correction |
105 | | - DTM support, for displaying in workflow manager |
106 | | = big change, but we don't use this |
107 | | * however, we probably should as this seems to be the bit that does distortion fixups..? |
108 | | - not ready yet.. maybe next week |
109 | | - post processing sw -> 1.2 |
110 | | - no breaker changes |
111 | | - minimised L/R imbalance, improved radiometric using ccd border area (hrm) |
112 | | |
113 | | things one can detect.. maybe.. |
114 | | - pulse stretching (return pulse longer than laser pulse |
115 | | - slopes |
116 | | - low vegetation (ie. may need to adjust "ground" peak downwards a little) |
117 | | - indication of biomass by evaluating area under peak |
118 | | - better vertical resolution/distinction of objects |
119 | | |
120 | | angle of laser may make a difference (flat ground at nadir is a slope at edge of fov, or cutting through vegetation) |
121 | | |
122 | | software changes |
123 | | - hardware done, most software beta or not done yet |
124 | | - various operation changes |
125 | | - fcms now creates proper structure for file outputs, but only for the laser - rcd isn't done! |
126 | | - may change some of our naming ("WebCamImages" or something like that) |
127 | | - waveform viewer s/w |
128 | | - alspp outputting in las 1.3 type 4 (option to output 1.0 if needed for compat) |
129 | | - version list in presentation |
130 | | |
131 | | where did gain come from in waveform viewer |
132 | | - volts= digitized value * gain + offset |
133 | | - not agc gain, this is a fixed amplication on the waveform board |
134 | | - value is 0.017290626 |
135 | | - offset is also hardcoded, value is 0 |
136 | | - system digitises from 0 to 4.something volts |
137 | | - gives you volts as received at the waveform board, after AGC applied, etc - probably only useful for engineering team |
138 | | |
139 | | bit mode |
140 | | - actually could process it! |
141 | | - interesting underflow spike |
142 | | - engineering think trigger delay shouldn't change with time, but may with temperature? |
143 | | - not sure if bit mode vs lase mode will have a different delay, not tested |
144 | | - fcms will record waveform bit mode data, will in version approximately 3.2.2? probably 6 months |
145 | | - should ensure you have full nav solution for maximum gps timing accuracy (ie. don't just switch on ipas and record, wait a few mins first) |
146 | | - need two recordings for bitmode, at pulse rates above and below TPR |
147 | | |
148 | | gps time difference between line time in alspp summary and waveform viewer times |
149 | | - Yuji checking |
150 | | |
151 | | lashisto viewer |
152 | | - can look at las files with it, gives various useful info |
153 | | - drag and drop a log file into it to get nicely parsed info |
154 | | |
155 | | |
156 | | |
157 | | terrascan |
158 | | - displays waveform as colour coded line along angle of ray |
159 | | - can set thresholds and ranges for colour coding |
160 | | |
161 | | future processing |
162 | | - gaussian fitting to fwd data |
163 | | - working with vienna uni guys |
164 | | |
165 | | ops changes: various.. relevantish ones to us are |
166 | | - hardware is now licensed (ie. turns into a paperweight if expires) |
167 | | - closing fcms shuts the system down cleanly |
168 | | - need to use fpes10 for planning |
169 | | - automatic bit mode at start and end of fcms session |
170 | | - moving to ethernet comms rather than rs232 |
171 | | |
172 | | processing changes |
173 | | - require alspp 2.69 or grater |
174 | | - GPS leverarms refer now to PAV80 rotation center (stabilised mount for camera, we don't have one) |
175 | | - PAV80 would be underneath the scanner |
176 | | * see slides for update formula |
177 | | * update wiki |
178 | | - alspp takes account of this if .sup file has a flag saying it was run with new fcms (sup comes from modern ipas pro) |
179 | | - lever arm measurement is the same, but you must include the offset to the virtual pav80 |
180 | | - note this doesn't apply to IMU - this is a fixed offset and entered into fcms |
181 | | * check it's right ;p |
182 | | - fixed offset is apparently x=-0.411, y=0.206, z=-0.192 |
183 | | - fcms also has a user defined offset currently set that is the offset from the pav80 back to the mirror |
184 | | - this is x=0.142, y=0.001, z=-0.188 |
185 | | * this possibly should be zeroed - Yuji checking if having it set will cause a double offset to be applied |
186 | | - check lever arm error (should be small, a few cm) |
187 | | - new option in alspp to process waveform |
188 | | - trigger delay in pico secs (= splitter circuit delay) |
189 | | - one for 4ns one for 9ns pulse width (!) |
190 | | - but no difference for A & B boards.. hrm |
191 | | - order of 10x slower processing |
192 | | |
| 150 | always produces las 1.3 file (despite currently saying 1.2) |
| 151 | - filename ends _4.las O_o |
| 152 | - unless you choose las 1.0 from the output options, but you must also check the output with timestamp option |
| 153 | trigger delay settings |
| 154 | - TPR = transition pulse rate, when the lidar changes from long pulses to short ones |
| 155 | - for our system, >100KHz = 4ns pulse, <100kHz = 9ns pulse |
| 156 | - each must be calibrated separately.. |
| 157 | - ie. calibration must include one above and one below TPR |
| 158 | - possibly also temperature dependent. shonk. |
| 159 | - should be able to do this with bit mode data? |
| 160 | - possible hardware issue preventing this, definite software issue (fcms doesn't record fwd in bitmode) |
| 161 | - definite killer: timing known to verify within a flightline |
| 162 | |
| 163 | |
| 164 | == Something == |
| 165 | |
| 166 | * When processing data collected after using FCMS v3.15 (anything after Jan 2010 ?) |
| 167 | * ALS system refers to a virtual rotation axis (assumes a PAV80 stabilised mount even if you do not have one) |
| 168 | * we need to update GPS lever arms in FCMS v3.15. |
| 169 | * .SUP file will automatically offset to the mirror centre in ALSPP processing (Need IPAS version 1.35 for this) |
| 170 | * Unsure as to whether leverarms need to be updated in IPAS or not - also how do we know IMU offsets to apply? |
201 | | |
202 | | * Nothing has changed for the AGC/mainboard of the ALS so the raw laser .SCN files will be the same as before. |
203 | | * Extra files will be created that contain the waveform data. Waveform files (.LWV) will be in the raw_wfd directory, SCN files in the raw_laser directory. |
204 | | * Waveform files have A or B in filename depending on which data board (A or B) acquired it. When processing both files are taken together. |
205 | | * The digitiser starts recording from the first returned peak for the number of required samples (256/128 @ 1ns or 256/128/64 @ 2ns) |
206 | | * If first return is noise (cloud/seagull) then the digitiser will start recording there and not at the target. |
207 | | * measured heights / distances for different sampling rates: |
208 | | |
209 | | || Sample rate || equivalent height || |
210 | | || 256 @ 1ns || 38.4m || |
211 | | || 128 @ 1ns || 19.2m || |
212 | | || 256 @ 2ns || 76.8m || |
213 | | || 128 @ 2ns || 38.4m || |
214 | | || 64 @ 2ns || 19.2m || |
215 | | |
216 | | data rate / height stuff |
217 | | - 19.2 / 38.4 / 76.8m for various heights |
218 | | - 1h04 recording at max rate on 160GB SSD |
219 | | |
220 | | * Benefits of full waveform |
221 | | * Better idea of the nature of the return e.g. tree canopy height is more accurate than from 1 discrete point |
222 | | * Extraction of points from the waveform missed by the discrete measuring |
223 | | * (a future benefit) pulse stretching at swath edges compared to nadir: indicating sloped terrain, improved classification |
224 | | * Maximum rate of acquiring digitised full waveform data is 120KHz. If a higher rate is used then the waveform data will record for every other emitted pulse. But the SCN files will still be recorded at the high rate. |
225 | | * Pulse length (sampling rate) should be chosen based on the maximum height of targets in the area. E.G. if all low lying targets then there is no point using 256 samples at 1 ns - better to use 128 at 1 ns. |
226 | | * No changes to the calibration flights except to collect FW data. Only change to the processing is to find the timing offset between FW and discrete points. |
227 | | * Pre-trigger - like a buffer zone to record digitised samples before the first return. Default is 5m. |
228 | | * Waveform and discrete data use different scalers for the intensity values and so will result in different intensities. |
229 | | * AGC is constant for a pulse - so the same value is used for the entire waveform |
230 | | * There is a slight delay between SCN files and waveform files being recorded (< 1 second). This may result in first few points not having waveform data. |
231 | | |
232 | | == Software == |
233 | | |
234 | | * ALSPP outputs in LAS 1.3 format which supports full waveform data (and also LAS 1.0) |
235 | | * To output in LAS v1.0 you must also select "LAS file with time stamp" in output options else no files will be output |
236 | | * ALSPP takes 10 times as long to process the data to produce a LAS file when using FWD |
237 | | * Includes a simple waveform viewer |
238 | | * Displays waveform and discrete points |
239 | | * There is a "constant" timing offset between the waveform and discrete points - thought to be due to processing time. This should be removed at calibration |
240 | | * In waveviewer "Ret point loc" is the discrete return time (from emit to receive) for the first return |
241 | | * intensity is the value for each discrete return |
242 | | * LASHistoViewer is useful for viewing stats of LAS file. Can also "drag and drop" Flightline_log into it to see info and stats together. |
243 | | * New version of Terrascan capable of displaying full waveform data and "creating extra" points from the waveform |
244 | | |
245 | | |
246 | | == Something == |
247 | | |
248 | | * When processing data collected after using FCMS v3.15 (anything after Jan 2010 ?) |
249 | | * ALS system refers to a virtual rotation axis (assumes a PAV80 stabilised mount even if you do not have one) |
250 | | * we need to update GPS lever arms in FCMS v3.15. |
251 | | * .SUP file will automatically offset to the mirror centre in ALSPP processing (Need IPAS version 1.35 for this) |
252 | | * Unsure as to whether leverarms need to be updated in IPAS or not - also how do we know IMU offsets to apply? |
253 | | |
| 179 | future processing |
| 180 | - gaussian fitting to fwd data |
| 181 | - working with vienna uni guys |
| 212 | lashisto viewer |
| 213 | - can look at las files with it, gives various useful info |
| 214 | - drag and drop a log file into it to get nicely parsed info |
| 215 | |
| 216 | |
| 217 | |
| 218 | terrascan |
| 219 | - displays waveform as colour coded line along angle of ray |
| 220 | - can set thresholds and ranges for colour coding |
| 221 | |
| 222 | processing changes |
| 223 | - require alspp 2.69 or grater |
| 224 | - GPS leverarms refer now to PAV80 rotation center (stabilised mount for camera, we don't have one) |
| 225 | - PAV80 would be underneath the scanner |
| 226 | * see slides for update formula |
| 227 | * update wiki |
| 228 | - alspp takes account of this if .sup file has a flag saying it was run with new fcms (sup comes from modern ipas pro) |
| 229 | - lever arm measurement is the same, but you must include the offset to the virtual pav80 |
| 230 | - note this doesn't apply to IMU - this is a fixed offset and entered into fcms |
| 231 | * check it's right ;p |
| 232 | - fixed offset is apparently x=-0.411, y=0.206, z=-0.192 |
| 233 | - fcms also has a user defined offset currently set that is the offset from the pav80 back to the mirror |
| 234 | - this is x=0.142, y=0.001, z=-0.188 |
| 235 | * this possibly should be zeroed - Yuji checking if having it set will cause a double offset to be applied |
| 236 | - check lever arm error (should be small, a few cm) |
| 237 | - new option in alspp to process waveform |
| 238 | - trigger delay in pico secs (= splitter circuit delay) |
| 239 | - one for 4ns one for 9ns pulse width (!) |
| 240 | - but no difference for A & B boards.. hrm |
| 241 | - order of 10x slower processing |
| 242 | |