Home‎ > ‎

Technical Articles

  • Neousys Nuvo-2500 MAIO Seemlessly Integrates with MERLIC MERLIC is an all-in-one software product for quickly building machine vision applications without programming. It is based on MVTec's extensive machine vision expertise and combines reliable, fast ...
    Posted Nov 4, 2015, 6:23 PM by Raymond Hsu
  • MAIO Enables PWM, QEI, AI and DI/O on Neousys Nuvo-2500 Neousys Technology releases a new option, titled as MAIO, of its Bay Trail fanless industrial computer Nuvo-2500. MAIO stands for Multi-function Automation Input and Output. Designed by Neousys ...
    Posted Oct 25, 2015, 6:45 PM by Raymond Hsu
  • Using Nuvo-2510VTC Reading and Sending OBD-II Message over CAN Bus Neousys Technology has released its Nuvo-2510VTC, an in-vehicle fanless computer with built-in Intel Bay Trail processor. As a product for in-vehicle applications, Nuvo-2510VTC provides several ...
    Posted Sep 19, 2017, 7:23 PM by Raymond Hsu
Showing posts 1 - 3 of 3. View more »

Neousys Nuvo-2500 MAIO Seemlessly Integrates with MERLIC

posted Nov 2, 2015, 6:05 PM by Raymond Hsu   [ updated Nov 4, 2015, 6:23 PM ]


MERLIC is an all-in-one software product for quickly building machine vision applications without programming. It is based on MVTec's extensive machine vision expertise and combines reliable, fast performance with ease of use.” (from: http://www.mvtec.com/products/merlic/)

Another article focuses on how easy to create an machine vision application with MERLIC, This article shows the integration of Neousys Nuvo-2500 MAIO with MERLIC. Like Halcon from the same vender MVTec, MERLIC provides an interface for integrating 3rd party digital I/O cards. By default, ADLINK, Advantech, Contec and NI are supported. If cards from those company are installed in the vision computers, users can directly access to the DI/O channels in the MERLIC software without programming. Now Neousys seamlessly integrates its MAIO, multi-function automation I/O, on Nuvo-2500 with MERLIC. With the provided DLL file, dynamic link library file, MERLIC automatically identifies Nuvo-2500 when the Digital I/O Communication Tool is used shown in the figure.
MAIO integrate with MERLIC
MAIO, as an option of Nuvo-2500, provides on-board 4 isolated DIs and 8 isolated DOs, and can be used as a single bit channel, such as di_0.0, do_0.0, and also as a whole port channel, such as di_0.0-3 and do_0.0-7. They are shown in the following pictures.
MAIO DI in MERLIC MAIO DO in MERLIC
Furthermore, integrating PWM, pulse-width modulation, outputs of MAIO into MERLIC has been done as a proof of concept. However, in MERLIC, the interface is for digital I/Os, which have only one property, i.e. on and off. It’s not sufficient for PWM output, which needs at least a frequency and a duty cycle. In this proof-of-concept, we hard coded the frequency of the PWM outputs and leave duty cycle as the only parameter in MERLIC DI/O Tool as shown in the figure.
MAIO PWM in MERLIC
An MERLIC project has been implement for test purpose on Nuvo-2500. In this project, di_0.3 acts as auto-run button, and do_0.2 simulates an output for an ejector. We use the example images from MERLIC and reading the bar code of MAC address as a criteria of good or bad. The following picture shows image-centered tool follow (left) and the frontend panel (right).
MERLIC Front-end Panel
The integration of Neousys products with MERLIC is now available only for MAIO on Nuvo-2500. And by default only DI and DO are implemented. For further request on PWM outputs, voltage inputs and encoder inputs of MAIO and other Neousys products, please contact with Neousys

MAIO Enables PWM, QEI, AI and DI/O on Neousys Nuvo-2500

posted Oct 18, 2015, 7:47 PM by Raymond Hsu   [ updated Oct 25, 2015, 6:45 PM ]

Neousys Technology releases a new option, titled as MAIO, of its Bay Trail fanless industrial computer Nuvo-2500. MAIO stands for Multi-function Automation Input and Output. Designed by Neousys for industrial applications, Nuvo-2500 with MAIO provides not only isolated digital inputs and isolated digital outputs but also other I/O interface commonly used. Enabling MAIO option of Nuvo-2500 resembles to installing a multi-function card insides without consuming the expansion slot. Here are the I/O interfaces covered by the MAIO option:
  • DI: 4 channels of isolated digital inputs
  • DO: 8 channels of isolated digital outputs
  • PWM: 6 channel of pulse-width modulation outputs
  • QEI: 1 set of quadrature encoder input with phase A, B and index signal
  • AI: 2 channels of uncalibrated voltage inputs

  • DI/O, isolatated digital inputs and outputs

    The term DI/O usually refers to discrete inputs and outputs with galvanic isolation, and is much more suitable for applications out of laboratories. In order to interfacing with external devices, i.e. sensors, relays and actuators, DI/O provides wider input voltage range and output driving capacity than GPIO which is usually TTL compatible. Unlike some traditional design with worse performance sensing the turning off action, the DIs of MAIO uses high speed photo-coupler with new technology. Therefore both turning on and off can be sensed by the MCU 10 times faster.

    Each DI of MAIO has an internal resistor, and 5~24VDC can be applied directly between the input pins and the common ground pin, DI_GND, as a logic “1”, while 0~1.5VDC as a logic “0”. The following figure shows the wiring digram of DIs.
    Figure 1: Wiring of DI of MAIO
    Figure 1: Wiring of DI of MAIO

    DIs usually work with dry contact switches and sensors with digital outputs. Dry contact switch comes in various forms, such as buttons, rocker switches, tactile switches, limit switches and so on. When a dry contact switch is used as the external devices, connect on pin of the switch to DI pin and the other pin to the positive voltage. When a sensor with PNP output is used, connect the output pin of the sensor to DI pin and the power pins, perhaps named Vcc and GND, to the PSU, power supply unit for the external devices. Sensors with NPN output is not compatible with DIs of MAIO. DOs is interfaced with open drain MOSFET, capable of 200mA sinking driving current each channel. With open drain design, loadings are connected between positive voltage of PSU and DO pins, and ground of PSU is connected to DO_GNDs.
    Wiring of DO of MAIO
    Figure 2: Wiring of DO of MAIO

    With open drain design, a wide range of driving voltage from 5VDC to 30VDC is acceptable. The rated driving voltage is 24VDC, while 30VDC is the peak voltage. Please note that when the DOs activate, as open-drain design, the DOs is almost short to DO_GND. It’s users’ obligation to calculate the driving current and connect resistors to limit the current if necessary.

    PWM, pulse-width modulation output

    PWM is a special form of digital outputs. It uses the percentage of “on-time” of a series of pulses to deliver information more than “0” and “1”, what a digital output does. PWM stands for pulse-width modulation. Wikipedia has deep explanation on this topic, and we don’t emphasize on the principle. Although it’s not exactly correct, thinking it as a special analog output might help you to understand. The following figure shows wave forms of different on time. Imagine that each “ON” turns on the lamp and the frequency is high enough. The larger portion of on-time is, the brighter you feel the lamp is.
    PWM wave forms and energy
    Figure 3: PWM wave forms and energy 

    PWM is widely used in applications. Many drivers and amplifiers accept PWM signals to adjust the their outputs. For example, the LED driver HLG-120H-C500B, from Meanwell, accepts PWM control signal for dimming purpose. The driving output current up to 500mA is provided by the LED driver, and the PWM signal only controls the percentage of output current. By the way, the PWM of MAIO is a 5V voltage output, but this LED driver accept a 10V-PWM signal. A simple Darlington IC can help to convert the voltage if necessary. Another example is the DC motor driver. PWM signal controls the rotational speed of the DC motor via the DC motor driver. The following picture shows a BLDC motor with a integrated driver. This BLDC uses 24V power source, and the yellow line is 5V PWM input for adjusting the rotational speed.
    PWM BLDC motor with an integrated driver
    Figure 4: A PWM controllable BLDC motor with a integrated driver

    Another application is to control RC servos. RC servo uses the pulse width of on time as a positioning command. A live demo of Neousys Nuvo-2500 with PWM of MAIO to control a tiny 6-axis articulated robot arm actuated by RC servos has been built for Computex 2015.
    Figure 5: Live demo of PWM controlling RC servo robot arm

    However, depending on the controlled devices, different PWM frequency might be required. The RC Servo usually requires 20ms period, i.e. 50Hz, and the mentioned LED driver HLG-120H-C500B accepts from 100Hz to 3KHz. PWM of MAIO provides programmable PWM frequency from 20Hz to 500KHz. The high frequency PWM is basically a series of pulses. This also make it possible to control the speed of stepping motors via the driver which is commanded by high speed pulse chain.
    PWM of MAIO controls speed of a stepping motor
    Figure 6: PWM of MAIO controls speed of a stepping motor

    QEI, Quadrature Encoder Input / Incremental Encoder Input

    Quadrature encoders are widely used in automation industrial applications. A quadrature encoder translates offset and speed into special pulse waves, and needs a QEI, quadrature encoder input, to translates it back to offset and speed. QEI is also known as incremental encoder input, and has three phases of inputs, denoted as Phase A, Phase B and Phase Z. Phase Z is sometimes named Index.

    QEI of MAIO supports two modes of counting. One is the quadrature encoder mode, and the other is event counter mode. If only number of event is counted instead of the quadrature encoder signal, it’s possible to configure QEI of MAIO to event counter mode. In this mode, QEI behaves like an event counter, counting the number of inputs occur at Phase A. Phase B is defined as direction, which decides to increase or decrease the counter while inputs are find at Phase A. When working with quadrature encoders, QEI of MAIO has to be configured to quadrature encoder mode. The pins of different phases are internally pulled high to 5V, is designed for open-collect output encoders, such as E6J-CWZ1C from Omron.

    Some industrial rotary switches and joysticks has quadrature encoder outputs, also named as quadrature 2-bit code. A Grayhill’s Joystick 60A loaned from QuadRep Electronics [Taiwan] Ltd. has been tested and is totally compatible with QEI of MAIO. Besied of encoder output, this 60A joystick has 2-bit output codes of X and Y status. That is, 0V for “Low” position, 5V for “High” position and 2.5V for neutral position. The AI of MAIO, introduced in the following paragram, is suitable for the 2-bit output. The following figure shows the wiring between Nuvo-2500 MAIO and Grayhill 60A.

    Wiring example of Grayhill 60A and Nuvo-2500 MAIO
    Figure 7: Wiring example of Grayhill 60A and Nuvo-2500 MAIO


    AI, Analog Input / Voltage Input

    There are also two AI channels of MAIO. The AIs accepts voltages signal up to 33VDC. Not designed for precise measurement usages, the AIs don’t have any calibration circuit. The input interface is a simple voltage divider. The AIs are suitable for human interface devices, such as hall sensor joysticks and analog joysticks. Grayhill 60A is an example mentioned in the previous paragram. In addition, APEM produces many industrial joysticks which should be compatible with AI of MAIO, but haven’t been really tested. Connecting to sensors, such as ambient light sensor TEMT6000, is also suitable. In short, the reading values of AIs are relatively correct although they are not calibrated.

    At last, but not least, like some multi-function I/O cards in the market, PWM, QEI and AI are interfaces which are not isolated. It means these interfaces share the same digital ground with Nuvo-2500. Among all interfaces of MAIO, only DI/O are, by design, isolated.

    Regarding to software and development of user applications, C APIs for developing applications under Windows XP, Windows 7 and Windows 8 are available from Neousys, and Linux is not support at this moment. The programming flow is nothing more than initialization, configuration and access. Sample codes for each functionality has been ready for reference. MAIO equips Nuvo-2500 with various interface, sush as DI/O, PWM, QEI and AI at the same time with one single option, and it’s not necessary to install extra 2 or 3 add-on cards and use only a little part of them. It’s really a cost saving option for your application. Please contact with Neousys if you need more information.

    Using Nuvo-2510VTC Reading and Sending OBD-II Message over CAN Bus

    posted Sep 14, 2015, 7:03 PM by Raymond Hsu   [ updated Sep 19, 2017, 7:23 PM ]


    Neousys Technology has released its Nuvo-2510VTC, an in-vehicle fanless computer with built-in Intel Bay Trail processor. As a product for in-vehicle applications, Nuvo-2510VTC provides several specific features, such as ignition power control, shock-absorbing mounting kit and also a CAN bus port. This article mainly describes the CAN bus on Nuvo-2510VTC and provides a demonstration of OBD-II communication over CAN bus as a proof of concept.

    The beginning of CAN, controller area network, bus dates back in 1983 and was first released in 1986 when the existing serial buses could not fulfill the requirement being used in cars. After several years, CAN bus was implemented in a real vehicle, BMW 8 Series. And nowadays, CAN bus is quite common in the automobile industry. Though CAN bus, compared with other buses, might not be a high speed bus, it shows several features which makes CAN bus suitable for in-vehicle applications. First, CAN is a bus of multi-master with prioritized message ID. Every node on the bus can send message when the bus is unoccupied. In the CAN message, there is a message ID. If more nodes send at the same time, the one with lower ID gets the authority to send, and the others stop sending immediately. This makes sure the urgent message is transmitted first without extra delay for arbitration. Secondly, CAN bus uses differential signal over two wires and supports multi-drop topology. The differential signal of CAN bus naturally results in noise cancellation. External disturbance on the two wires will be eliminated. Contributed by multi-drop topology, every CAN node on the bus can get the message at the same time. Faulty nodes will not break the bus connection. Besides, there’s no hardware identification, such as an address, of each CAN node. It’s easy to add, replace or remove a node without change to the system or other nodes on the bus.

    CAN bus also features its error detecting and error handling capabilities. Five error types, i.e. bit error, stuff error, CRD error, form error and acknowledgment error, are defined to ensure that CAN data frames are correctly transmitted and received. CRC field in the CAN data frame ensures the data consistency of CAN data frame. ACK field makes the transmitting node to know if the message is received by at least one node on the bus. Moreover, a sophisticated fault confinement mechanism, together with the five error types, is implemented to distinguish each CAN node in one of the three states, i.e. error active, error passive and bus off. When a node encounters too many errors, it will be in bus off state and will have no influence on the bus. This allows messages from good nodes to traffic on the bus.

    Based on the features, CAN bus focuses on Physical Layer and Data Link Layer according to the ISO/OSI model. While CAN bus provides a reliable foundation of communication, there are many CAN-based HLPs, standing for CAN-based higher layer protocols, defined over CAN bus in different applications. For example, CANopen and DeviceNet are CAN-based HLPs used in industrial automation. OBD-II and J1939 are those for in-vehicle applications. EnergyBus is developed for electric vehicles. There are still other CAN-based HLPs, such as CAN Kingdom, NMEA 2000 and VSCP for different fields.

    The mentioned OBD-II, standing for On-Board Diagnostics, refers to the self-diagnostic and reporting capability of a vehicle. OBD-II interface defines five physical signals via a 16-pin connector. Cars can support one or more of them to provide OBD-II capability. CAN bus is one of these five signals and getting more and more popular. After 2008, all vehicles sold in the US are required to implement CAN as one of these five signals. The communication protocol of OBD-II is a simple query and response process based on the OBD-II Parameter IDs and Modes. Figure 1 shows simplified CAN data frame and how OBD-II query frames fit in it. A single CAN bus data frame has a maximal 8 bytes of payload, and OBD-II query frame occupies all the 8 bytes although not all of them are used. In order to transmit all the 8 bytes payload, data length of CAN data frame is set to 8. To send OBD-II query frame over CAN bus, CAN ID is set to 0x7df. The digram shows a basic OBD-II query frame. What we need to do is to fill in the code of Mode and PID, e.g. Parameter ID. For example, Mode 0x01 means to query current data and PID 0x0C indicates engine rotational speed in revolution per minute. The full list of OBD-II PIDs can be found on Wikipedia.

     CAN Data Frame with OBD Query Frame
    Figure 1: CAN Data Frame with OBD Query Frame 

     CAN Data Frame with OBD Response Frame
     Figure 2: CAN Data Frame with OBD Response Frame

    The OBD-II response frame looks simular with the OBD-II query frame except that CAN ID ranges from 0x7e8 to 0x7ef and the 0x40 is added to Mode of the corresponding query frame. That is, Mode 0x41 is the response mode of Mode 0x01, Mode 0x42 is the response mode of Mode 0x02, and etc. In the OBD-II response frame, the value of queried PID starts at the 4th byte of CAN Data. The OBD-II PID list also indicates the formula to calculate the final values. Take querying current engine rotational speed of the vehicle as an example. The following diagram shows the query and response frame, assuming that the engine rotates at 3000rpm.
     OBD-II Query and Response Frame over CAN bus
     Figure 3: OBD-II Query and Response Frame over CAN bus

    The query frame has a CAN ID of 0x7df and indicates the frame is to going to query some data. Mode 0x01 is the mode to show current data, and PID 0x0C means engine rotational speed in revolution per minute. CAN ID of the response frame might vary from 0x7e8 to 0x7ef. The number of bytes is 0x04, which means 4 bytes, i.e. Mode, PID, value A and value B, are available. The response mode 0x41 means the frame is a response to a mode 0x01 query frame, and PID 0x0C shows the frame contains the engine rotational speed. According the the PID list, the formula of engine rotational speed is (A*256+B)/4. That is, (0x2E*256+0xE0)/4, 3000 RPM.

    Nuvo-2510VTC from Neousys Technology is an in-vehicle fanless computer with Intel® AtomTM E3845 quad-core processor. The built-in CAN bus port is complied with CAN Specification 2.0 Part A and Part B. Bit rates up to 1Mbps are possible at network lengths less than 40 meters. APIs, application programming interfaces, for Windows programming are provides for developing user applications. Nuvo-2510VTC and its APIs cover most sophisticated part of CAN communication so that users can focus on sending and receiving the CAN message. In C programming with the APIs, a data structure of CAN Message, CAN_MSG, is provided. CAN_MSG defines CAN_MSG.id, CAN_MSG.len and CAN_MSG.data[8] for the green, blue and red fields shown in Figure 3 respectively.
     Block diagram of the demonstration system
     Figure 4: Block diagram of the demonstration system

    To demonstrate reading and sending OBD-II messages over CAN bus using Nuvo-2510VTC, we establish a demonstration system as shown in Figure 4. An OBD-II to Bluetooth module, ELM 327 compatible, is commonly used in vehicles to transmit the OBD-II message via Bluetooth to your cellular phone with an OBD-II APP, such as Torque, to get the diagnostic information from the vehicle. A Nuvo-2510VTC is connected to the ELM 327 module via a commercial off the shelf DB9 to OBD-II cable, and acts as an ECU simulator, which receives OBD-III query frame over CAN from the ELM 327 and response to the query. With the installed OBD-II APP, the response can be observed on your cellular phone. The demonstration program on Nuvo-2510VTC is modified from the CAN sample program. It sends a triangle wave and sine wave of vehicle speed and engine rotational speed respectively. Figure 5 shows the demonstration system and the result on the cellular phone. The left graphics is vehicle speed, i.e. PID 0x0D, while the right one is engine rotational speed in RPM, i.e. PID 0x0C.

     Real demonstration system and result
     Figure 5: Real demonstration system and result

    In summary, CAN bus is a serial bus which supports multi-drop topology and is widely used in automotive and industrial applications. The 5 error types, 3 error states and 2 error counters form the fault confinement mechanism and ensure the stability of bus communication. Designed for in-vehicle application, Nuvo-2510VTC from Neuosys Technology provides a built-in CAN bus port. The provided SDK facilitates access to CAN bus despite the sophisticated theory of operation. Using the built-in CAN bus port of Nuvo-2510VTC to read and send OBD-II message over CAN is demonstrated as a proof of concept. This shows Nuvo-2510VTC is complied with CAN 2.0 Part A and Part B and compatible with off-the-shelf CAN bus products and CAN-based HLPs. For further detail of Nuvo-2510VTC, please visit the product web page, or contact with me at sales@neousys-tech.com.


    1-3 of 3