* Degi
thinks about listening to azonenberg and getting that toaster oven for 40 € in my city
juli965 has left #scopehal [#scopehal]
<azonenberg>
Degi: yeah i hope you have as good luck as i did with mine. literally no modifications and i get a perfect process window as long as i shut it off and open the door ~15 sec after the solder melts
<azonenberg>
degi, electronic_eel: thoughts on having a finely variable gain/attenuation stage somewhere in the frontend?
<azonenberg>
I feel like 1 dB steps might still be a bit fine?
<azonenberg>
a bit coarse*
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #scopehal
<azonenberg>
any suggestions on port numbers for waveform data?
<azonenberg>
5025 for SCPI is a well established IANA registered port
<azonenberg>
but our waveform protocol is custom
<azonenberg>
I'll use 20204 right now, we can always change it / make it configurable later
<sorear>
Pick a random port in the private-use range C000-FFFF
<azonenberg>
hex port numbers? lol, i dont see that too often
<azonenberg>
ok fine i'll use 50101
<azonenberg>
At some point i want to formally specify the protocol and actually register it
<apo>
azonenberg: 80, you can usually get to that through firewalls
<azonenberg>
as with jtaghal's protocol, which currently lives on 50100 by internal convention but doesn't have an IANA official port
<azonenberg>
apo: lol
<_whitenotifier-9>
[starshipraider] azonenberg pushed 4 commits to master [+8/-0/±9] https://git.io/Jf348
<_whitenotifier-9>
[starshipraider] azonenberg 3743838 - Continued BLONDEL FPGA work. UART transmit now runs through AcquisitionManager until we have a standalone arbiter.
<_whitenotifier-9>
[starshipraider] azonenberg f328974 - Initial draft of handheld-resistive-probe manual
<_whitenotifier-9>
[starshipraider] azonenberg 2780e91 - Changes to sweep config in oshpark-sma-test simulation
azonenberg has quit [Read error: Connection reset by peer]
azonenberg has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg>
ok so i'm pretty close to having TCP streaming of waveform data working, i think
maartenBE has joined #scopehal
<electronic_eel>
azonenberg: about the finer gain stage in the afe - do you have a specific component in mind to replace the gain stage we have?
<electronic_eel>
or do you think about adding another stage for finer gain control?
<azonenberg>
I'm thinking of adding another stage with fractional db range
<azonenberg>
maybe a small attenuator or something
<electronic_eel>
are you sure that it is worth it? I think there could be a software gain control to nicely fill the screen at the cost of a bit of resolution
<electronic_eel>
I think that is what most scopes do when you use fine gain control
<azonenberg>
I'm not sure. i wanted to evaluate the cost in bom/board area and decide
<azonenberg>
i havent had time to touch
<azonenberg>
keysight apparently has a full 10 bit fine gain setting
<azonenberg>
i'll see what my lecroy does
<azonenberg>
but i think it actually has fine gain too
<electronic_eel>
hmm
<azonenberg>
easy way to tell is to zoom in to max resolution
<azonenberg>
so you can see single codes in the output
<azonenberg>
then scale it back a bit
<azonenberg>
do the codes change or no
<electronic_eel>
maybe for the higher end scopes, like ZENNECK and above?
<azonenberg>
Yeah that's kinda what i was thinking
<azonenberg>
BLONDEL i dont want to overcomplicate
<electronic_eel>
ack
<electronic_eel>
had a look at your kickstarter page - nice
<azonenberg>
yeah it's getting there but still has a ways to go
<azonenberg>
i'm hopeful though, $1.5K of $4K in the first 2 days isn't bad given i still have a month left
<electronic_eel>
there are 3 things that I would improve:
<electronic_eel>
1. the photo of the probe on the characterization board, the grey of the probe shell and the char board "merge" and you need to look at it a bit to optically discern what it shows
<electronic_eel>
I would move the camera angle so that the probe shell has the blue bench as background
<azonenberg>
i'll try and take a better one, but i don't want to emphasize the old board too much
<electronic_eel>
you should emphasize the probe, what the buyer will get
<azonenberg>
Yeah the problem is i dont have any in hand yet :)
<electronic_eel>
and currently I have to look hard at it to see it
<azonenberg>
yeah i'll shoot a new pic. you're not the first to point that out
<electronic_eel>
2. add a precise list of the accessories the buyer will get
<electronic_eel>
you just list "standard grounding accessories"
<azonenberg>
I did in the update page
<electronic_eel>
but that is really vague
<electronic_eel>
ah, didn't see that
<azonenberg>
yeah i might link it somewhere more obvious
<electronic_eel>
can you add a link to that on the main page?
<azonenberg>
was trying to keep the main page from getting TOO big
<azonenberg>
yeah i'll do that tomorrow when i shoot the new pic
<electronic_eel>
3. low cost option for students and hobbyistst...must verify full time student status
<electronic_eel>
is it just for students or also for non-student hobbyists?
<azonenberg>
yeah i'll clarify that too
<electronic_eel>
can you just change stuff on the kickstarter page once the campaign is live or does it go through some manual review?
<azonenberg>
i can just edit stuff
<electronic_eel>
500$ pro edition probe - "you get a empty cardboard box"
<azonenberg>
Lol
<azonenberg>
no as far as i know manual review is only before you launch
<electronic_eel>
strange
<electronic_eel>
how do you plan to do sales after the kickstarter?
<electronic_eel>
because that is one thing I don't like at kickstarter
<azonenberg>
lain and monochroma have a shopify and amazon storefront set up for some other projects that i was probably going to use
<electronic_eel>
the kickstarter page is well linked everywhere, but when the campaign is over, you can't use it anymore
<azonenberg>
the KS was just meant to quickly fund initial prototyping and, more importantly, get feedback from the first rev in actual field use
<electronic_eel>
that is something I prefer on crowdsupply
<azonenberg>
Yeah i might consider it for future projects
<azonenberg>
Not a huge fan of KS's all-or-nothing model too, which is why i picked $4K as a fairly conservative target
<azonenberg>
also wooo, i have trigger + capture to block ram working on the BLONDEL test firmware. After configuring the AFE over TCP
<electronic_eel>
you can ask esden about his experiences, he does most of his sales of the icebreaker stuff through crowdsupply
<azonenberg>
all that remains is to stream the captured waveform out
<electronic_eel>
ah, nice
<azonenberg>
There's lots left to do before this is something we can ship, obviously
<azonenberg>
but i'm hopeful to get waveforms on my PC this weekend
<electronic_eel>
implement the auto setup button ;)
<azonenberg>
Lol
<azonenberg>
That tweet was actually me wondering if anyone would miss us not having one
<electronic_eel>
I wouldn't miss it
<azonenberg>
conclusion: if glscopeclient brings the instrument up in sane defaults
<azonenberg>
i doubt anyone will care
<electronic_eel>
the only time I use it is if I'm using a scope model I've never used before and the menus somehow confused me enough that it doens't do what I want anymore
<azonenberg>
it sounds like that's what most people use it for
<azonenberg>
when what they really want is a "restore default settings" button
<electronic_eel>
I think there are two different things: restore sane defaults and try to automatically pick the best settings for the current waveform
<azonenberg>
Yes
<azonenberg>
The latter i find of questionable utility
<azonenberg>
the former is handy
<electronic_eel>
the first thing is easy to implement and what most people want
<azonenberg>
Exactly
<electronic_eel>
the latter is questionable
<azonenberg>
Yeah
<azonenberg>
oook so the first PoC is not going to have any kind of full pub/sub since we only have one channel
<azonenberg>
If you connect to the waveform port and send any traffic whatsoever
<azonenberg>
you'll start getting data
<azonenberg>
you must send at least one byte, value is ignored
<electronic_eel>
don't need full scpi for the first prototype, getting actual live data to the sw is important
<azonenberg>
oh i have full scpi already on the control plane side
<azonenberg>
i'm talking about the data plane socket
<azonenberg>
that parsing will be super simple as it's all gateware
<azonenberg>
right now it's "wait for a single well formed tcp segment"
<azonenberg>
lol
<electronic_eel>
later on I think the port numbers should be assigned by the scope software and told to the client via scpi
<azonenberg>
why?
<azonenberg>
it's not like anything else will be on this IP
<azonenberg>
have one and standardize it
<electronic_eel>
to allow dynamically assigning them?
<azonenberg>
why would you ever want to change the port number internally?
<azonenberg>
this isnt something you'd ever connect to the public internet, or at least i hope not :p
<electronic_eel>
it is one port per channel, right?
<azonenberg>
No
<azonenberg>
One port for the whole acquisition subsystem
<azonenberg>
send a trivial command to subscribe/unsubscribe from a channel
<azonenberg>
(proposal: send channel number to sub, 0x80 | channel number to unsub)
<azonenberg>
then you get waveform data streamed every time the scope triggers
<electronic_eel>
how do you plan to packetize the tcp data when you have multiple channels in parallel?
<azonenberg>
eventually there will be a framing around each waveform
<azonenberg>
timestamp of the trigger event, then for each enabled channel the number of the channel, number of points, and then the data
<azonenberg>
exact formatting TBD but super simple
<azonenberg>
right now for the PoC i'm sending raw adc samples with no framing whatsoever
<electronic_eel>
when you have a long-running sample, like 5 seconds or similar, you want to start showing data directly after trigger and not wait for the 5 seconds to expire
<electronic_eel>
and you want to do that on all active channels
<azonenberg>
rolling captures may even be a totally separate framing
<azonenberg>
with interleaved sample data
<azonenberg>
every scope i have used in the past, other than in roll mode, has not updated the display until the entire waveform is acquired
<electronic_eel>
yeah, and that is what I hate
<electronic_eel>
we should do better
<azonenberg>
That's an enhancement we'll think about for the later firmware
<azonenberg>
The code i'm writing now will be mostly rewritten when we move to the ddr3 capture buffer and stuff
<azonenberg>
right now i have a hard wired 50% full scale rising edge level trigger
<azonenberg>
etc
<azonenberg>
this is very PoC'y just trying to get end to end dataflow through the system working
<electronic_eel>
ok, so one fixed port you connect to, and the data has some kind of framing
<azonenberg>
Yeah
<azonenberg>
I guess what we could do is change the format a bit
<azonenberg>
instead of having block based channels we could interleave the channels
<azonenberg>
But this will require some fun if we have channels at different rates
<azonenberg>
and different bit depths
<electronic_eel>
maybe the sw can tell the scope how it wants the data to be interleaved?
<azonenberg>
We'll have to sit down and design the protocol. That will happen once we have final hardware though
<azonenberg>
My goal right now is to get a PoC working so we can exercise the AFE more
<electronic_eel>
of course
<azonenberg>
so i truncated the waveform to one tcp segment
<azonenberg>
but i think i got something
<azonenberg>
There's also an off by one that i just found in the triggering logic, but i should have a plot in a minute or two
<azonenberg>
ok it looks like i might have some ordering bugs within the 8-sample blocks
<azonenberg>
this is a 5 MHz fast-risetime waveform off my scope
<miek>
woo
<Degi>
Nice
<azonenberg>
sampled at 625 Msps we should see a period of about 125 clocks which looks right
<azonenberg>
Next step is to fix a few details in the acquisition logic to correctly read from the start of the ring buffer and not memory address 0
<Degi>
Is that at minimum gain
<electronic_eel>
now that looks more like it
<Degi>
Hm I dont see any obvious jumps
<azonenberg>
and to read the entire waveform rather than only the first 1024 samples
<azonenberg>
i sampled 16K and only dumped the first 1K
<Degi>
Maybe send the full memory and send the trigger point?
<electronic_eel>
how does a sine look like?
<azonenberg>
since going more would require multiple tcp segments
<Degi>
Ah
<azonenberg>
and that's a bit more code
<azonenberg>
that's going to come shortly
<azonenberg>
Before we do any more integration i also need to make it re-arm once triggered, and start a scopehal driver
<azonenberg>
Degi: this is at *maximum* gain actually on teh frontend
<azonenberg>
+26 dB
<electronic_eel>
and the input signal, is that just a few mv pp?
<monochroma>
hey look a square wave
<azonenberg>
The amplitude ranges from codes 33 to 192 which is 160 LSBs. Gain is lower than it should be, i believe because of those output resistors on the LMH6552s
<azonenberg>
But i'm holding off on any more hardware work until i have this talking to scopehal
<azonenberg>
rather than netcatting a waveform into a .bin file and then using a php script to massage it into CSV that i can render in qtiplot
<azonenberg>
which is a bit of a roundabout way to do end to end data analysis
<electronic_eel>
but I don't see any obvious noise on the signal, with that being max gain this is a good sign
<azonenberg>
oh and i have to reload the bitstream after one trigger because there's no re-arm support
<Degi>
yay scope arrived
<azonenberg>
What i think i will do initially is make the trigger arm as soon as you connect like it does now
<azonenberg>
But then auto re arm after say 100 ms
<electronic_eel>
or maybe after reconnecting?
<azonenberg>
i don't want to go too fast because my tcp stack will desync if you drop a packet as i don't actually have tx buffering yet
<azonenberg>
so i need to be 100% certain i send waveforms slower than the app can process them for the moment
<azonenberg>
10 WFM/s * 16k points * 1 channel should be well within safe limits
<electronic_eel>
or do you haven't implemented tcp reconnection yet?
<azonenberg>
while the stack should handle reconnections or even multiple concurrent connections fine
<azonenberg>
the application layer code is in its extreme infancy
<azonenberg>
reconnection will work but i don't have per connection state tracking or anything
<azonenberg>
it uses the source socket of the most recently received tcp segment on port 50101 as the destination for all traffic
<azonenberg>
so if you make a second connection and send anything, you hijack the currently active session
<electronic_eel>
but couldn't you have a signal going from tcp reconnect to your rearm?
<azonenberg>
Yes i could. but i dont want to reconnect every waveform
<azonenberg>
I'm going to simulate the scope triggering on an external 10 Hz squarewave, basically
<azonenberg>
again the goal right now is just to validate the chain end to end
<azonenberg>
be able to change gain from scopehal, etc
<electronic_eel>
I would prefer reconnecting to a fixed 100ms, as it allows to change rearm more easily
<Degi>
Woo lets have a virtual champagne bottle
<azonenberg>
The goal right now is to have a steady stream at 10 WFM/s that i can use for bringup testing on the AFE
<azonenberg>
this is not intended to ever be used in real world work as it stands
<azonenberg>
this whole thing is a benchtop prototype, i'm capturing waveforms to block ram without any double buffering
<azonenberg>
literally all of this code is going to be eliminated in the final board
<azonenberg>
everything but the actual adc controller itself
<Degi>
Hm even the input alignment and the TCP?
<azonenberg>
Which is now validated in single channel 8 bit mode
<azonenberg>
Degi: the tcp stack is incomplete but i'm keeping. But the application layer code driving the tcp is going to need a significant rewrite
<azonenberg>
what i have right now is quite hacky, for example the arbiter between the uart and waveform data lives inside the acquisition manager
<azonenberg>
that has to be refactored out into a standard arbiter that's part of the tcp stack
<azonenberg>
i also have to rip out some arbiters at lower protocol layers that have huge buffers and replace with proper req/ack flow control
<azonenberg>
rather than letting any protocol send packets at any time and just hope i have enough buffer space
<azonenberg>
which needs either huge buffers or risks packet loss
<azonenberg>
This is a decent ways from being usable in a real world system. The priority right now is to validate the AFE and ADC subsystems so we can begin work on the actual production hardware
<azonenberg>
or at least, the first iteration of it
<azonenberg>
once we have scopehal working end to end on here, i plan to hook the VNA siggen directly to the AFE (no probes) and measure actual amplitude across a frequency sweep
<azonenberg>
compare output level to what i measure and see how much unexpected loss we have, and how flat it is
<Degi>
Yes that'd be nice
<Degi>
Can you sweep to like 2 GHz
<azonenberg>
Lol that would be a little ridiculous
<Degi>
Does it output differential or do you need a transformer forthat
<Degi>
I'd do at least 1 GHz
<azonenberg>
why?
<Degi>
To measure the bandwidth
<azonenberg>
we have a 100 MHz antialiasing filter
<azonenberg>
there's no point in going past about 200
<Degi>
Oh wait I swapped afe and adc sry
<azonenberg>
What i want to do is measure end to end frequency response
<Degi>
Actually it would still make sense to see how good the isolation is
<azonenberg>
Put 0 dBm into the AFE and sweep frwquency
<azonenberg>
see what the measured amplitude looks like
<azonenberg>
Which reminds me we need a scopehal measurement for RF power level
<azonenberg>
basically just convert p-p amplitude to dBm assuming a 50 ohm systme
<azonenberg>
system*
<Degi>
Just measure RMS multiply by Z?
<Degi>
yeah
<Degi>
Maybe allow setting the impedance somewhere
<azonenberg>
Want to write one while i'm working on this stuff? For now hard code the impedance as 50 ohms
<azonenberg>
because as of now measurements don't take parameters IIRC
<Degi>
hmm does scopehal work on rigol scopes? Mine just arrived
<azonenberg>
Measurements and protocol decoders will be unified at some point, i have an open ticket
<azonenberg>
which model?
<Degi>
MSO5074 I think
<Degi>
yes
<azonenberg>
Does it have ethernet?
<Degi>
yes
<azonenberg>
There's an open ticket for USBTMC support but i don't think that was ever implemented. Ok
<azonenberg>
In that case, connect it and see. I've only tested on DS1000Z series
<azonenberg>
i don't know how similar the scpi command sets are
<Degi>
How do scopes transfer samples anyways? Like as decimal data over scpi?
<electronic_eel>
Degi: if there is smoke coming out the back it wasn't supported ;)
<azonenberg>
Degi: it completely varies by the scope, sometimes it's even configurable
<azonenberg>
most common is a header with an ascii number of samples followed by raw binary adc codes
<azonenberg>
Grr, probe dummies are still in shenzhen. Fedex is overloaded again i guess
<azonenberg>
multech seems to be trying every carrier under the sun
<azonenberg>
pre-covid they always used DHL and it was always fast
<azonenberg>
apparently they had problems with DHL being slow, my last order shipped via UPS and was held up for a week before moving
<azonenberg>
this one used fedex and also is held up
<Degi>
Huh
<azonenberg>
(i've been using them for years and these are the first two orders i've ever had not ship via DHL)
<azonenberg>
also apparently i have a bug where pushing waveform data to TCP too fast causes corruption
<azonenberg>
i temporarily fixed it by adding an artificial delay between write calls in the ADC bridge
<azonenberg>
but clearly i missed flow control somewhere and need to add backpressure
<azonenberg>
(this is the first time i've tried to move any nontrivial amount of data through the stack)
<azonenberg>
but now i can dump 16K points, once
<azonenberg>
aand re-arming implemented, let's see how well that works
<miek>
azonenberg: might've hit labour day closures - i got a warning about DHL having a holiday 1st to 3rd
<azonenberg>
labor day in china?
<azonenberg>
because labor day in the US is in september ish
<miek>
yeah, in china
<azonenberg>
oook so the scope as it stands doesn't know when to quit
<azonenberg>
if you close the socket it keeps spamming you until you reload the FPGA
<azonenberg>
buuut it's probably complete enough i can try and get a scopehal driver up now :p
<miek>
"hey where you going, i've still got data!"
<azonenberg>
tl;dr the stack detects the FIN and closes the socket
<azonenberg>
but doesn't send any notification to the upper layer yet
<azonenberg>
And apparently i don't check the socket is open before sending a segment :p
<azonenberg>
did i mention this stack isn't complete yet? Lol
<azonenberg>
But this is good progress. We have full end to end waveforms getting to my computer
<azonenberg>
Sooo i'm sitting down and starting to write the driver. Here's a question
<azonenberg>
What should the default color scheme for our channels be?
<azonenberg>
I'm going with yellow, pink, cyan, green for the first 4 as that's what my LeCroy scopes use and i'm used to that
<azonenberg>
But what about the next 4?
<azonenberg>
i'm thinking orange somewhere in there, maybe a brighter red and pastel violet?
<miek>
i'm guessing everyone buys the little probe colour clips from PMK too - do they have a standard set of colours?
<azonenberg>
They only have four
<azonenberg>
yellow, pink, cyan, green although the ordering varies between vendors
<azonenberg>
R&S is a bit unique
<azonenberg>
yellow, green, orange, blue-gray is what i have in my driver
<azonenberg>
So i'm thinking we could use those latter two as two of our second four
<azonenberg>
the other two i'm not sure about
<miek>
yeah, seems they all like to be different. my agilent is yellow, green, blue, pink :p
<electronic_eel>
what does lecroy do if you have an 8 ch scope from them?
<azonenberg>
Very good question. It looks like white, pastel purple, deep red, and...
<azonenberg>
trying to find a screenshot with the last one enabled
<azonenberg>
but i like the idea of orange in the mix somewhere as it's quite distinct. the deep red looks too much like the pink IMO
<azonenberg>
ok looks like lecroy's last channel is orange
<azonenberg>
so it's the same yellow-pink-cyan-green for the first four, then white, pastel purple, red, orange
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jf3PM
<_whitenotifier-9>
[scopehal] azonenberg cbbfe19 - Initial BLONDEL oscilloscope driver can now display waveforms. No configuration support yet, lots of hard coded settings.
<bvernoux>
woo I have found a very good deal on Ebay ;)
<azonenberg>
just 30 seconds ago
<bvernoux>
ha great
<azonenberg>
This is *very* hacked together, there's a lot of missing parts before it will be remotely usable
<bvernoux>
very nice signal
<azonenberg>
But it is scopehal processing a waveform through my AFE and ADC, with configuration through the SCPI-over-TCP path and waveforms via pure FPGA TCP
<bvernoux>
ha great
<azonenberg>
I have to be careful not to trigger too fast or i fill up the linux tcp window
<azonenberg>
and then all hell breaks loose because the fpga never retransmits
<azonenberg>
and the fpga never stops sending when you close the socket
<bvernoux>
does it is smooth to display it in realtime ?
<azonenberg>
so, lots of things left to do
<bvernoux>
anyway very nice results for a preview
<bvernoux>
could you test with 50MHz signal ?
<azonenberg>
Right now with 16K points the scope is triggering at 6 Hz and has no trouble keeping up
<bvernoux>
as 625MSPS shall display nicely 50MHz
<azonenberg>
i need to fix triggering first, it's super distracting seeing the signal jumping all over the place
<bvernoux>
ha ok
<azonenberg>
The 6 Hz is a soft limit to keep the network link from saturating before i implement retransmits
<azonenberg>
basically if i go too fast, any momentary lag spike on the PC due to an interrupt or something might delay a packet and fill up the tcp window
<azonenberg>
and i don't back off when that happens
<azonenberg>
the TCP is very "hope everything works out, if not you're screwed" right now
<azonenberg>
it's basically udp in tcp framing :p
<bvernoux>
do you have tested the 12bits mode ?
<bvernoux>
as I imagine 625MSPS is 8bits
<azonenberg>
Not yet. I want to exercise the AFE more in 8-bit mode still
<bvernoux>
ok
<azonenberg>
actually the ADC can do 640 Msps in 12 bit and 1 Gsps in 8-bit (on one channel)
<bvernoux>
ha great
<azonenberg>
however the devkit i'm using has a -1 FPGA which tops out at 950 Mbps on the GPIO
<azonenberg>
So it cannot keep up with 1 Gsps waveforms even though my ADC test board has an 1 GHz clock source
<azonenberg>
so i have it set to the 625 MHz clock in 8-bit mode. If i build an integralstick with a -2 artix i'll be OK
<azonenberg>
But i have bigger fish to fry right now
<bvernoux>
yes very nice so far
<bvernoux>
it is intended to be a scope+LA ?
<azonenberg>
BLONDEL will be 8 channels split across two HMCAD1520s
<bvernoux>
I do not remember the spec of Blondel
<azonenberg>
each quad will be independently configurable as either 8 bits 1 Gsps or 12 bits 500 Msps
<azonenberg>
that sample rate can be split across 1, 2, or 4 channels
<azonenberg>
There will additionally be two 8-bit LA pods at 1 Gsps with separate Vt per channel (not per pod like normal)
<bvernoux>
with configurable level ?
<azonenberg>
Yes
<bvernoux>
ok great
<azonenberg>
Right now we're prototyping on a very simplified environment with an artix devkit, block ram instead of ddr3, and one adc connected to a single AFE
<azonenberg>
and no 10GbE
<electronic_eel>
bvernoux: there will be comparators in the pod and an 8ch dac to set the threshold
<bvernoux>
ha final version is planned to use 10GbE ? (probably SFP+)
<azonenberg>
The focus at the moment is to bring up the AFE more thoroughly and characterize it
<azonenberg>
The final version will have one XAUI
<azonenberg>
one XAUI connected 10G SFP+
<bvernoux>
ha nice
<azonenberg>
and one 1000base-T PHY + RJ45. You will have to select one or the other
<azonenberg>
it won't bridge
<azonenberg>
via the front panel LCD
<bvernoux>
it is intended to be like a PicoScope with everything on PC ?
<bvernoux>
(everything means retrieve data+Display on PC)
<azonenberg>
Yes. Fully headless 1U system
<azonenberg>
tiny LCD just for IP config and a few other things
<electronic_eel>
bvernoux: azonenberg plans to replicate pico, down to implementing the software in vb6 ;)
<azonenberg>
loool
<bvernoux>
yes do not replicate VB6 SW ;)
<bvernoux>
on mys side I have bought JFW Industries Rotary Step Attenuator 0-70db 2.4GHz 50DR-068 SMA for 45USD :)
<bvernoux>
I hope it is not a fake or broken part ;)
<bvernoux>
good attenuator are nice to have ;)
<bvernoux>
especially JFW it is military stuff with ultra accurate attenuator
<bvernoux>
Potentially I will buy also JFW 50DR-077
<bvernoux>
it is amazing
<bvernoux>
DC to 2GHz (but in reality more than 3GHz) with attenuator 1dB step up to 90dB
<bvernoux>
with very flat attenuator with max 0.7dB variation over the range ...
<azonenberg>
Just checked tracking. My mini-circuits splitter should be here weds
<bvernoux>
it is fun with dual rotary a bit old school ;)
<azonenberg>
which will be nice for double checking gain calibration on BLONDEL
<bvernoux>
ha yes
<azonenberg>
send one half to the scope and one half to the AFE
<azonenberg>
then compare reported results
<bvernoux>
yes clearly a must have for such things
<electronic_eel>
couldn't you just plug the whole afe between the vna?
<bvernoux>
yes if the power is not too high ;)
<azonenberg>
electronic_eel: it's differential, and i don't just want to do the AFE
<azonenberg>
i want to report the whole path including the ADC
<electronic_eel>
ah, right, output is differential
<azonenberg>
the idea here is to validate various parts of the design
<bvernoux>
directional coupler is also very nice for that
<bvernoux>
but a good one is more expensive than power divider ;)
<electronic_eel>
is the directional coupler as accurate as a power splitter?
<bvernoux>
even better in theory
<electronic_eel>
isn't there some variance in coupling over freq?
<azonenberg>
Directional couplers don't work down to DC
<azonenberg>
A resistive divider will
<bvernoux>
ha yes
<bvernoux>
directional coupler are limited to something like 10KHz I think ...
<miek>
i tested a couple of the dirt cheap directional couplers that are all over ebay and they're surprisingly good
<electronic_eel>
there are different topologies, like with transformers and striplines and such
<bvernoux>
anyway power splitter is very nice if your characterize it and in case of Mini-Circuits they provide SxP files so ...
<electronic_eel>
each works well in a limited freq range
<miek>
azonenberg: which splitter did you order?
<azonenberg>
DC to 4.2 GHz SMA from minicircuits. Forget the part number but ther'es only one with those specs
<bvernoux>
yes
<bvernoux>
It is a must have ;)
<bvernoux>
especially for the price
<miek>
got it, thanks
<bvernoux>
it is ZFRSC-42-S+
<bvernoux>
performance is very flat
<bvernoux>
with -6dB
<bvernoux>
+/-0.1dB worst case over full range DC-4.2GHz
<bvernoux>
I can take photo on what inside if you want ;)
<bvernoux>
but nothing terrible just few res ;)
<azonenberg>
ok i really need to implement support for dropping the connection when glscopeclient quiet
<azonenberg>
quits*
<azonenberg>
i just dos'd myself, i think my router pegged the cpu or disk or something
<azonenberg>
i wasnt getting packets routed for a while and the console was nonstop firewall alerts
<azonenberg>
quite a few Mbps of waveform data being sent to a closed socket :p
<monochroma>
:P
<azonenberg>
for now i'll just make sure to reset the fpga *before* i close the app
<miek>
bvernoux: oh no, i accidentally bought two jfw step attenuators
<Degi>
lol
<Degi>
You could use a balun for differential to SE
<Degi>
Hmh yeah being able to do a FFT on the sampled data from the ADC would be nice
<Degi>
For characterization
<Degi>
Hm we should also think about self tests etc
<azonenberg>
Yeah
<Degi>
If we wanna go full fancy we could add a duplexer relay on the input (like have the protection relay be a relay with 2 positions) to apply a cal signal
<Degi>
Probabbly overkill for blondel
m4ssi has quit [Quit: Leaving]
<azonenberg>
Yeah. I want to keep blondel simple
<azonenberg>
we're not building a super fancy scope here
<azonenberg>
zenneck is probably where we'll start seeing more high end design features come in
<azonenberg>
maybe a bit in duddell
<azonenberg>
Ok so, i'm now doing at least 25 WFM/s over ethernet no problem and i have better trigger phase correction. Next step is to add interpolation of trigger time
<azonenberg>
i'll try and post a video showing the performance later on
<azonenberg>
Also SMA test boards are at oshpark ETA the 12th
<azonenberg>
interesting note, Amphenol's recommended torque for this connector is 8 in-lbs (7-10 specced)
<azonenberg>
Not 5 like i normally see for brass SMAs
<azonenberg>
i am probably going to want to pick up another torque wrench at some point but for the time being i think i'll be OK running them at 5. Reproducibility i think matters more than the exact value, and not over tightening
<azonenberg>
Properly interpolating the trigger phase is definitely an absolute must
<azonenberg>
without it, you see the waveform jittering a lot at higher zoom values
<azonenberg>
Wow this looks really nice with the trigger interpolation
<azonenberg>
This is at 25 WFM/s, let's see how it does at 50
<azonenberg>
This is beautifully responsive compared to the other scopes i've used glscopeclient with and i'm not even close to pushing actual performance limits yet, i have sleeps all over the place to compensate for my lack of flow control in the TCP
<azonenberg>
looks like we have a mutexing problem somewhere that causes a deadlock when i open a protocol decoder dialog though
<azonenberg>
that's not good
<azonenberg>
But it explains a lot that i've seen in the past
<electronic_eel>
about SMA torque - is it just specced for female (board) side or for male (cable) also?
<electronic_eel>
if it is specced for both, what do you do if they spec different values?
<electronic_eel>
so like brass on one side, stainless on the other?
<azonenberg>
Good question
<azonenberg>
i'd imagine the lower to avoid deforming it
<azonenberg>
Most of my higher end cables are already stainless and i torque them to 5 since they're mated to brass connectors
<azonenberg>
what's more interesting is the amphenol connector i am using is specced 7-10 but it's brass
<electronic_eel>
maybe some special brass mix?
<azonenberg>
No idea
<electronic_eel>
most of my sma stuff is brass, I just got very few stainless adapters I once bought in a big box from ebay
<azonenberg>
Also i have glscopeclient running at about 45 FPS right now streaming waveforms from the BLONDEL prototype. I could definitely push it higher once i implement TCP handling of window sizes etc in case i go too fast
<azonenberg>
and fix arbitration on the fpga for some stuff
<azonenberg>
but it's working end to end. gonna try and add config for gain and offset soon
<electronic_eel>
really nice progress
<azonenberg>
Then grab a demo video probably
<electronic_eel>
upload to kickstarter, start campaign
<azonenberg>
Lol
<azonenberg>
no way :p
<azonenberg>
I don't take funding for vaporware - i'd never cut it in the bay area
<azonenberg>
i don't sell a product i'm not 110% confident i can deliver on time
<electronic_eel>
oh yeah I forgot, upload to marketing agency, let them make a nice video and marketing campaign for it
<azonenberg>
lol
<electronic_eel>
with dancing scope probes
<azonenberg>
Anyway yeah, good progress and i have the rest of the weekend to do more extensive testing now
<azonenberg>
there's still that static offset i need to measure and calibrate oute
<azonenberg>
out*
<azonenberg>
which will involve working out details of how to store cal data etc
<Degi>
Huh static offset
<Degi>
How much is it
<azonenberg>
i recall 30 mV or so?
<azonenberg>
easy to cal out, and constant, we just have to actually do it
<azonenberg>
anyway i'm thinking i2c eeprom on the AFE/ADC board for cal data. So if we swap boards the cal stays with them
<electronic_eel>
I think there wasn't any proper afe characterisation being done, like measure where the offset is from, what affects it and the like
<azonenberg>
There has not been any characterization done yet
<azonenberg>
i wanted to get end to end data capture with scopehal working first
<azonenberg>
The only thing i have to do before i'm happy with it for the short term is graceful connection teardown
<azonenberg>
i.e. having the scope back off if it gets a fin or rst
<azonenberg>
right now the stack wipes the socket state table entry when this happens but doesn't send any notification to the upper layer
<azonenberg>
So the SHTF
<azonenberg>
and more importantly the stack has a bug where it keeps on forwarding frames that are going to a closed/nonexistent socket
<azonenberg>
so i guess if i fix that the app pushing to a closed socket is not as big a deal
lain has quit [Quit: brb]
lain has joined #scopehal
<bvernoux>
woo nice 45fps
<bvernoux>
it is very nice to have a smooth refresh
<Degi>
What is the limiting factor for FPS?
<Degi>
Is it the wfm/s?
<Degi>
Hm having multiple trigger points on a continuous sample block would be nice,.
<Degi>
Actually a 50 ohm active probe with a termination resistor on its output should work on 1 MOhm systems with similar / same signal quality as on 50 ohm systems with double the amplitude, since the reflected signal would get gobbled up by the termination resitor.
<electronic_eel>
Degi: be careful with high voltage probes without proper datasheet and specs, it's your life (and that of your scope) that depends on this
<Degi>
k ill just build my own, at least then I know whats inside
<electronic_eel>
there should be some chart which shows the derating of the allowed voltage regarding frequency
<Degi>
I cant find one lol
<Degi>
I cant find anything about the probe number...
<electronic_eel>
if they don't have that, but just put "250 MHz" on it, I'd be careful
<Degi>
Lol
* Degi
applies 3 kV pk-pk at 250 MHz
<electronic_eel>
exactly, boom
<Degi>
Thatd be 35 kVAr into 5 pF
<Degi>
Meh I could build something like the thing from ice9 in smaller