<GitHub135>
[artiq] jonaskeller commented on issue #902: Below is the backtrace for one instance of it crashing (this is with 3.2+8.gaa64b8ad). Since I wasn't sure what causes it and was working on something else, I just let one of our experiments run in a loop - it's far from minimal, I'm afraid. If you need me to test something simpler, please let me know.... https://github.com/m-labs/artiq/issues/902#issuecomment-3614337
<GitHub114>
[artiq] jonaskeller commented on issue #902: Below is the backtrace for one instance of it crashing (this is with 3.2+8.gaa64b8ad). Since I wasn't sure what causes it and was working on something else, I just let one of our experiments run in a loop - it's far from minimal, I'm afraid. If you need me to test something simpler, please let me know.... https://github.com/m-labs/artiq/issues/902#issuecomment-3614337
<GitHub44>
[artiq] jonaskeller commented on issue #902: Below is the backtrace for one instance of it crashing. Since I wasn't sure what causes it and was working on something else, I just let one of our experiments run in a loop - it's far from minimal, I'm afraid. If you need me to test something simpler, please let me know.... https://github.com/m-labs/artiq/issues/902#issuecomment-361433786
<GitHub98>
[artiq] whitequark commented on issue #902: That... makes no sense. The only way to interpret that backtrace is that a packet arrived, passed the length verification in `smoltcp::Ipv4Packet::new_checked`, and subsequently failed the exact same length check it in `smoltcp::Ipv4Packet::payload()`. https://github.com/m-labs/artiq/issues/902#issuecomment-361454230
<sb0>
_florent_, thanks. I suppose you know about microscope.
<sb0>
there are examples in the sayma port that I used to debug drtio
<sb0>
whitequark, openocd is now opening a gdb socket while flashing a board
<sb0>
this prevents two boards from being flashed at the same time
<sb0>
did you change something in artiq_flash that could have caused that?
<GitHub22>
[artiq] sbourdeauducq commented on issue #652: Is there a package in particular you are worried about? Otherwise, the whole Anaconda distribution has been Python 3.6 by default for a while, and I don't expect problems other than the usual yak-shaving. https://github.com/m-labs/artiq/issues/652#issuecomment-361461333
<GitHub100>
[artiq] sbourdeauducq commented on issue #908: Here is everything I built from the current master (with RTM bridge, RTIO and other things disabled to save compilation and RTM yak-shaving time):... https://github.com/m-labs/artiq/issues/908#issuecomment-361462516
<whitequark>
sb0: are you sure this wasn't always the case?
<GitHub146>
[artiq] jordens commented on issue #652: The situation has reversed from what it was. Now 3.6 is eminent and sticking with 3.5 will ultimately lead to what @sbourdeauducq has described. https://github.com/m-labs/artiq/issues/652#issuecomment-361500992
<sb0>
the peak for 2 is slightly visible at the right, and very clear when changing contrast
<sb0>
also rjo what was your concern about operating a RGA at a variable frequency? afaict that works just fine.
<sb0>
x axis on this plot is 1/f^2
<rjo>
depends on what you want to achieve here. can you reliably and reproducibly calibrate the mass axis without reference peaks out to non-trivial values (like 100)? can you reliably do scans through the tips? or is this a proof of concept? (which?)
<sb0>
the 1 and 2 peaks are easy to discern, even though they are only 1 amu apart. I have a pretty wide margin to hit the tips...
<sb0>
and for scanning into high amus, that depends on the precision of my DDS and reference clock, which can be pretty good with modern parts
<rjo>
you can play with the voltages and suppress stimulated desorption vs actual gas
<sb0>
right now it's a cheapo DDS generator and a cheapo programmable DC power supply with a lot of noise and ~150mV (!) absolute imprecision, and the result is quite good...
<rjo>
that's not your problem.
<rjo>
distinguishing 1 and 2 is also not your problem.
<sb0>
so what is the problem then? is there something that is not limited by the RF frequency precision?
<rjo>
distinguishing 44 and 45 or 98 and 99 will be more interesting. doing so reliably and stably would be interesting. if the power consumption was comparable (at the same specifications) to a regular RGA
<rjo>
is your rf rod voltage constant up to amu 100 or 300?
<sb0>
if my scope probe is correctly calibrated, yes.
<sb0>
according to ltspice simulations, yes.
<sb0>
even higher than 300
<sb0>
and if that fails for some reason, I think stabilizing with a simple rectifier (assuming constant diode forward drop) is likely to work
<rjo>
you'll have to show it.
<sb0>
well, the regular RGA drivers actually have a worse amplitude stabilization issue
<sb0>
they something that gives <1% precision from a few volts of RF to 3kV
<sb0>
*need
<rjo>
you need the same precision but now you jave to keep it across frequency
<sb0>
so it's not a simple rectifier inside, but a charge pump with a precision high voltage capacitor
<sb0>
yes, but I only have to stabilize it to a constant value, not sweep it, i.e. diode forward voltages aren't an issue if they remain constant
<sb0>
also I'm only dealing with <200V, not 3kV
<rjo>
you are stabilizing the diode forward voltages to 1%? and there are no inductive or capacitive parasitics that make this all frequency-dependent?
<sb0>
well, let me see if that diode circuit is needed at all anyway
<rjo>
well yeah. this is all he says she says until you do it and e.g. name the krypton isotopes without (re)-calibrating your amu scale using those very isotopes.
<sb0>
and by the way, in such a circuit diode forward voltages do not need to be stabilized to 1%
<sb0>
a variation of the ~0.7V forward drop of a most basic diode on a 100V rectified voltage isn't much
<sb0>
diode capacitance doesn't affect the rectifier output, and inductance should be negligible at those frequencies. the only problem I see is diode recovery time, so one would need a relatively fast diode so it can be neglected
<GitHub17>
[artiq] sbourdeauducq commented on issue #908: Good. You do however seem to get a large number of Ethernet RX corrupted packets (preamble errors). Is the PHY correctly set in RGMII mode? You can change the RX phase as well by using this script command instead: ``set_property CLKOUT0_PHASE <phase> [get_cells crg_ethrx_mmcm]`` https://github.com/m-labs/artiq/issues/908#issuecomment-361631972
<GitHub78>
[artiq] sbourdeauducq commented on issue #908: Good. You do however seem to get a large number of Ethernet RX corrupted packets (preamble errors). Is the PHY correctly set in RGMII mode? Does this happen for every packet? You can change the RX phase as well by using this script command instead: ``set_property CLKOUT0_PHASE <phase> [get_cells crg_ethrx_mmcm]`` https://github.com/m-labs/artiq/issues/908#issuecomment
<GitHub21>
[artiq] dhslichter commented on issue #888: @philipkent ack. We have had similar issues with our sideband cooling and went to deeper output FIFOs as a result. Let's discuss offline and run some tests to come up with a good resource allocation. https://github.com/m-labs/artiq/issues/888#issuecomment-361667660