# Sending time values with vpixx\_blackrock\_sync\_word

**URL:** https://mworks.discourse.group/t/sending-time-values-with-vpixx-blackrock-sync-word/85
**Category:** Support
**Created:** [February 7, 2022, 2:08pm UTC](https://mworks.discourse.group/t/sending-time-values-with-vpixx-blackrock-sync-word/85 "2022-02-07T14:08:27Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [February 7, 2022, 2:08pm UTC](https://mworks.discourse.group/t/sending-time-values-with-vpixx-blackrock-sync-word/85/1 "2022-02-07T14:08:27Z")

</div>

Hi Chris -

We’ve started using the vpixx functionality below to send 16 bit digital codes to Blackrock. Bottom-line: We have no issue sending values related to space/color (e.g. stimulus size, or stimulus rgb value). But we consistently have issues sending time values (e.g. stimulus on duration or reward duration). Basically, the time-related values we recover on the blackrock side, are nothing like what we sent.

We think this issue might be related to the units of time, or how MWELS evaluate a line containing a mix of numbers/strings, for example:

var stimulus\_on\_duration = 300ms

I’ll include two examples that might help:

(1) When we send a non-time variable like fixation point size using this line:

vpixx\_send\_blackrock\_sync\_word(fixation\_point\_size\*100 + v\_offset)

We recover exactly the fixation point size expected (0.30 degrees)

(2) When we send a time variable like stimulus on duration (300 ms) using this line:

vpixx\_send\_blackrock\_sync\_word(stimulus\_on\_duration + v\_offset)

We recover the value “42856” which is nothing like 300 ms.

Any thoughts on what we’re doing wrong here? The time values send for stimulus on/off and reward\_duration are all different than expected.

Thanks!  
Yasmine

---

<div class="post-metadata">

### Author: ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [February 7, 2022, 2:25pm UTC](https://mworks.discourse.group/t/sending-time-values-with-vpixx-blackrock-sync-word/85/2 "2022-02-07T14:25:51Z")

</div>

Hi Yasmine,

MWorks times are in microseconds. As [described in the manual](https://mworks.github.io/documentation/latest/expressions/index.html#units), the expression `300ms` is shorthand for `300*1000`. If you want to send time values in milliseconds to your Blackrock, you’ll need to divide by 1000 first.

As for where 42,856 comes from, the main issue is probably that 300,000 is larger than the largest unsigned, 16-bit integer (65,535). I assume 42,856 is the truncated remainder of the actual value of `stimulus_on_duration + v_offset`.

It might be a good idea to add an [assertion](https://mworks.github.io/documentation/latest/components/assert.html) at the beginning of `vpixx_send_blackrock_sync_word` to confirm that you aren’t trying to send a value that’s too large:

```auto
%define vpixx_send_blackrock_sync_word (value)
    // Ensure that value is an integer in the range [0, 65535]
    assert (
        condition = ((int)value == value) and (value >= 0) and (value <= 65535)
        stop_on_failure = true
        )
    ...

```

Cheers,  
Chris

---

<div class="post-metadata">

### Author: ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [July 19, 2022, 6:22pm UTC](https://mworks.discourse.group/t/sending-time-values-with-vpixx-blackrock-sync-word/85/3 "2022-07-19T18:22:39Z")

</div>


