<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #998: With the same RTIO sequence that corresponds to one SAWG reset (channels and timestamps shifted), Kasli behaves itself and correctly reports the underflow.... https://github.com/m-labs/artiq/issues/998#issuecomment-393768841
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #998: With the same RTIO sequence that corresponds to one SAWG reset (channels and timestamps shifted), Kasli behaves itself and correctly reports the sequence error.... https://github.com/m-labs/artiq/issues/998#issuecomment-393768841
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #998: With the same RTIO sequence that corresponds to one SAWG reset (channels and timestamps shifted), Kasli behaves itself and correctly reports the sequence error.... https://github.com/m-labs/artiq/issues/998#issuecomment-393768841
<GitHub-m-labs>
[artiq] sbourdeauducq opened issue #1038: sawg.reset() writes more zeros at the same time than there are SED lanes on Sayma https://github.com/m-labs/artiq/issues/1038
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: As expected, just a silly code bug. With `t_rtt = 15 + 4` and a 1m SCSI + 2xVHDCI_carriers, this looks fine. e.g. rms noise hasn't changed. https://github.com/m-labs/artiq/issues/788#issuecomment-393829048
<GitHub-m-labs>
artiq/master 87d3ac9 Robert Jordens: suservo: swap transfer function parametrization...
<GitHub-m-labs>
[artiq] jordens commented on issue #788: Nice. I wonder whether the LVDS return current path (one pin plus shield) on the VHDCI cables will become problematic at some point. Especially given the usually separate power supplies. https://github.com/m-labs/artiq/issues/788#issuecomment-393830097
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: Some more data on this. I'm reading the ADC at 1 sample per 4us (nb plot x axis incorrectly uses 3.5us sample time) and plotting the ADC (not servo x) code with the mean subtracted. I'm running with 350mV at Sampler's input, G=1 no termination.... https://github.com/m-labs/artiq/issues/788#issuecomment-393842182
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: Finally, same as before (10m SCSI cable, same PSU for everything) but 50R terminate the input and increase the gain to 100. Set-point is not 35mV:... https://github.com/m-labs/artiq/issues/788#issuecomment-393848818
<GitHub-m-labs>
[artiq] hartytp commented on issue #788: I would have expected any major SI issues to show up in this testing, so tentatively I'd conclude that -- modulo standard grounding issues -- remote EEMs work fine. cool.... https://github.com/m-labs/artiq/issues/788#issuecomment-393849058
<GitHub-m-labs>
[artiq] jordens commented on issue #1022: The steps are expected. This is a sampled system. The sawtooth generators run at lower sample rate and have correspondingly larger steps. The distortion on the sawtooths after the jump is unexpected.... https://github.com/m-labs/artiq/issues/1022#issuecomment-393850422
<hartytp>
sb0, _florent_: my Sayma just arrived back.
<hartytp>
how do you want me to prioritize things/what do you want me to look at first?
<sb0>
hartytp, yes, please look at the JESD sawtooth and generally that the DAC is correctly reproducing the samples that the FPGA sends into the JESD core
<rjo>
it's consistent with all those issues having a common cause in jesd alignment, bad cdc, bad sync, etc. and filing more issues about sawg is unlikely to help.
<sb0>
does that explain why frequency0.set() works but frequency1.set() doesn't?
<sb0>
is the sawg producing slightly different output?
<rjo>
sure.
<hartytp>
okay, anything else you want me to look at while I'm at it?
<sb0>
whitequark, some of those cables were hacked together by florent, and i'd expect them to break
<hartytp>
ch 3:https://pasteboard.co/HnT4RtI.jpg
<hartytp>
the proper ($$$) SMP cables I bought are pretty sturdy, and removing them is fine but requires some care
<whitequark>
sb0: ah ok that explains a few things
<whitequark>
they seem to work if you fit them back together after they fall apart but not always, which i think is one reason i might have had so much trouble with allaki
<sb0>
there are some cheap smp cables on taobao. might or might not be good. sometimes chinese rf cables and connectors are good despite the low price and origin.
<sb0>
the bullets are nowhere to be found, on the other hand
<whitequark>
sb0: someone linked me cheap bullets on twitter
<whitequark>
well not cheap exactly but cheaper than the ones you used, sec
<whitequark>
wow, the extractor tool costs 3000 HKD
<sb0>
after interacting with machine shops, it's more understandable why low-volume tools like this are so expensive
<whitequark>
I don't know what is wrong with chinese machine shops, I never had any cost or delay issues with low volume in russia as an individual
<hartytp>
okay, so if that's all the no-sawg tests you want I'll look at florent's binaries with the HS ser-wb
<sb0>
well US and German ones weren't much better IME
<whitequark>
yes, US ones are absurdly overpriced
<whitequark>
with machinist salaries of $100/hr upwards that's not surprising
<sb0>
hartytp, there's the sequence error
<hartytp>
ack, will do that with florent's binaries
<whitequark>
did I show you the chamber I got made for the induction heater? that entire chamber was less than 2hr of machinist time in the US, including materials
<hartytp_>
I consistently get errors on the RTM to AMC link test
<hartytp_>
that's before the HMC830/7043 are configured
<hartytp_>
(and FWIW, errors seem unchanged when I remove the 100MHz clock)
<hartytp_>
sb0: building with SAWG to do the test you wanted
<sb0>
hartytp_, with SAWG I already know the result
<sb0>
and it seems to be reproducible
<hartytp_>
okay for me to do it with an idle kernel?
<sb0>
I had seen the issue with a startup kernel
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1022: Those wiggles look like they could be coming from some incorrect interleaving from the CORDICs -- if there was an incorrect phase offset between the start of each interleaved CORDIC, you could get something that looked like this instead of a clean sine wave. https://github.com/m-labs/artiq/issues/1022#issuecomment-393905496
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1022: If the JESD is incorrectly serializing samples (out of order) this would also produce the effect I was describing, and looking at @hartytp's scope trace it does seem like this might be the case. The sawtooth is a lot more jagged-looking than one would expect on the smooth part (the jaggedness is substantially larger than the spec'ed DNL, to my eye). https://gith
<hartytp_>
sb0: dumb question, but I shouldn't need to flash the FPGA, right? loading should be enough.
<sb0>
hartytp_, yes, in theory it behaves the same when it's loaded from JTAG or the flash.
<hartytp_>
okay, well when I tested florent's gateware before, I had my no-sawg, slow ser-wb flashed
<hartytp_>
I then loaded his gw, and consistently got lots of RTM->AMC link errors
<hartytp_>
having flashed his binaries, I can't reproduce that
<GitHub-m-labs>
artiq/master 62deffa Robert Jordens: opticlock: fix core device name
<GitHub-m-labs>
artiq/master f50aef1 Robert Jordens: suservo: extract boilerplate...
<hartytp_>
sb0: I've tried to do your test using the current master and no-sawg. atm it's either getting stuck initialzing the ser-wb link or with the SERDES PLL lock timeout
<hartytp_>
either way, I'm not getting far enough to do the test
<hartytp_>
sigh
<sb0>
so it just started breaking like that? did you change anything from when you posted the scope screenshots?
<hartytp_>
nope
<sb0>
yeah, I also had vivado segfault on me at some point, when building without sawg ...
<hartytp_>
the serwb issues were happening before some fraction of the time
<hartytp_>
maybe they're worse now, but I don't have the statistics to be sure
<hartytp_>
the SERDES PLL issue is new
<hartytp_>
same gw/fw
<hartytp_>
nothing else has changed afaict
<hartytp_>
so odd. maybe something thermal?
<hartytp_>
need to go now, but will try to get back to it on sunday. maybe being powered down for a while will make a difference
<hartytp_>
_florent_ thoughts?
hartytp has quit [Quit: Page closed]
<_florent_>
hartytp_: sorry i was away
<_florent_>
hartytp_: 100% sure that the binaries i just sent you are the one i used to the reboot tests (>800 reboots during a full day)
hartytp_ has quit [Ping timeout: 260 seconds]
<_florent_>
hartytp: i suggest checking the hmc830 and hmc7043 clocks with a scope
<_florent_>
hartytp: also it could be interesting to test with a 1.2Ghz clock connected to DAC clk and bypass the hmc830
<Omid>
Will create new Issue. Now seeing this repeat with different symptoms than #1026. Random characters printed on URART, kernel freeze but no kernel panic.
<GitHub157>
[smoltcp] barskern commented on issue #224: @pothos Do you think you would be able to write a test which mimics this behavior? Or explain me on how this managed to happen so that I could write a test?... https://github.com/m-labs/smoltcp/issues/224#issuecomment-394036403
<GitHub77>
[smoltcp] barskern commented on issue #224: @pothos Do you think you would be able to write a test which mimics this behavior? Or explain me how it happened so that I could write a test?... https://github.com/m-labs/smoltcp/issues/224#issuecomment-394036403