Dear Saleae Team,
I want to analyze a quadrature encoder with my Logic2 Pro, but currently there is no analyzer avaiable, right? I’m wondering nobody needs that, because it’s widely used for motor control. It would be great to have one…
If you have reasonable C++ foo you can write your own and make it available to everyone in the community. See the Protocol Analyzer SDK pages.
Dear Peter, I’m not sure if I can do this. Is a HLA also possible or better for that?
HLAs work with the output from low level analyzers, not with the raw data directly. At present they are also limited to use the data from just one channel so couldn’t decode the signal from a quadrature encoder in any case.
To get a feel for what is required you may be interested in looking at my TimeDelta Software Extension. It measures the time between edges in two channels and does somewhat similar work to that required by a quadrature decoder.
Dear Peter, could we also order this function from you? I guess you would be way faster…
If yes, pls send me PN with a quote.
BR,
Wolfgang
What type of output/decoding do you expect to see? What specific device are you monitoring (link to datasheet)?
Depending on exactly what you want, the SDK might not work and you may need to decode from exported data instead.
It’s basically the same as this:
for the beginning, it would be nice to see the count or position:
In the end I analyze Position, Speed and Acceleration. This is Excel Data with CVS Export.
But seeing the position would also help. I could not find this as function in my scope, Logicport analyser and Saleae, but I think more people need it.
Br, Wolfgang
I thought it might be something like that. To get a nice chart or graph, Saleae would need to finally implement:
(edited link – referred to wrong ‘virtual’ channel case in previous post)
(many other forms of this request) where you could have a ‘virtual’ channel to plot the decoded data.
However, you could calculate a position of sorts as a low level analyzer that would have a numerical value overlayed on one ‘main/master’ channel (ENCA), but may have to ‘calibrate’ it with analyzer settings (initial position, rotation ‘rate’ scale factor, etc.) to have meaningful output for more users. I am not a regular user of this type of signal, so can’t provide more specific advice.
Edit:
@wolfgang.kopp – Out of curiosity, do you have an example *.sal capture file of your encoder that you could attach? There might be some techniques you could use existing analyzers to extract some useful information in lieu of a custom LLA, but I’d need to see a real example capture to confirm
1 Like
The “mother case” for plotting virtual channels is this one: Virtual math channels and analog transformation functions - Logic 2 - Ideas and Feature Requests - Saleae
It’s something that ModelSIM does really well and is super useful for the users. However, it could turn out to be a bottomless pit of work for Mark and the other guys.
The request I linked is for allowing the analyzer SDKs to create a new ‘virtual’ channel as an output of an analyzer (LLA or HLA), which is different than using a basic ‘math’ operation of other analog/digital channel(s). Note: I updated my link to go directly to the ‘virtual’ channel idea (the previous reference was merged into that one anyway).
I think these ideas could be implemented together – as the underlying technology of supporting a ‘virtual channel’ should support both of these use cases: one uses built-in math functions or other predefined setting options provided by Saleae and the other uses any data generated by the analyzer SDK. If this feature was implemented, then each of the Excel charts shown above (position, speed, and acceleration) could be plotted directly within Saleae Logic UI and updated real time within the ‘live’ view.
For now, I think you can only calculate the derived value(s) (position, speed and/or acceleration) and output as ‘frame data’ (text) in the Analyzer data table/terminal view. You could also add ‘bubble text’ above the channel graphs. However, this is all just numerical text display, but no new graphical visualizations like what can be done in Excel.
Meanwhile, I think you might be able to use a Simple Parallel Analyzer, with:
- ‘ENCA’ channel is the ‘Clock’
- Clock State = Rising edge (?)
- ‘ENCB’ channel is ‘D0’
This should trace a ‘0’ or ‘1’ data value (with frame timestamps) on each ‘ENCA’ edge. Export that analyzer data into Excel or a script that would calculate position, speed, and/or acceleration as needed which might be a little easier than trying to decode ENCA + ENCB directly (??)
Also, you might be able to create a simple HLA from this setup to at least calculate ‘position’ (or other derived values) from this simple parallel frame data, too?
Note: If somebody who is interested in having this could reply & attach a quadrature encoder capture file (*.sal) of some real data, it might be an interesting HLA (or LLA) tutorial to try this out sometime.
TU_Linear_encoder1.sal (1.1 MB)
find an attached sample with encoder signals. I check the “parallel analyser” later, but I think, did does not work correctly.
just tried the “parallel analyser”, its kind of what I need. It does not count up/downwards and both channels needs edge detection I would say.
I notice that the some of the rising edges are rather glitchy. If you care you can turn on a glitch filter in the Device Settings panel to clean the edges up and avoid some very rapid count changes on those edges.
Hi @wolfgang.kopp –
I wanted to learn a bit more about how the Python extensions (and Saleae HLAs) worked, so I drafted a very basic Quadrature Encoder HLA over the weekend.
Is this the type of output you’re looking for:
Note: in your example, I think you set Clock State to Dual edge (default?) instead of Rising edge, which may not work very well with trying to create an HLA to process the Simple Parallel Analyzer output data and use its simple analyzer frame format as input. Currently, the only thing output is data and not the clock edge (might be a nice enhancement to the FrameV2 output), so the data will toggle back and forth (from rising edge vs. falling edge) rather than show a consistent value of 0 or 1 based on the ENCB channel state when ENCA rising edge occurs (see above).
Thus, for a ‘basic’ LLA (Simple Analyzer) + HLA (Python Extension), I think you can use ONE edge (rising or falling) of the ENCA channel ONLY. If you want 2X or 4X edge decoder capability, then that requires a custom LLA in C++, as the Saleae HLAs are limited to only one LLA source and must use the FrameV2 data provided by the LLA.
Anyway, is the screenshot above what you were expected, as far as decoding in the chart/timeline view?
Also, as far as Data / Table output view - how about the following:
… given the settings:
Where the Initial Position setting would allow you to tweak the starting position (before the first decoded edge from Simple Parallel analyzer input), and the Scale Factor (default: 0, interpreted as 1) will allow you to tweak the display value and calculate both the scaled_position and scaled_rate columns in the HLA output frame. Finally, the Initial Rate allows for user-defined rate for the first frame output (default: 0).
#include <stddisclaimer>
I definitely can’t guarantee that it works correctly or as anyone would prefer (as I have limited expertise with this type of input waveform), and it definitely depends on user configuration settings being set properly as described above. Also, the one example *.sal file provided appeared to only go in one direction, so I didn’t have a test waveform going the other way. However, it was an interesting practical tutorial to learn some HLA basics 
Finally, I didn’t include an acceleration value, since it seems like you needed a fair amount of user-defined post-processing (filtering) to have more meaningful data. I figured you could calculate additional derived measurements from a CSV export and decided to keep this decoder simple. Likewise, if you want any charts/graphs, you need to use the CSV export data anyway until Saleae implements the virtual channel feature described previously.
its counting 4 times as fast. I reckon we would need the LLA in C++ for a correct implementation. But basically it’s what I need. Thanks for that!
Okay, so it looks like you want X4 encoding vs. X1 – and that does mean you’d need a custom LLA, as it isn’t possible with the technique that I showed previously.
BTW: Are you on Windows platform, or something else?
Also, according to:
… it looks like even my simplified decoder wouldn’t quite decode correctly for even the X1 method, as it is only monitoring rising (not falling) edges of Channel A (ENCA) waveform. In the counterclockwise (reverse) direction, it would still be using rising edges to decrement – and could therefore have some accuracy/precision errors for anything that is changing direction frequently.
Note: this makes sense, as a rising edge in one direction should be a falling edge going the other way.
Thus, I think an X1 or X2 type of HLA could be created, but the Simple Parallel analyzer would need to indicate edge ‘polarity’ in the FrameV2 output vs. only providing data by itself. Otherwise, just save a CSV of the two digital channels (A and B) and do everything outside of Saleae Logic for now. Are X1 or X2 analyzers even useful, or is X4 the most common use case in practice?
Also, how are error cases supposed to be handled? E.g., what if one channel has both rising and falling edges before the other channel has any edges (which is not supposed to be possible)? Are these scenarios ‘filtered out’ (ignored) or what? I’d suspect you’d most likely see this as a ‘glitch’ on one channel – which could be filtered out and just ‘tagged’ as an error in the decoded stream, but curious about the real-world scenarios with this type of technology (i.e., what exception cases really happen and how should they be handled?)
Finally, what type of outputs would be useful other than the position and rate values? Are the ‘scaled’ versions of position and rate useful? Or, is it best to just display the simple encoder ‘position counter’ value and skip the ‘scale factor’ feature? At this point, I’m thinking the scale factor might be more useful on a graph/chart rather than table data output.
you have it right now, your analyzer is definitely not correct. I only know X4 quadrature encoders and they are very common. I do not care too much about “Position” and “rate”, because I can convert it externally, so I would focus on a basic X4 implementation.
also check out the other request:
Hi @wolfgang.kopp –
The other reference request seemed to be less complex of a request, only wanting X1 or something less than X4. Anyway, I am curious if you’re on Windows, or another platform?
Also, do you have a sample trace going both directions vs. only one?
Dear Bitbob, yes, just Windows! I will record multiple movements and post it here
Session01_6moves.sal (77.0 KB)
this sessions contains multiple moves:
