Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interference on DAISY_SS (D3) #1

Open
mikeanthonywild opened this issue May 31, 2015 · 4 comments
Open

Interference on DAISY_SS (D3) #1

mikeanthonywild opened this issue May 31, 2015 · 4 comments

Comments

@mikeanthonywild
Copy link

I've been trying to alter the firmware to use the daisychain header to transfer samples to another device via SPI. I've noticed that DAISY_SS picks up a lot of interference from the other SPI lines. Attached is a scope trace of the SPI lines when running unmodified firmware while capturing data from the ADS1299 - note channel 3 (DAISY_SS) is picking up significant interference from the other SPI lines.

DAISY_SS capture

@biomurph
Copy link
Contributor

biomurph commented Jun 1, 2015

Hi mikeanthonywild. Do you have anything attached to the DAISY_SS pin? What board are you using, the 32bit or the 8bit.

If you are using the 8bit Board:

The 8bit Board does not touch the DAISY_SS pin in the Library firmware at all, so it is left floating, and you are likely seeing cross-talk on that pin. Try adding this in your setup() and reprogram the board.

pinMode(DAISY_SS, OUTPUT);
digitalWrite(DAISY_SS, HIGH);

If you are using the 32bit Board:

Well, that's pretty messed up, because the 32bit Board does make the DAISY_SS pin OUTPUT and sets it HIGH so it really should be stable.

@mikeanthonywild
Copy link
Author

Sorry I should have specified, I'm using the 32-bit board. The only thing I have connected to DAISY_SS is a logic analyser. I should add that the trace above, I had set DAISY_SS low as a sanity check. The problem still persists with the default code, except the DC offset is high.

As an aside, I noticed this inconsistency while looking through the code:

csLow(ADS_SS);        //  open SPI
xfer(opcode1);          //  Send WREG command & address
xfer(_numRegistersMinusOne);  //  Send number of registers to read -1
for (int i=_address; i <=(_address + _numRegistersMinusOne); i++){
    xfer(regData[i]);     //  Write to the registers
}
digitalWrite(CS,HIGH);        //  close SPI 

I can't seem to find where CS is defined, but either way, csLow() sets the SPI speed to 4MHz, so when ADS_SS is toggled high again, the SPI speed needs to be set back to the default 20MHz used for the SD card. I'm not sure if this has any impact on the program (I don't have time to check) - I just noticed this inconsistency.

@biomurph
Copy link
Contributor

biomurph commented Jun 1, 2015

Well, that is certainly a bug, Thanks for pointing it out.
It has no effect on the current functionality, because we are not using the WREGS function in our code.
I will fix it, in case others want to use it in future.

I will be pulling my oscope out soon, and take a look at the behavior of the DAISY_SS to see if I can replicate your results.

@biomurph
Copy link
Contributor

biomurph commented Jun 1, 2015

I just scoped a couple of boards here in the OpenBCI lab.
Both 32Bit Boards. The image below Is what I got for both.
Channel 1 is connected to the CS2 pin on the Daisy Bus.
Channel 2 is connected to the SCLK pin on the Daisy Bus.
I do see alittle bit of noise in the CS2, but it is certainly acceptable.
Not sure where your noise is coming from. Can you describe your setup?

daisy_ss scope

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants