RHD2000 amplifier data :: sampling rate, channel renumbering, DC offset

680 views
Skip to first unread message

jorge.cla...@gmail.com

unread,
Apr 20, 2016, 8:36:52 AM4/20/16
to Bonsai Users, Armando Miguel Caseiro Pires Remondes
Dear Gonçalo Lopes, 

We are running a control test with RHD2000 acquisition system connected to a single Intan RHD2164 amplifier board using the SPI cable.


RHD2164 amplifier board channels 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44 and 46 are connected to a signal generator so that we can track signal processing pipeline. 

Bonsai test flow is mainly composed of RHD2000, AdcScale and SelectChannel nodes.


Please consider the annex files. 

We found that by changing the sampling rate on RHD2000 node (offline configuration), the channels are renumbered and a DC offset component is added to the original signal. Similar results are found when using MatrixWriter to write amplifier data directly to a binary file. 

 

Can you please help finding the root cause? 







Best regards,

Jorge Cardoso
000_T2_30kSamples_sec.png
000_T1_10kSamples_sec.png

Gonçalo Lopes

unread,
Apr 20, 2016, 9:18:03 AM4/20/16
to jorge.cla...@gmail.com, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Hi Jorge,

Interesting, we never noticed this. What sampling rates are you switching between? This may be something related to the Intan firmware itself.

Can you check if this happens on Intan's software? Would be good to compare both. Make sure to update Bonsai.Ephys to the latest version and also include the workflow as attachment so I can try it directly later.

Hope this helps,
From: jorge.cla...@gmail.com
Sent: ‎20/‎04/‎2016 13:36
To: Bonsai Users
Cc: Armando Miguel Caseiro Pires Remondes
Subject: [bonsai-users] RHD2000 amplifier data :: sampling rate, channelrenumbering, DC offset

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/bonsai-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/21bef524-3041-46cc-820c-975d07797c23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gonçalo Lopes

unread,
Apr 20, 2016, 9:19:22 AM4/20/16
to jorge.cla...@gmail.com, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Also, what exact hardware are you using? Open Ephys? Which bitfile are you sending to the FPGA and where did you get it from?

Best,
G
From: jorge.cla...@gmail.com
Sent: ‎20/‎04/‎2016 13:36
To: Bonsai Users
Cc: Armando Miguel Caseiro Pires Remondes
Subject: [bonsai-users] RHD2000 amplifier data :: sampling rate, channelrenumbering, DC offset

--

Jorge Miguel Claro Cardoso

unread,
Apr 20, 2016, 2:56:12 PM4/20/16
to Gonçalo Lopes, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Dear Gonçalo,

I'm using Open Ephys acquisition board with Opal Kelly brdXEM6010LX45, firmware version 3.1. 

I've tested the bit files available here (except usbv3 variant not supported by the type of board I'm using):



Tested also the version available @ INTAN website:



Bit files are correctly loaded but the aforementioned system behavior is the same.

Do you have any specific bit file previously tested I can use?





Best regards,

Jorge Cardoso

Gonçalo Lopes

unread,
Apr 20, 2016, 6:55:48 PM4/20/16
to Jorge Miguel Claro Cardoso, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Can you attach the workflow you were using for the tests along with the bitfile? Also can you tell me the sampling rates that caused the problem?

I will try and reproduce the situation on our hardware and let you know what happens.

Best,
G
From: Jorge Miguel Claro Cardoso
Sent: ‎20/‎04/‎2016 19:56
To: Gonçalo Lopes
Cc: Bonsai Users; Armando Miguel Caseiro Pires Remondes
Subject: Re: [bonsai-users] RHD2000 amplifier data :: sampling rate,channelrenumbering, DC offset

Jorge Miguel Claro Cardoso

unread,
Apr 21, 2016, 5:08:25 AM4/21/16
to Gonçalo Lopes, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Please consider the annex file, including the Bonsai workflow, the bit file and the RHD2164 . The channel numbering seems compatible with RHD2164 pinout @ 10kSamples/s and is the same as acquired by the INTAN software (using INTAN bit file). The channel numbering is different @ 30kSamples/s only with Bonsai but not INTAN SW.




Best regards,

Jorge Cardoso 
RHD2164_debug_info.zip
RHD2164_debug_info.zip

goncaloclopes

unread,
Apr 21, 2016, 6:49:37 AM4/21/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Thanks Jorge, I will test them as soon as I get my hands back on our ephys system (coincidentally, they should be arriving today actually! long story).

Anyway, I have one last question. When you tested the system with the Intan software, did you only use the Intan bitfile? Could you run the same test on the intan software, but swapping in the actual Open Ephys bitfile (i.e. just rename the bitfile to "main.bit" and the Intan software should be happy with it).

Let me know what happens and I'll get back to you when I'm able to run the tests on our end.

Best,
G

Jorge Miguel Claro Cardoso

unread,
Apr 21, 2016, 6:59:02 AM4/21/16
to Gonçalo Lopes, Bonsai Users, Armando Miguel Caseiro Pires Remondes
The channel renumbering is observed with sample rates > 15kSamples/s. We have another issue to solve that might be potentially related, unexpected sample readings when using 8kSamples/ s sampling rate configuration. 

This can be reproduced using a sine wave @12.5 Hz with the setup previously described.



Please consider the following plots:


10kSamples/sec (channel 16):

Imagem intercalada 1

8kSamples/ s (chhanel 16)

Imagem intercalada 2



Best regards,

Jorge Cardoso

goncaloclopes

unread,
Apr 21, 2016, 7:03:19 AM4/21/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Thanks for the information, this is useful. I did my ECoG recordings exactly at 8 kHz also with a 64-channel headstage and I'm pretty sure I never saw either swapping of channels or these noisy readings.

Did you have the chance to try the Intan software with the open-ephys bitfile? Actually, you should try the Intan bitfile in Bonsai as well. I think at some point the Open-Ephys bitfile did not work with 64-channel headstages, and I'm not sure which version you are using.

Best,
G


Best regards,

Jorge Cardoso


Jorge Cardoso 

To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

Jorge Miguel Claro Cardoso

unread,
Apr 21, 2016, 9:45:23 AM4/21/16
to goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
We tested both, INTAN SW with INTAN bit file/ Open Ephys bit file and Bonsai SW using Open Ephys bit file/ INTAN bit file. Channel renumbering only occurs with Bonsai SW using any of those bit files. 



Best regards,

Jorge Cardoso

Sent from my iPad
--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

João Frazão

unread,
Apr 21, 2016, 10:06:01 AM4/21/16
to Jorge Miguel Claro Cardoso, goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
It is always the same renumbering? it is always consistent?

Joao Frazao

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/bonsai-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/5BEEEEA4-3A99-47AD-A3BC-A70B7B02E46C%40gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

Jorge Miguel Claro Cardoso

unread,
Apr 21, 2016, 11:12:24 AM4/21/16
to João Frazão, goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
Yes, we can reproduce this behavior.



Best regards,

Jorge Cardoso

Niccolò Bonacchi

unread,
Apr 21, 2016, 12:45:54 PM4/21/16
to Jorge Miguel Claro Cardoso, João Frazão, goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
I believe João was asking if the renumbering is always the same, e.g. ch 1 always canges to ch15 (or whatever the case might be).


--
N

goncaloclopes

unread,
Apr 22, 2016, 4:55:16 AM4/22/16
to Bonsai Users, jorge.cla...@gmail.com, joao....@neuro.fchampalimaud.org, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hi Jorge,

Sorry for the delay. Finally got the time to setup a small improvised test rig isolating individual omnetics pins and I have to say that I could not reproduce your observations. I tried 8, 10, 15 and 30 kHz and all of them gave me the same channel mapping and no weird DC offset or low-frequency artifacts.

To be honest, I was expecting this already, since for the last 2 years we have been driving these chips and acquisition boards on all kinds of different situations from recording ECoG fields at 8kHz, to single-wire LFPs and high-density spike recordings with silicon probes @ 30 kHz and we never saw anything similar to this...

Discussing it with Adam and João at the lab the agreement seems to be that the remapping and offset you are experiencing is probably due to some misalignment of the data packets coming out of the acquisition board data lines. It is unclear what exactly is causing this, and it is really weird that you don't see this in the Intan software. We have had hardware issues with OpenEphys acquisition boards in the past, but we always saw the same symptoms appear on both Intan and Bonsai. They basically run the same protocol acquisition code, so in theory nothing much should change.

The fact that changing the frequency breaks things suggests some problem with the clock lines, but even this is mostly speculation at this moment.

At this point I have to admit that my suggestion would be to try it with another board. Do you by any chance have access to another OpenEphys board? It would be useful to plug in your system to a different hardware acquisition to remove this hardware bit out of the equation.



On Thursday, 21 April 2016 17:45:54 UTC+1, Niccolò Bonacchi wrote:
I believe João was asking if the renumbering is always the same, e.g. ch 1 always canges to ch15 (or whatever the case might be).


--
N

On Thu, Apr 21, 2016 at 4:12 PM, Jorge Miguel Claro Cardoso <jorge.cla...@gmail.com> wrote:
Yes, we can reproduce this behavior.



Best regards,

Jorge Cardoso

On 21 Apr 2016, at 15:05, João Frazão <joao.frazao@neuro.fchampalimaud.org> wrote:

It is always the same renumbering? it is always consistent?

Joao Frazao
On Thu, Apr 21, 2016 at 2:45 PM, Jorge Miguel Claro Cardoso <jorge.cla...@gmail.com> wrote:
We tested both, INTAN SW with INTAN bit file/ Open Ephys bit file and Bonsai SW using Open Ephys bit file/ INTAN bit file. Channel renumbering only occurs with Bonsai SW using any of those bit files. 



Best regards,

Jorge Cardoso

Sent from my iPad

On 21 Apr 2016, at 11:49, goncaloclopes <goncal...@gmail.com> wrote:

Thanks Jorge, I will test them as soon as I get my hands back on our ephys system (coincidentally, they should be arriving today actually! long story).

Anyway, I have one last question. When you tested the system with the Intan software, did you only use the Intan bitfile? Could you run the same test on the intan software, but swapping in the actual Open Ephys bitfile (i.e. just rename the bitfile to "main.bit" and the Intan software should be happy with it).

Let me know what happens and I'll get back to you when I'm able to run the tests on our end.

Best,
G

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

João Frazão

unread,
Apr 22, 2016, 7:27:15 AM4/22/16
to goncaloclopes, Bonsai Users, Jorge Miguel Claro Cardoso, mrem...@medicina.ulisboa.pt
This can be some performance interplay between the visualizer and the acquisition, so if that is the case it is expected some kind of stochastic behavior.
Because of that I was asking if the remapping is actually always the same. 
Can you try running bonsai, with all the visualizers closed? and just dump things to a file and see if happens. Also without dumping to a file just opening the visualizer for brief periods from time to time?

Joao

On Fri, Apr 22, 2016 at 9:55 AM, goncaloclopes <goncal...@gmail.com> wrote:
Hi Jorge,

Sorry for the delay. Finally got the time to setup a small improvised test rig isolating individual omnetics pins and I have to say that I could not reproduce your observations. I tried 8, 10, 15 and 30 kHz and all of them gave me the same channel mapping and no weird DC offset or low-frequency artifacts.

To be honest, I was expecting this already, since for the last 2 years we have been driving these chips and acquisition boards on all kinds of different situations from recording ECoG fields at 8kHz, to single-wire LFPs and high-density spike recordings with silicon probes @ 30 kHz and we never saw anything similar to this...

Discussing it with Adam and João at the lab the agreement seems to be that the remapping and offset you are experiencing is probably due to some misalignment of the data packets coming out of the acquisition board data lines. It is unclear what exactly is causing this, and it is really weird that you don't see this in the Intan software. We have had hardware issues with OpenEphys acquisition boards in the past, but we always saw the same symptoms appear on both Intan and Bonsai. They basically run the same protocol acquisition code, so in theory nothing much should change.

The fact that changing the frequency breaks things suggests some problem with the clock lines, but even this is mostly speculation at this moment.

At this point I have to admit that my suggestion would be to try it with another board. Do you by any chance have access to another OpenEphys board? It would be useful to plug in your system to a different hardware acquisition to remove this hardware bit out of the equation.

On Thursday, 21 April 2016 17:45:54 UTC+1, Niccolò Bonacchi wrote:
I believe João was asking if the renumbering is always the same, e.g. ch 1 always canges to ch15 (or whatever the case might be).


--
N

On Thu, Apr 21, 2016 at 4:12 PM, Jorge Miguel Claro Cardoso <jorge.cla...@gmail.com> wrote:
Yes, we can reproduce this behavior.



Best regards,

Jorge Cardoso

On 21 Apr 2016, at 15:05, João Frazão <joao....@neuro.fchampalimaud.org> wrote:

It is always the same renumbering? it is always consistent?

Joao Frazao
On Thu, Apr 21, 2016 at 2:45 PM, Jorge Miguel Claro Cardoso <jorge.cla...@gmail.com> wrote:
We tested both, INTAN SW with INTAN bit file/ Open Ephys bit file and Bonsai SW using Open Ephys bit file/ INTAN bit file. Channel renumbering only occurs with Bonsai SW using any of those bit files. 



Best regards,

Jorge Cardoso

Sent from my iPad

On 21 Apr 2016, at 11:49, goncaloclopes <goncal...@gmail.com> wrote:

Thanks Jorge, I will test them as soon as I get my hands back on our ephys system (coincidentally, they should be arriving today actually! long story).

Anyway, I have one last question. When you tested the system with the Intan software, did you only use the Intan bitfile? Could you run the same test on the intan software, but swapping in the actual Open Ephys bitfile (i.e. just rename the bitfile to "main.bit" and the Intan software should be happy with it).

Let me know what happens and I'll get back to you when I'm able to run the tests on our end.

Best,
G

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

Jorge Miguel Claro Cardoso

unread,
Apr 22, 2016, 8:37:04 AM4/22/16
to goncaloclopes, Bonsai Users, João Frazão, Armando Miguel Caseiro Pires Remondes
Hello Gonçalo,

Thank you for your feedback. 

This issue seems to be related with SPI BUS/ Open Ephys port indexing. 

We are using Open Ephys Port B because  A is broken.

We have reproduced the channel renumbering issue by (quickly) assembling a new Open Ephys acquisition board and comparing behavior with similar setup and comparing the results by using port A and port B. With a first quick test, with board connected on port A, channel numbering seems consistent. By connecting the same board/ SPI cable with port B we have channel renumbering issue previously described.

Several data structures are dynamically allocated by Bonsai based on external hardware configuration. 

This issue is potentially related with Open Ephys port indexing in Bonsai and all related data structures that contain our samples when we are using port B without anything connected on port A. 

Can you please doublecheck this setup using port B SPI BUS and nothing  connected on port A?
   

Cheers,

Jorge

2016-04-22 9:55 GMT+01:00 goncaloclopes <goncal...@gmail.com>:
Hi Jorge,

Sorry for the delay. Finally got the time to setup a small improvised test rig isolating individual omnetics pins and I have to say that I could not reproduce your observations. I tried 8, 10, 15 and 30 kHz and all of them gave me the same channel mapping and no weird DC offset or low-frequency artifacts.

To be honest, I was expecting this already, since for the last 2 years we have been driving these chips and acquisition boards on all kinds of different situations from recording ECoG fields at 8kHz, to single-wire LFPs and high-density spike recordings with silicon probes @ 30 kHz and we never saw anything similar to this...

Discussing it with Adam and João at the lab the agreement seems to be that the remapping and offset you are experiencing is probably due to some misalignment of the data packets coming out of the acquisition board data lines. It is unclear what exactly is causing this, and it is really weird that you don't see this in the Intan software. We have had hardware issues with OpenEphys acquisition boards in the past, but we always saw the same symptoms appear on both Intan and Bonsai. They basically run the same protocol acquisition code, so in theory nothing much should change.

The fact that changing the frequency breaks things suggests some problem with the clock lines, but even this is mostly speculation at this moment.

At this point I have to admit that my suggestion would be to try it with another board. Do you by any chance have access to another OpenEphys board? It would be useful to plug in your system to a different hardware acquisition to remove this hardware bit out of the equation.



On Thursday, 21 April 2016 17:45:54 UTC+1, Niccolò Bonacchi wrote:
I believe João was asking if the renumbering is always the same, e.g. ch 1 always canges to ch15 (or whatever the case might be).


--
N

On Thu, Apr 21, 2016 at 4:12 PM, Jorge Miguel Claro Cardoso <jorge.cla...@gmail.com> wrote:
Yes, we can reproduce this behavior.



Best regards,

Jorge Cardoso

On 21 Apr 2016, at 15:05, João Frazão <joao....@neuro.fchampalimaud.org> wrote:

It is always the same renumbering? it is always consistent?

Joao Frazao
On Thu, Apr 21, 2016 at 2:45 PM, Jorge Miguel Claro Cardoso <jorge.cla...@gmail.com> wrote:
We tested both, INTAN SW with INTAN bit file/ Open Ephys bit file and Bonsai SW using Open Ephys bit file/ INTAN bit file. Channel renumbering only occurs with Bonsai SW using any of those bit files. 



Best regards,

Jorge Cardoso

Sent from my iPad

On 21 Apr 2016, at 11:49, goncaloclopes <goncal...@gmail.com> wrote:

Thanks Jorge, I will test them as soon as I get my hands back on our ephys system (coincidentally, they should be arriving today actually! long story).

Anyway, I have one last question. When you tested the system with the Intan software, did you only use the Intan bitfile? Could you run the same test on the intan software, but swapping in the actual Open Ephys bitfile (i.e. just rename the bitfile to "main.bit" and the Intan software should be happy with it).

Let me know what happens and I'll get back to you when I'm able to run the tests on our end.

Best,
G

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

goncaloclopes

unread,
Apr 22, 2016, 8:55:38 AM4/22/16
to Bonsai Users, goncal...@gmail.com, joao....@neuro.fchampalimaud.org, mrem...@medicina.ulisboa.pt
Hi Jorge,

Thanks for the information, I agree that it might be relevant to understand what is going on.

However, I tried my setup on this situation (i.e. a single 64-channel headstage plugged into ports A, B, C and D one at a time) and still cannot reproduce the channel remapping or other artifacts. Again I tried 8, 10, 15 and 30 kHz on each of the ports A, B, C, and D, and the data always looks the same to me.

It is true that Bonsai allocates data structures dynamically depending on which ports are connected, but it should still preserve the channel mapping within each MISO channel. Basically the individual channel data is just sampled linearly from the data packets, following the same protocol as Intan, and this does not change depending on the connected ports. Data packets are always interpreted in the same way...

I'm still puzzled as to why you are not seeing this effect on the Intan software, but unfortunately without the ability to reproduce the issue on my end is going to be hard. I'm not sure how the Intan firmware handles ports, but I'm imagining this might still be explained by some clock line issue specific to that port.

What happens if you try it on the other ports (C and D)?
Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

Jorge Miguel Claro Cardoso

unread,
Apr 22, 2016, 10:53:23 AM4/22/16
to goncaloclopes, Bonsai Users, joao....@neuro.fchampalimaud.org, mrem...@medicina.ulisboa.pt
Hello Gonçalo,


Thank you for your update. 

A potential issue with the clock coordinating the transmission line would explain some samples being altered @ 8kSamples/ s but not isolated channel renumbering for all other sampling rates. Impairment is not visible with INTAN SW. 

In case of a performance issue as suggested by Joao, that would result in partial data discard, loss of synchronization and being MISO samples interleaved among different data streams every 16-bit word, that would probably translate into some random behavior mixing samples from different channels, messing up all data, not only channel renumbering as observed for sampling rates different from 8kSamples/ s.


We have confirmed the latest Open Ephys GUI keeps the expected channel numbering. 
We will also include the other ports C, D as next step.


Can you please confirm any other dependency of specific USB drivers, DLLs, acquisition board model and firmware version? 




Cheers,

Jorge
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

goncaloclopes

unread,
Apr 22, 2016, 11:36:22 AM4/22/16
to Bonsai Users, goncal...@gmail.com, joao....@neuro.fchampalimaud.org, mrem...@medicina.ulisboa.pt
Hi Jorge,

Ok, if you also don't see it on the latest Open Ephys GUI, then I'm practically convinced that it's most likely a software issue. However, where exactly along the pipeline it is will remain unclear until I can reproduce it or otherwise get some clues about it.

I also don't think it is a performance issue, especially because there is a buffer in the FPGA exactly in order to guarantee that even a "slow" acquisition will not immediately interfere with the MISO lines. Also, if that buffer is full what you can get is a crash, but not a consistent channel reordering.

I agree that an explanation in terms of drivers and firmware is more likely, although we are already using the same "bitfile" and presumably hardware, so maybe drivers are actually a good point to investigate. Bonsai also uses the Opal Kelly FrontPanel interface, the same as OpenEphys and Intan, in order to open the USB communication channel with the FPGA. However, Bonsai uses their C# interface, rather than C++. Still, this interface is developed by Opal Kelly itself and ultimately is just a wrapper for their C++ DLL, which should be the same as what Intan/OE is using.

I don't recall hearing about Intan or Open Ephys upgrading their dependency versions, but anyway you can try putting the okFrontPanel.dll that Bonsai uses on the Intan software or OpenEphys GUI and see if that changes anything. You can find it in the Packages folder of Bonsai, inside "Packages/Rhythm.Net.1.4.0/build/native/bin/x86/okFrontPanel.dll". Let me know if anything comes up.

Also, can you tell me which operating system are you running on? We have tested Bonsai with OpenEphys extensively with both Windows 7 and Windows 8/8.1, but we haven't done any actual recordings with Windows 10. We have used both the OpenEphys acquisition board and the Intan Eval Board successfully and they work without any modification. We have also tried different versions of the Opal Kelly FPGA (LX45 and LX150) again with no problem or difference in data consistency or noise.

I have to admit this is really weird because I have personally seen data recorded live from as much as 10 different Intan acquisition boards (Eval Boards and OE acq boards), including all Intan headstages (both 32- and 64-channel headstages, with or without accelerometers), in both acute, chronic and artificial stimulation settings and I have never seen anything like this, so I'm quite curious to figure out exactly what it is.

What about another option if none of this works: I will be around the next week from the 25th to May 3rd. Would you mind dropping by the institute with your physical board so I can actually see the problem happen? I'm really sorry for the inconvenience, but it's really hard (impossible) to debug until you can actually have the bug in front of you. If this works for you, feel free to e-mail me "off-list" so we can arrange a visit schedule that works for you.

Looking forward to figuring out this "mystery". Hopefully it will prove easier than solving the brain :-P

G

João Frazão

unread,
Apr 22, 2016, 12:24:31 PM4/22/16
to goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
are you using more than a headstage? long cables? can be a clock synchronization problem between two headstages?

Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

goncaloclopes

unread,
Apr 22, 2016, 1:02:49 PM4/22/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hi Jorge,

Ok, I have finally been able to reproduce the problem. However, my particular conditions raise a number of other interesting questions.

The way I did it is I remembered we had another OpenEphys acquisition board in the lab where port A was also "damaged". We stopped using this one long ago, but we keep it around as a "spare". Now the tricky bit is that we were also using this board with a different Opal Kelly (LX150).

When I first plugged in the 64-channel headstage @ 20 kHz I could see the channel remapping and I also confirmed that it was not there on the Intan SW. Interestingly, however, when I changed the FPGA to the normal Opal Kelly LX45, to be the same as you, the problem was gone, and it worked fine on both Bonsai and Intan @ any sampling frequency.

Intrigued by this, I then switched the LX150 back to our more recent acquisition card, and it also reproduced the error. This confirms that the damaged port has nothing to do with the problem and that it is probably independent of the acquisition board itself (I tried v2.1 and v2.2).

However, the interesting bit is that I can only reproduce this problem with this particular LX150. This makes it difficult to understand because we only have one LX150 (usually everyone just gets the LX45) so I can't even confirm whether it depends on this particular hardware combination or not. Another difficulty is that the bitfiles for the LX150 are all different from the LX45 (different FPGA architecture), so actually this does not exclude the possibility of some weird thing happening in the bitfile.

Nevertheless, it does confirm that something in the Intan software is making it more robust to this remapping, and now at least I have a setup that I can use to look at.

For your information, my setup was:

OpenEphys Acq board: v2.1 and v2.2 (the two versions I have available here)
FPGA: LX45 (ok) and LX150 (remapping observed)
okFrontPanel: I tried using the exact same DLL on both Bonsai and Intan and it doesn't change anything about the problem (my system drivers are also obviously the same)

So at least now I have a way to debug this and compare. Will let you know if I find out something. In the meantime if you can run your tests on other hardware combinations, I would be curious to know the results.

Thanks for reporting this.
Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

João Frazão

unread,
Apr 22, 2016, 1:31:27 PM4/22/16
to goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
the lx150 has a older bitfile version.

Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/50b6508c-01a1-4e21-a186-ec2cc051d31b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

goncaloclopes

unread,
Apr 22, 2016, 1:50:31 PM4/22/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Yes, I am aware of this, that's why I'm still not sure how much I should rely on it.

However, it is also true that the Intan software does not show the remapping, even using this old bitfile, so there may be some weird difference somewhere...

Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

goncaloclopes

unread,
Apr 23, 2016, 12:38:44 PM4/23/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hi Jorge,

Ok, so I think I figured out what the problem is. I contacted Reid Harrison from Intan Tech and he suggested this might be to some issue estimating the correct cable round-trip time delays for the SPI MISO lines. He said that in case cable delays are off even by just one tick it is possible the whole data stream is shifted by one word, producing the weird DC offset you were observing, as well as the channel remap. These delays are usually computed automatically in a way that you don't have to worry about them, but for some reason in your case they must be giving off some weird values.

In my case, because I'm using a different FPGA module, the LX150, the automatic cable delay estimation algorithm is probably not compatible with that module for some weird reason and so I was able to reproduce the issue. In your case, I believe the problem may actually be related to cable length. How long is the cable you are running exactly? If it's not too long, could you try replacing the cable with a new one and checking if the problem still persists? Just curious... it should work with the LX45.

I'm still not sure why exactly the Intan is robust to this, but I don't think the difference is in the cable delay estimation as Bonsai shares the exact same code. It might be in the way the incoming data packets get copied into the output buffer, maybe they have some extra checks to try and squeeze things into place regardless.

Anyway, in the meantime I was able to solve the issue on my side by just setting the cable delays manually. In general it may be useful to do this as you can get into situations where delays are incorrectly measured because of cable abnormalities or if you have weird chips (my case), so I've added additional properties to the Rhd2000EvalBoard source node that allow you to set this.

This delay is measured in integer clock steps and can range from 0 to 15. In my case I fixed port B with the number 4, but it might well be different in your case. You can try running the workflow again and trying each delay one by one until you get the proper alignment.

I'm attaching a pre-release of a new Bonsai.Ephys package 2.3.0 which adds the four extra properties for configuring the MISO line cable delays. If it installs correctly, you should see something like this show up in the properties:


The delay settings are where you can insert manually the cable delays. If you don't write anything (default), they will be computed automatically, which should continue to work most of the times. But you can use it to add manually a delay to port B and see if that helps.

Let me know how it works for you. Thanks for reporting, it was useful to learn more about this.
Bonsai.Ephys.2.3.0-alpha.nupkg

Jorge Miguel Claro Cardoso

unread,
Apr 24, 2016, 2:37:58 PM4/24/16
to goncaloclopes, Bonsai Users, mrem...@medicina.ulisboa.pt
Hi Gonçalo,

Thank you for your email and the SW update.


We are using a single cable (1.8 m) for this test but we will also be using cable lengths up to 3.6 m. I will doublecheck the issue you described and test the static settings configuration.



Cheers,
Jorge

Sent from my iPad
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
<Bonsai.Ephys.2.3.0-alpha.nupkg>

Armando Remondes

unread,
Apr 27, 2016, 5:11:23 AM4/27/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hello Goncalo
Thanks for the update! I had tried earlier the new package installation procedure...Then:
I tried copying this update to distinct folders and setting them as package sources and managed to install the update such that is shows in the package manager with what I believe is the correct ID: Bonsai.Ephys pre-release 2.3.0 and so on....However, I could never see the port delay def. options you mention, when I select the RHD2000 node. I went through the steps again and again and never managed to get it to work (create a new source directory and list it in package manager, using distinct directories as sources, and so on...). Any suggestions?
Miguel
Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

goncaloclopes

unread,
Apr 27, 2016, 5:17:52 AM4/27/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hello Miguel,

That is weird. I just tried installing again the package on a fresh version of Bonsai and it is showing up on my side.
Maybe the installation got corrupted somehow... Can you send me the "Bonsai.config" file? It should be in the top folder of the Bonsai installation directory, next to the executable. That way I can see which DLL your Bonsai is actually using.

Thanks,
G

goncaloclopes

unread,
Apr 27, 2016, 5:37:40 AM4/27/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Strange, in the Bonsai.config file you sent me the version that is installed is "2.1.1" and there is no reference to "2.3.0-alpha". If you close and open Bonsai again, and go to the package manager, and look into the "Installed Packages" tab, can you tell me which version is listed there? Bonsai only looks into the packages contained in this file, and I would find it very weird if the package is marked as installed without actually being listed there.

Thanks,
G

Armando Remondes

unread,
Apr 27, 2016, 7:27:27 AM4/27/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
OK. Reinstalled Bonsai and got it to work finally.
thanks
Miguel

Jorge Miguel Claro Cardoso

unread,
Apr 27, 2016, 7:36:50 PM4/27/16
to goncaloclopes, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Hi Gonçalo,

I've confirmed the static MISO delay settings can correct the issues previously identified. We are running some additional tests.

I'm also interested in understanding why INTAN SW seems more robust during the initial automatic MISO delay parameter estimation.
 
We have noticed that the behaviour with a single RHD2164 connected on port B is different from having two RHD2164 connected by a dual headstage adaptor in port B. Two RHD2164 on the same SPI cable, same port B behave as expected.

According to INTAN documentation RHD2000 system supports a total of eight data streams and they are usually mapped to the four ports (A,B,C,D) in groups of two:

data stream 0 => Port A (MISO 1)
data stream 1 => Port A (MISO 2)
data stream 2 => Port B (MISO 1)
data stream 3 => Port B (MISO 2)
data stream 4 => Port C (MISO 1)
data stream 5 => Port C (MISO 2)
data stream 6 => Port D (MISO 1)
data stream 7 => Port D (MISO 2)

Our initial estimation for MISO delay parameters is based on the assumption there is a static mapping between data streams and physical ports.

RHD2164 has a particular feature, it consumes two data streams and each data stream conveys 32 channels. Two RHD2164 boards will consume 2x2=4 data streams on a single port.

As root cause for automatic parameter estimation failure, I'm considering the hypothesis that data streams are sequentially allocated to RHD2164 boards and are not based on the previously described static port mapping. Data streams 0 and 1 for the first RHD2164, data streams 2 and 3 for the second RHD2164:

* That would explain why port A auto configuration is working with any  configuration, MISO delay settings are based on data stream 0 or 1 test results available with single or two boards combined in the same port.

* Port B automatic parameter estimation with one RHD2164 board is not OK, wrong MISO delay settings cause channel renumbering because the delay estimation output is probably available on data streams 0/ 1 and the MISO delay setting enforcement is based on data streams 2/ 3.

* Port B automatic parameter estimation with two RHD2164 boards is OK, delay estimation output is probably available on data streams 0,1,2 and 3 and the delay setting enforcement is based on data streams 2/ 3.
 

Would it be possible to doublecheck this hypothesis related with RHD2164 specificity by adding some debug code in order to confirm 1. mapping between data streams and physical ports and 2. the application of delay test results to the physical port MISO delay settings?



Cheers,

Jorge


Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

goncaloclopes

unread,
Apr 28, 2016, 10:04:04 AM4/28/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hi Jorge,

Thank you for debugging! Glad to hear that setting the MISO delay settings manually also worked for you as a temporary workaround.

I think your hypothesis makes a lot of sense. I still find it weird that there is a difference in the delay estimation behaviour: the code in C# was literally lifted directly from the original Rhythm C++ and should be identical to the original source line by line, aside from some really small syntax differences between C++ and C#.

However, as Sir Arthur Conan Doyle famously wrote: "Once you eliminate the impossible, whatever remains, no matter how improbable,must be the truth.".

I will not have access to the hardware until next Wednesday/Thursday as I am currently away from the lab. As soon as I'm back, I will make these tests and checks and let you know what I find.

In the meantime, please keep me updated of any additional findings.
Thanks!
Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

Jorge Miguel Claro Cardoso

unread,
Apr 28, 2016, 8:39:57 PM4/28/16
to goncaloclopes, Bonsai Users, Armando Miguel Caseiro Pires Remondes
Hi Gonçalo,

Original Rhythm C++ API initialization example seems to set only the basic mapping between the data sources (PortA1 to PortD2) and USB data streams.

With RHD2164 DDR technology we have now 16 possible data sources (PortA1 to PortD2-Ddr) but only 8 USB data streams.

Data source to data stream resource mapping will probably require some enhancement, a dynamic assignment mechanism based on the number and type of amplifier boards connected to each SPI BUS.

We need to clarify what's the current DDR source to data stream mapping. After confirming this is not set during initialization procedure we will also need to doublecheck the default FPGA logic implemented when the configuration register is not properly set to handle DDR source to stream mapping. We may need a more elaborate test protocol in order to track amplifier data samples inside our system.

To be confirmed:

1. Undefined RHD2164 DDR data source to stream mapping during initialization => 2. (default) FPGA dependent?! DDR mapping/ DDR source handling => 3. mismatch between MISO delay estimation container variables and MISO delay configuration settings to physical port mapping => 4. Inadequate automatic MISO settings => 5. Channel renumbering/ DC offset, other?!.   



Cheers,

Jorge  


Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

goncaloclopes

unread,
May 5, 2016, 3:33:27 PM5/5/16
to Bonsai Users, goncal...@gmail.com, mrem...@medicina.ulisboa.pt
Hi Jorge,

I just arrived in lab today, and I will try out some fixes.
Incidentally, I just realized that just today Intan released a new version of their Rhythm API, just in time for an upgrade!

What I will do then is actually go over their changes and see if they improved the USB delay detection code. If they did, then I will upgrade the corresponding Bonsai code and try out the new version.

Anyway, I will let you know as soon as I have more developments.

Thanks,
G
Jorge



--
N

To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users+unsubscribe@googlegroups.com.

KPerks

unread,
Jul 8, 2021, 2:42:33 PM7/8/21
to Bonsai Users
Hi all, 
Where are bitfiles found? The only ones I have found are the ones that come in the Open Ephys example from the Gallery (the usb and usb3 versions). I tried to follow some of the links in this forum thread that mentioned bitfiles, but could not find them (ex: http://intantech.com/files/RHD2000interface_compiled_v1_4_2.zip)

I am trying to debug why we are seeing 32 channels instead of 16 channels when we use the open ephys example workflow with the Open Ephys system and an Intan RHD2216 headstage.
My first guess is that the bitfile needs to be different? But I am new to this. Maybe it is something different. Either way, I can't figure out how to find or create bitfiles (or what they need to be specific for - is it just something specific to the FPGA or does it need to be specific for each headstage?). 

Cheers,
Krista

To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.



--
Joao Frazao
Intelligent Systems Laboratory
Champalimaud Centre for the Unknown
Av. Brasília, Doca de Pedrouços
1400-038 Lisboa, Portugal
www.neuro.fchampalimaud.org

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Bonsai Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bonsai-users/r6hcBT0vdGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bonsai-users...@googlegroups.com.

Gonçalo Lopes

unread,
Jul 11, 2021, 8:58:28 PM7/11/21
to KPerks, Bonsai Users
Hi Krista,

The bitfiles are specific to the FPGA and essentially represent the program that is running in the FPGA fabric (a bit like uploading code to the Arduino). The RHD2000 uses the same FPGA as the OpenEphys boards, so the bitfiles are mostly compatible apart from some differences in the polarity and amplitude of I/Os.

The bitfile used to be included in the RHD2000 software, although it seems now there is a radically new software package which might not reveal them easily. The legacy software is still there though and it has them: Downloads | Intan Technologies (look for version 1.5.4 of the USB Interface Board software, it has a main.bit inside)

Hpoe this helps.

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/1588885b-6c06-45c4-9660-24fdccbfc0f2n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages