<sb0>
rjo, is there any use case for the system clock as RTIO clock on Kasli, or can we ditch the internal/external clock switch?
<sb0>
the sayma in the lab has been producing RF for ~24hours without crashing. good.
<sb0>
with sawg even
<rjo>
sb0: i don't think there is a use case. but what's the reason for removing it? isn't that just a lot of work and risk?
<sb0>
it's 5 minutes of work afaict, removes a bit of code, and makes the timing reports clearer
<rjo>
sb0: i think you and whitequark are the only ones using the "development environment instructions" in the artiq manual. that should be removed or at least demoted further and the deprecation warning should be worded stronger.
<rjo>
ok to remove it if you are convinced it is a good idea. but please update and verify docs, tests, examples, etc.
<sb0>
we should also factor the code for testing EEMs. right now I'm just writing some ad-hoc kernels, which is a complete waste of time when we have a lot of systems
<rjo>
i think the target/device_db generator should fix all this.
<rjo>
sure. i test with the respective demo for the target. it doesn't get much faster than that. but the demo should also be autogenerated.
<sb0>
I think there should be a generic demo that looks at the device db and does an interactive system test
<sb0>
the target/device_db generator << could be called "variant manager", since it would also interact with things like artiq_flash
<sb0>
rjo, what's the plan for the grabber firmware?
ardavast_ has joined #m-labs
ardavast has quit [Read error: Connection reset by peer]
<rjo>
sb0: firmware? it's just a coredevice layer for the rtio channels.
<rjo>
i don't know about "manager". more a hardware/variant deployment tool to me.
<rjo>
sb0: you wanted to work on the cameralink phy. any news?
<sb0>
rjo, not yet. I'm going to need some hardware; considering the price of anything cameralink and the funding we have for this development, it makes sense to just do it on the final camera setup
<rjo>
sb0: apart from the whining, what's your plan?
<rjo>
if i have to choose between shipping/travelling the camera, setting up, and juggle with it and just writing a simple test pattern generator in gateware then i'd always choose the latter. that would be much easier to eliminate the first batch of bugs.
<sb0>
rjo, that's the plan, not whining; please set up a system with kasli, the camera emitting a constant stream of data, and give me ssh access
<sb0>
rjo, I don't think the camera has to be shipped around, just use the final system
<rjo>
the camera and the final system are in hannover. could you talk to christian about getting ssh access?
<sb0>
okay
<sb0>
also, are we doing base or medium cameralink?
<rjo>
base. see the camera datasheet
sb0 has quit [Quit: Leaving]
<whitequark>
rjo: ok. I will fix that soon.
sb0 has joined #m-labs
ardavast_ has quit [Read error: Connection reset by peer]
ardavast has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]