Switching serial DATA between two sources

[dknguyen]

nah. crosstalk in the switch doesn't have anything to do with the clock. What do you mean by switch track?

 

[camerart]

nah. crosstalk in the switch doesn't have anything to do with the clock. What do you mean by switch track?

Hi D,
I call the track that switches this switch, the switch track.
C.

 

[camerart]

Hi,
I'm now thinking that 'I' is correct, and maybe the correct switch is needed.

I've just found out that they are called mulitiplex switches or MUX for short.

I searched for MUX switches and found this page: https://para.maximintegrated.com/search.mvp?fam=swmux_low&190=2-to-1 Which shows the https://para.maximintegrated.com/search.mvp?fam=swmux_low&190=2-to-1
MAX4644, so to me it looks ok.

I'm still getting crosstalk.
C.

 

[dknguyen]

Can you show us a waveform?

 

[camerart]

Can you show us a waveform?

Hi D,
I'm not yet used to my new/old oscilloscope, but it has two channels. Here we have two INPUTs and one OUTPUT. What I've been doing is alternatively looking at one INPUT while looking at the OUTPUT. If BOTH readings are the same then ok, but if the INPUT doesn't match the OUTPUT, then I think the signals are getting crossed. I can photo both instances of each channel with one OUTPUT, is this what you're wanting?
C.

 

[Ian Rogers]

Hi E... I think that switch should work... I noticed your thread on AAC..

Did you place a 10k pullup on pin? Also... You mentioned RS232 from a GPS and a HC12... The signals will be "like for like" what I mean is if 5v arrives the 5v will fed out to the pic.... Also if -10 ~+10 from a RS232 compatible source, this will also be seen on the pic.... Are you sure they are both TTL 3v outputs?

 

[jjw]

Hi D,
I call the track that switches this switch, the switch track.
C.

So this is the output from pic?
104 cap here is not a good idea.
How are you testing this, manually or with a program in pic?

 

[camerart]

Hi I and J,
10K pullup on SWITCH PIN, yes. I'll remove the 104 Cap.

The GPS is powered at 5V, and outputs 3.3V. The USB to SERIAL has a 3.3V jumper. All signals are 3.3V

TESTING:
1/ With the GPS OUTPUT connected and feeding one side of the switch, and an HC-12 INPUT feeding the other side. A separate computer with a TERMINAL OUTPUT via a second HC-12 transmitting a test STRING e,g, $BASE,1100,1200,1300,1400,1500,1600,? (This is ONLY a TEST message)

The separate computer should RECEIVE all of the HSEROUTs from the PCB, on the terminal screen. It has had spells of working! At the moment with the attached PARSE, the TERMINAL doesn't show a calculated reply, also no LEDs ON.

2/ With one track of the oscilloscope connected to the PIC RX and the other track moving between the GPS and the HC-12, both are showing as expected, on their OUTPUTs but the RX PIN shows occasional crossover.
C

 

[dknguyen]

I can photo both instances of each channel with one OUTPUT, is this what you're wanting?
C.

yes

 

[JonSea]

If you switch sources during a transmission, the receiver may lose sync and garbled messages result.

 

[camerart]

If you switch sources during a transmission, the receiver may lose sync and garbled messages result.

Hi J,
I switch at the end of one sentence, to receive the other sentence, as a toggle.
C.

 

[JonSea]

If you connect to the other source in the middle of a transmission, the same thing will occur. You'll be out of sync. Unless you control when both devices send data, I think you're screwed.

 

[dknguyen]

If you connect to the other source in the middle of a transmission, the same thing will occur. You'll be out of sync. Unless you control when both devices send data, I think you're screwed.

JonSea brings up a good point. Do you have a hardware flow control signal to each source? Or maybe you are also switching a TX between each source and they only send data when polled?

Still doesn't explain the crosstalk though.

 

[camerart]

Hi J and D,
No hardware control.

It only switches after a sentence.
Am I correct that:
If it switched to the next sentence, mid sentence (1), that sentence (1)would be lost, then would the next sentence (1) be ok, then switch to the next sentence (2) and so on?
C.

 

[dknguyen]

Hi J and D,
No hardware control.

It only switches after a sentence.
Am I correct that:
If it switched to the next sentence, mid sentence (1), that sentence (1)would be lost, then would the next sentence (1) be ok, then switch to the next sentence (2) and so on?
C.

Only if both devices have a delay between consecutive transmissions of greater than a serial word (8-bits) or so. Because if there isn't, then the receiver won't be able to distinguish between the new-transmission you jumped into the middle of, the idle state, the stop bit of the old transmission, and the start bit of the new transmission. You basically rely on timing out the old transmission so you know that subsequent incoming data is new and fresh.

 

[camerart]

Only if both devices have a delay between consecutive transmissions of greater than a serial word (8-bits) or so. Because if there isn't, then the receiver won't be able to distinguish between the new-transmission you jumped into the middle of, the idle state, the stop bit of the old transmission, and the start bit of the new transmission. You basically rely on timing out the old transmission so you know that subsequent incoming data is new and fresh.

Hi D,
When you say receiver I do you mean the PIC RX PIN and program?

If the RX has received a mid sentence transmission, and is 'in error' when the next sentence arrives from, are you saying it won't 'see' it? There is quite a gap between sentences.

C.

 

[Pommie]

Can a 4093 do this? I think it can.

Mike.

 

[JonSea]

Can a 4093 do this? I think it can.

Mike.

The output is inverted, so this would not work, but a logic chip rather than an analog switch does seem like a better choice.

But a logic chip does solve the "We join this message in progress" sync problem.

 

[Pommie]

Something like,

Mike.

 

[JonSea]

Ah, gotcha. That would work great, except for the sync problem in switching between streams.