06:23 <GitHub36> [artiq] mntng closed pull request #831: set maximal divider value for SPI write and read clk (master...master) https://github.com/m-labs/artiq/pull/831

06:31 <GitHub17> [artiq] mntng opened pull request #832: set range for divider values (master...master) https://github.com/m-labs/artiq/pull/832

06:36 <GitHub107> [artiq] sbourdeauducq pushed 1 new commit to rtio-sed: https://github.com/m-labs/artiq/commit/07d3f87c5168e0b6441b102f5793f5d703fce17d

06:36 <GitHub107> artiq/rtio-sed 07d3f87 Sebastien Bourdeauducq: rtio/sed: min_space → buffer_space

06:40 <rjo> whitequark: it's better than what i had in mind. i had not expected Assembler.add() to be that nice.

06:44 <GitHub112> [artiq] jordens pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/9ccd95e10dfc...0a4381595621

06:44 <GitHub112> artiq/master 0a43815 Robert Jördens: Merge pull request #832 from mntng/master...

06:44 <GitHub112> artiq/master e94d2d3 Thao: set range for divider values

06:44 <GitHub38> [artiq] jordens closed pull request #832: set range for divider values (master...master) https://github.com/m-labs/artiq/pull/832

06:44 <GitHub129> [artiq] jordens commented on issue #832: thanks! https://github.com/m-labs/artiq/pull/832#issuecomment-331066786

07:07 <bb-m-labs> build #779 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/779

07:16 <bb-m-labs> build #569 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/569

07:16 <bb-m-labs> build #1679 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1679

08:02 <GitHub67> [artiq] sbourdeauducq closed issue #799: Minimum SPI clock frequency(equivalently maximum divider) needs documentation https://github.com/m-labs/artiq/issues/799

08:09 <GitHub80> [artiq] sbourdeauducq commented on issue #40: There is no problem with negative offsets, either on inputs or outputs, other than what I explained above and the increased slack requirements for outputs.... https://github.com/m-labs/artiq/issues/40#issuecomment-331084251

14:32 <GitHub167> [artiq] sbourdeauducq pushed 2 new commits to rtio-sed: https://github.com/m-labs/artiq/compare/07d3f87c5168...5cf06937588e

14:32 <GitHub167> artiq/rtio-sed 5cf0693 Sebastien Bourdeauducq: rtio: use BlindTransfer to report collision and busy errors to sys domain

14:32 <GitHub167> artiq/rtio-sed d74a7d2 Sebastien Bourdeauducq: rtio: fix/cleanup parameters

14:32 <sb0> bb-m-labs, force build --branch=rtio-sed artiq

14:32 <bb-m-labs> build forced [ETA 32m29s]

14:32 <bb-m-labs> I'll give a shout when the build finishes

14:55 <bb-m-labs> build #780 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/780

15:00 <bb-m-labs> build #1680 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1680

16:12 <rjo> sb0: current bscan_spi bitstreams and openocd work with sayma amc, kc705, reading and writing. but now on the one Sayma AMC you have connected, the second flash doesn't work.

16:13 <sb0> okay, I'll connect another one tomorrow

16:14 <sb0> what was the bug with writing?

16:16 <rjo> unexpected behavior of those flash chips to spi commands with spurios bits at the end.

16:16 <rjo> there might still be minor tweaks needed for the RTM case.

16:17 <sb0> ah, good find

16:17 <sb0> it could be that write-lock when they see the master acting crazy. they might have purposefully designed it that way.

16:21 <rjo> yes.

17:21 <GitHub159> [artiq] jbqubit commented on issue #40: > With the minimal amount of code modification, coreanalyzer would have compensated timestamps on inputs and uncompensated timestamps on outputs.... https://github.com/m-labs/artiq/issues/40#issuecomment-331224254

18:35 <GitHub35> [sinara] gkasprow pushed 1 new commit to master: https://github.com/m-labs/sinara/commit/ba48b4bb6ea0f90c5ad823629acf31f0481a6c8f

18:35 <GitHub35> sinara/master ba48b4b Greg: layout done, cosmetics missing.

19:00 <GitHub71> [artiq] dhslichter commented on issue #40: Negative-compensated timestamps on inputs is pretty straightforward I think; the trick is negative-compensated timestamps on outputs, and what this does to the FIFO structure proposed for SRTIO. In the current structure, with one FIFO per RTIO channel, it's pretty straightforward because each event in a given FIFO will have the same latency, but with this round-robin configuration things could get ugly fa

19:37 <GitHub9> [smoltcp] steffengy commented on issue #43: @whitequark ... https://git.io/vdvTj

19:39 <GitHub197> [artiq] jbqubit commented on issue #40: > one can easily change/reset the latency values... https://github.com/m-labs/artiq/issues/40#issuecomment-331259874

20:34 <GitHub181> [artiq] dhslichter commented on issue #40: Per-experiment latency control is a calibration/debugging feature. If you put some wack-ass latency values in, it may make things hard to debug, and you want to reset them to zero (for example) for debugging purposes. Likewise, you might change a cable in your lab setup and it would be nice to be able to recalibrate this without restarting everything. You might have an ion trapped and want to keep run

20:34 <GitHub195> [artiq] dhslichter commented on issue #40: Per-experiment latency control is a calibration/debugging feature. If you put some wack-ass latency values in, it may make things hard to debug, and you want to reset them to zero (for example) for debugging purposes. Likewise, you might change a cable in your lab setup and it would be nice to be able to recalibrate this without restarting everything. You might have an ion trapped and want to keep run

20:50 <GitHub77> [artiq] dhslichter commented on issue #40: A related question/thought: related to some of the issues in #778, it would be nice to do as little timeline rewinding as possible in the kernels. Is there a clean way that one could, at compile time, change the order in which pulse timestamps are emitted from the kernel in order to reduce rewinds? For example:... https://github.com/m-labs/artiq/issues/40#issuecomment-331277787

20:51 <GitHub53> [artiq] dhslichter commented on issue #40: A related question/thought: related to some of the issues in #778, it would be nice to do as little timeline rewinding as possible in the kernels. Is there a clean way that one could, at compile time, change the order in which pulse timestamps are emitted from the kernel in order to reduce rewinds? For example:... https://github.com/m-labs/artiq/issues/40#issuecomment-331277787

20:53 <GitHub164> [artiq] dhslichter commented on issue #40: A related question/thought: related to some of the issues in #778, it would be nice to do as little timeline rewinding as possible in the kernels. Is there a clean way that one could, at compile time, change the order in which pulse timestamps are emitted from the kernel in order to reduce rewinds? For example:... https://github.com/m-labs/artiq/issues/40#issuecomment-331277787

20:59 <karlesomatagente> hello

21:01 <karlesomatagente> me and some friends are writing a paper for college about what motivates participation in open hardware projects

21:02 <karlesomatagente> and would like to interview collaborators

21:03 <karlesomatagente> i was guided to seek help here from more general hardware channels

21:52 <GitHub153> [sinara] gkasprow pushed 2 new commits to master: https://github.com/m-labs/sinara/compare/ba48b4bb6ea0...63e768f28cb2

21:52 <GitHub153> sinara/master 63e768f Greg: production files

21:52 <GitHub153> sinara/master 3e5d885 Greg: added polygons

23:10 <GitHub29> [sinara] jbqubit pushed 1 new commit to master: https://github.com/m-labs/sinara/commit/59a7fe8c6157f54cfaafabe87f5cc225ec2fc184

23:10 <GitHub29> sinara/master 59a7fe8 Joe Britton: layout renderings for baikal