Hi All,
I purchased a couple CML Electronics DTM30 Tower master boards. They work great! However now i'm wanting to make them wireless somehow.
The way they are mounted is in portable switchboards. I have them powered by a battery and just plug them around the layout depending on what & where i'm running.
Normaly to use them, you plug them into a loconet port. Not a throttle jack, but the rear ports. Seeing I need rear ports, this makes me have to have specific plugs; you can't just use the UP5 front panel connections. Granted it's not a bad thing to have extra plugs and they're easy enough to add, it just annoys me to not be able to plug into the 25 UP5's around the layout. Truely though, it would be nice not to have to plug in at all and remove the 25 troublesome UP5's...
So is it possible to create a wireless connection? The duplex throttles send and receive info and have it transfered onto loconet. Could it be done with another loconet compatible board? Can you make a throttle relay messages from loconet (DTM30 plugged directly into throttle, no physical connection to loconet)? Or can a full wireless loconet to loconet port be built/bought?
Thanks for any help or ideas!
-Brendan
What Digitrax throttles are you using now? Are they tethered or wireless?
I'm not familiar with the DTM30 boards, but why can't you plug them into the front of the UP5? From a LocoNet perspective, both the front and rear ports are the same.
If it's just a matter of not enough ports, use a 6p6c phone splitter. That'll work fine, too.
I'm not aware of anyone who makes a wireless LocoNet device. It's intended to be a local bus, and it's design allows for cable lengths suitable for even quite large layouts.
Doesn;t the DTM30 have 2 Loconet jacks? The pictures I see of them, they have 2. So you can run command station----up5-----dtm30----up5----up5----dtm30----up5---up5 or whatever order you need.
Since it only needs Loconet and not Railsync, you can also use the front or side jacks of the UP5. What's missing on those jacks compared to the rear is the railsync signal, not loconet.
Also, if you run a 9-12V power bus around the layout you could plug the DTM30's into that instead of using batteries.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Ah and that is where I must correct you.
Front and rear UP5(3) Loconet ports are not the same. Rails_sync signals are propagated differently between the two. I can verify this 20 times over as devices will behave differently. You can occasionally use the front port for devices if you only do one device that doesn't use railsync. However you can't then daisy chain devices.
To my knowledge, this is done because the throttles don't care what most other Loconet devices are saying; i.e. a throttle doesn't need to know the conversation between a block detector and a signal controller.
On loconet, all throttle info is sent over Loconet +, -, and Ground. It is then duplicated, buffered, and sent in a mildly different format over Rail_sync. This is why, in most cases, control over Loconet will not drop out if one pin or wire is missing.. one leg or the other will continue to function. However this is different for some Loconet devices; they function more on the Rail_sync side, with the messages buffered to be sent (milliseconds waiting time) over the other Loconet pins, giving priority to throttles. It all really comes down to a priority thing over which devices need to have faster response.
As far as having enough ports, we have plenty! The layout has 25 UP5's, plus all but 3 throttles are wireless. 25 UP5's = 75 throttle jacks.
Yes the DTM30 has two Loconet ports. And yes that is what you do and how they are set up. The nice thing about Loconet is you are able to tap off anywhere in parrellel but it all just connects to the 6 pins.
But here's the thing- the DTM30 does require Rail_sync. Tested with one board going from UP5 front to DTM30 worked but didn't get me all the feedback from other devices, sending info to, say, throw a turnout worked fine- getting a PM42 zone on/off feedback wouldn't work along with a few other feedback things. A DTM30 is meant to be use as a feedback device, reading and relaying what the signal controllers, block detectors, etc are doing.
Going from UP5 to DTM30 to another DTM30 like I need them to just caused strange behavior which I think is more of a power output constaint on UP5 front jacks causing what the DTM30 thinks are communication errors.
And I just found batteries to be easier than crawling around to add yet another ~12 volt buss line. I just mainly wanted one wire to plug in and unplug around the layout.. purpose is trying to simplify for the idiot that will forget to plug in the 2nd cable or try to plug it into a front jack and wonder where to put the power plug when there isn't nessicary one handy
No, Steve is correct when he says from a LOCONET perspective, the front, rear, adn side ports on the UP5 are all teh same. They definitely are NOT the same from a Railsync perspective.
How many plug in throttles are you operating at a time? And do the UP5's have power? If you're plugging in 4-5 throttles and have no aux power in to the UP5's, this is probably your main issue. And the proper way to power UP5's is NOT running a common wire from one using the hole on the circuit board - you need to run TWO wires and tap off at each UP5 - easiest thing is to put a plug matching the socket on the side and just plugging in the power. One power supply can do all your UP5s as long as it puts out enough power to handle the current draw of however many throttles you plug in at the same time. UR91 and UR92 radio receivers need power as well to operate properly. Yes, I've seen people get away with just plugging them in and letting them use Railsync power like a throttle, but they actually draw more than the recommended amount of power and strange behavior results as the voltage drops under the excessive load. As for connectiong the UP5's as shown int he instruction sheet - this is just the positive supply wire, the ground then ends up using the ground wires int eh loconet cable. Being thin telephone wire, it's back to excessive voltage drop again. Running a paired power bus to the UP5s prevents this. CML recommends not sharing the power supply with the DTM30, so you still need a power source for those.
[/quote]
rrinker No, Steve is correct when he says from a LOCONET perspective, the front, rear, adn side ports on the UP5 are all teh same. They definitely are NOT the same from a Railsync perspective.
OK yes you are correct. Loconet ports, and pins are all the same on the ports. That goes for every Loconet compatible device I've encounted. And yes Rail_Sync pins are present even, however Rail_sync signals are propagated differently on Rail_sync ports when using UP5's- From Digitrax. Point being- One cannot use the ports interchangably with items that daisy chain or utilize the normal version of Rail_sync- ergo for my problem, can't connect to front ports reliably with DTM30's.
Yes the UP5's are powered. They have both the 2.1mm plugs connected to a ~11.7 volt dc power supply, connected with a buss wire to all 25 UP5's, 1 UR91, and 1 UR92.
Then the back track connections are also powered with a completly isolated PM42 zone- same thing with its own buss line. This has created SOOOOOOO many problems when first set up.
What I found is- When a throttle has a bad RJ12 6 pin plug and is plugged into the UP5's shorting things out- one (or more) of the 5 resistors/diode (I don't recall which off hand) on the board will (can) blow/go bad. This somehow connects with the track connections and LED status indicator and "leaks" current. The resistance created is very high and would never be noticed or cause enough to trip a zone when <4 UP5's are wired to track in one zone. When they are all powered by one buss line as mine are, the resistance adds up and causes unknown shorts. 25 tested and repaired panels later.... everything works as it should.
The UP5's test from front ports as putting out 10.7-10.9 volts depending on location and wire loss. There is plenty of power and extra amps to play with. At most there are 7 throttles plugged into the system with very little voltage sag. Since most are wireless, it is rare to have more than 3 connected. That part of the system is very stable.
Anyhow, the UP5's cannot withstand excessive current draw from the throttle ports. Plugging 5 throttles using a splitter from a single powered UP5 will also damage it. It claimes it shouldn't, but I tested and found otherwise.
As far as the DTM30's go, they seem to pull an odd amount of power from Loconet, considering they are also aux powered (batteries in my case @11.4-14.5 volts throughout charge/discharge cycle; more than the 9v they require. But all 3 of them I have do this and it seems normal.
So back to the question- How do I make these boards wireless? I can easily go back and add extra 6 pin connections with standard Rail_sync, but would rather not for various reasons.
You can't. Just buy or make a splitter (though again, if they REALLY just need Loconet, the side jack of a UP5 is fine. If they don;t work there, then they do need Railsync, and not just for power). Things like the Locobuffer interface work great off the side jack of the UP5.
If you power the UP5's from the 2.1mm jacks, you can theretically clip off the other two steering diodes, from track power and fromt eh railsync lines, since you want to use the power suppyl input as the power source anyway.
I still don;t see how any of thise is preventing you from usign Loconet int he way it was intended - link fromt eh command station to a DTM30, fromt eh secnd jack to the back jack of a UP5, from the second back jsk to the back jack of the next UP5, etc, to a DTM30, to the next UP5, etc. If they are not conventiently located, you can get 6p6c splitters (RR-CirKits has ones wired correctly so as not to reverd the Railsync phase). Plug in a line to the back of a UP5, a line to a DTM30, a line to the next UP5, whatever, it will all work. If not, you haev a bad cable or a bad jack on some device.
There are also instructiosn on the RR-CirKits page showing how to make a 'booster net' plus a dedicated 'throttle net' where you break out the Railsync conenctions and on teh throttle side supply power on those two wires, where they are notin any way connected to Railsync and are simply power wires. You cannot use any device that needs Railsync downstream of this, which means no boosters and no BDL168. Anything that does not need Railsync will work, like throttles. If the DTM30 won;t work on the side or front jack of a UP5, it must need actual Railsync and not just power, which it should mention in the instructions. Based on the function of the board, I can't see why it would need Railsync, other than to rectify into power to run the board. But since it has 2 ports like a UP5, you can just insert it in the daisy chain and it should work fine. I've plugged all sorts of stuff in my Loconet cabling, I have a PR3, a homemade Locobuffer, a homemade LocoIO, some UP5's, and an added booster. Just one long chain from end to end, device to device.
Thanks for the replies but-
The DTM30's do require Rail_sync. I've said that all along. I've read the manual. I've tested so lets not make it a discussion of if I can or can't use the front or side jacks.
The whole purpose of the board is to relay messages from detectors, signals, circuit breakers, info that is ultimitly sent over Rail_sync.
Do I tap off of the main loconet 6 pin running around the layout- Yes. That is how they are currently functioning.
Do I need to power the board somehow- Yes that if taken care of.
Could I just hard wire them or add 25 more splitters to allow these essentually giant controllers to be moved around- Yes
rrinkerI still don;t see how any of thise is preventing you from usign Loconet int he way it was intended - link fromt eh command station to a DTM30, fromt eh secnd jack to the back jack of a UP5, from the second back jsk to the back jack of the next UP5, etc, to a DTM30, to the next UP5, etc
Nothing is preventing me from using Loconet properly. I do it now and it works. But did the person who created the first wireless throttle figure "eh, I'll just add more plugs"? Wireless throttles were created- relaying messages from a sender to a base station to a loconet/rail_sync connected device. So why can't this be modified somehow to work?
Where I'm coming from is- Even if I add more jacks branched off of Loconet, some yahooo is going to come along and try to make them work off of the UP5's. I'd rather just have to not plug them in at all.
So any thoughts on how to relay these signals wirelessly?
BrendanMThe DTM30's do require Rail_sync. I've said that all along. I've read the manual. I've tested so lets not make it a discussion of if I can or can't use the front or side jacks. The whole purpose of the board is to relay messages from detectors, signals, circuit breakers, info that is ultimitly sent over Rail_sync.
Yes, the DTM30's do need Railsync (it does say so in the manual), but to clarify some - most of the information you mention is NOT sent over Railsync. Railsync is just a low power copy of the DCC track signal. Loconet packages are not sent over Railsync, only DCC packets. As an example, messages from occupancy detectors would not be sent over Railsync. This doesn't help your situation any, I just thought I would clarify what Railsync is.
BrendanMWireless throttles were created- relaying messages from a sender to a base station to a loconet/rail_sync connected device. So why can't this be modified somehow to work?
It would take a LOT of work to develop a wireless Loconet link, look at how long it took Digitrax to develop the Duplex radio. Additionally, even if you could use what they have already developed, their radio system only applies to the Loconet signal, so you would still have to add another radio to transmit the Railsync signal.
Okay, I don't use the CML products and wasn't aware they needed Railsync. But the 6p6c splitters I mentioned will work in the portion of the LocoNet that carries it.
If you really insist on wireless, try the JMRI and/or LocoNet Hackers lists. I believe JMRI has some XBee support that may be adaptable to what you're trying to accomplish, and a quick search of the LocoNet Hackers list turns up some threads that may be of interest.
Just be aware that absent a commercial solution, you'll need to work out all the collision avoidance, etc. on your own.
Nor would any existing wireless solution - even somehow adapting the wireless throttle - get what you need, because that would only have Loconet, and no Railsync.
Perhaps the real question is, do YOU need Railsync - are you using the DTM30 in a situation where it needs to see DCC packets, and not just Loconet occupancy message and switch messages, etc.? I've looked at a lot of loconet interface devices, but I never looked in depth at the DTM30 - the idea of a Loconet I/O board needing Railsync as well is somewhat foreign since none of the others do. I select turnout 244 on my throttle and set it Thrown - that message is on Loconet, I don;t need to read that from Railsync when the command station sends it out Likewise when an occupancy detector sense a block go occupied, it generates a Loconet message, and that never even gets repeated on Railsync by the command station. Anothr Loconet device cna act on that, or software like JMRI reacts to seeing that Loconet message that says block 5 is now occupied, and does something like generte additional loconet messages to make things happen. About the only thing I can even thoink of where reading railsync might be useful is to make something happen based on the commands sent to a specific loco - on the loconet side you have the throttle sending commands to a slot in the command station, but that doesn;t tell you the DCC address of the loco in that slot - the railsync side will be the NMRA DCC packet sent to that loco and will include the decoder address. Although for anything higher than F8, the throttle actually generates a loconet packet that is essentially a command to the command station to generate the included data as a DCC packet - functions hiogher than F8 are handled directly by the throttle Such loconet packets do include the actual loco address. This is also why to go past F12, you just plug in a DT402. No command station updating necessary - and the command station only goes to F8 anyway. Even F9-F12 are handled in the throttle and have been since the exnapsion to 13 functions.
Bottom line, no one yet makes any sort of device that converts both Loconet AND railsync to wireless for extending the bus. Given that it can run some rather extraordinary lengths without anything special, there's little call for a wireless extender. The throttle idea will not work, because the RF transceivers used by the UR92 and DT402D are merely encoding/decoding the Loconet signal, no railsync is involved.
I just looked at the DTM30 doc. All you have to do is uncheck "Uses Turnout Feedback" in each of the cells, and it no longer requires Railsync. It will instead use the command station's (LocoNet) confirmation that the command has been sent.
But it looks like all the DTM30 does is "convert" physical switch actions into LocoNet commands, and display the results on physical indicators.
So unless I'm missing something, you could simply use JMRI panels on a tablet to perform the same actions and display the same indications, AND get your wireless functionality without also having to lug a physical panel around the layout.
StevertI just looked at the DTM30 doc. All you have to do is uncheck "Uses Turnout Feedback" in each of the cells, and it no longer requires Railsync. It will instead use the command station's (LocoNet) confirmation that the command has been sent...
I think you misunderstand how "Use Turnout Feedback" works. First of all, Uses Turnout Feedback would have to be checked to not use Railsync, because then the DTM30 would monitor Loconet for turnout feedback messages instead of monitoring Railsync for DCC accessory packets. Second, and more important, the layout would have to be wired for turnout feedback, which would mean an additional switch and digital input for each turnout that needed to be monitored.
Something that might could be done, if they are using JMRI, is to setup something in JMRI to send a turnout feedback command whnever an accessory command is seen on Loconet.