<_whitenotifier-b>
[starshipraider] azonenberg pushed 2 commits to master [+1/-0/±7] https://git.io/JJWKi
<_whitenotifier-b>
[starshipraider] azonenberg 62e6971 - Finished pod length matching
<_whitenotifier-b>
[starshipraider] azonenberg 997e167 - Continued work on register interface formal verification. Added actual board delay values to LowSpeedInputs.
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #scopehal
hlzr has joined #scopehal
<azonenberg>
So i just got an idea based on XAPP523 to squeeze more performance out of MAXWELL
<azonenberg>
I think 2.5 Gsps on the inputs is plausible
<azonenberg>
The max data rate won't be any higher but i'll have more precise timing measurement capability
<azonenberg>
I'm already building the trigger system around 1.25 Gsps and having enough trouble with that though, so not yet sure if i'll actually do it
<azonenberg>
but i'll probably at least want to try
<azonenberg>
One possibility is to do the interleaved sampling at 2.5 Gsps (using an IBUFDS_DIFF_OUT, IDELAYE2, and second ISERDESE2) but only use the primary 1.25 Gsps stream for triggering, then the second only for acquisition
<azonenberg>
but we'll see
<azonenberg>
lain: ^
<azonenberg>
what do you think? the 1.25 Gbps max for the normal input is based on synchronous sampling of data
<azonenberg>
async oversampling, as in a LA, isnt bound by that
<lain>
ooooo
<lain>
interesting
<azonenberg>
xapp525's method might even let me squeeze out 5 Gsps, i dont quite understand the clocking structure they're using yet
<azonenberg>
but 2.5 is doable beyond any doubt
<azonenberg>
now of course this will also double my ram bandwidth so compression will become extra important
<azonenberg>
and of course there will be the problem of trigger performance
<azonenberg>
but I'm gonna play with it once hardware is back
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
<pepijndevos>
Degi, I have a MSO5k Yea I firured the "auto" setting is a bit excessive fore trying to squeeze it over the cable.
<pepijndevos>
azonenberg, would there be any harm in setting the socket timeout to something very low? Would that just slightly increase CPU, or actually break on high-latency networks?
<pepijndevos>
Just thinking about what you said rewriting the rigol driver for brokenness
<_whitenotifier-b>
[scopehal-apps] pepijndevos edited a comment on issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJWcO
<pepijndevos>
Something random I'm going to try... in the rigol datasheet it sets the mode and form before the write. Maybe that just trickles some random bit or introduces enough delay to avoid the firmware bug...
<pepijndevos>
I'm also going to acquire a trace from their own software.
<azonenberg>
pepijndevos: if the timeout is too low, it will break
juli964 has joined #scopehal
<pepijndevos>
Maybe it should be configurable then. I mean, ideally the Rigol bug should be fixed, but setting it to a few ms for my local network would make the broken driver a lot faster hehe
<pepijndevos>
Hmmm, what would happen if you send a new command before it finished replying to the previous one?
<pepijndevos>
Maybe that would be a fast way to detect a stuck DATA? command. If you immediately follow it up by another command and you get #9001000THESECONDREPLY you know it got stuck.
<azonenberg>
Good question
<azonenberg>
Try it? :p
<azonenberg>
of course if your waveform happens to exactly match that bit pattern you're in trouble, but that seems pretty unlikely if it's something long like *IDN?
<azonenberg>
also you'd need to modify the read data calls to not read the full buffer right away
<azonenberg>
lain: so now it's a question of if i can get my trigger logic to make timing with 2x or 4x the amount of data it was processing before
<azonenberg>
and not be massive :p
<azonenberg>
Having 96 channels of LA almost as fast as my scope would be super nice lol
<Degi>
pepijndevos: The rigol itself seems to take at least 50 ms to send a trace
<pepijndevos>
I'll definitely experiment more later. Unfortunately I also need to finish my master thesis...
<Degi>
Oki, much success with that!
<pepijndevos>
The last few days I've basically been toying around with implementing my IC on breadboard while my supervisors are on holiday.
<pepijndevos>
But tomorrow I have a meeting and need to actually read some papers which I'm dreading, and procrastinating from by typing in this channel
<pepijndevos>
lol wat... I put a wifi router at my scope so I can work comfortably from my desk, and now I can't reproduce the bug.
<pepijndevos>
Maybe we should introduce some "slow start" algorithm that reduces a delay until the scopes starts "dropping" packets.
<Degi>
The scope doesnt have wifi right...
<Degi>
Hmh maybe
<Degi>
Now it works fine?
<Degi>
Is your computer connected over WiFi? Maybe rigol has bad TCP stack?
<pepijndevos>
So what I did is put a wifi router next to the scope, and plug in the cable
<pepijndevos>
and then connect to the router over wifi from my laptop
<pepijndevos>
So I can have the noise scope in my bedroom lab and my laptop on my living room desk
<pepijndevos>
*noisy
<pepijndevos>
But yea... apparently the extra latency from the routed makes it all work fine.
<pepijndevos>
Before I plugged my laptop directly into the scope
<pepijndevos>
Maybe their own labview code is just too slow to trigger the bug hehe
<Degi>
Hmh plugged directly? did you disable dhcp etc?
<pepijndevos>
yea, just link-local IPs
<pepijndevos>
I assume you've been using a normal LAN in your testing?
<pepijndevos>
Would be curious to see if you can reproduce the bug on your scope with a direct cable
<azonenberg>
Degi, pepijndevos: conjecture: if you send commands too fast the scope ignores them
<azonenberg>
also woo final probe PCBs shipped ETA 27th
<azonenberg>
Gotta order components soon
<Degi>
hmm direct cable... Might test out sometime, I guess I could attach it to my laptop... Tbh I've never had 2 network interfaces at once.
<pepijndevos>
azonenberg, hmmm but when the DATA? gets stuck, it does send the #9001000 start of the data, so it's definitely parsing the command
<pepijndevos>
Something odd I've just noticed is that via WIFI the TRIG? call almost always returns STOP, while before it always returned TD IIRC
<pepijndevos>
Also, just looking at the trace, it appears as if it spends the majority of the time in the TRIG? call.
<pepijndevos>
(congrats on the scope pcbs)
<Degi>
Oh neat @pcb !
<pepijndevos>
I.... cannot reproduce the crash now with the direct cable
<pepijndevos>
s/crash/bug/
<pepijndevos>
OH I CAN IF I DISABLE TRACEING THE COMMANDS
<pepijndevos>
so like.... are you trying to tell me the delay of a printf is the difference?
<sorear>
.oO( reproduce timing bugs by swapping the crystal on the scope )
<pepijndevos>
actually no it's not the trace command it's something else
<pepijndevos>
OKAY I"M ONTO SOMETHING
<pepijndevos>
if i zoom in it works, if I zoom out it doesn;t work
<pepijndevos>
So as far as I can tell SING takes ages, like 300ms kind of times
<Degi>
Is the trigger set at a good level for triggering
<pepijndevos>
yea it's directly on a function generator at 0V
<pepijndevos>
So what I'm seeing is that on successful triggers, there is significant delay between TRIG:STAT? and WAV:DATA?, while on the failed triggers it's around 5ms
<Degi>
Did you check the delay in WAV:DATA from sending it to the first adn second response
<pepijndevos>
what do you mean?
<Degi>
When scopehal sends WAV:DATA? the response takes like 50-80 ms
<Degi>
Per trace
<pepijndevos>
but what do you mean with first and second response?
<Degi>
Hmh there is two reads on the socket, one for header and one for the trace data
<Degi>
Nvm that shouldnt matter, only time between sent and the first response should matter
<pepijndevos>
From the side of the scope it's one packet
<_whitenotifier-b>
[scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJl87
<azonenberg>
Production batch of probe shells are here
<azonenberg>
Some powder clogging, they're in the ultrasonic cleaner now
<azonenberg>
Was hoping i had solved that but clearly not
m4ssi has joined #scopehal
<azonenberg>
ok, after cleaning 1/18 was completely plugged and unusable, the other 17 are fine
juli964 has joined #scopehal
m4ssi has quit [Remote host closed the connection]