Open parityviolation opened 10 years ago
This sounds like it could be a software problem, rather than an issue with the FPGA firmware. The fact that it doesn't happen when you save to a new folder suggest it's a software bug.
Are you testing with multiple pulses per recording? If so, are all of them saved the same way (1s vs 0s), or is it only the first event? That could help us troubleshoot.
Also, do the events show up as 100 ms wide vertical bars in the LFP Display? If they do, then it's likely a problem with recording. If not, then it means the events might not be received by the software.
Finally, just as a sanity check, are your TTLs all 3.3V? That's the highest voltage the Eval Board can accept.
On Sat, Feb 8, 2014 at 4:40 PM, open-ephys notifications@github.com wrote:
This sounds like it could be a software problem, rather than an issue with the FPGA firmware. The fact that it doesn't happen when you save to a new folder suggest it's a software bug.
yes I agree
Are you testing with multiple pulses per recording? If so, are all of them saved the same way (1s vs 0s), or is it only the first event? That could help us troubleshoot.
sorry I am not sure I understand this question. yes multiple pulses per recording. the problem doesn't only occur with the first event
Also, do the events show up as 100 ms wide vertical bars in the LFP Display? If they do, then it's likely a problem with recording. If not, then it means the events might not be received by the software.
Yes I see the events in the LFP display (I haven't done a one to one check that....seeing them in the LFP display means that they are saved to the events file or not)
Finally, just as a sanity check, are your TTLs all 3.3V? That's the highest voltage the Eval Board can accept.
The TTL is likely 5V. I will check Monday
Reply to this email directly or view it on GitHubhttps://github.com/open-ephys/rhythm/issues/8#issuecomment-34548539 .
In any given recording, is every pulse saved consistently? E.g., the event ids are 0, 0, 0,...., or 1, 1,1,1.... as opposed to the expected behavior, which is 1,0,1,0,1,0....
Definitely check the voltage level, as well as other input channels. It could be something related to that.
We were having some issues with the digital input, that appear to have been primarily related to the pull-down resistors (our "high" level was much lower than expected).
Oops - just noticed this wasn't an open-ephys board. Have you tested with the Intan software?
Hey Guys,
I am testing out the reliability of a TTL pulse (100ms long) that is being sent to the Digital in (channel 1) of the RHD2000 EVALUATION board.
I get the following odd situation.
A few seconds after sending the pulse I STOP acquisition with open ephys gui. The all_channels.events file is then loaded using load_open_ephys_data.
Sometimes I see only 0 events others 1 event (channel 1 rising edge) and still other 2 events (rising and falling edge, the time between events seems right)
In the cases where I only got 1 event I have restart acquisition. After wait long enough (sometimes it can be 10's of seconds) It seems that the 2nd event (channel 1 falling edge) will be logged to disk. The timestamp seems to be write even though the logging to disk may be an undetermined time after the event occurs. This has happened when acquisition is restarted while appending to the same folder, I haven't yet seen the same behavior when a new folder is started but haven't tested exhaustively.