Date

Attendees

Goals

  • First group meeting

Discussion items

TimeItemWhoNotes
    

Action items

  • Clarify questions to Tor Arne

    1: Is the justification for go above 700 nm clear? Do we have to cover 700 - 900 nm? As this impacts (limits) the sensors to be used, this should be clarified and be supported by scientific needs

    2: Should we go ahead on build prototype with sensor + FPGA-board

  • Joao will finish an report from UAV test-flights this week --> send to Kanna, Julian and others

Status and staffing

Milica: 4 students

Joao: 3 students

One more phd-student to join us soon, hopefully

Data from HSI

There are data from drones: 
Joao is working on it, must calibrate something for wavelengths. 

Julian would like to review data as soon as possible. 

Joao has limited time, so things takes some time

Data from flights are from a lagoon, so they are brighter than deep clear/dark ocean.

Hardware

Start with system + smaller FPGA-board. Build modular before we do custom design. 

Timeframe for the prototype: Julian: One week to assemble everything.

Firmware (talking to the sensor) and such are missing. 

Milica wants to start pull data from memory; Julian does the integration/readout from the sensor

Specifications on the data cube: 
100 bands are ~fixed
500x500 pixles
12 bits/pixel (but still use 2 bytes so far. Should be fixed)

Software

Joao suggests perhaps starting with only using raw-mode first, and the have more advanced modes after we go on.

Must define which bands! Do we actually need above 700 nm. Do we actually need the 1-2 nm resolution?

There will be much more sensors available if we cut-off at 700 nm. Can be traded for sensitivity. 

The range to 900 nm is perhaps not justified? Is it a wish to "see what is there"?

Process

Who is actually decides stuff? How is leading?

We need to have a project manager

Actions ahead

Joao will finish an report from UAV test-flights this week --> send to Kanna, Julian and others

Should go forward with hardware development and procurement - making the assumption that the test-flight data is in such a state that it will change our design. Julian must check with Tor Arne. 

Bi-weekly meetings.