|
From: | Yann Le Coq |
Subject: | Re: [Discuss-gnuradio] comedi in grc |
Date: | Wed, 10 Feb 2016 15:05:08 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |