#334

would be very nice, especially if delay-time could be customized in the code

#335

Doesn’t quite sound right as i2c is a bus, unless there are messages sent on bootup that are read in a weird way.

#336

a Follower device needs to be powered before the Leader or it won’t register when the Leader power’s up.

I think this works out fine with devices powering up at the same time on the same board, but get’s a little messy with devices on separate power supplies. (or some devices might have little delays due to boot up processes, etc.)

In practice, power your 16n after your ER301

1 Like
#337

would be good to throw this in the i2c guide

3 Likes
#338

Here are mine, with blind standoffs so no screws visible
faderbankTop.fpd (981 Bytes)
faderbankBase.fpd (858 Bytes)
These are 3mm thick, vertically brushed, Blind pillars literally only cost a dollar or two extra and make it so much more in line with momone design

1 Like
#339

Good question. To extend on what was shared above…

Most times I’ve had no problem with boot order. I have had more fussy behavior with busses that are extended to the limits of the pull-up resistance. Due to the number of devices and amount of cabling connected, they can be in a working - but in a brittle state.

The first place where you can see things start to get weird on a bus is with i2c reads. When the bus is weak - they start failing and can cause the sending device to lock up (in the case of the Teletype). It may happen very rarely, which can be difficult to isolate and troubleshoot.

This can be problematic if you have a script on the Teletype starting up immediately and firing off commands - or a 16n that starts broadcasting i2c the moment it is turned on. On an unstable bus, or a bus that is still getting up to the proper pull-up resistance to be stable, you can have problems.

I do have a crazy setup on my dining table right now that is bridging 3 micro-cases with 9 i2c modules and an external 16n. With it, I’m finding that boot order matters. Turn things on in the wrong order and the whole thing hangs. It is consistent with @okyeron’s point above - followers first - then the leader.

That said, I’ve done crazy stuff with i2c and have had lots of devices connected without problems. One you have a stable bus - you usually have a stable bus. But, don’t be afraid to experiment with cable lengths, device spacing, and pull-up resistance to make sure you have a stable configuration.

Now - specifically on the ER-301. There was a time where there was some weirdness on startup. Not the exact situation, but it was startup related. This was corrected some time ago. Here is a reference to that area of the thread over on OD if you/anyone are curious.

2 Likes
#340

um, according to your file, the blind posts added $37 to the cost.

#341

Yes, actually it is more than I originally said
Panel goes from 101euro to 71euro (posts removed) but then up to 80euro (to add the 8 countersunk holes)

Comes in at a 20euro premium

1 Like
#342

I’m trying my 16n on the following setup: Teletype with backpack—>ansible 1, ansible 2, Telex I, Telex O, ER-301.

When I add the TXb (no additional power) and the 16n, the Teletype tends to hang after few seconds. I’m not sure it’s communicating with the 16n at all or not. My stereo cable is about 6 feet. Sounds like this might be too long. Also, what’s up with the boot order? How could even get the 16n to boot after the 301, as they are connected to the same bus/case and supposedly you can’t hot plug…??

#343

6ft is pretty long for i2c, i’d test it with a shorter cable. also try powering your TXb - this might help (i had to do this even with a much shorter cable). re: boot order - it’s not for plugging i2c (which indeed you shouldn’t hot plug), it’s for power - power your eurorack first, then 16n.

1 Like
#344

Uh, er, how do I power the 16n? I assumed it was drawing power through the cable connected to TXb [reveals his ignorance…again]. Do I need a separate power source? How is it connected? To the micro USB on the 16n?

Also, I thought I was supposed to NOT power the TXb? That won’t cause any problems?

#345

yes, you have to power 16n from the micro USB port (i2c does not provide power).

using a powered TXb in a setup with a powered backpack shouldn’t cause any issues as far as i know, but if you’re going to power TXb you don’t really need a backpack, you could just connect everything to TXb. i’d try it first with just teletype+TXb+16n, see if that works, then plug everything else.

one thing to remember is that with i2c it’s better to daisy chain devices instead of plugging everything to TXb or backpack. but i2c is a bit of a voodoo so just try different configs and see what works best.

1 Like
#346

Oy… Thanks so much, Ryan. I’ll give it a shot.

1 Like
#347

I’m up and running, thanks!

1 Like
#348

20 characters of great!

1 Like
#349

What’s the best way to use it ‘upside down’? Use the Scale command to reverse data?

#350

you can recompile 16n firmware to do this, if you’re comfortable working with arduino IDE (you just have to comment/uncomment one line, don’t remember the details, search this thread).

or if you just want to invert values read by teletype you could simply subtract from V 10:
- V 10 FADER #

2 Likes
#351

Would it be an idea to look into a CI solution to compile the firmware on new releases/tags? That way it would also be possible to compile the regular firmware and the “flipped” firmware as well.

1 Like
#352

Interesting. It looks like Teensyduino compilation on CircleCI is doable, although complex, but something to file away for sure.

As far as compiling multiple firmwares, that’d require manipulating config.h or uploading multiple ones. But I’ll take any suggestions, for sure. I have some links on the topic stored for another day.

#353

Doesn’t seem like this was shared already but it seems like you can get some panels and the PCB from pusherman at the moment :slight_smile:

1 Like