Using an ADS with 4-6 channels

AngelicaMunizAngelicaMuniz Brazil
edited August 2020 in Other Platforms

I am wanting to better understand how the firmware works.

First of all, I would like to inform the reason for my question: the intention is to use ADS1299-4, which has 4 channels. So, what I want to understand is whether any changes to the firmware are really necessary to use it.

In the OpenBCI_32bit_Library.h library, there is the updateBoardData (boolean downsample) function, which, as I understand it, is responsible for requesting the reading of data from the ADS channels.
Part of the function:

for (int i = 0; i < OPENBCI_ADS_CHANS_PER_BOARD; i++)
  {
    for (int j = 0; j < OPENBCI_ADS_BYTES_PER_CHAN; j++)
    { //  read 24 bits of channel data in 8 3 byte chunks
      inByte = xfer(0x00);
      boardChannelDataRaw[byteCounter] = inByte; // raw data goes here
      byteCounter++;
      boardChannelDataInt[i] = (boardChannelDataInt[i] << 8) | inByte; // int data goes here
    }
  }

So, what I would like to know is what ADS responds to when we send this command inByte = xfer (0x00);
Since the intention is to leave the number of default channels, such as 8 channels, knowing if using the 4-channel ADS would not cause problems. But I would only have this security if I knew what this function xfer (0x00) does to ADS even after having finished its number of channels.

If I could sum up the question, it would be:
Would sending this xfer (0x00) command to ADS within the for with more channels than ADS actually has, cause problems? What does ADS respond by sending xfer (0x00) more times than its number of channels?

Thanks.

Comments

  • wjcroftwjcroft Mount Shasta, CA
    edited August 2020

    Angelica, hi.

    Can you clarify, so you are building the Cyton yourself, and want to substitute the 4 channel ADS instead of the 8 channel? Is the price difference that significant that it would outweigh the time spent in possibly working out the firmware mods needed?

    The only way you can know if the 4 channel would work is to try it, and make any firmware adjustments necessary. OpenBCI does not have experience with the 4 channel version.

    [corrected your quoted code segment, see next comment]

    Regards, William

  • wjcroftwjcroft Mount Shasta, CA

    Ah, I see the issue now, your code formatting screwed up. I'll try to correct it. There are TWO nested for loops, not just one as your original post showed. So again, I don't know how the 4 channel version will react to reading extra channels not in the hardware. It might just return zeros, or it might cause other issues. Seems simple enough to adjust the OPENBCI_ADS_CHANS_PER_BOARD define. But that is not to say there may be other sections of firmware that fiddle with 8 channels.

  • AngelicaMunizAngelicaMuniz Brazil

    We have developped our own board that uses the OpenBCI firmware to control the ADS1299IPAGR (8 channels).
    This week I replaced only the ADS with a 4 channel.
    The data received for the last 4 channels were zero, as we wanted. But we believe that it is important to know if it will always be like this, or if we would have to change the value of this variable OPENBCI_ADS_CHANS_PER_BOARD or something else.

    I did other test with the 8 channels changing the variable OPENBCI_ADS_CHANS_PER_BOARD from 8 to 4, and the firmware really only sent the data of the first 4 channels, and zeroes the others. But if it was not necessary to change this variable, it would be perfect, because for applications with 4, 6 or 8 channels I could use the same firmware for everyone.

    I couldn't find in the datasheet about this 0x00 command that xfer sends before reading, nor in the OpenBCI Cyton documentation.

    So, if it is known what this 0x00 command sent via ADS to the serial does, or where I can find that information, maybe it would give me this assurance that the EEG will work as expected.

    Thank you very much for the quick response and attention.

  • wjcroftwjcroft Mount Shasta, CA
    edited August 2020

    https://github.com/OpenBCI/OpenBCI_Cyton_Library/search?q=xfer&unscoped_q=xfer

  • wjcroftwjcroft Mount Shasta, CA

    OK, correction, I was not looking closely at the line numbers. OpenBCI_32bit_Library::xfer(byte _data) is the same as the plain xfer(data) call. It is calling the spi.transfer(data) function. The OpenBCI_32bit_Library.h has these definitions:

    #include <DSPI.h>
...
  // Class Objects
  DSPI0 spi;  // use DSPI library

    So indeed this comes from chipKIT,

    https://chipkit.net/wiki/index.php?title=DSPI

  • wjcroftwjcroft Mount Shasta, CA

    https://github.com/chipKIT32/chipKIT-core/tree/master/pic32/libraries/DSPI

Sign In or Register to comment.

© Vanilla Keystone Theme 2026