<hartytp>
sb0: out of curiosity, did you have more problems with the 1v8 thing? Did the extra cooling make a difference (even if it didn't eliminate it) or was it just a red herring?
<sb0>
hartytp, hard to tell. one would need proper statistical analysis to answer this question.
<hartytp>
okay, that sounds like if it did make a difference, it wasn't a large one. Oh well...time to wait for Greg's better diagnostics then.
<sb0>
I'm also getting a uTCA crate soon, with powerful fans...
<hartytp>
nice! That's good. One of Greg's 1U ones, or a Schroff/etc one?
<sb0>
the big ones that can take several boards (will use for drtio)
<hartytp>
The one we have has fans that sounds like they were specified for trans-atlantic flight, so I'm guessing the cooling power is quite high
<sb0>
yes, this kind of crate
<hartytp>
the NAT one with the LLRFBP?
<sb0>
should be NAT, but not sure what model
<sb0>
Joe ordered it
<hartytp>
ack, same one then. It's a bit of a beast, but good to know we'll all be using the same model and chasing the same issues.
cedric has quit [Remote host closed the connection]
<sb0>
hartytp: oh and by the way, we can make the ethernet non-cc pins a complete non-issue by putting the PHY in DTE mode
<sb0>
we may actually want to do that, since then the issue doesn't have to be corrected on the board, and a single bitstream can be kept. but that would limit Ethernet speed to 100Mbps.
<sb0>
we could fix it on Metlino to keep the 1Gbps option open
<sb0>
whitequark, ping
<whitequark>
sb0: pong
<sb0>
whitequark, I'm finishing the report right now, can you send me something?
<sb0>
rjo, why is the New Focus 8742 driver outside the artiq tree?
<sb0>
we already have drivers for third-party hardware e.g. lda, thorlabs motors, etc. in-tree, so why is this one an exception?
<whitequark>
rjo: I have not tried the new bootloader with a cold start of kc705 as it did not occur to me
<whitequark>
what sort of bugs would you expect?
<sb0>
whitequark, see issue
<whitequark>
sb0: there's 46 emails in my inbox since yesterday, *which* issue?
<sb0>
there's definitely more than a thermal issue with the power supply. 1v8 just failed with a cold board.
<sb0>
"simple user error" eh
<whitequark>
sb0: SC is a trash fire... they just rejected a telegraphic transwer with "Reject reason: We are unable to process your request."
<whitequark>
something like two weeks in.
<whitequark>
this is so absurdly bad it's not even funny
<sb0>
rjo, we should definitely configure the attenuator on allaki. the noise level is quite high, and depends on electrical noise around the building, e.g. switching on all fluorescent lights in the room brings it into the 10's of mV
<sb0>
hopefully the uTCA crate shielding will improve that
<rjo>
sb0: having the drivers in-tree is a bad idea in most cases (and in this one).
rohitksingh_work has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
mumptai has quit [Remote host closed the connection]
<sb0>
rjo, so should lda etc. be removed?
<sb0>
what do we keep in-tree? own hardware?
<rjo>
sb0: imho, drivers that are useful without artiq (and where you can expect someone doesn't want to pull in all the artiq dependencies) or drivers that pull in other dependencies (hidapi for lda or libusb/pyusb for newfocus8742) can well be separate.
<sb0>
ok
<rjo>
it also decouples development. people can then pin the driver version in their environment independently of the artiq version. luckily the atriq controller api looks stable.
<rjo>
(i may have advocated the other position a few years back but that was before we had a reasonable packaging and testing infrastructure)
<sb0>
whitequark, why is the log level set late in the runtime? don't we want to debug startup?
<rjo>
sb0: walk me through the sayma testing setup. how do i load the rtm fpga?
<sb0>
rjo, look at /home/sb/load_rtm
<sb0>
and in sayma_new.cfg the ftdi_location lines correspond to the respective saymas
<sb0>
UARTs are /dev/ttyUSB_saymaX_Y
hartytp has joined #m-labs
<sb0>
Y=0 main UART (bootloader/runtime), Y=1 secondary UART (RTM or microscope), Y=3 MMC UART
<hartytp>
sob: re "simple user error" okay, that was a bit harsh (although, IIRC, I did caveat it with "if that really is what this is" or similar). Apologies. But, as I said, the frustrations I was venting weren't just from that.
<hartytp>
sb0
<hartytp>
(fat fingers in the am)
<rjo>
sb0: ack.
<hartytp>
re ethernet: personally, I'm not worried about maintaining compatibility with Sayma v1.0 and would prefer to open the option of Gbps ethernet in Sayma v2.0 by fixing the cc pin
<hartytp>
Looks like we're going to make plenty of other changes to Sayma v1.0 like adding the extra LVDS links between the AMC and RTM, so it's better (IMHO) just to obsolete the v1.0 boards.
<sb0>
well, we'd have to discuss that with people who have 1.0 boards
<hartytp>
(well, not "plenty" but at least one or two other changes). Better just to obsolete the prototypes and focus on getting a really good v2.0 than to make compromises in all future versions of Sayma to keep the 10 v1.0 boards we have working from the same bitstream
<hartytp>
sb0: ack. Ultimately it's Joe's decision since he paid for all of this.
<hartytp>
anyway, we can worry about this once we've finished bug hunting/fixing in v1.0
<GitHub184>
[artiq] whitequark commented on issue #886: > The old SDRAM code supported Spartan 6 and Artiz 7 memory PHYs that have hardcoded write leveling through the DQS clocks. The new rust sdram init code breaks this (and therefore Kasli).... https://github.com/m-labs/artiq/issues/886#issuecomment-355353417
<GitHub150>
[artiq] jonaskeller commented on issue #874: I tried reproducing the error today. In 3.1 py_35+git3ba82cf1, only the duplicate TCP packets appeared, but it never entered the ACK loop. So maybe this is already fixed.... https://github.com/m-labs/artiq/issues/874#issuecomment-355432744