Five Wire Automation using MBScript

The Five Wire GUI provides easy to understand interface for each of the five tools. It also allows you to save your complete setup or the setup of individual tools. However, for some applications automating the setup provides big advantages. Five Wire provides a ‘C’ like scripting language, MBScript, which allows you to take your tests to the next level. With MBScript you can:

  • Create custom digital and analog waveforms
  • Execute tests repeatedly, evaluating and storing results
  • Evaluate test results for application specific characteristics
  • Develop automated tests with user prompts

Each of the Five Wire tools includes a human readable command set. Scripts can use these commands to configure the tool and read back acquired data. For example, you can create a custom Waveform Source output by calculating the set of points that make up the waveform shape within a script. To execute the script just select File Run Script.

Here is an example script that creates a square wave by combining sine waves up to the 9th harmonic:

You can also create digital pattern sequences this way. For example, if you want to generate a series of random 8 bit values you can write a script with a for loop with the line value = rand(0, 255); and write that vector to the Logic Source using the library function LSvector(sequence, value, duration).

Capturing and evaluating data is just as easy. To start a Live Logic acquisition, include LL(“run”); in your script. To check that the acquisition is complete include if( !LLisStopped() ) sleep(100); . To retrieve the acquired data include data = LLgetWaveform(“CH1”, time[], data[]); which returns 2 arrays, one with the time of each sample and a second with the value sampled at that time. You can write for, while, and do-while loops to iterate over the data. Standard math and logic operations can be employed to search for the characteristic of interest. Results can be displayed in one of the easy to use dialog windows such as textWindow(value); or written to a text file.

MBScript looks very ‘C’ like. There are a few notable exceptions to this. Variables are not strongly typed; they are created automatically when encountered. Data arrays are associative not numeric. You can use a number index or a string to index the array. You can declare your own functions by inserting function funcName(param1, param2) {function body} .

The MBScript reference is included when the Five Wire application is installed. Just click Help Open MBScript Reference to open the PDF document. The reference includes a complete description of the script language, a description of the tool commands, and example scripts.


Using Five Wire Events

Five Wire provides 5 unique tools that address different needs of digital designers. Each tool operates independently providing its capabilities in tandem with other tools. For example, you can generate digital stimulus with the Logic Source while capturing test results with the Logic Analyzer. The tools can also interact with each other and the outside world using events or triggers.

Each tool provides an event input and an event output. For example, the Logic source can generate an event on a particular output vector. The Logic Analyzer can be configured to receive that event as a trigger input to terminate its acquisition. The trigger protocol tool provides trigger inputs and outputs that interface the event system with the outside world such as an oscilloscope. Linking the Five Wire tools using events extends their capabilities. Here we will show a few examples of what you can do with events.


The Logic Source tool can both source and accept events. To generate an output event, you specify event to be produced when a selected vector is output. For example, here we show a simple count output pattern where an event is output each time the zero vector is output.

This event could be used to trigger the Logic Analyzer tool to capture the current state of the system. First we must select the Logic Source event as an input to the Logic Analyzer tool.

Next we configure the Logic Analyzer trigger to use the input event.

The Logic Analyzer will now trigger on the event generated by the Logic Source as shown below.

The Logic Source can also receive events. In this example the Logic Source is configured to send its count pattern each time an event is received. We will use the Waveform Source to create an event once each millisecond. We will use the Logic Analyzer to capture the waveform.

First we select the On Event mode for the Logic Source keeping the same count pattern as before.

We select the Waveform source as the event input. The Waveform Source is configured to generate the default 1 KHz sine wave. It will generate an event each millisecond at the start of each cycle. We then capture the Logic Source output using the Logic Analyzer as shown below.

Zooming in we can see the count pattern burst that occurs when the event is received.

We can reverse the roles making the Logic Source provide an event each millisecond that the Waveform source will use to trigger its sine wave output. We exported the Logic Source event using the Trigger Protocol probe so we could also capture the event on the scope as shown in screen capture below.

Events can also be sourced by the System. Pressing the front panel button labeled System or by clicking the SYSTEM button in the Five Wire System window, an event is generated which can be used by any of the tools. This allows you to generate a waveform on-demand at the press of a button.

The Trigger Protocol tool allows you to input events from an external source or to output an internal event from its probe. Here is the configuration we used above to export the Logic Source event to the scope.

In this case the probe output O-TRIG1 was selected to output the Logic Source event. Up to 3 different events can be output. There are 3 event inputs that can drive up to 2 internal events, Protocol A and B. Protocol A can be sourced from any of the 3 inputs. Protocol B can select any of the inputs or a logical combination of the 3 inputs.

Five Wire events give you more control and extend the capabilities of each tool. They leverage the high level of tool integration making it easy to create the test that you need.



Working with I2C protocol

The I2C protocol provides a lightweight and convenient interface for sensors and controllers connected to microcontroller systems. Five Wire provides a number of tools that support hardware and firmware development using I2C. The Live Logic and Logic Analyzer tools can capture and decode I2C traffic providing a human friendly description of each I2C transaction. The I2C protocol tool can emulate an I2C master or slave device allowing you to take control of the I2C bus to better understand a peripheral devices behavior or provide direct control over the system.

Live Logic provides 2 channels of digital capture using scope probes. This makes it easy to probe SCK and SDA to capture I2C traffic. For example, here is an I2C read of a real-time clock (RTC) date/time value.

To read the RTC, the master must first write the address to read, 0x00, and then read 7 bytes which encode the date and time using the BCD format. We can zoom in on the waveform and inspect the timing or individual bits. However, for this example we want to know the contents of the transaction. First we must select a decoder for the protocol.

We select the I2C decoder using the default settings. Once selected, marks will be placed over the data describing the transaction.

The decoder shows that the RTC was accessed at I2C address 68 and a zero was written. Then 7 bytes were read. These bytes are BCD encoded so you can read them directly. 26 seconds, 42 minutes, 9 hours, day of the week 4 (Thursday), day 27, month 9, year 18.

Although this is a great improvement you can go further by customizing the decoder. Five Wire provides the ability to write your own decode (dcd) scripts which determine how the data is converted into human readable strings. If you browse the Documents/Anewin/FiveWire/decoders folder you will find the i2c.dcd decoder that was used to decode this transaction. The dcd scripts are simple text files. When you load the I2C decoder you can select your custom decoder. Here is an example of a custom dcd used with the RTC.

Now the read is decoded to show the contents of the transaction so you don’t have to mentally decode the bytes.

The Logic Analyzer provides more capture channels so you can observe other activity while capturing I2C transactions. The Logic Analyzer provides the same decode capability and dcd scripts but also supports loading multiple decoders. For example, you can load an I2C decoder on channels 0 and 1, monitor a digital output on channel 2 and load an RS232 decoder on channel 3 as in this example.

With the Five Wire I2C Protocol tool you can take control of the I2C bus as shown in the example below. By entering a few lines to define the desired I2C transaction, the Five Wire Protocol tool can emulate an I2C master doing reads and writes to retrieve the date/time from the RTC.

On line 1 we wrote a zero to the RTC. On line 2 we read 7 bytes (14:55:10 Thursday 09/27/18). In addition to read and write transactions you can include commands that insert delays between transactions, pause execution and wait for an event from another tool or an external trigger source, and form infinite loops to provide a repeated transactions.

The I2C Protocol tool can also act as a slave device. This allows emulation of a missing device or provide exact control over the I2C responses. In the example below the system makes an access to a emulated RTC at address 2. The slave has been programmed to return the date Monday, Sept 1, 2018, 12:00:00. A microcontroller was programmed to access the I2C address 2 and send the response out on its RS232 output. Here is the captured transaction using the Logic Analyzer tool.

Five Wire provides broad support for the I2C protocol. Because of the wide adoption of I2C as a peripheral interface, the capture/decode and protocol emulation capabilities can simplify debug and evaluation of I2C device operation and firmware development.

Testing battery powered devices

Battery powered devices present unique test challenges. During development, a circuit may be powered from a fixed power supply to eliminate the variability and hassle of debugging with a battery. However, this does not reflect the real environment the circuit will operate in. As a battery discharges its voltage decreases following a battery specific curve until at some point the battery is exhausted and its output voltage collapses. Eventually the device will have to be tested in its real-world environment.

Testing a devices behavior as the battery discharges can be time consuming and make reproduction of any failures difficult. A better approach would be to simulate the battery discharge curve over a shorter time period, sufficiently long to allow the device to experience and react to the shifting voltage and short enough that the test can be completed in a reasonable time frame. This allows repeated tests if any failure occurs.

To help with these kinds of problems, Five Wire includes the Waveform Source which is capable of acting as a power supply. Its output can drive voltages between 0 – 5 V with load currents up to 100 mA. It can be configured to generate a fixed output such as +3.3V DC but also includes standard waveforms that simulate battery types such as  Alkaline, Ni-Cad, Li-ion, Ni-MH, and LiPo. The discharge time can be adjusted to 60 seconds, 300 seconds (5 minutes), or longer. Simulating battery operation of your device using the Five Wire Waveform Source allows you to quickly test and debug issues related to battery operation. Here is an example of a LiPo discharge over a 5 minute period using the Waveform Source.

If the battery type or discharge curve you want to test is not directly supported in the menus, you can create your own custom waveform for testing. The Five Wire Waveform Source is an arbitrary waveform generator (AWG). It has 10 bits of vertical resolution, 0 – 5 V output, and each waveform can include up to 1020 points. The time duration of each point is settable with a range from 10 microseconds to 20 seconds for a maximum waveform duration of 20,400 seconds (more than 5 hours). The waveform can be developed using a spreadsheet or using MBScript, a ‘C’ like scripting language included in the Five Wire application software.

Creating custom analog waveforms

The five Wire Waveform Source is an arbitrary waveform generator (AWG). To simplify the user experience the GUI includes standard waveforms such as sine, square,  triangle, RC, battery, and DC with settable parameters such as frequency/period, duty cycle, amplitude, etc. The standard waveforms are easy to use but do not show the full power of the Waveform Source.

The Waveform Source generates 0 – 5 V output with 10 bits of resolution. Up to 1020 points can be defined each having a duration from 1 us to hundreds of seconds each. Just like the Logic Source, the Waveform source includes 3 jump controllers providing branch and counted loop control. You can easily generate a custom waveform using the MBScript scripting language. In our first example we will write a script which creates a square wave by combing the fundamental, 3rd, 5th, 7th, and 9th harmonics of a 1KHz sine wave.

The script defines a function waveValue() to calculate the signal magnitude at each point. This includes a 2.5 V offset to center the waveform and the fundamental sine wave and its odd harmonics scaled according to the Fourier series. The pattern includes 630 points with factors of 2 x 3 x 3 x 5 x 7 ensuring that complete integral cycles of each harmonic can be created. A for() loop sets the first 659 points by calling the function setPoint(). The last point is created with a jumpA command which is configured to branch back to the beginning of the waveform in an infinite loop. Here is the complete script.

// Include the WS_Lib.mbs library
addLibrary scriptDirectory + “WS_Lib.mbs”;

// Waveform parameters
fundamental = 1e3; // fundamental frequency is 1KHz

points = 630; // 2*3*3*5*7 = number of waveform points to use
dt = 1/(fundamental*points); // Period of eaach point

// Calculate the magnitude of the waveform at a specific phase
function waveValue(deg)
return 2.5 + sin(deg) + ((1/3)*sin(3*deg)) + ((1/5)*sin(5*deg)) + ((1/7)*sin(7*deg)) + ((1/9)*sin(9*deg));

SY(“openWindow waveformSource”);

// Generate and load the waveform
d = i*360/points;
setPoint(i, waveValue(d), dt, “next”);

// Create the last point with a jumpA mode
d = i*360/points;
setPoint(i, waveValue(d), dt, “jumpA”);

// Configure jumpA to always jump to the first point
configJump(“jumpA”, “always”, 0, 1);

// Update the waveform display

// Run the waveform

Running the script opens the Waveform Source window, loads the waveform, updates the Waveform Display to show its shape in the GUI, and runs the pattern on the Waveform source. Here is a partial screen capture of the Waveform Display view.

Here is a cell phone pic of an oscilloscope display.This shows that it is fairly straight forward to create your own waveforms by replacing the waveValue() function. For example you may want to step between two frequencies inside and outside of a filter pass band. Here is a waveValue() function that toggles between 1KHz and 3KHz

function waveValue(deg)
if(deg < 360)
return 2.5 + sin(deg);
return 2.5 + sin(3*deg);

We configure the A and B jump controllers to repeat each frequency for 100 cycles and the C jump controller branches back to the beginning of the waveform forming an infinite loop. Here is a cell phone scope capture of the frequency transition.

The Waveform Source provides quick easy to use standard waveforms. By writing a little MBScript code you can take full advantage of its AWG features.

Creating custom digital waveforms

Embedded systems often take external real world inputs from sensors evaluating their characteristics to produce a desired control function. For example, a micro-controller might accept a quadrature hall sensor input that indicates motor rotation. This input is used to determine motor RPM as part of a closed loop feedback system that controls motor drive via a PWM output to a full bridge driver. However, the real physical motor to be controlled may not be available for initial code development or may be impractical to have sitting on the developers bench. It is also difficult to get repeatable results using physical devices making it difficult to evaluate performance characteristics of the feedback loop. For these cases it can be advantageous to simulate the motor input or PWM output during early development of the system.

The Five Wire Logic Source tool is a digital pattern generator which provides a simple user interface for creating custom digital signals to stimulate the inputs of your circuits. It provides up to 1020 digital values with each value having a unique duration from 30 ns to 40 ms. The sequential output of vectors can be modified by up to three loop controllers branching execution to form loops, counted repeats, or conditional branching. In this post we will explore how these features can be used to create simulations of real world signals that can be used to evaluate embedded system performance.

We can generate the motor sensor quadrature output using two digital output signals. The pattern only requires 4 vectors, one for each 90 degrees of rotation – 00, 01, 11, 10. This pattern is continuously repeated.The period of each vector should be 1/4 of the motor rotation period. For example, if the motor is rotating at 600 RPM then the motor is rotating 600 / 60 = 10 times per second so the full period is 100 ms. The duration of each of the vectors should be 25 ms. The pattern should then repeat so an unconditional loop branching to the pattern start should be placed on the 4th vector. Here is a partial screen shot of the Logic source pattern editor screen to produce this signal.

This will provide a fixed RPM signal to help development of input timers and RPM calculation algorithms.

Once the input structure is functional it can be handy to evaluate the dynamic performance of the feedback algorithms. This can be accomplished by generating a motor RPM step to see how the algorithm reacts. The motor RPM is set to one value for a number of rotations and then changes to a second value for a set of rotations. For example, we can generate a step from 600 RPM to 900 RPM. The motor will make 100 rotations at each speed. Then the process will repeat.

To create this pattern we will use counting repeat loops. Each loop will repeat 99 times followed by one rotation outside of the loop. The 600 RPM vector period was calculated above. The 900 RPM period is as follows. 900 / 60 = 15 rotations per second making the rotation period 66.67 ms. Each vector period must be 16.67 ms for 1/4 of a rotation.

To fully control the pattern sequence we place the Logic Source in Custom pattern mode. We change the A loop control to type Inner Loop with a jump target of 0 and a loop count of 99. This will replace our original infinite loop. We repeat the vector pattern one more time following the repeat loop. So the 600 RPM pattern is implemented in vectors 0 through 7.

We use vectors 8 through 15 to implement the 900 RPM section. The pattern is the same but the vector duration is 16.67 ms. We use the B loop to repeat the 900 RPM pattern 99 times followed by one more rotation. On vector 15 the C loop branch is used to return to vector 0 repeating the overall pattern. Here is the partial screen capture of the pattern.

Here is a screen capture using the Logic Analyzer showing the step from 600 to 900 RPM.

For additional analysis it may be desirable to generate signals that are a linear function of time. For example, you may want to sweep over a range of RPM or create an RPM which includes noise or a sinusoidal oscillation to verify the operation of the feedback loop. Although these kind of patterns could be entered manually it is much simpler to create them using the scripting language MBScript.

Here is a script that generates 256 vectors (n) resulting in 64 motor rotations with a starting  speed of 600 RPM speeding up on each rotation and ending at 1200 RPM. Each iteration of the for loop creates 4 vectors or 1 rotation of the motor.

addLibrary scriptDirectory + “LS_lib.mbs”;

// Stop in case we are running and configure jump controller A to jump to sequence zero
configJump(“jumpA”, “always”, 0);

// Sweep from 25ms to 12.5ms phase period
t = 25e-3;
n = 256;
dt = (25e-3 – 12.5e-3) / n;

// Load the pattern
for(i=0; i<n; i+=4)

d = t – ( i * dt );
vector(i, 1, d);
vector(i+1, 3, d);
vector(i+2, 2, d);
vector(i+3, 0, d);


// Set the loop jump and event out
configMode(i-1, “jumpA”);
configMode(0, “event”);

// Update the GUI display and run the pattern

Running this script will open the Logic Source tool, program the series of vectors calculating the duration for each rotation, and set a branch loop to vector 0 at the end of the pattern. Here is a partial screen shot of the start of the pattern. You can see that the vector duration decreases on each set of 4 vectors.

Capturing the digital output with the Logic Analyzer tool shows the effect of the sweep pattern.

Other linear functions can be used to control the motor RPM by replacing the function
d = t – ( i * dt );

with another function such as
d = t + (5e-3*sin( i * 360 / n ));

This would impose a sine variation on the waveform.

The same approach can be used to generate reference PWM signals to control the full wave bridge driver and motor. Using a step function the dynamic performance of the motor can be determined by capturing its quadrature output signal with the Logic Analyzer tool. The captured data can be exported to a spreadsheet or processed with MBScript or Python. Five Wire provides the ability to better evaluate and test these dynamic systems.

Real-time trace of RTOS execution

Modern microcontrollers have much more processing power and memory than those of a few years ago. This has opened the opportunity to create more complex behaviors in the products we design. Managing this complexity requires the use of more sophisticated architectures to break the design into manageable components. An RTOS allows you to break your design into smaller chucks which are more manageable.

Each thread running in an RTOS is independent. It can generally execute its behaviors without regard to the other executing threads. When a thread has nothing to do it can yield execution to allow other threads to run. If its behavior is critical it can be assigned a higher priority assuring it runs as soon as it has work to do.

Because the RTOS is selecting which thread will run based on the current system state, it can be difficult to troubleshoot these systems, especially real-time systems which don’t tolerate setting a break point and stopping the execution.

One approach to tracking execution is to use a output port and pulse it each time the thread runs. This allows you to see if the thread runs and how often. Additional output ports can be added to trace more complex relationships. However, this solution is addhock and provides only minimal information.

Five Wire provides a more useful solution using the Logic Analyzer tool and the value nibble decoder. Four output pins must be assigned to make up a nibble that is captured by the Logic Analyzer. A small set of C functions are called within your thread to encode ‘marks’ or ‘variables’ which send short nibble packets to the Logic Analyzer. Once captured, the nibble packets are decoded into human readable values and displayed in the Logic Analyzer trace.

Here is an example capturing a span of time from an ST32F429 running 5 threads in FreeRTOS. Each of the spikes is a mark or variable being exported using the nibble decoder.

Zooming in on one of the spikes reveals three variables being exported and one mark indicating the monitor task is running. By calling the void nibMark(uint8_t n) function in your thread, a mark packet is sent to the Logic Analyzer. Up to 7 unique marks can be set. You can define your own label to reflect the purpose of each mark in the decoder definition file. For example, you could set a mark in each thread if the thread runs. This way you can see the sequence of thread execution, measure the time between executions, or compare the execution time with other external external signals captured on Logic Analyzer channels.

Even more powerful are the variable outputs. You can send up to 16 different variable values by calling void nibVar8(uint8_t n), void nibVar16(uint16_t n), or void nibVar32(uint32_t n). You can also customize the decoder to label each variable value. The variable nibble packets do take more time to send but usually less than a few microseconds.

Here we zoom in on the exported 32 bit tick timer to measure the time taken for the nibble export.

Here we zoom in on a mark to measure its export time.

Using this tool, you can trace the execution of your threads. You can also verify their reaction time to external logic signals by capturing additional signals on other Logic Analyzer channels. You can watch the values of variables as they change in reaction the external stimulus or track a control variable a state machine.

Here is a nibble capture on the same system but also capturing and decoding an RS232 input and the monThread RS232 response output.

The Five Wire Logic Analyzer with the nibble decoder provides a powerful tool to see whats going on in your multi-tasking environment.


Serial port debug

When developing firmware, it’s nice to have a serial debug port. By adding a little software, you can get information about the current operating state, “how much heap space have I used – heap?”, or exercise parts of your design, “set the motor to run at 50% – mot 50”, or tweak parameters of a PID loop to see the effect on system behavior.

Of course you have to first turn on and debug the serial port and parser before you can use it. Common issues are getting the serial inputs/outputs connected correctly and correct setup of the baud rate on your microprocessor. This is where Live Logic can help.

Live Logic provides high performance digital capture with easy to use scope probes. First, connect the probes to the Rx and Tx pins on your board. Live logic includes a DVM and you should immediately note that the Rx and Tx lines are high – close to the positive supply rail.

Next you can verify that The microprocessor serial input is connected to the terminals Tx output. Start the terminal program and hit the enter button a couple of times. The Live Logic activity LEDs will flash indicating activity on the channel connected to the terminal Tx line. Verify that this is the serial input pin to the microprocessor.

Finally, you want to verify that the baud rate for the terminal and the microprocessor UART are correct. Set Live Logic to single, SAMPLES to 512, and start a Live Logic capture. When you hit enter on the terminal you should see the Live Logic channel activity light flash and if your parser is working the Rx channel activity LED should also flash. Stop the acquisition and you should see spikes in the data display. These are the logic activity on the Rx and Tx lines.

Live Logic can capture up to 45 minutes of signal activity. In this case, it captured the entire time span from when you clicked start until you clicked stop. The width of the serial activity is very small compared to your capture time, more than 6 seconds. To see the serial activity, we will have to zoom in on the spikes.

To verify that the baud rate is correct, 38,400 in this example, we can zoom in further and use the A/B marks to measure the narrowest bit. To switch between time and frequency measurement just click ‘/’ on the keyboard.

The measurement is 1/dt=38.45KHz. We have the right baud rate programmed.

Live Logic can help you to quickly get a serial debug port up and running. Its long time capture eliminates the need to set up a trigger to capture the serial transaction. The DVM, activity LEDs, and A/B measurements make it easy to verify your connections and baud rate. The high sample resolution, 2.5 nanoseconds, ensures that the measurement is accurate, even at high baud rates.

What is this Live Logic Tool – what is it good for?

Anyone who uses a logic analyzer knows where to find it – its on a cart in the back of the room. Its there for a reason – no one wants to use it. It takes too long to set up to get the data you are looking for. So you try to solve the problem with a scope until you get to the point where you have no choice. Then you drag out the logic analyzer.

What we realized is that engineers have to invest time in a test tool every time they want to make a measurement. With a scope you can get a little information by just touching the probe to the circuit – the signal is toggling, stuck high, or stuck low. Twisting the trigger level and time per div knobs gets you a stable display so you can see the shape of the waveform. Not much effort gets you a lot of data.

Live logic has the goal of giving you a lot of information with not much effort and to capture your hard to see digital signals. It uses scope probes so you can just touch your circuit. An activity LED on each channel immediately tells you if the signal is toggling. The graphic display is continuously updating and auto-scaling so you immediately see the waveform shape – less setup effort than a scope! In addition, the average voltage of your signal is shown on a DVM for each channel so you can check your logic supplies or PWM levels. You get a lot of information by just touching the probe to your signal.

OK, so why is this any better than my scope? Your scope is a great tool but it is designed to display analog signals. This fundamental requirement means that it must be sampling your signal continuously – a good thing if you are interested in measuring overshoot! But if you are looking at an RS-232 signal or an I2C transaction that happens only occasionally and is different every time, your scope will run out of memory, filling it with the static logic levels that exist between these transactions. Yes you can trigger on the first edge and see the start of the transaction but what about seeing the whole transaction or even better, the one that follows this one as well.

Live Logic was designed to only capture digital signals. It ignores those long periods of static logic levels between your transactions. It focuses on the action – it stores signal changes. The only thing that is stored are the transitions in your I2C signal – the thing you are trying to see. If your processor sleeps most of the time waking up to check the local temperature, its no problem. Live Logic can capture time spans as large as 73 minutes! Of course it does have a memory limit just like your scope but that memory is only used to store useful information.

That’s it. That’s the whole reason for Live Logic. It doesn’t replace your scope but its just as easy to use and it can capture digital signals that are challenging for your scope. Add an MB-500 with Live Logic to your bench and your life as an embedded engineer can become a whole lot easier.




Welcome to the Anewin blog

Welcome to our blog! Our goal is to provide useful and timely information to help our customers get the most out of their Anewin products. The blog will include:

  • Application examples that solve real world problems
  • Tips and tricks
  • Tutorials
  • Just for fun topical discussions
  • News about Anewin

Thanks for your interest in Anewin and our flagship product the MB-500.

Mike Hagen

Principal, Anewin LLC