azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
someone--else has quit [Quit: Connection closed]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 250 seconds]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 250 seconds]
someone--else has joined #scopehal
<_whitenotifier-a> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JZYAj
<_whitenotifier-a> [scopehal] azonenberg bdaf7c9 - TouchstoneParser: support real/imag format as well as just mag/angle
<GyrosGeier> oh boy
<GyrosGeier> I need to play with the POWER stuff more
<GyrosGeier> they have interesting hardware
<GyrosGeier> yesterday I found that I can gzip with 1.4 GB/s with a special coprocessor
<GyrosGeier> let's see if they also have something useful for DSP
<GyrosGeier> and also if I can somehow make this stuff visible to OpenCL
<azonenberg> interesting
<azonenberg> note that right now glscopeclient only looks for opencl devices that report themselves as GPUs
<azonenberg> so you might have to patch that code to use more obscure accelerators
<GyrosGeier> I mean, I have an FPGA card with PCIe, I could just write a few functions
<GyrosGeier> convolution should be simple enough
<GyrosGeier> I shall not be nerdsniped though
<azonenberg> Exploring FPGA acceleration for glscopeclient has been on my list for a while. But i doubt it will be worthwhile
<GyrosGeier> well, I'd hide it in OpenCL
<azonenberg> most of the numerically intensive filters are floating point heavy
<azonenberg> no i mean hardware wise
<azonenberg> GPUs typically beat FPGAs in floating point performance
<azonenberg> even if you have the FPGAs with hard FPUs
<azonenberg> also the sheer ram bandwidth available on most GPUs
<GyrosGeier> hard FPUs tend to be singular
<GyrosGeier> but a FIR that uses three multipliers per tap can go a long way
<azonenberg> anyway, you're welcome to try but unless you converted everything from ieee754 to fixed point and back (which would probably consume more time than you'd save by running on the FPGA)
<azonenberg> i doubt it would help much
<GyrosGeier> if you only need multiplication and addition, ieee floats should be doable in FPGAs
<GyrosGeier> addition is a bit more expensive because of the barrel shifters
<azonenberg> I do subtraction in some filters, although i keep fdiv's to a minimum
<azonenberg> and i'm not saying it cant be done
<azonenberg> I'm just questioning the flops you can get vs a gpu
<GyrosGeier> yes, the flops are bad
<GyrosGeier> but data dependencies can be handled way better
<GyrosGeier> for FIR it should be somewhat even
<GyrosGeier> for IIR, I'd expect the FPGA to come out ahead
<azonenberg> Yeah, I don't have any IIR filters at the moment though
<azonenberg> The big numerically intense stuff that I opencl accelerate atm are FFT, FIR, and de-embedding
<GyrosGeier> FFT is going to be annoying on FPGA
<miek> can confirm, i've spent the past few days staring at gtkwave trying to figure out why my FFT isn't working right :p
<GenTooMan> :D
<GenTooMan> I had something weird going on with dealing with Sigilent and glsscopeclient for some reason after capture of data occasionally the next PollTrigger command causes the prior header from a RawRead to be returned.
<GenTooMan> well it was a big problem mostly because the client would segfault randomly afterward also. :/
someone--else has quit [Quit: Connection closed]
balrog has quit [Quit: Bye]
bvernoux has joined #scopehal
<bvernoux> azonenberg, I have modified the connector 901-10510-2 (length and hole size mainly)
<bvernoux> i have added +0.02mm on the hole size as it seems lot of manufacturer have about +/-0.08mm errors and so I have added a margin of 0.1mm
<bvernoux> so it is 0.82mm it is not clear if that will be enough to avoid using hammer or if there is a risk the connector is too loose (with worst case 0.828mm for the hole instead of expected 0.8mm)
<bvernoux> in fact hole diameter is specified to be 0.81mm ;)
<bvernoux> and Amphenol specify that for dimension 0.5 - 6mm tolerance on connector is +/-0.1mm ...
<bvernoux> so it is not easy to find a good rule for the hole size which seems pretty critical for good placement
<bvernoux> what is missing is a recommended footprint ;)
_florent_ has quit [*.net *.split]
agg has quit [*.net *.split]
GyrosGeier has quit [*.net *.split]
GyrosGei1r has joined #scopehal
_florent_ has joined #scopehal
agg has joined #scopehal
GyrosGei1r is now known as GyrosGeier
agg is now known as Guest958
<azonenberg> bvernoux: yeah I'm going to tweak mine a bit but i havent figured out exactly how uch
<azonenberg> me and derek are going back and forth with sonnet support trying to optimize my sim models to better match the first rev VNA data
<bvernoux> I have asked to Amphenal RF if they can provide a recommended PCB footprint ;)
<azonenberg> so i can spin a second board with more precisely tuned footprints
<bvernoux> AMphenol
<bvernoux> I plan to test my footprint with PCBWay 4 Layers
<bvernoux> on their 4 layers standard PCB stackup Conductor Height are 0.11 mm with Er 4.29
<bvernoux> so it is better than on standard FR4 in fact for a very correct price
<bvernoux> I have computed that with using Conductor Width (W) = 0.219 mm, Condutor Height (H) = 0.11 mm & Conductor Gap (G) = 0.219 mm I will obtain Z0 = 50.14 Ohms
Guest958 is now known as agg
nelgau has joined #scopehal
someone--else has joined #scopehal
<bvernoux> azonenberg, woo ultra fast Amphenol RF have replied with latest drawing which include the footprint
<bvernoux> hole size are 1.14mm (+/-0.05 typ)
<bvernoux> so clearly different than 0.81mm ;)
<electronic_eel> hmm, if 0.81mm did just barely not fit, isn't 1,14mm going to be to loose, so the placement will become inaccurate?
<electronic_eel> by gut-feeling i'd try 0.9 or 0.95mm
<bvernoux> yes I confirm 1.14mm is too large !!
<bvernoux> their recommended footprint is wrong !!
<bvernoux> yes it seems 0.95mm is maybe the best compromise
<bvernoux> depending on the fab which could use 0.9mm and when including plating ...
nelgau has quit [Remote host closed the connection]
someone--else has quit [Ping timeout: 245 seconds]
bvernoux has quit [Quit: Leaving]
someone--else has joined #scopehal
<someone--else> btw, these connectors are supposed to be aligned via an external jig (or hand-help perhaps)
<someone--else> not via any pcb features
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 252 seconds]
nelgau has joined #scopehal
someone--else has quit [Ping timeout: 245 seconds]
someone--else has joined #scopehal