Logic 2.2.14

Downloads / Releases
#1

Download Links

What’s new

  • Manual calibration - Download and install calibration files manually
  • Keyboard shortcut for closing the sidebar
  • Multi-column data table UI - Excel-like view of analyzer results. Some features are still missing: search, jump to graph time, store scroll position, etc

Improvement

  • UI rendering is now X4 faster!
  • Use tab name when saving to a file
  • Auto-select new markers and ranges
  • Moved capture progress popup to the bottom (closing it will minimize the window)
  • Data table can be navigated by ctrl/cmd-clicking protocol analyzer graph results (bubbles)

Bug fixes

  • Store app zoom factor on app reload
  • Handle start capture failures
  • Support for all low level analyzers in data table
2 Likes
#2
#3
#4

Zoom Does Not Work if Cursor is On Top of Yellow Trigger Line

After a capture, if the cursor is placed directly on top of the yellow trigger line, the =====++zoom (scroll wheel) does not zoom in or out. You know you are on top of the line when the pan arrow on the right side of the screen disappears.

1 Like
#5

Fixed :slight_smile:
Nice catch, thanks!

#6

Format string does not display as documentation suggests. A new template HLA on serial analyzer has this in set_settings()

    def set_settings(self, settings):
    # Here you can specify how output frames will be formatted in the Logic 2 UI
    # If no format is given for a type, a default formatting will be used
    # You can include the values from your frame data (as returned by `decode`) by wrapping their name in double braces, as shown below.
    return {
        'mytype': {
            'format': 'Output type: {{type}}, Input type: {{data.input_type}}'
        }
    }
    def decode(self, frame):
    # Return the data frame itself
    return {
        'type': 'mytype',  # This type matches up with the type returned from `set_settings`
        'start_time': frame['start_time'],
        'end_time': frame['end_time'],
        'data': {
            'input_type': frame['type']
        }
    }

A modified one has this:

   def set_settings(self, settings):
       return {
       'packet': {
       'format': 'Input type: {{data.kek}}'
        }
    def decode(self, frame):
       # Return the data frame itself
       return {
       'type': 'packet',  # This type matches up with the type returned from `set_settings`
           'start_time': frame['start_time'],
        'end_time': frame['end_time'],
        'data': {
           'kek': 'slam'
        }
    }

But the display in logic does not reflect that or any changes made to it.

image
image2031×596 31.1 KB

#7

I would like to first say, how much I appreciate the improvements going into each release. :smiley:

Serial Analyzer
I would like to second the desire for the Auto baud feature back, like it was in Version 1…

Handle Serial output at different Baud rates:
I am not sure I can explain this very well. but I am starting to play with a new robot with different servos (RobotShop - Lynxmotion LSS servos) than I have used. These servos are a full duplex Serial, with Ascii strings. input and output. like commands like:

#8QWR\r

And the servo responds something like:

*8QWR0\r

Which is asking Servo 8 for it’s wheel mode in RPM…

One thing I thought might good here is terminal mode as simple ASCII string commands and return values. But these only output \r and no line feed so end up with only the last line… So suggestion on allowing you to maybe configure what the line termination is. (Maybe I missed it).

But my current thing I am doing is changing all of the servos from their default baud rate of 115200 to be 500000. They say in their Wiki you need to do it by their app, but wondered what they are actually sending. As I expected they they send their configuration command at 115200:

#8CB500000\r
##254RESET\r

Which told the servo #8 to Change it’s baud to 500000 and then to reset all servos

It then tries to find servos by doing a simple query at different baud rates, until it gets one to respond.
So I first had the Serial analyzer setup for 115200 and saw all of the traffic up until the reset.

It then started to do some query functions at a few rates until it tried the 500000 and succeeded.
So I tried changing the Baud rate of the analyzer to 500000 and it did not show the query data correctly although the one in the response one appeared to recover properly and use the new baud rate.

One time I was able to delete the Analyzer, add it back and it did show the new baud rate correctly. Other times not. But if I then did a new query at the new baud rate it did show the new data correctly.

My guess is that maybe the analyzer did not recover from seeing the data from the other baud rates?

Again sorry I know I may have been a little verbose here and maybe not overly clear.

1 Like
#8

Sorry @mrkanaly, this is a bug in the documentation! That should be

   def set_settings(self, settings):
       return {
           'result_types': {
               'packet': {
                   'format': 'Input type: {{data.kek}}'
               }
           }
       }

Please let me know if that fixes the problem! We will get the template fixed.

#9

Indeed that fixed it! No need to be sorry, this is in fact alpha software. I can only give an A+ for the response time though. Thanks so much!

image

2 Likes
#10

Hi!
I am using the new SW, it is quite fine!
I saw one bug and I have one feature request:

Feature request first: If I chose a name for a channel, I’d like that the analoge channel and digital channel instantly get the same name. They are the same signal, so why can we give them different names?

Here’s a bug I saw: When exporting I2C data, the Packet IDs are not exported. Every packet has the ID “0”.
So, the exported list is useless, as we do not know if the data is really data or if it is a register address.
See example below. The stop bits which separate packets are not visible in the exported data.
I like that the format stayed the same though!

image
image1330×230 17.3 KB

Logic 2.2.14:
Time [s],Packet ID,Address,Data,Read/Write,ACK/NAK
0.109446880000000,0,0x96,0x28,Write,ACK
0.109544800000000,0,0x96,0x00,Write,ACK
0.109866720000000,0,0x96,0x2F,Write,ACK
0.109964800000000,0,0x96,0x01,Write,ACK
0.110286880000000,0,0x96,0x10,Write,ACK

Logic 1.2.18:
Time [s],Packet ID,Address,Data,Read/Write,ACK/NAK
1.171275260000000,1,0x96,0x28,Write,ACK
1.171372260000000,1,0x96,0x00,Write,ACK
1.171706760000000,2,0x96,0x2F,Write,ACK
1.171803760000000,2,0x96,0x01,Write,ACK
1.172136600000000,3,0x96,0x10,Write,ACK

Thanks!
Johannes

2 Likes
#11

Hi Johannes,

Thanks for the feedback! Matching the digital and analog channel names makes a lot of sense. Would you like to add it to our feature suggestion board at https://saleae.upvoty.com/b/feature-requests/ ? I’d also be happy to add it.

Great catch on the packet ids. That is currently being worked on, and should be fixed in one of the next few releases - it will be in the release notes when we do :slight_smile:

Ryan

#12

Will HLA output be added to the data table in the near future?

2 Likes
#13

Yes, probably in a couple of weeks

#14

I would like to second the desire for the Auto baud feature back,

Our plan is to create automation of things like that. For example, automate the following:

  1. Capture data for 1 second
  2. Create a measurement and extract the frequency
  3. Add an analyzer with a given set of parameters, including the frequency above.

In regards to the second part, I’m not sure that I’m following. Can you share a capture with us or provide us some steps to reproduce the issue? :slight_smile:

#15

We have an Idea request for matching digital and analog channel names: https://ideas.saleae.com/b/feature-requests/single-name-for-both-analog-and-digital-channel/

This feels like a no-brainer to me, but I can understand that the devs have been working so hard at other stuff that this is way down the list somewhere. Personally, for the small amount of work I’m guessing it should be, I’d love to see it bubble to the top some time soon.

1 Like
#16

Thanks for pointing that out, I had missed it when I searched!

#17

My take on @KurtE’s issue is that he has a system where his system starts up using a default baud rate then negotiates to use a different baud rate. Managing that in the analyzer is a hard ask, but an HLA that could offer advice to an analyzer would make this sort of thing easy.

It would mean exposing configuration parameters of the analyzer to HLAs so the HLA can update parameters on the fly. In this case default the baudrate to 115200, then when the HLA detects negotiation to a new baud rate the HLA sets the analyzer’s baud rate from that point forward to be the new rate.

1 Like
#18

I have an interest in it! :smiley:

This sort of small fix is what our dev team calls a “small win”. Something we can do to make customers smile and show we are listening, but doesn’t cost a lot of dev time.

In Saleae’s case all customers are grinning all over their face all the time anyway and the cadence for producing new cool stuff is already so high maybe this item would just get lost in the noise?

1 Like
#19

:grin: :grin: :grin: .

#20

That would be quite complicated to implement, however, maybe we kind find other ways around it, such as creating two separate analyzers with different start times. We’ll have to think about it more :slight_smile: