those RTS(ready to send) and CTS(clear to send) +/-(differential pairs) are two separate signals. neither of which is a clock. They're handshaking signals, used to signal and control the data flow between 2 devices. So if that's what you have on your RS422 ports, but nothing labeled something like "clock in" or "clock I/O" you don't have any synchronous comms compatible RS422. It appears that without synchronous communication, the emax won't work... after first posting about what you might need, I went and got back my copy of the emax service manual, and it shows very clearly a 500k signal going from the emax to the computer. the issue here is, that with a different 500k clock on the receiver, you can have the units basically appear to work. but no two 500k clocks are exactly the same frequency - and here's the sticky bit - the emax needs a long sustained transfer... so even if they start off in step, eventually the timing of the devices moves so the receiver is out of time with the transmitter, and you get a data error...sound familiar? and because it appears that the emax kills a whole transfer on a data error, once that happens, it's all over. if the EII has a more robust protocol, it could run without synchronisation, and just re-transmit a failed packet whenever inevitable clock differences cause a problem. I thought I had sent a link earlier to a card that would work, but on double checking I hadn't.... must have looked it up when i was investigation the PC side of synchronous RS422, but not sent the link..... anyway - here is one that will do what you want, on configuring correctly and hooking up the right pins. but US$399 makes it more expensive than an emax... http://www.quatech.com/catalog/rs422s_pcmcia.php I've just spent an hour or two looking around, and haven't found much that will do what you need for a lot cheaper..... :-( Anyway.. I'm spending another few hours evaluating something else now. I've had one of these sitting around at home for a while http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879 And its a cold windy sunday afternoon here. I've been meaning to have a go at playing with that eval board with this software for a while. http://www.fourwalledcubicle.com/MyUSB.php I'm not sure if it's an option yet, but this could be the basis of a solution for the problem. Especially if the issue isn't packet-packet timing, but is simply just an issue with serial data synchronisation... esynthesist wrote: >You made be thinking again. > >When I started my experiments I asked for some advice on serial >communication on a Dutch electronics internet group. One of my >questions was whether the 4 handshake signals on the standard RS422 >(RTS+, RTS-, CTS+, CTS-) can be compared in some way to the HSKi and >HSKo signals of the Mac serial port. Specifically I was also asking >what to do with the + and - signals, given the fact that the >Emax/Emulator sends a clock signal which is going + and - on the same >line, while the RS422 expects seperated opposite signals. >I also asked if an independent clock in the PC RS422, running at >500kbaud would be sufficient, instead of external clocking. >At the end the experts on this group confirmed that an independent >clock should be OK, even if it's not clocking exactly at the same >speed of the Emulator II and that phasing problems can be ignored. >One of the arguments they based their conclusion on was that the >Emulator II communication protocol is *asynchronous* (as also stated >in the technical documents of the EII). >Were they wrong ? > >And do you know the most appropriate wiring between the 4 >RS422 "clock" pins and the single clock pin of the Emax/Emulator II ? > >Or do I understand you completely wrong, and are those "external >clockable RS422 devices for the PC" not using these 4 signals but >even another one ? > >By the way: what exact link to which RS422 device are you talking >about ? I reviewed the messages but didn't find a direct link ? > >///E-Synthesist > > >
Message
Re: [emax] Re: RS422 fun
2008-11-23 by mr julian
Attachments
- No local attachments were found for this message.