#125

And you’re not in bootloader mode? Try this from the docs maybe?

Note: Occasionally you might see druid complain about errors after calling r . Wait a couple seconds & try again. If you still have problems, enter ^^kill to reset crow, then r again.

#126

I have tried ^^r, ^^kill, recalibration. Crow remains in the same sate it was in on delivery. Outputting positive voltage at the inputs and no response to gates.

#127

Do you have Druid set up? If so can you try running the following:

input[1].stream = function(value) _c.tell('stream', 1, value) end
input[1].mode = 'stream'

This sets the input handler to send the first input out the serial port. This should cause the voltage crow is reading at input 1 to show up in the top left part of the terminal:
image

I think some users have reported problems getting the handlers to work with gates from specific modules, what gates are you using? Sounds odd that you would have voltages being driven by the inputs though. Edit: I can confirm with a multimeter that my crow is showing about 1V at input 1, but input 2 is roughly 0V.

1 Like
#128

Not a single gate/trigger source in my shared system will advance it. From tempi to maths, wogglebug, etc. I enter the above via druid.

With nothing connected, I see input 1 fluctuating between -0.001 and 0.004.

When plugging in a clock source, in this case the wogglebug. I see the value spike to 9.0 when each gate is received, yet the script does not advance.

Shorting the cable plugged into the input advances the script, and a negative value is printed.

I have not modified the script, it is still running first.

Update: after running the monitor for a bit, the input is now printing 1.0 with nothing connected.

#129

So I patched Maths EOC output to crow input 1, and the stream was showing that it swings between about 9.4V for “high” and 0.7V for “low”. Then I noticed that the inputs also have a “threshold” setting which defaults to 0.5V. I changed this to 1 volt by running:

input[1].threshold = 1.0
input[1].mode = 'change'  # need to set this to latch the new parameter value

and now First will respond to the gates from Maths! I’ll make a pull request (edit: here) to change this threshold since I recall seeing some other posts where this was giving people issues.

6 Likes
#130

Just confirmed this appear to be working now. Thank you for the help.

Any thoughts on the positive voltage present at the inputs? Could this cause a problem connecting to other modules? Like connecting an output to an output?

#131

this is super curious, how much voltage are you seeing?

edit: also, @jws, how are you measuring?

(edit for future reader, this is expected + verified: ^^ crow help: general (connectivity, device q's, ecosystem))

#132

Input 1 is 0.975V
input 2 is 1.406V

1 Like
#133

I am measuring using voltmeter and a euro cable plugged into the jack. I first noticed when plugging crow into the shared system cv bus, as they light up displaying positive/negative voltage.

1 Like
#134

Have you double checked your power connector and do you have any i2c connections?

#135

Thought I’d break up the discourse for a moment and say that the crow’s jacks feel so good and I hope that more modules implement them in the future—I love how quiet they are! Alright back to it

1 Like
#136

Hi @Jonny, no i2c.

So it seems my problem is twofold.

  1. The Make Noise modules gates swinging from 0.7V for low while crow was expecting 0.5V. See @csboling post above to modify the threshold setting.
  2. The positive voltage present at the inputs. Nearly 1V on input 1 and Nearly 1.5V present at input 2.

I have verified I am not over power in the Shared system and even moved the module to an Intellijel case. The module yielded the same readings at the inputs. But advanced without the updated threshold when fed gates from non MN modules further confirming @csboling fix.

I am just worried about the positive voltage present at the inputs. I have been talking with @dan_derks over email. I’ll prob just send it back for inspection/repair.

#137

OK, will try that first. Now to get some ii cables…

While I’m at it, I am wondering if anyone has suggestions as to where to locate my new Crow in my monomer/mannequins row… I have exactly 2 hp left, unless I remove something…

Here’s a photo of where I am thinking of putting it… I am also thinking of putting it between Ansible and Just Friends. I understand from @alanza that the distance to my W/ shouldn’t be a problem when I eventually get around to running the ii cables over there.

Thanks!

Monome%3AMannequins%20104hp%20Row
Monome:Mannequins 104hp Row.jpg1131×600 129 KB

1 Like
#138

I also see the same voltages at the inputs on my crow. I don’t have any reason to think it’s defective, not sure what the cause of this is but I’m not too worried about it.

Almost totally off-topic part of the post

As far as I know this is generally not a problem in euro since outputs are buffered and modules are designed with the expectation that people may patch outputs to outputs by mistake, often for long periods of time, and generally that freely experimenting and patching anything to anything should be safe. It does sometimes make me a bit nervous and I would not be surprised to learn of cases where you should definitely not do this! I know I have done this a lot accidentally. But also purposefully: passive mixing can be really interesting and useful. If you know all the output impedances are the same, this is just averaging, so like a unity mixer but where the outputs are all scaled down evenly, so you don’t clip from adding them together. If the impedances are not the same though, the mixing will be weighted/uneven, which can often be unpredictable and fun to play with. I have been enjoying a lot of patching like this in an LZX video synth system (impedances are standardized) using a particular passive switch matrix which happens to be I2C controllable.

#139

But is it expected behavior?

I am aware of modules having buffered outputs. In fact Tony from Make Noise actively encourages passive mixing of gate sources in the Shared System.

I was wondering about potential damage in other manufacturers modules that may not account for this, also whether the creators expect this.

It also throws off my patching flow when my CV bus is reading HIGH when only an output is connected. :slight_smile:

#140

I’m working on verifying this :slight_smile:
edit for future reader, verified: ^^ crow help: general (connectivity, device q's, ecosystem)

1 Like
#141

Thanks @dan_derks. I really appreciate all the support from everyone.

3 Likes
#142

the 1v on the inputs i believe is a very weak pull-up due to the auto-calibration circuitry and is not a defect and should not have any impact on your system— but i’ll wait for @Galapagoose to confirm and explain.

2 Likes
#143

The voltage you can read off an input cable is the input circuit’s reference voltage. It’s not ‘outputting’ in that there is minimal current potential (that voltage is behind a big resistor!). Attach that input cable to any output and the signal will precisely track that source.

The weird benefit of this is you can use an input as a ‘switch’ by plugging/unplugging an unpatched cable. Just set the input to default ‘change’ mode, and the event will be called on connect/disconnect.

re: Make Noise modules. I didn’t realize their ‘low’ voltage was 0.7V. I’ll increase the default ‘threshold’ voltage in the next firmware.

9 Likes
#144

Thanks for the clarification @tehn and @Galapagoose. ^^ crow on ^^