perfect application for the

perfect application for the raspberry pi micro computer. I believe jmri can run on Linux. Use an encoder wheel on a knob for the throttle, push switch for direction. Would fit in an existing "big knob" throttle.

Stop when you're comfy...

Dear John,

Totally follow your logic, and agree that this would be one possible evolution of DCC as we know it today.

However, I would respectfully suggest that most "average modellers" will wait to "Stage 3",
(IE when we have
- a "Wifi Throttle that actually looks and feels like a throttle, with a physical speed knob and reversing switch",

thus replacing the percieved octopus of cables/PSUs/Adaptors/configurations which make up the functionally-same JMRI<> DCC systems of today, with "one box"... )

_PLUS_ expect the "Booster" to be built _into_ the "WiFi Command Station" unit,
(Sure, 2 different circuits,
but built and integrated into one physical box,
with 1 common PSU, preferrably IEC 3-pin mains powered).

and then will _stop_,
comfy that the solution works for their needs, 
and _not_ move onto steps 4 or 5.

I hope that's not just me being cynical, but I doubt it...

Love the nice lucid writeup...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

PS My "always have a redundant backup plan" side makes me ask,
"and would there be _any_ form of "plug in throttle buss" built into this WiFo Command Station, for situations where there is simply too much WiFi traffic in the area to operate reliably?"
(Thinking of exhibitions, Free-mo type running sessions, etc)

Smaller!

Mr. Hall,

I remember when the personal electronic display device used 32 tubes and was housed in a cabinet the size of a cook stove, and had only knobs for control. Back then there were only three picture streams and if the president was on, you only had one choice.

The answer is I do not know. This blog is a general outline and devoid of a lot of details that will need to be solved. it may be the best we can do is a WIFI to DCC system in N scale.

I never wanted a flying car, I have to much trouble with the ones that stay on the ground.

Regards,

John

*******************************************************************************************************************************************

It would appear that we have reached the limits of what it is possible to achieve with computer technology, although one should be careful with such statements, as they tend to sound pretty silly in 5 years  John von Neumann

WIFI Isolation

Prof Klyzir,

I have hoped for an open command buss for DCC and WIFI seemed the logical choice. My lot in life has always been to retrofit old control systems, so I am bent to take existing stuff and improve on it.

The WIFI overload problem is real but not widespread, but will be worse in the future. I guess we could move to the country! Isolating our layout room, in the future, from outside sources of WIFI may be as common as dust proofing or adding lighting.

A wired system would be an Ethernet network, why reinvent the wheel.

Regards

John

*************************************************************************************************************************************************

A man may imagine things that are false, but he can only understand things that are true, for if the things be false, the apprehension of them is not understanding. Isaac Newton

...

John, I think you've nailed it - and the beauty of the system is in Figure 4, that system is both forward and backward compatible.

I was at Walmart today and I saw something most interesting: a iPod to Cassette Adapter, on the racks with the gum and jerky next to the register.  It MAY be an iPod/CD world nowadays, but there are still a lot of cassette decks still left, and guess what, people still use them!  It was interesting, nonetheless!

It isn't just a push for the touch screen, it is a push for the GUI interface, that wonderful device that took the nerd computers of the 80s and turned them into the consumer computers of the 90s.  It's further a push away from dumping money down the hole for devices that were obsolete/superseded a fair ten or fifteen years before our hobby finally gets them.  This hobby is already expensive enough, without the added expense of paying manufacturers a premium so they can add these upgrades piecemeal.  I understand, development is expensive for the manufacturers and they are running a hard game trying to keep up in the face of very expensive upgrades, but to re-invent the wheel, well, that's just not going to be any good - not to mention all the patents/copyrights they'd face trying to do so!  So we might as well just jump the shark now and let the cat out of the bag...

I'll end the "push" thought with this: I am as much pushing the touch screens as a weatherman pushes a ten foot blizzard on the north east.  It doesn't matter what the weatherman does or says, if all the Signs suggest there will be a ten foot blizzard, that is what there will be.  So in those regards, I'm just a weatherman.  The pessimist complains about the wind, the optimist expects it to change, the realist adjusts the sails [William A Ward].  I'm simply saying, we may want to adjust the sails now before we have to change hulls...

This has nothing to do with Power issues; "Wireless" = "Means of Control."  Power is the transmission lines, Control is the phone lines!!  Control and Power are two complete separate horses, even if they have been entangled in either DC or DCC control.  We separate them out first, then we can deal with the power issue.  I do believe once we get the control issue settled, though, after what I have observed on standard DC layouts, the need for alternative power will be resolved very shortly after.

John, I'm not so sure WIFI will be too crowded for the level of information we'd be transmitting during operating sessions - at most, perhaps 100k [time tables, work orders, waybills, switch lists] per tranmission, at the least, 1k-10k [directional commands, speed commands].  Megabyte and gigabyte, I see that as being overkill particularly if all the uploading is done on the bench or when the locomotive is on a LAN line.  Would this suggest a USB slot in the bottom of the locomotive might be useful, or somewhere so that the locomotive could be plugged in? Perhaps!!

I will say, at the very least, a microUSB connector is more durable and easier to use than the plugs Spectrum uses on their tender/locomotive interface.

DCC phone home?

It's nice to see that the phone is relegated to an optional control device, while a proper, specifically designed throttle can be used in its place.  I still don't want to use a cell phone to talk to my train.

Perhaps there is a possiblity for decoders to become dual mode, in that they can talk to the DCC buss through the rails or receive WiFi commands.  I'm still concerned that the different formats won't be able to talk to one another, though.  I think it's vital to be able to use old and new technology on the same layout until the old has died off through attrition, rather than being forced out to use the new gee whiz instead.

This may be of interest

http://wiki.openpicus.com/index.php?title=DCC_railway_model_controlled_with_Wi-Fi

Video demo of Wi-Fi controlled Model Railroad

This guy has come up with a pretty cool system I think I would use "Engine Driver" app for the throttle. But a great start for a wi-fi system.

...

So at this point we can safely state that Figure 3 has also been accomplished... Anybody have the cost on that Flyport figured out?

[Edit: in following up, I'm finding the Flyport is available for 59 Euro, the TAM Valley DCC Booster is $50, the power supply another 15, and the TurnOn module is another $20, plus the total for the circuit to tie the two together...I'll be fair and say it costs ~$50.  So that means we can build the Wifi "Command station" for around 80+50+15+20+50 = around $215.  This does not include the power booster, though.

RailPro has accomplished Fig. 5, so I think we should be plain what we mean by a Decoder with WIFI capabilities.  A WIFI decoder would indeed use WIFI to communicate between the throttle and the locomotive, but the language inside the decoder would still be a standard DCC signal compatible with track-based DCC signal.  Hence, this decoder could in sorts be called a dual mode decoder, whereas it could receive signals from either the track or the air.

Naturally, due to interference between trying to listen to two command sources at once, we'd perhaps want a method to be able to disable either track commands or Air commands just as we are able to fully disable DCC or DC in our present dual mode decoders, I'm thinking either a hardwired switch in the bottom, or more preferably, a digital switch inside the WIFI module that allows disabling of one or the other.  But then, this might not be necessary in the first place.

WIFI motor control

I wonder if we even need a DCC decoder. I think a WIFI motor controller should be doable. That would open up the door for a whole new set of possibilities. Whatever we do it must be compatible with JMRI software. Everything is already out there to enable this system maybe with the exception of a WIFI transmitter/receiver small enough to fit in HO scale locomotives.

Rob Teed

...

Yes.  The DCC decoder is the device that takes electronic inputs and converts them to electromechanical outputs.  No matter what device you have inside the locomotive, you WILL have to have one that does this. 

This source puts it best:

In otherwords, the DCC decoder works in binary, on a digital signal, to control motor function.  Regardless of what you put in the locomotive, you will need a component to convert the digital information into analog discretes. 

The device you suggest with just motor control would be equivalent to a DCC decoder with two outputs. We already have DCC decoders with what, 8, 9 functions, if not more, the lower forms running around $10, $15 each?  The DCC decoder seems to handle this job very well, so I don't see any reason we'd want to waste effort re-inventing this wheel and introducing the potential for new proprietary controls at the motor-function level. 

The issue is how the DCC decoder listens - and putting a WIFI adapter onto the decoder [similar to the NWSL system] would be akin to giving the DCC decoder a better pair of ears.  Why not just use the S-cab, or the RailPro,or the others?  My main issue is the proprietary throttles and the proprietary receivers that are not interchangeable between systems.  I want one throttle, the throttle of my choice, being available and that one throttle being able to communicate with ALL of the similarly equipped devices on the layout, not just the devices that share make with my throttle.

Ultimately, using DCC decoder architecture ensures backwards compatibility while utilizing an open source command language.  Retaining DCC ensures compatibility with JMRI and a wide host of command stations as well.  Even if DCC decoders are merged with WIFI modules and more powerful chips [imagine stuffing a whole flyport into a DCC decoder] are integrated to provide an even wider degree of animation and automation, the outputs would still be similar to what a DCC decoder provides - output voltages at set currents.

The Goal is an Open WIFI Control Standard

The open NMRA DCC standard has been the basis for a revolution in the model railroad world. it has allowed many vendors to build locomotive decoders and other decoders that all work together to make our hobby better.

This blog is an attempt to sell the same type of standard system to the control side of the picture. This way throttles and other control devices will interface the same. Brand A throttle will interface the same as brand B throttle. The steps are a way to bridge with existing systems.

It may be that the smaller scales will use a hybrid system with the DCC for the decoders and the WIFI throttles for the controls. In the larger scales the throttle could directly control the decoder. In either case the throttle can be the same throttle. The People who prefer the JMRI System and those who like a packaged WIFI command station can use the same throttle.

If you like a touch screen OK. If you like a knob, switches and buttons OK. If you want voice commands OK. The throttle will be a black box that talks the same as the other black boxes.

The Android sticks, the Arduino  systems,  and other computer systems are in the $50.00 and below range. The WIFI touch screens are available in the sub $200.00 range. The hardware and the software tools exist today.

A WIFI approach may not be the answer, but it sure seems a logical path.

Regards,

John

*******************************************************************************************************************************************

You can design and create, and build the most wonderful place in the world. But it takes people to make the dream a reality. Walt Disney

WiFi Standards +++

O, S, Large Scale hackers have already reached level 5 with at least one vendor who was touting a level 4 system. There is also a substantial effort to develop the missing communication standards which are needed to implement a WiFi based Model Railroad Control system (OpenLCB / MNRAnet – http://openlcb.org/). But there is still a long way to go for if we are expecting a low cost, open WiFi system for the smaller scales any time soon.

WiFi:

We keep discussing WiFi, IEEE 802.11 and other related standards; however, we a missing a big piece of the puzzle for a Model Railroad Control System. A WiFi system is actually composed of layers, and these layers, from the bottom level electrical signals to the top level operating system functions, are described in standards. IEEE 802.11 only describes frequency, channel and other transmissions / reception aspects of such a network, but does not describe the specifics of the contents of the messages (packets) sent and received. Additional levels of standards describe the contents of these packages for networks like the Internet Protocol (IP) and World Wide Web (WWW) standards. However, there is currently no standard which describes the addressing, command, data, etc. structures which linked through TC/IP protocols are necessary to support a Model Railroad Control System. If anyone wants to contribute to this effort please contact the crews at OpenLCB or NMRA. Without an Open effort or another magnanimous gesture from a manufacturer like Lenz (who contributed DCC to the world) we will probably have the proliferation of other propitiatory RF systems as we have seen in the Large Scale community and are beginning to see from small scale vendors.

WiFi overload:

When we talk about WiFi overload just in terms of our specific communication need, we miss the point of how devices share the network spectrum with other users. As I noted in Benny's post ( https://forum.mrhmag.com/post/wireless-wings-for-dcc-throttles-12192317), IEEE 802.11 devices have to deal with every device on the network channel:

So for now on layouts and at shows were we use our smart devices to communicate through a few access points, the traffic is not bad. That’s W smart devices communicating with A access points for (W+A)(W+A-1)/2 of say for 1 show layout with 10 users each your will be dealing with 78 paths if there are no other WiFi devices active. But 10 users (30 total) on each of three show layouts gives you 528 paths to deal with. Now put a WiFi decoder in every locomotive (1770 paths) before adding several dozen phones, tablets, the local facility WiFi networks, Cameras C, mobile hot spots, etc. and you have the makings of a bad day. Now if one of these devices is say streaming HiDef video, like my train cam, it can chew up over 80% of a given channel. So if Tom and Dick are in the lounge watching “stuff” on their tabs, it could be a very bad day. Yes they have expanded the spectrum, but even the expanded regions are filling fast.

One data point: We took a laptop, WiFi sniffer and scanning software to the convention center downtown and did some single channel studies in the 2.4 GHz band. There were no fewer than 200 active WiFi devices in use, and there was nothing going on at the center this weekend. That is almost 200,000 channels that devices had to deal with. When we connected to a network, we at times noted packet collision rates in excess of 30% (Only one device can be transmitting on a frequency / channel at a time). I will try to get a set of measurements when something similar to a train show is in progress. At these collision rates we did experience some dropped packets (i.e., failed communications).

Note also that these WiFi frequencies are in the Industrial, Scientific and Medical (ISM) bands where other communications are allowed to “step on” (over power) your operation, and your operations are not allowed to infringe on these listed operations.

Fitting WiFi in smaller scales:

Yes it is possible to build a WiFi transceiver which will fit into an N scale locomotive, but it will for the near future be a cost and physical (Damn Physics) challenge. Why? For transmitter / receiver system to work effectively the antennas must be matched or “tuned” to the transmission frequency. For IEEE 802.11 g/n we are dealing with 2.4 and 5 GHz which corresponds to ¼ wave dipole lengths of 31 cm and 15 cm respectively. Easily hidden in a LS locomotive, but tough for an HO locomotive and near impossible in an N locomotive. Yes there are various techniques to reconfigure or reduce the size of these antennas, but with significant expense or loss in performance. And for similar reasons we are also approaching limits on the size of transceiver chip-sets and modules with current devices in the 20 x 30 mm range. Power is also a concern as even in low power transmit modes these devices can draw hundreds of milliamps.

RailPro at level 5????

As I understand the the transmitter operation and protocols used in the RailPro are proprietary and not WiFi compatible. But since, as far as I can determin, Ring Engineering has not even disclosed the frequency of operation let alone any protocol details it is difficult to determine. If a system becomes available, I can check it out.

Have you tried contacting the NMRA Standards group?

This has been raised there. Not sure who is doing what, if anything currently but volunteering to help couldn't hurt.

Andy

Ken Thanks for the details,

Ken

Thanks for the details, On a scale of 1 to 10 on WIFI knowledge I may be a 3. You know the guy who knows enough to be dangerous. If JMRI and a smart phone can do it, we could have a practical beginning. As always the devil is in the details.

Andy,

Thanks for the pointer. I have looked at their ideas and posts. I may do that, if I believe I have anything to contribute.

Regards

John

**********************************************************************************************************************************************
As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality.  Albert Einstein

USB port on your phone

As you can see in this video it is possible to hook into the phones usb port to control apps. So designing device to give real buttons and knobs cant be too hard.

Model Railroaders are not alone

We are not the only ones who like the tactile control.  Check out how the music industry has addressed this issue with an iPad.  Something similar might work for a throttle.

http://www.djtechtools.com/2013/01/08/ces-2013-ions-scratch-2-go-stick-on-ipad-controls/ 

Regards,

Dave

Custom Throttle

The use of a custom throttle could be implemented with a USB device, but a custom stand alone WIFI device would be preferred. the problems of two wire interconnected devices that are cobbled together with 2 or more software applications could be both cumbersome and unreliable. It may be a quick short term solution, but would be less desirable than a dedicated WIFI throttle.

Dave,

I could not get the Tactile Link to work, I get a not found error.

Thanks for the information

John

********************************************************************************************************************************************

When eating an elephant take one bite at a time.  Creighton Abrams

That's what I've been thinking too...

Build a throttle that is WiFi capable and that will talk to JMRI.  Use your phone to call out for pizza.

Hazards of ROOTING

The key words in the referenced video is rooted which is actually a term for unlocking, hacking and downloading software to a cell phone. For those who do not follow tech news, as of January 26, 20013 it is again illegal to unlock a phone. This is when the short reprieve from the requirements of the Digital Millennium Copyright Act expired. So now to legally unlock a phone you need to get permission from your provider. Providers are now back to blocking service for hacked devices. A good hacker can get around some of these blocks, but this is not a good strategy for the average smart phone user.

Now an app / interface device supplier could try and get a provider to let their apps selectively access the USB, but for the app to be successful the writer would have to get similar agreements with all major providers. Not likely, so we are back to batteries in the remote device. Sorry to be the naysayer, but they are not interested in making it easy.

From my post one might feel that I am anti-smart phone, but in reality I am a very frustrated developer. There are dozens of interfaces I would love have for these devices, but the proprietary interests of the manufactures and providers will continue to stymy these designs. That is until they can find a way to make money from them.

Smart Stuff

I was under the impression a WIFI throttle  was step 2 in  this blog's scheme. It would be hard to skip the smart device as this has already been implemented with the JMRI system. The market has many tablet devices that are not phones that will run the throttle apps. A personal smart phone is just a convenient way to provide hardware for a throttle. I agree that a USB device is not the optimal solution.

I have worked in automation and control systems since i was a young man. In the last 40 odd years I have found that one of the major constants in the world is change. This constant change is a challenge, sometime is is best to stay on the trailing edge, but if not carful one may fall off that edge.

I guess it is only an issue, if you think it is an issue.

Regards,

John

********************************************************************************************************************************************

Technology is so much fun but we can drown in our technology. The fog of information can drive out knowledge.  Daniel J. Boorstin

Hazards of ROOTING

While it may be illegal to root a phone while it is under contract with your provider. I would think if your using it just as a wifi device such as a throttle and it has no phone service connected to it then no law broken. I have several old phones that I use as throttles.

Rob Teed 

WiFi throttle

I'm thinking it would be pretty east to construct a Wi-Fi throttle with a MSP430G2xx Value Line microcontroller, a WiFi add on board and a PWM motor controller. If you were to purchase the chips and fab a PC board you could get the size pretty small. The RC helecopter guys are already doing this.

Stuff like this is usually made by hobbyist due to a specific need. You can wait for a manufacturer to come out with something but the market right now is not big enough for any major manufacturer to invest in it.

Rob Teed

WiFi Throttle Specifications

I do like Benny's Wings idea, and those who find smart phone ergonomics and apps adequate great, but if you want, as I actually want, a dedicated WiFi Throttle where to we go. What will be the characteristics (specifications) of this device. For starters:

• Hand Held (~ 3” x 5” x ¾”) Think of a 3 x 5 note pad!
• Throttle Knob (~360 degree control with Stop)
• Color Touch Screen ( at least 3”) [With Graphics, Image and Potentially Video Capabilities]
• Direction Switch (Three Position Toggle)
• Break Switch? (Slider)
• Buttons (At least 8 but preferably 10 for Alphanumeric Input)
• USB Port (OTG) for programming the Throttle
• LAN Port (RG-45) In case the RF Fails
• Battery Power (Maybe Rechargeable)
• IEEE 802.11b,g,n and Maybe Bluetooth
• Standard WiFi Protocol Compatible with NMRAnet and OpenLCB Standards and RPs
• WiFi Networking (Compatible with JMRI WiThrottle, JMRI Web Server, Direct to Locomotive WiFi)

Screen Views:

• Setup Screen:
  • Network Setup
  • System Selection
  • Channel Selection
  • Screen Configuration(s)
• Locomotive Selection Screen:
  • Lead Loc Selection
  • Multi-Unit Selection (MU)
• Normal Operation Screen:
  • Power On / OFF (Touch)
  • Lead Loc #
  • Lead Loc Image
  • Throttle Setting (Touch and Knob)
  • Direction Indicator
  • Smoke On / Off (Touch)
• Locomotive Configuration Screen:
  • Loc 3 Digit Address
  • Loc Long Address
  • Loc Image
  • Loc Buttons
  • Alternate Configuration Buttons
• Programming Screen(s): [Should be Similar to DecoderPro Structures]
  • Programming Track / Op Mode (Touch)
  • Direct CV Programming Screen
    • CV Function
    • CV #
    • CV Value (Current)
    • CV Value to be Programmed
  • Speed Table Screen?:
  • Configurations Supported (CV 29) Screen:
  • Function(s) Configuration Screen:
• etc.

Any more thoughts?