• @Kristofer PISTER

  • @Lydia Lee

  • @Jove Yuan

  • @Titan Yuan

  • @Alex Moreno

  • @David Burnett

  • @brian kilberg

  • @Tengfei Chang [remote]

Action Items

@Tengfei Chang continuous on code organization
@Tengfei Chang sweep test on Q3/Q8


@David Burnett is here!

@Jove Yuan Laser programmer

  • @Jove Yuan laser is not reliable (running master code to test optical program)

  • preliminary tests of visible LEDs show that some are viable (but programming has not been successful yet)

  • @Alex Moreno the alignment of the laser to the board is a problem?

  • an enclosure for SCuM could be an idea?

  • @Kristofer PISTER we are trying to get rid of the hazard IR part.

  • @Jove Yuan according to Brad’s thesis: if the short pulse of the laser is shorter then the self-clocked register delay (nominally 1us), should be able to program

  • can’t rely on the OPTICAL_RAW_DATA GPIO oscilloscope output to determine if programming will be successful (viewing 100us window does that mean entire program was sent successfully)

  • @Kristofer PISTER there are million of bits transfer which is hard to tell through oscilloscope.

  • @Kristofer PISTER @Jove Yuan should look at the digital output of the optical receiver (not just the RAW signals) and use a logic analyzer to see what the bit error rate is as a function of programming parameters: LED type, 4 pulse length settings, distance, etc.

  • @Kristofer PISTER @Jove Yuan should fill in the table with LED performance to include the actual measured drive current of the LED (which should be at or above the rated value on the datasheet) and the expected power density (mW/mm2) at 1cm distance.

  • @Kristofer PISTER if we are trying to use an enclosure, why not using the 3 wire bus to program?

  • @Tengfei Chang

    • update code organization next time