#367

IIRC if you define the function that gets called on overcurrent conditions (and have it debug print) you’ll be able to see if it is working. I was doing experiments in this area a year of so ago when trying to get a roli block to function as an mpe device… (I discovered back then it was tripping that protection)

2 Likes
#368

if i’m reading the code correctly the max power check is only performed upon the initial handshake with a connected device, and is based on the descriptor provided by the device, which would be the maximum that the device thinks it’ll need, not the actual amount it consumes at any given moment. so lowering the max value would simply mean tt refusing to talk to grid at all. i’ll play with it some more but pretty confident in this assessment (or as much as i could be without deep diving into the usb spec).

as a side note - would love to hear about your roli mpe experiments! earthsea i assume?

#369

MPE for earthsea and ansible was the goal. Ultimately I gave up because of what I believed at the time to be bugs in roli’s firmware - when the host device couldn’t keep up they would stop transmitting until disconnected and reconnected.

I picked up the quest again for norns but had to put it down to focus on maiden (the editor). I hope to get back to it post release - (stopping now as this is officially off topic!)

3 Likes
#370

ok-- some bad news. no, there isnt’ protection on the USB for overcurrent. the 5v regulator is underpowered. TT was designed without the fantastic-future-vision that a grid would be attached, let alone anything needing over a 100ma (ie, a keyboard).

further-- i don’t think any firmware hacking is going to fix it-- as i’m not sure the the uC has much to do with the current measurements (despite the libavr headers) in disabling the USB power switch.

what this has reminded me, is that i need to open-source the eagle files. (first i need to clean them up so they’re useful). and second, the next revision of TT need this fixed (along with having a few more i2c ports on the back).

a drop-in hack/fix would be to replace the 5v reg (U5, right on the bottom board edge) which is a SI8050— but i’m not sure there is a higher current drop-in replacement.

1 Like
#371

answer after quick search is NOPE

will look at the PCB and figure out if there’s a possible hard hack

2 Likes
#372

grid control mode is almost done. it certainly turned out to be a bigger feature than i anticipated! both in terms of how long it took to implement and how useful it is.

here is an example of using grid to edit variables and execute commands from history:

12 Likes
#373

Can anyone confirm that a 64 greyscale grid will work with grid ops?

#374

the latest posted beta won’t work with grids 64 properly but there will be a fix in the next beta. you can use any ops, for grayscale any brightness level under 8 will be “off”, any brightness above will be “on”.

i’ve also fine tuned the grid control mode for 64 / non vb specifically (256 too):

4 Likes
#375

Thanks so much! I was looking for a smaller grid solution and ran across a 64 for a decent price. :slight_smile:

Edit: This is apparently not a “grayscale” 64 but rather a “series” 64? Will it work OK?

canvas
canvas.jpg1920×1080 545 KB

#376

As above :slight_smile:

#377

not sure about series, unfortunately i don’t have one to test. maybe somebody who has one can comment? if it works with white whale/earthsea/meadowphysics/ansible it’ll work with teletype.

1 Like
#378

It looks like people have used the series 64 with White Whale and such, so I’ll keep my fingers crossed. It should be here by mid-week. I’ll report my findings.

1 Like
#379

series should work transparently with the libavr32 grid driver (aleph, WW, teletype, &c)

(sorry i can’t really speak specifically to the use case but did use a series 64 when writing the driver way back when)

#380

I made a cable for testing today and have some strange results:

http://www.prettyhowtown.com/grid64behavior.mp4

#381

guess its possible something rotted in the source code. (seems unlikely but i’ll do a visual inspection when i get a minute)

but also worth checking with a computer, because i know there have been a lot of issues over the years when supporting second/3rd/nth-hand grids that have been self-repaired or built from a kit.

1 Like
#382

Good point. Is there a recommended simple way to get “hello world” with a Linux laptop and grid?

#383

on linux?
i would do:

git clone https://github.com/monome/libmonome.git
cd libmonome
./waf configure
./waf
./build/examples/simple
1 Like
#384

this looks like the bug i fixed for grid 64. the fix will be in the next beta.

basically, for some reason with grid64 the monomeLedBuffer maps as if it has 16 columns per row. basically:

row 1 maps to monomeLedBuffer 0-7
row 2 maps to monomeLedBuffer 16-31 (instead of expected 8-15)
etc etc

so without the fix it “eats” every 2nd row and shifts everything up.

@jnoble - i’ll send you the updated version when i get home tonight so we can test the fix with series as well.

1 Like
#385

@jnoble
…woop, looking now i guess the “simple” example isn’t as simple as it could be, cause it uses serialosc
here’s a patch that points it directly at a serial port instead

libmonome_simpler.patch (631 Bytes)

@scanner_darkly ah… how odd. bitrot indeed. did you patch libavr32 or somewhere else?

1 Like
#386

nope, handling it in teletype code - i assumed that’s just how it worked.

… i think it’s this (monome_idx_xy also):

1 Like