high speed comms

[QuIcK]

Right, I have a side project that I'm thinking about.
I'll give you a quick run down, then ask the questions.
Its a digitally-controlled-analogue mixing desk. There will be a large box full of the analogue side of a mixing desk, and a large nice control surface.
The idea being the signal path for audio is very short, and near all the other audio processing things. The control surface can then be put somewhere more sensible.
The heart of each channel is a 16*16 audio matrix, and the multiple pga2310, meaning that the desk can be set up in many configurations, allowing for some insane routing options.

So, having come up with a nice lay-out for the control surface, it has the following PER CHANNEL:
53 push buttons
9 analogue inputs
200 LEDs

Now, i realise that no picaxe is ever likely to have that level of I/O. However, the picaxe is extremely useful for controlling the analogue side of things, eg sampling faders and setting the pga's etc, as well as bridging to SPI, as required for some of the io chips.

I originally thought of basing the whole thing around the I2C bus, with a USB-I2C convertor, the control surface can be read by a computer, sent by ethernet to another computer, then converted back to I2C to control the analogue.
This allows the controller-pc to read the values of all the controls very simpley.

Now, heres the problem:
53 button = ~7 bytes
9 analogue = ~72 bytes
200 LED = ~25 bytes
all rounded up.

therefor it takes 104 bytes to describe a channel.
which is 832 bits. for 8 channels, its 6656 bits
i2cfast runs at 400KHz. Including address etc, thats 100Kbps.
this means, to describe 8 channels, the max fps is 15 fps.
Ideally I would like to run it at 30 fps.

Question Time:
What is a fast and common protocol that would allow me to describe 8 channels (or more) at 30fps?
Is it a case of getting multiple I2C busses set up?
Or should I get something like a pci-96IO card and bit-bang multiple I2C ports?

 

[vttom]

Keep this in mind...

Not every input is going to change every sample period. So, you probably don't need as much bandwidth as you think.

If this were me, I would split up the inputs amongst several PICAXEs, or whatever it is you chose to monitor them. And then, only when a change is detected from one sample interval to the next do you send an update message to the master.

This is more-or-less how MIDI works, and that's based on only ~32kbps serial communications.

 

[hippy]

As vttom says. The desk will be initialised when the setup is turned on ( a huge dump from from the PC ) but when running you only need to record and later playback the changes.

If I2C is good enough for 15fps it will be good enough for 30fps if only half the data is sent at any time.

The difficulties come when lots of things change at the same time, moving a set of faders up or down, pushing multiple buttons. If the update isn't fast enough you may get delayed response, aliasing ( when one fader moves or button push occur later than another ) or the faders step rather than fades.

Fast processing times and fast inter-connects are key there and professional equipment usually has the controlling PC embedded with the other hardware with very high-speed links between the two ( dual port RAM is probably the fastest ), or does all the hardware control itself via purpose built hardware connected direct to the PCI bus.

This is why professional equipment often costs $10K upwards and using $10 micros is going to require some compromise or the additional of extra hardware which adds to the cost.

 

[QuIcK]

i realise that, and the budget is not tight. Im not trying to make a cheap piece of equipment that will do everything i want, and make coffee.

what i'm stuck on is starting this off, tbh.
I was wanting to use the I2C bus, so the picaxes would sample the fader, and put the value in scratchpad. the pc could then read the scratchpad, and act accordingly.
If it isn't going to be fast enough, perhaps an fpga is the way to go on this.

 

[hippy]

Speed may not be a problem but that depends on system design and how much data you need to pass over. FPGA or a dedicated microcontroller may be a better solution is budget isn't a problem as that will give you greater control over what you want to do without having to busk around what may become limitations through using a PICAXE or a network of them. While the PICAXE is ideally suited to many projects it is not suited to all.

That said, the project may still be achievable with PICAXE's. One handling each channel ( or maybe multiple PICAXE's per channel handling separate parts of that channel ) and paralleled I2C communication links could overcome any bandwidth limitations if there are any. If there are no bandwidth issues it should be simple enough to hang a whole bunch of PICAXE's onto the communication's channel.

The situation is the same whether using PICAXE or any other controller, a choice between using one fast processor or a distributed set of slower processors. Each controller will have limitations as to how much they can do in a given timeframe which dictates how many have to be used. So it's a question of system design, knowing what each part of the system has to do, how quickly it has to be done, and how much data has to be transferred and between what.

Your basic proposal seems sound enough but has an identified communications bandwidth problem; if that can be removed by sending less information then it should still work and at the speed required.

 

[QuIcK]

hmm, Ill have a think about reducing bandwidth.
unfortunately, each led needs to be controlled individually, so i can use a bcd-style decoder. I originally planned to use 8-bit pwm chips on the leds, so they are dimm-able, allowing for colour blending and more obvious colour coding schemes. scrapped that when i started calculating bandwidth .

the output isnt a problem. theres a max chip (cant remember part) that allows control of 56 leds (8x7seg display driver). a couple of these, and thats a channel sorted.
a picaxe 28x2/40x2 will easily handle the analogue conversions, and i might look into some sort of input expander chip. any suggestions?

the DCA is all 8-bit, so theres not much point in sampling at 10-bit. unless i decide too use linear faders and need to bit-log them to turn them into logarithmic.
I dont think i'll use motorized faders, i'll set up a few ways of indicating fader/knob position very simply.

I recon i'll go with a potent fpga with an ethernet port and vga on it. then i only need a computer with the analogue rack, which can be controlled by either the control surface or another computer.
bit bang multiple i2c busses on the fpga, one per 2/4 channel, and use logic to que them up for transmission over ethernet.
im counting the master section as equivelant to 8 channels, so for 16 channels, thats 4 or 8 i2c busses, or 8/16 io pins on an fpga.

any suggestions for a nice fpga? ive been drooling over some of the Stratix chips, but i think thats going to break the bank.


as for the DCA side of things, there is much less data to be transfered! like in the region of <24 bytes per channel. therefor, for 16 channels, thats 3200 bits, which will fit into an i2c bus at 30fps, with everything refreshing at once.
however, on top of that, i also need to send audio levels back to the control surface, i.e. input level, output level, that sort of thing.
typical vu meters run at 3fps (rise/fall time of 300ms), so i recon a picaxe with the audio-peak analogue circuit will be able to sample this fast enough, and down the same i2c bus. (4000 bits/s left, 8bits * 16 ch * 3 fps = 384 bits/s)

 

[boriz]

As Vttom alluded too, you will rarely (if ever) need to TX all the data all the time. Far from it. You only have two hands. Like with video compression, you don&#8217;t TX every &#8216;frame&#8217;, you just TX the changes made between frames.

EG:
On channel 3 you press down button 12 and button 13 and release button 14, and at the same time using the other hand you move sliders 4 and 7. Similarly you can reduce the LED overhead by just addressing directly the LEDs you want to change. Like &#8216;LED numbers 22,23,24 and 199 ON&#8217; &#8211; &#8216;LED numbers 1,2,3 OFF&#8217;.

A packet containing the above info might look something like this:

<nibble> cn &#8211; Channel number = 3
<nibble> nON - Number of buttons changed to ON state = 2
<byte> aON1 - Address of ON button 1 = 12
<byte> aON2 &#8211; Address of ON button 2 = 13
<nibble> nOFF &#8211; Number of buttons changed to OFF state = 1
<byte> aOFF1 &#8211; Address of OFF button 1 = 14
<nibble> nS &#8211; Number of slider readings updated = 2
<nibble> aS1 &#8211; Address of slider 1 = 4
<byte> pS1&#8211; Position of slider 1 = 128
<nibble> aS2 &#8211; Address of slider 2 = 7
<byte> pS2 &#8211; Position of slider 2 = 255

A grand total of 64 bits / 8 bytes.

 

[QuIcK]

aye, right enough.
although, automation allows you to make multiple passes of recording.
if it was just a control surface, with no recall, then that would be dandy. but there is a chance that 8 faders are going to fade down over 2 seconds, and as they start fading up, the pan or aux sends are going to fade as well.
which is 8 bytes for fade-downs per frame, and 27 bytes for fade up, per frame, in this situation.
plus, the master section may be updating/automated.

whilst only logging updates, the i2c bus still has to pass all the data for the main controller to analyse what exactly is a change. altho, the individual controllers could do this, they may not know what they are suppose to set, i.e. changes could be made through a menu system, or pre-recorded automation.

whilst they could be programmed to do this, the amount of processing (altho distrobuted) would be higher, and my plan of using 1 pic for analogue per channel, and the rest being support i2c chips wouldn't work, as a support i2c chip doesnt know if it has changed, it just sits there and gets read by the i2c master.

I think, in my case, i'm going to go for an fpga to detect changes and what not, with multiple i2c busses. this makes it easy to parallel process each channel, then syncornise updates/saves with a midi timecode

 

[QuIcK]

Thanks for all the suggestions! ive definately got a plan of action now.
has anyone had any experience with embedded systems like this?
or large i2c busses?
any suggestions to keep errors to a minimum?

 

[inglewoodpete]

A stadard i2c bus with 4.7k pullups is reliable up to (about) 1 metre. Check the spec!

I have experience with extended i2c busses. The bus uses special driver chips and works at a lower impedance. From my experience, in an electrically noisey environment (many motors) but with screened signal cable, the bus worked reliably at 100kHz up to about 12 metres. In my case, the capacitance of the cable started to affect the signal propagation delay in the region of 14 metres.