| | 22 | - normal lidar returns based on threshold, then look for peaks |
| | 23 | - requires a non-peak gap after a peak is found, so double peaks not spottable without fwd |
| | 24 | |
| | 25 | laser pulse is 4ns pulse duration or 9ns (<100khz digitisation), so must have a <2ns intensity digitisation to avoid aliasing (nyquist), normally prefer 1ns |
| | 26 | |
| | 27 | 1ns = 15 cm |
| | 28 | |
| | 29 | intensity is digitised to 8bit |
| | 30 | - no range gate yet but may be added (phil) |
| | 31 | - "pre-trigger" samples = buffer before first return peak to ensure you get lead in to pulse, defaults to 5m |
| | 32 | - especially important if there's low signal before first real peak, e.g. sparse tree top |
| | 33 | range data is measured independently to achieve 1.5cm range (100 picosec). |
| | 34 | - fwd data goes to RawWFD, structure identical to RawLaser, files named WFDYYMMDD_HHMMSS_XXXXXXXXXXX{AB}.LWV |
| | 35 | - A or B indicates which board digitised the signal |
| | 36 | .LWV files |
| | 37 | - are always up to 62501KB |
| | 38 | - always in A&B pairs |
| | 39 | - can't link single scn files to lwv files within a flightline |
| | 40 | flightline log file says if WFD on/off |
| | 41 | |
| | 42 | can turn processing of waveform data off |
| | 43 | always produces las 1.3 file (despite currently saying 1.2) |
| | 44 | - filename ends _4.las O_o |
| | 45 | - unless you choose las 1.0 from the output options, but you must also check the output with timestamp option |
| | 46 | trigger delay settings |
| | 47 | - TPR = transition pulse rate, when the lidar changes from long pulses to short ones |
| | 48 | - for our system, >100KHz = 4ns pulse, <100kHz = 9ns pulse |
| | 49 | - each must be calibrated separately.. |
| | 50 | - ie. calibration must include one above and one below TPR |
| | 51 | - possibly also temperature dependent. shonk. |
| | 52 | - should be able to do this with bit mode data? |
| | 53 | - possible hardware issue preventing this, definite software issue (fcms doesn't record fwd in bitmode) |
| | 54 | - definite killer: timing known to verify within a flightline |
| | 55 | |
| | 56 | processing time |
| | 57 | - discrete only, maybe 30secs per line |
| | 58 | - waveform data = ~10x slower |
| | 59 | - started 1023, finished 1030 |
| | 60 | - approx 10x larger file (46MB without fwd and 450MB with) |
| | 61 | |
| | 62 | waveform viewer |
| | 63 | - gps time = time of first return / when fwd started recording (but note it'll also have some pretrigger buffering) |
| | 64 | - retpoint loc = same time but in terms of fwd timing (?) |
| | 65 | - no way to accurately get second, third, etc times |
| | 66 | |
| | 67 | calibration procedure |
| | 68 | - delay between first return and trigger pulse getting to waveform digitiser |
| | 69 | - histogram viewer (lashistoviewer) |
| | 70 | - can see AGC histogram. Looking for dataset with agc somewhere in the middle range (150 ish) and without large variations |
| | 71 | - look for data point with intensity 60-80 ish / 1V, single return |
| | 72 | - find peak time for first return visually (e.g. 22.5ns into fwd sample window) |
| | 73 | - use ret point loc (e.g. 32.766ns) |
| | 74 | - calculate delay ;p |
| | 75 | - put into trigger delay in options, see if things look better |
| | 76 | - repeat N times |
| | 77 | - repeat for dataset above and below TPR |
| | 78 | - known to vary within a flightline by a small amount (+/- 100 ps) |
| | 79 | viewing with terrascan |
| | 80 | - alspp, create trj trajectory files |
| | 81 | - provide to terrascan.. next to helicopter icon under /// icon in toolbox ;p |
| | 82 | - then select file and import |
| | 83 | - terrabox, flightline -> deduce using time |
| | 84 | * possibly need to add trajectory to las 1.3? |
| | 85 | - view single point's waveform |
| | 86 | - draw in 3d draws a coloured ray, blue = low value, red = high |
| | 87 | - have to delete ray manually O-o choose selection tool, select line, delete |
| | 88 | - spectacularly poo |
| | 89 | - extract echoes (cf. calculate returns from waveform data) |
| | 90 | - place fence around, say, a tree |
| | 91 | - extract echoes |
| | 92 | - analyses waveform data and picks out a bunch of new returns, adds them |
| | 93 | - can extract data to ascii for a single point or a fence (EEK! one text file per point! NO, per {only or first+last} return!) |
| | 94 | - not sure there's a way to tie the waveform info to the return time? particularly for not-first-returns |
| | 95 | - spectacularly poo |
| | 96 | - terrascan user group meeting |
| | 97 | - 10-17 February 9th Terrasolid European Users Event, Levi Summit, Kittilä, Finland, Internet: www.terrasolid.fi/en/events/terrasolid_european_users_event_2010_agenda_an |
| | 98 | - check out other software, fullanalyze? |
| | 99 | |
| | 100 | |
| | 101 | |
| | 102 | RCD changes |
| | 103 | - uses full CCD instead of cut down area |
| | 104 | - 7162x5389 -> 7212x5408, 7012x5208 after geometric enhancement |
| | 105 | - see presentation for depressing readout location on old setup |
| | 106 | - change to SSD |
| | 107 | - new workflow software |
| | 108 | - file renaming to flightline/project naming from fcms |
| | 109 | - distortion removal, shutter correction |
| | 110 | - DTM support, for displaying in workflow manager |
| | 111 | = big change, but we don't use this |
| | 112 | * however, we probably should as this seems to be the bit that does distortion fixups..? |
| | 113 | - not ready yet.. maybe next week |
| | 114 | - post processing sw -> 1.2 |
| | 115 | - no breaker changes |
| | 116 | - minimised L/R imbalance, improved radiometric using ccd border area (hrm) |
| | 117 | |
| | 118 | AGC setting constant for a single pulse (ie. only need the one recorded in SCN) |
| | 119 | - confusing slide on intensity scale relating to voltage.. not quite sure what value is recorded (raw or agc scaled) |
| | 120 | - note intensity scales are different for standard returns and fwd |
| | 121 | |
| | 122 | things one can detect.. maybe.. |
| | 123 | - pulse stretching (return pulse longer than laser pulse |
| | 124 | - slopes |
| | 125 | - low vegetation (ie. may need to adjust "ground" peak downwards a little) |
| | 126 | - indication of biomass by evaluating area under peak |
| | 127 | - better vertical resolution/distinction of objects |
| | 128 | |
| | 129 | angle of laser may make a difference (flat ground at nadir is a slope at edge of fov, or cutting through vegetation) |
| | 130 | |
| | 131 | hardware changes |
| | 132 | - new data logger (cope with higher io) |
| | 133 | - hdd -> 160GB SSD, works up to 7620m altitude |
| | 134 | - should be ok to use spinning disk for bigger datasets @ low altitude |
| | 135 | - can't swap disks in flight without full shutdown of logger, but can keep ipas going without recording |
| | 136 | - fwd boards, 2 of them at 60kHz each |
| | 137 | |
| | 138 | software changes |
| | 139 | - hardware done, most software beta or not done yet |
| | 140 | - various operation changes |
| | 141 | - fcms now creates proper structure for file outputs, but only for the laser - rcd isn't done! |
| | 142 | - may change some of our naming ("WebCamImages" or something like that) |
| | 143 | - waveform viewer s/w |
| | 144 | - alspp outputting in las 1.3 type 4 (option to output 1.0 if needed for compat) |
| | 145 | - version list in presentation |
| | 146 | |
| | 147 | if pulse rate > 120kHz, then FWD on every second pulse.. e.g. 150kHz SCN file = 75kHz FWD |
| | 148 | |
| | 149 | where did gain come from in waveform viewer |
| | 150 | - volts= digitized value * gain + offset |
| | 151 | - not agc gain, this is a fixed amplication on the waveform board |
| | 152 | - value is 0.017290626 |
| | 153 | - offset is also hardcoded, value is 0 |
| | 154 | - system digitises from 0 to 4.something volts |
| | 155 | - gives you volts as received at the waveform board, after AGC applied, etc - probably only useful for engineering team |
| | 156 | |
| | 157 | bit mode |
| | 158 | - actually could process it! |
| | 159 | - interesting underflow spike |
| | 160 | - engineering think trigger delay shouldn't change with time, but may with temperature? |
| | 161 | - not sure if bit mode vs lase mode will have a different delay, not tested |
| | 162 | - fcms will record waveform bit mode data, will in version approximately 3.2.2? probably 6 months |
| | 163 | - 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) |
| | 164 | - need two recordings for bitmode, at pulse rates above and below TPR |
| | 165 | |
| | 166 | gps time difference between line time in alspp summary and waveform viewer times |
| | 167 | - Yuji checking |
| | 168 | |
| | 169 | lashisto viewer |
| | 170 | - can look at las files with it, gives various useful info |
| | 171 | - drag and drop a log file into it to get nicely parsed info |
| | 172 | |
| | 173 | data rate / height stuff |
| | 174 | - 19.2 / 38.4 / 76.8m for various heights |
| | 175 | - 1h04 recording at max rate on 160GB SSD |
| | 176 | |
| | 177 | terrascan |
| | 178 | - displays waveform as colour coded line along angle of ray |
| | 179 | - can set thresholds and ranges for colour coding |
| | 180 | |
| | 181 | future processing |
| | 182 | - gaussian fitting to fwd data |
| | 183 | - working with vienna uni guys |
| | 184 | |
| | 185 | ops changes: various.. relevantish ones to us are |
| | 186 | - hardware is now licensed (ie. turns into a paperweight if expires) |
| | 187 | - closing fcms shuts the system down cleanly |
| | 188 | - need to use fpes10 for planning |
| | 189 | - automatic bit mode at start and end of fcms session |
| | 190 | - moving to ethernet comms rather than rs232 |
| | 191 | |
| | 192 | processing changes |
| | 193 | - require alspp 2.69 or grater |
| | 194 | - GPS leverarms refer now to PAV80 rotation center (stabilised mount for camera, we don't have one) |
| | 195 | - PAV80 would be underneath the scanner |
| | 196 | * see slides for update formula |
| | 197 | * update wiki |
| | 198 | - alspp takes account of this if .sup file has a flag saying it was run with new fcms (sup comes from modern ipas pro) |
| | 199 | - lever arm measurement is the same, but you must include the offset to the virtual pav80 |
| | 200 | - note this doesn't apply to IMU - this is a fixed offset and entered into fcms |
| | 201 | * check it's right ;p |
| | 202 | - fixed offset is apparently x=-0.411, y=0.206, z=-0.192 |
| | 203 | - fcms also has a user defined offset currently set that is the offset from the pav80 back to the mirror |
| | 204 | - this is x=0.142, y=0.001, z=-0.188 |
| | 205 | * this possibly should be zeroed - Yuji checking if having it set will cause a double offset to be applied |
| | 206 | - check lever arm error (should be small, a few cm) |
| | 207 | - new option in alspp to process waveform |
| | 208 | - trigger delay in pico secs (= splitter circuit delay) |
| | 209 | - one for 4ns one for 9ns pulse width (!) |
| | 210 | - but no difference for A & B boards.. hrm |
| | 211 | - order of 10x slower processing |
| | 212 | |
| | 213 | |
| | 214 | IMU discussion |
| | 215 | - some discussion of IMU sharing |
| | 216 | - should be possible to mount lidar rigidly by removing shocks (or add massive stiffener!) and then applanix / ipas IMUs should be the same |
| | 217 | - not a risk of damage |
| | 218 | - interesting talk about harmonics between mirror vibration and engine vibration |
| | 219 | - IMU can pick this up and it'll show as banding alongtrack (for pitch errors) in the data |
| | 220 | |
| | 221 | |