<azonenberg>
Update all of your changes to that coding policy and I'll take another look
<azonenberg>
as far as adding/removing channels that's definitely a bug. channels should all be refcounted and disabled when the last reference is removed
<azonenberg>
tverbeure: i don't think the siglent driver was ever "known to work"
<azonenberg>
it was an incomplete WIP
<azonenberg>
that said, normally lecroy's scopes output unsigned 8 bit samples
<azonenberg>
and the siglent-lecroy collaborations have used the same interface
<tverbeure>
Ok. When you do "TEMPLATE?" on the Siglent, you can a full description of the descriptor data format. It shows "byte 08-bit signed data value".
<azonenberg>
Interesting. ok, that might explain some problems then
<tverbeure>
After casting to int8_t, my waveforms start to look better. They are out of range, though: I only see the bottom of the signal, the top gets clipped. Or vice versa.
<tverbeure>
In glscopeclient, is there a way to set the vertical scale?
<azonenberg>
maybe your offsets are wrong?
<azonenberg>
gain and offset are set by scrolling with the mouse wheel on, and dragging, the vertical axis. This simultaneously adjusts the scope settings and UI scale
<azonenberg>
the waveform area is always sized to fit the entire full scale range of the ADC top to bottom
<azonenberg>
if you see things falling off the edge your gain/offset values are wrong somehow
<tverbeure>
Aha! I tried all kinds of scrolling with ctrl, alt and whatever pressed, but never thought about doing that with the mouse on top of the vertical axis. :-)
<tverbeure>
It works now.
<azonenberg>
tverbeure: I'm actively working on the manual to document this sort of thing
<azonenberg>
in the doc/ directory you should see a LaTeX manual
<azonenberg>
it's very much a work in progress but i think i added stuff to describe that last night
<tverbeure>
No worries. As long as you don't mind my dumb questions.
<azonenberg>
honestly? at this point these questions tell me what's wrong with the documentation :p
<azonenberg>
first step, make it easier to find lol
<tverbeure>
The manual is already better than most other open source projects out there. I've been using it just to figure out how to select the right scope interface.
<tverbeure>
So right now, i get the waveform, but scale is totally off (the scope calibration signal is NOT 100V peak to peak!) Also, when I disable channels in the GUI and record, the thing gets into an endless loop.
<azonenberg>
So the gain/offset values the scope uses to convert raw adc samples to volts are probably set wrong
<azonenberg>
try looking at the values in the waveform header that it's pulling out and see
<azonenberg>
the wavedesc on your scope might have different offsets than the lecroy standard
<azonenberg>
so you might need to add some quirks for your siglent vs Error_404's
<tverbeure>
Yes. Should all be easy to fix. I don't expect to be able to spend much time on this in the coming week, so I'll create a pull request on what I have right now.
<azonenberg>
OK
<azonenberg>
just check the coding policy i linked earlier and make sure you match it
<tverbeure>
That's why I asked about the signed/unsigned stuff: if some scopes are signed and others are unsigned, how will we know which one to use?
<azonenberg>
You will probably have to add conditionals based on the scope model
<azonenberg>
that's why the initial *IDN? query is so important
<tverbeure>
If I create a pull request right now, I will probably break his scope.
<tverbeure>
Do you know the exact type of his scope?
<azonenberg>
No. For now, assume your SDS2000 series is the only one that uses this format
<tverbeure>
Ok.
<azonenberg>
and add a check based on that
<azonenberg>
we can then fine tune the checks based on test results from more hardware
juli964 has quit [Ping timeout: 256 seconds]
juli964 has joined #scopehal
juli965 has joined #scopehal
juli964 has quit [Ping timeout: 272 seconds]
<_whitenotifier-c>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfwLy
<_whitenotifier-c>
[scopehal] tomverbeure 1667b58 - Add support for VXI-11 over LXI.
<_whitenotifier-c>
[scopehal] tomverbeure 0a39cf6 - Hacks to make Siglent scope work.
<_whitenotifier-c>
[scopehal] ... and 10 more commits.
<azonenberg>
tverbeure: another thing i see missing is queued acquisition support
<azonenberg>
look at the end of LeCroyOscilloscope::AcquireData() for an example on how to do that
<tverbeure>
I saw that in the LeCroy code. What does it mean?
<tverbeure>
And what's the benefit?
<azonenberg>
basically AcquireData(false) is used in single threaded ATE-type code that sets stuff up, arms a trigger, grabs one waveform, etc
<azonenberg>
AcquireData(true) is used in glscopeclient when pulling data in a separate background thread
<azonenberg>
while the UI and DSP is still handling the old waveform
<azonenberg>
in that model you shouldn't overwrite the channel's current waveform during acquisitions as it can lead to race conditions
<azonenberg>
The UI thread calls AcquireDataFifo() when it's ready for new waveforms, which pops from m_pendingWaveforms and calls SetData() on each channel as appropriate
<azonenberg>
In general all scopehal drivers should be multithreading aware, and assume that arbitrary calls may overlap from different threads. So use mutexing around any access to the SCPITransport stream to ensure serialization when necessary
<azonenberg>
also you should aggressively cache scope settings in any of the Get*() calls because if you make one of those calls from the UI thread during an acquisition, and the cache misses, you have to hit up the hardware
<azonenberg>
Which means waiting until the current acquisition is over to get the mutex
<azonenberg>
Which on deep waveforms on slower scopes could be a fairly long time during which the UI hangs and is ~nonresponsive
<_whitenotifier-c>
[scopehal] tomverbeure opened issue #125: Add queued acquisition mode for SiglentSCPIOscilloscope driver - https://git.io/JfwYW
<azonenberg>
This is why my own custom hardware platforms use two sockets to different ports
<azonenberg>
one for binary waveform data and one for scpi control plane traffic
<tverbeure>
As mentioned earlier, I'm able to see the full signal by first acquiring and the changing the vertical scale. This is a bug that should be fixed
<tverbeure>
However, when you change the vertical scale in glscopeclient, it also changes V/div on the scope.
<azonenberg>
the latter is normal and expected
<azonenberg>
a full scale waveform on the scope should look full scale in glscopeclient
<tverbeure>
This tells me that the nature of glscopeclient is supposed to be a copy of the scope and not an indepedents waveform viewer.
<tverbeure>
But often, you want to zoom in on a special behavior of the wave without changing the acquisition parameters.
<azonenberg>
I have this in the time domain but not voltage, at least for now
<azonenberg>
i.e. the X axis time scale is decoupled from the hardware
<azonenberg>
Y axis is currently coupled because that seemed to make more sense
<tverbeure>
Ok. So, longer term, the Y axis will become decoupled?
<azonenberg>
I'm not sure yet
<azonenberg>
i may add a checkbox to allow configuration locked/unlocked to the scope
<azonenberg>
or something like that
<azonenberg>
this is the sort of thing where user feedback is important
<azonenberg>
i don't yet have enough users to get a consensus of how other engineers work
<tverbeure>
There's a case to be made for both. But as an RTL waveform jockey, it comes as a surprise. Getting scope acquisition parameters right is often tricky, and you don't want these settings to be changed just to observe a recording.
<azonenberg>
True. my thought is that you should always have your acquisition configuration set to maximize dynamic range of the instrument
<azonenberg>
and you normally have a pretty good idea of the amplitude of your waveform in advance
<azonenberg>
or well the peak to peak
<azonenberg>
File a ticket for allowing decoupling and we can get more folks to discuss what makes the most sense
<azonenberg>
(against scopehal-apps since this is a UI issue)
<tverbeure>
One of the reasons I started to look at glscopeclient is because the Siglent GUI is very slow when zooming into a waveform.
<azonenberg>
i imagine glscopeclient is just a wee bit faster? lol
<azonenberg>
heck, it's faster than full MAUI on a LeCroy in some of my benchmarks
<tverbeure>
I hope so1 Right now, it still too buggy to be useful.
<azonenberg>
Fair point
<tverbeure>
The Siglent driver, that is.
<azonenberg>
And yes... better driver support, especially for low cost stuff like siglent and rigol, is IMO one of the biggest blockers to more widespread adoption of glscopeclient
<azonenberg>
So your work is definitely appreciated :)
<tverbeure>
Just to set the right expectations: with all the side project and work going on, I don't know how much I'll really contribute in the future.
<azonenberg>
That's fine. Any contributions are better than zero
<tverbeure>
One thing that should definitely happen is to record and save some of the status information that is being returned by various scopes.
<azonenberg>
what do you mean?
<tverbeure>
For example: the TEMPLATE return data of my Siglent should be stored in some ./etc or whatever directory. If people do that for their scopes as well, there's a record to fall back one.
<azonenberg>
Hmm, we should probably make some kind of data/notes repository for that sort of thing
<tverbeure>
Even simple stuff like the output of "*IDN?" and "*OPT?" would already be useful to, eventually, have regression tests about figuring out which features are present based on name strings etc.
<azonenberg>
that people can send in info for
<azonenberg>
and have some kind of a "dump information" menu option
<azonenberg>
that generates a logfile with info about your opengl configuration, the scope, gtk version, etc
<tverbeure>
Right. Another thing could be a small dump program (base on lxi tools) that just dumps all that kind of stuff. You can ask on Twitter etc to a bunch of people to just run it on their scope and crowdsource the info.
<tverbeure>
Right now, it's not clear at all, for example, which Siglent scopes support raw sockets and which one require VXI-11.
<azonenberg>
Yeah
<azonenberg>
Make a ticket under scopehal-apps for creating a system information tool
<azonenberg>
we can figure out more details later, but it's a good idea
<azonenberg>
Stuff we've tested to date is documented in the manual
<azonenberg>
but that's known to be very incomplete
<_whitenotifier-c>
[scopehal-apps] tomverbeure opened issue #106: Option to decouple changing the Y axis in glscopeclient from changing the Y axis settings on the scope - https://git.io/JfwOv
<tverbeure>
BTW: I bought a Tektronics TDS420A scope from 1995. I want to see if I can get it wired to glscopeclient as well (through GPIB). It might be an entry point that lays the ground work for more modern Tek scopes.
<_whitenotifier-c>
[scopehal-apps] tomverbeure opened issue #107: Tool to dump all kinds of information of a scope to allow crowd sourcing a database with scope information - https://git.io/JfwOt
<azonenberg>
I mean, a SCPIGPIBTransport class would be nice to have at some point
<azonenberg>
that's as good an excuse as any
<tverbeure>
Have you looked for USBTMC drivers? So many cheap scopes have a USB type B port, but there's no standard Linux driver?
<azonenberg>
I thought there was one?
<azonenberg>
Someone here was looking into USBTMC support but i don't know the status of it
<tverbeure>
Just plugged in my scope over USB. It says "usbcore: registered new interface driver usbtmc". I assume this means that there is standard Linux support.
<azonenberg>
Yeah i thought so
<azonenberg>
So a SCPIUSBTMCTransport class should be a fairly simple wrapper around that
<azonenberg>
to open /dev/usbtmcX and talk to it
<tverbeure>
Might be faster too than VXI-11.
<azonenberg>
Very possible. It may also support batching
tverbeure has quit [Quit: Leaving]
<Degi>
azonenberg: You mean the rigol pr for scopehal? Because I didn't modify socket.cpp line 200 at all
<Degi>
Oh I see what you mean with the stars, apparently vscode changed all that when I hit autoformat
<azonenberg>
lol
<Degi>
So like int* x is the same as int *x for the compiler?
<Degi>
Thanks you, I think you should just put it into the top directory of the projects, that way properly configured IDEs should autoformat it neatly
<azonenberg>
Yes that is the plan
<azonenberg>
one thing i need to figure out is that there's a few spots where i use indentation to reflect the GTK widget hierarchy
<azonenberg>
and not control flow
<azonenberg>
and i don't want an autoformatter removing that
<Degi>
Hmmh
<azonenberg>
because otherwise the header file would get hard to read
<azonenberg>
anyway i just finished assembling some boards for a customer, gonna grab some food then make a clang-format
<Degi>
Hmm, Quantel asks me what institution I'm from, wonder if I can just say that I'm a hobbyist... They also ask the serial number of the device. Wonder if they can see who originally bought it?
<azonenberg>
what device are you talking about?
<azonenberg>
odds are good that if you say you're a hobbyist you'll never hear from them again :p
<Degi>
Hmm a 25 year old laser, I wanted a new flashlamp. They asked for serial number, my institution and what its application is
<Degi>
If I were an institution, I'd need a laser safety professional tho...
<azonenberg>
If they hear "hobbyist" they hear "liability"
<azonenberg>
good luck
<Degi>
Hmm
<azonenberg>
if it was something less hazardous than a laser you might have a chance
<azonenberg>
but i think your odds are near zero of getting one direct
<Degi>
Actually I know a place to which I might order it to
juli965 has joined #scopehal
<_whitenotifier-c>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfwEQ
<_whitenotifier-c>
[scopehal] azonenberg d2cdee1 - Updated to latest logtools
<_whitenotifier-c>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfwEd
<_whitenotifier-c>
[scopehal-docs] azonenberg eb57e63 - Fixed missing period in legal section, documented more decodes
<_whitenotifier-c>
[scopehal-cmake] azonenberg pushed 2 commits to master [+1/-0/±3] https://git.io/JfwEF
<_whitenotifier-c>
[scopehal-cmake] azonenberg e826844 - Added .clang-format for coding style
<_whitenotifier-c>
[scopehal-cmake] azonenberg 735355b - Updated to latest submodules
<azonenberg>
Degi: see clang-format. It's not quite perfect, in particular it borks OpenMP pragmas, but i think it's as good as i'm going to get with clang-format for now
<azonenberg>
as far as SetChannelAttenuation() goes, that is indeed ugly (this is the first time i've looked at that code)
<Degi>
Hmh my voltmeter LCD display looks weird and colorful in the presence of high voltages
<azonenberg>
lol i think thats a bad sign
<Degi>
Hmh yeah kinda, you can fold it in the code editor, then you don't have to look at it
<azonenberg>
well yes but i'm thinking of a way to clean it up in general
<Degi>
Maybe multiply by 10000, turn to int, count number of zeroes?
<azonenberg>
what about if you had a static array of attenuation values
<Degi>
Hmh that could work too, and then iterate over it with a for loop to check if the input value matches it and then send the scpi
<azonenberg>
loop over the array, if any of them are within epsilon of atten, send the ideal value with the array
<azonenberg>
and if not, no-op and LogWarning() an error message
<Degi>
Or like that
<Degi>
I thought about converting to int before like I do right now (also why is that 0.1 on a new line?)
<Degi>
Hmm voltmeter shows between 24 kV and 28 kV depending on whether I ground it or not...
<azonenberg>
lol that sounds sketchy
<azonenberg>
i hope you arent touching that meter, i doubt the casing is rated for that kind of voltage
<Degi>
Well I put a 200 MOhm resistor onto a 1 MOhm meter
<Degi>
So the meter reads 120-140 V
<azonenberg>
as far as SetChannelBandwidthLimit() you should not be parsing the model number in the get/set functions
<azonenberg>
Parse in the constructor then store data like the instrument's max bandwidth as member variables
<azonenberg>
the get/set should be as lightweight as possible
<Degi>
Lol sorry thats a leftover
<azonenberg>
in AcquireData(), don't use a semicolon for an empty conditional body as that tends to trigger compiler warnings
<azonenberg>
use {} to make it explicit that no body was deliberate
<azonenberg>
(523)
<Degi>
Oh wait thats not even supposed to be there
<azonenberg>
Lol
<azonenberg>
so the semicolon was a mistake and clang-format put it on the next line
<azonenberg>
this is why code reviews are a thing, lol
<azonenberg>
maxpoints should ideally not be hardcoded in AcquireData, it should be set by SetSampleDepth()
<azonenberg>
and GetSampleDepthsNoninterleaved() should return the set of legal memory sizes for the instrument in question
<Degi>
Whats the bandwidth of DS series scope? 100 MHz?
<azonenberg>
that's the max but it varies by model number
<azonenberg>
DS110x = 100 MHz, DS107x = 70 iirc
<Degi>
Hmh last number is channel count?
<azonenberg>
Yes
<Degi>
maxpoints = sampledepth=
<Degi>
?
<azonenberg>
SetSampleDepth() should also be possible to rewrite cleaner. have a table of legal values then a few if/else's to apply SI scaling suffixes to elements in the list
<azonenberg>
yes
<azonenberg>
also it looks like you are clearing depthValid/rateValid in the Set() functions, why is that?
<azonenberg>
if you just set the value you know what it is
<Degi>
"and GetSampleDepthsNoninterleaved() should return the set of legal memory sizes for the instrument in question" I think it does that? I didnt implement the DS series there yet
<azonenberg>
yeah i hadn't read that far down yet
<Degi>
You mean in line 939/940?
<azonenberg>
anyway you should be able to update the cache in the Set() function, eliminating the need to hit up the instrument to read a value you just wrote. Yeah
<azonenberg>
and 927
<Degi>
Because the scope sometimes changes that to something else
<azonenberg>
... Of course it does
<azonenberg>
Lol
<Degi>
Especially when you set it to auto in SetSampleDepth
<azonenberg>
You should never set auto
<azonenberg>
if you get an invalid input, don't change the depth and print an error
<Degi>
SetSampleRate: You can't set the sample rate, but I worked out a formula that works on the MSO5000 at least that most often gives you the right sample rate
<Degi>
Deleted that line above the logerror
<azonenberg>
yeah i did some ugly hacks on lecroy for the same reason
<azonenberg>
and in that case you should be able to keep depthvalid to true and keep the actual depth in cache?
<azonenberg>
it won't change under your feet?
<Degi>
Hmh not sure
<Degi>
Lemme try
<Degi>
Well when you enable other channels it changes
<Degi>
Also the max depth varies by number of active channels and whether or not the scope has the 200M option
<Degi>
And I guess the DS series has different mem depths too?
<azonenberg>
so they have a fixed amount of memory and they partition based on # of channels
<azonenberg>
Yeah leave things blank for the DS series until we get access to one to test
<Degi>
Well they have 100 M or 200 M for the 5000 series and it isnt obvious from the model #
<azonenberg>
is there a scpi command to query options like lecroy has?
<azonenberg>
as far as memory size changing when you enable/disable channels, if you can predict that
<azonenberg>
it should be possible to add logic to fix the depth in the APIs for doign that
<azonenberg>
i.e. if you enable a second channel with 200M points selected it should notice that this won't fit and reconfigure the instrument for 100M
<azonenberg>
then GetSampleDepthsNoninterleaved() will need to look at the set of enabled channels to figure out the legal depths
<Degi>
Oh yes I can query SYST:OPT:STAT? RL2
<azonenberg>
This kinda ties into a more general API issue, namely that in some scopes the set of memory depths and sample rates varies by enabled channels
<azonenberg>
the whole GetInterleaveConflicts() etc stuff needs to be refactored
<Degi>
How can I see the enabled channels
<azonenberg>
EnableChannel() / DisableChannel() should update caches in m_channelsEnabled
<azonenberg>
anyway the whole apis for dealing with interleaved capture are broken because they assume only 2:1 interleaving
<azonenberg>
but some rigols, and BLONDEL, can do up to 4:1
<azonenberg>
i.e. four channels share one adc
<azonenberg>
so we need to come up with a more general API for this. This is not a solved problem, nor one i've even had time to sit down and think about
<Degi>
Uhh
<Degi>
When I select 1 ch, I can still only select 50 Mpts and sometimes 100 Mpts?
<azonenberg>
So clearly there's more rules we don't yet understand
<azonenberg>
for now, cap max depth at 50M since we know that works
<azonenberg>
we can investigate the details of how to push the limits of the instrument later on?
<Degi>
Now I can do 100 Mpts on ch2
<Degi>
*ch3
<Degi>
The thing is, the max sample rate for 1 ch enabled is now: 4 4 8 2, but sometimes it is like 8 4 4 2 or some other mix and aah
<Degi>
If I only have CH4 enabled I can only set to 25M
<Degi>
But I think when I restart the scope that changes
<Degi>
lemme try
<azonenberg>
well definitely some details we dont understand yet
<Degi>
Ok channel 4 can only do 25 MPTs apparently
<azonenberg>
regardless of what channels are enabled?
<Degi>
Hmh maybe we should make conventions for log messages
<Degi>
Like "bad model number" should give the model number
<azonenberg>
OK i'll go merge this. I think there's still room to improve as far as the giant piles of switches and if/else cascades being turned into table driven implementations etc
<azonenberg>
but it's better than no driver
<azonenberg>
I'm also going to close the rigol driver ticket since i think we're at minimum-viable-product completion at this point
<azonenberg>
we can make new tickets as needed for specific features/bugs
<Degi>
Hmm
<Degi>
Somebody should test on DS1000Z and DS1000
<azonenberg>
i'll poke whitequark
<azonenberg>
she just got scopehal building a day or two ago and has a 1000Z series iirc
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #69: Proper "connect to scope/scopes" dialog if no scopes are specified on command line - https://git.io/JvgaT
<_whitenotifier-c>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jfw6P
<_whitenotifier-c>
[scopehal-docs] azonenberg pushed 1 commit to master [+1/-0/±1] https://git.io/Jfw6A
<_whitenotifier-c>
[scopehal-docs] azonenberg 8eb2321 - Added screenshot of connect-to-scope dialog to manual
<_whitenotifier-c>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jfwie
<_whitenotifier-c>
[scopehal-cmake] azonenberg bfe613b - Updated submodules with connect-to-scope dialog
tverbeure has joined #scopehal
<azonenberg>
So just out of curiosity, i sent an email to my contact at lecroy sales asking how much trade-in value i could get for my waverunner 8104-ms if i upgraded to a 3-4 GHz scope
<azonenberg>
will be interesting to see how much it's still worth. There's a waverunner 8404M-MS on ebay now for $20K
<azonenberg>
(from lecroy official refurb)
<azonenberg>
that's 20/40 Gsps instead of the 10/20 of my 8104, and 4 GHz bandwidth instead of 1
<monochroma>
:o
<azonenberg>
i expect i can probably get somewhere in the 10-12k range for my scope and i don't have 8-10k sitting in the bank, so i won't be able to get the ebay scope. But it's good to know how much they're worth on the secondary market for when i do have budget
<azonenberg>
And i definitely do want a higher bw scope. Yours is the fastest i have access to by far, but it's effectively a sampling scope with a slow realtime mode attached :p
<monochroma>
you can probably haggle them down too
<azonenberg>
Since the sample rate is totally inadequate for 5 GHz signals in realtime
<monochroma>
yeah
<_whitenotifier-c>
[scopehal] tomverbeure opened pull request #127: Fix Siglent SDS2000X acquired data voltage calculation - https://git.io/JfwD6
<Degi>
The 20 GS/s?
<azonenberg>
Degi: monochroma's scope only does 10Gsps with all channels active
<azonenberg>
you only get 20 Gsps if you have two
<azonenberg>
That's the same sample rate as my 1 GHz scope but hers is 5 GHz bw
<azonenberg>
my HDO9204 is double the sample rate, 20 Gsps on all channels and 40 on two, and 2 GHz bw. So exactly double the 8104 basically
<Degi>
huh
<azonenberg>
the waverunner 8000M series has 20/40 Gsps too
<azonenberg>
and is available with up to 4 GHz bw
<azonenberg>
so 4 GHz bw, 20/40 Gsps would be quite nice
<azonenberg>
But i don't have 20 kUSD available to spend on it
<azonenberg>
So it's not happening any time soon
<monochroma>
need to make our own :3
* Degi
solders at 410 °C
<tverbeure>
Shouldn't this be "OFF" instead of "ON" ?
<azonenberg>
tverbeure: wow, how did that happen? must have been a recent copy paste screwup or something as i know that code used to work
<tverbeure>
I will it roll it into my current pull request.
<_whitenotifier-c>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jfw9V
<_whitenotifier-c>
[scopehal] azonenberg d67ff57 - LeCroyOscilloscope: fixed DisableChannel() not properly disabling analog channels
<azonenberg>
Fix already pushed, don't bother
<tverbeure>
:-)
<Degi>
Who even invented the thing that is the absence of thermal connections to vias
<_whitenotifier-c>
[scopehal] tomverbeure synchronize pull request #127: Fix Siglent SDS2000X acquired data voltage calculation - https://git.io/JfwD6
bvernoux has joined #scopehal
Pretzel4Ever has joined #scopehal
bvernoux has quit [Quit: Leaving]
<Kliment>
Degi: How do you mean?
<Kliment>
Degi: thermals are not usually used on vias, only on PTH legs
<Degi>
Hm yes on PTHs
<Degi>
Because I need to heat like 2 or 4 layers when soldering the SMA connector...
<Kliment>
preheat is your friend
<Kliment>
if you don't have a preheater, do the ghetto preheat - hotair the hell out of the area
<Degi>
Hm yeah could've put it into the toaster oven, though that also makes thermal cycles...
<Kliment>
and then solder while it's still hot
<Degi>
I mean if I had 3 hands I'd just hold a mini blowtorch to my iron
<Degi>
Its like 72 joints lol
<Kliment>
Yeah then you really want a preheater - I have a little hotplate for precision rework that's a big heavy steel plate and a PID controller
<Degi>
Hmh I have an aluminium plate which can do like 120 °C
<Kliment>
Yeah that will work
<Kliment>
Preheat to 120 and the iron should manage the rest
<Kliment>
for 4 layer boards I will typically preheat to 100-110
<Kliment>
but a big bulky connector can use the full 120
<Degi>
Its only got like 60 W at 12 V though and not sure whether it can do more, considering that I glued some resistor wire between two aluminium plates with silicone and surrounded it with plastic foam... Originally for drying photoresist
<Kliment>
Yeah you don't need more than 120
<Kliment>
You just want to reduce the delta t to ambient a bit
<Kliment>
sorry, delta between your iron and the board, not to ambient
<Kliment>
And next time use u.fl :P
<Degi>
Meh the eval board was for SMA lol
<Degi>
Hmm if my iron had a builtin solder feeder, I could just heat the irons element with a blowtorch
<Degi>
Or I could use paste then
<Kliment>
Oh yeah if you have low temp paste use that
* monochroma
cringes and runs away
<Degi>
Nah standard tin solder paste, but the mini torch adds a hundred or so watts to my iron lol
<Kliment>
Degi: There's a really fun iron some Japanese manufacturer whose name I forgot makes
<Kliment>
Degi: it's 80W standard but it has a turbo button that gives you 200W momentarily
<Kliment>
monochroma: are you cringing at the u.fl, the blowtorch, or the bismuth?
<Degi>
Ohhh
<Degi>
I have DIY low temp solder too
<Degi>
Its approximately 50:50 Sn bi
<Kliment>
Yeah that will do without preheat
<Degi>
I dremeled it to a powder, it only works semi good tho, maybe rosin with IPA is not so good a flux or the Bi oxidizes bad
<Degi>
Maybe I should try making an induction heated iron, like metcals
<Kliment>
I don't like those at all
<Kliment>
I love the ability to get 20C more temporarily if I need it
<Degi>
Hmh why?
<Kliment>
Only way to change temp on the metcals is tip swap
<Degi>
You could get like 1000 °C more temporarily
<Degi>
Ah yes, they dont have adjustable power?
<Kliment>
Correct - they have a thing that changes impedance depending on temperature
<Kliment>
So the tip composition determines the temp
<monochroma>
Kliment: at the lack of pre-heater :P
<Kliment>
monochroma: Yeah, well, not everyone has one
<Kliment>
monochroma: I have two, but I'm not everyone
<monochroma>
crispy PCBs are sad PCBs
<Degi>
Hmm what if you induction heater the via
<Kliment>
Degi: don't
<Degi>
Or heat it with DC
<monochroma>
you will damage the PCB
<Degi>
Like those coldheat irons but better
<monochroma>
you want even heating
<Degi>
Hmh
<Kliment>
Degi: you will just delaminate your board locally
<Degi>
Or just spot weld it
<Degi>
Does that happen if the joint temperature stays below like 400 °C?
<Kliment>
Yes, if it goes on for too long or in a localized area
<Kliment>
Your via walls will crack
<Kliment>
even if the board doesn't fully delam
<Degi>
Hmmm
<Kliment>
Just preheat it on your Al plate and then use the lowest melting solder you have
<Kliment>
Make sure you preheat with the part inserted
<Degi>
I mean I dont care about that anymore since I managed to get some solder on all the SMAs which should be sufficient but for next time I can do that...
<Degi>
Well the lowest melting solder I have is lead-free almost pure tin... That SnBi I'm not sure of usability and it is a bit hard
<Kliment>
I bought a couple new rolls of SAC305 today because I discovered that slavery-free SAC305 is now available in 0.3mm
<Degi>
I only have 0.8 mm solder lol, I once had 0.3 and I wouldn't recommend that for soldering big cables... Maybe I should keep different solders on hand
<Kliment>
Yeah I mostly use .5 but .3 is nice for rework
<Kliment>
Anything bigger or smaller I'll use paste
<Kliment>
Unless it's really huge in which case solderpot
<Degi>
Well I've soldered 16 mm² wire with a torch before