<GitHub163>
[artiq] whitequark commented on issue #803: The provided code is not enough to unambiguously construct a reproducing example. I've modified it as follows so I can run it with `artiq_run`:... https://github.com/m-labs/artiq/issues/803#issuecomment-317620802
<sb0>
any idea what those fine diagonal lines are?
<sb0>
they are away for the Mathieu stability regions and they don't impact normal use, but I'm curious
<sb0>
*away from
<sb0>
X axis is RF, Y is DC as you can probably guess.
<sb0>
the current on them is very low, for the top line, which is brighter, it peaks at about 3pA
<sb0>
the RGA only has a faraday cup and no electron multiplier
<sb0>
the bottom ones peak at 1pA or less
<sb0>
(the ammeter is a transimpedance amplifier with a LMP7721 and 1Gohm resistor. pretty neat op-amp)
<rjo>
sb0: i'd go for a log TIA right away.
<rjo>
sb0: those lines could be some plasma/plasma resonances going on.
<sb0>
on this prototype I have reed relays that switch smaller resistors when it saturates (I'm using the ionpak PCB). but yes, I'm considering that. the scan is extremely slow (this picture was taken over several days)
<sb0>
what's a plasma/plasma resonance?
<rjo>
ah. there are also stability lines 2d mathieu out there. so it's regular mathieu stuff
<sb0>
ah. I didn't find them mentioned in the papers I read
<rjo>
sb0: at higher pressures (where you have more collisions/space charge) you get much more complicated dynamics.
<sb0>
I'm at ~10-8
<rjo>
there's no plasma physics down there.
<rjo>
for the log TIA, you can either build that discrete or for a few bucks get some 10-orders-of-magnitude integrated things like the ADL5304, which also makes for really nice photodetectors https://github.com/jordens/logpd
<sb0>
yes, I was already planning to use the ADL5304
<sb0>
ah, gEDA
<sb0>
do you prefer it over kicad?
<rjo>
until kicad receives a drastic cleanup and lots of UI love, yes.
<sb0>
what kind of fluorescence can I expect by shining a diode laser with the minimum/no amount of wavelength stabilization into a large cloud of trapped ions?
<sb0>
or their high-power variants, which are still many orders of magnitude cheaper than any toptica device
<rjo>
assuming you have (a) enough intensity over the line width, (b) a NA~0.3 lens and usual optics/PMT, (c) polarisation/magnetic field so that you are pumping into a dark state, you can expect 100k/s per ion.
<rjo>
saturation intensity at the line center is (OOM, IIRC) ~mW/cm²
<sb0>
pumping into a dark state?
<sb0>
did you mean *not* pumping into a dark state?
<sb0>
Ca+ also needs 866nm repumping iirc, when cooling...
<rjo>
yes. not pumping
<rjo>
yes. needs repumper and cleaner for low lying D state.
<sb0>
whitequark, instead of the very expensive, high-distortion and high-power-dissipation apex devices, have you considered a simple cascode circuit with BJTs?
<whitequark>
I think I asked you about cascode ladders, didn't I?
<sb0>
you briefly mentioned that
<whitequark>
but at MHz frequencies that would also dissipate a lot unless I'm missing something
<sb0>
yeah I think the voltage doesn't need to be that high
<sb0>
and the capacitance is <50pF
<sb0>
voltage ~100V
<sb0>
a load resistor of 1k dissipates only 100mW ...
<sb0>
the apex garbage dissipates 2W at 100V for quiescent power only ...
<rooi-oog>
Hello, I've a silly question. I have a lot of GDDR memory from my old video card thus can I use it with HPDMC as DDR memory without G extensions? Thanks
<whitequark>
well yes, the apex chip is a terrible disappointment
<GitHub96>
[artiq] sbourdeauducq commented on issue #779: But this description you wrote isn't good, and dealing with this is not a priority. Please use the existing APIs to build your own KC705+EEM designs, as I explained in the other issue you opened. https://github.com/m-labs/artiq/issues/779#issuecomment-317770028
<sb0>
rooi-oog, not sure if FPGA IOs support GDDR standards.
<sb0>
you might be able to get it to work with some hacks. but it'll be difficult.
<rooi-oog>
sb0, I've read GDDR uses SSTL_2 standart so it's totally supports by fpga
<sb0>
whitequark, yeah, except for filament lifetime, it's not much better than a vacuum tube :)
<sb0>
not even the size is better, since it requires a large heatsink
<sb0>
and vacuum tubes are cheaper
<rooi-oog>
sb0, what kind of hacks are talking about?
<sb0>
rooi-oog, if it's a supported I/O standard then no hacks are needed.
<sb0>
things like tweaking termination/bias resistors, or undocumented IOB settings.
<sb0>
rooi-oog, are you going to make a custom PCB? GDDR is BGA and nontrivial to route
<sb0>
also, removing it from your video card and onto your new PCB might not be worth the effort
<rooi-oog>
I've K4D551638 it tsop-66. very comfortable for custom pcb
<sb0>
ah, old stuff
<rooi-oog>
sb0, it's first generation of GDDR. I found it on radeon X700
<sb0>
still annoying to remove. why not order new DDR chips?
<_florent_>
sb0: I haven't done extensive tests but it seems to work fine
<rooi-oog>
sb0, you are absolutely right. GND not VCC. my mistake. Thank you
<sb0>
_florent_, cool :)
<sb0>
_florent_, i'd break down phy.py into smaller files
<sb0>
and not hardcode AMC/RTM names into it. this code is not specific to microTCA devices.
<sb0>
maybe initiator/target
<_florent_>
sb0: ok I'll do that
<_florent_>
sb0: do you want I integrate that in artiq or one of you will do it?
<sb0>
I'll do it
<_florent_>
sb0: ok thanks
<sb0>
do you need that soon to continue with the HMC programming?
<sb0>
well, i guess you can just load something into the Artix-7 alone
<_florent_>
sb0: no, I can continue working in my repository
<_florent_>
sb0: I have 2 week off after this week, what's the priority for you?
<sb0>
_florent_, clocking and then get the JESD204 to work
<sb0>
so that Greg can validate the RTM boards and produce the rest.
<sb0>
well, only JESD really, but this requires clocking
<sb0>
rooi-oog, so what is your plan with the FPGA?
<_florent_>
sb0: ok I'll see if I can do that
<sb0>
_florent_, please try your best. this is blocking the manufacturing of the remaining RTM boards which are very late already.
<rooi-oog>
sb0, I'm doing the order. Some kind of HDMI player. I need to read sequence of images from SD card and display them through HDMI. Just now I make a prototype.
<sb0>
_florent_, btw what do you use for JTAG on the boards?
<rooi-oog>
sb0, I going to use your vgafb core too :-D
<sb0>
rooi-oog, HDMI will use lots of memory bandwidth
<_florent_>
sb0: HS2 & Vivado script
<rooi-oog>
1024*768 @ 50Mhz
<sb0>
_florent_, the built-in "HS2" or some other cable you have?
<_florent_>
sb0: a cable I have
<sb0>
rooi-oog, you may also want to look at the migen/misoc stuff
<sb0>
though HPDMC might actually be better for your use case.
<sb0>
_florent_, why have a special synchronization pattern instead of using the 8b10b commas designed for this purpose?
<sb0>
_florent_, also, scrambling (at least after the link is established) would be desirable
<sb0>
there is scrambler code in drtio that you can recycle, though it is relatively complicated (earlier versions in the git history were simpler)
<rooi-oog>
sb0, I only have altera dev board thus I had to convert xilinx primitives. Plus I'll use GDDR instead of DDR so I'm wondering if will that fly off?
<_florent_>
sb0: ok I'll improve that.
<sb0>
_florent_, I don't really get what the crossbar is for
<GitHub30>
[artiq] whitequark commented on issue #804: This is basically expected because of Python's dynamic typing. @sbourdeauducq, can we say that only large numpy arrays will be compiled quickly? https://github.com/m-labs/artiq/issues/804#issuecomment-317800199
<GitHub28>
[artiq] sbourdeauducq commented on issue #804: We can do better than that. Checking that all the elements in that array have the same type takes 36ms on my slow Intel Atom computer.... https://github.com/m-labs/artiq/issues/804#issuecomment-317803441
<larsc>
sb0: how would you go about doing comma alignment in fabric (apart from probabilistic), just a mux for each and then rotate through it until you hit a match?
<GitHub121>
[artiq] whitequark commented on issue #804: The numpy array type inference being slow is a bug, the Python array type inference being slow is more or less by design. I'll think about what I can do. https://github.com/m-labs/artiq/issues/804#issuecomment-317813929
<larsc>
ok, thanks
<sb0>
if your serdes has a "bitslip" feature, you can use that too
<larsc>
the altera hard pcs only runs up to 9Gbits/s, that's a bit too slow
<larsc>
it seems the bitslip is also speed limited
rooi-oog has left #m-labs [#m-labs]
<larsc>
hm, there seems to be a so called clk_slip features, but that shifts by two bit
<rjo>
sb0: ecdl + ta likely
<rjo>
sb0: maybe even just dl + ta.
froggytoad has joined #m-labs
[florian] has quit [Ping timeout: 260 seconds]
<GitHub86>
[artiq] llopez32 commented on issue #767: We are able to connect a Ubuntu desktop (IP: 192.168.0.3) and a Windows laptop (IP: 192.168.0.2), so it should be aware of the route. Using the same router and Ethernet cables, the desktop can ping the board but a socket error is still thrown while trying to run the script. https://github.com/m-labs/artiq/issues/767#issuecomment-317840977
[florian] has joined #m-labs
[florian] has joined #m-labs
[florian] has quit [Changing host]
<GitHub136>
[artiq] jordens commented on issue #767: Please double check your numbers. The IPs you mention all.over this issue report are inconsistent. I suspect you are just hitting your own typos. If not, please provide your actual configuration for confirmation. https://github.com/m-labs/artiq/issues/767#issuecomment-317848253