Hi Uwe,
I did not follow the discussion regarding the transform feature in details,
but if I understand it correctly, it should work on streamed data.
I would ask for two features:
1. ability to have a different types of data on each side, for example a
raw digital analyzer input and decoded UART asci stream as output, this
requires the transform code to keep a state, but so would a decimator
2. option to write transforms using OpenCL this would be practical for
oscilloscopes to add SDR functionality
3. multiple input streams might be also useful for SDR
4. having the same capability for streaming signal generators
Regards,
Iztok Jeras
PS.:
I work for Red Pitaya from February, but I do not have the time to discuss
it right now.
On Wed, Feb 11, 2015 at 5:05 PM, Uwe Hermann <u...@hermann-uwe.de> wrote:
> Hi everyone,
>
> I've pushed a first, very simple and work-in-progress version of the
> generic "transforms" framework we wanted to have in libsigrok for quite
> a while now (and the respective sigrok-cli support for it).
>
> A "transform" is basically something that takes one packet (analog or
> digital or other) and outputs a packet (or NULL, i.e. no packet).
>
> A few simple ones are implemented for now:
>
> - nop: Do nothing; take the packet, output it again unmodified.
>
> - scale: For every analog packet it gets it will scale (multiply) the
> analog
> (float) value by a specified factor. Any packets other than analog
> ones are ignored and passed on unmodified.
>
> - invert:
> - For analog packets: outputs the same packet, but analog values x
> are changed to 1/x.
> - For logic packets: Every 0 probe becomes 1 (and vice versa).
>
> There are *many* further transform modules that can be written and
> should prove highly useful, e.g. "add", "subtract", "multiply", "divide",
> "average", "adc", "dac", "downsample", "upsample", and lots more.
>
> I'm currently in the process of writing a few more, e.g. "adc" which
> will convert an analog channel to a digital one (using a "threshold"
> option that specifies which analog values are to be considered "high"
> and "low").
>
> Implementations for other modules and ideas for useful ones we should
> consider adding are welcome!
>
>
> Here's a few examples of what is currently possible with this initial
> draft version:
>
> $ sigrok-cli -d demo:analog_channels=1:logic_channels=0 --samples 2 -T
> nop
> A0: -25.000000 V
> A0: -25.000000 V
> A0: 0.000000 V
>
> $ sigrok-cli -d demo:analog_channels=1:logic_channels=0 --samples 2 -T
> scale:factor=3.5
> A0: -87.500000 V
> A0: -87.500000 V
> A0: 0.000000 V
>
> $ sigrok-cli -d demo:analog_channels=1:logic_channels=0 --samples 2 -T
> invert
> A0: -0.040000 V
> A0: -0.040000 V
> A0: inf V
>
> $ sigrok-cli -d demo:analog_channels=0:logic_channels=1 --samples 192 -T
> nop
> D0:10001111 00001111 10001111 00001111 10001111 01110111 11111111
> 00111111
> D0:10001111 00001111 10001111 00001111 10001111 01110111 11111111
> 00111111
> D0:10001111 00001111 10001111 00001111 10001111 01110111 11111111
> 00111111
>
> $ sigrok-cli -d demo:analog_channels=0:logic_channels=1 --samples 192 -T
> invert
> D0:01110000 11110000 01110000 11110000 01110000 10001000 00000000
> 11000000
> D0:01110000 11110000 01110000 11110000 01110000 10001000 00000000
> 11000000
> D0:01110000 11110000 01110000 11110000 01110000 10001000 00000000
> 11000000
>
>
> There are *many* missing features, as well as various design and
> implementation problems and bugs. Please don't consider this as a
> finished feature yet, it's more of a preview of where we're aiming at
> with this; lots more work is required to make it all useful.
>
> Any reviews, comments, suggestions are highly welcome of course.
>
> Here's a short and incomplete list of TODOs and issues:
>
> - Most modules will need a "channels" option to specify on which
> channel(s) they should operate. Currently they're all hardcoded to
> affect all channels.
>
> - (C++) bindings need to gain support for this (e.g. to make this feature
> available to frontends like PulseView and sigrok-meter).
>
> - Various design/technical issues need to be sorted out, e.g. who frees
> what and when; how to let frontends know that a transform is
> generating a "new channel" that has nothing to do with any physical
> channel that may have been present on original device, etc. etc.
>
> - Currently multiple transforms can be chained linearly; later on we'll
> likely want some "pipes-and-filters"-style, "flowgraph" based system
> with more flexible facilities.
>
> - Options may need some more metadata, e.g. frontends may need to know
> which options are required or optional, which ranges of values are
> allowed etc. etc.
>
> - lots more...
>
>
> Uwe.
> --
> http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> sigrok-devel mailing list
> sigrok-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
