Emax

It seems there are only five different Emu RS422 equipped samplers to be supported: Emax I, Emax II, EII, EIII and EIIIx. So it should be quite simple 
to have some DIP switches on the interface that could be used to select the type of device in use. I am of course assuming the interface would only be 
connected to one sampler at a time... 

/Tristan

Tuesday, November 25, 2008, 6:12:14 AM, you wrote:

>
I hope you can create a device which is not restricted to the Emax ! 
If we could use the same device with the EII that would be awesome.

From a software developer's point of view, it would be really nice to 
have a device which can be instructed by software to:
- run with any supported internal clock rate (at least 31.25 kbaud 
which we really need)
- run with external clocking
- use X databits, Y stopbits and Z parity.
- (perhaps) use some timing parameters, like "max time between two 
bytes" (but I'm not sure we really need this)

That's all I want :-) and it would be the most flexible solution, 
capable of communicating with any Emu sampler supporting the RS422 
interface.

I hope I'm not dreaming ?
Crossing my fingers...
Good luck !

///E-Synthesist 

--- In emax@yahoogroups.com, mr julian <jujulilianan@...> wrote:
>
> 
> 
> tu@... wrote:
> 
> >Thanks, this protocol makes sense. No doubt Emu did it this way so 
they could reuse the SDS sample dump code. Can you confirm that the 
Emax 
> >always waits for an Ack/Nak before sending the next packet? This 
is important to know, as the buffering requirement is much lower if 
we can be sure a 
> >new packet will not arrive until after the last packet has been 
handled.
> > 
> >
> yeah..... that would make things really simple.
> :-)
> 
> >A side effect of this is that when operating at 31.25k baud the 
Emax UART is actually working in asynchronous mode. Synchronous 
operation 
> >only happens when the x1 clock divider is used. Therefore the Mac 
is presumably doing the same thing at its end when switching between 
the baud 
> >rates.
> > 
> >
> I'm pretty sure the mac would have to have it's own clock for 
> asynchronous communication.
> 
> in asynchronous mode, the UART runs at much faster than baudrate 
speeds 
> (say 500k for 31.25k data ??which is why the emax works fine at 
asynch 
> 31.25k with this as it's clock, still... ;-) and continually 
samples the 
> serial data for the start bit. then when it's got a valid start 
bit, 
> having detected the falling edge at the beginning, it samples the 
rest 
> of the bits in the middle, and confirms the final edge of the stop 
bit. 
> all being good, the received byte is latched to the output.
> 
> 
> >The easiest solution from your software perspective would be if 
you could have a USB serial port that supports synchronous RS422 
connection to the 
> >Emax (or other Emu sampler). Then you handle the protocol, baud 
rate switching etc and you can use standard Windows drivers. This is 
presumably 
> >what the expensive commercial interfaces are offering and I 
presume this is what Julian is working on a low cost alternative to. 
> >
> yep!
> :-)
> 
> basic solution if this works will be one $30 dev board, wired to a 
> separate board with a couple of ICs. I will just veroboard the 
custom 
> stuff for now, but if it works and a few people want one, can 
always get 
> a batch of small PCBs made up for a few $.
> 
> if I can get away with a simple unchanged serial adapter, that 
would be 
> amazing - otherwise I might have to put some smarts into my buffer 
that 
> will make it only work with the emax (ie look for header info and 
> deliberately hold off a packet retransmission to the emax until it 
has a 
> whole one, etc etc - basically make it run off the actual data that 
> comes through it...)
> 
> >Another option would be 
> >to have a microcontroller with a large buffer memory that the PC 
can read from and write to using whatever protocol and the 
microcontroller would 
> >handle the Emu sampler synchronous RS422 interface and protocols. 
Obviously this would be more work to develop the software for the 
microcontroller 
> >and possibly the drivers. 
> > 
> >
> yeah - would be best not to have to do that if at all possible.
> also, half a MB of fast access RAM for buffering would be annoying 
to 
> deal with hooking up on an 8 bit micro.
> 
> >Another possibility would be to have a micro controller with two 
serial interfaces, one to the PC (asynchronous RS422 or RS232) and 
one to the Emu 
> >sampler (synchronous RS422). The micro controller would just 
buffer and pass data between the two UARTs and switch baud rates 
(31.25k/500k) 
> >toward the Emu sampler if required. The PC host could connect via 
any off the shelf USB to RS232/RS422 adapter or use a built in or PCI 
serial port. 
> >Because of the flow control provided by the Ack/Nak messages, the 
PC serial connection could also use any baud rate the PC port 
supports. Although 
> >dumps would be slower at PC baud rates lower than 500kHz, this 
would make it widely compatible with any old PC you might happen to 
have lying 
> >around. Both the microcontroller software and hardware would be 
fairly simple for this option and no special drivers would be 
required. The Emax serial 
> >port even provides +5V that could be used to power the small 
interface board.
> > 
> >
> 
> A serial rate converter would be even simpler, but it would be nice 
to 
> be able to have PC side running fast enough that there was no gaps 
> between bytes in a packet, as seen by the emax.....
>