ibt-fmi/cosplay

Contrast Optimized Stimulation player

COSplay

COSplay (Contrast optimized stimulus player) is a Python based software solution for the delivery of stimulus sequences in stimulus evoked experiments. It is fully compatible with the stimulus sequence optimization package COSgen. The software is best used in conjunction with a COSplayer, an open source device, assembly instructions for which can be found here.

Rationale and Use Case Example

In many research areas, the functioning of complex systems is probed by measuring stimulus-evoked responses. COSplay can allow e.g. a neuroscientist to present milli-second accurate stimuli to a subject during a measurement procedure. Commonly, stimulus train delivery is coordinated by in-house and/or proprietary solutions, which are often ill-documented, expensive, poorly reproducible, high-maintenance, and unsustainable. Uniquely, COSplay permits stimulus train delivery via a small and portable device, capable of interfacing with proprietary measurement systems --- but in and of itself not containing any additional proprietary software or hardware!

Features

• TTL trigger from MRI scanner can be used
• 2 transistor channels
• 2 TTL output channels (3.3V)
• 2 amplitude modulation channels
• Microcontroller can be used standalone (c.f. Standalone use section in the docs)
• Stimulus pulse delivery with ms or μs accurary
• Random selection of a sequence from a sequence library
• Piping of sequence file to the directory of the latest scan on the MRI computer
• Error message forwarding to computer

Installation

COSplay can be installed using Python's setuptools.

git clone https://github.com/IBT-FMI/COSplay.git
cd COSplay
python setup.py install --user

Dependencies

• Python 2.7 or Python 3.5 and newer
• PySerial 3.3 or newer
• Setuptools 20.7 or newer

Hardware

• PyBoard 1.1
• microSD (recommended)
• USB cable (A to micro-B)

Minimal Usage Example

To execute a demo sequence on the COSplayer device, please follow the subsequent steps:

1. Install the package on a machine according to the instructions above.
2. Connect the COSplayer device to the machine. At this point the blue, orange, and green LEDs should light up, according to the LED legend.
3. Press the USR button twice. At this point the blue LED should light up, the red LED may also intermittently light up, according to whether data is being written on disk.
4. After the device is recognised by the host computer, navigate to the sequence_library directory.
5. Copy a file formatted according to the COSplay/BIDS standard into the directory. An example file is provided in this repository. All values are interpreted as SI base units, seconds and hertz, respectively --- with the exception of the amplitude (see more).
6. After the file has copied and the red LED is no longer lit, safely remove the volume, and press the RST button.
7. Click the USR button once to select the standalone operation mode. At this point the LED lighting should transition from blue, orange, and green to none.
8. Click the USR button again to arm the device. At this point the orange LED should light up.
9. Click the USR button once more to trigger the sequence. At this point the green LED should light up, and, as stimulation is delivered, the blue LED should intermittently light up as well.

Contributing Guidelines

You can:

• Submit suggestions for improvements via the GitHub Pull Request tracker.
• Report issues and seek help via the GitHub Issue tracker.

cosplay's Issues

Max sequence length in 'us'

Due to an overflow the 'us' accuracy mode only works for sequences with a max length of ~19min47s. (For the 'ms' mode it is ~317h, so not relevant.) As we originally only aimed for 'ms' accuracy, I suggest we mention it in the documentation but do not change anything.

Floating point inaccuracies

An onset time of 810.0 s (.tsv file below)

onset	duration	frequency	pulse_width	amplitude	out_channel	wavelength	strength	strength_unit
160.0	20.0	15.0	0.005	1.0	1.0	488.0	30.0	mW
290.0	20.0	15.0	0.01	1.0	1.0	488.0	30.0	mW
420.0	20.0	25.0	0.005	1.0	1.0	488.0	30.0	mW
550.0	20.0	25.0	0.01	1.0	1.0	488.0	30.0	mW
680.0	20.0	15.0	0.005	1.0	1.0	488.0	30.0	mW
810.0	20.0	15.0	0.01	1.0	1.0	488.0	30.0	mW
940.0	20.0	25.0	0.005	1.0	1.0	488.0	30.0	mW
1070.0	20.0	25.0	0.01	1.0	1.0	488.0	30.0	mW
1200.0	20.0	15.0	0.005	1.0	1.0	488.0	30.0	mW
1330.0	20.0	15.0	0.01	1.0	1.0	488.0	30.0	mW
1460.0	20.0	25.0	0.005	1.0	1.0	488.0	30.0	mW
1590.0	20.0	25.0	0.01	1.0	1.0	488.0	30.0	mW

is represented by COSplay as 809.9999:

Searching port...
Connection to /dev/ttyACM1 established.

Sequences found on computer:
None
Size of sequence library: 1

Current sequence:
onset   duration        frequency       pulse_width     amplitude       out_channel     wavelength      strength        strength_unit
160.0   20.0    15.0    0.005   1.0     1.0     488.0   30.0    mW
290.0   20.0    25.0    0.005   1.0     1.0     488.0   30.0    mW
420.0   20.0    15.0    0.01    1.0     1.0     488.0   30.0    mW
550.0   20.0    25.0    0.01    1.0     1.0     488.0   30.0    mW
680.0   20.0    15.0    0.005   1.0     1.0     488.0   30.0    mW
809.9999        20.0    25.0    0.005   1.0     1.0     488.0   30.0    mW
940.0   20.0    15.0    0.01    1.0     1.0     488.0   30.0    mW
1070.0  20.0    25.0    0.01    1.0     1.0     488.0   30.0    mW
1200.0  20.0    15.0    0.005   1.0     1.0     488.0   30.0    mW
1330.0  20.0    25.0    0.005   1.0     1.0     488.0   30.0    mW
1460.0  20.0    15.0    0.01    1.0     1.0     488.0   30.0    mW
1590.0  20.0    25.0    0.01    1.0     1.0     488.0   30.0    mW

I assume this is because there is no precise 810.0 s floating point, and at any rate this is not mitigated by passing 810 time (without the decimal point). Still, to avoid errors in record keeping, ideally COSplay should record the instructions it receives and it executes. If there is no way to distinguish 809.9999 from 810.0 that means it's just as correct to record 810.0.
@faymanns thoughts?

Sequence picking

The way COSplay currently picks sequences is somewhat intricate, and does no actually support randomized picking. This doesn't necessarily mean it should be changed (other than fixing randomization support), but the behaviour should either be simplified or precisely documented:

If the sequence_library directory contains:

• only files not named sequence*.tsv - the first file in alphabetical order is always picked
• files not named sequence*.tsv and files named sequence*.tsv - the first file in alphabetical order among the files named sequence*.tsv is picked
• only files named sequence*.tsv - the first file in alphabetical order among the files is picked

This is tested based on the terminal feedback from the COSplay CLI, with a sequence_library directory containing among others a .known_sequences directory repositing frequently used sequences under a <trial_ID>.tsv format - however, the presence and absence of this directory does not impact the picking behaviour.

sudden and permanent crash after sequence update

So, this just happened:

• I copied a new sequence (which you can see here) to /mountpoint/sequence_library/; I waited a bit, prepared the experiment and then tried to delete the previous sequence file, only to find that the filesystem got mounted read-only on all attempts on all USB ports

• I tried to start the stimulation manually to see which stimulation protocol it would choose and it crashed with alternating red and green lights imediately after I gave it a manual trigger every time I tried

• I mounted the filesystem manually to get write access, deleted both my new stimulation file an the abbreviated stimulation file we had previously tested, and placed only the example file inside the sequence library. Subsequenty, the system no longer crashed upon triggering, but instead executesd an almost instantaneous protocol, after which it was ready to be armed again.

• After an hour or so, I tried to test the behaviour again, and now, the board invariably crashes with alternating red and green lights immediately after I first push the middle button to have it select the present sequence.

In addition to fixing it soon, I recommend you try to repeat my steps, and make the needed modifications to avert this sort of crash permanently. The use case "write a manual sequence and just drop it in the right path" doesn't seem well covered and stress-tested at the moment.

Not delivering pulses after long delay

If the pyboard remained connected to the host computer for ~2h, when it was finally armed and triggered, it signaled to have started the sequence, but failed to actually deliver any pulses.

I was able to reproduce this twice, and each time it was fixed by restarting, re-arming. and re-triggering the board. Ideally this would not happen, though. Both times the pyboard had already once succesfully delivered the sequence before the 2 hour wait.

Amplitude modulation for laser

The amplitude modulation functionality provided by our stimulation file format, should be practically demonstrable with our Laser set-up.

Ideally you could call Omicron asap, and see if you need to make any changes with e.g. Markus Küpfer to implement the functionality in the device.

Memory Error

Apparently COSplay fails with larger sequence files.

Given the following sequence protocol:

onset	duration	frequency	pulse_width	amplitude	out_channel	wavelength	strength	strength_unit
50.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
51.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
52.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
53.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
54.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
55.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
56.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
57.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
100.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
101.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
102.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
103.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
104.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
105.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
106.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
107.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
150.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
151.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
152.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
153.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
154.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
155.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
156.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
157.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
200.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
201.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
202.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
203.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
204.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
205.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
206.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
207.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
250.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
251.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
252.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
253.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
254.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
255.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
256.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
257.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
300.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
301.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
302.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
303.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
304.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
305.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
306.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
307.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
350.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
351.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
352.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
353.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
354.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
355.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
356.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
357.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
400.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
401.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
402.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
403.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
404.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
405.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
406.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
407.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
450.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
451.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
452.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
453.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
454.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
455.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
456.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
457.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
500.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
501.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
502.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
503.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
504.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
505.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
506.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW
507.0	0.4	25	0.01	1.0	1.0	488.0	30.0	mW

I get:

[mri@pharmascan70 ~]$ COSplay 

Press Ctrl+c when you are done to close the program.

Searching port...
Connection to /dev/ttyACM0 established.

Sequences found on computer:
None
Size of sequence library: 1

Error on pyboard:
Traceback (most recent call last):
  File "main.py", line 323, in <module>
  File "main.py", line 190, in main
  File "/flash/lib/tsv.py", line 94, in dumps
MemoryError: memory allocation failed, allocating 2066 bytes

This is in spite of there being plenty of free space on the pyboard (40kB free, whereas the file is about 3.3kB).

Channels 5 and 6

I have tested the circuit for the second-generation COSplayer, and all is fine except channels 5 and 6:

1. The circuit schema is wrong, port 6 goes into X6 and port 5 into X5 (not the other way around).
2. Channels 5 and 6 seem to have an OFF voltage of ~1.4V and an ON voltage of ~1.6V. This doesn't seem right.

@faymanns could you please redo the circuit schema and let me know about the voltages?

Terminal trigger feedback

Things look to be working nicely. Ideally there would be some feedback which is written by the COSplay script to the terminal upon receiving the trigger.

Red LED

t would be better to have an ther LED than the red one signal that the pyboard is in copy mode. The red one seems to be controlled depending on actually writing going on, and will be switched off after you have finished a write operation.

Additionally this allows users to diferentiate between the mode they are in (this would be the "other LED) and time periods where they have a very high chance of corrupting their memory if they unplug or reset (these would be the times when the red LED is on).
Ideally we would make a note of this "safety" feature as well.

Installing Python modules on outdated End-Of-Life Bruker CentOS machines

This is not an issue, just a general tip.

Because CentOS 5 of Bruker consoles is no longer supported, and cannot access secure webpages anymore, I found it very tedious to manually install from source all the required modules for COSplay, and discovered a more convenient solution.
It may sound a bit complicated at first glance, but its actually very simple and will make any future python related software installations much easier:

On a windows machine:

• Download nginx (https://nginx.org/en/) on another computer in the same network as the Bruker console, which has an up to date OS (e.g. a windows machine, can also be a linux machine).
• change the server settings in the /conf/nginx.conf file as follows:

server {
    listen 80;
location /packages/ {
        proxy_pass https://pypi.python.org/packages/;
    }
location /pypi/ {
        proxy_pass https://pypi.python.org/simple/;
    }
}

• start nginx.exe . Thats all for the windows machine.

On the Bruker machine:
Assuming you have installed python 3 from source which includes the pip3 program, alongside the outdated python2 version of CentOS5.

• Add the following lines to ~/.bashrc, or probably better /root/.bashrc if you need root for installing stuff.

export PIP_INDEX_URL=http://192.168.X.X/pypi/    
export PIP_TRUSTED_HOST=192.168.X.X
export PIP_DISABLE_PIP_VERSION_CHECK=1

(replace the IP with the windows machine's IP)

• type: pip3 install requests

• Thats it. Make sure to always use python3 and pip3 (instead of python, pip) to install anything.
  As long as the windows machine running the local proxy is connected, you no longer have to manually download/install anything.

JOSS Documentation Review

From my JOSS review (openjournals/joss-reviews#1171 (comment)):

• The statement of need is present in the JOSS paper, but not in the documentation:

COSplay/paper.md

Lines 36 to 37 in ab7279c

	In many research areas, the functioning of complex systems is probed by measuring stimulus-evoked responses.
	Commonly, stimulus train delivery is coordinated by in-house and/or proprietary solutions, which are often ill-documented, expensive, poorly reproducible, high-maintenance, and unsustainable.

• Example usage of the software is missing

My other comments have been addressed.

Error handling

How should we handle timing error of the sequence? We could introduce a threshold (e.g. 1ms) for error handling. If the pyboard misses the deadline for the pulse by more than this the program stops. For smaller delays it only notifies the user and stores the error messages in an extra file which is stored in the same folder as the sequence on the host.

Capitalization

Python, the programming language, is a proper noun, and thus capitalized. Same goes for MicroPython, which you can either write as MicroPython (capitalization preferred by the authors and respected by e.g. Wikipedia) or Micropython (treating it as a normal proper noun).

I spotted one in the README 9378d86 but it seems there are more occurences in the package,

Add overview entry for more LED codes

However streamlined the workflow logic, new users will rely heavily on the LED patterns to indicate the status. It is particularly important to minimize confusion, by reducing the number of unexplained LED patterns. Two important patterns we do not currently list are:

• blue/red - for "writing to device"
• green/red - for "error encountered (e.g. sequence not recognised). Please Restart"

We should add them to the DOT file and printed overview.

Cannot escape CLI

Sometimes (eps on our 7T computer) the CLi can't be escaped once you get a sequence not found error.

This can be "fixed" by resetting the pyboard, but a more elegant/intuitve solution would be preferred.

Cannot mount in copy mode

The 7T computer cannot mount the pyboard - this is obviously a computer-specific issue - however it is also not possible to mount it manually (only the /dev/sdb device node is shown - no number).

Maybe this is also why automount fails?

Concurrent stimulus blocks conflict with most recently used channel beinf overriden.

With the following stimulus protocol:

onset	duration	frequency	pulse_width	amplitude	out_channel
10	10	0.2	1	1.0	4
30	10	0.2	1	1.0	5
50	10	0.2	1	1.0	4
50	10	0.2	1	1.0	5

during the concurrent stimulation blocks starting at 50s, only channel 4 will be active.

With this other stimulation protocol, however, during the concurrent stimulation blocks starting at 50s, only channel 5 will be active:

onset	duration	frequency	pulse_width	amplitude	out_channel
10	10	0.2	1	1.0	5
30	10	0.2	1	1.0	4
50	10	0.2	1	1.0	5
50	10	0.2	1	1.0	4

Given this record-related variability, I would conclude that there's some software issue at work here, rather than some hardware issue relating to parallel output element arrangement. @felixsc1 agrees :)

Installation and Runtime Issues @ Neurotechnology Lab

setuptools should be listed as dependency, whereas it is not. Under python 2.7 setup can be imported from distutils.core, but this is not able to correctly set up the package, as it does not understand e.g. entry points. distutils.core can also not provide find packages, but this import is apparently not needed - right?

After installing python2.7.14, pyserial3.4 and setuptools36.5.0, and setting up the package, we got the following error:

[mri@CZC5064MR2 ~]$ COSplay 
Traceback (most recent call last):
  File "/home/mri/.local/bin/COSplay", line 11, in <module>
    load_entry_point('COSplay==0.0.0', 'console_scripts', 'COSplay')()
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 570, in load_entry_point
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2750, in load_entry_point
ImportError: Entry point ('console_scripts', 'COSplay') not found

Additionally, even when executing as python2.7 cosplay/cli.py(and after having run the permission granting scripts as superuser), the software cannot find the device. Not least of all there is a typo with the respective prompt ("Seraching").

Circuitry not displayed in Documents

The relevant documentation page does not display the circuit schema, rather only the text _images/circuit.pdf.

This is strange because the file is actually present in the repo.

Package has no version

$ pip install .
Processing $DIR/COSplay
Building wheels for collected packages: COSplay
  Building wheel for COSplay (setup.py) ... done
  Stored in directory: /private/var/folders/yb/10x6vxlx40s1dhv5vc163m680000gp/T/pip-ephem-wheel-cache-17zpi6ha/wheels/8f/81/54/f726e6251e09278aca793f3475ff9d8af617261e2e93557dd6
Successfully built COSplay
Installing collected packages: COSplay
Successfully installed COSplay-0.0.0

A fairly simple option would be to use Versioneer, which will use the latest git tag to produce a PEP 440-compliant version string, avoiding the need for manual edits.

Timing with respect to trigger

The trigger signal has a finite duration, therefore I was wondering whether the image acquisition starts at the beginning or end or the trigger signal. There are a number of operation that need to be executed after receiving the trigger but before the sequence can start. I think we should fix a time limit for these. If the image acquisition starts at the end of the trigger signal, the trigger duration could be a good choice.

pkt.receive return None

Hi, I want to porting the pkt.py to pyboard.But when I run this code.It return None.How to solve this issue:
`from pkt import Packet

from pyb import UART

uart = UART(4, 9600)

pkt = Packet(uart)

test = "this is packet test"

while True:
pkt.send(test.encode('utf8'))
res = pkt.receive(time_out = 100)
print(res)`

Thanks !

Sequence info after restarting client script

If the client script (the one running in the terminal on e.g. the scanner computer) is restarted as the pyboard is in connect mode, the user is notified that a connection is established, but not shown whether any and if so which sequence was found. Ideally this information would be displayed, as to eliminate any uncertainty regarding what sequence is queued for delivery.

Example usage and automated tests missing

See JOSS review criteria and my comment https://github.com/openjournals/joss-reviews/issues/1171#issuecomment-486387960 for details

Link to documentation

It would be good to add a link to the online documentation to the front page of the GitHub webpage.

Trigger threshold sensitivity

The trigger module of one of our scanners is broken, and no longer triggers by going down from 3.5V to 0V but from 3.5V to 1.8V. Ofc the correct thing to do is to fix the hardware and not to break the software, but the former is taking a while.

In the mean time, is there any way to increase the sensitivity of the trigger?
As far as I understand this is where the triggering happens, and the amplitude of the event is predefined by pyb.ExtInt.IRQ_FALLING, which is shipped with the micropython implementation. Any idea how this could be hacked? @faymanns @felixsc1

5V output needed

Unfortunately, many neurophysiology devices need 5V inputs rather than the 3.3V provided by the pyboard.
E.g. we use this stimulator http://www.ampi.co.il/isoflex.html (input 5-10V) (part of the Master-8, the most widely cited stimulus generator). This stimulus isolator is not triggered by the pyboards low voltage output.

To make the cosplay hardware a viable alternative, I suggest to include in the hardware a 3.3V to 5V "logic level converter" learn.sparkfun.com/tutorials/bi-directional-logic-level-converter-hookup-guide (apparently this doesn't require an additional battery or anything)

JSON stimulation sequence format

If we decide to go with a high-level syntax, we really need to think about the issues/constraints it may cause in the long run.

Why do you feel there is a need to specify the number of events explicitly?

Handle multiple ParaVision versions

On the AIC 9T computer there are multiple ParaVision versions, this seems to be a challenge for COSplay:

[mri@biospec94 opt]$ COSplay 
Traceback (most recent call last):
  File "/usr/local/bin/COSplay", line 11, in <module>
    load_entry_point('COSplay==0.0.0', 'console_scripts', 'COSplay')()
  File "/usr/local/lib/python3.6/site-packages/COSplay-0.0.0-py3.6.egg/cosplay/cli.py", line 64, in main
  File "/usr/local/lib/python3.6/site-packages/COSplay-0.0.0-py3.6.egg/cosplay/server.py", line 320, in main
  File "/usr/local/lib/python3.6/site-packages/COSplay-0.0.0-py3.6.egg/cosplay/server.py", line 47, in find_current_scan_dir
RuntimeError: Multiple versions of ParaVision found. List of folders found: ['/opt/PV6.Beta.0.41/data/mri/', '/opt/PV5.1/data/mri/', '/opt/PV6.Beta.0.42/data/mri/', '/opt/PV6.Beta.0.31/data/mri/', '/opt/PV6.0/data/mri/', '/opt/PV6.0.1/data/mri/', '/opt/PV6.Beta.0.46/data/mri/', '/opt/PV6.Beta.0.35/data/mri/']

As it happens the used version is '/opt/PV6.0/data/mri/' - so not the newest. Ideally COSplay would just look for the most recent scan directory, regarless of which PV version is used or how many there are present.

Support of different python version

The scanner computer in the lab only has python 2.4.3 installed. I did a bit of digging on the issue of making a script work in python 2 and 3 and most sources suggest to only support python 2.6+ and 3.3+. @TheChymera, you said you have experience with this. How do you think we should go about?

root access on scanner computer

I don't know for other vendors, but for Bruker scanners it seems like at least one person in every lab should have root access on the scanner computer(s). Because of this, I opt to stick with our original plan of using the USB virtual com port for communication between the microcontroller and the scanner computer.

Documentation

I see you have already added docstrings for many functions. That's great!

As elements of the API begin to harden, I suggest you also add parameters, returns and yields lists. The most widespread formatting guidelines in scientific python applications are those provided by numpy. They are also compatible with Sphinx. Though beautified documentation might be wasted on COSplay (but certainly not on COSgen).

Amplitude-Modulated channels do not output enough voltage

Apparently, channels 5 and 6 (which support amplitude modulation) are capped not at 3.3V (as channel 4 is) but at 1.2V. This means that they may be unusable to trigger devices with TTL inputs.

This issue can be somewhat mitigated by installing COSgen from the no_amplitude_modulation branch. However, under this solution, there are no longer any channels on the device supporting amplitude modulation (i.e. all output from 4,5,6 is 3.3V).

Value Error: object not in sequence

When starting COSplay the following error message appears:

Error on pyboard:
Traceback (most recent call last):
  File "main.py", line 323, in <module>
  File "main.py", line 197, in main
ValueError: object not in sequence

Before the error appears, it successfully connects to the pyboard and also detects the sequence on it.

COSplay CLI will not detect device on new machine

I am trying to run the CLI COSplay on my new laptop (testing purposes ahead of our submission, since reviewers may not have ParaVision). I have recently pushed a commit which makes it possible to run the CLI interface on a machine without PV. That part seems to work well. As does the connection as mass storage device. However the CLI will simply not detecht the device:

chymera@zenhost ~ $ lsusb
Bus 004 Device 004: ID 05e3:0749 Genesys Logic, Inc. 
Bus 004 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 004 Device 003: ID 2109:0813 VIA Labs, Inc. 
Bus 004 Device 002: ID 2109:0813 VIA Labs, Inc. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 04f3:0903 Elan Microelectronics Corp. 
Bus 001 Device 005: ID 8087:0a2b Intel Corp. 
Bus 001 Device 003: ID 13d3:5755 IMC Networks 
Bus 001 Device 006: ID 2109:d101 VIA Labs, Inc. 
Bus 001 Device 046: ID f055:9802  
Bus 001 Device 004: ID 2109:2813 VIA Labs, Inc. 
Bus 001 Device 002: ID 2109:2813 VIA Labs, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
chymera@zenhost ~ $ ls -lah /etc/udev/rules.d/95-pyboard.rules 
-rw-r--r-- 1 root root 472 Sep  5 20:48 /etc/udev/rules.d/95-pyboard.rules
chymera@zenhost ~ $ cat /etc/udev/rules.d/95-pyboard.rules 
# f055:9800, 9801, 9802 MicroPython pyboard
ATTRS{idVendor}=="f055", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="f055", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="f055", MODE="0666"
KERNELS=="ttyACM*", ATTRS{idVendor}=="f055", MODE="0666"
SYSFS{idVendor}=="f055", ENV{ID_MM_DEVICE_IGNORE}="1"
SYSFS{idVendor}=="f055", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", SYSFS{idVendor}=="f055", MODE="0666"
KERNELS=="ttyACM*", SYSFS{idVendor}=="f055", MODE="0666"
chymera@zenhost ~ $ eix pyserial
[I] dev-python/pyserial
     Available versions:  3.2.1 (~)3.4 {doc examples PYTHON_TARGETS="pypy python2_7 python3_4 python3_5 python3_6 python3_7"}
     Installed versions:  3.4(20:30:27 05/09/18)(-doc -examples PYTHON_TARGETS="python2_7 python3_6 -pypy -python3_4 -python3_5 -python3_7")
     Homepage:            https://github.com/pyserial/pyserial https://pypi.org/project/pyserial/
     Description:         Python Serial Port extension

chymera@zenhost ~ $ echo $PYTHONPATH
/home/chymera/.python_develop:/home/chymera/.local/lib64/:
chymera@zenhost ~ $ echo $PATH
/home/chymera/utils:/home/chymera/.python_develop:/home/chymera/.local/bin:/usr/lib/llvm/6/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin
chymera@zenhost ~ $ which COSplay
/home/chymera/.local/bin/COSplay
chymera@zenhost ~/src/sci/sci-libs/spams-python $ COSplay --vendor none

Press Ctrl+c when you are done to close the program.

Searching port...

It hangs at the last step forever.

I have no idea what it could be. I am thinking maybe something unobvous is making my PV-free solution not work, or maybe the USB-C adaptor is subtly somehow messing things up? Though lsusb seems to list the device just fine.

@faymanns any ideas?