Emax

well, since I wrote my email yesterday I got my hands back on my service 
manuial... and bugger me, the emax really truly does generate a clock 
for the RS422 signal - when I played with RS422, it was obviously just 
the asynchronous version.....

SO I went and looked more in depth at asynchronous 422 adapters for the 
PC, and there's definitely devices out there that connect at the 
PCI/PCMCIA/expresscard level, and support tx and rx clock inputs....

if you wanted to do comms via USB, depending on packet size, an option 
might be to try and get a usb adapter with a bit of smarts. My friend ed 
suggested this - you can get an atmel AVRUSB evaluation board for not 
much $$ - now - there's a basic library that's been developped for this, 
so the PC comms side of the implementation is done. you would just have 
to write code (in C using the AVR port of GCC, with atmel's avrstudio 
IDE and you can program it via USB so the evaluation board is the only 
thing you'd have to buy here) to handle clocked serial data... and any 
kind of critical timing you need. only issue would be if you application 
needed more scratchpad space than the onboard RAM of the usb evaluation 
key....

Do you have much extra information in terms of the messages sent 
backwards and forwards and the overall communication protocol here? from 
what I can see, the RS422 interface is really the same interface as the 
MIDI interface, once you're past the voltage levels and baud rate.

Can you send normal note data, for example, via RS422?

PS, an eye diagram is what you want to look at with observing signal 
integrity - yeah, you can't read bytes this way, but if you trigger on 
every bit transition, and have brigntness up, to keep a bit of screen 
persistance, you can get a very good idea of if the voltage signal 
coming out of your emax is noisy, or if there's timing jitter at a bit 
level....
http://www.ee.ualberta.ca/~grover/EE489/Lecture_handouts/Eye_Diagram_Tutorial.pdf

PPS, do you have the EII schematics?? is there any difference between 
the serial port implementation on the emulatorII vs the emax??



esynthesist wrote:

>Thanks for this information.
>
>I understand that an analogue scope could be sufficient to analyse 
>the voltage levels, but I don't understand how such a scope can help 
>in checking the data integrity... the pulses are sent at 500000 
>pulses per second and are not symmetrical so I assumed I would just 
>see some fast moving pulses passing through the screen, too fast in 
>fact, right ?
>
>About the timing: the strange thing is that when I go in 
>conversational mode with the EII, it doesn't really care about the 
>time between bytes, commands, ack/nack, ... I wrote a terminal 
>program in which I can send one or more bytes to the EII and receive 
>one or more bytes from the EII. 
>A small example: the command to send 5 bytes to a certain position in 
>the EII memory is a stream of 4 bytes, e.g. FF 00 96 05. Then the EII 
>should answer with a kind of ACK (one byte) after which it expects 
>the actual 5 data bytes to be sent from the computer. Now when I send 
>the command byte after byte with pauses of 2 seconds between them, 
>it's OK for the EII. After receiving the ACK from the EII I can send 
>the 5 actual data bytes one by one, again one by one and even with 
>huge elapstime in between them, that's still fine for the EII. After 
>receiving the last byte it ACKs that it's OK. But when I the command 
>sring or the databytes in one move, the EII starts complaining. 
>Strange. At the other hand this might proove that it's a problem with 
>timing...
>I have no timing problems for receiving data from the EII.
>
>Maybe I will buy a s/h analogue CRO to check voltage levels (to be 
>sure) and a logic analyser to check timings.
>I'll also perform tests with the Emax instead of the EII during the 
>weekend.
>Finding a PC/Express card RS422 will be difficult I guess. I only 
>have laptops...
>
>Thanks
>
>///E-Synthesist
>
>
>--- In emax@yahoogroups.com, mr julian <jujulilianan@...> wrote:
>  
>
>>In my experience with comms between an embedded system and a modern 
>>    
>>
>PC, 
>  
>
>>your biggest problem is likely to be the timings.
>>
>>Not timing between edges on the data (and control lines? does emu 
>>    
>>
>gear 
>  
>
>>implement these? I don't have my emax service manual right now) but 
>>timing at more of the "transport" level - between data packets. 
>>especially requests, and acks. Possibly even timing between bytes...
>>
>>I haven't done anything with RS422 since my first proper job, 9 
>>    
>>
>years 
>  
>
>>ago (eeeek!) but RS422 is pretty much the same as RS232, in terms 
>>    
>>
>of 
>  
>
>>signalling, only lower level and balanced. As far as voltage goes, 
>>    
>>
>there 
>  
>
>>is a lot of margin in the design between what a transmitter should 
>>    
>>
>aim 
>  
>
>>for and what a receiver should act on.
>>
>>Anyway - I've done a lot with RS232 lately, and can tell you that 
>>    
>>
>USB 
>  
>
>>converters on a PC for RS232 can fail with older embedded gear, 
>>    
>>
>because 
>  
>
>>the embedded gear was written when computer interrupts were a lot 
>>tighter, and serial comms were not also piled on top of a USB 
>>    
>>
>interface 
>  
>
>>with its own hold-ups and data negotiation crap..... they could 
>>    
>>
>expect 
>  
>
>>an ack to a query a lot faster than they get now...... and so their 
>>timeouts are pretty intolerant of sloppy responses, and with USB 
>>interfaces especially, they can very easily fail.
>>
>>if you wanted to try something on a PC, have a go with a PCI (or 
>>    
>>
>PCMCIA 
>  
>
>>or expresscard if you have a laptop) card that does RS422. they'll 
>>    
>>
>be 
>  
>
>>more expensive than the USB equivalent, but you won't get the 
>>    
>>
>faffing 
>  
>
>>about related to the USB layer that is almost definitely the thing 
>>killing your comms attempts.
>>
>>Also - no need to buy a digital storage CRO here - if you want to 
>>analyse the integrity of serial data, you can see a lot with just 
>>    
>>
>an old 
>  
>
>>analogue CRO - looking at the integrity of the "eye" as long stream 
>>    
>>
>of 
>  
>
>>data goes past. If you want to analyse the actual data, then you're 
>>    
>>
>much 
>  
>
>>better off with a logic analyser. a cheap USB logic analyser would 
>>    
>>
>do 
>  
>
>>exactly what you want, and you'd be able to look really in depth at 
>>    
>>
>the 
>  
>
>>timings, at all of bit level, byte level, and packet level, if you 
>>    
>>
>get 
>  
>
>>one with a half decent amount of memory.
>>
>>    
>>
>
>
>
>------------------------------------
>
>Emax and Emax II User's Group Website
>
>http://www.silveriafamily.comYahoo! Groups Links
>
>
>
>  
>