Re: High channel count (Ch = 40) DRL issues

Hi Stefan

Thank you for your response, I am a friend of Jeff Joseph's, he was a year ahead of me in high school and I'm in the same research group that he was part of at UCT, what a coincidence he works down the corridor from you.

Thanks for your suggestions, here is what I have done:

1.       I made my own power circuit relying heavily on the power part of the  Olimex digital board design  to handle the higher current requirements, supplying +5V, +2V (for VGND) and AGND. So far there does seem to be a problem with it.

2.       I had the idea of inserting one IC201 chip for every stack of 3 boards to ensure the VNGD is distributed properly. As for the DRL, I have one Master board active as the DRL circuit, and bent the output pin of IC201B (pin 7) of all the Slave boards up  so that IC201B on the TLC277 is not active.  The DRL is then distributed from the Master to the slave boards via the COM pin. My understanding with this arrangement is that IC201A would still fulfil its buffering role for the VGND (the 2V comes from the power supply via the pin header) for each stack but with the output of IC201B disconnected it should have no effect on the DRL. Would this be correct?

3.       I  am wanting to do monopolar recordings using all  40 channels so  I need all the channels to take part in the DRL feed, would setting up the DRL circuit with the Master and Slave arrangement described above be adequate?

4.       I have changed out some of the filter capacitors to deal with the different bandwidth requirements for EMG recordings, so that should be sorted.

5.       I am using a 16-bit NI USB-6225 80 Ch DAQ sampling at +- 5000 S/s per channel (max 250kS/s), the analogue boards are essentially connected directly to the DAQ so all the ADC operations happen there.  The DAQ doesn't support concurrent sampling, but for our application we don't need such high sampling rates. The power supply and DAQ grounds are linked so the signals are essentially referenced at VNGD and swing between 0 and 5V.

Regards
Jeremy

From: Stefan Jung [mailto:[email protected]]
Sent: 19 April 2013 08:12 AM
To: [email protected]
Subject: Re: [Openeeg-list] High channel count (Ch = 40) DRL issues

Hi Jeremy

These sort of hacks are always difficult to implement and less than optimal.  You will spend a fair bit of money on components, connectors, etc. and actually this should be engineered properly.  The R 2500 or so on having a prototype board (with tooling costs) made by Trax is not that much, compared with all the other costs.  Obviously you would need to be able to design your own PCBs.

Here are my comments:

1. I certainly would not use a single opamp to drive such a huge virtual ground circuit.  All those 20 boards would parallel and be seen as a rather low load impedance to that poor TLC277.

2. You would have to substantially redesign the power supply because of your high overall current consumption. So in your case I would rather use a +3.0V and -2.0V linear regulator, creating a dual rail power supply with a REAL ground rather than a virtual ground.

3. Alternatively, keep IC201 on every analog board.  Use IC201A to create a local (PCB) Vground, but remove resistors /modify the circuit around IC201B to effectively disable IC201B.    In this case, only populate C213 on one board but replace the 10nF C203 with a 100nF on every board.

4. I would suggest to only use a limited number of channels to partake in the DRL feed.  Say, channel 1 to 4.  I think that often you will not use all 40 channels...  any channel that takes part in the DRL feed and is not used, is going to stuff you around.  Such channel you need to terminate and you can't leave it floating.

5. In fact, in your case I don't think I would use the centre feed from the INA to derive the DRL.  I would recommend having a separate CMS input which you buffer and then only feed that to the DRL driver.  This is normally what is done in systems with many channels.  Doing this, you never have to worry about terminating any input.  If a unused input then floats and saturates the INA that's OK.

6. EMG normally has wider bandwidth requirements, so you should change your anti-aliasing filter.  But then you obviously need a ADC system that can sample at higher rates such as 1024/2048SPS.

Are you going to use a National Instruments ADC card?  For many EMG applications you need concurrent sampling.  Don't know if NI make cards with many concurrently sampled channels.  Ni/Labview always gives me this idea of pedestian speeds and this would normally exclude the need for concurrent sampling.  But I don't really know their available hardware.  Just that it's expensive.  You would also need to isolate your equipment somehow.

Remember this:  Your ADC will determine if you are going to stay with a +3.0 / -2.0V power supply split, or if you are going to use the more conventional +2.5 / -2.5V rails.  If your ADC can be feed a 4.095V reference, you need to stay with the modeeg voltages.  If your ADC card uses a 5V reference, you need to use +2.5 / - 2.5V.

Are you a buddy of Jeff Joseph?  Jeff is sitting a few offices away from me :-)

Regards
Stefan

### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ###

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1