azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #scopehal
<_whitenotifier-b> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/JJLDL
<_whitenotifier-b> [scopehal-apps] azonenberg c8a2ead - Improved rendering of frequency domain cursors
<_whitenotifier-b> [scopehal-apps] azonenberg a7429b4 - Prevent getting stuck if file has invalid zoom
<_whitenotifier-b> [scopehal-apps] azonenberg 09fcc90 - WaveformArea: don't interpolate Y values for digital signals, we want them sharp and square
<azonenberg> This is me talking to a DAC60508
<azonenberg> Anybody want to help me figure out what i'm doing wrong?
<azonenberg> i'm trying to read the ID register and getting back nothing remotely close to what the datasheet suggests i should
juli969 has quit [Ping timeout: 264 seconds]
juli969 has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
<miek> looks like, by default, it clocks sdo data out on the rising clock edge - so the r/w bit echoed back ends up shifted?
Degi has joined #scopehal
<miek> oh wait, it's reading SDI on the falling edge??
<miek> azonenberg: ^
<azonenberg> yes
<azonenberg> I figured that out a minute ago
<azonenberg> wtf
<azonenberg> who does that
<azonenberg> also i have to constantly poke registers and enable/disable the spi peripheral because the LCD has normal rising edge SDI
<azonenberg> and as if that isnt bad enough you can't change CPOL/CPHA when the spi peripheral is enabled
<azonenberg> so i have to turn it off to change settings :p
<_whitenotifier-b> [stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JJLSU
<_whitenotifier-b> [stm32-cpp] azonenberg c12c447 - SPI: added SetClockInvert()
<apo> hooray for having four different SPI protocols
<_whitenotifier-b> [scopehal] azonenberg labeled issue #172: SPI: add support for decoding weird modes (CPOL or CPHA not 0) - https://git.io/JJLSt
<_whitenotifier-b> [scopehal] azonenberg opened issue #172: SPI: add support for decoding weird modes (CPOL or CPHA not 0) - https://git.io/JJLSt
juli969 has quit [Quit: Nettalk6 - www.ntalk.de]
<_whitenotifier-b> [starshipraider] azonenberg pushed 4 commits to master [+2/-0/±3] https://git.io/JJLSW
<_whitenotifier-b> [starshipraider] azonenberg 859bb70 - Changed font from 8x16 to 8x15 so we can fit 16 rows of text on the display
<_whitenotifier-b> [starshipraider] azonenberg 51d579d - Added DAC60508 driver
<_whitenotifier-b> [starshipraider] azonenberg 227a160 - Updated submodules
<_whitenotifier-b> [starshipraider] azonenberg c24b89f - Initial DAC config
azonenberg has quit [Ping timeout: 260 seconds]
azonenberg has joined #scopehal
<azonenberg> ok so the comparators and dac are alive now
<azonenberg> i think bringup on MEAD is about done. only thing left is to write the uart command parser to set dac thresholds and channel names remotely rather than hard coding them in the firmware
electronic_eel_ has quit [Ping timeout: 258 seconds]
electronic_eel has joined #scopehal
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<azonenberg> aaand got bit yet again by xilinx optimizing out IBUFDS's
<azonenberg> if you declare an input buffer in your circuit without a KEEP constraint, and it gets optimized out because nothing used it
<azonenberg> the DIFF_TERM goes away too
<azonenberg> and your signal integrity falls apart because there's no termination :p
<Degi> lol
<azonenberg> ok so that's fixed, it seems to work decently out to at least 1 Gbps
<azonenberg> past that i'm not sure yet but that's more than good enough for what i'm using it for right now
<azonenberg> I also discovered a hardware fault on one of my scopes :o
<Degi> Huhh?
<azonenberg> on my 2 GHz scope, when channel 4 is in 20:1 mode, the 100 mV/div range has no signal
<azonenberg> 50 and 200 work
<Degi> Interesting
<azonenberg> so i guess that's the 5 mV/div setting in 1x
<azonenberg> probably a loose connection in an attenuator somewhere
<monochroma> D:
<azonenberg> no idea how long it's been like that, this is the first time i've notiecd it
<monochroma> is that the one you just got back?
<azonenberg> It's the one i bought from TRS in january
<azonenberg> it's just barely past the factory warranty but TRS has a decent warranty on units they resell
<azonenberg> So i should be able to get a no-cost repair
<monochroma> which one did you send off to lecroy ?
<azonenberg> That was the 1 GHz scope, getting the LA module installed
<monochroma> ah
<azonenberg> incidentally that is also the one i plan to trade in for the 4G
hlzr has quit [Quit: Connection closed for inactivity]
<azonenberg> aaanyway so i tested the pod with a pretty decent range of inputs and i'm quite happy with how it's performing
<azonenberg> The two TODOs left are writing some host-side capture code - which i may not bother to do given that this is just a prototyping platform anyway, chipscope is probably sufficient
<azonenberg> and doing the UART command parser to configure the dac and channel names etc
<azonenberg> which is my next thing to work on in a few minutes
<azonenberg> Respun enclosure is at shapeways now, once that comes in i'll try packaging the pod up and giving it more of a "how does it feel" test
<azonenberg> But i think the pod is actually doing really well. The production PCB will likely move the SFF connector a tiny bit towards the back of the chassis for easier unmating, but other than that the PCB seems flawless
<azonenberg> The signals did looks a bit rounded off past about 1 Gbps, almost sinusoidal. So there's some high frequency losses in the SFF cable
<azonenberg> Not yet sure how much this will impact real world performance because i'm sampling with artix7 IOBs at relatively low speed
<azonenberg> i have no concerns about it performing great in the low speed channels of MAXWELL but there's a chance we may hit some bandwidth limitations on the 10 Gsps channels
<Degi> And it looks sharper at the other side of the cable
<Degi> ?
<azonenberg> Don't know, it's awkward to probe in the pod because of the LCD
<azonenberg> I probed at the distal end near the FPGA
<azonenberg> also i was testing with a sinewave input, not a square wave
<azonenberg> which makes the comparator's job harder
<monochroma> can't you remove the LCD for probing?
<azonenberg> No, the backlight is soldered to wires that are now permanently installed
<monochroma> oh.
<azonenberg> i can remove the ribbon from the socket but that wont help much
<Degi> The comparator has hysteresis...
<azonenberg> Degi: yeah but that shouldnt make the output sinusoidal
<azonenberg> Input sensitivity was *really* good, btw
<Degi> I mean that should turn even the worst sine wave into a square wave
<azonenberg> Exactly, so the sinusoidal output at higher freqs is the result of high frequency losses in the cables etc
<azonenberg> Some could also be the ENIG on the exposed diffpairs
<azonenberg> there is likely high freq loss there, at least a dB or so between the two sets of signals
<azonenberg> production will be soldermasked or silver
<azonenberg> anyway I was testing with my VNA which can generate pure sinewave carriers from about 1 MHz to 6 GHz and ampltudes of -20 to +6 dBm
<azonenberg> it got a bit jittery at -20 dBm but at -10 or so i was still getting really nice waveforms off the pod
<azonenberg> and honestly at -20 i think the only limit was i didn't have the scope frontend gain up high enough to trigger nicely on it
<Degi> So at -20 it even halfway worked? That's like 22 mV
<azonenberg> Yes
<azonenberg> So we could use this pod to probe a ~200 mV signal with a 10x probe
<azonenberg> lol
<Degi> lol
<azonenberg> I have zero concerns about sensitivity probing any common CMOS logic family
<Degi> Hmm
<Degi> RSDS?
<Degi> HMCAD in RSDS mode has 150 mV diff output
<azonenberg> It might work fine lower
<azonenberg> i couldnt get less without putting attenuators on the siggen output
<azonenberg> i honestly think the jitter was just the scope trigger not being set right for such a weak signal
<azonenberg> i'll characterize more later
<azonenberg> anyway, i'm done with performance testing for the moment, i have a bit more firmware to write for the uart interface
<Degi> Whats its output swing?
<Degi> Ah, you triggered the scope on the input signal
<azonenberg> Yeah
<azonenberg> I dont remember the output swing, i wasnt measuring using a super great setup
<azonenberg> it was high enough to reliably trigger a 7 series IBUFDS
<azonenberg> Once i have the uart set up so i don't need to recompile the firmware to change input configuration i'll characterize more
<Degi> You can trigger the scope on the output and then measure the jitter on the input signal heh
<azonenberg> Or i could do CDR on the ouput and measure jitter that way, etc
<azonenberg> one of the challenges is probing
<azonenberg> I don't have an active diff probe
<azonenberg> and the board doesn't have as many ground test points near the diffpairs as it should
<Degi> Wind a small transformer
<azonenberg> no the challenges are mechanical i mean
<azonenberg> physically where do i put the probes, how do i hold them, where do i ground them
<Degi> You could wind a small transformer, put one winding across the diff pair and the other to the probe...
<azonenberg> i mean sure if i made a solder-in test fixture i could get great results
<azonenberg> i am likely going to do that at some point
<azonenberg> probably just use the pico 6 GHz probe as it's my fastest probe
<azonenberg> just measure one leg to ground
<azonenberg> I also want to try to set up some kind of means to measure s-parameters of the cable
<azonenberg> maybe i should make a fixture with two sff connectors and some SMAs
<azonenberg> But i don't have a 4-port VNA which will make the data acquisition interesting
<azonenberg> i think in theory i could do several sets of 2-port measurements and massage the s2p's into a s4p?
<Degi> 4 port? Because of diff pairs?
<azonenberg> yeah
<Degi> Hmm, you could add baluns
<azonenberg> that still won't get me the full 4 port s params
<azonenberg> i.e. just differential mode, not common mode
<Degi> Hmm
<_whitenotifier-b> [stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJtf9
<_whitenotifier-b> [stm32-cpp] azonenberg b7c6d52 - FIFO status is now volatile to prevent optimizations from removing some checks
<_whitenotifier-b> [starshipraider] azonenberg pushed 4 commits to master [+0/-0/±4] https://git.io/JJtUT
<_whitenotifier-b> [starshipraider] azonenberg 35bb23a - Updated submodules
<_whitenotifier-b> [starshipraider] azonenberg 00dc6af - AMG240160P: added ClearRow()
<_whitenotifier-b> [starshipraider] azonenberg d900f71 - Finished initial MEAD firmware. Can't read temp sensors but all critical features work.
<_whitenotifier-b> [starshipraider] azonenberg d04d4ec - Can now read pod temperatures via the "t" command
<azonenberg> ok, uart interface is implemented. Super basic fixed format commands
<azonenberg> n3foo sets channel 3's display name to foo
<azonenberg> a210 sets channel 2 to 10x attenuation
<azonenberg> v6400 sets channel 6 to 400 mV threshold (after correcting for probe attenuation)
<azonenberg> and t0/t1 query left/right temperatures
<azonenberg> Possible room for future improvements: there is an ADC input to the mcu with a divided down version of the 12.0V rail that i can use to read the pod supply voltage
<azonenberg> and the mcu also has an on-die thermal diode you can read via the adc
<azonenberg> neither are implemented yet, but neither are critical to basic functionality at this time
<azonenberg> fundamentally, it works
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJtUP
<_whitenotifier-b> [starshipraider] azonenberg 67ba5c0 - Fixed missing "break" causing temp sensors to be read when changing channel Vt
<azonenberg> oops
<azonenberg> is correct url
<azonenberg> lol
<azonenberg> wow i'm sleepier than i thought i guess
<Degi> lo
<Degi> l
<Degi> Looks nice
<azonenberg> did that last one work? :p
<Degi> Do you hand type the URLs?
<Degi> yes
<azonenberg> yeah i uploaded it from my main box and was too lazy to copy the url to my irc vm
<Degi> irc vm?
<azonenberg> As a general rule, if it opens a socket to anything on the internet other than ssh to a trusted endpoint
<azonenberg> it doesn't run on my main dev workstation
<Degi> Hmm okay
<azonenberg> i have a xen server in the DMZ that runs a bunch of different vms for compartmentalized tasks
<azonenberg> i have one for irc, telegram, and skype
<azonenberg> one for facebook and twitter
<azonenberg> one for thunderbird
<azonenberg> one for online banking
<azonenberg> and one for miscellaneous web browsing
<azonenberg> i have some scripts to scp text files full of urls and other content between them but sometimes it's faster just to type stuff
<azonenberg> Until you screw it up four times in a row :p
<Degi> heh
<Degi> Hmm the LCD backlight wasnt on the flat cabe?
<azonenberg> Nope
<azonenberg> it was on two little metal tabs that i thought were mounting brackets
<azonenberg> lol
<azonenberg> they werent in the pinout table
<Degi> haha
<Degi> Wasnt there a 19 V backlight there?
<azonenberg> you had to tilt the display just right and see the "A" and "K" printed on the side of the display body
<azonenberg> No you're thinking MAXWELL
<Degi> Ah
<azonenberg> that's a bigger display
<azonenberg> and full color RGB24
<azonenberg> MEAD's display is monochrome although it does support 5-bit grayscale (I'm not using that capability right now)
<azonenberg> and the backlight is ~3V
<Degi> The x10 means 16.5 V?
<azonenberg> i'm running it off the 3.3V rail through a 10 ohm resistor
<azonenberg> No, it means 165 mV is the actual Vt on the board
<Degi> nice
<azonenberg> and 1.65V is the apparent threshold after a 10x probe
<azonenberg> the user doesnt care about the dac level, the user cares about the signal on the DUT
<azonenberg> "only" 1733 unrouted
<Degi> Oh well
<Degi> On the 40G part the diff pairs are kinda close tot he vias
<azonenberg> You mean the shell?
<azonenberg> I can fine tune the layout later, i'm trying to just get everything placed and approximately routed first
<azonenberg> i expect major tweaks once that's done
<Degi> The 10G pairs further up go very near to the vias of the 10G pairs below
<Degi> oki
<azonenberg> that said i dont think it's a problem?
<azonenberg> there's a huge amount of clearance
<azonenberg> the only possible issue is lane 3 on the top side near the shell mounting hole
<Degi> Oh I think I meant the 1G port lol
<azonenberg> but that's easy to reroute
<azonenberg> not seeing a problem
<Degi> Ah okay, it was kinda too little pixels https://imgur.com/v0bTGhP.png
<Degi> Oh neat, you got a 4k screen
<azonenberg> It's a 40" display too :D
<azonenberg> AWESOME for pcb routing
<azonenberg> you can see the big picture and not miss the details
<Degi> Oh neato
juli969 has joined #scopehal
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JJtmQ
<_whitenotifier-b> [starshipraider] azonenberg 05ad277 - Continued MCU region layout. Rough placement of PSU components near associated regulators.
juli969 has quit [Quit: Nettalk6 - www.ntalk.de]
<azonenberg> rough placed all of the remaining power supply stuff somewhere near their associated modules. Not anywhere near final, but makes the ratsnest a lot less cluttered and at least gives a general impression of where things need to go
<azonenberg> MCU is ~60% routed
<azonenberg> It's super nice working on an 8L board because i can place big bulky power supply stuff on the top layer, support passives under them, and still have two layers available for interconnect routing under them
<azonenberg> not needing to dodge components when routing is amazing
<azonenberg> although the vias still get in the way, but i'm not going to do blind vias on this board
<azonenberg> Just not necessary
m4ssi has joined #scopehal
<Degi> Woo, got a turbopump
Bird|otherbox has joined #scopehal
Bird|ghosted has quit [Ping timeout: 256 seconds]
Bird|ghosted has joined #scopehal
Bird|otherbox has quit [Ping timeout: 272 seconds]
bvernoux has joined #scopehal
<_whitenotifier-b> [scopehal-apps] ggsubs opened issue #129: Failed to create shader - waveform-compute.glsl failed - https://git.io/JJtrf
m4ssi has quit [Remote host closed the connection]
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<_whitenotifier-b> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/JJtMT
<_whitenotifier-b> [scopehal] azonenberg 7a9c0a8 - LeCroyOscilloscope: don't try to deskew digital channels
<_whitenotifier-b> [scopehal] azonenberg 9b561b4 - Oscilloscope: don't fail if no coupling option on a channel when loading a session
<_whitenotifier-b> [scopehal] azonenberg 0a29298 - ProtocolDecoderParameter: use lowercase k not uppercase for "kilo" prefix
<_whitenotifier-b> [scopehal-apps] azonenberg commented on issue #129: Failed to create shader - waveform-compute.glsl failed - https://git.io/JJtMS
<_whitenotifier-b> [scopehal-apps] azonenberg closed issue #129: Failed to create shader - waveform-compute.glsl failed - https://git.io/JJtrf
juli969 has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #scopehal
lukego has quit [Ping timeout: 244 seconds]
elms has quit [Ping timeout: 240 seconds]
futarisIRCcloud has quit [Ping timeout: 260 seconds]
wbraun has quit [Ping timeout: 246 seconds]
sorear has quit [Ping timeout: 244 seconds]
kc8apf has quit [Ping timeout: 272 seconds]
LeoBodnar has quit [Ping timeout: 265 seconds]
juli969 has quit [Quit: Nettalk6 - www.ntalk.de]