yattr

I am using Beta 3.21.25. It appears that the 8b decode isn't starting at the correct position. The top trace is without any input from the source. The lower trace is with a bit change input from the source. Notice that the decode is shifted left on the lower trace. The top trace should start its decode like the lower trace....

Problem solved THANKS!!!! At least for the issue above. It might have impacted another Manchester sequence in a negative way. I will capture it and post it...

Will give it a try - thanks!

Thanks for looking into it. I am currently looking at another Manchester stream of 6 words that are all 10 bit and found that setting the number of bits to 11 is working ok for this case The above example has words from 13 to 8, specifically 13, 10, 9 and 8 bits....

Yes... For Falling One, if the last bit of an Event is a 1, the bit count is 1 less than it should be. For Rising One, if the last bit of an Event is a 0, the bit count is 1 less than it should be. Watch the video above and the value/bit-count

removed

Here is a video of the last bit changing from 0 to 1 which changes the bit count from 10 to 9 xxx.mov

I figured out what is caused the 9 bit Event result versus the 10 bits I had before. I had turn of a switch at the source which changed the state of the last bit from 1 to 0 For Falling One, if the last bit of an Event is a 1, the bit count is 1 less than it should be. For Rising One, if the last bit of an Event is a 0, the bit count is 1 less than it should be. The true nature of the above encoding is digital phase modulation, Phase Shift Keying. The data is determined on the implied clock's falling edge and the direction of the data edge...

I was playing around with the sample setting yesterday and an interesting change occurred with the results. What where 10 bits above are now 9 bits! I can not figure out what might of changed? Checking settings, all appears as it should...

Outstanding - THANKS h1024,h1EC (9b),h80 (8b),0 (1b),h110 (9b),0 (1b),h190 (9b),0 (1b),h130 (9b),0 (1b),h1B0 (9b),0 (1b),h150 (9b),0 (1b),h80 (8b),0 (1b),h170 (9b),0 (1b) h1026,h1EC (9b),h80 (8b),0 (1b),h110 (9b),0 (1b),h190 (9b),0 (1b),h130 (9b),0 (1b),h1B0 (9b),0 (1b),h150 (9b),0 (1b),h80 (8b),0 (1b),h170 (9b),0 (1b) h1025,h1EC (9b),h80 (8b),0 (1b),h110 (9b),0 (1b),h190 (9b),0 (1b),h130 (9b),0 (1b),h1B0 (9b),0 (1b),h150 (9b),0 (1b),h80 (8b),0 (1b),h170 (9b),0 (1b) h1024,h1EC (9b),h80 (8b),0 (1b),h110 (9b),0 (1b),h190 (9b),0 (1b),h130 (9b),0 (1b),h1B0 (9b),0 (1b),h150 (9b),0 (1b),h80 (8b),0 (1b),h170 (9b),0 (1b) h1026,h1EC (9b),h80 (8b),0 (1b),h110 (9b),0 (1b),h190 (9b),0 (1b),h130 (9b),0 (1b),h1B0 (9b),0 (1b),h150 (9b),0 (1b),h80 (8b),0 (1b),h170 (9b),0 (1b) h1025,h1EC (9b),h80 (8b),0 (1b),h110 (9b),0 (1b),h190 (9b),0 (1b),h130 (9b),0 (1b),h1B0 (9b),0 (1b),h150 (9b),0 (1b),h80 (8b),0 (1b),h170 (9b),0 (1b)

attila, Thanks you for all of your assistance. I am finding the Event view to be very helpful with his particular Manchester sequence. Is there a way to organize the Event data on a per sequence basis (or cycle - start to start) rather than event to event? This would be via a Save of the Event data dialog. Rather than all vertical, horizontally grouped by sequence/cycle as shown here (removed the line breaks from the Events within a sequence/cycle) The result is that it becomes easy to notice the changes in an Event on a cycle by cycle basis...

How would I setup the parameters to capture all the events (in event view) for a 75ms cycle where the implied clock rate for the Manchester code is 10KHz?

On the current release, the arrows next to the buffer count cycle through the buffers for both the trace display and data view. This isn't the case in the Beta release. BTW this is on a Mac M1 latest OS

Some Beta feedback... The bit level and event length Manchester changes are great - THANKS The buffer clear on start great option. I scroll thought the buffers to see the event changes but it is no longer working in the Beta version I like the Event view but it updates at a different rate than the main signal trace area. In the case above the 4th event had an unexpected sequence of values which were difficult to finally detect. I used the current released version to step through the buffers to capture the sequence. It would be handy if the Event view had an option to capture value history