On Wed, Feb 10, 2016 at 9:05 AM, Yann Le Coq <[email protected]> wrote:
> 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 Yann, Great work so far, and sounds like it might be a useful addition to gr-comedi. We don't have many users of that library, but I've spoken to a number of labs who are interested. Providing a better solution would be great. Instead of breaking the current block, what I would recommend is adding a second block to support your input/output requirements. For the input, perhaps you could make the number of bits settable by the user (just 16 or 32, probably) and the output type float. Then wrap this up in the GRC XML file for your needs. We'll keep the other block there for backwards compatibility. Thanks! Tom > 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 >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
