<Bird|otherbox>
azonenberg: were you thinking that the sub-boxes within the about box would match the rest of the app theme, or use the stock text/background colors? (black text on white background)
<azonenberg>
I think matching the rest of the app makes sense
<azonenberg>
I expect glscopeclient to be used fullscreen a lot
<azonenberg>
the whole point of the dark theme was to avoid jarring contrast between dark plots and light UI chrome
<Bird|otherbox>
fair enough
Degi has quit [Ping timeout: 260 seconds]
<Bird|otherbox>
pushed a style fix, let me get you a screenshot or two
electronic_eel has quit [Ping timeout: 260 seconds]
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±6] https://git.io/JUyX4
<_whitenotifier-f>
[scopehal-apps] tarunik e72839b - Initial about-box implementation for #175 using Gtk::AboutDialog as a modal. Note that the credits box doesn't yet work correctly, perhaps due to theming issues.
<_whitenotifier-f>
[scopehal-apps] tarunik ae0c664 - Fixed about-box theming for #175 so that everything shows up, at least.
<_whitenotifier-f>
[scopehal-apps] azonenberg 877bf76 - Merge pull request #205 from tarunik/about-box Implement about box (#175)
<azonenberg>
monochroma, Degi, miek, tnt, Error_404, noopwafel, pepijndevos: How did you want to be credited? Right now i have github usernames
<monochroma>
github name is fine, don't really care if i'm credited or not
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUy1D
<_whitenotifier-f>
[scopehal-apps] azonenberg a9b4376 - Minor tweaks to about dialog. Added artists and hardware section.
<_whitenotifier-f>
[scopehal-apps] tarunik commented on issue #206: Add build system glue to display git hash in the about dialog - https://git.io/JUy1H
<_whitenotifier-f>
[scopehal-apps] tarunik edited a comment on issue #206: Add build system glue to display git hash in the about dialog - https://git.io/JUy1H
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUyMv
<_whitenotifier-f>
[scopehal-apps] azonenberg 8c5ed87 - Added tarunik to authors list in about box
<_whitenotifier-f>
[scopehal-apps] tarunik deleted a comment on issue #206: Add build system glue to display git hash in the about dialog - https://git.io/JUy1H
<azonenberg>
Bird|otherbox: so what do you plan to work on next?
<Bird|otherbox>
hm, looking at the git-describe stuff right now
<Bird|otherbox>
do you mind having just a git hash and not a version number for the time being?
<azonenberg>
Yes. That's what i intended to have to start, then add a version number once we've tagged a release
<azonenberg>
Right now it's not mature enough for me to be willing to give it a number :p
<Bird|otherbox>
yeah, git describe --always seems like exactly what we want then
<azonenberg>
Perfect. Then we can remove the --always once we've tagged a release?
<Bird|otherbox>
it's pretty harmless once the tag's in place
<azonenberg>
--always means hash all the time even with a version tagged?
<azonenberg>
i'd prefer to remove it once we have the tag so it's easy to ID releases vs dev versions
<azonenberg>
But that's for the distant future, we're a long ways from me being ready to call it a release
<Bird|otherbox>
--always means display a shorthash for the commit even if there's no tag to be had
<azonenberg>
ah ok
<azonenberg>
but if it's an exact tag match it shows the tag name?
<azonenberg>
and no hash?
<azonenberg>
Or tag+hash
<azonenberg>
Anyway my main priorities for being release ready are an install process, much more complete and up to date documentation, and general improvements to stability and testing
<azonenberg>
including graceful detection of situations we can't run, better error handling in general, a stable and documented save file format that includes all supported instrument settings (right now lots of stuff like timebase and trigger aren't serialized)
<azonenberg>
and of course the preferences stuff and all of the things that are blocked by that
<azonenberg>
Unrelated, the tek 5/6 series programming manual is woefully incomplete
<azonenberg>
A lot of settings i need to use aren't documented
<azonenberg>
But SET? allows you to query all settings
<azonenberg>
So i've managed to figure out a bunch
<Bird|otherbox>
it shows the tag name and no hash if you're on a tag
<Bird|otherbox>
also, it may have to be git describe --always --tags
<Bird|otherbox>
(GitHub's release mechanism uses lightweight tags instead of annotated tags, and git describe needs --tags to pick up on those)
<azonenberg>
Well, for now a hash is fine and we can always tweak it later on once we have a release
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
<Bird|otherbox>
which would you prefer: requiring Git to build from source snapshots in the future, or having a generated header in the source code tree?
<azonenberg>
Bird|otherbox: I'd prefer to have CMake generate a header in the build directory which is included by the about dialog
<azonenberg>
CMake should detect the presence of git and, if not present, emit a dummy file (for example, if you are building off a tarball without revision metadata)
<Bird|otherbox>
ah
<azonenberg>
You might have to do a bit of coding in the cmakelists to do that but i think it's the best overall solution
deltab has quit [Ping timeout: 240 seconds]
<Bird|otherbox>
yeah, the only issue with that approach is "what should go in the version field if we couldn't find Git?"
<azonenberg>
A generic default version string, for now "v0.1"
<azonenberg>
or better yet "v0.1-unknown"
<Bird|otherbox>
okiedokie
<azonenberg>
to make it clear it's not the v0.1 release
deltab has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] tarunik opened pull request #207: Add Git hash/version support to the CMakeLists.txt. Fixes #206. - https://git.io/JUyHV
<azonenberg>
Bird|otherbox: hmmm
<azonenberg>
think it would make sense to add a libscopehal version separately?
<azonenberg>
Probably not
<azonenberg>
at least at this stage
<_whitenotifier-f>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±5] https://git.io/JUyQT
<_whitenotifier-f>
[scopehal] azonenberg 1788668 - Oscilloscope: initial APIs for span, center freq, and RBW. Fixes #278.
<_whitenotifier-f>
[scopehal] azonenberg 759145f - PeakDetectionFilter: fixed detection of peaks when spectrum doesn't start at DC
<_whitenotifier-f>
[scopehal] azonenberg 1b90822 - TektronixOscilloscope: added support for getting/setting span and RBW. See #269.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #278: Design APIs for spectrum analyzers (can we just treat it as an oscilloscope where X axis unit is Hz? separate controls for RBW etc?) - https://git.io/JUoUo
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #208: Hide/gray out statistics menu for digital channels - https://git.io/JUyQq
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #208: Hide/gray out statistics menu for digital channels - https://git.io/JUyQq
<_whitenotifier-f>
[scopehal-apps] azonenberg edited issue #208: Hide/gray out statistics item in context menu for digital channels - https://git.io/JUyQq
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JUyQs
<_whitenotifier-f>
[scopehal-apps] azonenberg d8bd049 - TimebasePropertiesDialog: added settings for frequency domain span and RBW
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #207: Add Git hash/version support to the CMakeLists.txt. Fixes #206. - https://git.io/JUyHV
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+2/-0/±4] https://git.io/JUyQG
<_whitenotifier-f>
[scopehal-apps] tarunik efc55ce - Add Git hash/version support to the CMakeLists.txt. Fixes #206.
<_whitenotifier-f>
[scopehal-apps] azonenberg 7a0327e - Merge pull request #207 from tarunik/about-version Add Git hash/version support to the CMakeLists.txt. Fixes #206.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #206: Add build system glue to display git hash in the about dialog - https://git.io/JUyXY
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUyQl
<_whitenotifier-f>
[scopehal-apps] azonenberg 6587971 - Added "Version " text before git revision in about dialog
<azonenberg>
Bird|otherbox: Ok, merged. what's next on your list?
<azonenberg>
bvernoux: I had a lot of problems with fullscreen on linux but i think i finally got them solved
<azonenberg>
seems windows hasnt fixed them
<pepijndevos>
azonenberg, I feel like playing a bit with analog design in Sky130, but don't really have an analog IC that I personally want. So if you feel like drafting up some minimal/desired requirements for a scope input stage, I think that'd be fun to play with. No guarantee I'll get anywhere, but seems more fun than building some random thing nobody needs.
<azonenberg>
pepijndevos: i guess the basic requirements would be 50 ohm input termination, a fixed gain offset amplifier that takes in an offset voltage from an external DAC
<azonenberg>
then a variable gain amplifier (preferably continuously variable via external DAC reference, but fixed digital steps are probably tolerable worst case)
<azonenberg>
and then a differential output suitable for driving an ADC
<pepijndevos>
uhu uhu
<azonenberg>
Also, is anybody interested in a factory refurb WaveRunner 8104-MS for about $7K (MSRP $22.6K) with full warranty and accessories?
<bvernoux>
azonenberg, ha interesting
<azonenberg>
I know it's a good scope because it used to live in my lab :p
<azonenberg>
It's my old 1 GHz scope that i traded in, lecroy has finished refurb and is now offering it for sale
<bvernoux>
azonenberg, I want a Tek 6B refurbished ;)
<azonenberg>
(the serial number matches)
<bvernoux>
even just the 1GHz BW version ;)
<pepijndevos>
Probably for linearity fixed steps are a lot better. The DAC is going to be discrete anyway right, so doing weird triode stages is probably not a great idea
<azonenberg>
pepijndevos: well my thought was to allow continuous fine steps rather than like 1 dB steps like we have in the BLONDEL frontend
<azonenberg>
but i dont know how hard it is to design a variable attenuator with good linearity in CMOS
<azonenberg>
presumably you'd have a bunch of fixed gain stages then a variable attenuator for fine resolution
<pepijndevos>
hmmm okay, well, it's an interesting idea. We'll see how implementation turns out.
<azonenberg>
bvernoux: the waverunner is only 1 GHz but it's 10 Gsps in 4ch / 20 Gsps interleaved on 2ch
<azonenberg>
so that's a nice bit of sample rate for lowish bandwidth
<bvernoux>
azonenberg, yes clearly a good deal but I really prefer Tek 6-Series ;)
<azonenberg>
Anyway i have no financial stake in the matter, lecroy already bought it from me. Just figured i'd let you guys know because i was very happy with that exact scope
<bvernoux>
azonenberg, it is 50GSPS ;)
<pepijndevos>
What kind or range do you need on the gain for it to be useful? Like... you want to be able to handle pretty tiny and pretty huge inputs, I assume. Combined with a fixed gain, which I assume is just for noise reasons?
<bvernoux>
azonenberg, but so far any Tek 6 refurbished are something like 15KUSD ...
<bvernoux>
or more
<azonenberg>
pepijndevos: So, as a data point: The BLONDEL frontend is designed for +/- 5V input range max
<azonenberg>
I attenuate by 6 dB right off the bat which gives +/- 2.5V range
<azonenberg>
Then I apply a +/- 2.5V offset and clip, to push the signal into 0-5V with a 2.5V common mode (so i can use single rail parts)
<azonenberg>
i believe i have a 12? bit DAC for the offset
<azonenberg>
or is it 16, i cant remember
<azonenberg>
anyway, then comes the gain stage which applies -9 to +26 dB of gain, for a net of -15 to +20 including the frontend attenutor
<azonenberg>
That gives you 0.177 to 10V/V gain
<pepijndevos>
and you apply the offset before the variable gain? I'd think doing it after the gain would give you potentially better resolution at the lower range.
<azonenberg>
pepijndevos: offset has to be done first. You don't want to peg the amplifier
<azonenberg>
imagine adding 20 dB of gain to a signal with a strong DC offset
<azonenberg>
you'd need immense supply voltages to handle that
<pepijndevos>
heh fair enough
<azonenberg>
Finally, I have one more amplifier that adds a fixed 2 dB of gain and applies a common mode shift form the 2.5V the gain stage amplifier expects down to the 900 mV the ADC wants
<azonenberg>
Which gives you a net gain through the frontend of -13 to +22 dB or 0.223 to 12.59 V/V
<azonenberg>
The HMCAD1520 has a +/- 1V full scale range (differential, with a 900 mV common mode offset)
<azonenberg>
assuming we run it in 12 bit mode, at minimum gain we have a 10V full scale input range and get 2.4 mV/LSB resolution
<azonenberg>
assuming a standard scope grid of 10 divisions that would be 1V/div
<pepijndevos>
uhu uhu
<azonenberg>
At maximum gain we have 159 mV full scale range and get 38.7 uV/LSB resolution, which is 15.9 mV/div on a standard scope grid
<azonenberg>
although with 12 bit resolution we could apply a fair bit of digital gain to scale weak signals
<azonenberg>
I'd like a little bit more gain at the low end but that would mean a second variable gain stage since i had already maxed out the amplifier i wanted to use
<azonenberg>
and honestly this is probably enough
<pepijndevos>
Do you have any specific noise and linearity requirements? I guess you can somehow relate it to ENOB of the ADC...
<azonenberg>
I'm not good enough at analog stuff to be able to comment :p
<azonenberg>
The more linear/lower noise the better :p
<azonenberg>
As a general rule, total noise less than 1 LSB would be ideal
<azonenberg>
The HMCAD1520 is 2V range and 12 bit so that's 488 uV/LSB
<azonenberg>
so i'd target 500 uV/LSB noise at the output, at max gain, if possible
<azonenberg>
500 uV total noise*
<pepijndevos>
makes sense...
<pepijndevos>
and bandwidth? DC to.... a few GHz?
<azonenberg>
So there are fundamentally two unique "lines" of scope being developed under the STARSHIPRAIDER project umbrella
<azonenberg>
the first is BLONDEL, DUDDELL, and ZENNECK which tops out at 500 MHz 4 Gsps and uses the HMCAD1520
<azonenberg>
the only difference is the antialiasing filter in the frontend and how many ADCs are used
<azonenberg>
The second line, which will cost a lot more and may never happen because the ADC is $3500 and I don't even want to know what the FPGA and PCB will cost
<pepijndevos>
lol
<azonenberg>
is VOLLUM and MURDOCK, one and four AD9213's per channel respectively
<azonenberg>
targeting 1-2 and 6 GHz bandwidth
<pepijndevos>
oops haha
<azonenberg>
I fully expect these will be completely different frontends
<azonenberg>
Right now I have a working version of the low end frontend, 50 ohm only (1M might be nice to in the future but is NOT a priority)
<azonenberg>
needs more complete testing, the current version isn't as characterized as i want yet but looks good in the limited experiments i've done
<pepijndevos>
Right... I'll focus on the "low end" for now. Seems hard enough for a novice chip designer. Not sure it'll offer anything over your current setup if it works lolsob
<azonenberg>
Trying to reproduce this in ASIC, preferably with finer gain resolution, would be a great project
<azonenberg>
Even if it doesn't beat what i have i expect you'll learn a ton
<pepijndevos>
yah hopefully
<pepijndevos>
I also expect... to run into a lot of problems and hopefully make the tools a bit better.
<azonenberg>
That's the whole point of google's free fab thing
<azonenberg>
The free fab is meant to attract people to use the tools and have them fall on their face due to toolchain problems
<azonenberg>
then fix the toolchain
juli965 has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JUSDZ
<_whitenotifier-f>
[scopehal] azonenberg 9a27ea7 - TektronixOscilloscope: allow setting and querying center frequency of specan channels. Fixes #269.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #269: Support for Tek 5/6 series spectrum channels - https://git.io/JUaaE
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JUSDW
<_whitenotifier-f>
[scopehal-apps] azonenberg ebf06cd - ChannelPropertiesDialog: allow control of center frequency for specan channels
<bvernoux>
azonenberg, do you have a session to share with Tek5/6 including specan stuff ;)
<bvernoux>
?
<azonenberg>
No. I actually think this isn't possible
<bvernoux>
ha ok
<azonenberg>
Because i don't yet save the X axis units of a waveform
<azonenberg>
The save file format is far from complete
<azonenberg>
So i have to add that for it to work
<bvernoux>
it will be interesting when you will have rent a Tek5 to have interesting signals ;)
<azonenberg>
Yeah i will definitely have fun with that
<bvernoux>
I hop you will record some sessions ;)
<bvernoux>
hope
<bvernoux>
It is interesting for non regression tests also on some features
<bvernoux>
I saw you ask for some scopesession on Twitter
<bvernoux>
it will be amazing to create a repository for that like sigrok ;)
<bvernoux>
for each protocol
<bvernoux>
so far I cannot contribute but when I will have a scope supported by glscopclient I could push some I2C, SPI fun stuff ...
<azonenberg>
I have an internal data collection
<azonenberg>
part of the probelm is just that waveform captures are large especially at high sample rate
<bvernoux>
yes it requires some short capture
<azonenberg>
I have 10 GB of test data right now
<azonenberg>
so i'm certainly not putting that on github etc
<bvernoux>
yes ;)
<azonenberg>
also not all of the test data is necessarily sanitized for public release
<azonenberg>
i have at least one for qspi flash that came from $work
<bvernoux>
from a reverse engineering mission ;)
<bvernoux>
For information KiCad 5.1.7 Release is available since yesterday
<bvernoux>
there is very few modification only bug fix
<bvernoux>
everyone is waiting KiCad 6.0 first release ;)
<bvernoux>
I'm using the nightly on non critical project ;)
<azonenberg>
Yeah i'm sticking with 5.1.4 for maxwell
<azonenberg>
(Speaking of which i need to finish it)
<bvernoux>
you should update to 5.1.7
<bvernoux>
they have fixed few bugs since 5.1.4
<bvernoux>
and the risk to break something is very very small
<azonenberg>
maxwell is 99% done, i want stability
<bvernoux>
ha yes ;)
<azonenberg>
i'll update to probably nightly after
<bvernoux>
nightly is sometimes dangerous ;)
<azonenberg>
Also i'm probably going to be sending the v1.3 probe out to fab later today
<bvernoux>
ha great
<bvernoux>
do you have done test with the small tip ?
<bvernoux>
I have not seen any photo test with it
<azonenberg>
No i decided not to
<bvernoux>
ha
<azonenberg>
i would need to adjust the filter for the new resonant frequency
<azonenberg>
while i probably could tweak it with my mill i have better things to do with my time
<bvernoux>
yes it was just to see the drift of the frequency ;)
<azonenberg>
like finishing maxwell
<bvernoux>
a fun project will be to try to do a version (active) with perfect linearity
<azonenberg>
My current strategy is to flatten the response by de-embedding extracted s-parameters
<bvernoux>
so including some filter and some amplifier at end ;)
<bvernoux>
but it is clearly an other type of project
<azonenberg>
In postprocessing
<bvernoux>
anyway a nice 5GHz passive probe is what we need ;)
<azonenberg>
Working on it
<azonenberg>
lol
<azonenberg>
I mean the S21 curve is already very good for 5 GHz
<azonenberg>
It's S11 that i'm trying to optimize still
<bvernoux>
yes
<bvernoux>
it is already the best open source probe available
<bvernoux>
even the 1.5GHz was already the best open source passive probe ;)
<azonenberg>
Yeah lol
<azonenberg>
i was gonna say, this beats most of the commercial probes i've tested it against
<bvernoux>
as there is some open source probes but they are active and go only up to 1GHz
<azonenberg>
The only probe i have left that's better is the >$1K pico
<azonenberg>
And probably the 4 GHz LeCroy active probe i'm buying soon
<azonenberg>
but that's a $3.5K used probe which probably means $7K new
<bvernoux>
yes crazy price for any probe > 1GHz
<azonenberg>
I want to try building an active differential probe of my own. I think i can get much much cheaper
<bvernoux>
the probe are even more expensive than oscilloscope ;)
<bvernoux>
yes an active diff probe is a must have
<bvernoux>
so far I have only one with my CHipWhisperer ;)
<bvernoux>
but it is < 100MHz IIRC
<bvernoux>
and it is manual ;)
<bvernoux>
I'm very tempted to buy this cheap Rigol MSO5074 ;)
<miek>
i think a lot of the used list prices are pretty inflated, i don't see them ever sell for that sort of money
<azonenberg>
I'll let you know how my friend likes it
<bvernoux>
until I can buy a good 40GSPS+ scope ;)
<miek>
i got 1 faulty (that i then repaired) and 2 used 1.5GHz active probes for £500 total
<azonenberg>
miek: The $3.5K is what i plan to buy it for next month. But this is a factory refurb with 3-year warranty and current traceable cal
<azonenberg>
You pay more for that than getting a rando off ebay and hoping for the best
<bvernoux>
Yes I have stopped to buy things on Ebay very old no warranty and expensive for the risk behind to have something which break quickly ...
<miek>
right yeah, it's more reasonable for refurb
<bvernoux>
yes clearly refurb is the way to go for things like scope/SA ...
<azonenberg>
I've found for my use case, factory refurbs are the best choice. About 50% discount from new, and a bit beyond the bleeding edge, but you get really solid hardware in like-new condition with full warranty and such
<azonenberg>
If you go older with no warranty you can get really good deals but it also might break at any point and you've got no recourse
<miek>
i'm fine with the rando ebay deals, you just have to weigh in the risk to the price you're willing to pay
<bvernoux>
miek, yes ;)
<bvernoux>
miek, I played few time on Ebay ;)
<bvernoux>
miek, my VNA I'm still very happy with it
<bvernoux>
miek, my SA a total fail ;)
<azonenberg>
bvernoux: what SA?
<miek>
that's part of why i go for a lot of HPAK gear - you can get a lot of service info
<bvernoux>
my HP 53150A Microwave counter very nice so far ;)
<azonenberg>
I am seriously considering buying one of the signalhound 10gbe RTSAs
<bvernoux>
azonenberg, yes it is a beast ;)
<azonenberg>
if i'm lucky i'll find one on the secondhand market
<azonenberg>
but it's new enough that might take a while
<bvernoux>
azonenberg, and their software seems great too
<azonenberg>
Yeah. And it's a RTSA so you can use it as a 20 GHz rx-only SDR too
<bvernoux>
yes it is clearly a SA+SDR all in one ;)
<bvernoux>
but only RX
<azonenberg>
Literally my ONLY complaint is that power and SFP+ are on the same side of the device as the signal input
<azonenberg>
I prefer RF ports on the front panel and power/control on the back
<azonenberg>
But if that's the only problem with it, i can live with that lol
<bvernoux>
azonenberg, I would have loved they go further up to 26.5GHz for radar stuff
<bvernoux>
as it is limited to 20GHz :(
<bvernoux>
even with decreased performance it will be nice to 26.5GHz
<azonenberg>
20G is more than enough for me
<miek>
everything on my bench was bought used or faulty. the first thing i've had major problems with is this sampling scope mainframe, but at £100 it's worth a punt
<azonenberg>
miek: yeah if you value your money more than your time that's the best choice
<azonenberg>
in my case i have a good salary and nowhere near enough time
<bvernoux>
azonenberg, yes 20G is clearly enough for 99.999% stuff ;)
<azonenberg>
bvernoux: now i just need a 20 GHz scope to go with it :p
<bvernoux>
azonenberg, haha 20GHz BW scope ;)
<bvernoux>
azonenberg, it is 100GSPS minimum ;)
<azonenberg>
Oh, speaking of equipment dreams
<bvernoux>
the price of a house ;)
<azonenberg>
I currently have no signal generation capability
<azonenberg>
other than the dinky sine generator on my VNA
<azonenberg>
It looks like fundamentally there are three classes of generator
<bvernoux>
analog sig gen are still very expensive I do not even speak about RF SigGen ;)
<azonenberg>
there's the stupidly low end sine/square/triangle etc generators, some with arb, that top out at ~25 MHz
<azonenberg>
those are a few hundred bucks
<bvernoux>
yes like the one Rigol include in their scope
<azonenberg>
then there's the high resolution (12-16 bit, 1+ Gsps) ones like the Rigol DG2000 or the LeCroy T3AWG series
<azonenberg>
which cost around $10-15K for ~350 MHz
<bvernoux>
yes :(
<azonenberg>
Then there's vector signal generators that do I/Q modulation but are RF only and can't go down to DC, and often don't actually have that high *bandwidth*
<azonenberg>
so they're basically a low speed i/q baseband and a variable upconverter
<azonenberg>
Then i guess the fourth class is stuff like keysight's stupidly expensive 100 Gsps AWG :p
<bvernoux>
yes RF SigGen are clearly other beast
<bvernoux>
for specific stuff ;)
<bvernoux>
and also ultra expensive especially for something >3GHz
<azonenberg>
In particular, it seems like a DC to ~1 GHz signal generator that does full arbitrary scalar and vector modulation doesn't exist
<azonenberg>
What I want is an AWG that can do DDS sine, square, ramp, etc
<bvernoux>
an alaternative is to buy ERASynth Micro with a very nice filter behind ;)
<bvernoux>
but it is also for RF stuff
<azonenberg>
but can also mix complex baseband data with DDS'd I/Q carriers
<bvernoux>
but can be useful for some analog stuff too
<azonenberg>
i.e. use a single 2+ GHz DAC for direct RF synthesis of a QAM signal
<bvernoux>
azonenberg, anyway to validate the different scope especially 50Ohms you need more a RF SigGen to check different RF properties
<azonenberg>
Yeah i'm thinking for general testing purposes
<azonenberg>
But it seems like i can't get what i want in one instrument
<bvernoux>
yes never see an all in one Analog+RF SigGen ;)
<azonenberg>
I'm wondering why that is
<azonenberg>
basically i want an inverse oscilloscope
<azonenberg>
just a fast DAC hooked up to a frontend
<bvernoux>
hehe
<azonenberg>
that will spit out anything i give it
<azonenberg>
A scope can look at DC or RF or vector modulation etc and decode it in post
<azonenberg>
so why can't i have a siggen that can output a constant DC level or 900 MHz QAM16 equally well?
<bvernoux>
my Agilent E4432B have LF ;)
<bvernoux>
too
<bvernoux>
but it is quite limited for Analog stuff ;)
<bvernoux>
+5V ;)
<azonenberg>
voltage range isnt the big issue for me
<azonenberg>
it's that i want the ability to do things like 1 kHz PWM
<azonenberg>
or even a constant DC level
<bvernoux>
it can
<azonenberg>
then switch to OFDM for the next project on the same generator
<bvernoux>
I have such features on mine
<bvernoux>
with LF port
<azonenberg>
(most vector siggens i looked at had AC coupled output and couldn't do DC)
<bvernoux>
and the RF port is an other one
<bvernoux>
but signals on LF are quite limited
<azonenberg>
yeah I think what i'm going to do, whenever i get around to it
<azonenberg>
will be building a full AWG that does like 2 Gsps
<bvernoux>
mine do DC ;)
<azonenberg>
DC coupled output, probably with a variable gain and offset stage after
<bvernoux>
but it shall be not used as a power supply ;)
<bvernoux>
else it burn in hell after 50mA ;)
<azonenberg>
Lol
<azonenberg>
And then add complex DDS support to it
<azonenberg>
so basically have two FPGA DDS cores for each DAC and multiply their output together
<bvernoux>
yes it is clearly something which could be done
<azonenberg>
or better yet, four
<bvernoux>
I think the industry is very old in mind
<azonenberg>
Baseband I, baseband Q, carrier I, carrier Q
<bvernoux>
and they want to do 2 separate stuff
<bvernoux>
RF & Analog for SigGen
<azonenberg>
then just disable the ones you don't want to use
<bvernoux>
even Rigol do the same
<azonenberg>
Yeah. Meanwhile, i see all instruments as being software defined these days
<azonenberg>
they're basically just a bunch of ADCs and DACs hooked to a frontend
<azonenberg>
So i want to unify stuff as much as physically practical
<bvernoux>
yes ADC/DACs + Custom ASIC/FPGA ;)
<bvernoux>
like all latest oscilloscope ...
<bvernoux>
I'm not sure SigGen are so advanced
<azonenberg>
They're not :p
<azonenberg>
Which is why i think i can do better
<bvernoux>
as anyway it load some point in the dac and do the stuff in loop ;)
<azonenberg>
I see no reason why a modern FPGA can't do complex RF synthesis in real time with some DDS's
<azonenberg>
you can pipeline it nice and deep, you have zillions of multiplier blocks
<azonenberg>
you could even do multi-carrier
<bvernoux>
yes at least up to 300MHz ;)
<azonenberg>
have several different DDS blocks that multiply together
<bvernoux>
it is ultra expensive to have ARB
<bvernoux>
today for SigGen
<bvernoux>
mine is defective in fact in my Agilent
<bvernoux>
but anyway there is no any software working today to do that
<bvernoux>
the HW is from 1990 ;)
<bvernoux>
working on Windows 95 ;)
<bvernoux>
NI have some expensive card to do that
<bvernoux>
you can stream stuff with DAC ...
<bvernoux>
We was using that at my previous work
<bvernoux>
they was crazy expensive for what there is behind
<bvernoux>
just to generate ARINC429 signals what a shame ;)
<bvernoux>
the things behind was a Corei7 with a pseudo realtime OS from LabView a pure joke
<bvernoux>
it was not realtime as all as their was some PCI interruption which disrupt the pseudo realtime ;)
<bvernoux>
a total shame it cannot even maintain 1ms realtime
<bvernoux>
things we can do easily with a poor CortexM0@48MHz ;)
<bvernoux>
so at the end it was something like 6 channels ARINC429 which cannot maintain realtime to generate data ;)
<bvernoux>
and with a Corei7 Quad Core @2.5GHz haha
<bvernoux>
it was WindowsXP Embedded or something like that ;)
<bvernoux>
Conclusion NI+ LabVIEW Real-Time stuff is just bullshit ultra expensive ;)
<bvernoux>
for non developer ;)
<azonenberg>
Lol yes
<azonenberg>
That's what i hope to fix with the scopehal ecosystem
<bvernoux>
yes
<bvernoux>
I'm tired of all that marketing BS we see with LabView and other stuff like that ;)
<bvernoux>
azonenberg, I see Kate advancement with USB3.0 on ECP5-5G Amazing
<azonenberg>
Yeah
<bvernoux>
next step shell will need glscopeclient with a good 20GS scope and Eye Diagram ;)
<bvernoux>
azonenberg, maybe she will be interested by your 2nd Lecroy Scope you sell
<bvernoux>
it can do Eye Diagram with USB3.0 ?
<bvernoux>
with repetitive signal of course
<azonenberg>
bvernoux: I'm not selling it myself. LeCroy already bought it
<bvernoux>
ha ok
<azonenberg>
They're selling it after a refurb (which was probably just a cal job, it was in good shape)
<azonenberg>
I just saw the listing and figured i'd let folks know. It's 1 GHz BW which is probably a bit slow for usb3
<bvernoux>
yes
<bvernoux>
a nice stuff will be to have the features of dslogic-u3pro16 or even the u3pro32 is glscopeclient ;)
<bvernoux>
when you see the price of the u3pro16 it is amazing for 299USD ;)
<bvernoux>
and it clearly work nicely
<bvernoux>
would be fun to try to sniff Etron RPC DRAM with it ;)
<bvernoux>
I saw that GreDavill is testing one
<bvernoux>
Etron RPC DRAM is clearly amazing for nice upgrade of SDRAM for MCU ;)
<bvernoux>
or FPGA ;)
<bvernoux>
I have the datasheet of RPC DRAM ;)
<bvernoux>
it is not SDRAM it is DDR3 ;)
<bvernoux>
clock frequency 800MHz or 933MHz
<bvernoux>
anyway the package is impressively small WLCSP 1.96x4.63x0.545mm !!
<miek>
maybe it's just me, but it's hard to summon up any motivation to improve dlogic's product for them when they've been so hostile so far
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/JUShc
<azonenberg>
miek: i'm thinking more like cheap saleae clones as a target
<azonenberg>
those would be easy to support and open up low end scopehal access for a lot of people
<azonenberg>
The things that are just a fx2 and maybe not even any io buffers
<miek>
oh yeah, fully on board with that. i was just responding to the comment about dslogic specifically
<miek>
i guess one hurdle is demonstrating how a streaming device like that should fit into the api
<azonenberg>
My thought was to do triggering in the server that would make it look more like a normal LA
<azonenberg>
since streaming is not the typically intended use case
<azonenberg>
run it as a separate application that talks to libusb then streams waveform data over a socket to glscopeclient using a modern push-based protocol (no polling roundtrips)
<azonenberg>
do software triggering in the application. we could probably do pretty basic i2c/spi/uart protocol triggers realtime in software with a modern PC
<azonenberg>
it's only a few Mbps of data
<miek>
i guess so, it feels a bit backwards though. the streaming LAs are so useful because you can capture everything. triggering kinda exists just because proper streaming usually isn't possible, right? :p
<azonenberg>
miek: well you can always set the trigger condition to "true"
<bvernoux>
miek, yes dslogic is closed and bad toward open source
<azonenberg>
my thought is that as a user i normally want to see specific events
<bvernoux>
I totally agree
<azonenberg>
and not long periods of downtime
<bvernoux>
but unfortunately their HW is the best for the price
<bvernoux>
azonenberg, for LA use case I usually want to capture long stream and analyze it after the use case is very different vs Scope
<bvernoux>
but realtime could be nice too
<azonenberg>
bvernoux: Yeah, well there's nothing stopping us from not using the trigger on the instrument. I normally find when using a LA I want to look at specific bus packets etc that have long periods of downtime between them
<azonenberg>
so a preprocessing trigger makes sense
<bvernoux>
yes it is useful of course for such type of use case
<bvernoux>
for me i'm more using it to analyze lot of frames and "reveng" the stuff ;)
<azonenberg>
Yeah but what i find more useful for that is to ahve a trigger on each packet/burst of data
<azonenberg>
then use the glscopeclient protocol analyzer to crunch it
<bvernoux>
Ha yes to crunch it in background to have all at end anyway ;)
<miek>
ideally as a user i want to capture everything, then do some processing afterwards
<bvernoux>
so we have advantage of both
<bvernoux>
miek, like me in 99% of use case with LA
<azonenberg>
miek: yeah. my proposal is to have a "null"/"auto" trigger that just returns fixed size data blocks back to back with no gaps
<azonenberg>
(user configurable size)
<bvernoux>
as anyway we have no choice with actual poor GUI ;)
<azonenberg>
but then allow you to also sync to a trigger event on request
<bvernoux>
PulseView, Salae stuff does not support realtime display like scope
<bvernoux>
it is mainly a limitation on PC side...
<miek>
ok yeah, that sounds good to me
<bvernoux>
azonenberg, do you plan to support cheap LA soon in the long list of things to do ?
<azonenberg>
bvernoux: soonish would be handy because it would let me prototoype some architectural stuff i need for maxwell etc
<bvernoux>
ha yes great
<azonenberg>
Current priority is finishing tek 5/6 series support though as far as drivers go
<bvernoux>
and it will bring lot of people I think
<azonenberg>
then i have a few more LeCroy trigger types to implement still
<bvernoux>
to gain popularity
<bvernoux>
especially with cheap LA for 7USD ;)
<bvernoux>
which can do amazing stuff even just at 24MHz ;)
<bvernoux>
I could release a secret project for that to have USB 3.0 streaming for less than 99USD for LA ... ;)
<azonenberg>
using kate's ecp5 usb3 stack?
<bvernoux>
as what is missing is a USB 3.0 Ethernet Gigabit LA which is cheaper than 200USD ;)
<bvernoux>
azonenberg, no using an ASIC ;)
<azonenberg>
Lol
<bvernoux>
it is a secret project ;)
<azonenberg>
I see
<bvernoux>
a cheap chinese asic ;)
<bvernoux>
I still do not know what is the price
<azonenberg>
well, if hardware shows up i'll work on support as time permits
<bvernoux>
it is the one which do all ;)
<bvernoux>
Ethernet Gigabit SerDes, USB 3.0 Device/Host ;)
<bvernoux>
all embedded in a RISCV
<bvernoux>
the RISCV is just a controller
<azonenberg>
but right now what i need more than anything else is core development. There's a lot of work needed on rendering, file load/save, general application stability, etc
<azonenberg>
And documentation
<bvernoux>
yes more user does not means more developers/contributors ;)
<bvernoux>
I have seen that on AirSPy project
<bvernoux>
more than 10K units sold and not even 5 contributors ;)
<bvernoux>
and the Firmware is fully open source with tools ;)
<bvernoux>
So it is a good lesson ;)
<bvernoux>
It could have been totally closed source in such area (mainly HAM guys and few SDR guys/hackers)
<bvernoux>
It is also why I will probably never release the schematics/board I have done on KiCad since the start ;)
<bvernoux>
What for as there is no any contributors/developer ...
<bvernoux>
maybe that will help the bad cloner to do something better ;)