<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?
<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
<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.
<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.
<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]
<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
<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: > 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
<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