Emax

We've tried to build the EMUSER around the Teensy++ board, and we had no success so far.

It seems like that upon bank transfer, the clock disappears on the XCK1 pin .
When unplugging-replugging the board the clock will come back.

We suspect the pin changes the direction (the input will become an output) 

Has anyone actually tried the firmware on THIS version of the Teensy ?

Any help is appreciated.

thanks!

OK guys, i do NOT recommend anyone to build EMUSER.

We spent over 15 hours to get this thing work, and there are problems with the hex files as far as i can tell (i guess it has not been tested with the recent Teensy hardware) and even if you attempted to look into the source code (which is shared on the Emuser homepage), you'll find that it will not compile. Files missing, library files are incompatible and such things. It's very far from well prepared.

I would be glad to share the knowledge and experience with the hardware we made, but since the software is far from "ready to use", you do better to write the thing from scratch, unless you have luck, and can get in touch with the author. Unfortunately i could not.

So, what's the purpose of this post? Don't think it is easy to do, and none will be here to help you. Probably there are too few Emuser users. It's a pity...

Pfff...

- "unless you have luck, and can get in touch with the author. Unfortunately i could not"
True, you have sent two e-mails to me, but both have been sent only TODAY while I was at work, and when I finally log on in the evening to my mailbox and to this forum you are already posting this kind of messages ???

- "It's very far from well prepared."
This may be true for the source code part of the firmware (see next bullet) but on the other hand:
Do you have any idea how many hours, days, weeks we (Julian and me) have worked on the EMuSer to get it working ? Do you have any idea how many hours I have spent on writing the construction manual, including all these step-by-step instructions with pictures ? Have you ever seen this kind of material just for free ??? Or even payable ???

- "I would be glad to share the knowledge and experience with the hardware we made"
Fine, but from the electronics point of view the EmuSer based on Teensy++ 2.0 is exactly the same as the circuits using the Teensy 2.0, except for the pin numbering of the Teensy.
From the firmware point of view, a different build of the firmware must be used, because it's another processor board. 

- It's true that there's no well documented source code and HOWTO provided for changing the source code of the firmware... because it was simply not the intention that anyone would do that !! That's why ready-to-use HEX files are provided for 3 different processor boards, including one for the Teensy++ which is not the standard EmuSer processor. I'm very sorry it doesn't work in your version. In fact the only reason why the source code is released is because it's under an open source license. So yes, if you want to start changing and re-compiling this code, I can imagine it will not be easy. But maybe...(??) I will add a readme file explaining what should be done if someone really wants to start programming for AVR with AVR Studio... although I don't think many E-Mu users will be interested...

- The firmware used in the EMuSer is only a slightly changed version of the example USB/Serial code delivered with one of the older LUFA libraries. I am not a distributor of LUFA, so I only provide the files that have been changed (is required under the license). It's also true that the source code of the firmware is not the best designed software of the world. More recent LUFA distributions contain much "better designed" software than the version I have used. Unfortunately these newer distributions have been changed in a way that they don't work anymore with the EmuSer (firmware is too slow). well... at least that's what I observed when I have tested all newer versions in 2010. Maybe now there's even a better version. I'm not checking every month. I'm sure a better firmware can be developed for the EmuSer; I just didn't spend any time on that because the version we had was sufficient and successfully running with all E-Mu vintage samplers.
The LUFA version used in the EmuSer DOES support the AVR processor used in the Teensy++ 2.0. The only thing I did in addition was copy and change some files from a newer LUFA distribution into this older version in order to have some definitions for the LEDs on the Teensy boards and to allow the usage of the TEENSY board definition in the makefile. The adapted "new LUFA" files are provided on the website too. These were not available yet in that older LUFA version. It's a small trick, and it is not described in any readme file, so again, I can imagine that you encounter problems when you just want to do a plain vanilla recompile/rebuild.

- I have built 3 EmuSers based on Teensy 2.0 and 1 EmuSer based on Teensy++ 2.0 and all of them are working fine, using the HEX files as provided on the website. Some other people have built the Teensy 2.0 EmuSer themselves too, and I received reports from them that they work 100 pct fine too. These people are using the EmuSer mainly with Emulator II, but I have also received positive feedback of using the EmuSer with the Emax.
The last few days I have been doing intensive tests myself with the Emuser on the Emax and Emulator-II because a new version of EMXP will be released. And the EmuSer worked fine with both of my Emax-I and with my Emax-II during these tests.


I will check if the latest Teensy++ 2.0 boards sold by PJRC are still exactly the same ones as I have used here in 2010, and I will also double check if the HEX file provided for the Teensy++ on my website is really the correct version and that I didn't make a mistake with that one. 
I can only do this in the weekend though because I don't have access to my material now. I had other things planned in the weekend, but hey who cares...

///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> OK guys, i do NOT recommend anyone to build EMUSER.
> 
> We spent over 15 hours to get this thing work, and there are problems with the hex files as far as i can tell (i guess it has not been tested with the recent Teensy hardware) and even if you attempted to look into the source code (which is shared on the Emuser homepage), you'll find that it will not compile. Files missing, library files are incompatible and such things. It's very far from well prepared.
> 
> I would be glad to share the knowledge and experience with the hardware we made, but since the software is far from "ready to use", you do better to write the thing from scratch, unless you have luck, and can get in touch with the author. Unfortunately i could not.
> 
> So, what's the purpose of this post? Don't think it is easy to do, and none will be here to help you. Probably there are too few Emuser users. It's a pity...
>

I'm not 100 pct sure what the exact situation is with your XCK1 pin, but the EmuSer's firmware WILL put the clock in SYNC mode once EMXP instructs it to do that. This is done only if high speed communication is required, for normal SYSEX communication internal clocking is used at MIDI baudrate (which is also used by EMXP with the Emax through RS422). 
So for high speed communications (=actual transfer of bank and sample data) the EmuSer MUST receive the clock signal from the Emax instead of clocking itself. This is basically the "heart" of the EmuSer, and the reason why most other USB/RS422 devices don't work with E-Mu samplers. So the firmware contains a piece of code which changes the a flag on the XCK port when it receives a baudrate setting of 500000. 
 
///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> We've tried to build the EMUSER around the Teensy++ board, and we had no success so far.
> 
> It seems like that upon bank transfer, the clock disappears on the XCK1 pin .
> When unplugging-replugging the board the clock will come back.
> 
> We suspect the pin changes the direction (the input will become an output) 
> 
> Has anyone actually tried the firmware on THIS version of the Teensy ?
> 
> Any help is appreciated.
> 
> thanks!
>

I have an eMuser, and I love it.  It is a brilliant piece of reversed
engineering.  I have hit a few snags along the way but, esynthesist has been
very helpful with offering support any way he can.    He is just 1 guy, and
I assume he works a day job too.  Any question that I have ever sent him has
been replied to eventually, and this includes EMXP questions as well.  I
fully endorse the eMuser and suggest that anyone who owns an Emax 1/II or
Emulator II, and wants a nice, easy way to backup, load, convert, samples
via a computer try to build one of these.  In fact, if anyone takes the
initiative to build these on mass, I am certain several people would be very
happy to buy them from you.

One thing to keep in mind, Emu did not make every version of the
Emax/Emulators standard.  The revisions of these devices and the functions
on them are not identical from one unit to the next.  Some of these
differences between revisions may be causing issues.  Also, if the Teensy
board is a different revision, then this would be beyond the control of the
developer of the eMuser.  Perhaps there are some alterations that can be
made to make this revision work?

Regardless, this isn't a company developing a device.  The eMuser is
definitely DIY and Beta and I think that esythesist has made these caveats
clear from the beginning.  I don't think that your individual initial
testing should result in downplaying a device which has been documented to
perform and work perfectly well.  Good things take time.  Be patient and I
am sure you can figure out some of the problems that you are facing.

Regards,

-s*

On Wed, Apr 13, 2011 at 5:16 PM, esynthesist <esynthesist@...> wrote:

>
>
> Pfff...
>
>
> - "unless you have luck, and can get in touch with the author.
> Unfortunately i could not"
> True, you have sent two e-mails to me, but both have been sent only TODAY
> while I was at work, and when I finally log on in the evening to my mailbox
> and to this forum you are already posting this kind of messages ???
>
>
> - "It's very far from well prepared."
> This may be true for the source code part of the firmware (see next bullet)
> but on the other hand:
> Do you have any idea how many hours, days, weeks we (Julian and me) have
> worked on the EMuSer to get it working ? Do you have any idea how many hours
> I have spent on writing the construction manual, including all these
> step-by-step instructions with pictures ? Have you ever seen this kind of
> material just for free ??? Or even payable ???
>
> - "I would be glad to share the knowledge and experience with the hardware
> we made"
> Fine, but from the electronics point of view the EmuSer based on Teensy++
> 2.0 is exactly the same as the circuits using the Teensy 2.0, except for the
> pin numbering of the Teensy.
> From the firmware point of view, a different build of the firmware must be
> used, because it's another processor board.
>
> - It's true that there's no well documented source code and HOWTO provided
> for changing the source code of the firmware... because it was simply not
> the intention that anyone would do that !! That's why ready-to-use HEX files
> are provided for 3 different processor boards, including one for the
> Teensy++ which is not the standard EmuSer processor. I'm very sorry it
> doesn't work in your version. In fact the only reason why the source code is
> released is because it's under an open source license. So yes, if you want
> to start changing and re-compiling this code, I can imagine it will not be
> easy. But maybe...(??) I will add a readme file explaining what should be
> done if someone really wants to start programming for AVR with AVR Studio...
> although I don't think many E-Mu users will be interested...
>
> - The firmware used in the EMuSer is only a slightly changed version of the
> example USB/Serial code delivered with one of the older LUFA libraries. I am
> not a distributor of LUFA, so I only provide the files that have been
> changed (is required under the license). It's also true that the source code
> of the firmware is not the best designed software of the world. More recent
> LUFA distributions contain much "better designed" software than the version
> I have used. Unfortunately these newer distributions have been changed in a
> way that they don't work anymore with the EmuSer (firmware is too slow).
> well... at least that's what I observed when I have tested all newer
> versions in 2010. Maybe now there's even a better version. I'm not checking
> every month. I'm sure a better firmware can be developed for the EmuSer; I
> just didn't spend any time on that because the version we had was sufficient
> and successfully running with all E-Mu vintage samplers.
> The LUFA version used in the EmuSer DOES support the AVR processor used in
> the Teensy++ 2.0. The only thing I did in addition was copy and change some
> files from a newer LUFA distribution into this older version in order to
> have some definitions for the LEDs on the Teensy boards and to allow the
> usage of the TEENSY board definition in the makefile. The adapted "new LUFA"
> files are provided on the website too. These were not available yet in that
> older LUFA version. It's a small trick, and it is not described in any
> readme file, so again, I can imagine that you encounter problems when you
> just want to do a plain vanilla recompile/rebuild.
>
> - I have built 3 EmuSers based on Teensy 2.0 and 1 EmuSer based on Teensy++
> 2.0 and all of them are working fine, using the HEX files as provided on the
> website. Some other people have built the Teensy 2.0 EmuSer themselves too,
> and I received reports from them that they work 100 pct fine too. These
> people are using the EmuSer mainly with Emulator II, but I have also
> received positive feedback of using the EmuSer with the Emax.
> The last few days I have been doing intensive tests myself with the Emuser
> on the Emax and Emulator-II because a new version of EMXP will be released.
> And the EmuSer worked fine with both of my Emax-I and with my Emax-II during
> these tests.
>
> I will check if the latest Teensy++ 2.0 boards sold by PJRC are still
> exactly the same ones as I have used here in 2010, and I will also double
> check if the HEX file provided for the Teensy++ on my website is really the
> correct version and that I didn't make a mistake with that one.
> I can only do this in the weekend though because I don't have access to my
> material now. I had other things planned in the weekend, but hey who
> cares...
>
> ///E-Synthesist
>
>
> --- In emax@yahoogroups.com, "Adam" <fake@...> wrote:
> >
> > OK guys, i do NOT recommend anyone to build EMUSER.
> >
> > We spent over 15 hours to get this thing work, and there are problems
> with the hex files as far as i can tell (i guess it has not been tested with
> the recent Teensy hardware) and even if you attempted to look into the
> source code (which is shared on the Emuser homepage), you'll find that it
> will not compile. Files missing, library files are incompatible and such
> things. It's very far from well prepared.
> >
> > I would be glad to share the knowledge and experience with the hardware
> we made, but since the software is far from "ready to use", you do better to
> write the thing from scratch, unless you have luck, and can get in touch
> with the author. Unfortunately i could not.
> >
> > So, what's the purpose of this post? Don't think it is easy to do, and
> none will be here to help you. Probably there are too few Emuser users. It's
> a pity...
> >
>
>  
>



-- 
<http://www.obsoletecomponents.ca>


[Non-text portions of this message have been removed]

Hello, i did not mean to hurt te feelings of the authors in any way, who must have had extreme amount of work with this thing, and they deserve nothing, but respect. I agree with that. I also plan to support their efforst, it is no question. (Donation-wise ofcourse)

The point of what i said was, that anyone who goes into building this, should not think of it as something easy. It may become serious effort and many work hours might be required. I was already preparing a good amount of extra information to share, but i don't think i can finish this unless i get help.

Maybe i was naive, but i thought by ordering the parts, getting it together will be 2-3 hours. 

Maybe i was naive with thinking that the user group will help me with their experience, but it did not happen and it's true for other issues.  

At this point, i am not sure i can get this to work by myself. 
But let's hope, someone may find these information useful, i am going to share what i know.
 
> - "I would be glad to share the knowledge and experience with the hardware we made"
> Fine, but from the electronics point of view the EmuSer based on Teensy++ 2.0 is exactly the same as the circuits using the Teensy 2.0, except for the pin numbering of the Teensy.
> From the firmware point of view, a different build of the firmware must be used, because it's another processor board. 
 
> - It's true that there's no well documented source code and HOWTO provided for changing the source code of the firmware... because it was simply not the intention that anyone would do that !! 

sorry, i did not know that. if i knew this i did not even try it, because to get that compiler run on os-x with all the libraries and other stuff to work took me a day. And it still does not compile the code, i guess some more days of work has to go into it.

on the other hand, from what i could measure the thing works like it supposed to, and what i could experience that the problem relates to the clocking.  Seems like EMXP kicks off the Teensy++ from asynchronous mode and switches the clock pin to output instead of input. The board i made works perfect in other aspects. Connecting the tx-rx pins on teensy will pass the RS422 test on the EMAX I diag, and  Hyperterminal on PC will happily send back the characters too. However, it looks like it does not sync to the EMAX I's clock. 

all my question was -and thats why i wrote al this- if anyone actually tried it with Teensy++ but i had the usual silence. i am glad to hear, that you report, that the hex files provided work on this board 100%. Means i did something wrong with the circuit, although i still can't imagine why, because of the above. (Do you have an idea how could it pass the above tests and still not working with EMXP?)

"So yes, if you want to start changing and re-compiling this code, I can imagine it will not be easy. But maybe...(??) I will add a readme file explaining what should be done if someone really wants to start programming for AVR with AVR Studio... although I don't think many E-Mu users will be interested..."

I only wanted to recompile your code because i assumed, something went wrong with the included firmware. 
Actually the files are well documented, but many files missing from the sources you included on your page. Normally i wouldn't want to touch it, it required a hell of a work. I wanted to use it to figure out why it does not go to asyncrhonous mode.
I don't go to my work these days i wanted to figure this out so hard.

> I will check if the latest Teensy++ 2.0 boards sold by PJRC are still exactly the same ones as I have used here in 2010, and I will also double check if the HEX file provided for the Teensy++ on my website is really the correct version and that I didn't make a mistake with that one. 

That would be super-great! Please let me know what you found!

I'd also welcome if you had some hints now regarding this clock-issue or what could went wrong with it.

If you didn't mind sharing the folder you used for compiling the firmware, i could also help tracing. May not be necessary though.

> I can only do this in the weekend though because I don't have access to my material now. I had other things planned in the weekend, but hey who cares...

;) thumbs up! 

Adam

I am very well aware of this. Looking at XCK1 with a scope seems like it's in output state.

Btw, can i know a little what tipical issues you or your friends faced with their EMUSER's?

Maybe i made a huge mistake i can't see yet.

thanks,

A


--- In emax@yahoogroups.com, "esynthesist" <esynthesist@...> wrote:

>
> I'm not 100 pct sure what the exact situation is with your XCK1 pin, but the EmuSer's firmware WILL put the clock in SYNC mode once EMXP instructs it to do that. This is done only if high speed communication is required, for normal SYSEX communication internal clocking is used at MIDI baudrate (which is also used by EMXP with the Emax through RS422). 
> So for high speed communications (=actual transfer of bank and sample data) the EmuSer MUST receive the clock signal from the Emax instead of clocking itself. This is basically the "heart" of the EmuSer, and the reason why most other USB/RS422 devices don't work with E-Mu samplers. So the firmware contains a piece of code which changes the a flag on the XCK port when it receives a baudrate setting of 500000. 
>  
> ///E-Synthesist
> 
> --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> >
> > We've tried to build the EMUSER around the Teensy++ board, and we had no success so far.
> > 
> > It seems like that upon bank transfer, the clock disappears on the XCK1 pin .
> > When unplugging-replugging the board the clock will come back.
> > 
> > We suspect the pin changes the direction (the input will become an output) 
> > 
> > Has anyone actually tried the firmware on THIS version of the Teensy ?
> > 
> > Any help is appreciated.
> > 
> > thanks!
> >
>

I am happy to hear this! I agree that Emuser is better solution than anything out there.
 
 > One thing to keep in mind, Emu did not make every version of the
> Emax/Emulators standard. 

i do, but so far i am having clocking issues which relates to that the EMXP can't force the Teensy into the right sync mode. Therefore EMXP does not send out a single character.

 "Also, if the Teensy board is a different revision, then this would be beyond the control of the developer of the eMuser.  Perhaps there are some alterations that can be made to make this revision work?"

I agree with that. That's why i missed a working and full veresion of the source code. It may help keeping it intact with future versions. I just did not expect that it is incomplete, and i burned quite some hours just to find it out.

"Be patient and I am sure you can figure out some of the problems that you are facing."

You are right, i apologize for the wording.

On the other hand, i think these expereince should be shared so the developers would not have to put precious time into supporting.

"I will check if the latest Teensy++ 2.0 boards sold by PJRC are still exactly the same ones as I have used here in 2010"

Paul @ PJRC confirmed:

"All Teensy++ 2.0 boards should be identical.  They are all the '1286 chip, same circuit board and other parts.

I have some that were recently built with the '1287 chip (the same, but has extra features), but so far we haven't sold them, except to a couple people who specifically asked."

"and I will also double check if the HEX file provided for the Teensy++ on my website is really the correct version and that I didn't make a mistake with that one. "

it would be very kind from you.

thanks!

I have just downloaded the Teensy++2.0 HEX firmware from my website and uploaded it into a Teensy++ 2.0.

I also have built the circuits of the EmuSer with this Teensy++2.0 on a breadboard, and tested it with an Emax SE/Plus and EMXP.
See picture in the photos section:
http://groups.yahoo.com/group/emax/photos/album/1383123911/pic/1129124448/view?picmode=large&mode=tn&order=ordinal&start=1&dir=asc

As you may guess and derive from the picture... it works like a charm.

Are you sure your Emax doesn't have a problem with its RS422 port on high speed ? A good test (but maybe not obvious for everyone) would be to test your EmuSer board on another Emax and/or test the Emax with Sound Designer for Emax on an old Mac ?

I assume you are using a correct Emax OS version (only SE, SE/HD and Plus support RS422 transfers)?

On the electronics side, you could try some alternatives, e.g. by removing the LEDs and/or by removing the small capacitors C4 and C5. These components can influence signals; the capacitors were specifically added for the Emulator II rev 1, and also work fine with my Emax and Emax-II samplers, but maybe some Emax revisions may be more sensitive to them... (the original prototype which was created for Emax did not have LEDs nor these capacitors...)

///E-Synthesist


--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> "I will check if the latest Teensy++ 2.0 boards sold by PJRC are still exactly the same ones as I have used here in 2010"
> 
> Paul @ PJRC confirmed:
> 
> "All Teensy++ 2.0 boards should be identical.  They are all the '1286 chip, same circuit board and other parts.
> 
> I have some that were recently built with the '1287 chip (the same, but has extra features), but so far we haven't sold them, except to a couple people who specifically asked."
> 
> "and I will also double check if the HEX file provided for the Teensy++ on my website is really the correct version and that I didn't make a mistake with that one. "
> 
> it would be very kind from you.
> 
> thanks!
>

Hi, thank you for the test on your side. Here it still looks rather weird.
The problem is definietly related to the clock.

Let's make things as simple as possible. 

Let's detach everything from the Teensy, just get EMU's clock to the XCK (PD5) pin (besides VCC and GND) - but nothing else.

In this situation we've used an SN75176 line driver configured  as receiver like this:

CLK (from Emax:5)  ->  SN75176B:pin6 (A) 
SN75176B:pin7 (B) = L
SN75176B:pin1 (R) -> Teensy PD5  (XCK)
SN75176B:pin4 (D) -> not connected
SN75176B:pin3 (DE) -> L  
SN75176B:pin2 (NRE) -> L  

in this configuration i can measure fine clock coming from the EMAX (or EII: tried with this too, results were the same), and it can be seen arriving on the XCK.

as soon as i start EMXP and initiate transfer or receive, XCK will be pulled to ground! the oscilloscope shows almost no signal on the pin, which suggests that it went to output state.
 
What you think of this? I'd appreciate any suggestions.

Beyond this we wrote a single code that tests the Teensy's PD5 output by making it H, and it works.  

Then we wanted to check then if it could read its PD5 pin. We did a little program which reads PD5, and if it was high, it sets PD6 high, and it makes the orange LED lit up, as it wired there by default.  

For me it means that the PD5 on the Teensy works all right.

Btw Teensy++ will not work with the Teensy firmware (Windows will not detect the COM port, which proves this)

At this point we are completely clueless!!!! If there was anyone who could say anything about it, that would be none else, but you i guess.

Adam

> I have just downloaded the Teensy++2.0 HEX firmware from my website and uploaded it into a Teensy++ 2.0.

we are talking about this, right?  http://users.skynet.be/emxp/Firmware_EMuSer_TeensyPlus2_0_v1_00_1.zip

(and the "USBtoSerialEmu_TeensyPlus2_0.hex" file from it)

just want to make sure everything is ok.

Yes indeed.

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> > I have just downloaded the Teensy++2.0 HEX firmware from my website and uploaded it into a Teensy++ 2.0.
> 
> we are talking about this, right?  http://users.skynet.be/emxp/Firmware_EMuSer_TeensyPlus2_0_v1_00_1.zip
> 
> (and the "USBtoSerialEmu_TeensyPlus2_0.hex" file from it)
> 
> just want to make sure everything is ok.
>

>>> as soon as i start EMXP and initiate transfer or receive, XCK will be pulled to ground

That's normal, especially if you didn't connect the send/receive data pins with the Emax.

The reason is that EMXP doesn't instruct the EMuSer immediately to go in SYNC mode. It first does some communication in asynchronous mode:
In a first stage, it instructs the Emax to change its Timeout parameter, followed by an instruction to start the bank transfer.
Both commands are done in ASYNC mode at 31250 baud. As you can see in the main program of the firmware (EMUToSerialEmu.c), if the baudrate is not 500000 (as 31250 is...), the clock pin is set to OUTPUT (bit 5 of DDRD register) and the communication mode is set to ASYNC (UMSEL bits of the USCS1C register).
Only after both instructions have been executed succesfully at Emax side, EMXP will instruct the EMuSer to go into SYNC mode, which is done by changing the baudrate to 500000. As you can see in the main program of the firmware, only then the XCK direction changes into INPUT and the device is set in SYNC mode.
After the high speed data transfer, EMXP will init the EMuSer to baudrate 0 to disactivate it temporarily.

As long as EMXP's RS422 functions have not been used after initial connection of the EMuSer to the USB port of the PC, the EMuSer uses the default settings of LUFA. As far as I remember this means that the XCK direction is OUTPUT (high).

If your Teensy++ is continuously showing an OUTPUT direction of the XCK pin after having started the bank transfer option in EMXP, it means that for some reason EMXP is not getting a response from the Emax in MIDI/async 31250 baud mode. After a while you should get an error in EMXP (=when timeout/read retrials limit is reached). This could take a while (even minutes) depending on the Preferences parameters that are defined for the RS422 communication with the Emax. 

So, what error do you actually get in EMXP ?   


>>> Btw Teensy++ will not work with the Teensy firmware (Windows will not detect the COM port, which proves this)
Do you mean Teensy++2.0 firmware or Teensy2.0 firmware ?
(I hope Teensy2.0, that would be normal :-)


BTW1: Have you tried SYSEX communication with your Emax via the MIDI bus ? Perhaps you should try this at least. If it doesn't work, there's definitely something wrong with the Emax. If it works, there could still be a problem with the RS422 section of the serial circuit hardware of the Emax. If the Emax RS422 driver or receiver IC is dead (which is perfectly possible !) then it's normal that EMXP will fail in its attempts to communicate with the Emax.

BTW2: Can you confirm that you are using an SE/SE-HD/Plus OS on your Emax ?

(PS: if these detailed technical discussions are too boring for most group members, we should switch to e-mail communication...)

///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> Hi, thank you for the test on your side. Here it still looks rather weird.
> The problem is definietly related to the clock.
> 
> Let's make things as simple as possible. 
> 
> Let's detach everything from the Teensy, just get EMU's clock to the XCK (PD5) pin (besides VCC and GND) - but nothing else.
> 
> In this situation we've used an SN75176 line driver configured  as receiver like this:
> 
> CLK (from Emax:5)  ->  SN75176B:pin6 (A) 
> SN75176B:pin7 (B) = L
> SN75176B:pin1 (R) -> Teensy PD5  (XCK)
> SN75176B:pin4 (D) -> not connected
> SN75176B:pin3 (DE) -> L  
> SN75176B:pin2 (NRE) -> L  
> 
> in this configuration i can measure fine clock coming from the EMAX (or EII: tried with this too, results were the same), and it can be seen arriving on the XCK.
> 
> as soon as i start EMXP and initiate transfer or receive, XCK will be pulled to ground! the oscilloscope shows almost no signal on the pin, which suggests that it went to output state.
>  
> What you think of this? I'd appreciate any suggestions.
> 
> Beyond this we wrote a single code that tests the Teensy's PD5 output by making it H, and it works.  
> 
> Then we wanted to check then if it could read its PD5 pin. We did a little program which reads PD5, and if it was high, it sets PD6 high, and it makes the orange LED lit up, as it wired there by default.  
> 
> For me it means that the PD5 on the Teensy works all right.
> 
> Btw Teensy++ will not work with the Teensy firmware (Windows will not detect the COM port, which proves this)
> 
> At this point we are completely clueless!!!! If there was anyone who could say anything about it, that would be none else, but you i guess.
> 
> Adam
>

well, it starts to make sense! it really looked disappointing, now there are new things to check. 

meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?

i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.

since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.

i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.

"So, what error do you actually get in EMXP ?   "

When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.

i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.

and now the connections:



RECEIVER (RX): MAX RS485
---------------------
TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
RS485:pin1 (R0) -> Teensy PD2 (RXD1)
RS485:pin2 (NRE) -> L 
RS485:pin3 (D) -> L  
RS485:pin4 (DI) ->  not connected 

TRANSCIVER (TX): MAX RS485
------------------------
Teensy TXD (PD3) -> RS485:pin4 (DI)
RS485:pin6 (A) -> Emax:pin5 (RXD-)
RS485:pin7 (B) -> Emax:pin4 (RXD+)
RS485:1 (R0) -> not connected
RS485:2 (NRE) ->H
RS485:3 (DE) ->H

CLOCK (CLK): SN75176B
------------------------
CLK (Emax:5) -> SN75176B Pin6 (A) 
SN75176B:pin7: B -> L
SN75176B:pin1: R -> Teensy PD5  (XCK)
SN75176B:pin4 (D) -> not connected
SN75176B:pin3 (DE) -> L 
SN75176B:pin2 (NRE) -> L

>>> meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?

Yes

>>> since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. if there were any other reasons, please let me know, i need to check that.

The resistors and capacitors are added for voltage dividing (changing levels) and for shaping the signals.

From what I read now, you actually didn't use any of the components and any of the schematics of the published EMuSer specifications.
The Teensy++2.0 is the only component you used which is kind of "supported" by the EMuSer specs.

I'm not saying that alternative circuits with different driver/receiver ICs and different (or no) resistors and capacitors will not work, but you probably understand that *your device* is not  an "EMuSer" for me. 
So I can not give any support for it and of course I can also not say or guarantee whether it will ever work with any E-Mu sampler. 
I hope you understand that I will not go into the detailed specs of the MAX485 and SN75176B (or buy them) to check if they make sense on the level of expected signal shape and signal level.


But you are right that that the components from the EMuSer specs are a little bit harder to find than the ones you used. 
However, they are usually still available on online electronics websites. I was even able to order them in a 'brick and mortar' electronics shop in my city a few months ago (I had to wait 1 week).
And the Teensy2.0 is also available again on PJRC.COM and it even dropped in price :-) !


One last note:
If anyone wants to build the EMuSer, I strongly recommend to follow all instructions and specifications from the contruction manual. Or at least the ones regarding the electronics. If not, you are actually designing another device which is a great initiative but which should be considered another project.

Good luck.

///E-Synthesist









--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> 
> meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> 
> i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> 
> since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> 
> i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> 
> "So, what error do you actually get in EMXP ?   "
> 
> When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> 
> i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> 
> and now the connections:
> 
> 
> 
> RECEIVER (RX): MAX RS485
> ---------------------
> TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> RS485:pin2 (NRE) -> L 
> RS485:pin3 (D) -> L  
> RS485:pin4 (DI) ->  not connected 
> 
> TRANSCIVER (TX): MAX RS485
> ------------------------
> Teensy TXD (PD3) -> RS485:pin4 (DI)
> RS485:pin6 (A) -> Emax:pin5 (RXD-)
> RS485:pin7 (B) -> Emax:pin4 (RXD+)
> RS485:1 (R0) -> not connected
> RS485:2 (NRE) ->H
> RS485:3 (DE) ->H
> 
> CLOCK (CLK): SN75176B
> ------------------------
> CLK (Emax:5) -> SN75176B Pin6 (A) 
> SN75176B:pin7: B -> L
> SN75176B:pin1: R -> Teensy PD5  (XCK)
> SN75176B:pin4 (D) -> not connected
> SN75176B:pin3 (DE) -> L 
> SN75176B:pin2 (NRE) -> L
>

Got the Emax I error code but i had not time to test the sysex stuff on the emax. btw. how can i test that? (EMXP via MIDI perhaps?)

the error code from Emax was different:

errorcode 1048

emax doesnt give the expected sysex response response is 0 0 0 0 exprected response is f0 18 2 38

going home, i am falling apart now :(

For testing the Emax MIDI port, I would recommend a (free) software like MidiOx and of course a (USB-)MIDI adapter. With this kind of software you can send/receive individual SYSEX messages, which is great for testing purposes because you can use it as a kind of terminal utility. The SYSEX specs can be found on Emulatorarchive.
But using EMXP via MIDI is an alternative (not as a terminal though...)

The errorcode that you receive from the Emax is - as expected - the "wrong" reply on the "change timeout" instruction; this means that the communication already fails during the asynchronous 31250 baud mode, so the Teensy++ never even gets into SYNC mode.

BTW: if you use EMXP with the Emulator-II via RS422, the Teensy++ should go in SYNC mode at all times. So in the period between launching the "bank upload/unload" from EMXP and the moment you get the 990 errorcode, the XCK of the Teensy should be INPUT and the device should be in SYNC mode. That's because the ASYNC 31250 baud mode is only used at the very beginning in a fraction of a second to put the EII in "Mac Control" mode after which EMXP immediately instructs the RS422 port to go into SYNC mode - EVEN if the instruction to put the EII in ASYNC mode failed (!). This failure is also covered by the 990 errorcode. 

///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> Got the Emax I error code but i had not time to test the sysex stuff on the emax. btw. how can i test that? (EMXP via MIDI perhaps?)
> 
> the error code from Emax was different:
> 
> errorcode 1048
> 
> emax doesnt give the expected sysex response response is 0 0 0 0 exprected response is f0 18 2 38
> 
> going home, i am falling apart now :(
>

I just did a quick comparison of the ICs you used with the ones as specified for the EmuSer. At first sight they should be compatible, although yours are a bit slower...

However when checking your connections mentioned in your message below, I think you have swapped the inverting and non-inverting pins.
I think the RXD+/RXD- and TXD+/TXD- must be swapped on the MAX and SN ICs...

///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> 
> meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> 
> i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> 
> since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> 
> i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> 
> "So, what error do you actually get in EMXP ?   "
> 
> When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> 
> i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> 
> and now the connections:
> 
> 
> 
> RECEIVER (RX): MAX RS485
> ---------------------
> TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> RS485:pin2 (NRE) -> L 
> RS485:pin3 (D) -> L  
> RS485:pin4 (DI) ->  not connected 
> 
> TRANSCIVER (TX): MAX RS485
> ------------------------
> Teensy TXD (PD3) -> RS485:pin4 (DI)
> RS485:pin6 (A) -> Emax:pin5 (RXD-)
> RS485:pin7 (B) -> Emax:pin4 (RXD+)
> RS485:1 (R0) -> not connected
> RS485:2 (NRE) ->H
> RS485:3 (DE) ->H
> 
> CLOCK (CLK): SN75176B
> ------------------------
> CLK (Emax:5) -> SN75176B Pin6 (A) 
> SN75176B:pin7: B -> L
> SN75176B:pin1: R -> Teensy PD5  (XCK)
> SN75176B:pin4 (D) -> not connected
> SN75176B:pin3 (DE) -> L 
> SN75176B:pin2 (NRE) -> L
>

First of all, thank you for caring!

i had the idea, that on the MAX'es the +/- things should be swapped.
but why on the SN?

In the meantime i've ordered the original ICs you used from the US, because i could see these nowhere around. I'll definietly going to compare these part by part, and will let you know if we found out something!

thanks,

adam

--- In emax@yahoogroups.com, "esynthesist" <esynthesist@...> wrote:

>
> I just did a quick comparison of the ICs you used with the ones as specified for the EmuSer. At first sight they should be compatible, although yours are a bit slower...
> 
> However when checking your connections mentioned in your message below, I think you have swapped the inverting and non-inverting pins.
> I think the RXD+/RXD- and TXD+/TXD- must be swapped on the MAX and SN ICs...
> 
> ///E-Synthesist
> 
> --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> >
> > well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> > 
> > meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> > 
> > i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> > 
> > since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> > 
> > i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> > 
> > "So, what error do you actually get in EMXP ?   "
> > 
> > When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> > 
> > i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> > 
> > and now the connections:
> > 
> > 
> > 
> > RECEIVER (RX): MAX RS485
> > ---------------------
> > TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> > TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> > GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> > RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> > RS485:pin2 (NRE) -> L 
> > RS485:pin3 (D) -> L  
> > RS485:pin4 (DI) ->  not connected 
> > 
> > TRANSCIVER (TX): MAX RS485
> > ------------------------
> > Teensy TXD (PD3) -> RS485:pin4 (DI)
> > RS485:pin6 (A) -> Emax:pin5 (RXD-)
> > RS485:pin7 (B) -> Emax:pin4 (RXD+)
> > RS485:1 (R0) -> not connected
> > RS485:2 (NRE) ->H
> > RS485:3 (DE) ->H
> > 
> > CLOCK (CLK): SN75176B
> > ------------------------
> > CLK (Emax:5) -> SN75176B Pin6 (A) 
> > SN75176B:pin7: B -> L
> > SN75176B:pin1: R -> Teensy PD5  (XCK)
> > SN75176B:pin4 (D) -> not connected
> > SN75176B:pin3 (DE) -> L 
> > SN75176B:pin2 (NRE) -> L
> >
>

Indeed, the SN pin connections you mentioned are correct - this means that only on the two MAX485 the + and - signals should be swapped.
Once modified I would expect that there's a big chance the circuit should work, even without any resistors and capacitors.

Except for the LED resistors and the signal shaping capacitors C4 and C5 on the EmuSer schema, the other resistors and capacitors are mainly added for signal leveling/protection purposes (avoiding too high voltages on input pins and avoiding peaks). But in normal circumstances - given the voltage range specifications of all involved ICs (the absolute maximums and the tresholds for L and H) - direct connections between the ICs should work too... I would have to double check but I think this is true both for the ICs and Teensy you have used, and the ones that are used in the EMuSer schema.
I remember though that I had problems with alternative designs with more or less resistors on the board, so I decided to stick as much as possible to the original design by Julian H (co-member of this forum). 

It will be interesting to learn about any possible differences between the two schemas !

///E-Synthesist




--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> First of all, thank you for caring!
> 
> i had the idea, that on the MAX'es the +/- things should be swapped.
> but why on the SN?
> 
> In the meantime i've ordered the original ICs you used from the US, because i could see these nowhere around. I'll definietly going to compare these part by part, and will let you know if we found out something!
> 
> thanks,
> 
> adam
> 
> --- In emax@yahoogroups.com, "esynthesist" <esynthesist@> wrote:
> >
> > I just did a quick comparison of the ICs you used with the ones as specified for the EmuSer. At first sight they should be compatible, although yours are a bit slower...
> > 
> > However when checking your connections mentioned in your message below, I think you have swapped the inverting and non-inverting pins.
> > I think the RXD+/RXD- and TXD+/TXD- must be swapped on the MAX and SN ICs...
> > 
> > ///E-Synthesist
> > 
> > --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> > >
> > > well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> > > 
> > > meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> > > 
> > > i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> > > 
> > > since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> > > 
> > > i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> > > 
> > > "So, what error do you actually get in EMXP ?   "
> > > 
> > > When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> > > 
> > > i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> > > 
> > > and now the connections:
> > > 
> > > 
> > > 
> > > RECEIVER (RX): MAX RS485
> > > ---------------------
> > > TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> > > TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> > > GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> > > RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> > > RS485:pin2 (NRE) -> L 
> > > RS485:pin3 (D) -> L  
> > > RS485:pin4 (DI) ->  not connected 
> > > 
> > > TRANSCIVER (TX): MAX RS485
> > > ------------------------
> > > Teensy TXD (PD3) -> RS485:pin4 (DI)
> > > RS485:pin6 (A) -> Emax:pin5 (RXD-)
> > > RS485:pin7 (B) -> Emax:pin4 (RXD+)
> > > RS485:1 (R0) -> not connected
> > > RS485:2 (NRE) ->H
> > > RS485:3 (DE) ->H
> > > 
> > > CLOCK (CLK): SN75176B
> > > ------------------------
> > > CLK (Emax:5) -> SN75176B Pin6 (A) 
> > > SN75176B:pin7: B -> L
> > > SN75176B:pin1: R -> Teensy PD5  (XCK)
> > > SN75176B:pin4 (D) -> not connected
> > > SN75176B:pin3 (DE) -> L 
> > > SN75176B:pin2 (NRE) -> L
> > >
> >
>

it's still not working BUT! i measured response from the sampler.
it made the scope flicker a little. i might have made some other mistake, but i agree with you, in theory, it should work without these capacitors and resistors.

i expect to receive the original ICs by this friday or next monday, and i am not going to wait a second to build your version ;)

i've already received a Teensy 2.0 too!

adam



--- In emax@yahoogroups.com, "esynthesist" <esynthesist@...> wrote:

>
> Indeed, the SN pin connections you mentioned are correct - this means that only on the two MAX485 the + and - signals should be swapped.
> Once modified I would expect that there's a big chance the circuit should work, even without any resistors and capacitors.
> 
> Except for the LED resistors and the signal shaping capacitors C4 and C5 on the EmuSer schema, the other resistors and capacitors are mainly added for signal leveling/protection purposes (avoiding too high voltages on input pins and avoiding peaks). But in normal circumstances - given the voltage range specifications of all involved ICs (the absolute maximums and the tresholds for L and H) - direct connections between the ICs should work too... I would have to double check but I think this is true both for the ICs and Teensy you have used, and the ones that are used in the EMuSer schema.
> I remember though that I had problems with alternative designs with more or less resistors on the board, so I decided to stick as much as possible to the original design by Julian H (co-member of this forum). 
> 
> It will be interesting to learn about any possible differences between the two schemas !
> 
> ///E-Synthesist
> 
> 
> 
> 
> --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> >
> > First of all, thank you for caring!
> > 
> > i had the idea, that on the MAX'es the +/- things should be swapped.
> > but why on the SN?
> > 
> > In the meantime i've ordered the original ICs you used from the US, because i could see these nowhere around. I'll definietly going to compare these part by part, and will let you know if we found out something!
> > 
> > thanks,
> > 
> > adam
> > 
> > --- In emax@yahoogroups.com, "esynthesist" <esynthesist@> wrote:
> > >
> > > I just did a quick comparison of the ICs you used with the ones as specified for the EmuSer. At first sight they should be compatible, although yours are a bit slower...
> > > 
> > > However when checking your connections mentioned in your message below, I think you have swapped the inverting and non-inverting pins.
> > > I think the RXD+/RXD- and TXD+/TXD- must be swapped on the MAX and SN ICs...
> > > 
> > > ///E-Synthesist
> > > 
> > > --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> > > >
> > > > well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> > > > 
> > > > meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> > > > 
> > > > i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> > > > 
> > > > since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> > > > 
> > > > i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> > > > 
> > > > "So, what error do you actually get in EMXP ?   "
> > > > 
> > > > When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> > > > 
> > > > i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> > > > 
> > > > and now the connections:
> > > > 
> > > > 
> > > > 
> > > > RECEIVER (RX): MAX RS485
> > > > ---------------------
> > > > TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> > > > TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> > > > GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> > > > RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> > > > RS485:pin2 (NRE) -> L 
> > > > RS485:pin3 (D) -> L  
> > > > RS485:pin4 (DI) ->  not connected 
> > > > 
> > > > TRANSCIVER (TX): MAX RS485
> > > > ------------------------
> > > > Teensy TXD (PD3) -> RS485:pin4 (DI)
> > > > RS485:pin6 (A) -> Emax:pin5 (RXD-)
> > > > RS485:pin7 (B) -> Emax:pin4 (RXD+)
> > > > RS485:1 (R0) -> not connected
> > > > RS485:2 (NRE) ->H
> > > > RS485:3 (DE) ->H
> > > > 
> > > > CLOCK (CLK): SN75176B
> > > > ------------------------
> > > > CLK (Emax:5) -> SN75176B Pin6 (A) 
> > > > SN75176B:pin7: B -> L
> > > > SN75176B:pin1: R -> Teensy PD5  (XCK)
> > > > SN75176B:pin4 (D) -> not connected
> > > > SN75176B:pin3 (DE) -> L 
> > > > SN75176B:pin2 (NRE) -> L
> > > >
> > >
> >
>

IT'S WOOOOOORKING!!!!!!

i asked my friend to do the modding for me, but it seems like he made some mistake. i fixed the wires and it completed the transfer, but under Win XP only (i tried it under Parallels Desktop from OS-X). 

At first it gave an error when receiving the first bank, but after retrying everything went fine.

I'll do further investigation....

Thank You very much, ESynthesist!

Adam

> --- In emax@yahoogroups.com, "esynthesist" <esynthesist@> wrote:
> >
> > Indeed, the SN pin connections you mentioned are correct - this means that only on the two MAX485 the + and - signals should be swapped.
> > Once modified I would expect that there's a big chance the circuit should work, even without any resistors and capacitors.
> > 
> > Except for the LED resistors and the signal shaping capacitors C4 and C5 on the EmuSer schema, the other resistors and capacitors are mainly added for signal leveling/protection purposes (avoiding too high voltages on input pins and avoiding peaks). But in normal circumstances - given the voltage range specifications of all involved ICs (the absolute maximums and the tresholds for L and H) - direct connections between the ICs should work too... I would have to double check but I think this is true both for the ICs and Teensy you have used, and the ones that are used in the EMuSer schema.
> > I remember though that I had problems with alternative designs with more or less resistors on the board, so I decided to stick as much as possible to the original design by Julian H (co-member of this forum). 
> > 
> > It will be interesting to learn about any possible differences between the two schemas !
> > 
> > ///E-Synthesist
> > 
> > 
> > 
> > 
> > --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> > >
> > > First of all, thank you for caring!
> > > 
> > > i had the idea, that on the MAX'es the +/- things should be swapped.
> > > but why on the SN?
> > > 
> > > In the meantime i've ordered the original ICs you used from the US, because i could see these nowhere around. I'll definietly going to compare these part by part, and will let you know if we found out something!
> > > 
> > > thanks,
> > > 
> > > adam
> > > 
> > > --- In emax@yahoogroups.com, "esynthesist" <esynthesist@> wrote:
> > > >
> > > > I just did a quick comparison of the ICs you used with the ones as specified for the EmuSer. At first sight they should be compatible, although yours are a bit slower...
> > > > 
> > > > However when checking your connections mentioned in your message below, I think you have swapped the inverting and non-inverting pins.
> > > > I think the RXD+/RXD- and TXD+/TXD- must be swapped on the MAX and SN ICs...
> > > > 
> > > > ///E-Synthesist
> > > > 
> > > > --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> > > > >
> > > > > well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> > > > > 
> > > > > meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> > > > > 
> > > > > i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> > > > > 
> > > > > since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> > > > > 
> > > > > i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> > > > > 
> > > > > "So, what error do you actually get in EMXP ?   "
> > > > > 
> > > > > When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> > > > > 
> > > > > i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> > > > > 
> > > > > and now the connections:
> > > > > 
> > > > > 
> > > > > 
> > > > > RECEIVER (RX): MAX RS485
> > > > > ---------------------
> > > > > TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> > > > > TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> > > > > GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> > > > > RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> > > > > RS485:pin2 (NRE) -> L 
> > > > > RS485:pin3 (D) -> L  
> > > > > RS485:pin4 (DI) ->  not connected 
> > > > > 
> > > > > TRANSCIVER (TX): MAX RS485
> > > > > ------------------------
> > > > > Teensy TXD (PD3) -> RS485:pin4 (DI)
> > > > > RS485:pin6 (A) -> Emax:pin5 (RXD-)
> > > > > RS485:pin7 (B) -> Emax:pin4 (RXD+)
> > > > > RS485:1 (R0) -> not connected
> > > > > RS485:2 (NRE) ->H
> > > > > RS485:3 (DE) ->H
> > > > > 
> > > > > CLOCK (CLK): SN75176B
> > > > > ------------------------
> > > > > CLK (Emax:5) -> SN75176B Pin6 (A) 
> > > > > SN75176B:pin7: B -> L
> > > > > SN75176B:pin1: R -> Teensy PD5  (XCK)
> > > > > SN75176B:pin4 (D) -> not connected
> > > > > SN75176B:pin3 (DE) -> L 
> > > > > SN75176B:pin2 (NRE) -> L
> > > > >
> > > >
> > >
> >
>

Great news !

(but now you're stuck with the orders for the other ICs that you have placed :-)

If you would continue using the device based on MAX485 and the SN IC and after a few weeks of usage it would seem to be stable, just let me know. Then I can add a note to the instruction manual of the EMuSer that these ICs can be considered as alternatives for the UA ones ...

///E-Synthesist

--- In emax@yahoogroups.com, "Adam" <fake@...> wrote:

>
> IT'S WOOOOOORKING!!!!!!
> 
> i asked my friend to do the modding for me, but it seems like he made some mistake. i fixed the wires and it completed the transfer, but under Win XP only (i tried it under Parallels Desktop from OS-X). 
> 
> At first it gave an error when receiving the first bank, but after retrying everything went fine.
> 
> I'll do further investigation....
> 
> Thank You very much, ESynthesist!
> 
> Adam
> 
> > --- In emax@yahoogroups.com, "esynthesist" <esynthesist@> wrote:
> > >
> > > Indeed, the SN pin connections you mentioned are correct - this means that only on the two MAX485 the + and - signals should be swapped.
> > > Once modified I would expect that there's a big chance the circuit should work, even without any resistors and capacitors.
> > > 
> > > Except for the LED resistors and the signal shaping capacitors C4 and C5 on the EmuSer schema, the other resistors and capacitors are mainly added for signal leveling/protection purposes (avoiding too high voltages on input pins and avoiding peaks). But in normal circumstances - given the voltage range specifications of all involved ICs (the absolute maximums and the tresholds for L and H) - direct connections between the ICs should work too... I would have to double check but I think this is true both for the ICs and Teensy you have used, and the ones that are used in the EMuSer schema.
> > > I remember though that I had problems with alternative designs with more or less resistors on the board, so I decided to stick as much as possible to the original design by Julian H (co-member of this forum). 
> > > 
> > > It will be interesting to learn about any possible differences between the two schemas !
> > > 
> > > ///E-Synthesist
> > > 
> > > 
> > > 
> > > 
> > > --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> > > >
> > > > First of all, thank you for caring!
> > > > 
> > > > i had the idea, that on the MAX'es the +/- things should be swapped.
> > > > but why on the SN?
> > > > 
> > > > In the meantime i've ordered the original ICs you used from the US, because i could see these nowhere around. I'll definietly going to compare these part by part, and will let you know if we found out something!
> > > > 
> > > > thanks,
> > > > 
> > > > adam
> > > > 
> > > > --- In emax@yahoogroups.com, "esynthesist" <esynthesist@> wrote:
> > > > >
> > > > > I just did a quick comparison of the ICs you used with the ones as specified for the EmuSer. At first sight they should be compatible, although yours are a bit slower...
> > > > > 
> > > > > However when checking your connections mentioned in your message below, I think you have swapped the inverting and non-inverting pins.
> > > > > I think the RXD+/RXD- and TXD+/TXD- must be swapped on the MAX and SN ICs...
> > > > > 
> > > > > ///E-Synthesist
> > > > > 
> > > > > --- In emax@yahoogroups.com, "Adam" <fake@> wrote:
> > > > > >
> > > > > > well, it starts to make sense! it really looked disappointing, now there are new things to check. 
> > > > > > 
> > > > > > meanwhile i switched to an Emulator II+HD to do the tests, because i know that works well with SD thru DB25. is it fair to assume that it has a healthy port and will work with the EMXP too?
> > > > > > 
> > > > > > i put this back to the bench and will check if there were any signals coming in and out on the TX-RX stuff. i havent included the LEDs on this design.
> > > > > > 
> > > > > > since the UA9637AC is not available around, i replaced it. i did not use any capacitors and resistors though. i assume you used it to shape the signal (apart from those to support the LEDs). if there were any other reasons, please let me know, i need to check that.
> > > > > > 
> > > > > > i am going to list the short description of my version in a very easy way. everything is connected direct, no resistors or capacitors used. please see below if you were interested in.
> > > > > > 
> > > > > > "So, what error do you actually get in EMXP ?   "
> > > > > > 
> > > > > > When receiving from the EII it says: Errorcode 990. There is a communication problem with the EII. ReasonCode is 3.
> > > > > > 
> > > > > > i am going to post it quick, so maybe you had more time to check and think, and now i'll return to measure the circuitry.
> > > > > > 
> > > > > > and now the connections:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > RECEIVER (RX): MAX RS485
> > > > > > ---------------------
> > > > > > TXD+ (Emax: pin8) -> Teensy RXD+ (RS422:3) -> RS485:7 (B)
> > > > > > TXD- (Emax:pin9) -> Teensy RXD- (RS422:4) -> RS485:6 (A)
> > > > > > GND (Emax:pin3) -> Teensy (RS422:5) -> RS485:5 (GND) 
> > > > > > RS485:pin1 (R0) -> Teensy PD2 (RXD1)
> > > > > > RS485:pin2 (NRE) -> L 
> > > > > > RS485:pin3 (D) -> L  
> > > > > > RS485:pin4 (DI) ->  not connected 
> > > > > > 
> > > > > > TRANSCIVER (TX): MAX RS485
> > > > > > ------------------------
> > > > > > Teensy TXD (PD3) -> RS485:pin4 (DI)
> > > > > > RS485:pin6 (A) -> Emax:pin5 (RXD-)
> > > > > > RS485:pin7 (B) -> Emax:pin4 (RXD+)
> > > > > > RS485:1 (R0) -> not connected
> > > > > > RS485:2 (NRE) ->H
> > > > > > RS485:3 (DE) ->H
> > > > > > 
> > > > > > CLOCK (CLK): SN75176B
> > > > > > ------------------------
> > > > > > CLK (Emax:5) -> SN75176B Pin6 (A) 
> > > > > > SN75176B:pin7: B -> L
> > > > > > SN75176B:pin1: R -> Teensy PD5  (XCK)
> > > > > > SN75176B:pin4 (D) -> not connected
> > > > > > SN75176B:pin3 (DE) -> L 
> > > > > > SN75176B:pin2 (NRE) -> L
> > > > > >
> > > > >
> > > >
> > >
> >
>