<rjo>
whitequark: the Cargo.lock's should either be added to the repository or gitignored.
<rjo>
whitequark: more accurately: carg should either always update the file and then it should be ignored. or it should not automatically update the file and then it should be in the repo.
Gurty has quit [Ping timeout: 240 seconds]
Gurty has joined #m-labs
sandeepkr has quit [Read error: Connection reset by peer]
sandeepkr has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
sb0 has joined #m-labs
mumptai has joined #m-labs
sandeepkr_ has joined #m-labs
kuldeep_ has joined #m-labs
sandeepkr has quit [Ping timeout: 255 seconds]
kuldeep has quit [Ping timeout: 260 seconds]
jbqubit has joined #m-labs
<jbqubit>
rjo: "I don't know which of the changes made the difference. But it looks ok now from my end. You should see a signal on channel 1." I see 4 LEDs on KC705 pulsing at about 1 Hz. No output on DAC.
<rjo>
where are you measuring?
<rjo>
jbqubit: ^
<jbqubit>
I checked all four outputs. Now connected to DAC0 and DAC1
<jbqubit>
I rebooted kc705.
<rjo>
jbqubit: J17?
<jbqubit>
Yes
<rjo>
jbqubit: LED state (all eight, be precise), and what do you see on ttl_sma?
<rjo>
(user_sma_gpio_n)
<jbqubit>
user_sma_gpio_n is 0V (1 us/div on scope)
<jbqubit>
012345678 is 0011fff where f is ~1 Hz flash
<jbqubit>
12345678 is 0011fff where f is ~1 Hz flash
<rjo>
you said you see four leds flashing. what now?
<jbqubit>
12345678 is 0011ffff where f is ~1 Hz flash
<jbqubit>
They flash on and off in unison.
<GitHub137>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vME1L
<GitHub137>
artiq/master 7c699e2 Sebastien Bourdeauducq: drtio: add FIFO space request count debug API
<rjo>
jbqubit: check whether you messed up things by installing things with setup.py.
<rjo>
jbqubit: oh. please always check with the original script first before you edit things.
<jbqubit>
I did check with original script. And saw nothing triggering on DAC0.
<sb0>
rjo, are you using any of the HKG KC705s?
<rjo>
"triggering"?
<rjo>
sb0: no.
<rjo>
jbqubit: does the original script give you an exception?
<jbqubit>
both version compile without exception
<jbqubit>
This might be the problem...
<jbqubit>
$ artiq_corelog WARNING:artiq.coredevice.comm_generic:Mismatch between gateware (3.0.dev+684.g7af152e) and software (3.0.dev+687.g394ffd8.dirty) versions
<rjo>
dude no. you posted a log with an exception.
<jbqubit>
I've rolled back to version of artiq that matches my installed gateware.
<jbqubit>
and ran setup.py develop --user
<jbqubit>
As regards "jbqubit: does the original script give you an exception?" I thought you were asking about the artiq_compile step.
<jbqubit>
I now see that there is a RTIOCollision.
<jbqubit>
I've resolved RTIOCollision. Now I see waveform.
<sb0>
the DAC waveform?
<jbqubit>
Yes. I see the DAC waveform.
<sb0>
great!
<sb0>
out of curiousity, what was causing the JESD ready timeout?
<jbqubit>
I don't yet know what was causing the JESD ready timeout. Changes vs when SB and Joe were debugging things are a) lower amplitude clock b) different prototype board. I'm checking now to see if I can revert.
<sb0>
so, a random selection of 0.0213% of the drtio packets are truncated somehow, apparently at the transmitter. this is what is causing most of the symptoms it seems...
<jbqubit>
sb0: Just confirmed problem was too high clock power on J1. +11 dBm produces behavior you and I saw. Today I reduced power to +6 dBm and it works.
<jbqubit>
I see the too high clock power reproduce.
<sb0>
jbqubit, good
hozer has joined #m-labs
mumptai has quit [Quit: Verlassend]
<GitHub31>
[artiq] jbqubit opened issue #653: cannot unify numpy.int? with float https://git.io/vMuq0