azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
* 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]
<_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 883d318 - Updated footprint caches
<_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> but we have a waveform
<azonenberg> and it looks at least vaguely like what it should
<azonenberg> Gonna try with a sine wave now, which should make ordering issues more obvious
<Degi> azonenberg: The HMCAD has finely variable gain
<Degi> Oh nice, samples
<Degi> Hm the full scale range is apparently -+ 10 %, then there is a second gain 0-12 dB
<Degi> Well there is fgain from -0.067 to +0.0665 dB
<Degi> Oh you can choose between 0-12 dB and 1x-50x
<azonenberg> ook so i'm sampling at 625 Msps looking at a 5 MHz squarewave. So I should have 125 samples per cycle
<azonenberg> While i see periodicity...
<azonenberg> it's... not what i expected
<azonenberg> Unclear at this time whether it's an RTL or board or config bug or what
<electronic_eel> strange
<electronic_eel> can you change the sine frequency?
<Degi> Huh=
<azonenberg> yes, i can do ~DC to 6 GHz :p
<azonenberg> it's on the VNA
<Degi> Does it drop samples maybe
<azonenberg> Degi: Not yet sure, I'm recompiling the FPGA design with an ILA on the ADC controller's outputs
<azonenberg> see if that sheds any light on it
<Degi> ILA?
<azonenberg> internal logic analyzer
<Degi> Hm also you trigger and then send the packets right? So the board is on all the time and this cant be a startup transient..
<azonenberg> I trigger as soon as I see a TCP segment hit port 50101 containing nonzero bytes
<azonenberg> more precisely i arm the trigger
<electronic_eel> while you wait for vivado to do it's thing - how does the output look like when you change the sine freq a bit?
<azonenberg> i record 1024 samples in pre-trigger mode
<azonenberg> then i wait for a rising edge crossing the midpoint of the ADC range
<Degi> In a ring buffer?
<azonenberg> when i see that, i mark the current time
<azonenberg> then i fill the ring buffer
<azonenberg> The readout, right now, does not respect the ring
<azonenberg> so there will be one discontinuity in it
<azonenberg> however what i see is far more than one discontinuity
<Degi> Yes
<azonenberg> once i've triggered once, i stay in ADC_STATE_DONE forever
<azonenberg> there is not yet any means of re-arming the trigger
<azonenberg> So no chance of any kind of race where i re-trigger before readout
<Degi> Is there something with 16 MHz around?
<azonenberg> Not that i know of
<azonenberg> the sinewave is 5 MHz, all of the FPGA clocks are multiples of 20 or 24
<azonenberg> the stm32 is 8 PLL'd up to 48 which is a common divisor, it's possible there is some noise coming from that?
<azonenberg> looking at the AFE outputs with a scope they did seem a little noisy but we'll address that separately
<azonenberg> there was a clear sinusoid on them
<electronic_eel> that is much more than some noise
<Degi> Or maybe around 9 MHz
juli963 has joined #scopehal
<azonenberg> ok, first result: the ILA sees gibberish too
<azonenberg> before data even hits the ring buffer
<Degi> Does it see what we see in the inmage?
<azonenberg> Pretty much, yes
<azonenberg> So i'm beginning to suspect there's a bug in the controller and/or the adc setup
<electronic_eel> so the adc is configured wrong?
<azonenberg> or my controller is reading it wrong
<azonenberg> Not yet sure
<azonenberg> Give me a minute to check a few things
<Degi> Hm so you sample all 8 inputs for 1 byte each and then order then in 1A, 1B, 2A...?
<electronic_eel> why 8 inputs? this is just 1 channel
<azonenberg> Ok THIS is interesting
<azonenberg> like, really really interesting
<Degi> Because we're sampling at full sample rate
<Degi> Huh?
<Degi> We have 8 outputs, the first sample arrives on 1A, the second on 1B etc...
<Degi> Squarey
<azonenberg> This is the waveform i see coming off the ADC
<azonenberg> With C1:GAIN -9
<azonenberg> i.e. gain is as low as it goes and the ADC is reading almost nothing
<azonenberg> we see a full amplitude squarewave
<Degi> Whats C1 gain?
<azonenberg> channel 1 gain on the ADL5205
<azonenberg> is as low as it goes
<azonenberg> max attenuation
<Degi> Hmh maybe the hmcad is on x50 gain by default
<azonenberg> That's an interesting theory. Let me try dumping the waveform with this
<azonenberg> see if it shows any signs of siney-ness
<Degi> Hm is it possible to lower the amplitude from the vna
<azonenberg> Yeah gimme a minute
<azonenberg> let me show you the downloaded data first
<Degi> That looks similar to what the LA shows
<electronic_eel> what happens if you just disconnect the input? does it show the same square output?
<azonenberg> hold on one thing at a time
<azonenberg> ok so right now the VNA is outputting 0 dBm which is about 615 mV p-p
anuejn has quit [Quit: No Ping reply in 180 seconds.]
anuejn has joined #scopehal
<azonenberg> I turned it down as low as it goes, -20 dBm which is about 76 mV p-p
<azonenberg> it looks maybe a bit different but not much
<azonenberg> let's try terminating the input now
<Degi> So the gain code is 111111?
<miek> this is going through the AFE? could you probe the hmcad input and double check it?
<azonenberg> Yes. it looks fine there
<azonenberg> well this is interesting
<azonenberg> now it basically looks like noise, but it's binary noise
<azonenberg> not analog noise
<azonenberg> basically full scale top and bottom
<Degi> Did you maybe swap lsb and msb
<azonenberg> No. The codes i'm seeing on the wire are e0, 1f, and 10
<azonenberg> extreme high gain on the ADC is plausible
<electronic_eel> like the high gain drives some digital part of the adc into overdrive?
<azonenberg> the adc has programmable gain inside it
<azonenberg> i'm wondering if that might be set to max at powerup
<Degi> So on the HMCAD input you see something with a few hundred mV or less?
<azonenberg> Degi: i have the afe input tied to ground with a terminator
<miek> could enable one of the hmcad test pattern options and check that
<Degi> hm yes
<Degi> Try 0x33: 0, 0x34-0x37 also 0, 0x2A, 0x2B also 0
<azonenberg> hold on a minute
<azonenberg> i'm trying the test pattern first. 0x25 = 0x0040
<azonenberg> that should be a 0 to full scale ramp
<Degi> yes
<Degi> On the image you sent what are the four values? In this order: 10 1f ef e0?
<azonenberg> i think so? i already closed that LA view
<electronic_eel> hmm, the datasheet of the hmcad claims that the gain at the default values (=reset?) should be x1
<azonenberg> Yeah
<azonenberg> so i thin kwe have something else going on
<azonenberg> It's very possible we were wrong from day one
<azonenberg> and this error just looked enough like the expected squarewave i didn't look deeper
<Degi> In the repeating 1f e0 pattern what if it outputs FF 00 actually
<Degi> Can you add FCLK to the LA view
<azonenberg> Already done. Waiting on that to build
<Degi> nice
<azonenberg> Very interesting
<azonenberg> We have a phase shift
<azonenberg> of... looks like about 4 bits
<azonenberg> it looks like the correct bit ordering from MSB to LSB is 4, 5, 6, 7 / 0, 1, 2, 3
<Degi> Hm I guessed 5
<azonenberg> no the LSB is bit 3
<Degi> Pics plz
<azonenberg> So it looks like a) we synced to the inverted fclk instead of the non-inverted (correcting for pcb layout pinswaps done wrong i guess)
<azonenberg> and b) we have msb-lsb backwards
<Degi> Huh so D0 is the LSB?
<Degi> Ah yes then the actual signal varies between 0 and 1
<azonenberg> in normal verilog convention 7 is MSB, 0 is LSB
<azonenberg> looking at the toggle rates of the various bits, the highest frequency is bit 3
<azonenberg> they get slower down to 0, then 7 to 4
<Degi> Huh so 0 is the MSB? interesting
<Degi> Ok then inverting frame clock should work
<miek> nice
<azonenberg> no i have the bits numbered backwards on the parallel output of the SERDES
<azonenberg> easy fix though
<azonenberg> Recompiling
<Degi> So we get 01 01 FE FE but after correcting for shifts and swapping MSB with LSB tgets 80 80 8F 8F for 101fefe0...
<Degi> Nah wait didnt account for the fclk
<azonenberg> ok i get a nice smooth ramp now
<azonenberg> let's see if i get it all the way through TCP
<Degi> Yaaay
<azonenberg> Looking good aside from an off-by-one in the readout code i already knew about
<azonenberg> let me fix that real quick and we'll see how it looks on real data
<Degi> Yes just mtu rn off the ramp
<azonenberg> ok, nice clean flattish line coming off the ADC now. Let's turn the sinewave up a bit
<azonenberg> oh derp i forgot to take the terminator off
<azonenberg> that looks more plausible
<Degi> yay
<Degi> Is the period as expected?
<_whitenotifier-9> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-9> [starshipraider] azonenberg c27534c - Updated AcquisitionManager with initial working PoC for a single waveform
<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
<electronic_eel> tek mso 5 series: yellow, cyan, red, green, orange, blue, pink, bluegreen
<electronic_eel> the colors should be easy to create with rgb leds
<electronic_eel> so that each channel can light up in the correct color
<electronic_eel> or one of our probes light up with the correct color, depending in which channel you plug it in
<azonenberg> Yeah
<azonenberg> That will be nice
<azonenberg> I think what we should do soonish is start prototyping the detection and usb stuff for the active probes
<azonenberg> They dont even need to have any probe itself on them necessarily
<electronic_eel> no, just the mcu and usb comms, maybe also the probe power stuff with +-7v or similar
<azonenberg> Yeah i want to get that tested
<azonenberg> hmmm just found a bug in arbitration causing scpi and waveform data to get mixed
<azonenberg> i.e. sending to the wrong socket
<azonenberg> that, understandably, confused the heck out of my scpi code :p
<electronic_eel> hehe
<azonenberg> Speaking of which right now the application is responsible for storing the IP and port of the client
<azonenberg> and the socket handle only stores the seq/ack metadata
<azonenberg> i should fix that at some point
<azonenberg> ok so... firmware reports channel gain in dB
<azonenberg> but the scopehal API uses full-scale ADC voltage range as the native unit
<_whitenotifier-9> [scopehal] azonenberg pushed 3 commits to master [+2/-0/±4]
<_whitenotifier-9> [scopehal] azonenberg 90b0216 - Fixed incorrect log message saying VICP instead of SCPI
<_whitenotifier-9> [scopehal] azonenberg c2a649a - Unit: if printing less than 1 of something, default to milli as the prefix
<_whitenotifier-9> [scopehal] azonenberg 35ded8d - Initial (very incomplete) BLONDEL oscilloscope driver
<azonenberg> all we can do right now is print the *IDN? stuff in the header and query the gain setting
<azonenberg> So there's a lot to do
<azonenberg> But hey, i have scopehal talking to the stm32 on the AFE via the fpga tcp stack
<azonenberg> So lots of building blocks are in place now even if they're not complete
m4ssi has joined #scopehal
bvernoux has joined #scopehal
<miek> nice!
<miek> ship it :p
<azonenberg> lol
<_whitenotifier-9> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-9> [scopehal] azonenberg cbbfe19 - Initial BLONDEL oscilloscope driver can now display waveforms. No configuration support yet, lots of hard coded settings.
<bvernoux> hello
<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,.
bvernoux has quit [Quit: Leaving]
<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