board to board bus - standards

[Rochey]

Andy,

I completely agree. My thought was a little more than simply point to point.

My thought was an embedded hub on a master cart, then each channel strip could look like a usb sevice, that could offer various services over usb. (Audio, control, midi, uart etc)

Using 2 pins for digital I/o allows for multiple guest data formats. The additional interrupt/ID can also be used to grab the attention of a host or set. I have a little time tonight to draw up a scheme to mux those control signals.

Cheers

/R

 

[Rochey]

this first attachment is what I was thinking of in a slave to host system.
In a slave-slave-slave-master type of system, USB may not be applicable, but other protocols like Midi, UART, and I2C become perfectly possible.
The ID pin can be set up as a simple voltage, run into a comparator to set the protocol switch.
Interrupts can use the same pin, providing the interrupt pulse length is shorter than the low pass filter that sets the protocol switch.

ID behavior done with static voltage
E.g. 4V->5V = USB
3.0V - > 4.0V = I2C
2.0V -> 2.9V = Midi
1.0V – 1.9V = Guest Protocol
<0.7V used for interrupt

Different protocols can exist in a multichannel system, providing Digital Section is not bussed. (must be master-slave, point to point)

 

[Rochey]

Just some notes jotted down on paper regarding the int/id pin.

Changing control methods is done slowly (if they change at all!) which allows interrupts, short in nature, based on a "pull to ground" to be used on the same line.

Thoughts?

 

[audiomixer]

Hi Rochey,

I have been thinking about the active protocol management scheme you suggested and came to the following conclusion (for myself) - implementing different protocols on the same bus has no direct added value, since you can only use one at the time and everyone will settle for the most convenient - from his own perspective. still attributing power, data, signaling to the bus does make sense in term of enabling the creation of not conflicting hardware, but there will never be dual control systems active at the same time I believe.

so for me the following is a sensible,  KISS solution:

* Pin definition can stay as proposed.
* data and int / mode lines are to be connected via jumper / resistor to the bus, so that they can easily be disconnected without hardware change.
* implementation can vary on data and int pins. leave unconnected per default.
* no feature creep on these pins restricted use for logic / signaling only.


how about that?

- Michael

 

[Rochey]

yeah, fair enough. I figured there may be times when you want to I2C/UART in to configure various items, then switch to USB to audio streaming... but I guess that's down to implementation.

enjoy.



/R

 

[Andy Peters]

Changing control methods is done slowly (if they change at all!) which allows interrupts, short in nature, based on a "pull to ground" to be used on the same line.

I cannot see any situation where a slave card would need change its "digital personality," or at least how that bus is configured.

Just my opinion, of course.

-a

 

[Rochey]

It may power up in uart mode for firmware updates, then switch to usb for functional use.

 

[Andy Peters]

yeah, fair enough. I figured there may be times when you want to I2C/UART in to configure various items, then switch to USB to audio streaming... but I guess that's down to implementation.

The configuration can be done over USB via an HID interface. And certainly within the USB Audio Class there is already support for most of the things you'd want to configure -- gain, EQ, compression settings, clock sourcing, audio routing, all sorts of things.

Firmware update is easily accomplished with DFU (Device Firmware Update) class support, or in the case of something I did with a TAS1020B, a custom HID report to send the firmware image to the processor.

But support for all of that in your master slot requires a fairly complete USB Host Protocol stack, including support for the audio class. I'm sure there is code out there but now you've gone from having a $5 ARM on your board to something a whole lot more complicated. OK, maybe it's a $15 ARM. Hah.

-a

 

[Rochey]

Andy,
thats kinda where I'm coming from. I foresee channels strips with an integrated MCU for handling recall etc, then a separate fixed function (in some cases) USB doing things like midi/audio etc.
There are a lot of fixed function USB devices that are going around which are nice and easy to use, but separate MCU's that bring signals out etc.

I'm actually trying to avoid putting a whopping great big uC on the motherboard, hence the discussion for UART and USB. Your digital motherboard could essentially become a PC.

/R

 

[Andy Peters]

I'm actually trying to avoid putting a whopping great big uC on the motherboard, hence the discussion for UART and USB. Your digital motherboard could essentially become a PC.

I'm not sure what qualifies as "whopping big" these days. 144-pin QFP ARM with USB etc etc?

HEY. A lot of the ARMs have 100-BaseT ethernet interfaces and the vendors include examples with lwip and the like. Why not put the lunchbox on your ethernet network? Run all of the control through a web browser. I AM NOT KIDDING.

-a

 

[Orpheus]

I was under the impression that ribbon cables are inferior to proper shielded cables, is that not true? Or is it a special grade of cable to be used?

 

[audiomixer]

I have been thinking about that for a while too...

shield is good mainly to keep external interference out. If you look at the rane pin1 doc and others you can see that it should be treated as an extension of the chassis. in the chassis (box, enclosure), this is not a problem anymore. crosstalk would be reduced by having ground wires between signals. the most critical signals on the bus are balanced. This is probably better then many out in the wild mixers I know.

backplanes in large scale mixers a common and do not provide shielding as far as I am aware.

connection reliability is an issue, like dislodged and loose connectors, but less with 'not for road production' gear. if you are paranoid about that or want to go to space with your mixer there are IDC ribbon cable connectors with latches. having a large PCB on an edge connector does not inspire more confidence to me, except if you have a precise mechanical alignment and mount.


- Michael

 

[Orpheus]

Those are some good points, Audiomixer! This has given me a lot to think about.

 

[joaquins]

I would purpose API7600/7800/8200 standard which could be found in the manual but seems to be discontinued product (doesn't appear any more on the website), why? so maybe no more, still a lot of them lying around and won't be bad to take it in to consideration.

JS

 

[audiomixer]

can you put that into a list so we can compare?

I can send you the excel as template if you like.

- Michael

 

[joaquins]

Here it is, page 10 http://www.studiomanuals.com/docs/api/api_7600_manual.pdf

In the 7600 manual, not in the 7800, why? It has stereo, 4 buses and 4 sends, all balanced. left side of the connector are hot buses, left cold. tree first pairs are ground, then left, right, buses 1 to 4 and sends 1 to 4 solo left and solo right, one ground between each signal and the other. then 4 more grounds and compressor link, mute group, solo in place and solo dc, for pins 61 to 64 in that order.

It is a bigger connector than yours and has less aux, but they are all balanced so it you may get half way compatibility. also a lot of more pins for ground (36 to be precise) which may or may not be an advantage (it will has a beefier ground but a lot of pins and wires involved). And the last 4 pins for utilities. You could erase 16 pins and still has all the important stuff and compatibility, getting rid of all the firsts and lasts grounds and utilities. so with a 48 pin connector be working on it.

JS

EDIT:in any case isn't impossible to build a adaptor to connect between and make them compatible.

 

[Orpheus]

What type of ribbon cable should be used? I know there are different types that have twisted pairs etc... I guess crosstalk is negligible?