sb0 changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs :: Due to spam bots, only registered users can talk. See: https://freenode.net/kb/answer/registration
<GitHub157> [smoltcp] jhwgh1968 commented on issue #256: I have updated my test branch, and replaced the ``dequeue`` calls with ``recv``. It seems to still return ``Ok(None)``.... https://github.com/m-labs/smoltcp/issues/256#issuecomment-428018235
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1129: @jbqubit ping https://github.com/m-labs/artiq/issues/1129#issuecomment-428030219
rohitksingh_work has joined #m-labs
<sb0> are we still using a hmc542 on the new AFEs? no hidden bugs?
_whitelogger has joined #m-labs
sb0 has quit [Quit: Leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
d_n|a has quit [Read error: Connection reset by peer]
d_n|a has joined #m-labs
m4ssi has joined #m-labs
sb0 has joined #m-labs
<GitHub-m-labs> [artiq] jordens opened issue #1171: API inconsistency: set_dataset(..., save=True) vs get_dataset(..., archive=True) https://github.com/m-labs/artiq/issues/1171
<GitHub-m-labs> [artiq] jordens commented on issue #1141: This is AD9910-specific. I have seen it as well. And we know that its bigger brother the AD9914 is equally easy to bring into a locked up state. I'd hypothesize that a multi-transfer SPI transcation is interrupted mid-way (due to an underflow or due to bad initialization or due to some other reason) and the AD9910 machinery is driven into a non-recoverable state by subs
hartytp has joined #m-labs
<hartytp> sb0: those attenuators seem fine to me
<hartytp> hmc stuff is usually excellent from an analog perspective, the digital side is a bit crappy, but even they can manage a sr...
<hartytp> out of curiosity, what kind of panels did your urukul v1.3 ship with?
<hartytp> and who did you buy them from?
<GitHub-m-labs> [artiq] hartytp commented on pull request #1170 95217d3: OK, let's do that.... https://github.com/m-labs/artiq/pull/1170#discussion_r223614884
<rjo> hartytp: technosystem, v1.3 panel. i guess you are the first one to get this stuff from creotech.
<rjo> and mine have the clips DNP
<hartytp> rjo: so, nice schroff panel with engraving? are you happy with it? the creotech ones are really nice, but I haven't seen the new technosystem offering
<hartytp> and do you have the emc clips as well?
<hartytp> (i.e. if I buy nominally the same part from TechnoSystem then how different will it actually be?)
<rjo> hartytp: no. same old panel style.
<hartytp> ack.
<hartytp> If you're interested I can post some photos of the new panels
<rjo> the emc clips are not there.
<rjo> please do. what was the price?
<hartytp> they seem nice. really solid, proper emc gaskets etc
<hartytp> sec
<rjo> and who is the contact, what parts do they have?
<rjo> yeah. i use the schroff emc panels already for all other things.
<hartytp> also, the QC seems better. They tested them all quite carefully and then sent most of the first batch back to production team for repair. In contrast, TechnoSystem have sent me a few dud units which I've had to send back
<hartytp> right now they have nothing in stock, but they plan to stock everything in the next 6 months or so
<hartytp> Greg's attitude seems pretty sensible: make sure you give regular business to at least two suppliers to keep the competition up. So, I'm trying to distribute orders a bit. But, want to make sure that the products they ship are identical
<rjo> hartytp: different q: have you tried these: http://www.farnell.com/datasheets/48895.pdf would be nice for Thermostat, UK company even
<hartytp> no
<hartytp> look nice though
<sb0> hartytp: I got urukul v1.3 from technosystem. same panels as before with the film. also I can confirm that the board works after flashing the cpld.
_whitelogger has joined #m-labs
<GitHub-m-labs> [artiq] jordens closed issue #1148: channel numbering for DIO_BNC EEM is wrong https://github.com/m-labs/artiq/issues/1148
<GitHub-m-labs> [artiq] jordens commented on issue #1031: This could be handled in some circumstances by using the DAC power limiter/blanking. Guaranteeing well defined behavior during random bitstream loads, crashes (i.e. guaranteeding well defined outputs during ill-defined situations) is up for sponsoring. https://github.com/m-labs/artiq/issues/1031#issuecomment-428156443
<GitHub-m-labs> [artiq] jordens commented on issue #1166: Given that the behavior differs between channels (where the ramp generator does not differ), this is likely something downstream and not the ramp generator. https://github.com/m-labs/artiq/issues/1166#issuecomment-428156858
kjh_m has joined #m-labs
<GitHub-m-labs> [artiq] jordens commented on issue #1126: This will generally not work. `cound(); ...; self.led0.off()` and `count(); ...; gate_rising()` are guaranteed to see an `RTIOUndeflow` the way it's written. The 135 ms are probably exactly the compiler overhead. https://github.com/m-labs/artiq/issues/1126#issuecomment-428159572
<kjh_m> hi
<GitHub-m-labs> [artiq] jordens commented on issue #1126: ~~This will generally not work. `cound(); ...; self.led0.off()` and `count(); ...; gate_rising()` are guaranteed to see an `RTIOUndeflow` the way it's written. ~~ Scratch that.... https://github.com/m-labs/artiq/issues/1126#issuecomment-428159572
<GitHub-m-labs> [artiq] jordens commented on issue #1126: ~~This will generally not work. `cound(); ...; self.led0.off()` and `count(); ...; gate_rising()` are guaranteed to see an `RTIOUndeflow` the way it's written.~~ Scratch that.... https://github.com/m-labs/artiq/issues/1126#issuecomment-428159572
<rjo> kjh_m: hello
sb0 has quit [Quit: Leaving]
hartytp has quit [Quit: Page closed]
<kjh_m> I was wondering, if there's a way to pass an argument to already running kernel without starting a new experiment (requesting termination etc)? For example, if I have kernel which cycles through DDS frequencies, is there some way to alter frequency step, or delays 'on the run'?
<kjh_m> Or should this be done somehow with a kernel handover?
<rjo> kjh_m: depending on what you mean by "pass an argument" here, just do an rcp from the kernel to the host and have the host get the data from wherever you want.
<rjo> s/rcp/rpc/
<GitHub-m-labs> [artiq] jordens commented on issue #1166: @hartytp to clarify what you were saying:... https://github.com/m-labs/artiq/issues/1166#issuecomment-428170911
rohitksingh_work has quit [Read error: Connection reset by peer]
<kjh_m> right, thanks, that's true
<kjh_m> perhaps I was overthinking it..
sb0 has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<GitHub-m-labs> [artiq] hartytp commented on issue #1166: > Is it known whether or not this happens with SAWG as well?... https://github.com/m-labs/artiq/issues/1166#issuecomment-428218092
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1166: @hartytp Did you try to supply other reference frequencies (100, 125 MHz?). Just as a sanity check. With @jbqubit we had very similar symptoms, which were caused by wrong reference frequency (even though hmc830 locked). Perhaps hmc830 freq isn't set properly?... https://github.com/m-labs/artiq/issues/1166#issuecomment-428222933
rohitksingh has joined #m-labs
<GitHub-m-labs> [artiq] hartytp commented on issue #1166: > @hartytp Did you try to supply other reference frequencies (100, 125 MHz?). Just as a sanity check. With @jbqubit we had very similar symptoms, which were caused by wrong reference frequency (even though hmc830 locked). Perhaps hmc830 freq isn't set properly?... https://github.com/m-labs/artiq/issues/1166#issuecomment-428230099
m4ssi has quit [Remote host closed the connection]
<GitHub-m-labs> [artiq] connorgoham opened issue #1172: Kasli ignores rtio_clock e https://github.com/m-labs/artiq/issues/1172
connorgoham has joined #m-labs
connorgoham has left #m-labs [#m-labs]
connorgoham has joined #m-labs
<connorgoham> Need any more info on the rtio_clock issue I just posted?
mumptai has joined #m-labs
<GitHub-m-labs> [artiq] jordens commented on issue #1172: It uses its internal oscillator. Kasli clocking is set in the target definition. The `rtio_clock` config entry is only used on kc705 (see the manual). https://github.com/m-labs/artiq/issues/1172#issuecomment-428274585
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
jbqubit has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<GitHub-m-labs> [artiq] jbqubit commented on issue #1172: OK. Current doc is confusing. Please move ```rtio_clock``` config instructions from [here](http://m-labs.hk/artiq/manual-master/installing.html#configuring-the-core-device) to [here](http://m-labs.hk/artiq/manual-master/core_device.html?highlight=kc705#clocking). ... https://github.com/m-labs/artiq/issues/1172#issuecomment-428301748
<GitHub-m-labs> [artiq] hartytp commented on issue #1172: > `self.config["SI5324_EXT_REF"] = None`... https://github.com/m-labs/artiq/issues/1172#issuecomment-428302597
<GitHub-m-labs> [artiq] jbqubit commented on issue #1172: I gather this is creating a key with empty value. Presence or absence of key as a way of toggling a bool is opaque. The only reference I can find to ```SI5324_EXT_REF``` in source relates to Sayma. https://github.com/m-labs/artiq/issues/1172#issuecomment-428313405
<GitHub-m-labs> [artiq] hartytp commented on issue #1172: To explain more (and @jordens should correct me if I'm wrong since it's been a while since I thought about this):... https://github.com/m-labs/artiq/issues/1172#issuecomment-428313507
<GitHub-m-labs> [artiq] hartytp commented on issue #1172: > I gather this is creating a key with empty value. Presence or absence of key as a way of toggling a bool is opaque. The only reference I can find to SI5324_EXT_REF in source relates to Sayma.... https://github.com/m-labs/artiq/issues/1172#issuecomment-428314549
mumptai has quit [Quit: Verlassend]
<GitHub-m-labs> [artiq] jbqubit commented on issue #1172: >> each entry in self.config leads to a config option in the rust sources... https://github.com/m-labs/artiq/issues/1172#issuecomment-428333065
<GitHub-m-labs> [artiq] jordens commented on issue #1172: @hartytp almost. IIRC there is no fallback. It either does one or the other. Automatic fallback was rejected because of presumed user confusion. It might also be worse noise-wise or even inaccurate ... https://github.com/m-labs/artiq/issues/1172#issuecomment-428338296
<GitHub-m-labs> [migen] whitequark pushed 1 new commit to master: https://github.com/m-labs/migen/commit/076ec0dd63162d34f293a9cb93804d435740d053
<GitHub-m-labs> migen/master 076ec0d whitequark: fhdl.visit: fix nondeterminism in visit_Case....
<bb-m-labs> build #320 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/320
<GitHub-m-labs> [artiq] jordens commented on issue #1172: The si5324 fallback mode also won't work because that needs the other input. But a one shot runtime fallback could be done. https://github.com/m-labs/artiq/issues/1172#issuecomment-428343655
<GitHub-m-labs> [artiq] hartytp commented on issue #1172: > @hartytp almost. IIRC there is no fallback. It either does one or the other. ... https://github.com/m-labs/artiq/issues/1172#issuecomment-428344704
<GitHub-m-labs> [artiq] hartytp commented on issue #1170: updated... https://github.com/m-labs/artiq/pull/1170#issuecomment-428356552
mumptai has joined #m-labs
mumptai has quit [Client Quit]
<GitHub-m-labs> [artiq] jbqubit opened issue #1173: urukul.set() touches timeline cursor https://github.com/m-labs/artiq/issues/1173
<GitHub-m-labs> [artiq] jbqubit opened issue #1174: with parallel urukul.set() broken https://github.com/m-labs/artiq/issues/1174
jbqubit has quit [Ping timeout: 256 seconds]