At some point you may want your JNIOR to always have an output close or pulse, and when you reboot a JNIOR, they get reset. This post will show you how to have your JNIOR automatically close outputs from startup. If you’re looking for different information on the DCP, or don’t know how to access it, you can look here.

To start, make sure you are able to access the DCP (Dynamic Configuration Page) of your JNIOR. Then you’ll want to go to the Configuration tab of the DCP. Here we will be accessing the outputs section.

Here is where you can close or pulse outputs on startup. Simply add a zero to the Initial Action section for whichever channel you wish to close, and it will now always close that input on startup. To pulse the output on startup, simply add any positive value and it will pulse for that many milliseconds instead.

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 really an 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.


We can provide the adapter (as shown) along with a power supply and instructions.  The adapter can be used in any serial application and not just with the JNIOR however as discussed in the article you would need to accommodate the unique Baud rate and trap the framing error for synchronization. The document supplied includes an example application for the JNIOR and a schematic.

Note that straight-thru terminals are provided allowing you to tap either 3-wire or 5-wire DMX signals.  You may wish to splice into a DMX extension cable (not provided) to give yourself cabling terminated by the desired (3 or 5 pin) DMX XLR connectors. An isolated DMX port is implemented and so your JNIOR or PC is not directly connected to the lighting system.

The above kit is INTEG P/N A00-00155 – DMX512 SERIAL PRE-PROCESSOR.

The JNIOR Model 410, 412 and 412 each have two available serial ports. Each port providing at least a 3-wire RS-232 interface. A 3-wire connection contains only the Transmit (Tx), Receive (Rx) and Signal Ground (GND) circuits. This is the bare minimum for Duplex communication or interfaces utilizing software handshakes. The Rx line may be omitted if only sending data. Similarly the Tx might be omitted if only receiving data.

In addition to the 3-wire signals the AUX port supports optional hardware handshaking using the Request To send (RTS) and Clear To Send (CTS) signals. The Model 410 AUX port also provides a configuration for RS-422 and RS-485 communications.

While there are a number of parameters that must be properly configured in order to achieve functional and reliable communication, the biggest issue is (and has always been) proper cabling. If an RS-232 connection is not working and it is the first time the connection has been made, the connections are probably not correct.

Originally the RS-232 standard was created to support the connection of a modem. Before networking the modem was used to extend communications over standard telephone lines. Typically a computer (an IBM 360 for instance) would connect to a modem. At home a user would connect their terminal to another modem and establish a remote connection via dial-up. There are two types of equipment in this scenario: the computer stuff and the communications stuff (modems). The RS-232 standard defines two acronyms for this: DTE and DCE. These are used extensively to define connector types and signal definitions.

This is where the confusion begins. The acronym DTE refers to Data Terminal Equipment and in our example above this includes both the Computer and the Terminal (CRT or Teletype). That would be the stuff that you would be trying to connect together had you not needed the modems. The term DCE is often confused and is meant to refer to Data Circuit-Terminating Equipment or Data Communications Equipment. That being the modem in the above example. It does not stand for Data Computing Equipment which implies the computer. These terms are often confused and, perhaps, never really understood. As a result even the engineers who design the equipment (including myself) often employed the incorrect connectors, signal terminology and pin assignments. So let’s not use these designations.

JNIOR Serial Ports

The JNIOR has a COM port (labelled RS-232) and an AUX port (labelled AUX Serial). Both are DB-9F Female 9-pin D-sub connectors. The AUX port has 4 active signals and the COM port 2. The pin assignments are as follows:

2 >> RS232 TX / RS485 TX-
3 << RS232 RX / RS485 RX-
5    GND
7 << RS232 RTS / RS485 RX+
8 >> RS232 CTS / RS485 TX+

Here is how it shows on the schematic. Note that even the pin numbering on the the connector itself can be confused. The (>>) indicates an output. The JNIOR generates a voltage on this pin and it must be connected to an input at the other end. The (<<) indicates an input. This should be connected to an output at the other end. We will cover RS485 in a little bit.

You can see that we do not use DCD, DSR, DTR and RI. These are unconnected. The COM port follows the same assignments but ONLY pins 2, 3, and 5 are used.

Here is the source of additional confusion. The JNIOR transmits data on Pin 3 and therefore from the JNIOR’s point of view THAT is Transmit Data (TX or TxD). But when that signal reaches the other end (say your PC) it is incoming data or Receive Data (RX or RxD). That is because from the point of view at the PC it is data that would be received. So you connect RXD to TXD and visa versa.

Not everyone labels it that way. You will find an input pin labelled TxD. The thinking is that you would connecte TxD to TxD. After all you do connect CTS to CTS as the signal is Clear To Send regardless as to who generated it and who is listening to it. The same goes for Request To Send (RTS).

It is not surprising that we sometimes have to grab a voltmeter to see if a pin is generating an RS232 voltage level (an output) or not (an input). Even that can be misleading when pull-up resistors are used. I used to have a couple of really sweet RS-232 break-out boxes. Those have gotten lost but were life savers back in the day. You know, nice colored LEDs showing outputs and jumper wires that you could use to test various cabling solutions before soldering the final cable.

JNIOR to PC Connection

Well today if you want to connect the JNIOR to your PC you will need a USB-To-Serial adapter. You would likely want to do that to gain access to the JANOS Console (command line interface) available over the COM port (115.2Kbaud, 8 data bits, 1 stop bit, no parity). The adapter will present you with a DB-9M Male connector identical to what you would have found on an older PC as a COM or AUX port connection. The connector (DTE) can be directly plugged into the JNIOR COM (or AUX) port (DCE).

Some USB-To-Serial adapters provide a length of cable and others are relatively short. If you need a longer cable then you either use a USB extension or an Male-To-Female Straight-Thru Serial Extension cable. The latter would need only be 3-wire unless your application optionally employed the hardware handshake. I will cover that a little later.

You would use this same approach to connect the JNIOR’s AUX port to a PC-based media server or other system that uses the standard PC serial ports. An application on the JNIOR can then send and recieve data or commands to the remote server.

Connecting a Device to the JNIOR

If you plan to connect a barcode scanner or other device to the JNIOR then you might need a little help. You may need a 9-pin Gender Changer. There are two kinds: F-F and M-M. You may need the Male-To-Male (m-M) Gender Changer. This has pins on both sides and when plugged into the JNIOR it changes the connector from a Female DB-9F to the equivalent of a Male DB-9M. Unfortunately this does not alter the pin assignments and if the device was designed to be plugged into a PC then you will need a cross-over adapter or cable. The cross-over exchanges pins 2 and 3 (as well as 7 and 8). Remember that you want to always connect an output to an input. Sometimes this is called a Null Modem adapter, the name coming from the need to interconnect two DTE devices without modems.

Perhaps in hindsight it would seem that the JNIOR AUX port should have been DTE. In fact in the beginning we did not use a DB9 connector at all and provided screw terminals for the 5 signals since we would be required to connect to either DTE or DCE. The reality is that in Cinema (which was an early and big market for JNIORs) we connected often to media servers (which are essentially PCs) and the current DCE arrangement worked best for those customers. That stuck.

So as a result you end up with stuff like this.

Of course if you are handy with the soldering iron and get some solder-cup DB9 connectors and hoods from Digi-Key, you can clean this up nicely.
They had hoped to solve all of this with USB but that has created other issues.

It didn’t help RS-232 that from the beginning no one fully understood how to document it. Some of us might remember the detailed signal diagrams explaining plus and minus 12V states, start and stop bits, and little endian order in the back of manuals. That level of detail was just adding to the confusion.

Here is a modern day failure. This is from a product received in 2017. At first glance you would think this is good documentation.

Here only the boldface signals are available or can be used. Perhaps only those should be shown. But beyond that picky item the important piece that is missing is any indication or what is an output and what is an input. You can naturally make your own assumptions. You might correctly assume that Received Data (RxD) is information generated (or output from) the remove connection and therefore an input at this connector. The TxD would then be an output. I mean you only have two choices here and chances of being correct are 50/50. If you are working a soldering iron though you won’t appreciate making the wrong guess.

It is not so obvious as to whether the CTS or RTS connection is an input or output. These signals are shown here but are they used? Are they required? Is there an option setting some place of which you should be aware?

So if you have the diagram for the other piece of equipment that you are connecting should you wire straight thru? Do you wire TxD to RxD and vice versa? If that ends up crossing over from pin 3 to pin 2 and vice versa should you also cross over RTS and CTS? Who knows. RS-232 failure.

My point though is that this nice little picture doesn’t eliminate the chance that your cabling or the cable you make might not work. And, if it doesn’t work you don’t have enough information to decide what to change. Come on man! You can do better.

We’ve been experimenting with ride-thru power supplies. Basically the JNIOR continues to run after power is removed even though the unit is not battery powered. The hold time is relatively short and only a matter of seconds depending on the load on the supply at the time. But it is sufficient to weather short power outages and glitches that would otherwise cause the JNIOR to reboot. This ride-thru supply design makes sense for controller applications. It may save you the cost of a UPS if dirty power appears to be your issue. It will debut for INTEG in our 412DMX JNIOR.
One advantage of this is that we know when power has been removed or lost. We also know when it has been restored. That means we can now tell if the JNIOR has been left powered off and then booted up by looking at the log. With product without this technology you cannot tell from the log if there was a spontaneous reboot or what may have occurred.
This 412DMX prototype (the first) had been off for a couple of days and, well, it can’t hide that fact.

We see now that the unit was powered down for roughly 74 hours. When NTP re-synchronized the clock it had gotten 2.87 seconds fast. That is an error of about 1%. It goes to the importance of clock synchronization through NTP. If your JNIOR does not have access to the Internet and the host of NTP servers out there, maybe there is one on your internal network. If not perhaps there is another approach you can use to keep accurate time.
It is surprising that in this day and age that clocks in our computers are not much more precise. Some devices now get accurate time through the GPS system. Others over the cellular networks. Nether are generally available to a JNIOR. Don’t ask me about the RTC in the Renesas RX63N. I’ll go off on a rant!
So here is what you would see for a brief power outage. In this case the JNIOR never skipped a beat. There was no reboot and the DCP never had to reconnect.

Here power was out for some 7 to 8 seconds (I yanked the plug). Subsequently the ride-thru supply recharged itself so it would be ready to do it all over again.
Okay, not so impressive given that we are spoiled by all of our battery devices like phones, tablets and laptops. But there isn’t the cost of the battery nor the risk of fire. And, given that the JNIOR controller is generally powered 24/7 that extra hardware isn’t justified. But it does piss you of when the power company decides to reboot all of your unprotected equipment when the reconfigure the Grid. This handles that.
By the way, this R00 prototype has a 5F capacitor in which it stores the holding energy. The R01 prototype has 10F and that is likely what we will be shipping. You can see here using the STATS command that the average hold time for the 5F unit is about 12.5 seconds (no real load). The 10F units pushes 20 seconds.

Did you know that every JNIOR since the beginning of time has used the same isolated digital input design? It is not that this design is particularly special. It is more that a better one hasn’t been suggested or required.

Here it is from external connector to the RX63N processor pin (right to left).

The input is optically isolated by the device U12. That means that you can bring a signal from a distance and not have to worry about it being referenced to any local GND. You won’t create any ground loop. There is no common connection between signals (they all need not be referenced to GND). To activate the input then all you have to do is turn that LED on.

The diode D34 protects the isolator LED from high voltages. You can put 30V on this input and not risk LED damage. The extra voltage above 5V is dropped across the 910 Ohm 1 Watt resistor. The input is limited by that 1W power rating. The maximum voltage is 35VDC. And 1 Watt is a lot of heat so you probably want to limit the amount of time that the input sits at that voltage.

To deal with that limitation you could add a series resistance. The maximum voltage is 5V above the square root of the series resistance assuming 1W resistors. So if you want to sense the presence of a 120VAC signal you might insert a 20K series resistance. I will leave the Ohm’s Law exercise to you. Just make sure that you can dissipate the power.

The input can be considered to have about a 1200 Ohm input impedance. It is not a high-impedance input. Therefore any signal used to drive an input must be able to deliver current into a 1200 Ohm resistance and turn on the isolation LED.

The circuit after the isolator creates a 2 KHz low-pass filter. Basically we’ve specified that input signals should not exceed 2000 Hz. The reasoning behind this lies in the need to be kind to the processor. Each input transition generates a software interrupt and executes some code. This allows JANOS to know when the state of the input changes, perform some debounce, and log the event. If this happens too fast the system can be overwhelmed having to execute interrupt code back to back and not get anything else done. That’s not ideal. So the hardware prevents it.

The processor can handle faster signals to be sure. But not if several of the inputs are cranking like that. Besides, the JNIOR is not targeted into applications that process high speed signals.

Now the RED LED that you see when the input is active is driven by the output of that filter. In other words, if the after the filter the hardware thinks that the input is ON then it turns the LED on. So those LEDs are software driven. They illuminate when the input is high enough to activate regardless of how the input is configured internally.

I’ve been meaning to see if there is a more cost-effective and compact implementation for that filter. It was implements old-school with separate gates. Works though.

The input signal then interrupts the processor. In the Series 4 each separate input has its own interrupt channel. That was not the case in the Series 3 where we had some trouble insuring that all of the input channels were properly counted when triggering simultaneously. There is no issue in the Series 4. Each input can be configured.

This shows the input signal processing. In this case we go from left to right. The DIN input generates interrupts. It can be optionally inverted by configuration prior to the debounce logic. This is consistent with the Series 3. Logically though you might want to invert an input afterprocessing. That inversion can be performed by the Conditioning block which finalizes the input state for the system. This is an extension in the Series 4.

The debounce delay by default is set to 200 milliseconds. Basically when an input that has been in one state for a while changes the new state is recognized immediately. The debounce timer then is started. During the delay time additional transitions restart the debounce timer and those state changes are ignored. The reported state is then refreshed once the timer does expire. The trigger is rearmed at that point.

This debounce approach effectively stretches an input pulse until it has been stable for the delay period. So if you want to detect the presence of a 60 Hz AC signal then you need to set the debounce delay long enough to ignore the time when the AC signal does not drive the input. That would be at least 17 milliseconds.


Input Latching is optional. When not enabled the function is bypassed as indicated in the flow diagram. When enabled it can be configured to latch either the HIGH or LOW state. Once latched the input state will remain the same until the input is reset. This would allow you to catch and deal with a pulse or otherwise not lose track of the fact that some alarm condition had triggered.

The latching can be configured to time out. This will latch a pulse and allow it to reset itself after a period of time. You can use this to stretch a short pulse so logic downstream has the time to detect it and to deal with it.


Once the input has been debounced and optionally latched it will be counted. The counter can be configured to count a LOW to HIGH transition (0->1) or a HIGH to LOW transition (1->0). Each counter can be reset to 0 or set to any initial value. These can even be manually incremented by an application.

When counters are displayed they can be scaled and shown with unique units. A counter can trigger an alarm when it reaches predefined values. Alarms can send email notifications.


The Usage Meter totals the length of time that an input has been active. You can tally time for the HIGH state or for the LOW state depending on configuration. Usage meters can be reset to 0. This can be useful in monitoring the operating time of a piece of equipment. An alarm can be triggered when the usage meter reaches a configured amount of time. Alarms can send email notifications. This could be helpful as a reminder for the performance of preventive maintenance.


All input and output signal transitions are by default logged. The IOLOG command can be used to review I/O activity.


Finally the input state can be conditioned (Series 4 only). Here the input state can be optionally inverted or forced to a HIGH (1) or LOW (0) state. The forced states may be of use in debugging applications or disabling an input without having to physically disconnect it. A forced input is masked but continues to be counted and metered.


Note that alarms are available for Counters, Metering, and Input State. Alarms can be configured through the Registry or DCP. These can send unique email notifications.

In summary…

A digital input seems like it is a simple thing with just a HIGH or LOW input state. There is however a lot more to it. We have seen here what effect the hardware has and how the input can be configured. All of this before the input state ever affects any application.

A controller depends on the availability of good clean and stable power. Unfortunately with the JNIOR any small interruption or glitch in the power source results in a reboot. Applications need to be written to handle unscheduled restarts.

The recommended solution is to place all critical systems on an Uninterruptible Power Source (UPS) like those available from APC.

Things like air conditioner compressors can cause momentary dips in local power. The amperage of the power circuit and distance from the subpanel come into play here. The voltage available at the end of wiring that operates near its rated current or that may be lengthy tends to be easily affected by current surges. The voltage drops very briefly. That minor drop can be significant enough to reboot a JNIOR located on that circuit. And, the addition of a separate UPS means extra cost.

The 412DMX model of JNIOR is being developed and here we are testing the new internal power circuit. This JNIOR will incorporate “ride-thru” power supply technology. Regardless of the selection of buzz words that we use to describe it, the basic function is to store enough energy to keep the JNIOR powered through a momentary loss of external power. The implementation will flash the blue power LED to indicate the loss of external power. If power is restored before the stored energy runs out then the JNIOR continues unaffected. The loss of external power and its restoration are logged in the system log. Here we let it run out to see how long we really have.

Can you do that? Does it work? Well observe the first prototype:

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.

The Series 3 JNIOR is no longer in production. The 310, 312 and 314 have some time ago been replaced by the much more capable Series 4 models 410, 412 and 414. All versions of JNIOR utilize a 3V Lithium cell as battery backup for the time clock and the RAM based portion of the file system. While the Series 4 employ standard coin cells (CR2016 or CR2032) that can be easily replaced with batteries available from your local convenience store, the Series 3 batteries are soldered in place.

The one shown here is dead. So DEAD in fact that you can barely detect the 0.008 volts that remain.

These batteries were expected to last 10 years in the typical JNIOR application where the unit remains powered 24/7 or nearly so. In applications where the JNIOR is powered less than 8 hours per day these batteries need to be replaced after about 6 years of service.

Note that the battery IS NOT required for product operation. In situations where the time clock needs to be accurate (scheduling) then units should be updating their clocks from a separate time server (NTP) through the network. The clock will be set after booting. The RAM based portion of the file system retains log files which are normally only necessary for debugging. Those files need not be retained through power loss.

INTEG no longer has inventory for these batteries. It is not cost effective for us to replace them.

If you feel confident using a soldering iron, these batteries can be replaced.

The original battery was Panasonic BR1632A/HAN and is currently not in stock at DigiKey. However, you can use the Panasonic BR-1632/HFN battery and at this writing there appears to be sufficient stock. These are less than $2 in quantities of a few.

You can however use any 3V battery source. You might add wires to accept wired batteries. You might even find a coin cell holder to fit. The pin spacing is 15.2mm. But since you will likely not need to replace the battery or another half dozen years you might not get too fancy.

Desoldering is tricky. First of all the solder has a high melting temperature due to its RoHS nature. Secondly the (-) GND terminal connects to the ground plane which represents a fair heat sink. It will take time and a lot of heat to loosen the negative battery terminal. Replacement is simpler if you first carefully cut the existing battery off of the board. The positive lead can be removed easily with the simplest desoldering equipment. The negative lead will take some effort. I end up using a hot air soldering iron in combination with a desoldering station. Be patient. It can be done.

Even though an old battery may be dead it should be disposed of properly. Most instructions for Lithium cell displosal are referring to serious batteries like that for your laptop computer. Those may require a more complicated procedure. If necessary in this case you can simply wrap the battery with tape sufficient to prevent the accidental shorting of the contacts and toss it out with your trash.

There is one additional note of caution. You will note that there are surface mount components under the battery itself and near the terminals. Care must be taken to not disturb those components. Don’t damage them if you go to cut the battery off of the board. Watch that you don’t apply so much heat to the terminals that you loosen the surface mount components. Apply heat only to the rear of the board.

If you damage those circuits you will impact product operation.