On 06/28/2016 06:25 AM, Piotr Krysik wrote:
>
> Hi Marcus,
>
> It's great to hear that there is interest in using the block. I can
> change how parameters are displayed but I don't have clear idea how to
> do this so the user experience with for a systems with 8+ inputs will be
> improved. I can separate RF options to another tab but it won't improve
> much - you will still have a very long list of parameters that you will
> have to scroll.
>
> I can do this - it is not any problem for me (actually I already did
> this after your post:
> https://github.com/ptrkrysik/multi-rtl/commit/dfda15b5332cafb7da9288707fc9c58be91370b6).
> But in my opinion if you want to have more than 8 inputs you can
> consider coding the flowgraph in Python. GRC might be cumbersome in
> itself when you have blocks with
> so many ports.
Just tried it out. I like the new layout. Tried it with 4 ports, and
it's quite manageable.
> Regarding the coherent operation - I have to play with the driver
> prepared by you. If it works fine - it is the way to go in my opinion.
> Some people might still need dithering (i.e. because they don't care
> about coherency but want to set the frequency more precisely). One
> solution for this might be some additional option in the gr-osmosdr
> block that turns on/off dithering. Or if frequencies for which dithering
> is used can be easily listed/computed - then dithering can be just not
> used when the user sets frequency that doesn't require it.
Indeed, my fork includes API for turning on/off dither, which I
inherited from keenerd. But without gr-osmosdr support, I needed to
force it.
>
> Best Regards,
> Piotr
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment