Micro USB Audio and Link Cable

I think you mean length of the calbe you mean.
for both serial and TWI cable length can be quite long (I believe TWI even longer at same voltage) but the longer the cable the lower the baudrate.
TWI’s clock signal makes it more reliable.

I agree.

It’s just a matter of choosing the right value for the pullups and shouldn’t be a problem for GPIO pins.

Great idea! and we can call it ArduPi :stuck_out_tongue:

Getting back on my erlier idea (a while ago) about mixing the serial signals with the USB signals. TWI is open collector driven meaning the signals are normaly floating (and expected to be pulled up by external resistors) and are pulled low when active.
So I don’t see any problem in hooking up SDA and SCL to USB D+ and D-. The required pullups could be put in a small gender changer USB adapter (board).

Oh man I so like this idea now ! TWI over USB :smiley:

I want to stay using the aux cable. I don’t want to require any additional adapters.

1 Like

So last night I met with an audio engineer and we brainstormed.

It’s going to need a little more fiddling, but the main concept is this:

To avoid sending serial data through a headphone there a few changes to be made.

The mechanical switch will actually be a electronic set of fets to swap the signals.

The software will by default start in slave mode. In order to enter master mode, it will send a TX signal on the MIC line. So if headphones are plugged in, then obviously there is nothing there to receive it, and send the response. Only once a slave has become initialized and reports back to the master, can serial data be sent on the L or R audio channels.

The other change we could potentially make, is that when multiplayer is not initialized, to duplicate the audio signal onto both L and R channels, so you can get sound in both headphones.

So in conclusion, a GPIO will be broken out to switch a master/slave fet toggle.

1 Like

This is all starting to sound very complex. A seperate link connector would make things much easier.

Lol can we do it over a micro-hdmi port?

No but seriously, if we want to protect the users ears we will need to do this safe initialization.

It’s not complex, it’s elegant. I’ll draw up the schematic and you will see.

Hey @dxb as far as the two pins, are they always differential signal? So when one pin is set as an output, the other is set as an input? OR are they both output, just being cycled between on and off?

OR do each pin receive it’s own unique PWM and the resulting intersections create additional edges?

ATMLib always configures those pins as being one complementary outputs i.e. when one is low the other is high and viceversa. There is an Arduboy tones library that programs the two pins as independent outputs driven by two separate PWM capable timers so in that case the two pins change state independently from each other.

Yeah seems the edge case here is games I made lol where I have two instances of playtunes running on different pins.

The need to get at that second pin in those instances is what is throwing me for a loop on this design.

I think you could “mix” those two PWM pins by XOR’ing them.

Yeah I think so too I’m not sure how you would do that in a schematic because I am noob.

I can probably get that in a sot 23 then huh?

When using a XOR gate, you won’t hear a sound with the libraries that drive one pin the reverse of the other (like ATMlib)

( 0 ^ 1 == 1 and 1 ^ 0 == 1 so the result is always 1 )


So really you need a + b / 2?

(/ 2 is cheap because it can just be >> 1, but + means an 8-bit binary full adder,
which probably isn’t quite so cheap.)

Why not just A+B, AND should work. The problem is if you AND the output from atmlibrary it is always differential so again it’s always 1.

Which seems more appropriate for sound behaviour?

(7 + 5) == 12
((7 + 5) / 2) == 6

That has opposite problem of ^ (XOR):
1010 ^ 0101 == 1111
1010 & 0101 == 0000

Disclaimer: I’m worse at sound stuff than I am at maths.

I think it will work for the purposes of single channel mono on one pin. You’ll probably want to put a series capacitor there so that you limit the current going between the pins, but that is trivial.

The challange is using this system also with the ATM lib, because they will always be inverted from each other. The edges are created from the swapping of the signals. If tied directly into the amp that is fine because the amp is expecting that. But if the signals are tied together then it won’t work. That’s what that trimpot does.

Of course… I don’t know what I was thinking when I wrote that. Thank you @Mr.Blinky.

I really don’t know what I was thinking the other day… Anyway, what about adding (with a half-adder) one bit and the complement of the other and then feed the result into a DAC like @Mr.Blinky proposed?

I imagine the amp’s other input pin would have to be at the same potential as the DAC output voltage for b01.

We’ve reached the limits of my technical competency lol.

Resurrecting this thread as I saw this on Twitter:

Could this potentially work to link 2 Arduboys together for multiplayer?