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.
Fixed 
Nice catch, thanks!
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.
I would like to first say, how much I appreciate the improvements going into each release. 
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.
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.
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!
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!
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
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
Ryan
Will HLA output be added to the data table in the near future?
Yes, probably in a couple of weeks
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:
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?
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.
Thanks for pointing that out, I had missed it when I searched!
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.
I have an interest in it!
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?
.
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
Fixed, we’ll be live on 2.2.16 probably
On the 2nd part the issue was that the host software changed baud rates several times in a second, or so, where it would try one baud rate see if anyone responds, if not, it would try different one… Until something responds.
With this I was having some issues where the analyzer would not pickup the data at the new baud rate, even when there were gaps between their logical packets. I will try to capture this again, but may be slightly fickle to get again.
0th issue is when you are doing terminal output with Serial, and the output stream is using \r characters to terminate lines, the terminal just keeps going back to start of row overwriting the data.
Would be good to be able to choose what your line termination is. for the terminal output
Thanks for the detailed description
I’m not sure what the right solution for something like that is. Feels like automation scripts code be useful…
Would be good to be able to choose what your line termination is
Would you like to add that to our feature requests board? I can to do as well
