Ikalogic Blog

Blog

Kinetis, FTM, and complementary combined PWM

Lately I’ve been working on a Kinetis K70 cortex M4 micro controller. It’s one of my favorite micro controllers by the way. I needed to control a 3 phases BLDC motor.  Obviously, there was going to be some PWM signals involved!

There are two ways to generate PWM signals with a kinetis MCU, either using the “classic” TPM-compatible registers (that’s when the bit FTMEN in  FTMx_MODE register si cleared), or the FTM mode (FTMEN = 1). Using the TPM-compatible mode is rather simple and straight forward, but offer limited functionalities, compared to FTM mode. (more…)

ScanaQuad Input / Output configuration

Introduction

ScanaQuad Logic Analyzers and pattern generators have a versatile I/O stage, that allows the user to configure the probes in various different fashions, covers a broad range of applications.

In this tutorial, we’re going to present the different probes configuration options and their usage. We’re going to assume you’re using an SQ200 Logic analyzer. Depending you the model you own, not all features may be available. (more…)

The nightmare of electronics parts inventory management!
posted by: in Company life

Ikalogic was created in 2010. We buy electronics components 2 to 3 times per week for prototyping purposes. We also buy a big amount of those in industrial conditioning for PCB assembly. That’s a lot of components. By the end of 2015, we had a huge amount of stocked components, and dealing with that stock was a night mare: Each electronics chip or passive component usually cost a few dozen cents: it’s not worth spending too much time searching for it, so whenever we need one, well, we buy it (again). It’s a vicious circle, because the more you move in that way, the more you have components laying around, the less it becomes easy to find anything. (more…)

High level decoding with ScanaStudio

Content on this page applies to ScanaStudio V2.4 and above.

Contents

Introduction

ScanaStudio allows users to write their own protocols analyzers. By “Protocol analyzer”, we mean a script that can handle one or more of the following actions:

  • Decode a protocol (like I2C, UART or SPI) and display decoded data superposed on the wave forms (example)
  • Display decoded data as packets (like WireShark does) or as a HEX dump (as in a regular HEX file viewer).
  • Trigger on a specific data content (like a UART Data byte or I2C address)
  • Build arbitrary signals that can be used to generate data latter.

(more…)

Signal builder script

NOTE 1: The information on this page applies to ScanaStudio v2.303 and above
NOTE 2: The information on this page only apply to logic analyzers that support signal generation feature (Like ScanaQuad series or Scanalogic-2)

Introduction

ScanaStudio V 2.3 (and above) introduced a new digital signal generation module that was designed to be more versatile, more powerful, and more user friendly in the same time. For that, the signal generator is divided into two sub modules:

  • Simple signal generation: Allows you to quickly generate a square signal with an adjustable frequency and duty cycle
  • Script signal generation: Allows you to generate virtually any kind of digital signals by writing a script in a dedicated window like in the image below:

digital signal generator script

 

This tutorial is dedicated to the process of generating signals using this script editor.

In order to generate “physically” some electrical signals on the probes of your logic analyzer, you need to follow 3 steps:

  1. Write the code to build the signals you wish to create
  2. Apply and visualize a preview of those built signals on the waveform viewer
  3. Send the freshly created signals to the logic analyzer device for actual generation of electrical signals

The base language used for scripting in ScanaStudio is JavaScript. If you have ever worked with C or Java programming languages, it should be very easy for you to grasp the idea. We recommend that you start by looking at example generator script that can be found next the “templates” button in the script editor window.

Minimal generator script
Before looking at the details generator script writing, let’s take a look at the main, indispensable parts of the code that must be present in any generator script. This will give you an idea of what to expect when writing your own script.

function build_signals() {
	add_samples(0,1,10);	//add 10 samples, on channel 0, having High level
	add_samples(0,0,10);	//add 10 samples, on channel 0, having Low level
}

As you can see in the example above, the script must contain a function called “build_signals()”. This function will be called by ScanaStudio to generate the script. A series of functions like “add_samples()” are exposed by ScanaStudio into the context of the JavaScript editor. Those functions are used by your code to build the signals. All those special pre-defined functions will be elaborated in this tutorial.


Device configuration & pattern duration

In order to get the most out of the signal generation, it is important to have a minimal understanding of the underlying processes related to it.

signal generator principle of operation

As you can see in the image above, the process of generating signals is tightly related to two parameters:

  • The sampling clock
  • The generator memory (where signals to be generated are stored).

Those two parameters will define crucial information like the maximum resolution and maximum length of the generated signal. That’s why, they are always visible at the bottom of the editor window. It is hence very important to  carefully configure your logic analyzer device to optimize the resolution versus the maximum length of the generated pattern.


Adding samples to build signals

The set of functions below are used to add signals to the ScanaStudio workspace. Note that any channel on which signals are build is totally erased before this process. (By erasing, we mean setting all the samples of that channel to 0).


add_samples(channel,level,s)

This function add some samples to a channel.
Parameters:
  • channel: The target channel where the samples will be be added
  • level: The logic level for those samples
  • s: The number of samples to add


add_cycle(channel,duty_cycle,samples)

This function adds a complete cycle composed of a high and low part.
Parameters:
  • channel: The target channel where the samples will be be added
  • duty_cycle: The duty cycle, a value between 0 and 1 (Ex: 0.2 for 20% duty cycle)
  • samples: The number of samples of the whole cycle. This also defines the period (and the frequency) of the cycle.


add_cycles(channel,duty_cycle,samples_per_cycle,cycles)

This function adds a certain number of cycles, each cycle is composed of the high and low part.
Parameters:
  • channel: The target channel where the samples will be be added
  • duty_cycle: The duty cycle, a value between 0 and 1 (Ex: 0.2 for 20% duty cycle)
  • samples_per_cycle: The number of samples for a whole cycle (the includes the low and high part of the cycle).
  • cycles: The total number of times to repeat this cycle.


add_inv_cycle(channel,duty_cycle,samples)

This function adds an inverted cycle. An inverted cycle starts by the low part then the high part of the wave.
Parameters:
  • channel: The target channel where the samples will be be added
  • duty_cycle: The duty cycle, a value between 0 and 1 (Ex: 0.2 for 20% duty cycle)
  • samples: The number of samples of the whole cycle. This also defines the period (and the frequency) of the cycle.


add_inv_cycles(channel,duty_cycle,samples_per_cycle,cycles)

This function adds a certain number of inverted cycles
Parameters:
  • channel: The target channel where the samples will be be added
  • duty_cycle: The duty cycle, a value between 0 and 1 (Ex: 0.2 for 20% duty cycle)
  • samples_per_cycle: The number of samples for a whole cycle (the includes the low and high part of the cycle).
  • cycles: The total number of times to repeat this cycle.


get_device_n_channels()

This functions returns the maximum number of channels supported by the actual device attached to the workspace.


get_sample_rate()

This function returns the sampling rate (in Hz) for the current device.


get_maximum_samples()

This function returns the maximum number of samples that the device can store it its generation memory.


get_device_name()

This function returns the name of the Logic Analyzer device attached to the workspace. This function can be useful if you wish to adapt your script depending on the type of device.


How to debug your code

In case your script is not behaving as expected, it is helpful to be able to output some data or some text from your script to help you debug your code. For that, we have added a function which simply appends some text to an “error log”. This error log is generally used to show some syntax errors in your code, but alternatively, it can also be used to append some information to that log. This function is described below:


add_to_err_log(txt)

This function appends some text to the error log. Note that the text will not be displayed in real time, it will only be displayed after you click on the “apply” button.
Parameters:
  • txt: The text, data, or object to be displayed. (Any argument type passed to this function will be converted to text).


Getting more help

If you need more help writing your signal generator script, all ikalogic team as well as other fellow users will be more than happy to assist you on ikalogic’s forum.

Custom Protocol Script

Content on this page applies to ScanaStudio V2.4 and above.


Introduction

With ScanaStudio 2.0, a completely revisited protocols decoders module was added. This module allows users to freely and easily customize existing decoder scripts or create new ones. This is done via simple JavaScript programs and does not require any external compiler. As of version 2.305, ScanaStudio includes an IDE for protocols decoders that features syntax highlighting, Auto-completion , visual GUI editor and live syntax checking. This is what we call the Protocols Manager:

decoder manager(The decoder manager can be invoked by going to Options menu, then Manage decoders.)

 As of version 2.4 of ScanaStudio, Protocol Scripts provide the following features:

  • Decoding logic signals and displaying decoded data on the waveform, in the Packet View or in the Hex View.
  • Generating demo signals that can be useful to test the decoder or to demonstrate the operation of a protocol decoder without having a Logic Analyzer device attached.
  • Generating trigger sequences, that allows a Logic Analyzer to trigger on a “protocol-specific condition” (like an I2C address for example).

Hence, this documents treats 3 distinct aspect of the protocol script:

  • Protocol decoder, also referred to as “decoder script”
  • Demo signal generator, also referred to as “demo signal builder”*
  • Trigger sequence generator.

Note that a decoder may not contain all 3 parts above. However, it must contain at least the core “protocol decoder” part.

We recommend that you start by looking at a decoder script for a protocol you are familiar with, and see how it is written. All supported and tested decoder scripts can be accessed via ScanaStudio software. (The full list of available protocols is here).

Minimal decoder script

Before getting into the details of writing a decoder script for ScanaStudio, let’s take a look at the main, indispensable parts of the code that must be present in any decoder script. This will give you an idea of what to expect when writing your own decoder script.

The process of creating a new decoder script goes though the following minimal steps:

  1. Designing the user interface of the decoder that will be used by final users to configure the decoder. The function that does that must be named “gui()”. It is autmatically created by the GUI editor, but you can always modify it manually later.
  2. Accessing the logic signals to be decoded from your script in a fast, easy and efficient way.
  3. Write the core of the decoder that will generate the decoder items to be displayed on the graph, as well as Packet View and Hex View elements. The function that does that must be named “decode()
  4. Provide some feedback for ScanaStudio to be able to show a progress bar in case your decoder script takes a dozen of seconds to execute.

The source code of a minimalist script is presented below:

/* The decoder name
*/
function get_dec_name()
{
    return "Minimal decoder (example)"; 
}

/* The decoder version 
*/
function get_dec_ver()
{
    return "1.0";
}

/* Author 
*/
function get_dec_auth()
{
    return "IKALOGIC";
}

/* Graphical user interface for this decoder
*/
function gui()
{
    ui_clear();        // clean up the User interface before drawing a new one.
    ui_add_ch_selector("ch", "Channel", "Channel legend");
}

function decode()
{
    get_ui_vals();                // Update the content of user interface variables
    clear_dec_items();            // Clears all the the decoder items and its content
    dec_item_new(ch, 0, 10000);    // add a new decoder box on channel 0    
}

Protocol decoder


Design the user interface of your protocol decoder

One very important step of designing a custom protocol decoder, is to provide a user interface for your decoder (like in the image below).

uart_cfg

This can be done by two methods:

  1. By writing the code that describes the GUI
  2. By using the visual – user friendly – GUI editor.

Designing the user interface using java-script functions

The following functions have to be written inside a function named “gui()”.


ui_clear()

Cleans up the user interface.


ui_add_ch_selector(id,caption,def_name)

Adds a combo box to chose a channel among a list of available channels.
Parameters:
  • id: unique code (character string) that can be used to read back the user’s choice
  • caption: The text to show next to the combo box.
  • def name: If you wish ScanaStudio to propose a new name for that channel, pass it here. E.g. for a CAN bus, you may want to propose “CAN” as the channel name. The user will be then asked if he wishes to use the channel name that you proposed in the script.


ui_add_txt_combo( id, caption)

Adds a combo box with text content (not pure numerical values)
Parameters:
  • id: unique code (character string) that can be used to read back the user’s choice
  • caption: The text to show next to the combo box.


ui_add_item_to_txt_combo( item_txt,def)

Adds a text element to the combo box that was last created with the function “ui_add_txt_combo”. This function can be called as much time as you need to add elements in a combo box.
Parameters:
  • item_txt: The text to be added (character string).
  • def: If this value is set to “True”, this item will be selected by default.


ui_add_num_combo( id, caption, n_start, n_end,def)

Addd a combo box with pure numerical values. The combo box will be populated with 1 element for each number between “n_start” and “n_end”.
Parameters:
  • id: unique code (character string) that can be used to read back the user’s choice
  • caption: The text to show next to the combo box.
  • n_start: The first number to add to the combo box.
  • n_end: The last number to add to the combo box.
  • Def: The number to be selected by default.


ui_add_baud_selector( id, caption,def)

Add text box for the user to input a baud rate or bit rate. Additionnaly, a button will be added to allow automatic baud rate detection.
Parameters:
  • id: unique code (character string) that can be used to read back the user’s choice
  • caption: The text to show next to the combo box.
  • def: The value to be displayed in the text box by default.

The function calls that create the user interface must be contained within the function called “gui()”, as this is the function that ScanaStudio will call to draw the user interface.

The following example demonstrate the “gui()” function for the UART decoder interface shown in the image above:

function gui() //graphical user interface
{
    ui_clear();    // clean up the User interface before drawing a new one.
    ui_add_ch_selector("ch","Channel to decode","UART");
    ui_add_baud_selector("baud","BAUD rate",9600);
    ui_add_num_combo("nbits","Bits per transfer",5,16,8);
    ui_add_txt_combo("parity","Parity bit");
        ui_add_item_to_txt_combo("No parity bit",true);
        ui_add_item_to_txt_combo("Odd parity bit"); 
        ui_add_item_to_txt_combo("Even parity bit");
    ui_add_txt_combo("stop","Stop bits bit");
        ui_add_item_to_txt_combo("1 stop bit",true);
        ui_add_item_to_txt_combo("1.5 stop bits");
        ui_add_item_to_txt_combo("2 stop bits");
    ui_add_txt_combo("order","Bit order");
        ui_add_item_to_txt_combo("LSB First",true);
        ui_add_item_to_txt_combo("MSB First");
    ui_add_txt_combo("invert","Inverted logic");
        ui_add_item_to_txt_combo("Non inverted logic",true);
        ui_add_item_to_txt_combo("Inverted logic");
}

Designing the user interface using visual GUI editor

To design the user interface using the visual editor, follow the steps below:

  1. Open the protocols manager, by going to Option > Manage Protocols
    dec_man
  2. Select an existing decoder and click “Edit selected decoder”, or simply click “Create new decoder” and chose a suitable name.
  3. In the decoder editor window, select “GUI editor” as in the image below:
    dec_gui
  4. The GUI editor window will then show up as in the image below. You can then drag and drop items from the right tool box to the central area:
    dec gui editor
  5. Each and every element in the GUI has an Object name, also called “ID”. That can be edited by double clicking on an element. For example, below is the properties of the first element in a UART decoder’s GUI, the “Channel selector”:dec_item_propThe object name is very important, as it’s the variable name that will be later used to retrieve the choice of the user. An object name is automatically added, but it’s wise to modify it to a name that has meaning to you when writing the decoder script.
  6. The properties window for each UI element can be invoked to change text labels, combo box contents, etc…

Once you’re done with the design of the user interface, you can switch back to the code editor, or you can click “generate GUI code”. In both cases, you will be redirected to the code editor, and you will be able to look at the generated GUI code and verify it.


Accessing data from decoder’s user interface

As it is explained in the section above, the “id” parameter (passed in the user interface creation functions), or the “Object name” (in the GUI editor) can be used directly in your java-script code as a variable. However, before accessing those variables, you must call the following function:

get_ui_vals();

This is typically done only once in your script before the first access to the UI variables. It will simply update the content of all users interface related variables.

For instance, if you create a “baud selector” item with the id “baud” using the following function:

ui_add_baud_selector("baud","BAUD rate",9600);

You can then access the value of the BAUD rate choosen by the user using the value “baud”. Ex:

get_ui_vals();
//...some other code...
if (baud == 9600)
{
    //the baud rate is 9600.
}
//...rest of your code...

The same applies for a GUI designed with the visual editor, the object’s name “baud” can be directly accessed within you java-script code.

The data relative to each type of user interface item is formatted as follows:

  • Channel selector: This variable contains the number of the channel that was selected (starting by 0 for CH1)
  • BAUD selector: This variable contains the baud rate (as a numerical value)
  • Text combo box: This variable contains the index of the selected element (starting by 0)
  • Numerical combo box: This variable contains the index of the selected element (starting by 0)

Available global variables

In addition to the variables defined in the user interface of your decoder, you also have access to those global variables over the whole javascript code:

  • sample_rate: This is a variable that contains the sample rate expressed in Hz. (The period of 1 sample = 1/sample_rate)
  • n_samples: This variable contains the total number of samples for a capture.

The main decoder function

The part of the decoder script that will actually access the logic signals and decode them must be contained in a function called “decode()”, as this is the function that will be called from ScanaStudio to update the decoded items. By definition, this is the most important part of your code. Example:

function decode() //don't rename this function!
{
    //...your own decoder script here...
}

Navigating through ScanaStudio’s logic signals:

The first step in learning how to write the core of the decoder scripts, is to understand how ScanaStudio stores the logic signals and how to read them within your decoder script.

ScanaStudio allows you to read the logic signals through “navigators”. There is a seperate navigator for each channel of the logic signals set. Each channel contains transitions, and each transition is characterized by two informations:
– The number of samples between the start of a capture and this transition.
– The value of the transition (0 means a falling edge. 1 Means a rising edge).

transitions

The “Transition” data type

Many function calls within this context will return a variable of type “Transition”. A Transition data type is a structure composed of two elements described via the example below :

var t = new transition(0,0); //create a new variable t of type "Transition"
var s = t.sample; //Access the sample number of that transition
var t = t.val; //Access the value of that transition (0 for falling edge, 1 for rising edge)

Navigating through transitions

There is one navigator for each channel. Each navigator allows you to navigate through the transitions of a channel via the following functions:


trs_get_first(k)

This function positions the navigator for the channel ‘k’ at the very first transition. It also initialises the navigator for that channel, and thus it is recommended to always call this function before atempting to navigate through the signals of any channel. This function returns the very first transition.
Parameters:
  • k: Channel


trs_is_not_last(k)

This function checks if the navigator for a channel is looking at the last transition. It returns true (1) if the navigator is not “looking” at the last transition, false (0) otherwise.
Parameters:
  • k: Channel


trs_go_before(k,target)

This function positions the navigator for a channel at the transition right before a target sample. This functions returns the transition right before the target sample number.
Parameters:
  • k: Channel
  • target: the sample number before which the navigator should look for a transition


trs_go_after(k,target)

Position the navigator for a channel at the transition right after a target sample. This function returns the transition right after the target sample.
Parameters:
  • k: Channel
  • target: the sample number before which the navigator should look for a transition


trs_get_next(k)

This function advances the navigator of a channel to the next transition.
Parameters:
  • k: Channel


trs_get_prev(k)

This function rewinds the navigator of a channel to the previous transition.
Parameters:
  • k: Channel


Optimize data access time

Often when desiging a protocol decoder script, one needs to repeatedly probe a data line at regular time interval in order to “build” a binary word. This is the case, for instance, in CAN and UART protocols. ScanaStudio exposes some functions specially made to facilitate the construction of binary data based on logic signals. They also allow much faster overall code operation.

A) Bit sampler (bits sperated by regular intervals)
The bit sampler is a set of two functions, used – as the name implies – to sample data lines at each bit position and return a value (0 or 1) depending on logic value. In order to use the bit sampler to build some binary data, you first need to initialize it via this function:


bit_sampler_ini(k,s_offset,increment)

This function initializes the bit sampler to perform bit sampling on channel “k”, starting from the actual position (plus an optional offset) and with a specific number of samples increment between each two bits.
Parameters:
  • k: Channel
  • s_offset: The number of samples to add to the actual navigator position in order to reach the position of the first bit
  • increment: The number of samples between every two bits.


bit_sampler_next(k)

This function returns the next bit’s value. The function “ini_bit_sampler()” must be called at least once before using this function. The first call of this function after initializing the bit sampler returns the first bit value (0 or 1) in a sequence of bits.
Parameters:
  • k: Channel

The following diagram shows a typical use case of the bit sampler feature. As an example, let’s imagine we are to decode a serial packet (the famous UART). As soon as we catch a falling edge (a transition whose value = 0) using our navigator, we can initialize the bit sampler to start sampling bits with increment of 1 bit between each two bits. We will also add a starting offset of 0.5 bit, to make sure we sample each bit exactly at the middle of it. Of course, the increment and offset are to be expressed as ‘n’ samples. (Example: 1 bit = 5000 samples, 0.5 bit = 2500 samples. This is just an example, exact relation between bit time and number of samples depends on UART bit rate, and sampling rate.)

bit_sampler

B) Access bit values at arbitrary position (no regular intervals between bits)
Sometimes bits of a digital word are not seperated by regular time interval, in that case, the following function will still provide very fast bit value access:


sample_val(k,sample)

This function returns the logic value of a sample number for a specific channel. For the “sample_val” function to work properly, the function “trs_get_first(k)” must have been called at least once in order to initialize the navigator for that channel.
Parameters:
  • k: Channel
  • sample: The sample for which the function should return the value.

Note: It is recommended to use the function “sample_val(k,sample)” in an incrementing chronological order. This will highly optimize the execution time of this function, as it will prevent the navigator from searching through transition back and forth.


Adding decoder items to be displayed on the graph

The image below shows a working CAN bus decoder displaying the decoded bits and bytes of the data.

dec_items

As you can notice, there are some terms used to describe the items being displayed on the graph:

  • A decoder item is a box anchored to the graph and having a specific width. The position and width of decoder item are defined by a “start sample” and an “end sample”. The decoder item is the container in which any other data, drawing or text can be appended.
  • A data is a data word to be displayed in the decoder item. It can be composed of any number of bytes. The decoder script should not worry about the display format (Hex, Decimal, Binary, etc..) as this is handeled by ScanaStudio.
  • A pre-text is a text that is appended before the data to be displayed.
  • A post-text is a text that is appended after the data to be displayed.
  • A sample point is a drawing that is shown when the mouse passes over a decoder item. Typically, this can be used to display when data is actually sampled, thus, helping the user to identify why some data have some specific value.

The principle base is that you create a decoder item, then add content to it, whether it is data or text. All those features and the realted functions are explained in detail in the following section.


clear_dec_items()

This function clears all the decoder items and its content.


dec_item_new( k, start_sample, end_sample)

This function adds a new decoder item.
Parameters:
  • k: Channel to add the decoder item onto.
  • start_sample: The anchor point for the left of the item’s box.
  • stop_sample: The anchor point for the right of the item’s box.


dec_item_add_pre_text( pre_txt)

This function adds (appends) some “pre-text” to the decoder item that was last created using the function “dec_item_new”. This function can be called multiple times to add texts of different sizes. ScanaStudio will then pick the most suitable text according to the zoom level.

Ex: If you call the following functions:

dec_item_add_pre_text( “DATA FIELD ”)
dec_item_add_pre_text( “DATA ”)
dec_item_add_pre_text( “D ”)

Then ScanaStudio will show the biggest of those three character strings that can fit in the decoder item (depending on the zoom level).


dec_item_add_data( data)

This function adds some numerical data to the decoder item that was last created using the function “dec_item_new”. This function can be called various times to add multiple data words for the same decoder item.


dec_item_add_post_text( post_txt)

This function is similar to “dec_item_add_pre_text” with the exception that it will add the text after the data.
Parameters:
  • post_text: The text to be added


dec_item_add_comment( comment)

This function adds a comment that will be displayed when the mouse passes over the decoder item.
Parameters:
  • comment: The text to be displayed on mouse hover.


dec_item_add_sample_point(k,sample,drawing)

This function adds a small drawing to show the sampling point on the logic signals. There are variables already defined in the decoder’s script context that cover the different types of drawings. Those variables are defined in this table:

ValueDrawingDescription
DRAW_00Draw a small logic 1 symbol
DRAW_11Draw a small logic 0 symbol
DRAW_POINTpointDraw a point
DRAW_SEPsepDraw a vertical separator
DRAW_CROSScrossDraw a cross
DRAW_ARROW_TOParrow_topDraw a arrow pointing to the top
DRAW_ARROW_BOTarrow_downDraw a arrow pointing to the bottom
DRAW_ARROW_RIGHTarrow_rightDraw a arrow pointing to the right
DRAW_ARROW_LEFTarrow_leftDraw a arrow pointing to the left
Parameters:
  • k: The channel to add the sampling point to.
  • sample: The sample to anchor the drawing to.
  • drawing: The type of drawing (one value from the table above)

Important note: You must create a new decoder item (using the function “dec_item_new” before adding any data, pre-text or post text to it. The only exception to this rule is the “dec_item_add_sample_point” function, which can be called anywhere in the code without any constrains.


Adding decoder items to be displayed on the “Packet View”

The packet view is a great feature of ScanaStudio. It lets you present decoded data as a neatly organised and colorful set of packets and sub packets.

Before we get into how to create packets, let’s first get familiar with some vocabulary.
packet structureBefore we get into the details of the functions used to create packets or sub packets, let’s take a look at a simple java-script code to create a packet and a sub packet:

pkt_start("parent packet");
  pkt_add_item(start_sample,end_sample,"item 1",content,tc,cc,0);
  pkt_add_item(start_sample,end_sample,"item 2 with sub packet",content,tc,cc,0);
    pkt_start("sub packet");
        pkt_add_item(start_sample,end_sample,"child item 1",content,tc,cc,1);
        pkt_add_item(start_sample,end_sample,"child item 2",content,tc,cc,1);
    pkt_end();
  pkt_add_item(start_sample,end_sample,"item 2",content,tc,cc,1);
pkt_end();

The code above adds a main packet with 3 items. Item 2 has a sub packet with 2 items. Each item in a packet or sub packet can have a title, a content or both. As you can see in the example above, each packet is encapsulated with a pkt_start() and a pkt_en(). A call to pkt_start() within another packets creates a sub packet.

A packet or a sub packet is created with the functions below:


pkt_start(name)

This function starts a new packet (or a sub packet if a previous call to pkt_start() was not terminated with a pkt_end()).
Parameters:
  • name: A name for that packet or sub packet.


pkt_end()

This function marks the end of a packet.

pkt_add_item(start_sample,end_sample,title,content,tc,cc,title_no_wrap)

This function adds a new item to a packet or sub packet that was created with the function pkt_start().
Parameters:
  • start_sample,end_sample: If you wish to “link” that packet to a part of the waveform, put significant values here. Then, if a user clicks on that packet, he will be directed to the corresponding parts on the graph. This can be useful to quickly check the underlying signals behind a specific packet. If you don’t wish to use this feature, just put “-1” for each of start_sample and end_sample.
  • title: Some text and or numerical values to be used as title (upper part of the packet item, check the image above).
  • content: Some text and or numerical values to be used as the content of a packet item.
  • tc,cc: Respectively title color and content color . This will define the background color of the upper and lower part of a packet item. The foreground (text color) will either be white or black and is automatically determined to ensure best contrast. the parameter “tc” or “cc” is an object structure having 3 elements: ‘r’,’g’ and ‘b’ for respectively Red, Greed and Blue .

    title_no_wrap: Put this variable to 1 if you want to ensure that no text wrapping occurs on packet item’s title.

More about packet items colors

The color parameter is given as a java-script object (or structure, from a c/c++ point of view). This object has 3 properties:

  • r : Red component of the color
  • g : Green component of the color
  • b : Blue component of the color

Here is a sample code to create a color variable:

var color;
color.r = 0x25;
color.g = 0;
color.b = 0x10;

You can also access the color of a particular channel (as it was set by the user) using the function below:


get_ch_color(k)

This function returns the color information of a channel
Parameters:
  • k: the number of the channel, starting by 0 for the first channel.

Here is an example usage of the function “get_ch_color()”; a function that provides a “lighter” version of the channel color, by blending it with some white:

function get_ch_light_color (k)
{
    var chColor = get_ch_color(k);
    chColor.r = (chColor.r * 1 + 255 * 3) / 4;
    chColor.g = (chColor.g * 1 + 255 * 3) / 4;
    chColor.b = (chColor.b * 1 + 255 * 3) / 4;

    return chColor;
}

Additionally, within the context of ScanaStudio, you can access the following two global variables (objects):

  • dark_color
  • light_color

Each one of those objects have the following properties:

  • gray
  • pink
  • red
  • green
  • yellow
  • orange
  • brown
  • violet
  • blue
  • black

for instant, if you wish to use a light blue color, you can simply use the variable: “light_colors.blue”.


Give feedback to ScanaStudio about decoding progress

For some coders (and depending on the quantity of data that need to be decoded), the process can take dozens of seconds. This is not very long, but long enough to make the user feel that the decoder is frozen. To prevent this you can (and you should) provide some feedback to ScanaStudio about the progress percentage of your decoder script. This is done using the following function:


set_progress(p)

This function sets the progress value for the decoder script. This value will then be used by ScanaStudio to draw a progress bar.
Parameters:
  • p: A value between 0 and 100 indicating the progress percentage.

A typical usage of this function is shown in this example:

set_progress(100*t.sample/n_samples); //Gives a number between 0 and 100

In this example, we assume that the object “t” contains the last transition reached by the decoder. “n_samples” is a global variable defined by ScanaStudio that contains the total number of samples.


Allow the user to abort a decoder script

In case a decoder script is taking too much time to execute, the user should be able to abort it. To know if the user requested an abortion of the script execution, you should regularly call this function:


abort_requested()

This function return “True” if the user requested to abort the decoding.


How to debug your code

In case your decoder is not behaving as expected, it is helpful to be able to output some data or some text from your script to help you to debug your code. For that, we have added a function which simply appends some text to a “log”. To use this log, just use this function in your code:


debug(txt,sample)

This function appends some text to the debug log.
Parameters:
  • txt: The text, data, or object to be displayed. (Any argument type passed to this function will be converted to text).
  • sample: Optional argument to link this debug entry to a sample. If a sample number is provided, the line of text will be displayed as a link in the log. If you click on one of those links, it will take you to the linked sample (in the waveform window)

Here is an example of the decoder log window:

decoder_log

This window also allows you to refresh the decoder by clicking on the icon.

If you accidentally close this window, you can open it again by going to : “Workspace > Show decoder log”.


Writing a high level protocol decoder, based on lower level decoders

There are many cases where you’ll want to write a specific protocol decoder / interpreter that will be based on a lower level decoder. For Example, if you’re writing a decoder for a specific kind of I2C temperature and humidity sensor, you don’t want to re-write the whole I2C decoder before getting into the specifics of the temperature and humidity sensor.

For that purpose of building a decoder as a layer above another one, we have created the function “pre_decode()”. What this function does is that it will run an existing decoder and provide the decoded data as an array.

sub decoder

As shown in the image above, the principle of operation is that a high level decoder calls a lower level decoder. Since the lower level decoder can’t show any GUI in that mode of operation, higher level decoder has to provide UI interface variables. Hence, higher level GUI provides information for both low and high levels decoding.


pre_decode(sub_decoder_name,ui_var_list)

This function returns an array of objects containing all the information about the decoded data.
Parameters:
  • sub_decoder_name: name of the low level decoder, ex: “i2c.js”
  • ui_var_list: a character string listing all the user interface (UI) variables name and their assigned values, separated by semicolon. The UI variable names here are those of the GUI function of the low level decoder. Ex: “chSda = ” + ch_1 + “;” + “chScl = ” + ch_2+ “;” + “adrShow = 1 ; ” + “hexView = ” + “3;”

Once pre_decoder function is called, it will return an array where all decoded items can be found. Example, If we call the pre_decoder function:

data = pre_decode(sub_decoder_name,ui_var_list);

Then we can access the following objects:

  • data.size: The total number of elements
  • data(n).start_s : stat sample for n’th element
  • data(n).end_s : end sample for the n’th element
  • data(n).pre_text : pre-text for the n_th element
  • data(n).post_text : post-text for the n’th element
  • data(n).data : array containing 1 or more data words.
  • data(n).k : channel to which the n’th element is attached.

A practical example of using pre_decode() function is the 1-Wire temperature sensors decoder. Here, the existing 1-wire decoder is just used to decode the “low level” 1-Wire signals:

decBuf = pre_decode("1wire.js", "uiCh = " + uiCh + ";" + "uiSpeed = " + uiSpeed + ";" + "uiHexView = " + 3);

the array “decBuf” is then used to access all decoded items.


Generating demo signals

The ability to generate demo signals from within the protocol script is very useful for two reasons:

  1. Thoroughly testing your decoder without having to actually capture real life signals. When you write a decoder, you want to be sure it will work under all circumstances, but often you can’t get hold of an electronic circuit that generates “all possible special cases” of a decoder. The demo signal builder helps you get past this limitation, by generating a complete test pattern, without having to connect a logic analyzer at all.
  2. Demonstrate the operation of the decoder. Often a user will want to try the operation of ScanaStudio software and its associated decoders. Demo signal builder allows a user to evaluate the protocol decoder part easily and in controlled conditions.

In order to implement this feature in a protocol script, a function called build_demo_signals() needs to be added to your script. This function will be called by ScanaStudio whenever demo signals need to be generated.

Before moving forward, let’s look at a minimalist demo signal builder script:

/* Main demo signal builder function
*/
function build_demo_signals()
{
    add_samples(0,1,100); //add 100 logic '1' samples on channel 0
    add_samples(0,0,100); //add 100 logic '0' samples on channel 0
}

The example above simply generates a single square wave, having a period of 200 samples. When the function is executed by ScanaStudio, the content of channel 0 will be erased before before new samples are generated. This is – by the way – a working example that you can try yourself.

Available global variable

When generating demo signals, one needs to access relevant information like:

  • Protocol configuration variables (e.g.: UART’s BAUD rate and channel)
  • Workspace and device related variables (e.g. sampling frequency, maximum sampling depth, etc…)

Protocol configuration variables

All user interface items are accessible exactly as in the protocol decoder part of this manual. As a reminder, let’s take the classic UART example below:

function gui() //graphical user interface
{
    ui_clear();    // clean up the User interface before drawing a new one.
    ui_add_ch_selector("ch","Channel to decode","UART");
    ui_add_baud_selector("baud","BAUD rate",9600);
}

You can access the value the selected channel using the global variable “ch”, as well as the user chosen BAUD rate using the global variable “baud”.
write in progress…

Workspace and device related variables

  • The current sampling rate (expressed in Hz) can be retrieved anytime by calling the predefined function “get_sample_rate()
  • The sampling depth (maximum numbers of samples) is available as a global variable called “n_samples

The example code below show how they are accessed and used:

var sample_r = get_sample_rate();
samples_per_bit = sample_r / baud;

var demo_length = n_samples / sample_r; //total demo signal length in seconds.

Constructing demo signals

A set of predefined functions are exposed by ScanaStudio to the script context to allow construction of signals.

 The functions used to construct demo signals are all listed and explained in detail in this page.

However, the most useful function that is most often used to generate demo signal, is the “add_samples()” function:


add_samples(channel,level,s)

This function add some samples to a channel.
Parameters:
  • channel: The target channel where the samples will be be added
  • level: The logic level for those samples
  • s: The number of samples to add


Protocol based trigger

Introduction

As of ScanaStudio v2.4, it is possible to trigger on virtually any arbitrary logic sequence. this, of course, is mainly used to allow triggering on a specific protocol feature (like an I2C address or an UART data frame).

Please note that Protocol Based Trigger is not supported by all Logic Analyzer devices.

The main idea behind protocol based trigger, is a method of describing virtually any logic sequence in way that can be transferred to an embedded controller (like a micro controller or an FPGA) that will handle the precise task of triggering the capture at the right instant. That being said, all the sophisticated and complicated parts of the protocol based trigger are totally transparent to the user or the protocol script writer (you).

To sum up, the only thing you need to do in order to build a functional protocol based trigger, is to be able to describe correctly your trigger sequence.

Let’s a take a short simple example: We are using a 4 channels logic analyzer, and we want to trigger when a “start” condition is detected on I2C lines. Let’s assume the I2C lines are connected as follows:

  • SCL on CH1
  • SDA on CH2

i2c_start

As you can see on the capture above, the start condition is defined as a falling edge on the SDA line, while the SCL line is at a logic ‘1’ level. In the “language” of  ScanaStudio, this can be translated as character string “XXF1”. Each character describes a channel, so for a 4 channels logic analyzer, we have 4 character:

  • The X means “don’t care”
  • The F means falling edge
  • The 1 means a logic level ‘1’.

Reading it again, you should be able to see how “XXF1” describes a falling edge on CH2 while CH1 is logic-high.

Trigger sequence generator example

Before we get more into details, let’s look at a complete source code for a protocol based trigger that – as in the example above – trigger on an I2C start condition;

function trig_seq_gen() //This function is called by ScanaStudio
{
     flexitrig_clear();
     flexitrig_append("XXF1",-1,-1);
}

The function called trig_seq_gen() must be present in your code. That’s the function that ScanaStudio will call in your script just before a new capture is requested by the user.

The function “flexitrig_clear()” is used to clear any previous list of trigger sequence steps.

The function “flexitrig_append()” is used to append a new trigger sequence step. The parameters are :

  • “XXF1” : The trigger step description, as defined above
  • -1,-1 : The minimum and maximum time constrains. -1 means no time constrains are used at all, so let’s ignore that for now for the sake of simplicity.

 What’s FlexiTrig? FlexiTrig is the name of Ikalogic’s proprietary flexible trigger sequence, that allows complex trigger sequence to be described to a hardware device.

Basic principle of operation

Protocol based trigger was designed and integrated into ScanaStudio, with a specific usage in mind. It’s important to understand how should your trigger generator script integrates with ScanaStudio’s ecosystem.

Blank Flowchart - New Page (1)

As you can see in the diagram above, the trigger sequence generator get its input from both the decoder GUI as well as the trigger GUI. Based on that input, it then generates a trigger sequence, which will then be transferred to the logic analyzer device.

The decoder GUI, is the GUI that have been discussed various times in that document, it allows a user to configure the BAUD rate of a UART decoder for example. The Trigger GUI, is a new GUI, that is solely used to define the exact trigger condition for a specific decoder. If we keep the I2C example, that could be a combo box to offer the use a choice to:

  • Trigger on an I2C start condition
  • Trigger on an I2C stop condition

With data gathered from both GUI, as well as some data gathered from the workspace (like the number of channels of the logic analyzer device), the trig_seq_gen() function can generate the correct trigger sequence.

Trigger Sequence definition

A trigger sequence is composed of steps. Each step describes the state of one or more channels. In order for a logic analyzer to trigger, all the steps must be validated, one after the other.

For example, if a trigger sequence is composed of the following 2 steps:

  • Rising edge on channel 1
  • Rising edge on channel 2

Then, the logic analyzer device will only trigger when A rising edge on channel 1 have been followed by a rising edge on channel 2.

Each trigger step contains the following information:

  • The state on each channel (Rising edge, Low level, don’t care, etc..).
  • The minimum and maximum time elapsed since the last step.

Channel state definition for a trigger step

A character string is used to define the state of the channels for a single step. For example, a trigger step for a 9 channels Logic Analyzer can be defined as “XXXXXXXXXR”. The character string means a step with a rising edge on channels 1.

The full list of characters that can be used to describe the state of any channels is as the following:

CharacterMeaning for ScanaStudio
RRising Edge
FFalling Edge
0Low Level
1High Level
XDon't care

Please note that a single step may only have one edge (rising or falling).

Time constrains between two trigger steps

In addition to the channel state definition, it is also possible to time-constrain a trigger step with respect to the previous step. What that means is that for a trigger step to be validated, the channels has to have the right value at the right time.

A timing constrain can only exist between two steps that have “edge” states. For example, a timing constrain can exist between a falling and a rising edge, but cannot exist between a “low level” and a “high level”.

Below is a classic UART packet where the character ‘h’ is transmitted. If you wish to trigger on this UART character, the trigger sequence must define minimum and maximum time between edges. It is very important to define different timings for the “minimum” and “maximum”, because there are always time uncertainty that has to be respected. In other words, with the timing constrain we define a timing window in which a transition has to fall.

uart packet

In some cases, only the maximum or minimum time time need to be defined. Take for example the 1-Wire bus below and let’s assume you wish to trigger when a presence pulse is detected. Normally, a 1-Wire slave must acknowledge its presence within a predefined time after the end of the RESET pulse. To detect a presence pulse, we only care about the maximum time between the reset pulse and the presence pulse.

1wire bus

So, to recap, if we were to define 3 trigger steps to detect that condition, we could write them as:

Step NumberStep Description Minimum time Maximum time
1XFXX-1-1
1XRXX400e-6500e-6
1XFXX-1500e-6

As you can see, the second edge is defined to fall 400 to 500 µs after the first edge. The last falling edge, however, is only time-constrained with a maximum time, since -1 for the minimum time means it’s ignored.

The very first trigger step cannot have any timing constrain.

Asynchronous VS Synchronous protocols

For Flexitrig system to operate correctly, it is important to specify if the protocol is synchronous or asynchronous. Synchronous protocols usually have a clock signal like SPI, I2C and JTAG. Asynchronous protocols do not have any clock or synchronization signal, like UART, USB, CAN and LIN.

By default, ScanaStudio will handle any trigger sequence as an synchronous one. If your protocol is asynchronous, you should let ScanaStudio know about it by calling the function “flexitrig_set_async_mode(true)“. This function only need to be called once, pereferably at the begining of the “trig_seq_gen()” function.

Protocol Trigger GUI

In addition to the decoder GUI, protocol based trigger needs a secondary GUI, which is used to define when exactly should the logic analyzer device trigger. The design of a trigger GUI totally depends on the protocol used, however, some common rules apply:

  • A decoder GUI is divided into several “trigger alternatives”. Each trigger alternative is considered as a independent GUI on its own. Only one trigger alternative can be selected by a user.
  • Each trigger alternative can contain classic GUI elements (like check boxes, combo boxes, text field, etc..)

The source code that “builds” this GUI must be contained in a function called: trig_gui(). The name of this function must not be changed, since ScanaStudio will call this function when needed.

Before we get into details, let’s take (again) the example of UART. A UART based trigger may have 2 alternatives:

 

AlternativeDescriptionGUI content
Trigger on any FrameAllows trigger on a UART start bit  –  
Trigger on a specific FrameAllows a device to trigger on a specific byte valueA text field where the user can enter the byte value to be used for trigger

Below screen shot shows how this UART Trigger GUI may look like:

uart trigger

And below is the source code of the trig_gui() function that created that GUI. To make the example more exhaustive, a sample “trig_seq_gen()” function that makes use of that GUI is also added.

function trig_gui()
{
	trig_ui_clear();
	trig_ui_add_alternative("ALT_ANY_FRAME","Trigger on a any frame",false);
		trig_ui_add_label("label0","Trigger on any UART Frame. ");
	trig_ui_add_alternative("ALT_SPECIFIC","Trigger on byte value",true);
		trig_ui_add_label("label1","Type decimal value (65) or Hex value (0x41)");
		trig_ui_add_free_text("trig_byte","Trigger byte: ");
}
function trig_seq_gen()
{
	if (ALT_ANY_FRAME == true)
	{
		//code to generate 1st alternative trigger sequence
	}
	else if (ALT_SPECIFIC == true)
	{
		//code to generate 2nd alternative trigger sequence
	}
}

Trigger GUI functions


trig_ui_clear

This functions cleans up the trigger GUI.


trig_ui_add_alternative(id, caption, checked)

Adds a new trigger alternative. The Trigger GUI script must at least contain one occurrence of this function (a script must contain at least one alternative). This function call also separates the GUI items of two alternatives: All the GUI items created after a call to “trig_ui_add_alternative” belongs to that alternative.
Parameters:
  • id: unique ID for that GUI element. The value of ID will be “True” for the active alternative (the one selected by the user)
  • caption: A short text description of that alternative.
  • checked: set to “True” if you wish the check box to be checked by default, “False” otherwise.


trig_ui_add_free_text(id,caption,default)

Adds a text box that allows the user to type any text (numbers or characters).
Parameters:
  • id: unique ID for that GUI element.
  • caption: A text displayed next to the text box
  • default: The default text displayed inside the text box. May be left empty.


trig_ui_add_num_text(id, caption, def)

Add a text box that allows only numerical values to be typed.
Parameters:
  • id: unique ID for that GUI element.
  • caption: A text displayed next to the text box
  • default: The default text displayed inside the text box. May be left empty.


trig_ui_add_combo(id, caption)

Adds a combo box. After adding a combo box, elements can be added using the function trig_ui_add_item_to_combo(). The index of the selected item stored in the global variable “id” (id is to be replaced by the given unique ID).
Parameters:
  • id: unique ID for that GUI element.
  • caption: A text displayed next to the combo box


trig_ui_add_item_to_combo(item_txt, def)

Adds a new element (item) the last created combo box.
Parameters:
  • item_txt: Text caption of that new element.
  • def: set to “True” for the line you wish to be selected by default. Other lines should be set to False.


trig_ui_add_check_box(id, caption, checked)

Adds a check box. The global variable “id” will contain “True” or “False” depending whether the box is checked or not.
Parameters:
  • id: unique ID for that GUI element.
  • caption: A text displayed next to the check box
  • checked: set to “True” if you wish the check box to be checked by default, “False” otherwise.
  • [/fn_params

    [fn_block f= "trig_ui_add_label(id, caption)"] Adds a label. Usually used to display information text. This GUI element can’t be modified by the user.:

  • [fn_params]:
  • id: unique ID for that GUI element.
  • caption: The actual content of the label.


trig_ui_add_serparator()

Adds a horizontal separation line. Only used to visually separate different parts of the GUI.

Trigger sequence generator script

As stated earlier in this document, the main function that needs to be implemented for the protocol based trigger to function is called “trig_seq_gen()”. The name of this function must not be changed, since ScanaStudio will call this function when needed.

In it’s simplest form, a trigger generator script may only contain 3 functions:


flexitrig_clear()

This function simply cleans up an previously defined trigger steps.


flexitrig_append(step_description, t_min, t_max)

Appends a new trigger step. If time constrains are applied, please note that the constrains are applicable between two consecutive edges (rising or falling).  It’s possible to constrain the time between two different edges of the same polarity (e.g. two rising edges).
Parameters:
  • step_description: A character string whose length equals the number of channels of the actual workspace. Each character describes the state of a channel. refer to previous sections for more details.
  • t_min: the minimum time between this step and the previous one, expressed in seconds. Set to -1 if you don’t wish to use this feature.
  • t_max: the maximum time between this step and the previous one, expressed in seconds. Set to -1 if you don’t wish to use this feature.


flexitrig_set_summary_text(txt)

Defines a short (50 characters) text to describe current trigger. Ex: “Trigger on UART byte 0x41”. This text is then displayed on the workspace (in the device configuration panel) to give to the user a quick preview of the currently configured trigger.
Parameters:
  • txt: a short text to describe current trigger configuration.

Available global variables

As with other aspects of protocol script (like the decoder or the demo builder), ScanaStudio exposes a number of global variables and functions that can be used within the script. Those variables are very important to be able to build precise trigger sequence.

Workspace and device variables

  • The current sampling rate (expressed in Hz) can be retrieved anytime by calling the predefined function “get_sample_rate()
  • The sampling depth (maximum numbers of samples) is available as a global variable called “n_samples

The example code below show how they are accessed and used:

var sample_r = get_sample_rate();
samples_per_bit = sample_r / baud;

var demo_length = n_samples / sample_r; //total demo signal length in seconds.

GUI variables

The GUI variables are accessible as global variables. the “id” parameter that was used when creating the user interface is the variable name.
In order to be sure that the variables content is updated with latest user choices in the GUI, you should always call the function get_ui_vals() before using the variables.
Refer to the GUI construction section of this document for more details on how to use the GUI data (that reflects different user choices).

Debugging your trigger sequence generator

When designing a trigger sequence for a protocol, it is helpful to be able to test and debug your code. For that reason, the function “flexitrig_print_steps()” have been created:


flexitrig_print_steps()

This function causes the trigger sequence generator to print the trigger sequence in a message box, when called by ScanaStudio. This function is usually put at the end of the main trig_seq_gen() function. More precisely, when you open the flexitrig configuration window in a specific workspace, select your decoder as a trigger source and click “ok”, the list of all the trigger steps created by your script will be printed. An example is given in the image below:

trigger-protocol-debug-compressor

 


Getting more help

If you need more help building your decoder script, all ikalogic team as well as other fellow users will be more than happy to assist you on ikalogic’s Questions & Answers section.

Why we don’t use a logic analyzer probe to capture analog waveforms

Mixed signal oscilloscopes or MSO’s, scopes that integrate a Logic Analyzer,  have been around around for ages. They are undoubtedly super useful pieces of equipment for any electronics engineer (or even hobbyists!). However, recently some firms started releasing Logic analyzers that support analog capturing. In this article, I’ll be explaining why we don’t think it’s a good idea.

Disclaimer: Before I continue, let me stress on the fact that I believe the companies releasing such devices are very respectful and respected competitors, i am just informing our position on the subject, to whom it may concern!

So, to put things simply, we think that a logic analyzer whose probes can be used to capture both analog and digital signals would end up being a toy, an expensive one, but not a reliable measurement device. Here’s why:

Sampling rate is not bandwidth

Look carefully at the analog sampling rate of that analog-capable logic analyzer. Chances are it will be below 100 MSPS (million samples per second). This may be due to hardware or economic limitations. What ever the reason is, 100 MSPS is not even close to what you’re used to have on a classic low cost Scope.

With a sampling rate of 100 MSPS, you can only start to clearly see analog signals having a frequency of 5 MHz (like a square wave clock signal). With a sampling rate of 10 MHz, don’t expect to reliably capture any analog signals having a frequency higher than 500 KHz. This, is in many cases, makes such a device, well… useless.

What that means is that you would get a half-baked scope-like features that can’t compete with the lowest cost Rigol scope on today’s market! We don’t want to offer you that! not even for free!

Logic Analyzer probes are not oscilloscope probes

If you are info electronics in a way or another, you would probably recognize in a glance what’s in the picture below. Good old oscilloscope probes! (and the tektronix scope laying on my desk, by the way!).

27516067_s

Oscilloscope probes may have evolved a lot during past decades, but some of it’s mains characteristics remain:

  • They are shielded
  • They have very low inductance
  • They are compensated for their stray capacitance
  • They have attenuators that further decrease their loading on the circuit.

I could write a lot about each and every one of those features, but the bottom line is: those probes will capture very low voltage signals with high degree of fidelity, without impacting the operation of the measured circuit.

Again, what that means, is that logic analyzer probes cannot be used to measure analog signals. Those probes are quite susceptible to transient noise.

A Scope, a Data Logger or a Logic Analyzer

You can’t have those three features in one low cost device. Even if you would find such a device, would you really want it? Those three kinds of devices exist independently for a reason. If there is no reason to have those devices combined “all-in-one”, then you’ll be better off using each device independently.

  • An oscilloscope’s design is optimized to collect a small amount of data but at a very high refresh rate
  • A Logic analyzer is optimized to capture a important amount of data while performing real time or near real time processing and decoding of the data.
  • A Data logger is designed to capture huge amount of brute data without any real time analysis or processing. Data may be analysed after being collected.

As you can see each device is optimized in such a way to give you maximum usability for specific applications, and that’s why we are careful when combining multiple functions in one device.

OLYMPUS DIGITAL CAMERA

 

New USB, JTAG and SENT protocols decoders!
posted by: in Ikalogic News

Dear hobbyists, fellow electronics engineers and all users of our Logic Analyzers,

First let me wish you all the best for 2015!

I am happy to announce that we have some new protocols decoders in our growing repository!

Among these, there is the – long awaited – USB decoder:

usb decoder screen shot

It can decode both low speed and full speed USB protocols. As you can see in the image above, it’ll present the decoded data in a nice “packet view” window.

Similarly, the JTAG decoder will also present decoded data using the packet view:

jtag decoder screenshot

The JTAG decoder can be configured to suit your needs using the configuration windows :

jtag configuration

Most importantly, the “data organisation” parameter will allow you to group the data into 8, 16 or 32 bit words. This can be very useful when – for example – you’re using a JTAG probe that reads or write MCU firmware in words of 32 bits (which is very often the case).

Finally, a Single Edge Nibble Transmission (SENT) decoder according to SAE2716 Jan 2010 was written by Volker Oth [forum username: 0xdeadbeef] and we thank him for his contribution!

SEND protocol decoder screenshot

The protocol decoder is very professionally written, does CRC verification and supports the packet view to provide a nice colorful view of the data packets.

 

 

 

nRF24L01 debugging: Piece of cake!
posted by: in Ikalogic News

Working with the famous nRF24l01 2.4GHz transceiver? Debugging will be much easier with a logic analyzer and our newly added dedicated nRF24L01 protocol interpreter.

The nRF24L01 decoders directly shows meaningful command names on the logic signals:

nrf_signals-compressor

Want to get a nice, colored, datasheet-like and intuitive representation of the data being transferred? the Packet View will give you just that:

nrf_packet-compressor

Hopefully, from now on, this decoder will help you whenever you’re working with Nordic Semiconductor transceivers!

ScanaStudio: New decoders for MIDI and I2C Humidity sensors
posted by: in Ikalogic News

Recently we have added to our growing list of decoders the following two items:

  • MIDI protocol decoder
  • I2C Temperature and humidity sensors decoder

Hopefully, this will boost your productivity if you happen to use those in your projects.

The Midi decoder can interpret almost all commands that we’re aware of, and will even interpret the names of the manufacturers, like in the example below:

midi-decoder-compressor

The decoder have been designed with a MIDI specialist so it’s presented in the best possible way.

The I2C Temperature and humidity sensors have been developed since we worked with this kind of sensors for internal projects. We though a decoder could be useful so we did it! As you can see on the image below, the decoder will interpret the bitmap of the internal register of the I2C sensor.

i2c_temp_rh_sensor-compressor

That temperature and relative humidity sensor decoder should work with the following parts: SHT20, SHT21, SHT25, STS21, HTU21A, HTU20D, HTU21D, HTU_3800, Si7006_A10, Si7020_A10, Si7021_A10, Si7013_A10.

If you need any other deocoder added to our list of protocol decoders, don’t hesitate to contact us!

Introducing Bus View for ScanaStudio
posted by: in Ikalogic News

Scanastudio V2.304 have been out for a couple of days now, and I didn’t get the time to properly highlight its top features, like the “Bus View”

As the name implies, Bus View allows you to look at parallel data lines captured with your logic analyzer as a “bus”.

busview3-compressor
(more…)

ScanaStudio for Mac OS X
posted by: in Ikalogic News

Well, the title says it all. We’ve just released a native version of ScanaStudio for Mac OS X.  As of version 2.303.000 of ScanaStudio, we will be providing full support and updates for the 3 major platforms: Linux, Mac and Windows. Now you can use any of our logic analyzers on your preferred OS. No need for virtual machines or parallel desktops…

You can download the latest release of ScanaStudio on this page: https://www.ikalogic.com/ikalogic-products/scanastudio-2/. Just pick your OS, and you’re ready to go.

Sniffing CMOS camera initialization sequence!

Yesterday at work i did a really cool thing with the new Hex View feature of ScanaStudio, and I though i would share that with our readers! I used ScanaStudio to write a CMOS camera initialization function in minutes instead of hours! (more…)

Packet View & HEX View
posted by: in Ikalogic News

We are glad to announce our all new addition to ScanaStudio: The Packet view and HEX view. This feature is so useful that we can’t stop using it for our own projects, and we became totally addicted to it! No more having to zoom in, and out and in again and again to look at decoded data bytes. The image below gives you a quick idea of what this is all about:

overall-compressor

 

What you can see in the picture above, is an example CAN bus capture that was done with ScanaPLUS. The decoded CAN bus packets can be visualized in 3 different ways:

  • [icon type=”icon-arrow-right” color=”black”] (Left) Superposed on the waveform, which can be useful to debug the lowest level of the CAN bus.
  • [icon type=”icon-arrow-right” color=”black”] (Middle) Packet View, which lists all packets, one after the other, mixing packets from different channels depending on when each packet arrives
  • [icon type=”icon-arrow-right” color=”black”] (Right) Hex View, allowing you to look at a HEX dump of data being transferred.

The packet view and hex view can be accessed by click on those icons:

icons-compressor

 

Of course, the way the data is presented in the packet view and hex view totally depends on the way the decoder script was written. While most decoder scripts are written by Ikalogic, we allow users to write and customize their own decoder scripts to quickly interpret the data that was captured with our logic analyzers.

We hope you will enjoy this new feature as much as we enjoyed working on it, and we hope it will increase your productivity!

 

FTDI, D2XX and Linux: Overcoming the big problem!

FTDI chip provides really excellent USB chips, that will handle all the USB communication for you with really excellent bandwidth performance. FTDI provide an exhaustive documentation for their cross platform driver. In contrast with the VCP (Virtual Com Port) mode, the D2XX driver allows direct access to the USB device ports in a completely transparent fashion. The Windows drivers are already certified by Windows, so you can just pick your favorite chip from FTDI, and use it in your product without having to worry about time consuming driver development and certification.

All those arguments make FTDI a very good choice if you are willing to launch a cross platform USB based product as we did for ScanaPLUS. However, be warned, there is One Big Problem you will face on Linux platforms. This short post is all about this problem, and the solution we found to overcome it in a nice, transparent and beautiful way. (more…)

New decoders (interpreters) for new protocols!
posted by: in Ikalogic News

Since ScanaStudio V2 is there, you can write your own decoders. Ian (username salts) made use of this feature and wrote two decoders for the following protocols:

 A decoder for the DHT11 bus

 HC-SR04 ultrasonic range finder decoder

We thank him for sharing the source code of those decoders and allowing us to post them in our decoder repository!

You can also automatically download those decoder via ScanaStudio V2, by going to Option > Manage decoders, like in the image below:

manager_decs-compressor

 

ScanaPLUS, ScanaStudio V2 and more
posted by: in Ikalogic News

ScanaPLUS

We just ended the “pre-order” period for our new ScanaPLUS logic analyzers. Time to announce how this period went: ScanaPLUS did very well! We didn’t even expect users to like it so much and so quickly!

During the past 2 years, we worked very hard for this moment, and we hope to continue bringing you the best tools for your electronics workspace!

Just wanted to say a big Thank you to all our customer that trusted us!

ScanaStudio V2

ScanaStudio V2 (V2.300.000 more exactly) is evolving very quickly. A quick look at the release history  page will tell you how often we are adding new features.

Very soon we will be adding a very cool “Decoder Search” feature that will allow you to quickly identify the interesting byte of data. Sometimes a 1 second capture of SPI signals can contain thousands of data words, that’s when this feature will be very handy!

A little later, we will add a new mode, that will also be related to the protocols decoders/interpreters. It will allow you to look at decoded data in a “time stamped table” instead of directly on the graph. Colors and icons here and there should make this feature very user friendly!

More news

We have got many surprises in the pipelines, in other words: New products. We want to broaden our horizon, innovate and more importantly, impress you! Those products will involve LCD screens for some,  Analog switches for others, and even proximity sensors. I know what you think: what a mystery! Sorry, can’t tell you more about that for now (copy cats are always around…). However, if you feel we should trust you and want to take part into our new products development and propose your ideas, don’t hesitate to mail us, we will be very happy to hear from you!

IKALOGIC proudly brings the first 9 channels, CAN, LIN, RS232 and RS485 capable logic analyzer to the market!

Today we are proud to announce that Ikalogic brings to the market the first 9-channel logic analyzer device. Similarly to the alternate functions of micro controller’s inputs, ScanaPLUS inputs can be configured in many ways. It  integrates 2 differential receivers for direct connection to differential buses like CAN or RS485. ScanaPLUS also integrates 5 receivers for RS232 or LIN bus. All 9 inputs are protected again over voltages up to ± 50V. That being said, It’s sensitive enough to catch 1.2v logic signals at 100MSPS rates (Million Samples Per Seconds).

ScanaPLUS was designed to be unique of its kind. Our proprietary, FPGA based, compression and streaming algorithm allows fast streaming of samples from device to PC, without being limited by USB bandwidth.

We have also put a lot of effort into the cross platform software you’ll be using to capture and analyze signals. Beside the Excellent quality included probes, the software is what you will use the most and we wanted it to be a very pleasant experience!

See more details about ScanaPLUS: ikalogic.com/scanaplus

 

IKALOGIC Team is growing!
posted by: in Ikalogic News

As you can see on this page, Ikalogic team has.. changed. Maxime BOUDRIE left the team but two new excellent team mates joined us:

Franck NICOLAUSIG and Vladislav KOSINOV. Both are very serious programmers with failry good electronics background, and together we shall advance much faster on different project.

By the way, I know very little news was filtering out of ikalogic those last months, but we have been working around the clock on many projects and i didn’t have time to share it here:

  • We have been working on some very exciting project for the CNRS (French national center of research) involving lasers and mirrors.. (sorry, can’t say more :) )
  • ScanaStudio is being totally rebuilt by Franck (it’s allready in beta testing). It took a lot of time, but hopefully, this will help us to add more features more often later on.
  • Vladislav is writing decoder scripts for the new ScanaStudio, those JavaScript based scritps are really really excellent. Vlad has spent hours to make those script as user friendly as it can get. For example, the I2C decoder will not only tell you the slave address, but also display the family name from an official database of I2C slave addresses! And that’s just an example!
  • ScanaPLUS, our new product, is being tested and validated by some close & trusted ikalogic fans.
  • We are already planing for new products developement…

That’s all for now!

Thanks for reading!

Tips, tricks and highlights for the AtXmega micro controller

AtXmega micro controllers are quite special. Even If you are familiar with standard AVR micro controllers like the AtMega 168 (used in arduino), there are many aspects that can discourage you from migrating to Xmega. (more…)

What’s next on IKALOGIC?
posted by: in Ikalogic News

If you ask yourself if we at IKALOGIC have been planning on releasing a new logic analyzer, then the answer is Yes! We have been working on it for the past 10 months and we expect this little baby called “ScanaPlus” to be on sale starting on September 2012. I decided to write this news to break the long silence about our new product, although this is not in my habits.  I am going to reveal very few information in this post, consider it a teaser! (more…)

Hello ScanaStudio, goodbye frustration!
posted by: in Ikalogic News

We really want SCANALOGIC-2 users to adopt this new software, simply because it’s way better than the previous one. ScanaStudio was built from the bottom up to be as fluid, as smooth, as enjoyable as possible. It’s not just another update! We have completely replaced the display system (more…)

CMOS camera as a sensor

Today I am going to talk about low cost and effective image processing for very specific embedded applications. I am not talking about robots recognizing their environment or finding their way to a power plug, but rather using small CMOS camera as better sensor. We have used this technology for various clients (more…)

¿Hablas español?
posted by: in Ikalogic News

Our new Spanish partner VOIP minic has published a very interesting video review of our Scanalogic-2 logic analyzer (yes, another review!). Even if you don’t understand Spanish, you can clearly see how Joan Soler put our analyzer to the test (more…)

IKA-TACH

This new contact less tachometer project is based on an ATMEGA48 AVR micro controller, and is able to measure very high RPMs, as well as very low ones. It is based on an IR (Infra Red) opto-couple to detect shaft rotation. It is designed to allow many modifications to me made buy the users like adding additional sensors. (more…)

SCANALOGIC-2 gets a LIN decoder
posted by: in Ikalogic News

Thanks to the cooperation of Gerard Klaver from the Netherlands, we added the LIN1.x and 2.x bus decoding feature to the SCANALOGIC-2 Logic Analyzer. This extends the field of applications of that tiny full featured logic analyzer! (more…)

IKALOGIC enters the Automobile industry!
posted by: in Ikalogic News

Thanks to the cooperation of our Polish partner SILTEGRO, we recently added a CAN protocol decoding feature to our logic analyzers. (more…)

AVR: Monitor power supply voltage, for free!

While apparently being a very simple task, measuring the voltage of the power supply of your micro-controller can be very important and critical, specially for battery powered applications. (more…)

Take a deep breath!
posted by: in Ikalogic News

… As our logic analyzer SCANALOGIC-2  got new breathtaking features for the new year!
First, we worked on the visual interface, our objective was to make it look much better, and make the navigation much smoother even on low performance computers! (more…)

CuriousInventor reviews our product
posted by: in Ikalogic News

Early this week, Curiousinventor released this video clip about our product SCANALOGIC-2. Scanalogic-2 is a logic analyzer and digital signal generator that we launched from a couple of months. (more…)

New IKALOGIC Headquarters!
posted by: in Ikalogic News

We are happy to announce  that as of september 2010, IKALOGIC has finally moved to its new headquarters, in ESTER technology center, at the north of Limoges, France.  (more…)

Scanalogic: the beginning!

Here is one project we are really proud of, and we hope that its simple design will encourage you to build your own, and use the provided software to obtain your own logic analyzer for less than 10$. This device can help you in most of your projects, it’s an essential measuring device when it comes to digital electronics. Those pages will discuss all what you need to know to understand how it works, and build your own, and use it. (more…)

Build a 5A H-bridge Motor driver! New version
posted by: in Motor Control

This H-bridge is easy to build, without any critical components. It is based on the famous and cheap TIP122 and TIP127 power transistors. It have been used on many of our robots and proved to be very versatile and robust. Another major advantage is that it only needs four wires for 12V power supply and direction control. Nevertheless, it allows bidirectional control, breaking and freewheeling.

(more…)

Build a 5A H-bridge Motor driver! Old version
posted by: in Motor Control

In this article, I am going to show you how to build a relatively High power H-bridge motor controller (which is the most common way to control DC motors) With cheap TIP transistors. (more…)

Part 4: Interrupts, timers and counters

Most microcontrollers come with a set of ‘ADD-ONs’ called peripherals, to enhance the functioning of the microcontroller, to give the programmer more options, and to increase the overall performance of the controller. Those features are principally the timers, counters, interrupts, Analog to digital converters, PWM generators, and communication buses like UART, SPI or I2C. The 89S52 is not the most equipped micro-controller in terms of peripherals, but never the less, the available features are adequate to a wide range of applications, and it is one of the easiest to learn on the market. (more…)

Part 3: Basic Input/Output Operations

In this third part of the 89s52 tutorial, we are going to study the basic structure and configuration of I/O ports. Then we are going to apply this theory on simple experimental projects, using a LED and switch, to experiment with the different I/O features of the micro-controller. (more…)

Part 2: C programming for 8051 using KEIL IDE

If not simpler, the version of the C programming language used for the microcontroller environment is not very different than standard C when working on mathematical operations, or organizing your code. The main difference is all about the limitations of the processor of the 89S52 microcontroller as compared to modern computers. (more…)

Part 1: Introduction to 8051 microcontrollers

This tutorial is specially tailored to electronics and robotics hobbyists that have already realized some simple electronics projects and want to go a step further and start using microcontrollers in their projects, more precisely the 89S52 microcontroller. (more…)

De-bouncing circuits

This article deals with a very common problem that occurs in any circuit – more precisely digital circuits – that contains input from a mechanical switch. (more…)

Build your 40 MHz Frequency meter!

This article shows how to build a small, cheap and simple frequency meter, without any fancy, out of reach components. The simple proposed design can measure frequencies up to 40 Mhz with errors below 1%! This degree of precision will be more than enough to debug most of your analog and digital circuits, and will give you the ability to analyze many aspects that you were unable to see before.

The frequency meter is build on a veroboard, using only three components and eight resistors. It is designed to be plugged into any standard bread-board. (more…)

Migrating from 8051 to AVR microcontrollers

While the 8051 microcontrollers are a brilliant invention, their strength remain in their simplicity and ease of use, but not in their processing power or diversity of peripheral features. The 8051 microcontroller is still a very useful device, but sooner or later, you’ll feel that you need a more powerful microcontroller. That’s why I am proposing to 8051 adepts, like me, this tutorials, that shows what are the key differences between those two families of microcontrollers. I’ll also propose an interesting development environment for AVRs. (more…)

Closed Loop Speed and Position Control of DC motors
posted by: in Motor Control

Without getting too close to the mathematical nature of this subject, this tutorial aims to explain what is the meaning of closed loop control, and how to apply it in your projects. As you shall learn in this article, closed loop control offers new possibilities to a project designer, it increases accuracy, shorten response time and dramatically decreases error. (more…)

WFR, a Dead Reckoning Robot
posted by: in Robotics

The aim of the project is simple: Build a robot that moves in any required direction, while keeping record of it’s actual position and angle with respect to a reference starting point but without any lines or ground marks to guide the robot. This data will be then displayed on an LCD display. (more…)

BJT switches

The Bipolar Junction Transistors (BJT), is one of the oldest but most famous transistors, that still find their place in modern electronics. They come in many classes and sizes to match your application, and with some basic knowledge and some simple mathematical relations, you can build very efficient while very simple switch circuits. Using a transistor in the ‘switching’ configuration is indispensable in many situation, where it is required to drive a relatively important load, providing important currents, that most controllers are not able to provide. (more…)

Resistors, Volt and Current

In this article we will study the most basic component in electronics, the resistor and its interaction with the voltage difference across it and the electric current passing through it. You will learn how to analyse simple resistor networks using nodal analysis rules. This article also shows how special resistors can be used as light and temperature sensors. (more…)

5hz to 500 Khz Frequency-Meter

Based on the famous AT89C52 microcontroller , this 500 Khz frequency-Meter will be enough to trace and debug most of your circuits, to adjust 555 timers frequency and perform all kind of frequency measurements in Digital circuits. And once you have this tool between your hand, you will get used to it to the point of no-return! and you will say “remember the days we adjusted the frequency by trial and error till we get it..! (more…)

Uninterruptible Power Supply (UPS) Schematic

This circuit will provide electric power from a backup battery when AC power is cut, always providing a clean 5V power supply for sensitive equipment like microcontrollers and logic circuits. (more…)

Mini line follower Robot
posted by: in Robotics

This small line follower robot, was designed to be easily built at home without any special equipment, and using a minimum number of mechanical parts. You wont need more than two small motors, two free wheels and a piece of pcb (to hold the micro-controller, the motors driver and the line sensor) and sure.. your soldering iron! (more…)

3-bit simple flash ADC Schematic

This three parts flash ADC converter is extremely fast, accurate, and easy to operate. The main disadvantage is it’s relatively low resolution, but this circuit is designed to solve this problem by concentrating on a small range of voltage variation, to obtain high resolutions in that range. (more…)

8-bit Digital to Analog converter (DAC)

This article aims to introduce to beginners and intermediate readers a simple solution to build a digital to analog converter, based on the famous r/2r resistors network. This article also discuss a problem encountered by many beginners while trying to build their own DAC, and proposes some very simple solutions to that problem. (more…)

Line tracking sensors and algorithms
posted by: in Robotics

Line tracking is a very important notion in the world of robotics as it give to the robot a precise, error-less and easy to implement navigation scheme. (more…)

Counting type ADCs

In this article, we will discuss a very common type of digital to analog converters called the counting type ADC. Based on our previous simple tutorial about DACs (digital to analog converters), this article presents a technique of building ADCs that you can use to learn and master the process of analog to digital conversion, but also use it in many of you projects, adding an incredible feature to basic microcontrollers like the 8051 that don’t have integrated ADCs.. (more…)

4A H-bridge motor driver using the L298 IC Schematic
posted by: in Motor Control

This is an implementation of the L298 to drive motors and inductive loads up to 4A continuously. Initially the L298 contains two separate channels, each one capable of driving 2A loads. Connecting them in parallel as in the schematic makes a single 4A driver. (more…)

Small Robot Drive Trains
posted by: in Robotics

This Tutorial Aims to introduce to beginner the different techniques used to build the chassis and drive trains of relatively small robots. What I mean by small robots, is the category of light weight robots where aspects like aerodynamics and vibration damping are not taken in account. (more…)

Digital Thermometer

This article shows you how to build a digital thermometer from the beginning to the end, using a thermistor and a 8051 micro controller. Being based on our tutorial about Analog to Digital conversion, it is very easy to understand the functioning of the device, and you can build it with any micro controller even if it doesn’t have a built in ADC. (more…)

99 000 RPM Contact-Less Digital Tachometer

This article describes how to build a contact -less tachometer (device used to count the revolutions per minute of a rotating shaft) using a 8051 microcontroller and a proximity sensor. (more…)

Infra-Red Proximity Sensor Part 2

This article deals with a more advanced IR proximity sensing scheme, as compared to the one proposed in the previous article. It is also more expensive but provides more accurate results even in sunny outdoor environment. (more…)

In System Programming (ISP) for ATMEL chips

If you didn’t guess it from the title, ISP is a way to serially program your microcontroller, while it resides in its place, in other words, without removing the chip from your board. (more…)

Infra-Red Proximity Sensor Part 1

Based on a simple basic Idea, this proximity sensor, is easy to build, easy to calibrate and still, it provides a detection range of 35 cm (range can change depending on the ambient light intensity). (more…)

Photo cell schematic

This circuit is a classic application of LDRs (Light Dependent Resistors) or also called CdS cells, because they are made of Cadmium Sulphide. The LM358 Op Amp is used as a comparator. Its output is connected to a transistor used as a switch, to trigger a relay. (more…)

Simple IR barrier Schematics

This Infra-Red barrier have many application like:

  • Detecting the presence of objects between a transmitter and a receiver
  • Counting the number of object passing on a rolling belt

Note: this circuit’s behavior is affected by exposition to direct sunlight or strong indoor light directly falling on the receiver.

(more…)

555 based Voltage inverter Schematic

This circuit will convert a positive voltage to a negative voltage, while losing 1.5 V (approximately). For example, if you’re supplying 9V to the circuit, the output will be -7.5 V. This circuit can also be used as voltage doubler, by using the output as the new ground for another circuit.

(more…)

Simple battery monitor Schematic

This is a very simple but effective and accurate battery monitor. The four LEDs D1 to D4 acts like a bar graph. (more…)

Project Housing Ideas

Sometimes, this is the cutting edge that will make you’re project look neater, distinguish it by the way it is finished or perhaps it will protect it and make it a professional and useful product. (more…)