How can I convert serial data to a binary sequence?

> The sequence is 01011010 how can I change from the square wave shown here to a square wave that shows just 01011010? The data rate is 600 bits per second and I am sampling at about 3 times that. Thank you.

[Walter Roberson]

Is the diagram intended to display one copy of sampling 01011010 at 1800 samples per second? Is the x axis numbering sample numbers or milliseconds?

For the numbering to make sense as sample numbers, there would have to be about 83 groups of 8 bits.

For the x axis number to make sense as milliseconds, there would have to be about 18 groups of 8 bits.

[Brendan Lyden]

x axis is samples and there are (almost) 7 01011010 sequences

[Walter Roberson]

I was misreading the readings a bit.

On my display it appears that 3 cm corresponds to 80 samples. The overall display shows up as 7.8 cm, so that would be 7.8*(80/3) = 208 samples.

The sample counts would work out if there were 4 samples per bit rather than 3 -- 208/4 = 52 bits, which would be 6 1/2 repetitions of 8 bits. For the sample count to work out with 3 samples per bit, there would have to be between 8 and 9 repetitions rather than between 6 and 7.

[Walter Roberson]

I see in the other discussion that you are sampling at about 3000 samples per second. 208 samples at 3000 samples per second of 600 data bits per second would only be enough samples for 5 complete repetitions.

Question: are you sending async or synchronous? If you are sending async with RS232 then you need to worry about start bits and stop bits, and you have to know the number of each; pretty much everyone uses 1 start bit, but the number of stop bits used varies a bit. Asynch implies that the transitions need to be detected rather than assuming a fixed frequency.

It would also be important to know if you are using a protocol such as bisync or NRZ or NRZI.

Answer 1

[John BG]

There are a couple ways to do this. The comments below are referring to John's initial Answer (Approach 2).

Approach 1:

For the first approach, we've included a Simulink model.

Convert this analog serial signal into a digital signal, we will use a comparator.  This will generate a series of 1s and 0s at “around 1800 Samples/second.”  Then we will down-sample, but since we don’t know the exact original sample rate we have used interp1() instead of downsample().  This has the added benefit of handling nonuniform input sample rates but requires a time value for each sample.  It generates our stream of 1s and 0s at 600 S/s.  We can get away with this because the incoming symbol rate is exactly 600 b/s, therefore sampling at that rate guarantees us one sample per symbol (bit).  More care may be needed to apply this approach to jittery signals.  Finally, we can do digital processing to recover the input signal. In this case, we know the first 8 elements of this sequence will be our input data word. Additionally, we can plot the first 9 elements to see a graphical representation (the extra element helps the graph look as expected).

Approach 2:

1) square the signal the time reference is not really needed. Clipping

x(x>500)=500;

x(x<250)=200;

2) Brendan, please let know if the following reasoning is consistent with your question:

in order to use the 600bps rate one has to know the time reference.

Visual observation reveals that about 15 samples make the 8 pulses of the basic sequence.

7 bursts take the whole scope shown, that comprises 2840-2640, 200 samples

200 samples are (approximately) 7*8=56 pulses

If you have assigned 1 bit per pulse, an estimate of the presented time span would be:

56[pulses]*1[bit/pulse]*1[sec]/600[bps]*200[samples]=15 seconds

it would be safer to assign at least 3 samples per pulse.

3) synchronisation, how do want to sync?

4) can you present a time based graph? with the time vector, not the numerals. Meaning, can you, instead of

plot(x)

do

plot(tx,x)

If you find this answer useful would you please be so kind to mark my answer as Accepted Answer?

To any other reader, please if you find this answer

please click on the thumbs-up vote link

thanks in advance

John BG

<mailto:[e-mail] [e-mail]>

[Brendan Lyden]

I am sampling for 5 seconds and there are approximately 15000 samples. I have set the data rate of the input data to 600 bits/s.

Is it necessary to have synchronisation?

Thank you

[John BG]

1.

NYQUIST

you have to sample faster than the signal changes.

The Nyquist boundary or Nyquist frequency is the 'edge of the cliff' where you don't really want to work.

Reconstructing sharply changing sine cosine signals only allowing a couple samples per cycle of the highest tone is not a good practice.

It happens, people do it, but why assign just 2 samples per cycle when you can assign more than 2?

2.

ALIAS

This applied to your question means that 15ksamples over 5 seconds, you have 3ksamples/second.

Since it's a binary signal, 3kbps is the rate of bits assigned by the acquisition device, which doesn't have to be the signal rate itself.

If your signal is slow, the signal is going to have many 1 bursts and 0 bursts, and the 600bps sampling may be ok.

If your signal is the fastest it can assuming there is no aliasing, then the signal may (or may not) be 1.5kbps (or faster) which would be the worst case when you are receiving 10101..

If the signal faster than 1.5kbps then, one step back, your data is already corrupted, so if you can fix it first, but we have been assuming it's not the case.

Then, in such case, if the input rate is 1.5kbps the sampling 600bps is a rate way too slow, to keep up with 1.5kbps

If you use 600bps on a signal faster than 300bps one is going to be misled to take the sampled signal as good, but it would be like measuring how fast a wheel spins just with the human eye: above certain w[rad/s], human eye only catches the alias.

3.

SO

the key question, how much time do you measure between the 1st bit of consecutive 01011010 bursts?

By the way, shift 1 bit right and instead of 01011010 use the burst 10110100, it may help.

Are you measuring with oscilloscope? then measure the time between consecutive bits, or the time between consecutive bursts, and divide by the amount of bits in the burst or frame: here 8, right?

this is the key data you need in order to tell whether 600bps is fast enough, too fast or won't catch all you may need above 300bps.

can you measure such delay?

John BG

<mailto:[e-mail] [e-mail]>

[Walter Roberson]

I think they are indicating that the signal rate is 600 bits per second (600 data pulses) but that they are sampling at about 3000 samples per second, which would give about 5 samples per bit, which should be enough to recognize the data without worry about aliasing.

The indicated sequence 01011010 has the interesting property of being symmetric, which removes the question about which order it is being transmitted in, Most Significant Bit first or Least Significant Bit first.

[John BG]

Hi Walter

those 5 samples per bit may well go down to just 2 samples per bit because from the provided data it's not known whether the pace of the input signal, not the sampling rate, is kept constant along the entire signal.

It could be that the samples shown in the question seem to hold constant rate, yet it all speeds up a few moments later, the frame, not the sampling rate.

An amplitude conditioning circuit to remove possible 'ups and downs' of the amplitude may be of interest, but to make sure that the decisions to '1' and '0' are correct, local synchronisation has to be provided.

Getting to the point that one has to build a circuit that every 7 bits generates a pulse telling 'frame starts now', if the data rate is not going to be constant, deciding when the frame starts is easier basing the decision upon a sharp enough transition.

I you use 01011010, ok it's symmetric, but you can only appreciate such symmetry AFTER you have decided whether the burst has started and then you count forward. In detection there's always some guessing, that has to be minimised, but if you must guess, would you choose between zeros or right between 01? or 10?

The problem of waiting right between zeros, 0 Volts I mean, is that if that low level lags or speeds up, you are going to start introducing counting errors.

If the counting errors pile up, entire frames may be miscounted.

However, if you base the detection no 0 to 1 transition (or 1 to 0 transition) unless the signal is missing or there's some kind of hardware problem, you will always be able to tell where to start counting, as long as the transition is sharp enough indeed.

Once you have synced, then you can build frames, and correlate, and rebuild the clock based on the spikes produced buy 01011010 instead of 10110100, but to catch the beginning of a 7 bits frames, to avoid taking the 1st zero for the second one, or the other way round, it should make sense to base the initial detection where the 1st one starts or stops, whichever one you want.

Or you can go for a zero, but it should have ones both sides to make sure you don't wait guessing.

John BG

<mailto:[e-mail] [e-mail]>

[Walter Roberson]

We do need to know whether the bits are synchronous or asynchronous, and we need to know whether start and stop bits are being used, and whether bit-stuffing or Non Return To Zero, Inverted (NRZI) is being used.

Asynch protocols like RS232 or TTL often need three voltage levels: one for 0, one for 1, and one for idle. The diagram posted gives no clear indication that there is a third voltage; if there is then we can see from the pattern that it is not being used in a regular pattern such as would be expected for RS232 or TTL. That does not rule out NRZ or NRZI though, which avoids going to rest state.

The y values are mostly between 200 and 550. That sort of sounds like "5 and a half volts". But if so then it cannot be RS232 because RS232 needs positive and negative voltages. Could it be TTL? TTL uses 2V to 5V for the High state, and if we are getting that the readings are in 1/100 V then that would be 200 to 500; the peak at 550 might be excused, but nearly all of the readings are at least 200 or High; Low in TTL is 0 to 0.8V, or about 0 to 80 if we guess at 1/100 V. So the TTL is not supported.

The RS232 and TTL idle states are both between the high and low states, and we see no evidence of any intermediate values, only a hint that there might be something below 200 that is neither high nor low.

Could it be a synchronous protocol? Possibly. Synchronous protocols reconstruct timing by careful protocol violations, such as using a voltage that is otherwise out of range, or by using more than a certain width of one voltage or another (e.g., more than four 0s in a row might represent a protocol violation that indicates a timing pulse.) We would not necessarily observe such a thing in this extract, as it might have occurred before the sampling started.

With respect to whether 10 or 01 would be preferred for detecting pulses: the odd thing about a number of communications protocols is that it is not uncommon for the 0 state to be represented by the high voltage and the 1 state to be represented by the low voltage.

8 bit bytes with Most Significant Bit 0 occur more often than not in text, so it would not be realistic to build a communications protocol that only worked if the Most Significant Bit was 1. And RS232 for one transmits the Least Significant Bit first...

[John BG]

the High 0V and Low +Vcc is because it simplifies signalling error if +Vcc goes down.

When doing High +Vcc and Low 0V, how do you tell, without additional signalling, just from the line, that Vcc voltage is down?

Let's focus on this question, why browsing protocols if there is no protocol defined at all.

It's far more simple, it's before defining any protocol at all:

Let be you are receiving

..000111000111111000111000000111000111111000111000 000111000111111000111000..

if you decide to watch right in the middle of those 6 zeros, and start from there, it's problem is the signal starts doing this

..000111000111111000111000011001111001100 000111000111111000111000..

if the signal increases, 4x9 instead of 6, you are waiting for 6 zeros, but you are going to find 1, lost sync, then how do you solve the problem? how do you recover the 6x0? there are no more 6x0 consecutive zeros.

If the signal slows down, taking into account signal levels only, it's a problem as soon as jitter, noise, whatever shakes the signal enough to introduce counting errors: solution catch transitions, at least to tell where burst should start. Add a basic PLL to lock on any possible small rate variation, and then, even if a bit too many or too short, the PLL will slow down or speed up detection to remain locked.

Regards

John BG <mailto:[e-mail] [e-mail]>

[Walter Roberson]

However, we are shown an extract from the middle of a signal, not the beginning of the signal. If the bits are asynch then you need to know which asynch protocol is being used in order to figure out where the word boundaries are. If the bits are synchronous then we have the possibility that any synchronization happened before the data we are shown, and that in the section we are shown that bit boundaries are determined by timing. It is not uncommon in synchronous protocols for there to be a burst time defined, that once synch is recovered that all of the time slots for the next fixed time are to be assumed to be valid bits. I do not see anything in the signal that rules out the possibility that we are being shown something in the middle of such a synchronous burst.

[John BG]

1.

if sync happened the previous word and missed, doesn't matter, the circuit should catch up on next word.

It's not about protocol, you are assuming that the step samples-to-bits is solved. The question was about basic amplitude conditioning, clipping solves it.

2.

If it had been asked anything about sync

then there is only one word to sync to: 10110100 or 11010010 or 01101001 all same word shifted, also 01011010 but you make things a bit more difficult because of the lack of transition, the uncertainty of telling to sync in the middle of nowhere.

3.

see it this way:

you are suggesting to apply a set of masks and tell whether the word is detected

buffer 7 bits; check mask 11010010
buffer 14 bits. check mask 1111001100001100
buffer 21 bits check mask 111111000111000000111000

.

I am suggesting

WORD=0
if up
  if timeout break
  if still up
      if timeout break
      if down
           if timeout break
           if up
               if timeout break
               if down 
                   if timeout break
                   if still down
                        if timeout break
                        if up 
                            if timeout break
                            if down
                                if timeout break
                                WORD=1
..

that, in real 3D, example circuit, the CY22150,

4.

tolerated jitter:

.

.

5.

timing is everything, within specs? bus caught? too fast, too slow, sync lost

.

.

6.

the faster is the PLL clock the better because it widens lock windows

hope it helps

John BG

<mailto:[e-mail] [e-mail]>

[Walter Roberson]

"if sync happened the previous word and missed, doesn't matter, the circuit should catch up on next word."

That depends on it being an asynch protocol, which we do not know. It might be a synchronous protocol.

Synchronous protocols have two basic variations:

A) synchronization is signaled (somehow), and for a period of time after that, clocks are assumed to stay in sync to within half of a bit time, so that the total timing difference between sender and receiver is less than 1 bit during the block. After that period, synchronization is re-established for another burst. If I recall correctly, I have heard this referred to as a "block sync protocol"

B) synchronization is continual and not block oriented. The protocol is arranged so that there is a guaranteed transition within a certain number of bits no matter what the source. This can be by "stuffing" a transition if needed that is removed from the data stream on the receiver; or it can be by using two or more different constellation encodings for groups of bits and switching to the alternate constellation if continuing in the same encoding would otherwise have failed the transition guarantee. Each transition regenerates the clock for the receiver, so instead of it being a fixed block size after a block sync during which the clock is considered to be valid, every received transmission effectively restarts a timer. This kind of protocol can go on indefinitely, but there are usually built in safeguards so that you can determine the initial boundary in the first place, and also safeguards to periodically re-establish the major boundary in case the link dropped. These often involve deliberate protocol violations.

"you are suggesting to apply a set of masks and tell whether the word is detected"

I am suggesting no such thing.

Async protocols typically have mandatory silence gaps, and extra non-data bits or extra transitions to set up framing for the following byte (which could be 5 to 11 data bits); or (much less commonly) framing for two bytes. Those mandatory silence gaps and extra bits or transitions leave visible traces on the signal. It is far from clear that we are seeing those traces here; we are not seeing the sort of traces that would be associated with RS232, RS422, or TTL, even if we were to suppose that the y axis has been mislabeled.

Synchronous protocols vary in how they handle timing and synchronization, but by definition for synchronous protocols, it is never at the bit or byte level. Any protocol that synchronizes each byte independently is, by definition, an asynchronous protocol.

Answer 2

[fateme zabihi]

hello

I have a 4-bit output as a pulse that I want to multiply by 8, 4, 2, and 1 based on the importance of the bits and see the final output. What should I do?