Tony's summary of the 27May SGIR Meeting in Manoa Attended by: IRTF (TD, CL, EW), and SG (PO, IS, CR) 1. Good discussion occurred. IRTF demo the pclock program to the SG group. The SG group thinks a more generalize approach for supporting IR device (less code stage2) should be implemented in the actual stage2. Seems like if these features were implemented in in stage2: 1. Transfer to the Seq table and CE_sam/reset tables data from host to uboot. 2. Code to run the sequence tables. 3. A method to stream the resulting array readouts to a the host. Then SGIR could support any IR Device (no array specific code in stage2). The generation of CE Engine commands and the SeqTables would be coded/executed on the linux host. Unfortunately, IRTF needs a controller as soon as the hardware is built. So, TD thinks, IRTF could continue with it's pclock prototype branch and use it as an initial solution. This pclock branch could help the SG group with it's more generalize implementation. Later the IRTF would switch over. 2. TD to provide pclock2 source code, and CE Eng timing notes. TD's pclock talks was based on these notes: pclock2.html The source code for pclock is here: pclock2.tar To untar: tar xvzf pclock2.tar The README.html is the place to start. I also copied my version of cli_comlist.c here: cli_comlist.c TD to provde data on CE engine timing testing using the logic analyser: 2.1 - The result of the timing measurement are used by ir.c/h. When generating CE command into the ir_ce_buf_t the function ir_ce_put() needs the CE data, nsec (time to execute). 2.2 - These pages contains my note when I was measuring clocking waveform on the logic analyser: Tony's CE notes: ce.html ce_timing.html Illustrate how to clock the aladdin array: ce_adc_diagram_1.png Illustrate how to clock the aladdin array: Aladdin_clocks_illustration.pdf 3. SI to write code fill data (to a buffer pool) and transfer data to host code in gpc/ The Hilo group can using this to continue prototyping in pclock. IRTF as the cable to upgrade the firmware. IRTF should look a grasp_vidgrab (rather than grasp_save) as an example of how to do things. 4. A future discussion on how the A/D samples get handled is needed: A 4-1,4-1 method provides the lowest noises, but require 32-bit per pixel. There could be an issue the H2RG (using Red & Green), as it was unclear if the FPGA could provde and single 16 or 32 bit values per pixel for multiple samples. Ideally, when sampling a pixel, a single 16-bit averaged value is desired. It should be noted that the term "Math Engine" refers a desired FPGA development. There are no firm plans to implement this now. IRTF might expect a 'hack' to the current FPGA to support sgir, nsfcam, spex, ishell.