RailPro for
Model Railroading is interesting in its
requirements for radio communication. RailPro radio communication
needs to have dependable real-time control so your speed changes and button
pushes are responded to almost instantly and it needs to transfer data well (for
sounds, pictures programs, etc)! Further it needs powerful networking to
allow hundreds of handheld controllers (throttles),
locomotives, accessories, etc. on one layout to communicate together. With
RailPro, locomotives need to be able to communicate their pulling power directly
to other locomotives in the consist to do our real time true load sharing.
Further, RailPro needed to be capable of simultaneously and seamlessly
transfering control of locomotives and consists from any one controller to any
other and much more! Before we built RailPro, we looked into all
the commonly available radio standards and found none of them to be great fit
for running model trains. We looked at WiFi, Bluetooth, and others.
When our research was over, it was clear to us that no common existing radios
were going to be what we wanted for RailPro. This is why we created
'Direct Radio + NET' communications for RailPro instead of using off the shelf
solutions like WiFi or Bluetooth!
Below is why we found 'Direct Radio + NET' to be far superior to other wireless
solutions for communications.
'Direct Radio + NET' vs. 'WiFi'
- We have seen WiFi communications stall before so for us WiFi
was not going to be a good choice for RailPro. Imagine trying to blow a pattern with the horn or more importantly
trying to stop your train if WiFi stalls! The communications need to
respond nearly instantly and always needs to be dependable (Real-Time).
Direct Radio + NET was designed from scratch to be a
real-time control system and not have stalling problems. We have sold RailPro
for years, and as of this writing, basically no one has ever complained about
RailPro not being responsive and working well even on huge layouts.
- WiFi uses too much power.
Any WiFi solution we looked at used far more power than we wanted. We put
Radio Transceivers in locomotives so it is important that they are small and use
low power. Also, our handheld controllers and locomotives may be battery
powered, so low power is important for longer battery life. Our HC-2 handheld
controller can run over 12 hours on a single charge! Direct Radio + NET
electronics do not create much heat and that allows us to put radios in smaller packages!
- WiFi setup can be complicated.
Direct Radio + NET setup is so simple just press 'Find
Product' button when you buy a new product (locomotive accessory etc.) and
simply select a repeater if you need one or more in your layout....SIMPLE!
Compare that to WiFi with WEP keys, subnet masks, channel selection and so on.
- WiFi software libraries to us are bloatware.
Direct Radio + NET was written from scratch by Ring Engineering and only has the
code needed to run model trains! Therefore the code is small and fast.
If you use bloatware in your product, it can cause you to use a more powerful
processor with more memory which can drive costs up and create more heat.
Direct Radio + NET keeps the cost of our radio products at a minimum and less heat
allows us to put radios in smaller packages!
It was obvious to us that WiFi would not be a good solution for RailPro.
'Direct Radio + NET' vs. 'Bluetooth'
- Bluetooth was not designed for powerful networking.
With RailPro, we
needed powerful networking capabilities. We needed a radio system that supported
handheld to handheld communication (two-way), handheld to locomotive
communication (two-way), locomotive to locomotive (two-way) communications.
Further, RailPro needed to handle hundreds of throttles, locomotives,
accessories, etc. on one layout. Below are just a few examples of how networking is required by RailPro:
1) RailPro needed to allow one user to make up a consist of several locomotives
and put it in motion. Then if another user selected any locomotive in the
consist, the user would take control of the entire consist at current speed.
Further, the user that lost control needed to be notified that control was taken
away.
2) If one user presses stop all, then every handheld needed to coordinate with
each other to stop all the locomotives.
3) Locomotives need to be able to
communicate their pulling power directly to other locomotives in the consist to do
our real time true load sharing.
These are just a few examples of how RailPro's 'Direct Radio + NET' uses its
very advanced networking.
- Bluetooth software libraries to us are bloatware.
Direct Radio + NET was written from scratch by Ring Engineering and only has the
code needed to run model trains. Therefore the code is small and fast.
If you use bloatware in your product, it can cause you to use a more powerful
processor with more memory which can drive costs up and create more heat.
Direct Radio + NET keeps cost of our radio products at a minimum and less heat
allows us to put radios in smaller packages!
It was obvious to us that Bluetooth would not
be a good solution for RailPro.
Copyright © 2019 Ring Engineering, Inc.
|