DD Manchester Hex display

[yattr]

I have a 75ms cycle of 10 Manchester encoded words of various word lengths at a clock rate of 10k.  When decoding the bits as HEX, the display requires the exact bit count or less to display anything.

I have one 13-bit word, seven 10-bit words and two words that can change between 8 and 9-bits.

Is there a way to have the HEX display output a value independent of the word size from 8 to 13 bits?

Also, because the words occupy a small about of the 7.5ms frame (10 frames), is there a method to display each frame vertically so all can be seen together versus scrolling and zooming?

Here is the 75ms cycle with the 10 7.5ms frames comprised of the various word sizes.  The X pulses are don't cares.

Here is a HEX dispaly with 10 bits.  part of the 13 bit word and all of the 10 bit word

Here is the same as above with all of the 10 bit word but none of the 8/9 bit word

[attila]

Hi @yattr

The next version will show value for remaining/less bits than specified. It will also add 'bit label' option.
The decoded values are listed in the Events view. Click to highlight in plot, or modify Select mode, or double-click for positioning.

[attila]

Hi @yattr

 

[yattr]

attila,

Outstanding and thanks for the beta.  We give it a try today.

[yattr]

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

 

[attila]

Hi @yattr

Could you explain what is not working ? 

[yattr]

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

[attila]

Hi @yattr

In newer WF version the Buffer is only used in Repeated mode. This, to reduce the workspace/project size and save/loading time since the record is intended for large captures. If you want to keep the captures, these can be saved in tabs with the + (Add Tab) or scissors button.
Are you referring to operation this change ?

[yattr]

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?

[attila]

Hi @yattr

Configure the capture to cover the required time by adjusting Samples and Rate in the top-right.

[yattr]

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...

 

[attila]

Hi @yattr

You could use a Script like this:

Logic.run();
while(Logic.wait()) print(Logic.Channels.Manchester.events)

[yattr]

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)

 

[yattr]

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...

[yattr]

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...

[yattr]

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

 

 

[yattr]

removed

Edited January 27 by yattr

[attila]

Hi @yattr

Is there any problem in the decoding ?

[yattr]

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

[attila]

Hi @yattr

I tested this encoder with patterns where the line stays at last level.
I have to think about this, if I have to add an option for trimming last odd bit or not... to not to break other patterns.

[yattr]

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....

[attila]

Hi @yattr

 

[yattr]

Will give it a try - thanks!

[yattr]

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...

Edited February 2 by yattr

[yattr]

[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....