#54

Certainly possible, and no harm in re-installing the 1.5 firmware

#55

I’ll plan on doing that tonight and report back. Thanks!

1 Like
#56

So working on updating to latest White Whale firmware. I’ve downloaded the file from https://github.com/monome/whitewhale/releases, which went fine. But following the directions on Monome’s firmware update page for Mac, it states

“there’s a script called update_firmware.command within the named module folder.”

which I don’t see anywhere in the folder. There are two folders, libavr32, and src. The src folder has a few files named

config.mk
flash.command
flash.sh
main.c
Makefile

But nowhere can I find a script called "update_firmware.command.

I tried running the flash.command twice, since I missed the first error output, and the second error returned this…

Checking memory from 0x2000 to 0x3FFFF… Empty.
Chip already blank, to force erase use --force.
Error opening whitewhale.hex
See --debug=51 or greater for more information.
logout
Saving session…
…copying shared history…
…saving history…truncating history files…
…completed.

Am I missing something? I hope I didn’t jump the gun and prematurely run the wrong script…

Okay, I found the correct file after a quick search for that specific script. Sorry about that. But now the I show this while trying to update the firmware.

dfu-programmer: no device present.

SOLVED:

I had to bring the whitewhale.hex file over to the same folder. AND all TT commands are working as expected!

2 Likes
#57

I think you only needed whitewhale-1.5.zip, which has the flash.command and whitewhale.hex file.

1 Like
#58

Just wanted to say thanks again to the trio above for putting this guide together (and all those that contributed and clarified). It has been great to be able to refer people here who have questions.

4 Likes
#66

Theoretical question: if I had a module connected at the very end of an i2c bus and wanted to DIY a switch to connect/disconnect it on the fly, could that cause potential damage to any modules connected to the bus while the system is powered on?

#67

not sure about hardware damage, but in any case i2c implementation used by monome modules doesn’t support hotplugging.

1 Like
#68

If you power off and on a follower - you might run into a problem with the follower no longer being recognized after it’s been disconnected from a leader.

1 Like
#69

Sounds like a thing only to do when the system is off for safety and avoiding any bugs. Thanks y’all :+1:

#70

Hi all, can anyone confirm the i2c connections to TRS, I’m making connections today for the 16n.

Tip to SDA
Ring to SCL
Sleeve to GND?

#71

ya that’s correct…i’m having issues communicating from my FB to my TT using what i’m assuming is a similar modded trs to i2c cable. how did things go for you?

#72

Thanks for your reply. I don’t have my 16n yet, was just modding a mult in preparation for it’s arrival hence can’t tell you if it works. What issues are you having?

#73

oh nice, my issue is that my tt won’t determine the fader values of my faderbank over i2c. maybe @scanner_darkly can solve it? i checked the modded trs to i2c cable w a multimeter and everything works. the faderbank is acting as a follower as the 4.7k resistors were left off. aside from basic communication from the faderbank to the tt, i was hoping to send messages from the faderbank through the tt to the er301. not sure if that’s possible but seems like it should work.

#74

correct, minijack is:

sleeve - GND
ring - SCL
tip - SDA

@okyeron we should add this to the guide!

3 Likes
#75

sounds like you need pull up resistors, since your 16n doesn’t have them, and you’re not using anything else that would provide them (like TXb or backpack). this is just a guess though, as i2c is a bit of a voodoo, and i’m not an expert in hardware. but if you can borrow a TXb or backpack from somebody i’d try that.

16n Faderbank: build help, dev suggestions
#76

from what I understand the pull-up resistors are intended to connect the fb directly to the er301, ansible or txo which would place it in master-mode. also i forgot to mention i am using a backpack on the tt.

#77

sorry it’s the firmware that places it in mastermode.

#78

pull-up resistors must be provided by at least one device. i’m not sure teletype alone provides that. the backpack will, however.

with everything connected, are you able to send i2c from teletype to er-301? if it works, the next thing to try is update 16n with leader firmware and see if it can send to er-301 directly (you will still need to have backpack connected for pull-ups, just don’t send anything from teletype at the same time as multiple leaders are not supported).

no, the leader/follower are two different firmwares. pull-up resistors don’t control the mode, they just provide the hardware needed by i2c.

#79

iwith everything connected i can send i2c from the tt to the er301 yes.

oh i see i was under the impression that the fb could be loaded with the follower firmware and communicate through the tt to the 301.

makes sense thanks for clearing that up.

#80

yes, 16n can be loaded with either the leader or the follower firmware. teletype can only poll values from 16n when 16n is running the follower firmware, and you can only send directly from 16n to er-301 when it’s running the leader firmware. in the setup when you have both teletype and 16n connected to er-301 you want 16n to run the follower firmware (as multi leader setup is not supported), and then you use teletype to poll 16n values and pass them to er-301.

instructions on how to load 16n firmware should be in the 16n thread.

2 Likes