MAX4644 not switching cleanly

Thread Starter

camerart

Joined Feb 25, 2013
3,830
Hi,
I have a PCB with RX INPUT to a PIC, where there are two sources.

I need to switch the 2x serial INPUT sources, and have tried a MAX4644 switch.

Most times it switches ok, but quite often the 2x signals get mixed.

I have 104 CAPS on the supply track and the switch track. I'm using a battery for power.

Any ideas please?

Camerart.
 

Papabravo

Joined Feb 24, 2006
22,082
Hi,
I have a PCB with RX INPUT to a PIC, where there are two sources.

I need to switch the 2x serial INPUT sources, and have tried a MAX4644 switch.

Most times it switches ok, but quite often the 2x signals get mixed.

I have 104 CAPS on the supply track and the switch track. I'm using a battery for power.

Any ideas please?

Camerart.
I'm not sure I quite understand what you are trying to do. Are you trying to select one of two asynchronous sources for a single input and you don't want the UART to see garbage when you switch in the middle of a character? You're going to have to acquire some capability in precognition for that to happen. Unless you have some control of the two transmitters I don't see a viable solution. If you implemented the XON/XOFF protocol then you could switch when both are in the XOFF state. Then XON the one you want to listen to.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
I'm not sure I quite understand what you are trying to do. Are you trying to select one of two asynchronous sources for a single input and you don't want the UART to see garbage when you switch in the middle of a character? You're going to have to acquire some capability in precognition for that to happen. Unless you have some control of the two transmitters I don't see a viable solution. If you implemented the XON/XOFF protocol then you could switch when both are in the XOFF state. Then XON the one you want to listen to.
Hi P,
At the moment it switches alternatively, until the end of one sentence then switches to the other, till the end of that sentence and so on.

What's happening is while switched one way, the other sentence is also showing at the RX PIN, so both at the same time, but mostly it switches cleanly.
C
 

Papabravo

Joined Feb 24, 2006
22,082
Hi P,
At the moment it switches alternatively, until the end of one sentence then switches to the other, till the end of that sentence and so on.

What's happening is while switched one way, the other sentence is also showing at the RX PIN, so both at the same time, but mostly it switches cleanly.
C
How long does this condition persist? Are we talking microseconds or milliseconds?
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
How long does this condition persist? Are we talking microseconds or milliseconds?
Hi P,
I haven't measured the time, but I can see a whole sentence go by.

I'm doing two things at the same time. 1/ Making changes to the parse section of the program. 2/ Figuring out what's wrong with the switching. So first, I think I should make sure the program's working by cutting the tracks, switching it manually, then getting it to work with both sentences, then come back to the switch.
C.
 

Papabravo

Joined Feb 24, 2006
22,082
I think that is a good approach. If you have two producers, it is handy to be able to tell one to talk and the other to be silent. This also works without a switch if the two transmit lines can be wire-ORed together.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
I think that is a good approach. If you have two producers, it is handy to be able to tell one to talk and the other to be silent. This also works without a switch if the two transmit lines can be wire-ORed together.
Hi P,
I was told previously, that two lines wired together won't work. Perhaps because of Oshonsoft. (The program I use)
C.
 

ericgibbs

Joined Jan 29, 2010
21,439
hi C,
Are the two Serial messages the ones listed in your other thread.??
ie: $GPGGA and $BASE

As you know the GPS message is at a fixed 1 second rate and the BASE message depends on when you call the BASE Servo module.
If they are not in timed sync they will clash and you will have corrupt data.

Just toggling the 'dataswitch' bit select source at the end of each 'get_val' subr will not work.

E
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
hi C,
Are the two Serial messages the ones listed in your other thread.??
ie: $GPGGA and $BASE

As you know the GPS message is at a fixed 1 second rate and the BASE message depends on when you call the BASE Servo module.
If they are not in timed sync they will clash and you will have corrupt data.

Just toggling the 'dataswitch' bit select source at the end of each 'get_val' subr will not work.

E
Hi E,
I presume that you've seen the #283 PARSE TXT, good! I'll try manual switching then, and monitor the other thread.
C.
 

ericgibbs

Joined Jan 29, 2010
21,439
hi C,
What is the 'Enable ' response period and rate of the $BASE SERVO.?
If it less than 1 second, I would consider calling the SERVO at the end of the know fixed period of the 1 second GPS string.

ie:
Await $GPS
Get $GPS message
Set the 'dataswitch' bit; set to recv the Servo
Call the Servo
Get the Servo message
Reset the 'dataswitch' bit; set to recv the GPS
;;process the $GPS and $BASE messages.

E
 

Papabravo

Joined Feb 24, 2006
22,082
Hi P,
I was told previously, that two lines wired together won't work. Perhaps because of Oshonsoft. (The program I use)
C.
Has absolutely nothing to do with the program you use. The condition for Wire-OR to work is that the drivers must be open collector/open-drain; and you have to ensure there will be no collisions. This was a common way of doing a bus before tri-state outputs came along. The drawback is fast fall times and sometimes painfully slow rise times. This is because risetime is controlled by a pullup resistor and the distributed capacitance of the signal lines. You should not always believe what you are told without asking why.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
Has absolutely nothing to do with the program you use. The condition for Wire-OR to work is that the drivers must be open collector/open-drain; and you have to ensure there will be no collisions. This was a common way of doing a bus before tri-state outputs came along. The drawback is fast fall times and sometimes painfully slow rise times. This is because risetime is controlled by a pullup resistor and the distributed capacitance of the signal lines. You should not always believe what you are told without asking why.
Hi P,
I suppose it depends who is telling me, what to believe :)
What do you think about this? #37 https://forum.allaboutcircuits.com/threads/hc-12-radio-module-tx-rx-in-oshonsoft.147865/page-2

Using a BASE INPUT from a SENT terminal, when set to RECEIVE BASE it PARSES ok.
INPUT from the GPS isn't giving results.
C.
 
Last edited:

ericgibbs

Joined Jan 29, 2010
21,439
hi,
What Papa is saying is correct for open collector/drain serial data ORed connections, the modules that you are using are not open drain/collector.

Post #37 devices are NOT open collector/drain outputs.

Its not a matter of whom you believe, its the modules that you trying to OR together that permits or not, ORed connections.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
hi,
What Papa is saying is correct for open collector/drain serial data ORed connections, the modules that you are using are not open drain/collector.

Post #37 devices are NOT open collector/drain outputs.

Its not a matter of whom you believe, its the modules that you trying to OR together that permits or not, ORed connections.
Hi E,
Ok, that's clarified it, so I still need a switch.
I've never heard of ORed.

Regarding who I question when they are telling me something: Each post tells me something. Some I question and some I get a second opinion. I generally believe what you tell me ;)
C.
 

Papabravo

Joined Feb 24, 2006
22,082
Hi E,
Ok, that's clarified it, so I still need a switch.
I've never heard of ORed.

Regarding who I question when they are telling me something: Each post tells me something. Some I question and some I get a second opinion. I generally believe what you tell me ;)
C.
It is not "ORed", it is "wire-ORed". What it means is the connection two open collector/drain outputs together, along with a pullup resistor, to perform a logic function without an explicit gate. In the case of the TTL 7438 which consists of 4 2-Input NAND gates, when you connect two ouputs together the result is the negative logic OR function which operates as follows:

a LOW .OR. a LOW is a LOW​

http://www.ti.com/lit/ds/symlink/sn7438.pdf

This was a pretty bright realization for the IC designers in 1970, at least IMHO.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
It is not "ORed", it is "wire-ORed". What it means is the connection two open collector/drain outputs together, along with a pullup resistor, to perform a logic function without an explicit gate. In the case of the TTL 7438 which consists of 4 2-Input NAND gates, when you connect two ouputs together the result is the negative logic OR function which operates as follows:

a LOW .OR. a LOW is a LOW​

http://www.ti.com/lit/ds/symlink/sn7438.pdf

This was a pretty bright realization for the IC designers in 1970, at least IMHO.
Hi P,
I think I've got some of those chips, but they're covered in dust, as is my memory of them.
Thanks, I'll remember if I need some of those gates.
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,830
It is not "ORed", it is "wire-ORed". What it means is the connection two open collector/drain outputs together, along with a pullup resistor, to perform a logic function without an explicit gate. In the case of the TTL 7438 which consists of 4 2-Input NAND gates, when you connect two ouputs together the result is the negative logic OR function which operates as follows:

a LOW .OR. a LOW is a LOW​

http://www.ti.com/lit/ds/symlink/sn7438.pdf

This was a pretty bright realization for the IC designers in 1970, at least IMHO.
Hi P,
I've re-read your message, and think I understand now.
C.
 
Top