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)
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?
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!)
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.
answer after quick search is NOPE
will look at the PCB and figure out if there’s a possible hard hack
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:
Can anyone confirm that a 64 greyscale grid will work with grid ops?
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):
Thanks so much! I was looking for a smaller grid solution and ran across a 64 for a decent price.
Edit: This is apparently not a “grayscale” 64 but rather a “series” 64? Will it work OK?
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.
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.
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)
I made a cable for testing today and have some strange results:
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.
Good point. Is there a recommended simple way to get “hello world” with a Linux laptop and grid?
i would do:
git clone https://github.com/monome/libmonome.git cd libmonome ./waf configure ./waf ./build/examples/simple
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
row 2 maps to
monomeLedBuffer 16-31 (instead of expected 8-15)
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.
…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?
nope, handling it in teletype code - i assumed that’s just how it worked.
… i think it’s this (