<_whitenotifier-3>
[scopehal] four0four e6fb395 - Initial, broken Siglent support
<_whitenotifier-3>
[scopehal] four0four 3802f3b - rebase
<_whitenotifier-3>
[scopehal] ... and 37 more commits.
<_whitenotifier-3>
[scopehal] four0four opened pull request #65: some changes in the upper LeCroyOscilloscope class for Siglent compat - https://git.io/fjncK
<Error_404>
hrm, did I fuck up the git history there?
<Error_404>
oh, no. looks fine. cc azonenberg
<Error_404>
bah, i am going to need to basically wrap all of the siglent-facing network stuff in verrry fault tolerant code
<azonenberg>
first off (you probably copied this from the lecroy driver before i fixed it) rather than doing C%D:blah
<azonenberg>
you can just use GetHwname() on the channel object
<azonenberg>
and do chan->GetHwname() + ":WF? DESC"
<azonenberg>
the hwname is explicitly "whatever the scope refers to the channel as over SCPI"
<azonenberg>
the display name defaults to the hwname but is user modifiable
<azonenberg>
Also, i just skimmed it but i didn't see you handling the toQueue parameter properly in AcquireData()
<azonenberg>
It's used for multithreaded/offline acquisitions and pushes waveforms into the pending queue rather than into the channels' current data
<azonenberg>
whitequark: actually it seems to have spontaneously recovered, i think i'm good
<azonenberg>
Error_404: let me finish what i'm doing wrt rigol driver support, get that to MVP level where i can pull a waveform
<azonenberg>
then i'll grab your PR and test on my actual lecroy gear and make sure nothing borked
<Error_404>
yep that's all true. refactoring that stuff is coming next
<azonenberg>
Dont worry about the interleaving or sample rate stuff
<azonenberg>
just return empty arrays for now, none of those functions are ever called
<azonenberg>
Or call the base class since i dont think you need to override
<azonenberg>
i need to change that API a bunch
<azonenberg>
(thanks rigol)
<azonenberg>
BTW i'm thinking of making an integralstick based oscilloscope prototype at some point in the not too distant future
<azonenberg>
i'll use the same adc as whitequark's rigol but stream direct to gig-e and have no AFE
<azonenberg>
so direct 50 ohm inputs with no gain/offset
<azonenberg>
just for experimenting to see what i can do performance wise
<azonenberg>
could probably do it for $200-300
<azonenberg>
the focus will be on providing test data to push WFM/s performance on glscopeclient
<azonenberg>
See if i can max gig-e with scope data, how fast i can retrigger, etc
<azonenberg>
alternatively maybe i'll make it as a FMC and hang it off a beefier board with 10GbE
<azonenberg>
The ADC can do 8 bit 1 Gsps so if i have next to no delay between triggers, i can stream full line rate over 10GbE
avl has joined #scopehal
<azonenberg>
whitequark: your scope crashed again
_whitelogger has quit [Remote host closed the connection]
_whitelogger_ has joined #scopehal
<whitequark>
azonenberg: has it?
<whitequark>
azonenberg: uhhhhh it now hard-crashes at startup
<whitequark>
azonenberg: back up
<whitequark>
i think its LAN addon got extremely confused
<whitequark>
i had to unplug the network and replug it back for it to stop crashing
<sorear>
What purpose does the AFE serve?
avl has quit [Remote host closed the connection]
<whitequark>
sorear: the range of the ADC itself is limited
<whitequark>
the ADC in my rigol has a 2V full scale range
<sorear>
mm
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
avl has joined #scopehal
<whitequark>
hm
<whitequark>
i got some YMF262-Ms without the "OPL" calligraphy logo
<whitequark>
fake?
<whitequark>
i can't figure out how is it faked if it is
<whitequark>
the mold looks pretty much identical, mold flash, pin1 mark, dimensions, texture
<whitequark>
so it is not sanded down
_whitelogger has joined #scopehal
<whitequark>
er, oops, wrong channel
<azonenberg>
whitequark: ok so now i cant even connect
<whitequark>
azonenberg: i turned it off
<whitequark>
needed that power cable
<whitequark>
lemme get it back up
<whitequark>
azonenberg: done
<whitequark>
azonenberg: in the US system, does "ECE 6440" mean something in particular
<whitequark>
like year or something
<azonenberg>
whitequark: As a class number?
<azonenberg>
i'd interpret that to be "electrical and computer engineering" department, difficulty 6 (graduate level), course number 440
<whitequark>
oh
<azonenberg>
course numbers are commonly 2 or 3 digits, with 2 slightly more common
<whitequark>
well that explains why i'm having trouble understanding that material
<azonenberg>
so the stereotypical course 101 = difficulty 1 (first year undergraduate), course number 01
<azonenberg>
2xx = second year undergrad, 4xx = third and fourth year undergrad
<azonenberg>
3 and 5 are not commonly used
<azonenberg>
7-8-9 i normally see used for "special purpose" or "administrative" classes
<azonenberg>
Things like "teaching assistant" or "dissertation" or "research" that aren't really classes
<whitequark>
ahh i see, thanks
<whitequark>
i'm trying to implement a CDR
<whitequark>
and i find it to be hard
<azonenberg>
oh? for what purpose and in software or hardware?
<whitequark>
currently prototyping it in python
<azonenberg>
i've done oversampling based CDR in hardware and soft PLL based in software
<whitequark>
it will eventually be an oversampling based CDR in hardware
<azonenberg>
How much oversampling?
<azonenberg>
i.e. ratio of data rate to fclk
<azonenberg>
And is the data scrambled or encoded at all?
<whitequark>
the data is encoded with 1b2b and the hardware already performs edge detection
<azonenberg>
so manchester?
<whitequark>
MFM
<azonenberg>
... oh. Lol
<whitequark>
it's for a floppy
<whitequark>
and i oversample by about 100 times
<azonenberg>
So in that case I'd actually suggest you try a PLL based CDR
<azonenberg>
you can make a DPLL out of a NCO and a feedback system
<whitequark>
what i've done so far is i made a rotational frequency detector and tried to lock it to the data
<whitequark>
and it didn't really work well at all
<azonenberg>
So, that won't handle jitter well
<whitequark>
exactly
<whitequark>
i have a lot of jitter
<azonenberg>
You need a second order control loop that syncs to both phase and frequency
<azonenberg>
Check out scopeprotocols/ClockRecoveryDecoder.cpp for some reference code
<whitequark>
yes, i was going to use some phase detector once i got frequency detector to work
<whitequark>
well i don't want reference code, i want to understand how to do this
<whitequark>
i could just grab code from MAME otehrwise
<azonenberg>
you dont need to explicitly measure frequency
<whitequark>
hmm
<azonenberg>
You can work entirely in the phase domain
<azonenberg>
Basically, start with a rough first order approximation of the data rate to initialize your oscillator
<azonenberg>
As soon as you see an edge in the data, zero the phase
<azonenberg>
So if you guessed right, your next edge should occur on a data edge (or the one after that, if there's no transitions immediately)
<azonenberg>
So what you do is, run the oscillator for a cycle and see if you saw a data edge
<azonenberg>
If not, keep going and run another cycle
<azonenberg>
If you did see an edge, figure out the delta from the actual edge position to your predicted position
<azonenberg>
if the data edge comes in the second half of the period, assume it was meant to be aligned to the second edge
<azonenberg>
if it comes in the first half, assume it was meant to be the first
<azonenberg>
follow so far?
<whitequark>
uh, yes
<azonenberg>
So then you use this as the error signal into your control loop
<whitequark>
that's actually what i already wrote without really looking at any reference material
<azonenberg>
All you measure is phase, but you correct in both phase and frequency
<whitequark>
but it doesn't work so well
<azonenberg>
There's two control schemes possible, proportional and binary aka "bang-bang"
<azonenberg>
Proportional control cares about the magnitude of the error, binary only cares about the sign
<azonenberg>
I use a binary control loop in the scopeprotocols CDR
<azonenberg>
you make a fixed correction every time in both phase and frequency
<azonenberg>
So if you're lagging you increment the phase so you start the next NCO aligned slightly closer to this edge, and you speed the NCO period up a little bit
<azonenberg>
If leading, you decrement phase and slow down the period
<azonenberg>
There's probably some fancy theory for calculating the deltas but i just experimented a bit to see what gave me a fast lock and low jitter with real-world test signals
<whitequark>
ohhhhh fascinating
<azonenberg>
i made a plot over time of the phase error values and frequency, it will start out shooting all over the place while the frequency converges to the correct value, possibly a bit of overshoot, then the error will suddenly drop to a tiny fraction of its old value and the frequency will stop changing much
<azonenberg>
i'm locking to a 1.25 Gbps random bit stream (800ps nominal period)
<azonenberg>
and deliberately starting the oscillator a bit fast to observe the locking process
<avl>
which signal is it ?
<avl>
ethernet ?
<azonenberg>
avl: PRBS-31
<avl>
i see
<azonenberg>
Although i later decoded SGMII using the same PLL
<azonenberg>
i was just testing for this plot
<azonenberg>
I later improved loop stability by tuning the coefficients, this was my first successful lock ever
<azonenberg>
whitequark: my first attempt at a PLL did a second order loop only (control frequency but not phase) and it was all over the place and never locked
<azonenberg>
You need first and second order (phase and phase velocity aka frequency) control to be stable
avl_ has joined #scopehal
<whitequark>
azonenberg: so let's say my NCO produces a 50% duty cycle clock
avl has quit [Ping timeout: 252 seconds]
<whitequark>
wait
<whitequark>
azonenberg: when you're saying "start at a rough first order approximation of data rate"
<whitequark>
how do you get that?
<whitequark>
is it just hardcoded 1.25 Gbps or something? or is it more clever?
<azonenberg>
User provides a guess of the data rate in a dialog when you configure the decoder
<azonenberg>
It can be arbitrary, but the further off from the actual rate it is, the longer it will take to lock
<azonenberg>
If you want, you can measure the delta between a few clock edges and calculate a histogram of that or something
<azonenberg>
and use it as an initial seed
<whitequark>
i'm thinking wait for a few edges and choose the smallest period
<azonenberg>
That would work
<whitequark>
because this lets me read both HD and DD floppies without user input
<azonenberg>
again, the control loop will correct for any error in the initial guess - but if you're too far out it will take a while to lock
<whitequark>
ok, got it
<whitequark>
so after that
<whitequark>
i don't entirely understand your phase detector, let me try describing it
<whitequark>
let's say i have an NCO that produces 50% duty cycle clock
<azonenberg>
(unrelated, your scope isnt resopndiong to network traffic - the socket is open but nothing is coming back)
<whitequark>
fixed the scope
<azonenberg>
Duty cycle doesnt matter, you only run the phase detection on the rising edge
<azonenberg>
Thanks
<whitequark>
the goddamn thing keeps getting a zeroconf address
<whitequark>
i don't even have zeroconf
<whitequark>
anyway, i was thinking about this implementation
<azonenberg>
Your feedback system is trying to sync your rising nco edge to the data transitions (or, in the case of my decoder, sync the rising edge to the center of the data eye)
<whitequark>
hm
<whitequark>
right so how'd you decide if it's leading or trailing?
<azonenberg>
Look at a window of two NCO edges with a data edge somewhere between them
<azonenberg>
and see which one it's closer to
<whitequark>
yeah but i'm aiming for a hardware implementation
<azonenberg>
So? You're oversampling
<whitequark>
sure
<azonenberg>
When you see an edge, calculate the time of the previous and next NCO edge
<azonenberg>
it doesnt even need to have happened yet
<azonenberg>
If the data edge is less than half a UI after the previous NCO edge, it's leading
<azonenberg>
If it's more than half a UI after, it's lagging the one that didn't happe nyet
<whitequark>
what i was thinking is to make the NCO use 50% duty, then see which phase it is when data edge happens
<azonenberg>
That would work too, my NCO isnt even really a squarewave per se
<whitequark>
if it's 0..180° then it's trailing, if it's 180-360° then it's leading
<whitequark>
or the other way around
<whitequark>
it saves an adder! :D
<azonenberg>
All i have is rising edge events
<azonenberg>
with fixed times between them
<azonenberg>
i synthesize falling edges in between but dont actually use them for anything
<azonenberg>
it's just so i have something to rise from
<azonenberg>
But yeah, you're getting the idea
<whitequark>
ok, i have one last question before i can implement it
<whitequark>
adjusting frequency is just changing period, that's easy
<azonenberg>
adjusting phase is adding or subtracting a delta value to your phase counter
<whitequark>
right
<whitequark>
so instead of changing that counter by 1
<whitequark>
i would change it by 0 or 2
<whitequark>
right?
<azonenberg>
Or even -1 or 3, etc
<azonenberg>
you'll have to experiment and see what gives best resuls
<whitequark>
excellent, i understand it entirely now
<whitequark>
i wrote something very imilar
<whitequark>
but it did a lot of useless ad-hoc things and also didn't adjust phase well
<azonenberg>
Yeah my initial implementation didnt change phase at all
<azonenberg>
Side note, if you are running fairly fast wrt the data rate
<whitequark>
48 MHz currently
<azonenberg>
you may be able to reduce jitter by having a DDS for the NCO
<whitequark>
wait what
<azonenberg>
Store a fractional component to the phase
<whitequark>
so that jitter would be contained entirely in the fractional part, ideally
<whitequark>
that's clever
<azonenberg>
So you can have your actual nco period jittering between say 4 and 5 clock cycles
<whitequark>
i might try it
<azonenberg>
and get a closer overall match
<azonenberg>
If you're running at like 50x the data rate, probably not necessary
<azonenberg>
if 5x, it might improve stability
<whitequark>
well eventually i want to push a floppy to its limits
<whitequark>
put 20 MB on it
<whitequark>
or more
<azonenberg>
Lol nice
<whitequark>
i know ~6 MB is definitely possible
<whitequark>
just from looking at histograms of domain sizes
<whitequark>
but i think that with a really good PLL and a good line code and some ECC i can go even higher
<azonenberg>
Do some FEC for sure
<azonenberg>
maybe 64/66b coding instead of MFM
<azonenberg>
For extra fun, PAM4? :p
<azonenberg>
or is the drive hardware incapable of that
<sorear>
microstepping and SMR? :p
<whitequark>
sorear: i wanted to do that
<whitequark>
but you need to modify the erase head
<sorear>
PAM4 is almost certainly impossible
<whitequark>
because it erases more than one track
<whitequark>
azonenberg: the drive does AGC
<whitequark>
so the thing about 64b/66b is that it wouldn't work very well
<whitequark>
it solves a different problem
<whitequark>
64b/66b improves over 8b/10b by providing statistically bounded DC balance instead of hard bounded DC balance
<whitequark>
floppy doesn't care about DC balance in the slightest
<azonenberg>
well 64/66 also reduces coding overhead
<azonenberg>
That's the point
<whitequark>
yes but you wouldn't use 8b/10b either
<azonenberg>
it gives you transitions to sync to with very low overhead
<sorear>
with a floppy you're limited in transition density, but AFAICT precision timing of transitions can encode a little bit more data
<azonenberg>
If you just scramble the data you have no easy way of syncing to it
<azonenberg>
the dc balance is almost irrelevant, the scrambling is to add transitions
<whitequark>
hm, you're right
<whitequark>
azonenberg: as sorear correctly notes in a floppy you're limited by bandwidth, effectively
<sorear>
dense information storage would be easier to think about if clock recovery weren't simultaneously an issue
<sorear>
I have a hunch that clock recovery isn't a limiting factor, but it's a complication for sure
<azonenberg>
sorear: PAM4 is impossible period, or only with the current hardware?
* sorear
imagines hacking a decent rotary encoder on the drive
<azonenberg>
i.e. is it possible to do PAM4 on a floppy with a custom built head? or is the media incapable
<whitequark>
azonenberg: it is possible but you would need to do something clever with gain
<whitequark>
or even better
<whitequark>
abandon constant rotational speed
<whitequark>
and use constant surface speed
<sorear>
azonenberg: it'd definitely not be possible if you were working at the single-domain level, because domains are all-or-nothing
<whitequark>
azonenberg: because in existing floppies (most of them) the drive spins at 300 rpm
<azonenberg>
So it's not constant linear velocity?
<whitequark>
the outermost domains are the largest and the innermost are the smallest
<azonenberg>
like CDs?
<whitequark>
that's why the FAT of FAT is in track 0
<sorear>
azonenberg: I think floppy heads are much bigger than that and analog recording would be possible, but the drive electronics have a lot of gain and normally operate way into clipping
<whitequark>
that's the track with physically largest sectors
<whitequark>
so it's least likely to be damaged
<whitequark>
track 80 in contrast is the most likely
<whitequark>
it's a really stupid system
<whitequark>
i absolutely want to make a drive with constant linear velocity and something like PAM4
<whitequark>
wait
<whitequark>
isn't that how zip drives work
<azonenberg>
whitequark: hey, if you want to write a MFM protocol decoder for scopehal i would love that
<whitequark>
azonenberg: ok, i can do that after i get my own PLL to work
<whitequark>
and after you make it so that i can use the captures from my rigol :P
<whitequark>
i mean, i can always export data from glasgow, but where's the fun in that
<azonenberg>
I'm working on that now, lol
<azonenberg>
There's extra data coming back when i read a waveform that's confusing my driver
<whitequark>
scopehal would be useful if i connected the scope across the head itself
<azonenberg>
(that's what i had in mind)
<azonenberg>
it's unable to align subsequent commands to replies
<whitequark>
holy shit, zip drives can be up to 750 MB
<azonenberg>
so i need to wireshark and see how much ACTUAL reply comes back
<avl_>
i had 150M iomega
<whitequark>
i had a 150M one too
<whitequark>
possibly iomega as well
<azonenberg>
so what does the zip disk physical layer look like?
<whitequark>
currently reading about it
<whitequark>
one thing is that it uses voice coils
<whitequark>
instead of a stepper
<whitequark>
is there any public info on that anyway?
<azonenberg>
Dont know
<azonenberg>
Thats why i was asking
<sorear>
remember when magneto-optical was going to be a thing
<whitequark>
aha, they have some patents on it
<avl_>
LIMDOW
<avl_>
Light Intensity Modulation Direct Overwrite
<whitequark>
that line code reminds me of something, but i can't put my finger on it
<azonenberg>
4b/6b of some sort?
<whitequark>
it's variable length
<whitequark>
azonenberg: ohhhh
<whitequark>
it's almost like HHH(1,13)
<whitequark>
it definitely belongs to the RLL family of codes
<whitequark>
which is unsurprising
<whitequark>
it's RLL(2,8) i think?
<whitequark>
or more like RLL(1,8)
<sorear>
looks like (1,8)
<azonenberg>
whitequark: well it's ungodly slow running over this high latency WAN link, lol
<azonenberg>
Buuut it's working
<azonenberg>
In read only mode, none of the set functions are implemented
<sorear>
ultimate gains from improved timing precision on a fixed transition density (essentially, pulse position modulation) are, unfortunately, logarithmic
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/fjnzA
<_whitenotifier-3>
[scopehal] azonenberg de5b6b6 - Continued initial implementation of Rigol driver. Waveform download now (sort of) working. Still no Set* functions.
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjnzx
<azonenberg>
There's basically no way to control the scope yet, all you can do is query the current configuration and display waveforms
<azonenberg>
Deep memory not yet tested
<avl_>
i see
<azonenberg>
no USB backend, ethernet only
<whitequark>
azonenberg: ok, how do i build it
<azonenberg>
whitequark: clone azonenberg/scopehal-cmake and pull all submodules
<azonenberg>
then normal cmake build process
<azonenberg>
run $BUILD/src/glscopeclient/glscopeclient from the src/glscopeclient directory in your source tree (no proper locating of shaders etc is implemented yet)
<azonenberg>
standard logtools arguments, i suggest --debug
<_whitenotifier-3>
[scopehal-cmake] whitequark forked the repository - https://git.io/fpF3Q
<azonenberg>
then the connection string which is formatted as nickname:api:hostname[:port]
<azonenberg>
so in my case whitequark:rigol_lan:whitequark.org:5556
<azonenberg>
again, all of the Set* functions are not working so most of the UI to change trigger, gain/offset, etc wont work
<azonenberg>
But it should connect and show you a waveform and let you run math functions and measurements on it
<azonenberg>
If you give me another day or so i can probably implement the remainder
<sorear>
question
<azonenberg>
Changing the horizontal time scale will not work even once fully implemented because i havent finished the API design for that
<sorear>
does scopehal work on ipv6
<azonenberg>
there's some quirks in how differnet scopes do this so i wanted to spend some time and design a portable API
<azonenberg>
sorear: i use my generic socket class which doesnt care
<azonenberg>
if your scope speaks ipv6, which is the big question
<azonenberg>
Note that scopehal in general does not require TCP/IP as a transport
<sorear>
azonenberg: i mean, without dns
<azonenberg>
But all currently implemented scopes do
<_whitenotifier-3>
[scopehal-cmake] whitequark opened pull request #4: README: reformat to use block code tags - https://git.io/fjngU
<azonenberg>
sorear: I take anything you can pass to getaddrinfo()
<azonenberg>
avl_: but yes, feel free to compile and test
<azonenberg>
whitequark: i'm curious what kind of WFM/s you can get over a local connection
<azonenberg>
with several hundred ms RTT it's... not fast
<_whitenotifier-3>
[scopehal-cmake] whitequark opened pull request #5: Search for libffts in ~/.local as well - https://git.io/fjngY
<whitequark>
azonenberg: else(LIBFFTS_INCLUDE_DIR AND LIBFFTS_LIBRARIES)
<whitequark>
wtf
<whitequark>
cmake hasn't required this for like five years
<whitequark>
azonenberg: you really should make ffts a submodule
<sorear>
I'm surprised-not-surprised that RTT affects that
<whitequark>
it's very obnoxious how i currently have to mess with include paths just to get it to build
<sorear>
how will your scope handle large bandwidth-delay products
<_whitenotifier-3>
[scopehal] whitequark forked the repository - https://git.io/fpF3Q
<_whitenotifier-3>
[scopehal] whitequark opened pull request #66: Actually use the results of FindFFTS - https://git.io/fjngB
<whitequark>
azonenberg: that doesn't work
<whitequark>
Warning: Shader::Load: Could not open file "shaders/waveform-vertex.glsl"
<whitequark>
ERROR: failed to load default shaders, aborting
<whitequark>
ohhhh i see
<whitequark>
it can't do out-of-tree builds
<whitequark>
urgh
<_whitenotifier-3>
[scopehal-cmake] whitequark edited pull request #4: README: reformat to use block code tags - https://git.io/fjngU
<whitequark>
azonenberg: also doesn't work
<whitequark>
INTERNAL ERROR: fail to open eye gradient This indicates a bug in the program, please file a report via Github
<whitequark>
Aborted
<whitequark>
WTF is eye gradient
<whitequark>
oh
<whitequark>
it's the same problem with out-of-tree builds
avl_ has quit [Remote host closed the connection]
avl has joined #scopehal
<whitequark>
azonenberg: ok, fixed those
<whitequark>
now it segfaults on a null pointer
<whitequark>
#1 OscilloscopeChannel::GetHwname[abi:cxx11]() (this=0x0) at /home/whitequark/Projects/scopehal/lib/scopehal/OscilloscopeChannel.cpp:199
avl_ has joined #scopehal
avl has quit [Ping timeout: 246 seconds]
<whitequark>
ok that was *also* caused by an out-of-tree build
<azonenberg>
whitequark: It *does* out of tree builds
<azonenberg>
You need to *run* from the source directory for now
<azonenberg>
there is a hard coded chdir() to work around it on my machine
<azonenberg>
i havent made a more permanent solution yet
<whitequark>
ok
<whitequark>
so it doesn't give me any wfm/s
<whitequark>
in fact it never retriggers
<whitequark>
also it just hung hard
<azonenberg>
So, still some issues to work out
<azonenberg>
But it loaded and gave you one waveform?
<whitequark>
yes
<whitequark>
now if i start it, it segfaults
<azonenberg>
Lol
<azonenberg>
let me see...
<avl_>
for submopules pull should i use this ?git submodule update --recursive
<whitequark>
yes
<avl_>
trying to build
<azonenberg>
whitequark: So, i am able to get it to re-trigger fine over the port forward
<azonenberg>
It's super slow, like 5 sec between triggers
<azonenberg>
but it does work
<azonenberg>
whitequark: do you have a recommended solution to the out of tree build problem btw?
<azonenberg>
wrt locating resources in general
<avl_>
how do i set ip address of scope ?
<azonenberg>
that's always been a sticking point for me
<azonenberg>
avl_: run glscopeclient --debug nickname:rigol_lan:host_or_ip:port
<azonenberg>
port should be 5555 unless you changed it
<avl_>
ok
<azonenberg>
nickname can be anything you want, it serves no purpose unless you have >1 scope connected simultaneously in which case it is used to distinguish one channel from another
avl_ has quit [Ping timeout: 248 seconds]
avl has joined #scopehal
<avl>
what is rigol_lan ?
<avl>
oh man
<avl>
scope gone mad
<avl>
it has connected
<avl>
but it beeps and writes down some message Cant operate now
<whitequark>
huh, azonenberg connects to my scope via ipv6
<azonenberg>
whitequark: i have native ipv6 here so yeah
<whitequark>
azonenberg: i usually add some cmake rules that copy the files over to the build directory
<whitequark>
since symlinks don't work on windows
<avl>
behaviour is this
<avl>
iut switches on all 4 channels
<avl>
i have generator with sine on channel 1 but it tries to activate all