<bvernoux>
12.5MHz to 6.4GHz with amplitude -50 to +15 dBm
<bvernoux>
good point is it also support ref input 10MHz GPSDO and by default it use a 0.5ppm TCXO
m4ssi has quit [Ping timeout: 272 seconds]
<tnt>
I wouldn't call it a signal generator ...
<tnt>
It has no output filtering so harmonics are not getting any suppression at all.
m4ssi has joined #scopehal
<bvernoux>
yes ;)
<bvernoux>
it is fun for some basic tests but not really for serious things anyway for 200USD ...
<bvernoux>
cannot be compared to some Agilent E44xx Signal Generator ;)
<bvernoux>
in my case i want it in order to test my filter as it has crappy output it is sometimes good to have no output filtered ;)
<tnt>
A few years back I wanted to combine one of those synth (not this one, but an adf based one) and a log power sensor from adi to make a crude filter measurement/sweep.
<tnt>
That failed miserably unfortunately.
<tnt>
Because of course the power sensor is wideband and so it would be sensitive to all the harmonics as well and so the measured sweep response had nothing to do with reality.
<bvernoux>
yes it shall be not used to do any measurement
<bvernoux>
and it shall be advertised like that anyway anyone know that for 200USD you can have something clean like a real measurement instrument which cost 10 or even 100x more
<bvernoux>
can=> can not
<bvernoux>
i consider it like a tone with lot of spurs which could be fine to check some band pass filter ... ;)
m4ssi has quit [Quit: Leaving]
<bvernoux>
what is fun on leo bodnar mini GPS is even when it is off it output signal ;)
<bvernoux>
about -80dBm SIGNAL
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg>
I see a web interface, but to transfer data I need the SCPI port (5025)
<marcos__>
I can connect some test signals
<marcos__>
okay, gimme a moment
<azonenberg>
No rush, i have zero progress on the R&S driver at the moment so it will take me a couple of hours to write up the skeleton of the driver to the point that i can even query signal state etc
<marcos__>
190.103.214.156:5025 should work now
<azonenberg>
Got the ID back so it's good - you can close port 54 now since i don't have any use for the HTTP service
<azonenberg>
I only need the SCPI port
<azonenberg>
Does your scope have the function generator option installed, btw?
<azonenberg>
(not sure if it comes standard or what)
<azonenberg>
And will you be using the scope in the next day or two or do i have exclusive access to it?
<azonenberg>
also it's cool that you have a 10-bit scope, I have not tested my tools on anything but 8-bit so this will give me an opportunity to make sure nothing breaks with higher precision samples
<azonenberg>
(it should be fine, the driver class is the only thing that handles raw samples and I convert to IEEE754 floating-point voltages for rendering and analysis)
<marcos__>
nope, no signal generator here
<marcos__>
I only bought the 350MHz upgrade
<marcos__>
I'll leave the scope online and powered on for about a week
<marcos__>
if I have to use it I'll let you know over here
<azonenberg>
OK i might not have time to do a ton for a bit (still @ $dayjob right now) but tonight into the weekend i'll try banging up the driver and getting it up and running
<marcos__>
I'm preparing a test jig now, that will take me a while
<azonenberg>
yeah not a rush, if you get it by late tonight or tomorrow that would work great
<marcos__>
awesome! let me know if I can help
<azonenberg>
i dont care what the signal is, just try and get a few things of different time scales
<azonenberg>
(at this point in time at least)
<azonenberg>
Too bad you dont have the func gen, i guess i wont be adidng support for that ye
<azonenberg>
yet*
<azonenberg>
but that is incomplete anyway, i have the API defined in libscopehal but there's no UI support for it
<azonenberg>
my wavesurfer 3000 series has an integrated fn gen i partially support but you have to write C++ to use it
<azonenberg>
as far as helping, once i get the driver up and running i'd love if you would run some tests locally
<azonenberg>
its hard to find (especially) performance issues over a slow internet pipe
<azonenberg>
but also the more you use it the more bugs we'll find
<azonenberg>
What OS do you normally use?
<azonenberg>
Right now I'm doing development on Debian, it should work fine on most other linux distros, and is relatively portable so should-in-theory be buildable for windows but to my knowledge nobody has tested yet
<azonenberg>
so it's very likely the first windows guinea pig will encounter problems
<azonenberg>
Another thing i'd love for someone to do is write end user documentation, right now the code is decently well commented but I have no docs on how to actually use it as an EE rather than a software developer :)
<marcos__>
debian was my daily driver for nearly a decade
<marcos__>
now I fell back to ubuntu
<marcos__>
kde neon to be precise
<azonenberg>
They're close enough i wouldn't expect problems building it
<azonenberg>
If you want to try compiling the current code now, it won't work with your scope yet but you can at least get any missing libraries figured out etc
<azonenberg>
you can do out of source builds with cmake no problem however glscopeclient needs to be run from src/glscopeclient right now, i need to work out a proper way of finding all of the shader/color ramp files at some point (there's an open ticket for that)
<marcos__>
I'll try building tomorrow, dayjob now
<azonenberg>
arguments are glscopeclient nickname:api:host[:port]
<azonenberg>
nickname is just something you want to call the scope, it's pretty much ignored if you only have one instrument attached but if you connect to two or more scopes simultaneously it's used to disambiguate channel IDs (you can do protocol decodes across channels from different instruments etc)
<azonenberg>
api is the name of the driver to use, for example lecroy_vicp or (not yet implemented) rs_scpi for your scope
<azonenberg>
then hostname and port if not default
<azonenberg>
connection schema for USB not yet defined
<azonenberg>
For testing experimental code like we have now, you will probably want to add --debug to see more verbose logging on stdout
<marcos__>
great, I wrote that down, thanks!
<azonenberg>
For extreme verbose debugging you can add --trace classname or --trace classname::function but unless you are doing active development in one particular subsystem that should stay off :p
<marcos__>
lol, okay
<azonenberg>
then as far as UI goes, it's mostly mouse driven - mouse wheel on waveforms changes display timescale for that viewport (changing instrument timescale is not yet implemented and will use a separate command)
<azonenberg>
dragging the time bar at top scrolls horizontally
<azonenberg>
mouse wheel on the Y axis changes volts/div for the channel
<azonenberg>
dragging the Y axis will change offset but i dont think i implemented that yet
<azonenberg>
dragging the trigger arrow changes trigger level
<azonenberg>
right click to bring up a context menu for protocol decodes, changing channel coupling/probe attenuation/bandwidth limits etc
<marcos__>
yeah I use a touchpad here, it may get a bit cumbersome
<azonenberg>
the context menu is sensitive to which trace you selected, so if you want to do multilayered protocol decode you need to make sure you right click on the correct decode overlay and not th ebase signal
<azonenberg>
Better touchpad support is on the wishlist, if you have any suggestions on ways to make the UX for laptop users better i'm open to suggestions
<azonenberg>
this is one of the sorts of things i want more users for
<marcos__>
cool
<azonenberg>
anyway i'm off to grab (late) lunch then back to client stuff, we can sync up later
<marcos__>
protocol decoding is my main interest
<azonenberg>
what time zone are you in?
<marcos__>
as I didn t want to pay for that, I have my trusty saleae
<marcos__>
GMT-3 (Argentina)
<marcos__>
can you use saleae code for the protocol analyzers?
<marcos__>
its C++ (Qt), and IIRC its available
<marcos__>
I wrote 2 or 3 protocols for them, a couple of lifetimes ago
<whitequark>
marcos__: the code is available but it's not oss
<marcos__>
booo
<azonenberg>
My architecture is a lot more flexible than most other stuff
<marcos__>
well, I can't complain, they paid for those decoders
<azonenberg>
because it supports things like non-uniform sample rates, sparse traces, etc
<azonenberg>
not all of the decoders handle this (a better abstraction layer for sampling is on the TODO list) but i already have support for synchronous serial protocols where the data and clock have variable or unequal sample rates
<azonenberg>
eventually i want to be able to do math functions between channels from different instruments at different rates with automatic resampling
<azonenberg>
then once you get to higher level things like UART decodes, you can have "ascii sample" objects which, just like "analog sample" objects have both a start time and duration
<azonenberg>
samples are not evenly spaced instants in time in my architecture, they're regions in time which occur sequentially but may not be directly adjacent
<marcos__>
you better get R&S running because I'm excited!
<azonenberg>
Lol i'll work on it this weekend if not sooner, i just can promise results at any particular point in time
<tnt>
azonenberg: if at anypoint you want a remote Agilent 3000-X, ping me :)
<azonenberg>
tnt: i think lain/monochroma have an agilent although i dont remember the specs, i was gonna work on that too
<azonenberg>
agilent support is on the wishlist for sure
<lain>
agilent dsox2024a
<lain>
I'll probably find time to add support in the coming weeks when crunch time is over on the current project
<azonenberg>
Awesome, i guess once you do that we can have tnt try your driver and see if it works on that?
<lain>
sure
<lain>
the 3000x series is very similar to the 2000x so it should be close, at least
<tnt>
yeah, it's even the same programming manual I think.
<tnt>
the 3000-x just has a couple more options.
<tnt>
and I'd be happy to test !
<lain>
:3
<tnt>
Are you writing a network or usb one ?
<azonenberg>
tnt: i'd like to make it modular so you can swap out transports
<azonenberg>
one of the TODOs is to refactor some stuff so i have a Transport object that just takes scpi strings in and out
<azonenberg>
and you can hook any driver to every transport
<azonenberg>
right now i have a SendCommand() / RecvReply() function which works but makes porting a bit more annoyning
<azonenberg>
all of the socket creation/connection code and such should be movable to its own class