|
From: | Tom Rondeau |
Subject: | Re: [Discuss-gnuradio] comedi in grc |
Date: | Wed, 10 Feb 2016 09:54:43 -0500 |
Hello,
In the process of writing the xml files for gr-comedi in grc and testing the result, I believe I am getting in an gr-comedi issue.
The only comedi board I have access to is a USB-DUX Sigma, which outputs ADC data in the comedi type "lsampl_t" (32 bits per sample). The gr-comedi module, however, is hard coded for the comedi type "sampl_t" (16 bits per sample only).
The only way I see to make this work for the USB-DUX Sigma (or any other >16bits ADC equipped board) is to modify the gr-comedi module C source itself, so as to accomodate 32 bits ADC devices.
If I were to do this, I would, however, be tempted to change the output type entirely. The way it is done now, the comedi-device is expected to return "sampl_t" type raw data (unsigned 16 bits), which are then shifted down by -32767 and the resulting "signed and hopefully zero-centered" data is output as a short. There might be a good reason for that, but it seems more likely to be a quick hack, that has the drawback of making the whole module interface too device-dependant, IMHO.
The comedilib standard way would rather be to use the comedilib function "comedi_to_phys()", which takes raw data and makes it a float that actually represents a physical value (a voltage for example) based on the channel/board configuration (unipolar/bipolar, ADC range, etc.). This function helps a lot providing device-independence and I don't see good reason why gnu-radio shouldn't be using it. In fact, I don't see why one would want to have access to the raw data itself from gnuradio, especially if it means changing the output type depending on the device being used... Getting a physically meaningful float output seems to make ways more sense.
Doing this modification would, however, break backward compatibility with pre-existing gr-comedi-using top_blocks, so I am a bit hesitant and would like some feedback before investing the time that is necessary to make this change.
Best regards,
-Yann
Le 01/02/2016 18:19, Marcus Müller a écrit :
Hello Yann,
no, you're not missing something; I don't remember there ever being GRC
XML files for gr-comedi, but if there where pre-3.7, they might have
gone away during the restructuration for 3.7; and, as there seemed to be
very little interest in getting gr-comedi to work from within GRC....
At any rate, since the sink and source have no own method and their
ctor/make functions only take sample rate and device address string as
arguments, copy&pasting together a valid XML file should be done very
quickly. However, I (used to think that I) don't know anyone who has
uses comed to talk to a data aquisition or signal generation device –
which would be useful for testing.
So, would you be willing to contribute such XML?
Best regards,
Marcus
On 01.02.2016 18:00, Yann Le Coq wrote:
Hello,
Unless I missed a point in compilation from source, there doesn't seem
to be a grc blocks for the comedi driver gnuradio interface in a
standard installation (origin/maint commit
11973c64437683cc99c48eae9eb4db8234f1ac42). Indeed, in the source code,
there is no /grc sub-folder in the gr-comedi folder to define the .xml
files.
Am I missing something, or is there a place somewhere where this can
be found ?
Thank you for your help.
-Yann
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |