There is a known issue in Support Tool 7.8 for new installs. Click below to download 7.9. If you have trouble launching Support Tool 7.8 it is likely because the INTEG directory was not created at the root level of your drive. If you wish to stay with 7.8 you can create a C:\INTEG\JNIOR Support Tool directory and try to launch the Support Tool again. Sorry for the inconvenience.

Check the Support Tool News Section to get the latest update!

Pronounced “jump”, the JMP protocol is the JANOS Management Protocol. It will be available in JANOS 1.8.

The JMP protocol shares the messaging JSON structure that is used by the DCP (Dynamic Configuration Page) and the web-socket protocol but on port 9220, by default.

To make processing easier we wrapped the JSON message in a two element JSON Array.

[ number, object ]

Where number is the size in bytes/characters of the JSON object that follows.

Doing this relieves us of needing to count braces to see when an entire JSON message was received. To parse the structure we can do the following:

  1. Look for the opening ‘[‘.
  2. Then process numeric values until a ‘,’ is found. White-space is ignored.
  3. White-space is again ignored and N bytes are read.
  4. Finally remaining white-space is ignored and the trailing ‘]’ confirmed.

If the numeric value is invalid, the comma missing or the trailing ‘]’ bracket not found, the entire message is to be ignored. The extracted JSON Object can then be validated as well.

The JNIOR Control Panel is shipped with a ‘click’ sound that plays when a switch is pressed. This gives immediate feedback to the user that the panel has power and that the software is running normally and is ready to accept the press. There are times when the panel is used in a situation where the ‘click’ may not want to be heard. In this situation we may want to turn off that sound. The following application will accomplish this goal.

To run this application you need to download it from the button and load it on your JNIOR. Applications are generally loaded in the flash directory. To run it simply type the command as you see it above.

ControlPanel Application JAR [7 KB, MD5: c573b4c989ea0380729fecae5283e937]

In the following code you will notice two classes. The main class of interest here is the ControlPanel class. This class will load the arguments into a ParameterGroup class so that we can process different commands at some point as well as there specific options. For now our command line is pretty simple but we set this application up for the future.

package com.integ;

import com.integpg.sensor.SensorPort;
import com.integpg.system.JANOS;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.Hashtable;

 * This application will allow you to set the volume of the control panel click
public class ControlPanel {

    private static final String USAGE_STRING = "CONTROLPANEL\n\n"
            + "Options:\r\n"
            + "  -VOLUME volume     Sets the volume level to a value between 0% and 100%\n"
            + "\n"
            + "Set options for the control panel";

    public static void main(String[] args) {
        // load the arguments into our parameters class
        ParameterGroups parameters = new ParameterGroups(args);

        // if the paremters are empty or there is a -help parameter then print the usage string and exit
        if (parameters.isEmpty() || parameters.containsParameterGroup("help")) {

        // go through each parameter and process it
        while (parameters.hasMoreParameters()) {
            String parameterGroupName = parameters.getNextParameterGroup();
            ArrayList parameterOptions = parameters.getParameterOptions(parameterGroupName);

            switch (parameterGroupName) {
                case "volume":
                    try {
                        // process set volume
                    } catch (Exception ex) {

                    System.out.println("unknown parameter: " + parameterGroupName);



    private static void processSetVolume(ArrayList options) {
//        ArrayList volumeArguments = _parameters.get("volume");
        if (0 == options.size())
            throw new RuntimeException("must specify a volume parameter between 0% and 100%.");

        int volume;
        try {
            // get the volume from the arguments.  allow the user to enter a double but 
            // save the integer part
            volume = Double.valueOf(options.get(0)).intValue();
            if (0 > volume || 100 < volume) throw new Exception();
        } catch (Exception ex) {
            throw new RuntimeException("invalid volume specified: '" + options.get(0)
                    + "', volume parameter must be between 0% and 100%.");

        // go through the external devices and set the volume for any connected control panels
        for (long externalModuleAddress : getExternalAddresses()) {
            // get a string representation of the address
            String addressString = getAddressString(externalModuleAddress).toUpperCase();

            // determine the type of module and handle accordingly
            if (0xfa == (externalModuleAddress & 0xff)) {

                try {
                    byte[] writeBlock = getSetVolumeWriteBlock((int) (volume * 2.55));
                    SensorPort.writeDeviceBlock(externalModuleAddress, writeBlock);

                    // lets print the result to the screen as well as the syslog
                    String result = String.format("Panel at %s set volume to %d percent", addressString, volume);
                } catch (IOException ex) {
                    throw new RuntimeException(
                            String.format("unable to write to the control panel: %s.", addressString));


    private static long[] getExternalAddresses() {
        try {
            // query the unit for an array of external module addresses
            return SensorPort.externalDeviceList();
        } catch (IOException ex) {
            throw new RuntimeException("unable to get external device list.");

    private static String getAddressString(long address) {
        String addressString = "0000000000000000" + Long.toHexString(address);
        return addressString.substring(addressString.length() - 16);

    private static byte[] getSetVolumeWriteBlock(int volume) {
        // the write block for the control panel is 20 bytes
        byte[] bytes = new byte[20];

        // to set the volume we only need to set the command byte and the audio volume byte
        bytes[10] = 4; // set audio volume command
        bytes[11] = (byte) volume; // audio volume level

        return bytes;

 * A class for interpreting command line arguments into parameter groups
class ParameterGroups {

    private final Hashtable> _parameters = new Hashtable<>();
    private Enumeration _enumeration;

    public ParameterGroups(String[] args) {
        // parse the arguments
        ArrayList options = null;
        for (int i = 0; i < args.length; i++) {
            String arg = args[i].toLowerCase();

            if (arg.charAt(0) == '-') {
                while (arg.charAt(0) == '-') {
                    arg = arg.substring(1);
                options = new ArrayList<>();
                _parameters.put(arg, options);

            } else if (options != null) {

            } else {
                System.out.println("Illegal parameter usage");

        _enumeration = _parameters.keys();

    public boolean isEmpty() {
        return 0 == _parameters.size();

    public boolean containsParameterGroup(String paramterGroup) {
        return _parameters.containsKey(paramterGroup);

    public String getNextParameterGroup() {
        if (null == _enumeration) _enumeration = _parameters.keys();
        if (_enumeration.hasMoreElements()) {
            return _enumeration.nextElement();
        } else {
            return null;

    ArrayList getParameterOptions(String parameterGroupName) {
        return _parameters.get(parameterGroupName);

    boolean hasMoreParameters() {
        return _enumeration.hasMoreElements();


Once the ParameterGroups class has been instantiated with our command line arguments we loop through each parameter group. When we find the “volume” parameter group we call processSetVolume() and pass in the parameter options.

        // go through each parameter group and process it
        while (parameters.hasMoreParameters()) {
            String parameterGroupName = parameters.getNextParameterGroup();
            ArrayList<String> parameterOptions = parameters.getParameterOptions(parameterGroupName);

            switch (parameterGroupName) {
                case "volume":
                    try {
                        // process set volume
                    } catch (Exception ex) {

                    System.out.println("unknown parameter: " + parameterGroupName);


Now that we are inside the processSetVolume() method we need to validate the options provided. We make sure that a volume was provided and that it is a valid number between 0% and 100%.

    private static void processSetVolume(ArrayList<String> options) {
//        ArrayList<String> volumeArguments = _parameters.get("volume");
        if (0 == options.size())
            throw new RuntimeException("must specify a volume parameter between 0% and 100%.");

        int volume;
        try {
            // get the volume from the arguments.  allow the user to enter a double but 
            // save the integer part
            volume = Double.valueOf(options.get(0)).intValue();
            if (0 > volume || 100 < volume) throw new Exception();
        } catch (Exception ex) {
            throw new RuntimeException("invalid volume specified: '" + options.get(0)
                    + "', volume parameter must be between 0% and 100%.");


Now that the options have been validated and we processed the assigned volume we are ready to write to the connected control panels. We loop through each connected panel and check to make sure it is a Control Panel which is type 0xFA. If it is a Control Panel we can get the write block and send it to the Sensor Port.

        // go through the external devices and set the volume for any connected control panels
        for (long externalModuleAddress : getExternalAddresses()) {
            // get a string representation of the address
            String addressString = getAddressString(externalModuleAddress).toUpperCase();

            // determine the type of module and handle accordingly
            if (0xfa == (externalModuleAddress & 0xff)) {

                try {
                    byte[] writeBlock = getSetVolumeWriteBlock((int) (volume * 2.55));
                    SensorPort.writeDeviceBlock(externalModuleAddress, writeBlock);

                    // lets print the result to the screen as well as the syslog
                    String result = String.format("Panel at %s set volume to %d percent", addressString, volume);
                } catch (IOException ex) {
                    throw new RuntimeException(
                            String.format("unable to write to the control panel: %s.", addressString));

The JniorWebSocket Library was started as an example project.  It has not had much use here in-house and therefore the testing has been limited.

Here is a quick application that demonstrates how to instantiate multiple JNIOR WebSocket objects.  Each Object is added to a tree control so that they may be interacted with individually.  So far I have added the ability to add and remove, connect and disconnect and pulse output 1.  This application can be easily extended to manage multiple JNIORs and perform many different tasks.

Here are 2 links.  The first is a link to the Visual Studio project for the library.  The second link is a zip file containing the example described above.

C# WebSocket Example [6 MB, MD5: fe1be1e450c2772a16d090a0d9c37f99]

MultipleJniors-1.zip [1 MB, MD5: 26485d581f00d9c5985db3e7f481e551]


In an earlier article we attempted to connect the JNIOR to a DMX512 network in a way that would allow a theatre stage crew to control relays and other outputs through their main lighting control panel. Here with the programmable facet of the JNIOR we could help create complex special effects that can be triggered in-sync with lighting. In fact, DMX channel data can be used by the JNIOR application to trigger and manipulate activity on a LAN segment and thereby update computer screens and TV displays on stage. This can all occur with precise timing in concert with other lighting changes.

The DMX512 protocol and interface was developed over 50 years ago as a means to reduce wiring cost and to improve the mobility needed to support major concert tours in the music industry. It incorporated serial data transmission formats that were state-of-the-art at the time and that are still relevant today. Unfortunately the protocol employed a baud rate much higher than would be later recognized as standard in the computer industry. Also the limited capabilities for data synchronization and lack of error checking make interfacing difficult. Even though the JNIOR Model 410 is able to handle the RS-485 signals and was upgraded to receive 250 Kbaud data triggered on the specified serial Break Condition, we could not achieve reliable operation as a fixture through programming alone.

The issue relates to the design of the standard computer hardware component called the UART. The Break Condition that the DMX protocol uses to identify the start of a frame of data is not handled by the UART in a fashion that can be reliably used to synchronize data reception. At least it is not possible in a purely software implementation as we discussed previously. The answer lies in a simple hardware adapter that alters the DMX512 signals just enough to work correctly through the UART. We will see what that entails in the rest of this article.



DMX512 Fundamentals

Today DMX is defined by official standards. On the wire DMX512 uses EIA-485 differential signaling. We often refer to it as RS-485. You are probably more familiar with the term RS-232. As serial digital communications became more prevalent the distance limitations and noise susceptibility of RS-232 became more and more of concern. The solution, designated as RS-422, used balanced transmission lines over twisted pair which extended the distances that signals can traverse as well as the communication rates that can reliably be achieved. RS-422 connections however are point to point and as computer systems grew so did the need for networking. Soon RS-485 came along and added functionality that created a multi-drop environment where one talker can communicate with a number of listeners. RS-485 is what DMX512 needed where one (or more) lighting control panel must communicate with multiple lighting fixtures.

This basically amounts to a 3-wire network where there is one DATA+ (positive) data line and one DATA- (negative) data line along with a GND ground. The DMX standard details specific connectors (5-pin XLR) and wiring of sufficient gauge and quality. The world also wants to utilize 3-pin XLR connectors for DMX as these are prevalent in the industry through their use in audio applications. You will find a mixture of fixtures some with 3-pin and some with 5-pin connectors. Thankfully 3-pin to 5-pin adapters are readily available.

On the protocol side it was necessary to standardize. This would encourage lighting manufacturers to incorporate the technology. Over the years the protocol itself had been handled by different standardization groups and now is:


American National Standard
ANSI E1.11-2008 (R2008)
Entertainment Technology – USITT DMX512-A
Asynchronous Serial Digital Data Transmission Standard
for Controlling Lighting Equipment and Accessories.


In order to understand where we have difficulty we need to look deeper into the specifics of what is sent across the wires. You recall that DMX was invented to reduce wiring costs. Each channel in the protocol replaces a single power cable. The protocol allows for up to 512 channels and all of those multiplexed onto a single 3-wire network cable. That is a significant savings.

Each channel digitizes an analog signal into one 8-bit value. These can represent numbers from 0 to 255 and for lamps that is used to sufficiently cover the range from 0% to 100% brightness in 256 steps. Where once one channel controlled one lighting fixture, today multiple channels are assigned to each fixture to define attributes such as color and positioning in the case of motorized fixtures. In the serial world each channel is transmitted just as a byte of character data would with a start bit, 8 data bits and one or two stop bits. For DMX512 two stop bits are used. That is a total of 11 bits per channel.



The DMX protocol allows for the transmission of up to 512 channels. These are sent in sequence starting with channel 1 and up to channel 512. A Start Code is defined as channel 0 and the typical value for that is zero. The complete set of channels 0 through 512 (513 channels) is called a Frame. Frames are transmitted repeatedly one right after another with the start bit immediately following the prior stop bits at the defined rate of 250 Kbaud. We can now do some math. With 11 bits per channel and 513 channels that is a total of 5,643 bits. A bit at 250 Kbaud requires 4 microseconds and so the data part of the frame takes a total of 22.6 milliseconds. We can fit a little over 44 frames in a each second.

Now with a constant flow of channels each looking the same on the wire how do we know which one is channel 0 and which might be the one we need for our fixture? If we connect to an active DMX network we need a way to synchronize ourselves. For this the standard defines the use of a Break Condition to signal the beginning of a frame. In old days this was called an Attention Signal and it was used to wake up remote teletype equipment and there was actually a key on the Teletype for this. So back in those days this was a natural choice for DMX synchronization. A Break Condition amounts to a period of time where the signalling is held at the level of a Start Bit (Space) long enough to violate the normal byte format and cause a reception error. The receiver simply fails to see the Stop Bits where they are expected and raises a flag. This is intended to signal the beginning of a frame.



By this definition a Break Condition need only last long enough to mask the expected Stop Bits (11 bits, 44 microseconds). This causes a UART to signal a Framing Error indicating that the data it received was not properly formatted and followed by the expected Stop Bits. This error can then be used for Break detection and the synchronization of the DMX Frame. The current DMX512 specification defines the minimum time for this Break Condition to be 88 microseconds which is exactly the transmission time of two channels. The timing of this Break Condition has been reduced from prior versions of DMX512 and it is unclear if there is any risk that existing lighting fixtures may fail to operate when presented with the shorter pulse. The specification does not specify a maximum duration for the Break Condition and states only a “typical” duration of 176 microseconds.

After the Break Condition terminates there must be a brief period of time before the Channel 0 (Start Code 0x00) can be transmitted. This period is called Mark After Break and the current specification defines a minimum of 8 microseconds the time period of two bits. This too has been reduced from prior versions of the specification. A maximum duration of 1 second is defined for Mark After Break and no typical value is given.

This defines the entire sequence. First a Break Condition of sufficient duration is issued. This is followed by a Mark After Break also of sufficient duration. After this each of 513 Channels is sent with proper serial formatting. The first is the START CODE which for normal DMX is always 0x00. Following the final Stop Bits for the last Channel there can be a gap before the next Break Condition. These Frames are sent continuously and according to the specification at least one Frame needs to be sent every 1.25 seconds.

Here is what this looks like in reality. The wider pulse in the center is a Break Condition and Frame data can be seen to the right and left of it. Note that in this case all Channels are set to 0x00 and so we see only the Stop Bits for each.



One side note is that shown above are the CMOS logic signals observed after the RS-485 receivers. This signal is typically fed to the receiving hardware or UART. This image is consistent with our prior diagrams where the Marking condition is a HIGH or 1 and the Spacing condition a LOW or 0. The signals on the actual wire demonstrate the same timing but would involve dramatically different voltage levels.

There is one point that I have not mentioned. The total number of Channels included in a Frame is a maximum of 513 but that number is optional. A lighting controller may decide to only send 128 Channels in addition to the START CODE assuming that others are unused and thereby increasing the number of Frames per second. The specification defines a maximum Frame rate of around 836 Hz (Frames per second). This can accommodate fixtures that need higher Refresh Rates. The Refresh Rate for a DMX512 Universe of a full 512 Channels is around 44 Hz.

In the previous article we alluded to there being some difficulty in receiving these signals with standard computer hardware. We now have enough technical detail to understand what that reception problem might be. This is the topic for the next section.


The Issue with the DMX Break Condition

Now let’s look at the task of receiving a frame of DMX data from a software point of view. We will assume that you have configured the hardware to receive RS-485 signals. The JNIOR Model 410 AUX port has RS-485 capability when properly wired and configured. INTEG can provide those details and those are mentioned in other articles. The JANOS operating system has also been enhanced to accommodate DMX and includes the 250 Kbaud rate setting as standard.

In the previous article JNIOR as a DMX Fixture we covered both the proper hardware configuration for the JNIOR Model 410 and the simple Java application software that might be used to receive a frame of channel data. We took that a step further and let the JNIOR activate relays in response to changing channel levels. It is here that we noticed a reliability issue and then spent time to understand it. We discovered that it is a limitation in the design of the standard UART and not something specific to our software or even the design of the JNIOR. Here we will review those findings and then in the balance of this article present a solution.

As you can imagine it would not be acceptable for the JNIOR to receive an incorrect channel value and act upon it. On stage you might create a flicker and distract the audience or worse trigger some elaborate effect at a totally inappropriate moment. Neither contribute to receiving good performance reviews. Well our first attempt at having the Model 410 serve as a fixture worked but occasionally there was a glitch. A relay toggled inappropriately and this lead to an investigation.

We started by attempting to validate the frame of channels. We know that the START CODE should be 0x00. So we decided to first test the START CODE. Well, 0x00 was not what we were seeing and this led us to understand that the UART is not able to properly receive data immediately following a Break Condition. Let’s look deeper into it.

Every description of the inner workings of the UART describes the reception of data beginning with the detection of the Start Bit. They state that “A Start Bit is detected as the falling edge of the signal” (which at that point is moving from a Mark condition to a Space condition from HIGH to LOW). This makes sense since this can be used to synchronize the baud rate and the UART once detecting the falling edge delays 1/2 bit time to begin sampling. The first reading is then LOW (0) since it is a start bit.

The UART then can proceed to receive data bits one after another starting with the LSB (Least Significant Bit or D0). Let’s assume that we are configured for 8 data bits and no parity as is the case for DMX. Once all 8 Data Bits are collected and the byte of data fully accumulated then next bit sampled is expected to be HIGH (1) as this is the necessary Stop Bit. The UART sees the Stop Bit and pushes the data to the output buffer and notifies the system that data can be read from the port. You can see how this follows from the first figure in this article repeated here.


Logically then you can see how the UART might go back into some ‘Start Bit Search Mode‘  in order to pass over any number of remaining Stop Bits and dead time between character transmissions.

We mentioned previously that in the case of a Break Condition the Stop Bits are missing. Here the UART receives 8 Data Bits or what it hopes are 8 Data Bits and then fails to detect the Mark condition signalling the presence of a Stop Bit. The typical UART then pushes the data to the output buffer and signals the processor that data can be read from the port. It also sets a Framing Error flag and well-written serial drivers handle the error accordingly.

Here is where your logical thinking might fail you. Once the UART signals a framing error you would like to think that it reenters the aforementioned ‘Start Bit Search Mode’. This would take the UART through the balance of the Break Condition and past whatever Mark After Break is present to the very next falling edge of the signal. This then allowing it to reliably and properly receive the very next valid byte of data. Well, surprise, it does not work that way.

Instead the UART continues to sample bits based upon its internal baud rate clock. It accepts the very next LOW (0) bit as a Start Bit and proceeds to process the following 10 or 11 bit times as another byte of data. This is why from the software side a Break Condition usually presents itself as more than one 0x00 byte each with an associated Framing Error. By itself this is not an issue as you can accept one or more Framing Errors as an indication of the Break Condition. In fact you could use this to detect a short Break from a long Break. But let’s look closer at what happens at the very end of the Break.

At the conclusion of an arbitrarily long Break Condition the signal returns to a Marking state. We have reached the Mark After Break but it is highly likely that the UART is still accumulating hopeful data bytes. Eventually it sees the Mark as a valid Stop Bit. The result is that a byte is then output by the port and there is no Framing Error. There is no way for software to determine if this is the first valid data byte (START CODE) or a bogus trailing byte formed out of the end of the Break Condition.

In testing we can see that this indeed is occurring. Since data bits are transmitted from least significant to the most significant, depending on signal timing this bogus byte can be seen to contain any one of the following: 0x00, 0x80, 0xC0, 0xE0, 0xF0, 0xF8, 0xFC, 0xFE or 0xFF. Perhaps you can see that this result depends on just what Data Bit the UART thinks it is receiving at the point when the Mark After Break begins. There is actually one additional case and that being when the data is actually the first valid data byte after the Break. This effect depends highly on the duration of the Mark After Break as well.

Matters can be even worse. In DMX512 the Mark After Break can be as short as two bit times or 8 microseconds. That means that it is possible that the UART does not even look for a Stop Bit until the signal is deep into the START CODE byte. Since the START CODE is itself 0x00 the UART might then grab one of those data bits as a Start Bit and, well, fail to receive several channels of data. How can this be? Are UART designs defective?

Well let’s not jump to that conclusion just yet. Let’s give the hardware developers the benefit of the doubt at least initially. First we should understand that once the computer industry embraced serial data communications use of the Break Condition fell by the wayside. Protocols used Start of Header (SOH) bytes and other means for synchronizing data blocks. These tended to include byte counts, error checking and even error correction. These days there is even data compression and data encryption. The Break Condition not only fell out of use but also started to disappear from serial communications documentation.

Meanwhile the industry started to look into the reliability of data transmission lines. In the early days RS-232 cabling was not what it is today and it was very susceptible to external electrical noise. Also remember that we were still using machines developed in the early half of the 20th century. These were power hungry electro-mechanical contrivances that spewed out electrical noise with reckless abandon. RS-232 signals often experienced data disruptions some as brief as an incorrect value of a single bit up to the loss of entire blocks of bytes. There were even situations where communications were completely blocked out for lengthy periods of time. Perhaps for as long as the nearby noisy equipment remained in use. This led to better cabling. It led to improved communications standards like RS-422. It prompted the need for error detection and motivated a lot of creativity on the error correction front. Simultaneously the Federal Communication Commission (FCC) put forth standards for controlling RF and electrical noise emissions and prompted certifications making new equipment meet the stringent requirements.

A UART design that utilized a “Start Bit Search Mode” fails to perform properly in a noisy environment. In the case when a Stop Bit is damaged by noise and thereby missed by the UART, an approach that accepts the very next falling edge as a start bit falls on its face. It fails to re-synchronize quickly. Many bytes of data then are lost even though electrically the signals are undamaged. Error correcting schemes just could not handle it. They determined that the current UART approach performed much better and, well, what is this Break Condition anyway?

We can only guess at how we got to where we are today. It is actually a surprise that a 50-year old protocol would still be as active today and it would still rely on synchronization techniques like the Break Condition. Of course it is not a really issue as DMX fixtures are developed to properly receive these signals. We are just a bit hampered in trying to use standard computer hardware. So what can we do about it? That is our next topic.


Correcting the DMX512 Protocol

We stand little chance of “correcting” the DMX512 protocol. With over 50 years worth of legacy DMX equipment out there a change in the design of the protocol is just not an option. The ability for DMX to inter-operate with standard computer hardware is just not that critical of a need. We have also exhausted any possible software solution to this issue. So what can we do? Some kind of hardware solution will be needed if we want to develop a JNIOR that can be used as a DMX fixture. What form will that take?

Obviously lighting fixtures all over the world read DMX channels seemingly without difficulty. So we know we can do it. Does this require a custom UART implementation in some FPGA component? Do we have to dedicate some PIC processor or other device to process incoming DMX bit by bit? Are there standard DMX chip level devices out there to make it easy? It certainly all cries out for some research. But first let’s see if there is some simple and creative way to address the issue.

The problem breaks down into two separate issues:

  1. The UART is unable to synchronize after a Break condition and reliably read the first START CODE byte.
  2. The trailing edge of the Break Condition can generate unexpected data not identified with a Framing Error.

Clearly if we use a Framing Error indication to signal the reception of a Break Condition and we are 100% assured that the next valid data byte is accurately representing the START CODE we are good to go. We assume then that the processor has enough horsepower to receive and buffer all 513 channels (if they are present) without error. This can be done with low-level interrupt routines avoiding any dependence on the processing load in the JNIOR. In fact all of this has already been implemented in JANOS and deployed into the field. Those techniques were tested in the prior article.

The Mark After Break condition specified by the DMX512 protocol is a minimum of 8 microseconds. That is just two bit times. This is unfortunate. If this Mark After Break condition were to be held at least 11 bit times (44 microseconds) then any UART would be assured of seeing some part of the condition as valid Stop Bits. The UART then would be guaranteed ready to receive the very next data byte which is the START CODE.

If we somehow could extend the Mark After Break that would insure the reliable reception of the channel data. That by itself is not enough since we know that the trailing edge of the Break Condition can generate a data byte that is not flagged with a Framing Error. This would confuse us as there is no real way to determine if this is the START CODE or a bogus addition to the stream.

Now if we could somehow limit the Break Condition to a single byte we would receive one and only one byte flagged with a Framing Error. The UART would not see an additional Start Bit and thereby insure that the next byte we see is in fact the START CODE. We know that the Break Condition is at least 88 microseconds at its shortest. That is exactly two data byte times (each of 11 bits = 1 start bit + 8 data bits + 2 stop bits). So if we truncated the Break Condition at exactly 44 microseconds which would generate 1 byte with a Framing Error, there is another whole byte’s worth of time that could be added to the Mark After Break. This would satisfy our interest in extending the Mark After Break for at least a byte time. At a minimum it would then be 52 microseconds (44 borrowed from the Break + 8 original microseconds).


The Hardware Solution

Our hardware needs to truncate the Break Condition. We need only hold it long enough to mask the first Stop Bit and thereby force the Framing Error. This needs to be achieved without risk of causing other Framing Errors. With a little thought we developed the following logic.


This circuit is inserted in the CMOS logic stream after the RS-485 receivers and before input to the UART. The RXD signal from the receiver enters at the left. We will use the OR gate (U7) to truncate the Break Condition. This will pull the signal HIGH at the appropriate time but otherwise allow the normal serial stream through. The output then is TXD to be delivered to the UART on the right.

The CD4024B (U6) is a 7-stage counter and it is reset (RST) or restarted with any HIGH Marking condition on the incoming data. This means that the count is not allowed to progress very far except during the Break Condition where there is no reset (RST). This in essence times the duration of the Break Condition. Note that when the output of the 7th stage goes high (count >= 64) the OR gate then pulls the TXD signal high effectively truncating the Break Condition. The signal output is then held HIGH until the Mark After Break arrives and resets the counter. At this point the incoming signal is HIGH and we have effectively transferred time from the Break Condition to the Mark After Break. This is exactly what we want.

The UART will throw the Framing Error as soon as the first Stop Bit is not detected. We don’t want it to see any potential Start Bit after that. To be safe then we truncate the Break Condition after the 10th bit time right after the first Stop Bit. This means that we must truncate the Break Condition precisely after 40 microseconds and this must occur at the 64th count when the 7th stage goes high. As it turns out 40 microseconds divided by 64 is 0.625 microseconds the precise period of a 1.600 MHz clock. Those are readily available. So we clock the counter with a 1.600 MHz signal using oscillator U4.

One last detail to consider. There is no upper bound on the duration of the Break Condition. That means that once we truncate the Break Condition we need to hold it for potentially a very long time. So we cannot allow the counter to continue to run. Once the 7th stage goes HIGH we need to hold it there. A second OR gate (U5) masks the incoming 1.600 MHz clock signal at that point effectively stopping the counting. And, miraculously, we’ve got it covered.

To test this we created a prototype adapter which implements an isolated DMX512 standard port. The signal passes through our circuit and then a standard RS-232 transceiver is used to communicate with the JNIOR AUX port. One advantage this has is that any Model JNIOR with an AUX port can be used as a DMX fixture. Whereas only the Model 410 supports RS-485 directly and can be used as described in the prior article.



Here the few components involved sit in the lower lefthand corner. These Surface Mount devices take up almost no real estate and this is perfect for a new model of the JNIOR sporting a DMX512 input. Okay, so does the circuit work?



Here we see another oscilloscope trace. The yellow signal is RXD as received from the RS-485 receiver. This is what enters the schematic from the left. The blue signal is TXD and what we will supply to the UART. This exits on the right of our schematic. The wider pulse in the center is our Break Condition.

On the yellow trace we see that the Break Condition supplied by the DMX network is about 100 microseconds and it is followed by a brief Mark After Break which looks to be somewhat less than 50 microseconds. We know that this signal is problematic as it is from the same source used in the prior article. Note here that the START CODE and all channels happened to be 0x00. So those high pulses are Stop Bit pairs.

Now the blue trace is the result. The Break Condition has indeed been truncated. The vertical cursor lines are positioned to measure the duration of the new Break Condition. On the right we see the delta-t to be the precise 40 microseconds we had hoped for. We can also see that the balance of the time in the Break Condition has now been added to the Mark After Break.

Does this allow the JNIOR to be used as a DMX fixture? In fact it does and there is absolutely no glitch or reliability concern. Here is a short video showing relays responding to a DMX channels. A channel value greater than 127 is used to signal closure of a relay. The JNIOR’s 8 relays are mapped to consecutive channels.


Of course this would need to be evaluated with a wide range of DMX512 signal sources. The Java application on that JNIOR in the video is essentially that discussed in the previous article. It would be useful to reiterate its operation but that is beyond the scope of this article. If you should be interested in using a JNIOR as a DMX fixture just let us know. We can likely supply you with one of these prototype adapters and the application programming is open source from us. If you already have a JNIOR then your are almost there.

Now we have everything that we need to create another JNIOR Model with its own Isolated DMX512 input!

We should note that not all UARTs are created equal. There are likely UART implementations that do properly handle synchronization after the Break Condition. If you have one of those then you are golden. In the case of the JNIOR we were not so lucky. While the adapter was described above as prototype we do have several that we can supply. It is not clear that there would be any long term demand for this. A model of the JNIOR directly providing a DMX512 electrically isolated input is now feasible and would likely include the circuit as described here. Contact INTEG to find out more.

Here is a very simple example of how we can use websockets in a client browser to interact with the JNIOR.  This example will demonstrate how to register a few event callbacks, connect, and display the messages that are received from the JNIOR.  To force a monitor message to get sent we added an inversion checkbox for Digital Input 1.  When the Inversion state changes the input acts as though an electrical signal has forced the state change.

The WebSocket connection now behaves like any other bi-directional TCP Socket.  All of the functionality of the JNIOR protocol has been implemented in the WebSocket protocol.  The binary implementation has been replaced by JSON.  This not only makes it easier to code and debug but it is more extensible.

Below we have a zip file containing a demo page.  The page shows the incoming JSON messages in the lower part of the page.  The upper part of the page contains a button that will invert input 1 in software thus simulating the input receiving an electrical state change.

The javascript for our demo page is listed below

        // or comm object.  The communication will be established to the device that serves this page.
        _comm = new Comm();

        // called when the connection is successfully opened
        _comm.onopen = function () {
            logToBody('comm opened');

        // called when the connection closed
        _comm.onclose = function () {
            _loggedIn = false;
            logToBody('comm closed');

        _comm.onerror = function (error) {
            logToBody('comm error: ' + error);

        // called when there is an error
        _comm.onmessage = function (evt) {
            var messageJson = JSON.parse(evt.data);
            logToBody('comm message: ' + JSON.stringify(messageJson));

        // called when the page has been loaded
        window.onload = function () {
            logToBody('init comm');

        // a function to create a div with a timestamped message to the messages section of the page.
        // The div will be prepended so that is is at the top of the section.
        var logToBody = function (message) {
            var el = document.createElement('div');
            el.innerHTML = new Date().toLocaleString() + ': ' + message;
            el.style = 'white-space: nowrap';
            var messagesElement = document.getElementById('messages');
            messages.insertBefore(el, messages.firstChild);

        // called when the user clicks the inversion checkbox
        function invert(checkbox, channelNumber) {
            var registryWriteJson = {
                "Message": "Registry Write",
                "Keys": {}

            registryWriteJson.Keys["IO/Inputs/din" + channelNumber + "/Inversion"] = checkbox.checked.toString();

wsdemo.zip [6 KB, MD5: 7f19c6f6a69e39fc795b88444fddfff2]

To run the demo simply place the downloaded .zip file in the flash/www folder on your JNIOR.  Then open your browser and navigate to http://[IP_ADDRESS]/wsdemo.

Using the zip file is taking advantage of another great feature of the JNIORs web server. A whole web application can be served out of a single zip file. This makes distribution and file management a lot easier.

  • Added ability to load single CA Certificate to be supplied on TLS connection
  • Support TLS Client Certificate Verification on outgoing connections
  • Added legacy PKCS1 support for externally generated certificates
  • Corrected array issue with processing of deferred email transmissions
  • Corrected memory issue with TAB use on the Command Line

Beginning with JANOS v1.6.4 you will be able to adjust the Time-To-Live (TTL) parameter used by the network stack.

The IpConfig/TTL Registry key defines the lifespan of a network packet. The time-to-live value is a kind of upper bound on the time that an IP datagram can exist in the Internet system. The value is reduced with the passage through a router. If it reaches 0 the packet is discarded. The default value has been increased to 128 from the value of 64 used prior to JANOS v1.6.4.

The TTL setting can be considered to limit the maximum radius (in terms of hops) of the network within reach of the JNIOR. The default setting should allow packets to reach the far end of the globe. A low setting would limit access to the unit as only those in the local vicinity could communicate. In this respect the TTL setting can be used to improve device security.

A very low setting of 1 or 2 would constrain the JNIOR to the local network. One must consider the need to reach Doman Name Servers (DNS) and Network Time Servers (NTP). There may also be the requirement for email transfers wherein the JNIOR needs to reach out to a SMTP Server. To help determine the minimum setting you may be able to use your PC’s TRACERT command to detect the hop count involved in reaching those destinations. The JNIOR does not support a route tracing function.

Real World Test

Luckily we have a neat way to test the effect of reducing TTL. We have a JNIOR we call HoneyPot sitting on the open Internet. Naturally it comes under a constant level of attack. For instance there is a fairly constant level of random login attempts on the Telnet port. On the JNIOR the Telnet port provides access to the JANOS command line interface. We log failed login attempts to a @/access.log@ file.

Log files on the JNIOR rollover to BAK files when they reach 64 KB in size. We keep only one BAK file for each log. Typically an application would archive BAK files when longer term logging is desired. A syslog server can be used for the system log @/jniorsys.log@ for longer term logging.

On HoneyPot we have an application that takes the access.log when it rolls over and analyzes the hosts attempting to log into the unit. IP addresses are added to a database (JSON based) covering data from the past 24 hours. The application uses a locating service to identify the geographical location of the host. A simple web page http://honeypot.integpg.com/map.php receives the database and uses the Google Maps API to plot these locations.

By default JANOS uses a TTL of 128. The map typically appears as follows:

If we reduce the TTL to 16 the map changes. Note that this seems to thin out the number of hosts able to communication with the unit. It does not seem to create a geographical radius.

The thinning effect is useful but one gets the feeling that systems within our own country may no longer be able to communicate with the unit.

The further reduction of TTL to 12 begins to suggest a geographical radius. Note in the following how the unit now seems to be invisible in China. This might suggest that our friends in far away places might actually be using shortcuts in the network to gain access to systems in the United States.

Of course, for a controller the most important aspect of this kind of security is whether or not YOU can access your own unit. In that case you might also use the IP filtering functionality of the device and limit access to only YOU.

One note. With the TTL limited to 16 the HoneyPot unit had trouble reaching some of the @pool.ntp.org@ NTP servers for synchronizing the clock. By limiting the radius of the network you may limit the useful services such as DNS and NTP.


So this test fails in that the service that is used to determine a location for an IP address is about 12 hops away. Here we see it is 13 from inside INTEG.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>tracert ip-api.com

Tracing route to ip-api.com []
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms
  2     1 ms     1 ms     1 ms  50-197-34-78-static.hfc.comcastbusiness.net []
  3    12 ms     9 ms     9 ms
  4    10 ms     9 ms     8 ms  te-0-1-1-1-sur01.westdeer.pa.pitt.comcast.net []
  5    32 ms    15 ms    15 ms  be-62-ar01.mckeesport.pa.pitt.comcast.net []
  6    28 ms    21 ms    37 ms  be-7016-cr02.ashburn.va.ibone.comcast.net []
  7    21 ms    20 ms    20 ms  be-10130-pe04.ashburn.va.ibone.comcast.net []
  8    20 ms    20 ms    19 ms
  9    61 ms    61 ms    72 ms  xe-0-2-1.cr2-kan1.ip4.gtt.net []
 10    62 ms    52 ms    51 ms  ip4.gtt.net []
 11    52 ms    53 ms    60 ms
 12     *        *        *     Request timed out.
 13    52 ms    51 ms    51 ms  us-mo-1.free.ip-api.com []

Trace complete.


And as a result with TTL restricted to 10 I get a lot of these errors.

04/05/18 08:29:12.949
** Uncaught java/io/IOException thrown: "Unable to connect to remote host"
   in java/io/IOException.<init>:(Ljava/lang/String;)V
   in java/net/PlainSocketImpl.connect:(Ljava/net/InetAddress;I)V
   in java/net/Socket.<init>:(Ljava/net/InetAddress;ILjava/net/InetAddress;IZ)V
   in java/net/Socket.<init>:(Ljava/lang/String;I)V
   in jaccess/JAccess.main:([Ljava/lang/String;)V at line 71

Just a note that I generally create application programs that are not destined for customer deployment with a throws Throwable clause. This insures that every exception is logged to the errors.log file and I don’t need to busy the code with try-catch structures. The application uses the com.integpg.system.Watchdog class which restarts the application after a timeout. You can see this in the system log up until I removed the TTL restriction.

In summary…

Reducing the TTL reduces the “radius” of the the accessible Internet but that does not precisely correspond to a geographic radius. Sites in Russia appear to have access to our Internet vicinity through less hops than some citizens in this country. Still it is a good defense in limiting access to the JNIOR so long as the resources your application uses can still be reached.

I had been thinking about this.

In testing by running with a low TTL we ran into problems where the JNIOR had difficulty reaching services it requires (like NTP) while locations perhaps even in Russia could still reach us. It seems to me that the standard large TTL should still be used for all outgoing communications. But a reduced TTL applied only to incoming connections. Specifically to UDP replies and TCP/IP SYN ACK responses. This would prevent distant (Internet radius wise) hosts from initiating connections or soliciting UDP replies.

The issue with UDP is that the original source TTL is unknown. So we cannot filter on it. The UDP would be received and would be processed. That packet would represent a vulnerability. All we can do is prevent any response from making it back to the malicious host.

To demonstrate an outgoing HTTP request I am going to use the IP Address Location service that our HoneyPot unit uses. This creates the JSONdatabase used to generate the map at http://honeypot.integpg.com/map.php .

The JANOS Runtime Library does not provide classes to handle different web requests. Perhaps over time we will supply external libraries for that. But, you can easily do that directly. And, it is probably more educational to know how things work at the low level.

The procedure is straight forward.

  1. Establish an outgoing socket. (Lines 19-22)
  2. Issue a minimally formatted HTTP request. (Lines 25-27)
  3. Read the response. (Lines 45-50)
  4. Use the data. (Line 53)
package jtest;
import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.net.Socket;
public class Main {
    public static void main(String[] args) throws Exception {
        // IP Address query
        String ipaddr = "";
        // Location services
        String serverHostname = "ip-api.com";
        int port = 80;
        // Establish a Socket, get streams, and set a timeout
        Socket dataSocket = new Socket(serverHostname, port);
        DataOutputStream sockout = new DataOutputStream(dataSocket.getOutputStream());
        DataInputStream sockin = new DataInputStream(dataSocket.getInputStream());
        // Issue the HTTP request
        sockout.writeBytes("GET /json/" + ipaddr + " HTTP/1.1\r\n");
        sockout.writeBytes("Host: " + serverHostname + "\r\n");
        // Process the response header
        int length = 0;
        String response;
        while ((response = sockin.readLine()) != null) {
            // Header ends with blank line
            if (response.length() == 0)
            if (response.startsWith("Content-Length: ")) 
                length = Integer.parseInt(response.substring(16));
        // Obtain the entire response (if any)
        response = "";
        if (length > 2) {
            byte[] resp = new byte[length];
            response = new String(resp, "UTF8");
        // Data (should be JSON)
        // Close the Socket
bruce_dev /> jtest
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Fri, 08 Dec 2017 14:01:58 GMT
Content-Length: 321

{"as":"AS7922 Comcast Cable Communications, LLC","city":"Pittsburgh","country":"United States","countryCode":"US","isp":"Comcast Business","lat":40.4406,"lon":-79.9959,"org":"Comcast Business","query":"","region":"PA","regionName":"Pennsylvania","status":"success","timezone":"America/New_York","zip":"15282"}

bruce_dev />

So you can see that the response is JSON and can be easily used.

If you replace line 53 with Debug.dump(response.getBytes()); which is the new dump method in the library the data can be more easily reviewed.

bruce_dev /> jtest
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Date: Fri, 08 Dec 2017 14:27:52 GMT
Content-Length: 321

 7b 22 61 73 22 3a 22 41-53 37 39 32 32 20 43 6f    {"as":"A S7922.Co
 6d 63 61 73 74 20 43 61-62 6c 65 20 43 6f 6d 6d    mcast.Ca ble.Comm
 75 6e 69 63 61 74 69 6f-6e 73 2c 20 4c 4c 43 22    unicatio ns,.LLC"
 2c 22 63 69 74 79 22 3a-22 50 69 74 74 73 62 75    ,"city": "Pittsbu
 72 67 68 22 2c 22 63 6f-75 6e 74 72 79 22 3a 22    rgh","co untry":"
 55 6e 69 74 65 64 20 53-74 61 74 65 73 22 2c 22    United.S tates","
 63 6f 75 6e 74 72 79 43-6f 64 65 22 3a 22 55 53    countryC ode":"US
 22 2c 22 69 73 70 22 3a-22 43 6f 6d 63 61 73 74    ","isp": "Comcast
 20 42 75 73 69 6e 65 73-73 22 2c 22 6c 61 74 22    .Busines s","lat"
 3a 34 30 2e 34 34 30 36-2c 22 6c 6f 6e 22 3a 2d    :40.4406 ,"lon":-
 37 39 2e 39 39 35 39 2c-22 6f 72 67 22 3a 22 43    79.9959, "org":"C
 6f 6d 63 61 73 74 20 42-75 73 69 6e 65 73 73 22    omcast.B usiness"
 2c 22 71 75 65 72 79 22-3a 22 35 30 2e 31 39 37    ,"query" :"50.197
 2e 33 34 2e 37 35 22 2c-22 72 65 67 69 6f 6e 22    .34.75", "region"
 3a 22 50 41 22 2c 22 72-65 67 69 6f 6e 4e 61 6d    :"PA","r egionNam
 65 22 3a 22 50 65 6e 6e-73 79 6c 76 61 6e 69 61    e":"Penn sylvania
 22 2c 22 73 74 61 74 75-73 22 3a 22 73 75 63 63    ","statu s":"succ
 65 73 73 22 2c 22 74 69-6d 65 7a 6f 6e 65 22 3a    ess","ti mezone":
 22 41 6d 65 72 69 63 61-2f 4e 65 77 5f 59 6f 72    "America /New_Yor
 6b 22 2c 22 7a 69 70 22-3a 22 31 35 32 38 32 22    k","zip" :"15282"
 7d                                                 }

bruce_dev />

By the way, the Lat and Lon returned by these sites varies in accuracy. We use the above as a free service. I believe that some services will provide more precise locations when used in a paid mode. The free data however is just fine when mapped on the globe (http://honeypot.integpg.com/map.php).

The HELP command provides basic information about syntax and options for each and every command. If issued without parameters it lists all of the commands available to you at the JANOS Command Line.

bruce_dev /> help
Available Commands:
  arp             bye             cat             cd              
  certmgr         chdir           chgrp           chmod           
  chown           copy            cp              date            
  del             dir             echo            egrep           
  exit            extern          find            gc              
  grep            groupadd        groupdel        groups          
  help            history         hostname        iolog           
  ipconfig        jar             java            jrflash         
  jrmon           jrupdate        kill            logger          
  ls              man             manifest        md              
  mkdir           mode            move            mv              
  netstat         nslookup        nv              passwd          
  ping            ps              rd              reboot          
  reg             registry        ren             rename          
  rm              rmdir           sendmail        set             
  setenv          stats           thd             touch           
  type            useradd         userdel         usermod         
  users           whoami          zip             

bruce_dev />

Note that this list depends on the user’s permission level. The list above covers all commands. It is displayed for Administrator accounts.

The list is reduced when not an Administrator. These are the command available to a user with the Control permissions flag.

bruce_dev /> help
Available Commands:
  bye             cat             cd              chdir           
  chmod           copy            cp              del             
  dir             echo            egrep           exit            
  extern          find            grep            help            
  history         java            jrmon           ls              
  man             md              mkdir           move            
  mv              passwd          ping            rd              
  ren             rename          rm              rmdir           
  stats           type            whoami          

bruce_dev />

And if you are logged in as a guest with an account that neither has the Administrator flag or the Control Flag then this is all you can use.

bruce_dev /> help
Available Commands:
  bye             cat             cd              chdir           
  dir             echo            egrep           exit            
  find            grep            help            history         
  jrmon           ls              man             passwd          
  ping            stats           type            whoami          

bruce_dev />

The HELP command has an alias MAN. JANOS wants to seem familiar to new users and so tries to be a bit flexible. For this reason both DIR and LS perform the same function.

If you provide the name of a command as a parameter details for that command are displayed.

bruce_dev /> help dir
DIR [filespec]

 -A             List all including hidden files
 -F             List only files
 -D             List only folders
 -L,-V          Verbose format
 -W             Wide format
 -S,-R          Include subfolders
 -X             Expanded includes path permissions
 filespec       May contain wildcards

Lists a file, group of files or the contents of an entire folder.
Aliases: LS, DIR

bruce_dev />

That includes itself.

bruce_dev /> help help
HELP [cmdspec]

cmdspec May include wildcards

Lists available detail for matching commands

The following special characters define the command-line syntax:

 [ ]    Identifies an optional argument. Arguments that are not enclosed in brackets
        are required.

 ...    Indicates possible multiple values for the previous argument.

 |      Indicates mutually exclusive information. You can use the argument to the left
        of the separator or the argument to the right of the separator. You cannot 
        use both arguments in a single use of the command.

 { }    Delimits a set of mutually exclusive arguments when one of the arguments is
        required. If the arguments are optional, they are enclosed in brackets ([ ]).

Enclose argument values that have embedded spaces with double quotation marks.
Aliases: HELP, MAN

bruce_dev />

The command string supplied to HELP may include simple wildcards. For example:

bruce_dev /> help j*

JAR filespec [pattern]

 -C             Check integrity
 -T             Lists library contents
 -X             Extracts library contents
 -V             Verbose

List/Extract files from a ZIP/JAR library.
Aliases: JAR, ZIP

JAVA filespec [&]

 &              Executes in background ('&' must be last on the line)
 filespec       Either a .class file or .jar library containing classes to execute

Executes the given Java program.


 -C             Display cache status
 -F             Format (all data will be lost)
 -R             Perform reclamation pass

Displays Flash File System status.


 -C             Enable control commands
 -D             Enable control including diagnostics functions
 -M             Monitors processor load
 -X cmd         Execute commands and return

I/O monitoring utility


 -U file        Perform Field Firmware Update
 -F             Skip confirmation prompt
 -P             Reboot if successful
 -R             Rollback OS
 -C             Cancel pending update

Manage firmware updates.

bruce_dev />

Along these lines you can create your own HELP manual. Here we will send the HELP output to a file which I will attach.

bruce_dev /> help * > help.txt

bruce_dev />


If you have a 310/312/314 Series 3 JNIOR you may also have its wall power supply. As we ship JNIORs in bulk we often supply them without the corresponding power supplies. Customers often use their own power sources. So you might just have the JNIOR or perhaps its original supply is still in service with a replacement Series 4.

By itself the JNIOR is not self explanatory. It’s a 6″ by 4″ by a little over 1″ black box with connectors filling the 4 sides. On the cover there are places for 18 LED indicators. You may recognize two DB-9F connectors for serial communications. You likely notice the CAT5 LAN connector. But the rest is somewhat mysterious. So what is next?

Typically we supply the JNIOR with a 12VDC Regulated 1A wall mounted power supply. Some series 3 are labelled with ‘9-24V DC/AC’ and some with ’12-24V DC/AC’. While the JNIOR will operate with a 9VDC supply that turns out to be too close to the low side and does not afford enough margin to insure reliable operation under all conditions. So at some point we made 12V the recommended low end.

The 4-position connector at the top of the unit is for the supply. The positive lead is connected to either of the left two positions (1 or 2) and the negative to either of the right two (3 or 4). We supply connectors wired to the center two positions, positive to pin 2 and negative to pin 3. The other two pins are there to allow you to tap this voltage for use in simple circuits involving the digital inputs or relay outputs as needed. Of course if an AC power source is used it is connected to pins 2 and 3 without regards to polarity.

One advantage to this particular design is that if you make an error and connect the DC supply backwards it will still work. Note though that the negative lead IS NOT circuit GND. More on that later.

Using any appropriate power source (and we all have a box of them laying around these days) the JNIOR should power up. A GREEN LED to the left next to the power specification will illuminate to indicate that power has been applied. We improved on this in the Series 4. The leftmost LED on the Series 4 is BLUE. That greatly enhances the product. :-)

Actually, it is hard to resist a BLUE LED. They were a rarity for many years. When we built the first Series 4 units the prototype boards were installed in Series 3 enclosures. I elected to use a BLUE LED for the power indicator so we could easily tell a prototype Series 4 from a standard Series 3. We have so many mounted around the office. It was supposed to be temporary but democracy prevailed and we were destined to leave it that way.

So power up your Series 3. If the LED illuminates then your internal power rails have reached their proper voltages. You should also see the rightmost LED (ORANGE) come on for a brief period. That is illuminated during the OS boot. It also flashes indicating connection status. More on that at some other time. The rest of the indicators are RED and will display the state of the corresponding input or output.

By the way if you have a Series 4 you will notice one other difference (besides the BLUE LED). When the Series 4 boots the ORANGE Status LED flashes on for no more than a second or two. That is because JANOS boots in just a couple of seconds and applications start in seconds.

The operating system on the Series 3 however can take minutes to boot. The ORANGE status LED only illuminating as the base TINI operating system loads and subsequently the JniorOS loads. Once that is done applications then load. The boot process is lengthy but the unit will get it job done.

So the Series 3 internal power supply is a bit unconventional. While we typically power the unit with 12VDC it is designed to be powered by an AC source. Here is the front end. I had to go back and reinstall OrCAD to get to these schematics. We use Altium for the Series 4.

It is important here to note that the negative (-) power supply connection IS NOT the same as GND.

Now that generally isn’t an issue as all of the JNIOR’s inputs are isolated and all of the outputs are dry relay contacts and therefore also isolated. The GND signal does appear on the serial connectors and on the Sensor Port. The external modules that are designed to run on our Sensor Port are also isolated. The bottom line is that you can possibly cause an issue if you ground (GND) the negative (-) supply lead and then also connect the GND pin of either serial port. This is also true with the Series 4 with the exception of the 412DMX that is currently under development.

Another issue that has been corrected in the Series 4 JNIOR is that the negative path is not fused. In this case if a grounding problem occurs and you use the GND pin of one of the serial ports you can cause high current to flow through the product. As mentioned this has been corrected with the addition of the second fuse on Series 4 units.

The VUNREG here supplies the rest of the power supply regulation. With a 12VDC regulated source VUNREG will be somewhat less than 12V but sufficient to power the regulator that generates the internal 5V rail. That was not true with a 9VDC source under some load. Thus, the change to a minimum 12VDC.

Another concern here is that if you use a 24VRMS AC source VUNREG becomes 34V challenging the 5V regulator to follow. This is easily worsened in an HVAC environment where the 24VAC supply can be an unloaded transformer with more like 30V+ RMS. VUNREG can exceed 40V and component ratings including the rating of the subsequent 5V regulator become a concern.

So run the JNIOR with a 12VDC 1A regulated supply and avoid issues. Use increased voltages with caution.

One does not need to use a Regulated external supply. That does insure though that you have precisely the voltage that you want. Unregulated supplies tend to vary more significantly in voltage than you would think from the nominal.

The internal 5V (VCC5) is used to power our relay coils. It if stepped down further to provide the 3.3V (VCC) and 1.8V (VCC1) rails that the processor and digital circuits require.

You can see here that the GREEN (BLUE in Series 4) Power LED illuminates when the 3.3V rail is powered.

The internal Series 3 power supply produces 5V at 0.75A (stepped up to 1A with Series 4) driving the rest of the product. In addition to relay coils the 5V is presented to the Sensor Port circuit as a source of power for external modules. The Series 3 also supplies the VUNREG to the Sensor Port which was not used and removed for Series 4.

To verify the supplies on the bench, power the JNIOR with 12VDC. You can check each rail across the associated capacitors as show below.

Here we note that VUNREG is approximately 10.6V showing the diode drops from the supplied 12V inherent in the full-wave bridge. The 5V (VCC5) and 3.3V (VCC) rails are nearby and easily checked. The 1.8V (VCC1) rail is developed at the far other end of the board as shown below.

That pretty much covers the power supply requirements, powering your JNIOR and testing voltages.

If you have a Series 3 that no longer functions, check carefully for evidence of damage from over-voltage or high-current in the area of the 5V regulator. The use of excessive input voltages can melt traces around the power connector. A grounding issue can cause damage to the 5V regulator U12 which can show physical damage. In these cases the JNIOR more than likely cannot be repaired.

In some cases the Power LED did not illuminate as a result of a bad LED or poor soldering. Voltages are otherwise as expected. Most of those failures are caught in production. A marginal solder joint can operate for some time but as pass production tests. But after aging it can present as an open circuit.

This power supply has proven to be very reliable. INTEG has seen an extremely small percentage in failure rate. In general, most causes have been tracked to improper external wiring and severe grounding issues.