sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined #m-labs
cr1901_modern has joined #m-labs
balrog has quit [Quit: Bye]
balrog has joined #m-labs
kaolpr has quit [Ping timeout: 268 seconds]
kaolpr has joined #m-labs
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1026: When that happens, can you post the *exact* runtime.elf file that was flashed into the board, and the corresponding *exact* error message?... https://github.com/m-labs/artiq/issues/1026#issuecomment-393389318
<GitHub-m-labs>
[artiq] hartytp commented on issue #1015: > To a new user it may not be clear if clock is derived from DRTIO or external or from XO. Never hurts to reiterate frequency range and power.... https://github.com/m-labs/artiq/issues/1015#issuecomment-393450248
<GitHub-m-labs>
[artiq] hartytp commented on issue #1027: 3. `Output RF switch setting takes effect immediately.` means that the RF switch opens after exactly 1 servo memory access time (approx 1 us -- it would be good to have the exact memory access time and update cycle time documented clearly). https://github.com/m-labs/artiq/issues/1027#issuecomment-393486827
<GitHub-m-labs>
[artiq] hartytp commented on issue #1027: 4. The delay set using `set_iir` is rounded to the nearest number of 1.2us servo cycles. So, e.g., a 3 us delay will round up to about 3.5us. This delay is effectively a lower bound on the delay, since it is synchronous with the servo update timings. So, a delay of 3us means that the actual delay will lie between 3.5us and 4.7us.... https://github.com/m-labs/artiq/i
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 244 seconds]
<GitHub-m-labs>
[artiq] hartytp commented on issue #1027: 4. The delay set using `set_iir` is rounded to the nearest number of 1.2us servo cycles. So, e.g., a 3 us delay will round up to about 3.5us. This delay is effectively a lower bound on the delay, since it is synchronous with the servo update timings. So, a delay of 3us means that the actual delay will lie between 3.5us and 4.7us.... https://github.com/m-labs/artiq/i
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #1020: @hartytp: if you are able to reproduce the hangs/crashes, i first suggest to verify the ouptuts of the hmc830 and hmc7043. We already saw that it can cause some broadband noise and having a crash just when we are configuring and enabling the outputs of the hmc7043 seems strange... It also strange that when we have the first crashes, we are then not able to pass th
<GitHub-m-labs>
[artiq] hartytp commented on issue #1020: @enjoy-digital ack. If I start to be able to reproduce the issue then I'll have a look at that. I'll also look at the 7043 outputs on a fast scope and see how they look.... https://github.com/m-labs/artiq/issues/1020#issuecomment-393523878
<GitHub-m-labs>
[artiq] hartytp commented on issue #1027: > We can add a feature that gives you synchronization on-the-fly by supporting emission of an RTIO input event when a cycle starts. The other way to synchronize is to calculate the cycle restart from the known enable timestamp and the cycle time.... https://github.com/m-labs/artiq/issues/1027#issuecomment-393525203
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1026: Just happened again. Was running sines.py and seeing sinusoidal output on scope. After about 2 minutes see panic and output on scope is garbage. Same .elf. ... https://github.com/m-labs/artiq/issues/1026#issuecomment-393526991
<GitHub-m-labs>
[artiq] hartytp commented on issue #1030: True, I'd forgotten that it's documented there. Do you think it would be worth adding a note in `get_adc` as well (in practice, it's easy for a user to forget to go back and look at the constructor docs)? If you strongly feel that this is redundant/pointless then I'm fine with that. https://github.com/m-labs/artiq/issues/1030#issuecomment-393538908
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1022: They're not reflections. They only appear on some channels. For some reason my scope doesn't do AC coupling AND 50-Ohm internal termination at the same time. I'm getting proper external terminators post haste. Prior to posting the present screen shots I confirmed that the wiggles were present even with 50-Ohm internal termination and DC coupling. But its easier to see w
<GitHub-m-labs>
[artiq] jordens commented on issue #1033: I went along the lines of the digital-servo. We change it if that's your preferred parametrizaion. I don't think there would be that much less special casing. https://github.com/m-labs/artiq/issues/1033#issuecomment-393549078
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1022: Oddly, after rebooting and programming sines.py again the "funky/wiggly" behavior went away on the two channels where it was formerly present. Here's SA for "good looking" channel. ... https://github.com/m-labs/artiq/issues/1022#issuecomment-393552597
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1020: Being able to constrain output of RF system to only "good behavior" is really important. Even when booting. One manifestation of this is #1031. https://github.com/m-labs/artiq/issues/1020#issuecomment-393553536
<GitHub-m-labs>
[artiq] jbqubit commented on issue #998: Please make mods to your hardware to get Ethernet to work. Please open an Issue on sinara-hw if you don't know what changes need to be made. https://github.com/m-labs/artiq/issues/998#issuecomment-393555024
<GitHub-m-labs>
[artiq] hartytp commented on issue #998: > Please make mods to your hardware to get Ethernet to work. Please open an Issue on sinara-hw if you don't know what changes need to be made.... https://github.com/m-labs/artiq/issues/998#issuecomment-393556583
<GitHub-m-labs>
[artiq] jbqubit commented on issue #998: @hartytp M-Labs needs a working hardware setup so they have the ability to debug Sayma. Many of the very nice debug tools rely on Ethernet. It's annoying the M-Labs sent their only fully functioning board to Duke without having a fully-functioning backup in HK. It's like the warning on aircraft to "put the oxygen mask on yourself before assisting your fellow passenger."
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #998: And the analyzer buffer is cleared every time you use ``artiq_coreanalyzer`` to retrieve it from the board. So the procedure is: artiq_coreanalyzer, throw away the results, run experiment, artiq_coreanalyzer again and post results. Or if the board is freshly booted and without a startup kernel, the buffer is already empty. https://github.com/m-labs/artiq/issues
<GitHub-m-labs>
[artiq] jbqubit commented on issue #998: > And the analyzer buffer is cleared every time you use artiq_coreanalyzer to retrieve it from the board. So the procedure is: artiq_coreanalyzer, throw away the results, run experiment, artiq_coreanalyzer again and post results. Or if the board is freshly booted and without a startup kernel, the buffer is already empty.... https://github.com/m-labs/artiq/issues/998#
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: As previously discussed, we'd like to use the SUservo with Sampler 10m away using a pair of VHDCI_carrier cards as SCSI<->IDC adapters. Initial SI testing on Kasli suggests that this should be possible from a HW perspective. ... https://github.com/m-labs/artiq/issues/788#issuecomment-393566670
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: @jordens hmm...had a quick go at that. With `t_rtt=15+5` all the red LEDs are on on my Urukul. Do you expect (SI asside) that running the gateware with this `t_rtt` will work? If so, I'll look into what's wrong on my setup in the morning. https://github.com/m-labs/artiq/issues/788#issuecomment-393578023
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1036: The SAWG gateware is essentially the same on KC705-phaser and on Sayma. So, you're probably seeing general Sayma bugginess and nothing that is SAWG specific. https://github.com/m-labs/artiq/issues/1036#issuecomment-393595403
<GitHub-m-labs>
[artiq] jordens commented on issue #1034: Hmm. On re-reading I don't understand the first paragraph. Just to clarify: This is a setup with a positive ADC working point and thus negative `offset`. Do you mean `offset=-0.99` and `offset=-1` in the first paragraph? Because those two should be fine. https://github.com/m-labs/artiq/issues/1034#issuecomment-393600311
<GitHub-m-labs>
artiq/master 5dbdc56 Robert Jordens: suservo: document set_config and get_status more...
<GitHub-m-labs>
artiq/master e1b0fcc Robert Jordens: suservo: add documentation on settings and setup...
<GitHub-m-labs>
artiq/master 9b5a46d Robert Jordens: suservo: fix restart counter assertion...
<GitHub-m-labs>
[artiq] jbqubit commented on issue #1036: When I tested SAWG on KC705 in summer 2017 I found quite a few bugs. @jordens worked with me to resolve many of them but the process was painful. The point of creating a test suite is to codify in code my baseline expectations. They're simple tests you can run on your own hardware. And, there's no communication delay or inevitable misunderstands that arise in human lang
<GitHub-m-labs>
[artiq] jordens commented on issue #1033: I went along the lines of the digital-servo. One argument would be that the corner frequency is the only (externally relevant) frequency scale of a PI filter. We change it if that's your preferred parametrizaion. I don't think there would be that much less special casing. https://github.com/m-labs/artiq/issues/1033#issuecomment-393549078
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: Thanks. I suspect it's something daft like a loose cable in my setup. But, I just wanted to check that there is no obvious reason why this won't work. I'll dig into it in the morning. This is the last test I want to do on the bench before using the servo in experiments. https://github.com/m-labs/artiq/issues/788#issuecomment-393673331