lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sb0 has joined #m-labs
<GitHub139>
[artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/WsokYQ
<GitHub139>
artiq/master 8b55213 Sebastien Bourdeauducq: transforms/inline: keyword argument and default value support
<GitHub139>
artiq/master 9098d10 Sebastien Bourdeauducq: use .py extension on all Python files
<rjo>
davidc__: runtime (funny concept...)
<davidc__>
rjo: sorry, SW terms :)
<davidc__>
rjo: so you need to cal it every experiment, I guess
sj_mackenzie has joined #m-labs
sb0 has quit [Ping timeout: 250 seconds]
sb0 has joined #m-labs
sb0 has quit [Ping timeout: 258 seconds]
sb0 has joined #m-labs
<rjo>
davidc__: if the amp is broadband and load-independent that should not be necessary.
<davidc__>
rjo: and close enough to the load.
<sb0>
rjo, making it fully load-independent pretty much implies charging and discharging that capacitor through a resistor (or equivalent) 50 million times per second, which dissipates significant power...
<sb0>
compared to a simple class-A, the efficiency goes from horrible to bad
<rjo>
sb0: no. with feedback (like an opamp) you need no resistor. or a zero-impedance source.
<rjo>
the efficiency of an amplifier driving an imaginary impedance is always horrible.
<rjo>
i was hoping not to need 8 valves per channel just for the output stage...
<davidc__>
rjo: could you just use a resonator, but use active feedback to servo the target phase?
<rjo>
davidc__: yeah. except that i would have to build stuff to tune the resonator frequency and coupling electronically as well and then stabilize those. three feedback circuits and difficult control electronics per channel...
<rjo>
because if i load the resonator with more capacitance, everything moves.
<davidc__>
rjo: if you use a lower Q resonator, then you don't need to tune the resonator directly
<davidc__>
just control the phase offset
<davidc__>
meh, anyhow, guess it depends whether its simpler to build the control electronics or the big drive amps
<rjo>
but then i can also use a not-so-wideband amp with just inductive peaking.
<rjo>
and feedback
<rjo>
feedbacks on phase and amplitude
<rjo>
davidc__: exactly.
<davidc__>
hmm, interesting problem. maybe I'll build one at some point
* davidc__
pushes it onto the project queue
<davidc__>
I'll get back to you sometime in 2017
<rjo>
;)
FabM has joined #m-labs
kmehall has quit [Read error: Connection reset by peer]
sj_mackenzie has quit [Remote host closed the connection]
groolot has joined #m-labs
groolot has quit [Ping timeout: 258 seconds]
_florent_ has joined #m-labs
<ysionnea1>
rjo: I guess you did test the labbrick controller with cffi on a 32 bits windows machine?
ysionnea1 is now known as ysionneau
<ysionneau>
cause I'm trying here to make it work on a 64 bits windows 7 and I have lots of troubles
groolot has joined #m-labs
groolot has quit [Ping timeout: 264 seconds]
_florent_ has quit [Quit: Leaving]
sb0 has quit [Ping timeout: 255 seconds]
sb0 has joined #m-labs
<sb0>
rjo, those 8 valves are there to lower the output impedance - a speaker load is an extremely low impedance for vacuum tubes. the electrode is a friendlier load in that respect, which also needs less power, so two valves should be enough.
<sb0>
you can probably replace all the other valves with op-amps
sb0 has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
<ysionneau>
sb0: I am trying to integrate the 3 Mbps uart in ARTIQ, I replaced the custom code by pySerial in comm_serial.py , it seems to sometimes exchange a few messages, sometimes none
<ysionneau>
the uart link seems buggy
<ysionneau>
when I look with logic analyzer I see a lot of coupling between flash SCK and the uart pins or maybe the coupling comes from my shitty probes ...
<ysionneau>
anyway, it results in even the simplest led.py example (which just switches the LED on) to not work at all
<sb0>
that's possible, cf. papilio pro flashing issues
<ysionneau>
yep
<ysionneau>
the comm_serial.py stays busy in port.read() in my case
<sb0>
is there a way not to ue pyserial?
<sb0>
use
<ysionneau>
I tried to use the same kind of logic as in flterm, maybe I should try tht harder
<ysionneau>
that*
<ysionneau>
pyserial is able to read() the BIOS messages though
<ysionneau>
and by it's code (and documentation) it supports the non standard baudrates
<ysionneau>
if I just do from serial import Serial ; s = Serial("/dev/ttyUSB1", baudrate=3000000) ; while True: s.read() in python interpreter and reboot the board, I can see the bios+runtime messages
<ysionneau>
I guess it's just losing some bits sometimes which I cannot see in the BIOS messages but happen during RPC and kills the protocole dead :/
<davidc__>
by any chance is this an FTDI cable talking to a VM under vmware?
sb0 has quit [Ping timeout: 256 seconds]
<ysionneau>
here I'm connecting FTDI cable to a native ubuntu desktop computer
<ysionneau>
but I also use quite a lot virtualbox Debian machine
sb0 has joined #m-labs
<davidc__>
ysionneau: I've seen missing bytes on FTDI cables when passed through vmware VUSB; not on native/virtualbox though.
<ysionneau>
I must say that here I'm using non-standard high baudrate 3000000
<ysionneau>
the 115200 works fine
<sb0>
ysionneau, can you add dynamic baudrate selection? add a parameter to comm_serial that defines the baudrate, and dynamic baudrate switching in the serial protocol and runtime. it goes without saying that this requires e.g. handshaking (so that the computer will not try to send subsequent bytes at the new baudrate while the UART receives them at the old) and reverting to the default baudrate in comm_serial's __exit__
<ysionneau>
for the handshaking what do you have in mind? Something like : comm_serial sends a message to change the FTW (frequncy tuning word), then it sends messages at the new frequency and tries to read answers, and when finally it manages to read the correct answer back it means the core device have finished switching to the new frequency?
<sb0>
no. waiting for a "ftw updated ack" from the device should be enough.
<sb0>
before you send new bytes
<ysionneau>
ah so I switch immediately to the new frequency and do a read() to read some magic ACK word
<ysionneau>
sb0: I fixed shebang + flake8 (no more warning on rjo's lda.py and in my adapted lda_client.py and lda_controller.py), I also modified lda.py so that it behaves in "simulation mode" if no HW detected and just prints to console whenever doing a set_attenuation()
<sb0>
good
<ysionneau>
I didn't take into account yet your comment about the float conversion and the usage of parameter instead of text input for the client
<ysionneau>
as soon as I take also care of this I send you the 3 files?
<sb0>
instead of going to sim on no hw detected, I think we should have a cmdline parameter that selects the device
<sb0>
and there's a special device name that goes to sim
<sb0>
the pdq2 driver doesn't do that atm but I think it should be fixed
<ysionneau>
oh ok, and then if we select a device but no device is really detected -> raise exception
<ysionneau>
(select a non-simulation device)
<sb0>
(I just copied that pdq2 detection code from rjo)
<sb0>
yes
<ysionneau>
ok got it
<ysionneau>
I tried this controller (lda) on my Win 7 Pro 64 bits, I never got cffi to work correctly...
<ysionneau>
I get linker error when it tries to link the generated C file
<ysionneau>
saying either my hidapi.dll is corrupted, or if I use the hidapi.lib static library it then says it does not find the symbols
<ysionneau>
because it searches for __imp_XX instead of XX (which is in the .lib)
<ysionneau>
after a bit of research (I know nothing about Windows development) I found out __imp_ prefix is for shared library imports in windows
<ysionneau>
and there also seem to be issues of mixing x86 and amd64 binaries
<sb0>
hmm, idk much about that. my latest programming experience with windows was in 2004 when there wasn't much 64-bit yet...
<ysionneau>
I don't know which Windows flavour rjo used when he said he got this to work
<ysionneau>
but let's keep in mind we might have trouble when trying this on Win 64 :/
<ysionneau>
we might have to dig deeper on that
<ysionneau>
maybe I should dump the usage of visual studio and try to make cffi use mingw...