curious to know if a laptop can monitor (listen only) a cab bus using an rs-485 interface?
i also assume that a laptop cannot respond quickly enough to act as a controller because the cab bus polls cabs and expects a response within some limited period of time.
If JMRI can do this, does it use special HW?
greg - Philadelphia & Reading / Reading
I dopubt you can just plug it in and it would work, but it should be more than doable. And why would you think a laptop wouldn't be fast enough? ANy laptop made in the past 10 years is MANY times faster than the embedded Z80 used in the NCE command station. You might have to use something other than Windows for an operating system because you can't guarantee some other task would suck up all the CPU time and not allow the cab bus handler to process anything. The multitasking nature, even though it's pre-emptive since Windows 2000, makes Windows a rather poor RTOS.
It works to have a Windows PC monitor the much faster Digitrax Loconet because the interface adapters are buffered. The first such adapter though wasn't, and the missed data could bite you at times - I saw Digitrax's own display demo get hung up, it was a simple track with block sensors and Winlok controlling it to automatically reverse diectrions at each end. A block detection message for the last block at one end was missed to the RDC kept pushing into the end of track bumper and never reversed. With buffered adapters like the Locobuffer, this doesn't happen.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
gregcIf JMRI can do this, does it use special HW?
Your typical laptop doesn't have a serial port nowadays. However, a USB/serial adapter gets you in business with JMRI. The JMRI hardware page can give you a range of choices. I use a Tripp-Lite Keyspan USA-19HS with my Power-Pro. The serial cable can be to the max length allowed (~30'-ish?).
Once you're online in JMRI with the Power Pro, you have several options to interface with the command station, depending on what you have in mind.
Mike Lehman
Urbana, IL
can the JMRI software both receive and send within the time contraints of the cab bus protocol using Windows?
Greg,
That's a question above my paygrade. I poked around a bit and there is this discussion about RS-485 that starts about a third of the way down the page: https://sourceforge.net/p/jmri/mailman/jmri-developers/thread/tkrat.12e93baa78a1b2f5@sbcglobal.net/
using this rs-485 usb interface, open() to read() /dev/ttyS8 i get the data below.
There are two sets depending on the polarity of the wires. I also believe I need to configure the port for 8-bits (none below). Following link describes protocol and command set:
https://ncedcc.zendesk.com/hc/en-us/article_attachments/200182749/Cab_bus_protocol.pdf
Each read returns none or 1+ bytes of data. The data is displayed in groups; 1+ reads separated by a read returning no data.
this seems to confirm that data can be monitored (if configured correctly). Still very unsure and doubtful that windows code could respond to the protocol.
curious and tryign to unerstand capability of using rs-485 bus w/ laptop.
monitor: COM9 opened
7e 4f
0f 4f
72 3d 2f
7a 7c 7d 4f
52 3d 2f
7a 4f
6f
7c 0f
monitor: opened /dev/ttyS8
7f
5f
77
3f
7b
Outside of the real time issues I mentioned, I don't see how a Windows PC could not respond in time - the Cab Bus protocol is rather slow. Even an old 4.77MHz original PC could handle 9600 bps communications just fine. There is nothing high speed about any of this. C/MRI also uses RS-485 with some low end microcontrollers, and there are now Arduino replacements. It's the real time component that makes Windows a possible problem - I would suggest designing something around a micro, like an Arduino, to act as the actual response mechanism for the bus and then buffer information and read/write tot he PC, that way if you open a second window and it sucks up all the processor time, the railroad application would be able to catch up by reading the buffered data from the interface. ANd commands could be queued up from the PC to the interface which would then issue them as the polls came in.
Downside of polled protocols. You need real time processing to catch every request. It doesn need hish speed or very powerful processors, it just needs to be mindlessly dedicate to processing that bus, or at least not take attnetion away for longer than the polling protocol allows. For something like an Arduino, this doesn;t even require the use of an interrupt. For a much faster peer protocol like Loconet, the Arduino libraries for it DO use an interrupt for data receive, otherwise data would be lost. For RS-485 communications, just using common sense looping, like avoiding the delay() command, are enough to process input at higher speeds than the NCE Cab Bus use.
Special hardware is needed because there aren't RS-485 ports on PCs. That's what the NCE USB interface does (as opposed to hooking a serial cable to the command station). There are limitations in JMRI because they designed the software based on how NCE intended to use the hardware - a Power Pro system is meant to be controlled via the command station's serial port, not by something attached to the cab bus - that's why if you use the USB interface (intended for the PowerCab) on a PowerPro, there are limitations on what you can do. What you're talking about is more liek replacing the command station with a PC< that communicates on the cab bus and drives a booster based on what the throttles and so forth are telling it. This is a lot like the homemade Arduino DCC system, although ne made no attempt to make his communications protocol compatible with NCE cab bus. Effectively substituting the Arduino's more poweful 16MHz ATMega 328 for the Z80 in the PowerPro command station. I don;t think it would be outside the realm of possibilities to tweak that code to actually use Cab Bus protocol, which would allow the use of NCE cabs on it.
rrinkerOutside of the real time issues I mentioned, I don't see how a Windows PC could not respond in time - the Cab Bus protocol is rather slow.
The command station polls the cabs. It can take it's time deciding when to poll and a number of bytes to be transmitted can be buffered. But the cab needs to respond within 800 us. The receiver UART on the PC can capture and buffer a number of bytes even though the application may not check for a while.
A much slower processor can handle the response time required. The cabs use a PIC process. It's not the HW, its the OS. I believe they'd be ore than adequate for a command station.
rrinkerSpecial hardware is needed because there aren't RS-485 ports on PCs.
There isn't much of anything on a PC anymore. I don't believe any special is needed to monitor, just a serial port with an RS-485 interface.
Some recent experiences with Linux make me wonder it it would be possible for Linux to respond within 800 us.
Any multitasking operating system that doesn;t have the ability to wrk specifically in a real time mode is potentiually going to have a problem not responding in time. If everything is working fine, there's no issue of Windows responding. or Linux, or Mac OSX. But all it takes is clicking on a huge program, or triggering a large file transfer over the network, or something else that keeps the system busy, and it will start missing events.
rrinker Any multitasking operating system that doesn;t have the ability to wrk specifically in a real time mode is potentiually going to have a problem not responding in time.
this is what i thought. But is it still always true on a multi-core processor?
my laptop has 2 cores. My son says the AMD processor he uses has 6.
Yes, because you can;t dedicate a core to a process (easily). Windows (and Linux) have way more than 2 threads running just displaying the desktop with no applications running. With 6 cores, each one may only be doing 4 things, instead of 2 cores each doing 12, but you're not likely to get a Windows system running applications and have totally idle cores unless you sit there for a few momoents and let everything settle down - but as soon as you move the mouse, it jumps right back.
It CAN be done, there are real time applications that run on Windows. There are ways to control which core an application runs on - it's used internally in SQL Server, for instance. The other option is a system so fast that even if it DOES switch away to do something else, it will be back to the cab bus application fast enough to not miss data, but that's a gamble - interrupt driven or a dedicated interface device would be more guranteed to work. Either way requires a little bit of hardware at least - interrupt driven should work given the required timing, an arriving poll would trigger an interrupt which would cause the application to immediately service the request.
Just saw this thread.
Are you asking if a computer with a serial port can listen/respond to the cab bus, at cab bus speed, via the serial port on the NCE Power Pro?
The first thing to keep in mind is that the serial port on the Power Pro does NOT directly connect into the cab bus, nor does it echo the commands from the cab bus. See this post on the JMRI list for more detail.
Also, the speed for that port is limited to 9600 baud because the processor in the command station can't process the commands and get them out to the track fast enough to avoid buffer overruns.
So with that in mind, yes, a laptop is not only fast enough, but unless limited to 9600 baud can actually be too fast for the command station to keep up with.
As for JMRI or any other software, it is limited to what the specific DCC system it's connected to allows. External hardware can't speed up the processor in the command station.
gregcThere isn't much of anything on a PC anymore. I don't believe any special is needed to monitor, just a serial port with an RS-485 interface.
If the adapter you linked to is what you are using for the RS-485 interface, then you probably will not be able to use the that combination as a cab. If you have a serial interface on the laptop's motherboard then as long as you weren't trying to do too much at the same time it would be quite doable. With the cab bus protocol, if you occasionally do not respond in time it doesn't cause an issue, the command station just assumes you had nothing to send and will check back again briefly. Virtually any PC should be able to respond fast enough often enough to not have any problems. With the USB adapter, however, there is a whole new set of problems. For USB "Low Speed" and "Full Speed" devices, latency times of a full millisecond are not uncommon, so regardless of what else you have going on or how fast your computer is, when it receives a prompt from the command station your software may not even know about for 1000us.
I actually ran into this issue at work. We developed a system to record data on race cars and then download the data to a PC to analyze. The download worked great if the PC had a true srial port, but it would not work with USB serial adapters until we re-wrote it to handle the long latency times.
One option that would work well is to use an Arduino with a RS-485 adapter to buffer the data between the PC and the bus.
StevertAre you asking if a computer with a serial port can listen/respond to the cab bus, at cab bus speed, via the serial port on the NCE Power Pro?
No, he's wanting to connect directly to the cab bus.
CSX Robert Stevert Are you asking if a computer with a serial port can listen/respond to the cab bus, at cab bus speed, via the serial port on the NCE Power Pro? No, he's wanting to connect directly to the cab bus.
Stevert Are you asking if a computer with a serial port can listen/respond to the cab bus, at cab bus speed, via the serial port on the NCE Power Pro?
Then the OP can use the NCE USB adapter, but it has some limitations especially when used with the Power Pro (it is really intended for the PowerCab). Whether or not those limitations would affect the OP depends on his intended use.
Or he can build his own device that emulates a cab. But as previously mentioned, the required timing (not raw speed) is tough if not impossible for a PC. A PIC- or Arduino-based design would probably be a better choice.
There was some discussion about building a 3rd party cab on the NCE Yahoo list not too long ago. The OP may want to check there if he hasn't already.
after properly configuring the tty port (struct termios) and using the correct wire polarity, I believe I'm seeing NCE cab-bus "pings". I repeatedy see: 0x80 0x83 0x84 0x85 0x88 0x89 0x8a. (the upper 2 bits are 10 and the lower 6 bits the cab address. 0 is the broadcast address.
this convinces me that the NCE cab bus is nothing other than a standard RS-485 bus which any commercial adapter can connect to.
I believe serial HW in the PC can capture/buffer a sufficient number of bytes transmitted on the bus, allowing SW to read the data at a more leasurely rate.
I am dubious that the laptop can respond to a ping request within 800 usec, but will likely try. What happens if there is a collision?
I was surprised by the real-time capabilities of Linux at work and am interested in understanding the limitations of a laptop running Windows, as well as the cab bus protocol
There shouldn't be collisions on a polled network as long as you don;t just try to randomly send data when not being polled.
The whole thing is like token ring vs ethernet - token ring is slow, but doesn't really slow down when you add more stations. Ethernet is way faster, but if your collision domain gets too large, it gets slower as more time is spent in recovery time and retransmits. It's less of a problem these days with active switches, but ethernet at the time token ring was popular was still often thinet coax with T adapters on the back of every computer, or early UTP attempts like Synoptics LatticeNet (ok, I am dating myself here). In say a 10 station network, 10Mb ethernet of the day was faster than even the 16Mb token ring. But change that to a 100 station network - 10Mb ethernet could still beat out 4Mb token ring. 200+ stations? Now the 4Mb token ring was faster than 10Mb ethernet. Token ring uses a passed token, so it's not really a polled bus, but a polled system like RS-485 works on similar principles in that no station speaks unless spoken to, so there should in theory never be a collision unless two stations have the same address.