Tam Valley Discussion

Wow, never going to get good range at 5mW, so I don't understand the conversations about upping the voltage to the chips.

The future is a 2.4GHz frequency unit.

The idea of deadrail was (originally)to take a DCC system, and basically put the "tracks" wirelessly. What radio and what protocol is a variable, but does not affect the idea.

Now, this means no programming track in most cases, transmit from throttle to loco only, no receive.

Where it gets complicated is where you have no "system".

So, in the "beginning", you took what would go to the rails, and broadcast it. Then the locos would all have receivers. In this case the locos really have no "idea" they are wireless. (notice you can do this with battery, or track with constant power, or a combination).

So your DCC system works as before, multiple throttles all communicate to the command station, and ALL the commands for ALL the locos are put in a stream and transmitted. Therefore no limitations in the number of locos or throttles in any way different from the "normal" track powered system.

Next someone had the bright idea to have individual throttles and not use a command station. In reality, the command station was built into the throttle, it still generates DCC commands, but now there is no "SYSTEM", i.e. the throttles do not know about each other.

Here's where it gets interesting. If your throttles are all on different frequencies (like AirWire channels), no problem, they can all transmit at the same time no problem. You do lose features like "all stop" and if you have a consist made with universal consisting, the other throttles cannot "take over" that consist.

(There are some systems that can "clone" the memory of a throttle to help this a bit).

But you are still limited by the number of frequency channels, and if you want to control a different loco, you have to switch your throttle to that channel.

Enter the bright idea of sending all commands on the same frequency... now you have to solve another issue, how to keep multiple throttles from transmitting at the same time. What is usually done is different from a normal DCC system, which has commands being transmitted continuously, round robin, new commands, and what available time is left transmitting the speed commands for existing locos. (This is why you can pick a DCC loco off the track and put it back on and it resumes the speed it was at)

You need to just transmit your new command. Two large problems surface: First if you "miss" receiving a command, like stop, then you miss it, no second chance. Second, even with the short bursts of necessary commands, you still have a limitation on how many throttles you can use, and you have to randomize your transmitting. The bottom line is you lose performance and reliability to receive commands.


For my money, I would use the original concept, and if I want to take it to someone else's railroad, just buy a compact system, like the NCE PowerCab, and then add a wireless throttle to it. Granted the NCE system is 900 MHz only ok in the US, but you could change the frequency, or interface a different throttle. This can be done, and I'm working on making a small portable system, which will most likely be a powercab, and JMRI on a tiny computer and then my throttles are cell phones... all can be done cheaply and made small and compact.


Whew... just wanted to get this out in it's entirety to put things in perspective. DCC may be old, but how it works is proven and there are many features you can lose by trying to chop up the architecture to where it is no longer a system.


Greg
 
Wow, never going to get good range at 5mW, so I don't understand the conversations about upping the voltage to the chips.

The future is a 2.4GHz frequency unit.

The idea of deadrail was (originally)to take a DCC system, and basically put the "tracks" wirelessly. What radio and what protocol is a variable, but does not affect the idea.

Now, this means no programming track in most cases, transmit from throttle to loco only, no receive.

Where it gets complicated is where you have no "system".

So, in the "beginning", you took what would go to the rails, and broadcast it. Then the locos would all have receivers. In this case the locos really have no "idea" they are wireless. (notice you can do this with battery, or track with constant power, or a combination).

So your DCC system works as before, multiple throttles all communicate to the command station, and ALL the commands for ALL the locos are put in a stream and transmitted. Therefore no limitations in the number of locos or throttles in any way different from the "normal" track powered system.

Next someone had the bright idea to have individual throttles and not use a command station. In reality, the command station was built into the throttle, it still generates DCC commands, but now there is no "SYSTEM", i.e. the throttles do not know about each other.

Here's where it gets interesting. If your throttles are all on different frequencies (like AirWire channels), no problem, they can all transmit at the same time no problem. You do lose features like "all stop" and if you have a consist made with universal consisting, the other throttles cannot "take over" that consist.

(There are some systems that can "clone" the memory of a throttle to help this a bit).

But you are still limited by the number of frequency channels, and if you want to control a different loco, you have to switch your throttle to that channel.

Enter the bright idea of sending all commands on the same frequency... now you have to solve another issue, how to keep multiple throttles from transmitting at the same time. What is usually done is different from a normal DCC system, which has commands being transmitted continuously, round robin, new commands, and what available time is left transmitting the speed commands for existing locos. (This is why you can pick a DCC loco off the track and put it back on and it resumes the speed it was at)

You need to just transmit your new command. Two large problems surface: First if you "miss" receiving a command, like stop, then you miss it, no second chance. Second, even with the short bursts of necessary commands, you still have a limitation on how many throttles you can use, and you have to randomize your transmitting. The bottom line is you lose performance and reliability to receive commands.


For my money, I would use the original concept, and if I want to take it to someone else's railroad, just buy a compact system, like the NCE PowerCab, and then add a wireless throttle to it. Granted the NCE system is 900 MHz only ok in the US, but you could change the frequency, or interface a different throttle. This can be done, and I'm working on making a small portable system, which will most likely be a powercab, and JMRI on a tiny computer and then my throttles are cell phones... all can be done cheaply and made small and compact.


Whew... just wanted to get this out in it's entirety to put things in perspective. DCC may be old, but how it works is proven and there are many features you can lose by trying to chop up the architecture to where it is no longer a system.


Greg


Excellent concise description of the evolution of wireless DCC.

Of course you also lose other things than Greg has stated by doing away with the command station; the ability to control your already wired points and signals (unless you invest in standalone receivers), the inability to see programming feedback.

I agree with Greg; at home it is best to continue to use existing cabs and command stations but just avoid the track cleaning by sending the DCC wirelessly and power your trains with a battery. For visiting other lines a single S-CAB, a NCE PowerCab modified to be powered by batteries and with and transmitter tacked on it, or a small portable DCC system (I've done this with a Lenz Compact). Remember you don't need to use a specific G Scale DCC system since you are only powering a small transmitter and not providing traction power.
 
Last edited:
Setup as follows, Raspberry Pi3 as standalone Wi-Fi AP with JMRI loaded onto it, connected to an Arduino UNO R3 acting as a DCC ++ Central Station, with a Deek-Robot Motor Shield to the Tam Valley Transmitter, accessed via either VNC on a PC or via the Engine Driver App on a Smart Phone.
Playmobil chassis with a Massoth M Decoder and a Tam Valley Receiver.

RPi3 requires 5V, Deek-Robot shield requires 12V to drive the DCC output to the Tam Valley Transmitter.

View attachment 232788

John,

Which bits go onboard the train and which bits are off the train?

How many 'throttles' can be used with this type of setup?

Is it restricted to Massoth decoders and Tam Valley transmitters and recievers only?

I take it that full DCC functions are provided.

I have to many more questions to post them all.
 
Just a very brief summarising to your questions.

Receiver, decoder, batteries on the train, transmitter, Pi3, Arduino, Motor Shield off the train.

Theoretically 256! but in reality and to save a boring technical discussion, and based on the original Pi setup of 2014, would say eight as a number that can be used without undue complications.

Any NMRA decoder can be used, (some are more efficient than others for running on battery power) opted for Tam Valley Equipment as it is/was? readily available and proven to work reliably.
A compromise between power consumption and the ability to send and receive data reliably are deemed to be of more priority against economic cost!

Other options are being evaluated, my acquaintances in France, Holland, and Germany are looking at other available products.

All DCC functions are supported, mobile, accessory, etc.

Next question could I use my existing pololu motor drives with this, maybe running off the decoder?
I am only asking because I have 2 tablets that are wifi capable and my be able to be used to run a proposed indoor layout.
That plus I am a bit of a techno enthusiast albeit not real up to speed on it yet but retirement and some spare time beckons.
Price is a consideration but I do not intend to buy any more locos and I am now scratch building my rolling stock so no outgoings in that department.

My philosophy is "Hey its a hobby and one must experiment, else I may as well but a 'train set' run that and be done with it."
 
John S, should there have been an actual post number in your request to the mods above?

Jon.
 
Thanks John, was just doing a comparision of going your way vs. a tradtional laptop and access point and command station approach... so I wanted to note (mostly to myself) that when comparing the 2 approaches, there was no display, keyboard or mouse in your approach. I completely understand they are not needed, the idea of a very compact foolproof, transportable system appeals to me.

I'm building up a "portable" DCC system, and there are pro's and cons to having a local keyboard display and mouse.

Regards, Greg
 
Back
Top Bottom