Brultech: Multiplex Cable

A little Ruby thing I wrote to send out strings and accept/parse data into a csv format.

The ECMs will not send unless polled, and there is a mechanism to address a specific ECM on the shared cable and request it's stored records.
I didn't recall that ... so I figured dumping one ecm would dump them all. Maybe I'm ok with one etherport after all.


the new firmware allows setting up ECM units for different command "start" bytes. For instance the standard is 0xFC before sending a command. With the new firmware, you can set the 2nd device to respond to 0xFD or 0xFE or 0xFF. This would allow you to send commands specific for each of the devices.

tenholde
 
Today I finally got around to installing my ECM-1240 and all of the latest software from Brultech. I have one ECM communicating via wireless. My goal is to have a total of three ECM's communicating via a single EtherBee device (they are all within a couple of feet of each other) and two ECM's in my shop communicating over a EtherPort connections. Is it possible to have this configuration look like a single "logical ECM" when viewed with Brultech's dashboard software? My concern is that when I look at Brultech's ECM Engine software (I think they call it the "IA"), it has stuff for devices A, B, and C. Furthermore, it only has TCP/IP A and TCP/IP B. How would this work using three wireless ECM's (all talking to the same EtherBee device) and two wired (EtherPort) ECM's?

Still no response to my emails to Brultech for expansion package pricing. Guess I will try calling them again.

Thanks,
Ira
 
One thing I am sure most of you are aware you can do serial over cat5 for a decent distance. my units are at least 75 feet of cable away and they work fine. I realize you cant always fish a wire but if someone was thinking you would need a giant serial cable this is not the case.

It is possible you could pick up a serial/usb adapter (or a multiport serial card) for the computer to expand the number of serial ports cheaper then a special cable.
 
I bought 2 ECM-1240s, an EtherPort adapter, a serial MUX cable, and a bunch of CTs last month.

At first, I thought that one of the ECM-1240s was defective because I could never get it to respond to any commands. Eventually, I got through to Paul, and he said it was not in the documentation, but one of the ECM-1240s would respond to Cmd Byte FC and the other to FD. That fixed that problem.

I examined the MUX cable pretty closely and it appears to me that the connections are as follows:

Serial Port (in my case the EtherPort) Pin 5 & Shield connect directly to the terminal labeled GND on each ECM-1240
Serial Port Pin 3 (TX) connects directly to the terminal labeled RX on each ECM-1240
Serial Port Pin 2 (RX) connects through diodes to the terminal labeled TX on each ECM-1240

So, anything transmitted from the EtherPort's serial port will be received by both ECM-1240s, but only one will recognize it's Cmd Byte. When one of the ECM-1240s transmit data, the diodes in the MUX cable prevent contention between the two output buffers. There can still be a collision if both ECM-1240s try to transmit data at the same time. I guess in this case the packet would just be discarded which isn't a big deal.

My next hurdle was getting all the software to work with Windows 7 64-bit. I did finally get it all to work after replacing the file "System.Data.SQLite.dll" with one that I downloaded that had been compiled for a 64-bit OS.

Two problems I am still having are:

1) If I try to change the number of MicroCT's on an AUX channel, I get a Run-time error '13': Type mismatch and the ECM Engine closes
2) Every day or two the ECM Engine will put up an error dialog box (don't remember the exact error) and I will have lost data from the time the error occured to the present.

Has anyone else seen errors like these two with the ECM Engine?
 
I just recalled that Brultech has a rep here on the BBS: BTechRep. According to his/er profile, s/he hasn't logged in since November 19. I sent a PM.

Chris D.
 
I just recalled that Brultech has a rep here on the BBS: BTechRep. According to his/er profile, s/he hasn't logged in since November 19. I sent a PM.
No ambiguity... He signs his posts "Paul", as in Paul Brule, as in BrulTech. I sense they have been swamped with the success of the ECM-1240 as email replies are spotty also, but it is a good product and we miss his input here.
 
Regarding my configuration questions...

I talked to Paul at Brultech today. He said that the current software supports a maximum of three ECM's. I didn't ask about the different variations of three ECM's (i.e., means of communication) that were supported, because he also told me that a new version of the software will be released soon that will support up to six ECM's. Again, I didn't ask about the specific variations that will be supported, but he did say that my "maximum" configurate (three ECM's via one EtherBee device and two ECM's via wired TCP/IP) will be supported.

He also said he can send out beta copies of the new software, but they don't have the documentation for it yet. Since it will be a little while before I exceed the current limits, I did not take him up on the beta version.
 
I got a PM from Paul (BTechRep). He confirms that the MUX cable is just as Ira describes. I cobbled one together with spare parts:

View attachment MUX1_Cable.pdf

and it seems to work: when I power one unit up, I can query it; when I power it down and power the other one up, I can query the second one. I cannot verify that both at the same time work, because I don't have the firmware that lets me configure unit ids. My units are serial numbers 30023 (uid=1) and 33153 (uid=1). When both are powered up and I ask for settings I get junk.

I'm trying the IA configurator, but I don't see where to enter the TCP/IP address for my EtherPort adapter. Any clues?
 
I'm trying the IA configurator, but I don't see where to enter the TCP/IP address for my EtherPort adapter. Any clues?

My additional ECM's haven't come in yet, so I'm still only using one via EtherBee wireless. But...I think you use the EtherX Configurator for both types of TCP/IP connections. The title bar on it says "EtherX Configuration Software for EtherBee and EtherPort V2.20". You specify an IP address and port number on it, and specify the port number on the Engine IA, I think.
 
I got a PM from Paul (BTechRep). He confirms that the MUX cable is just as Ira describes. I cobbled one together with spare parts:

View attachment 3038

and it seems to work: when I power one unit up, I can query it; when I power it down and power the other one up, I can query the second one. I cannot verify that both at the same time work, because I don't have the firmware that lets me configure unit ids. My units are serial numbers 30023 (uid=1) and 33153 (uid=1). When both are powered up and I ask for settings I get junk.

I'm trying the IA configurator, but I don't see where to enter the TCP/IP address for my EtherPort adapter. Any clues?

I could be wrong, but is the polarity of the diode drawn correctly? Seems reversed.
 
I could be wrong, but is the polarity of the diode drawn correctly? Seems reversed.
I'm a computer scientist, not an electrical engineer; so I may have goofed.
When I designed it, I figured Tx was positive heading toward the negative at the DB9. I want that positive to NOT go into the other Tx. IIRC diodes have the triangle pointing in the positive to negative direction (which is opposite to the flow of electrons).
The band on my diode is on the end away from the ECM-1240, and it passes Tx to my etherPort. I think I've drawn the schematic symbol accurately for the band location.
 
My additional ECM's haven't come in yet, so I'm still only using one via EtherBee wireless. But...I think you use the EtherX Configurator for both types of TCP/IP connections. The title bar on it says "EtherX Configuration Software for EtherBee and EtherPort V2.20". You specify an IP address and port number on it, and specify the port number on the Engine IA, I think.
Aha! The etherPort is configured as a push device, not a pull device. The etherPort can have a DHCP (floating) address, because it directs the RS-232 communication to a specific address. I expected a pull device, where a floating terminal would connect to a fixed, known service that was the RS-232 endpoint.

It works now.
 
I could be wrong, but is the polarity of the diode drawn correctly? Seems reversed.
I'm a computer scientist, not an electrical engineer; so I may have goofed.
When I designed it, I figured Tx was positive heading toward the negative at the DB9. I want that positive to NOT go into the other Tx. IIRC diodes have the triangle pointing in the positive to negative direction (which is opposite to the flow of electrons).
The band on my diode is on the end away from the ECM-1240, and it passes Tx to my etherPort. I think I've drawn the schematic symbol accurately for the band location.
My knowledge is old (like me) - The reason I first thought it was backwards is because I remember that diodes only pass current one way - "opposite" the direction of the "arrow". Not the same direction of the arrow. Looking @ the device, It looks like the TX would not get out the way it is oriented (With the arrow).
So - please to correct me if I am incorrect! ;) I have a feeling BSR knows this answer for sure?
 
The drawing Chris posted is correct.

When one of the ECM-1240's begins to transmit data, it raises the voltage on its TX pin. Once this voltage (which is applied to the diode's anode) is .7 volts above the diode's cathode the diode becomes forward biased and begins conducting electricity from the anode to the cathode (same direction as the arrow). Eventually, the TX pin will reach its final voltage (probably 5V) and the other side of the diode (the cathode) will be at around 4.3V which will be registered as a "high" signal by the RX pin of the serial port. The whole point of this setup is to allow the other diode to remain reverse biased which allows the TX pin on the other ECM-1240 to remain at a logic "low" without the two TX pins causing contention between each other.
 
I have cheated in the past by using this same method of sharing a serial port with up to 5 different devices to one serial port. It works well and is very relaible as long as your devices in the field are "speak when spoken to" type devices. If there is enough delay between polls to each device you should be fine.
 
Back
Top