Super Mini-Node Interface Card (SMINI) - Part 3
Click HERE to download a printable copy of Chapter 4.
Super Mini-Node Interface Card (SMINI) - Part 1
Super Mini-Node Interface Card (SMINI) - Part 2
Super Mini-Node Interface Card (SMINI) - Part 3 <- You are HERE
USER'S MANUAL v3.1: CHAPTER 4
SUPER MINI-NODE INTERFACE CARD (SMINI): Part 3
ADDED RESEARCH REQUIRED TO BEST APPLY USB TO C/MRI APPLICATIONS
There are a large number of USB to RS232 and USB to RS422/485 Converter Cables on the market and a significant number of C/MRI users are successfully using many different brands. However, based upon my discussion with many users and postings to the C/MRI User’s Group, it appears that some brands work fine for some users while the identical model does not work as well, or it might even work better, for other users. The problems encountered appear often to be software related in terms of:
- Which computer operating system is being employed with which cable, and
- The capability and universality provided within the “Device Driver” software supplied with the particular converter cable and the corresponding level of provided customer support.
Personally, I avoid the very low priced converters in anticipation of lower level customer support. In general, there appears to be two different brand of processor ICs used within the converters, “Prolific” and “FTDI”. Although I am not sure of how universal is the thinking, C/MRI user Jean-Francois posted in Message 13368 to the C/MRI Group that the “FTDI” based devices are a lot simpler to install. Although far from conclusive, my observations seem to support his input.
Because user experience varies between different brands of converter cables and even when using the identical model number device it is difficult to make specific recommendations. However, for the benefit of alerting users to the potential challenges that they might face in trying to incorporate USB converter cables, I will discuss my latest findings. Remember however, that the experience of others may be entirely opposite. With more experimentation and research efforts being performed by other C/MRI users, what is found as unworkable today may very well be workable tomorrow. Additionally, a simple wiring error or an incorrect parameter set in the driver software may lead to reporting that a particular converter doesn’t do the job. Then, later on, when the error is corrected the converter may provide good performance.
To support my own experimentation, I purchased five different USB Converter Cables but found none that really performed to my high-level expectations. Most functioned successfully when connected to a single node used for testing I/O cards, but failed or were unreliable when attached to the large multi-node SVOS application involving 7 nodes with 134 I/O cards supporting nearly 3800 I/O lines.
- The USB to RS232 cables that I purchased include www.cablestogo.com Part Number 26886, www.usconverters.com Model UT880 and www.Keyspan.com Model USA-19HS.
- The USB to RS422/485 cables include the USConverters Models UT890 and U485G.
One design feature I like with the UT880, UT890 and U485G is their having three display LEDs. One illuminates when power is applied, the second when data is flowing from the PC and the third when data is flowing to the PC. I find these display LEDs very useful when checking and debugging system operation. By contrast, the Keyspan USA-19HS has a single LED that blinks when data is being transmitted or received and the Cables-to-GO has no display LED.
I did find when first attempting to use the Cables-to-Go converter, with my Laptop operating with VISTA, that I received an “Error 820” message when trying to read C/MRI data to the PC. A quick email to techsupport@cablestogo.com instructed me to download a new driver for Vista which after doing so solved the “Error 820” problem but I still could not read input data.
Taking advantage of Message 13358, as posted by Jean-Francois to the C/MRI User’s Group, we downloaded the two Microsoft updates which he found required when using USB with Vista and VB6. However, our experience so far is that even with these updates installed, we still were unable to read input data from the large SVOS system using the Cables-to-Go converter cable.
C/MRI User Chris Elliott posted with his Message 13479 to the C/MRI User’s Group denoting a “little gem” he found on the JMRI list that said: “Some of the newer adapters require the following pins connected together DSR-DTR (pins 4 and 6 on a DB9) and RTS-CTS (pins 7 and 8 on a DB9)”. However, with just so many other avenues to investigate, and publication deadlines looming, we have not yet taken the opportunity to continue with such testing to see if making these added connections or following some other avenue-of-attack solves our problem when using the Cables-to-Go converter.
By contrast, once we installed the driver software that came with the USConverters Model UT880, we found that it worked right-out-of-the-box in communicating in both directions with the SVOS. However, the resulting real-time loop response was very sluggish. Typically, and as covered in the Railroader’s Application Handbook in detail, the iteration time of the real-time loop on the SVOS using VB6 and operating at 28800 baud is .26 seconds. Out of the total .26s, the actual serial I/O time (the physical time it takes to transmit and receive data over the RS232 lines, including overhead) is .19s and the internal processing time of the VB6 application is .07s.
With everything else held identical except for substituting the UT880 in place of the direct RS232 connection, the loop response time increased from the .26s up to 1.68s. This is unacceptable. For example, you need to hold a “pushbutton pressed” for close to 2s to be assured that the button press was recognized by the application software.
An email to the support team at mail@usconverters.com came back with the following response: “Thank you for your detailed description (of your problem). I understand what you mean. There will always be latencies with using a USB to serial adapter because of the drivers and data conversion. Unfortunately, there is nothing we can do to improve the adapter itself, we would have to find you another high-speed adapter that fits your exact application.” Then they went on to suggest other converter cables that I should purchase for testing to see if they did a better job. Well, one could go broke pretty fast following that approach.
While waiting for the response, we sought support from the C/MRI User’s Group. Bob Jacobsen, one of the responders and the founding creator of JMRI, provided significant input with his explanation in Message 13552 that:
|
“Serial-to-USB convertors have to decide when to forward the input data to the computer. Ideally, this would be done on each character, but some adapters default to only forwarding when a control character is received, and some default to only forwarding on CR or LF. Since C/MRI messages don't end in a CR or LF, that last type can delay reception until a timeout expires, typically 250 msec. It sounds like that's what's happening here. activeSerialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);” |
Based upon Bob’s input, we delved into implementing his recommendations, first via the driver software supplied with the UT880. Low and behold, and certainly not told to us by the USConverters’ support team, the UT880 driver software provided an option to set the Latency Time. Adjusting the Latency Time from its “default” setting of 16ms to the lowest accepted setting of 1ms, resulted in a loop response time change from 1.68s to 1.2s. A significant improvement, but still far short of that required for acceptable real-time response.
At that point in our test/experimentation process, we received the Keyspan USA-19HS USB to RS232 adapter that is advertised as “Low Latency”. Using its driver’s “default setting” the measured real-time response was .9s. We then changed the driver’s “compatible interrupt” setting to “high performance bulk” and the timing improved to .84s. Next, changing the “Transmit Completion Timing Advance (TCTA)” from the default setting of “standard” to “faster” the timing improved to .5s. Lastly, changing the “receive First-In-First-Out (FIFO) buffer size” from its default value of “16” to “none” improved the loop time to .46 seconds.
When operating at the .46s rate, we could very acceptably move levers and press code start buttons on both the US&S and the GRS CTC Machines, and operate the three N-X Interlocking Machines and achieve acceptable system performance. That made us pretty happy.
To further test the Keyspan converter, SVOS Operator Don Jones moved it to our Laptop computer operating with Vista. With the identical VB6 application software operating the railroad, Don cycled through all combinations of the “driver options”. The best loop response achieved was .46s, which is identical to that achieved with the XP machine. Additionally, the options that provided this response were, “high performance bulk”, “TCTA = faster”, and “FIFO” set to 16 although a setting of 56 provided the same results. However, reducing “FIFO” to “none” increased the loop time from .46s to .58s.
As we will see in a following section, I am very confident that if the Keyspan Driver software would permit changing from “high performance bulk” to “isochronous transfer”, that we could achieve significantly faster real-time loop response. However, to date, I have not yet located a USB Converter Cable that permits Isochronous Transfers. C/MRI serial system specialist Alan Anderson is supporting this research with a special test setup that he is generating.
Besides its improved operation, the Keyspan USA-19HS provides a downloadable 34-page Users Manual. Additionally, a “Keyspan Serial Assistant” software package is provided that can capture and display the bytes going and coming on the port. It includes timestamps and has good “display” and “save to file” features. The “Open Data Monitor Window” sets up the traffic capture feature.
SUBSTANTIAL USER TESTING USB APPLICATION
Another point of reference is the extensive testing performed by Ken Cameron, who among his many activities supports a C/MRI system on Jim Heidt’s freelanced Ogdensburg and Norwood Railway which was a real railroad name that Jim’s family owned for years that ran between Ogdensburg, NY along the St. Lawrence River to Norwood, NY where it interchanged with Penn Central. Its 5-node C/MRI system comprises 3 SMINI cards, an SUSIC with 5 DOUT32 and 1 DIN32 and a second SUSIC with 1 DOUT32 and 1 DIN32. The system’s function is to monitor 85 DCCODs and 50 turnout sensors and control all wayside signaling. Also, part of the job of the one SUSIC node is running 27 stepper motors that drive the room lighting dimmers and another 6 for clock speed control. Everything feeds into and out of JMRI via the C/MRI.
Two different computer setups are employed with the data for each summarized as:
- 800MHz Pentium running Windows ME, JMRI 2.9.6, on Java 16.0_17, and a real RS232 serial port operating at 19200 baud and using the default settings within JMRI for the serial port control. The real-time loop cycle time for this set up using RS232 Serial Port is .2695s seconds.
- Dual Core 2.6GHz computer with USB2.0 ports running Windows XP, JMRI 2.9.6, on Java 16.0_20 and incorporating the Keyspan USA-19HS USB to RS232 Converter Cable operating at 19200 baud. The real-time loop cycle time for this setup using the USB Converter Cable is .1564 seconds.
The first setup is used to support normal railroad operations and the second, making use of a laptop, is used for application program development and system debugging.
What is encouraging regarding Ken’s data is that he is achieving faster real-time loop response when using the USB port than when using the RS232 port, albeit on a much faster computer. Based upon Ken’s findings, it might be safe to assume that as computer speeds increase, the applicability of USB to adequately handle real-time requirements will become increasingly attractive.
To obtain a better handle on equivalent timings using the same computer, Ken set up additional testing using a computer having both an RS232 Serial Port and a USB connection. For the record, it was an IBM Thinkpad A21, 200MHz P3 Pentium with 384Meg RAM operating with Windows XP. The real-time loop cycle time when using the RS232 Serial Port setup was .13 seconds and when using the Keyspan USA-19HS Converter Cable was .16 seconds. Table 4-9 summarizes the data that Ken collected.
Table 4-9. Loop timing test results for different computers and port connections[1]
|
Computer (see text for details) |
Operating System |
Computer’s Port Connection |
Loop Timing (seconds)[2] |
Programs Internal Processing Time[3] (seconds) |
|
Pentium 800MHz |
Windows ME |
RS232 |
.27 |
.19 |
|
Dual Core 2.6GHz |
Windows XP |
USB2.0 using Keyspan USA-19HS |
.16 |
.08 [4] |
|
Pentium 200MHz |
Windows XP |
RS232 |
.13 |
.05 |
|
Pentium 200MHz |
Windows XP |
USB1.0 using Keyspan USA-19HS |
.16 |
.08 [4] |
[1] All test data supplied by joint C/MRI and JMRI user Ken Cameron with all testing conducted with a C/MRI System consisting of 3 SMINIs and 2 SUSICs with 8 I/O cards (32-bit) using a baud rate of 19,200
[2] Loop timings are rounded to the nearest .01 seconds.
[3] Assumes theoretical serial I/O time, as calculated below, of .08 seconds (rounded to nearest .01 seconds)
[4] Includes possible added delay resulting from USB Converter Cable
Numerous conclusions can be reached by studying the results presented in Table 4-9:
- All four loop timings listed in Table 4-9 yield acceptable performance,
- However, when the same computer is used for both tests as indicated with the last two rows, the operation with the USB cable is slower by 23%.
- Also of special interest is that the performance with the 200MHz Pentium, both with RS232 and with USB, is significantly faster than the performance provided by the 800MHz Pentium using RS232. This result may be attributed to non-optimality of the Windows ME operating system applied to real-time applications.
- Equally interesting is that there is no measurable improvement in loop timing when using the 2.6GHz Dual Core processor with USB2.0 as compared with the 200MHz Pentium using USB1.0. It would appear that both performances are being limited by the performance of the Keyspan USA-19HS.
To expand a little on the last conclusion, it is important to understand that in every application, there is a portion of the loop timing that is essentially independent of computer speed. This is the actual transition time that it takes for the bits to be transmitted to and from the railroad. This time is dependent upon the baud rate, which is the number of bits that are transmitted per second, and not computer speed.
Table 4-10 shows a “work table” that can be used for calculating the theoretical Serial I/O time for any C/MRI system as a function of its number of nodes, the overall compliment of cards making up the nodes, and the baud rate being employed. I have filled out the table, using the numbers noted in italics, for the C/MRI system used for collecting the test data shown in Table 4-9. For those interested, the derivation of Table 4-10 is presented in Chapter 15 of the Railroader’s Application Handbook.
Table 4-10. Serial I/O time calculation for Ogdensburg and Norwood Railway
(Employing 3 SMINIs, 2 SUSICS and 8 I/O cards (32 bit)
|
Arithmetic Function to be performed: |
No. of Bits and Serial I/O time |
|
Enter total number of 24-bit I/O cards here __0__ then multiply by 30 |
0 |
|
Enter total number of 32-bit I/O cards here __8__ then multiplied by 40 |
320 |
|
Enter total number of SMINI cards here __3__ then multiplied by 90 |
270 |
|
Enter total number of serial nodes here ___5_ (including all USIC, SUSIC and SMINI nodes) then multiply by 180 to determine total number of “overhead bits” per pass through real-time loop |
900 |
|
Perform addition of the above 4 entries in the rightmost column to arrive at the total number of bits that need to be transmitted each pass through the real-time loop |
1490 |
|
Enter the baud rate here ___19200___ (with valid entries being 9600, 19200, 28800, 57600 or 115200) and use it to divide into the above total number of system bits to arrive at the serial I/O time in seconds |
.0776s |
Table 4-10 shows us that communicating with 3 SMINIs and 2 SUSICs with a combined total of 8 I/O cards of 32 bits each, requires 1490 bits (calculated as 590 data bits + 900 overhead bits) being transmitted to and from the railroad every pass through the real time loop. At a transmission rate of 19200 bits/sec, the theoretical serial I/O time is calculated as 1490/19200 or .0776 seconds. This is the actual time it takes for RS232 to transmit all the required I/O bits, including overhead, between the PC and the railroad each pass through the real-time loop.
From this, we can determine that the internal JMRI processing time, including any extra delay caused by the USB conversion as simply the measured Loop Timing, the second column from the right in Table 4-9, minus the .08 seconds. This subtraction is the time reported in the rightmost column in Table 4-9.
USB TRANSPARENCY AND DATA TRANSFER METHODS
A key point in using a USB to Serial Port converter cable is that the resulting conversion is transparent. You simply compose your program just as if you were using a “standard” RS232 serial port. The only difference you are likely to notice is a change in the COMPORT number. Dependent upon which USB port you plug into, the Operating Systems’ Device Manager assigns an equivalent COMPORT number, usually between 4 and 9. To determine the specific assignment in your situation, Click on “Control Panel” and then click on “Device Manager”.
If the assignment is greater than 4, and you are using the Serial Protocol Subroutines supplied with the V3.0 User’s Manual, you will encounter the “COMPORT must be 1, 2, 3 or 4” error message. To correct the problem, replace the SPSVBM.bas module in your application program with the one contained on the CD associated with this manual. Assuming your computer has an available expansion slot, then an alternative to purchasing a USB to RS232 Converter Cable is to invest in a plug-in serial interface card that supports RS232 and sometimes RS422/RS485 combined with RS232. In that case direct connections can be made between the computer and the SMINI and SUSIC.
|
****Key Points Using USB with C/MRI****
|
The main reasoning behind using a “real” RS232 port, contrasted to a “virtual” RS232 port as set up when using USB, is that physical RS232 ports are integrated more closely with the computer’s hardware and application software. Typically with the real RS232 port, the application software has direct or almost direct accessibility to the port’s performance. Settings like baud rate, number of data bits and stop bits, and use of hardware-software flow control can frequently be controlled from within the application program.
By contrast the USB interface is much more complex with much added overhead. Additionally, it does not provide a close tie to the application software. This can result in the user having less effective control of how the I/O is handled. To try and provide “transparent” RS232 performance under USB, a second device driver is necessary with its purpose being to emulate an RS232 UART, which is the IC that handles the RS232 data transfers, but still communicates through the USB.
The challenge with real-time applications, such as the C/MRI, is that specific timing constraints apply to I/O handling. With RS232 ports closely integrated into the computer’s core architecture, data transfer can be very closely controlled when running QuickBASIC applications under DOS. Even when operating with Visual Basic under Windows, which can interfere with I/O efficiency, there is still reasonably tight control. For the most part, the application software communicates directly, or via a small and very efficient device driver, to the RS232’s UART. Thus, everything happens within a quite closely defined time frame.
The setup with the USB bus is much more complex and much more divorced from the application software. Additionally, having the double device driver layer, with an RS232 driver functioning on top of the complex USB driver, is prone to adding extra communication overhead, resulting in delays. In our quest to maximize system responsiveness when using USB it is important to be aware of the four different types of transfers employed with USB. These are:
Control Transfers – are typically used for command and status operations and they are the only type that is specified by the USB specification. They enable the host, in our case the PC, to read information about a device, set a device’s address and select its configuration. They may also be used to send requests that result in sending and receiving data for any other purpose. This “send request” capability is essential because USB bus operation is a “polled system” whereby USB devices on the bus can send information to the host only when requested to do so by the host.
Interrupt Transfers – are typically non-periodic, small device “initiated” communications whereby the device must receive the PCs attention or the PC must obtain the device’s attention with a bounded latency. For example, mouse movement and key press data make use of interrupt transfers.
Isochronous Transfers – can occur continuously and periodically. They typically contain time sensitive information and enjoy a guaranteed delivery time. Typical applications include transferring audio and video files to be played in real-time. If there were a delay or retry of data in a video stream, then you would expect some erratic video containing glitches or with an audio file the “beat” may no longer be in synchronism. On the contrary, if a frame or packet of data was dropped every now and then, the loss would be less likely noticed. Thus, there is CRC checking of isochronous transferred data but there is no automated retry if data is found to contain errors. Consequently, if using isochronous transfers, occasional errors must be tolerated.
Bulk Transfers – are intended to support moving large “bursty” data under situations where the timing to initiate the transfer is not critical. Example applications are sending a file to a printer, or receiving data from a scanner. In these applications, data transfer can typically wait for a reasonable period of time. Fundamentally, bulk transfers use spare un-allocated bandwidth on the bus after all other transactions have been allocated. For example, if a bus is busy with isochronous and/or interrupt transfers, then bulk transfers may just slowly trickle over the bus. As a result, bulk transfers should not be used for time sensitive communication as there is no guarantee of latency. On the other hand, if the bus is idle, bulk transfers can be very fast.
Almost everything I read and study regarding USB points to the fact that real-time applications, such as transferring audio and video files to be played in real-time, robotics, machine tool control and the C/MRI, are best served by having the USB port operate in its Isochronous Transfer mode. However, up to this point in time, I haven’t discovered a USB Converter Cable that permits operating in this mode. Possibly, searching for adapter cables designed to support the audio and video editing market, would provide fruitful results.
Although the management of all transfers is under the direction of the PC, it is the responsibility of the end-device, e.g. the printer, scanner, mouse, and so forth, to inform the PC as to its data transfer needs. Once these needs are understood, the PC operates under a strict “time slicing protocol” to manage all transfers. Dependent upon such factors as the particular version of USB being used, the type of device with which it is communicating and the transfer method being employed, three different operational speeds are involved. These are denoted as “low speed”, “full speed” and “high speed”. Traffic is managed by dividing time into slices called “frames”, or in the case of high speed transfers “microframes”. Frames, used for low and full speed transfers, are 1ms duration. For high speed data transfers, the PC divides each frame into eight 125μs Microframes. Low speed devices, such as mouse and keyboards, must use either Control or Interrupt transfers, while Isochronous and Bulk transfers must use full or high speed. However, USB1.0 only supports low and full speed while USB2.0 automatically uses high speed whenever possible, switching to low and full speeds when necessary.
For general applications, where you plug a USB compatible device, such as a printer, mouse or scanner directly into a USB socket on your computer, the PC automatically interrogates the attached device to determine its capabilities and needs and then adjusts the operation of the USB port, such as setting the transfer mode, operational speed, receive buffer size, etc., to “best service” the device. To provide this “plug and play” capability, every manufactured USB device must receive a Vendor ID and a Product ID that are embedded in the device to identify it to the PC’s operating system. Additionally, “device specific” parameters are transferred as part of the interrogation that in turn enable automatic optimization of the USB port to “best match” the needs of the device.
FUNDAMENTAL CHALLENGE USING USB CONVERTER CABLES
However, once a USB to Serial Port converter cable is employed to attach a non-USB equipped device, such as the C/MRI, the merits provided by “plug and play” loose their luster. The host no longer knows if the end-point device is a printer, scanner, digital camera, robot, piece of laboratory test equipment or production machinery, or a C/MRI. It simply knows that a particular brand and model number adapter cable is attached. The knowledge that the PC needs to “optimize” its USB bus performance is missing.
To help overcome this limitation, USB to Serial Port Converter Cable providers include options in the “Driver Software” supplied with their cable. Then, working within the constraints of the driver software the cable’s end user has latitude in tailoring the operation of the USB port to best fit the intended application.
For the majority of applications where USB to Serial Port converter cables are employed, such as attaching a non-USB equipped printer or a reasonably sized C/MRI application, simply applying the “default options” is adequate. Other general applications that have somewhat more time-critical transfer requirements, including medium sized C/MRI application, may require some level of “driver parameter” tweaking.
Fundamentally, being able to “best set” driver parameters becomes increasingly important as the demands of the real-time system expand. With the C/MRI, this “expanse of the system” is measured in terms of the number of bits that need to be transmitted between the PC and the railroad during each pass through the real-time loop. As indicated within Table 4-10 this number is directly related to the total number of Nodes, SMINIs, SUSICs and 24-bit and 32-bit I/O cards.
Experience has proven for a growing number of USB C/MRI users that obtaining a suitable USB adapter cable and then, if and when required, making appropriate driver parameter adjustments, can and will continue to provide successful results. This is especially true for the smaller, less-demanding, real-time applications. The challenge comes, I believe, when working to apply USB adapter cables to the larger real-time systems.
While this “research level” activity is continuing, my recommended course of action, and especially so for the large system application users, is to continue where you have a choice to make use of a computer that still employs a RS232 connector. However, as the technology and our application of it improves, I fully expect that the utilization of USB for C/MRI applications will continue to expand. Furthermore, as they expand to make increasing use of USB ports as integrated into all later model computers, the typical C/MRI setups will be reflective of those illustrated in Fig. 4-13.
