Products > Test Equipment

Siglent SDS2104X Plus - serial decoding digital input - number of bits

(1/2) > >>

Sorama:
@tautech and all other respected Siglent boys  ;D

When using the digital inputs with the optional probe of a Siglent scope 2000X plus series; how should I interpret the Bus Wide of the parameter 'Bus'?
Is this the number of bits including Start/Stop/Parity?

So let's say my bus is using 11 bits (9 data, 1 start, 1 stop bit): should I put the Bus Wide (strange word, no?) at 11?

I'm using a ninth bit for addressing between a processor (Dallas 80C52 compatible) and multiple slaves using UART (RS485 transceivers).
However, when doing so, the decoding is not correct.
However I set it, decoding is not correct.

tnx.

Sam

tautech:
One must ask what firmware version is in use ?
Latest is V1.6.2R5

Sorama:
Latest it is.
Tnx.

2N3055:
Serial protocols have no parallel number of bits, hence serial.
For serial UART type protocols we are looking into single bit that changes in time.
You set up parameters in UART Config. Baud rate, data length, parity and number of stop bits. Idle level and bit order.
Select which digital input pin or analog channel you are decoding.

And, at this time, UART decoders form Siglent does not support 9 bit modes with addressing.

Sorama:
tnx.
I am (of course) not confusing parallel with serial: I just mentioned the setting on the Siglent scope in Digital Bus Menu (see screenshot) which asks for "Bit Wide".
What is one supposed to put in there?

You say 9 bit is not supported, but the fact you can define parity to Mark or Space, that is supposed to be the implementation of 9 bit decoding.
That is how the other manufacturers do and they specifically mention it for 9 bit multidrop systems with the 9th bit set to 1 when an address byte is sent.

So, are you sure the Siglent cannot handle it?

PS: the screenshot shows the TTL levels of a RS485 transceiver running @ 345600 baud where Di is the driver/sender and coming from a 80c52 processor.
Protocol= when 9th bit is set to 1, the frame is considered to be an address of a slave.

The green trace is the sending of the address byte (9 bits, 1 start and 1 stop) but doesn't get decoded correctly.
The red trace is the receiver, a slave that is answering.

As you may not be able to see; the triggering is not stable; there is a horizontal jitter all the time that impacts a correct decoding. But as said before, I can't get it right even with correct holdoff time.
If you have a suggestion to solve that, please do so.

tnx again.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod