Protothrottle

[Regularity]

My own interest stems from modelling Irish EMD locos , which never had dynamic braking , the control stand ( or desk version) had reverser, throttle , independent ( loco ) , and train brake , and a physical arrangement different to US models , even where a vertical control stand type of operation was used. Both train and independent were self lapping with slaved vacumn operation

BUT , while you can fill a DCC throttle with all forms of levers and dials, you constantly are faced with the same issues , I've played with DCC throttle design for a while now

(A) there is no consistent brake function across decoders , and certainly where variable ( often called progressive ) braking functions are provided they all operate in a different manner , hence emulating self lapping brakes is almost impossible to do correctly in DCC, and typically DCC brake levers are just forms of push button , this is also true for the Protothrottle

(b) Typically DCC implements " pseudo momentum " in the decoder , these days arguably that's the wrong place , and since , without useing railcom, you can't verify CVs values on the " main " it's hard to ensure the controller/throttles perspective of CVs values is the same as the decoder. hence throttles that rely on significant " on the fly " CV modification , run the risk of getting out of sync with the decoder

© many sound decoders in essence have fairly fixed momentum settings in order to make the sound control logic work properly , changing these CVs often screws up the basic sound logic in the decoder

So you could boil this down to this type of base system suitable for high revving diesels

1. The DCC throttle just controls sound notch up and down

2. Momentum effects are used to control speed , i.e. A variable momentum can be selected and it's this that determines how fast the " loco " catches up with its throttle setting ( in effect ) , this requires CV on the fly reprogramming and can be problematic for sone decoders

3. Variable progressive braking simply can't be emulated on a DCC throttle , there is no way to feed the decoder a variable brake factor . So it can only be emulated by " binary " braking of some degree or other . Technically , like " drive hold" you could have a function where the decoder interprets the speed byte as a braking factor , but you are now bending DCC into something it was never designed for

4. The thorny issue of where the momentum is implemented, it could be argued today , that all momentum should be in the controller , the loco responding directly to speed commands only ( rather like DC operation ) , this allows progressive braking , allowing both train and independent brake simulation and avoids the decoder having to " interpret " throttle position into sound output. This would also greatly ease DCC layout automation. ( because today you can't easily tell what actual speed the loco is doing in DCC systems)

This would mean sound would be exclusively in the form of "drive hold " types i.e. the decoder doesn't try and interpret sound output ,merely generates it according to commands from the controller

Of course this type of control doesn't suit steam locos , where the big issue is synchronising steam to wheel movement an issue that isnt really an issue for diesels

All this points to a massive failing system of the NMRA to update the basic DCC protocols to make it possible to implement these features easily ,

There is no easy solution nor one that works consistently with the present arrangement

The NMRA DCC protocols are primarily concerned with how the commands are coded and decoded, so that you can use system A to control decoders made by B, C and D, etc. To criticise them for not imposing themselves further is to misunderstand what they are there to do: they are not a regulatory body with legal powers (nor would they wish to be so). They are a voluntary body that publishes standards required for compatibility and interchangeability, as if manufacturers chose to conform, then they will maximise their sales’ opportunities. They are, in effect, a consumer champion for basic requirements, but wisely eschew going further than this. No manufacturer is forced to comply, and apart from anything else, it would be impossible for the NMRA to enforce anything at all. Something more complicated would lead to (not unreasonable) accusations of arrogance and condescension and ultimately to manufacturers doing their own thing, to everyone’s detriment.

 

I don’t like the ESU DCC command system, for example (I would be seriously interested in the new handheld unit they have in North America but not Europe) but I might choose to use their sound decoders, which means I can choose the best combination for me, and also take my trains and run them on someone else’s layout, which may have Digitrax as its base system.

 

Home computers are now so common that most DCC users probably have one, and for the cost of not a lot - certainly less than most RTR locos without DCC let alone sound - could buy a Sprog and install JMRI, even if only to fine tune decoders and remap function keys to be consistent with each other. Use of, say, phone based throttles means that one can visit friends and provide a controller as well as locos running on trackage rights, so there is no need for the NMRA to mandate what the functions actually do. Besides, manufacturers may have different sound sets they wish to incorporate, and who is to say where they put what?

 

I agree that the way momentum is handled, and the poor way it is coupled to sound, is an issue, as is the matter of engine brakes and train brakes, but that reflects a lack of imagination on the part of some manufacturers, and also on modellers - as Paul Chetter has shown, amongst others, it is possible to program a more realistic response into a decoder, but I think we have yet to see something properly designed so that the sound and speed and momentum reflect what would really be going on, depending on the load and how it was being driven.

 

But your admonishment of the NMRA for not doing what they are not there to do is wide of the mark. And no, I am not a member, and don’t intend to be, either.

[TomHolley]

Dear Tom,

 

Serious question, given that DCC-controlled train-consist wagon-braking is not yet a (common*) thing, how do you model stretch-braking operations at the moment?

 

Happy Modelling,

Aim to Improve,

Prof Klyzlr

 

* I've previously built On30 logging disconnects with working manual brakes, and literally had guest operators slide-the-wheels as they tried to drag the cars out of the yard (the call from knowing onlookers to "unwind the brakes" was met with comical responses, until the train crew actual did release the brakes), but they weren't DCC... ;-)

 

PS Tom, we need to get you hooked up with Rick Mugele over on MRH, he's another modeller actively seeking a "braking against power" solution for DCC, with a layout design dependent on nailing the problem...

Hello, Prof. I don't model stretch braking at present, since I can't. The issue I have with the ProtoThrottle is they say, on their website:

 

Introducing the most realistic throttle for

operating model diesel locomotives – the ProtoThrottle.

With the ProtoThrottle, modelers can operate just like a real

engineer because the controls feel and perform just like the prototype.

 

That's just not true. You can't operate just like a real engineer; you are missing a key component: the trainline brake stand. If you are deep enough into operations to want a prototype throttle, you'll probably want to do brake tests. It's hard to do with no brake stand...show me how to make a 20 pound reduction on the ProtoThrottle. Also, there is no amp meter. That's a fairly critical piece of equipment, too. How can I blend air and dynamic braking with the ProtoThrottle? These are things I do (or did) on a daily basis...so I am somewhat biased.

 

In short, I can't stretch brake on my railroad now. Even after I spend a ton of money on a ProtoThrottle I still won't be able to. It's nice piece of equipment, and represents a lot of thought and work, and I respect that. I can understand its appeal, but, for me, it doesn't ring true.

 

What we need is an an optional trainline brake valve. That would open up a whole range of possibilities...

 

As far as the electronics side of simulating stretch braking, t would seem to me that as you made a reduction on the modeled brake valve, it would reduce throttle output by X amount, based on the tonnage and train length parameters you input. That way, you'd still be in whatever notch you were in when you made the reduction, and less current would go to the locomotives, thus slowing the train. As you notched down, power loss would increase, reflecting less power being applied against the train brake. You would eventually stop when the power being applied was not sufficient to overcome the braking force applied. I'm probably clear as mud here, I know...

 

These are just the musings of an old engineer. Take them for what they're worth.

 

Regards,

 

Tom Holley

 

 

[TomHolley]

Hello, list. Sorry for the second post. I just received a very nice email from Scott at ProtoThrottle, in which he explained to me the thought process the designers followed in omitting the trainline brake. I understand their reasoning, and I understand they have a much better grasp of the market they are selling to.

 

I hope the product does well; I hope at some point you can get it in the UK. It is well designed, but just doesn't do it for me. Moving on now...

 

Happy modeling!

 

Tom Holley

[Junctionmad]

The NMRA DCC protocols are primarily concerned with how the commands are coded and decoded, so that you can use system A to control decoders made by B, C and D, etc. To criticise them for not imposing themselves further is to misunderstand what they are there to do: they are not a regulatory body with legal powers (nor would they wish to be so). They are a voluntary body that publishes standards required for compatibility and interchangeability, as if manufacturers chose to conform, then they will maximise their sales’ opportunities. They are, in effect, a consumer champion for basic requirements, but wisely eschew going further than this. No manufacturer is forced to comply, and apart from anything else, it would be impossible for the NMRA to enforce anything at all. Something more complicated would lead to (not unreasonable) accusations of arrogance and condescension and ultimately to manufacturers doing their own thing, to everyone’s detriment.

 

I don’t like the ESU DCC command system, for example (I would be seriously interested in the new handheld unit they have in North America but not Europe) but I might choose to use their sound decoders, which means I can choose the best combination for me, and also take my trains and run them on someone else’s layout, which may have Digitrax as its base system.

 

Home computers are now so common that most DCC users probably have one, and for the cost of not a lot - certainly less than most RTR locos without DCC let alone sound - could buy a Sprog and install JMRI, even if only to fine tune decoders and remap function keys to be consistent with each other. Use of, say, phone based throttles means that one can visit friends and provide a controller as well as locos running on trackage rights, so there is no need for the NMRA to mandate what the functions actually do. Besides, manufacturers may have different sound sets they wish to incorporate, and who is to say where they put what?

 

I agree that the way momentum is handled, and the poor way it is coupled to sound, is an issue, as is the matter of engine brakes and train brakes, but that reflects a lack of imagination on the part of some manufacturers, and also on modellers - as Paul Chetter has shown, amongst others, it is possible to program a more realistic response into a decoder, but I think we have yet to see something properly designed so that the sound and speed and momentum reflect what would really be going on, depending on the load and how it was being driven.

 

But your admonishment of the NMRA for not doing what they are not there to do is wide of the mark. And no, I am not a member, and don’t intend to be, either.

 

I think you miss my point

 

A standard  essentially frozen in the 80s is not a " good thing ", as for voluntary standards , the whole internet is based on them .  Whats different between the internet  and NMRA DCC is the internet standards have not atrophied , whereas NMRA have in essence never looked at V2, V3 of DCC.  Had they published improvements, of course these would also be voluntary , but in essence we are stuck  with a protocol , largely developed before on board sound was invented and as a result are paying the price 

 

Manufactures cant innovate , because they must maintain compatibility , hence we have shoe-horned 1980s protocols into modern requirements, which has resulted in peculiarities like Cvs that cant be read, drive holds , and binary braking solutions 

 

Had we an active process by now we could have had , improved protocols , etc and be able to model throttles far closer to the real thing 

Edited January 29, 2018 by Junctionmad

[Junctionmad]

 

 

I agree that the way momentum is handled, and the poor way it is coupled to sound, is an issue, as is the matter of engine brakes and train brakes, but that reflects a lack of imagination on the part of some manufacturers, and also on modellers - as Paul Chetter has shown, amongst others, it is possible to program a more realistic response into a decoder, but I think we have yet to see something properly designed so that the sound and speed and momentum reflect what would really be going on, depending on the load and how it was being driven.

no it doesnt , it reflected in the fact that the DCC protocol has no allowance for variable braking , engine or train , has decoupled momentum from the throttle  ( again because there is no way to handle it easily within the current protocol 

 

manufactures are then forced to come up with all sorts of back bending permutations, like Drive hold etc , purely to get around the fact that the protocol cant handle what is necessary to do it correctly 

 

Thats the issue 

[Junctionmad]

 

That's just not true. You can't operate just like a real engineer; you are missing a key component: the trainline brake stand. If you are deep enough into operations to want a prototype throttle, you'll probably want to do brake tests. It's hard to do with no brake stand...show me how to make a 20 pound reduction on the ProtoThrottle. Also, there is no amp meter. That's a fairly critical piece of equipment, too. How can I blend air and dynamic braking with the ProtoThrottle? These are things I do (or did) on a daily basis...so I am somewhat biased.

 

In short, I can't stretch brake on my railroad now. Even after I spend a ton of money on a ProtoThrottle I still won't be able to. It's nice piece of equipment, and represents a lot of thought and work, and I respect that. I can understand its appeal, but, for me, it doesn't ring true.

just a point, how can you emulate a train line brake, when in reality you have no train brakes on the cars.  I cant see your point, You simply cant and never will emulate a real locomotive and train  using a model  with the electric motor and drive train we have in current models . its simply not possible. 

 

You can make various stabs at " simulating " it electrically, but all of them are a conceit in reality 

[Regularity]

I think you miss my point

 

Quite probably, but I think you didn’t put it very well, otherwise your second post wouldn’t have been so lengthy and full of additional information.

[Regularity]

no it doesnt , it reflected in the fact that the DCC protocol has no allowance for variable braking , engine or train , has decoupled momentum from the throttle  ( again because there is no way to handle it easily within the current protocol 

 

manufactures are then forced to come up with all sorts of back bending permutations, like Drive hold etc , purely to get around the fact that the protocol cant handle what is necessary to do it correctly 

 

Thats the issue

 

I agree that’s the issue, but it is still possible, with better programming of decoders and indeed by resetting CVs (as ProtoThrottle does) to use the standard DCC protocol to issue commands. The throttle settings need, on a diesel, to determine the prime mover sounds, whilst the momentum settings cause the engine and train to move according to the load - which includes, on a heavy train, the possibility of the engine not getting the train going at all. On a steam engine, the would be a slight difference as the chuffs need to be synchronised with the wheels, but the sounds could be varied to increase the “attack”, volume, etc, reflecting full gear, etc. Essentially the throttle setting is determining a target speed setting, and the momentum setting determines how long it will take to get there. By comparing the difference between the two, it is possible to vary the sound of the exhaust beats as the driver/engineer notches up the valuable gear to allow for expansive working.

 

Better still, there would be two levers on the controller, one for throttle and one for regulator, as well as one for engine brake and one for train brake. The actual sounds should be driven by an intelligent program that does the hard work in getting that right, so that you then drive the engine according to the load. Drive hold/full throttle is, to my way of thinking, a dead end development as we should be looking more at how we can best simulate the driving experience, not becoming sound effect engineers.

 

All of what I suggest is achievable using existing DCC prototcols.

All of what I suggest would benefit from much better protocols, but it is not the input that matters here, but what happens between the input and the output. Sound is an output just as much as the current fed to the motor. The output from a decoder is up to the manufacturer, and not so dependent on the protocol, which should really be saying things like “set the momentum CVS to high values, to reflect a heavy load; now set the target speed to 56/128 steps, and accelerate to that based on the momentum settings last provided, and make sure that the main sound effects are delivered accordingly, based on the gap between whatever we are at and 56”. Extra sounds, horns, whistles, bells, whatever would remain independent and of course, there would be a coast/brake set of CV instructions and mappings, with some brake squeal blending in as the brakes get proportional tighter.

 

Abandoning protocols and making them bigger and more complicated or just requiring more memory is what the computer industry typically does, rather than writing better operating systems and more efficient programs: I am not saying the the current DCC protocols aren’t old and wouldn’t benefit from some revision, but backwards compatibility needs to be maintained, and rather than putting more into the bandwidth, why aren’t we making much better use of the in-board microprocessor on the decoder?

[Junctionmad]

Better still, there would be two levers on the controller, one for throttle and one for regulator, as well as one for engine brake and one for train brake. The actual sounds should be driven by an intelligent program that does the hard work in getting that right, so that you then drive the engine according to the load. Drive hold/full throttle is, to my way of thinking, a dead end development as we should be looking more at how we can best simulate the driving experience, not becoming sound effect engineers.

 

the issue is not how many levers the throttle has.  There is no reason to not have all sorts of stuff on an electronic throttle 

 

The issue is how you communicate all that information to the loco and what the loco does with that information 

 

example, how can you communicate variable loco and train brake information , when the underlying protocol has only a single variable  field ( i.e. speed ) 

 

This is precisely why LokSound came up with Drive hold , at any one time you can only communicate one variable to the decoder, be it sound , speed , brake etc 

 

 

Secondly the nature of the DCC protocol is you cant  read CVs on the main, hence you cant design a reliable dynamic system that relies on large scale reprogramming of CVs to reliably stay in synch , especially if you have multiple ways of so programming these CVs 

 

again a failing of the original DCC protocol, which the NMRA tried to sort with Railcom , but we know where that went 

 

 

and Yes I agree with you , "in theory ", we should have the throttle controlling sound with the loco speed controlled by momentum settings , the reality is today , you largely have that , even if some of the implementations leave a bit to be desired. The issue  is how you then can communicate loco and train brake information in a protocol that has " brake on" "brake off " functionality.

 

You can see this directly in Protothrottle, the brake lever is actually a fiction as its not graduated , all its does is at a certain point in its travel , generate the Brake function code . Why you ask is that the way , because , the underlying protocol cant send anything else to the loco 

Edited January 30, 2018 by Junctionmad

[Junctionmad]

 

 

Abandoning protocols and making them bigger and more complicated or just requiring more memory is what the computer industry typically does, rather than writing better operating systems and more efficient programs: I am not saying the the current DCC protocols aren’t old and wouldn’t benefit from some revision, but backwards compatibility needs to be maintained, and rather than putting more into the bandwidth, why aren’t we making much better use of the in-board microprocessor on the decoder

the are many ways to have successive protocols and maintain backwards compatibly. its done all the time everyday in computer systems , even in model railways , JMRI supports bother versions of the Engine Driver protocol the original and the more advanced. both are compatible and the throttle has a way to announce its using the more advanced protocol etc 

 

dave

Edited January 30, 2018 by Junctionmad

[TomHolley]

Junctionmad said, "just a point, how can you emulate a train line brake, when in reality you have no train brakes on the cars.  I cant see your point, You simply cant and never will emulate a real locomotive and train  using a model  with the electric motor and drive train we have in current models . its simply not possible."

 

That's exactly right. So how does the ProtoThrottle let me operate exactly like a real engineer? It doesn't. It's a throttle with a lot of bells and whistles, but it won't let "modelers can operate just like a real engineer because the controls feel and perform just like the prototype." because they don't. I don't think that's really truthful advertising. Again, that's just my take on it. That's my issue with it.

 

Regards,

 

Tom Holley

[Regularity]

Suggest that comments on errors over ProtoThrottle be posted on the MRH thread, where the development is actively discussed.

[Regularity]

The issue is how you communicate all that information to the loco and what the loco does with that information 

 ...

You can see this directly in Protothrottle, the brake lever is actually a fiction as its not graduated , all its does is at a certain point in its travel , generate the Brake function code . Why you ask is that the way , because , the underlying protocol cant send anything else to the loco

 

Ah. I see. I hope.

So anything like applying a partial brake would have to be done at the controller, not at the decoder, and to simply modify the speed signal sent over DCC?

Yep. Big problem.

 

This sort of thing was easily achievable with straight DC in the seventies, using a capacitor and a couple of variable resistances driving a pair of transistors (I know cos a friend and I built one to a circuit published in 1975!) so I sort of assumed this would have been built in to any “advanced” control system dating from 10+ years later. Maybe it was a “not invented here” mindset?

Secondly the nature of the DCC protocol is you cant  read CVs on the main, hence you cant design a reliable dynamic system that relies on large scale reprogramming of CVs to reliably stay in synch , especially if you have multiple ways of so programming these CVs 

 

How is that, for example, you can switch between two different CV sets on a Zimo decoder via a function key, or change the momentum settings with an NCE powercab/procab?

Not being difficult, just wondering how they do it within the constraints of the current protocol?

 

The only reason I have DCC is for the sound: otherwise I would go for remote/direct control. I am beginning to wonder if the DCC is worth it, at least how it currently stands. An on-board Arduino with DCC++ directly controlled might be a better solution: when the engine is at rest, I could use POM to re-configure some settings, and have the sound and drive separated at source. Seems like a bit of a faff, though!

[Mike Storey]

I don't really understand most of what is being discussed, as my eyes kind of glaze over. However, I use a ZTC 611, which has similar brake and throttle levers to the Protothrottle, albeit as a desk console, and with RealDrive sound chips, it works just fine at simulating what I used to be able to do with a similar DC arrangement years ago, except that I now get the associated engine (and automatic brake and flange squeal) noises, that help me to drive in a way that I think is more realistic.

 

I do not know what "realistic" really means to a professional train driver, as I was never a loco driver (apart from a few stints on a preserved railway, on a small shunter). That will be the case for the vast majority of users. What I think it means, personally, is that I have to wait for the appropriate sounds to be generated before moving off (brake pump, brakes off, sound horn, revs up etc), not just take off like a rat from a bottle, and throttle up or down according to programmed load, and then try to work out where to start braking whilst coasting, to stop where I should, rather than a less than realistic,power controlled halt. The sounds add to the sensation of driving. The levers, as opposed to buttons or touch screen, add even more to the sensation. If this throttle achieves that for the vast majority, it will have done its job? 

[Prof Klyzlr]

Dear UK/EU ProtoThrottle wistful,

 

I stand corrected,
(yes, I was wrong, not the first time and certainly won't be the last),

for those who haven't caught up on the relevant threads on MRH
http://model-railroad-hobbyist.com/node/32344?page=3 

 

herewith the official explanation from ISE's Michael P.

 

 

Contrary to popular opinion, it is NOT the radio module that is limiting the countries to which we can ship.  The radio module is pre-certified in a number of markets, including the EU.  While the output power would have to be limited to 10mW, that's easy.

The limitation has to do with the other testing requirements for any electronic device that emits unintentional RF radiation.  I won't go into the details yet again, but for your reading pleasure, look up Unintentional Radiator:

https://en.wikipedia.org/wiki/Unintentional_radiator

Or, for all the gory details:

https://www.ecfr.gov/cgi-bin/text-idx?mc=true&node=sp47.1.15.b&rgn=div6

Europe and other parts of the world have similar regulations, some more restrictive than the US, and adding additional requirements such as immunity testing.  All of these add cost, and more importantly time, to the development, in addition to increasing the risk that a redesign be required to meet the more stringent requirements.  Not being intimately familiar with all the EU directives, and having plenty of other (more interesting) things to spend my time on, this is a huge risk to take.  This isn't to say we wouldn't pass, but it costs a lot of money to find out.  Some have suggested that we simply "self certify" for the CE mark.  While it is true you can self certify - it doesn't require an accredited lab as in the US - you still have to have the data to back up your claims.  And since I don't have a $100k anechoic chamber sitting in my backyard, decked out with all the RF and EMC gear to take the measurements, self-certification is not an option.  And I'm not about to lie and just slap a CE mark on the product - I like my ability to travel and vacation in the EU. 

Without a solid market case, I can't justify at this point making 3-4x the investment to get CE marking for, what is most certainly, a smaller market in an already niche market of a hobby.

Michael

 

FYI...

 

Happy Modelling,
Aiming to Improve,
Prof Klyzlr

[F-UnitMad]

So how does the ProtoThrottle let me operate exactly like a real engineer? It doesn't. It's a throttle with a lot of bells and whistles, but it won't let "modelers can operate just like a real engineer because the controls feel and perform just like the prototype." because they don't. I don't think that's really truthful advertising. Again, that's just my take on it. That's my issue with it.

 

Regards,

 

Tom Holley

I think Mike makes a good point. How many railroad modellers are Engineers in real life, too? So we don't really know how it feels to drive a train, but this throttle would get 99% of us somewhere close.

Until fairly recently I was a truck driver in real life. I enjoyed the job (most of the time!!) but sure as hell didn't want to make models of them in my spare time Nor would I expect a large scale Radio Control model truck to give a 'true to life' experience of what it's like to drive them for real. Some aspects, such as getting on the catwalk to couple the suzies, & negotiating your way through a 4-over-4 gearbox, just cannot be translated into miniature! I suspect that if I could drive real trains (American, naturally!!) I wouldn't bother modelling them as well...!!

So I have no end of respect for real-life Railroaders who model trains as well, but while model diesel trains are powered so completely differently to the way they are in reality, there'll be no way in the world that control of them will be a 100% lifelike experience.

Edited February 2, 2018 by F-UnitMad

[Petesquire]

I think Mike makes a good point. How many railroad modellers are Engineers in real life, too? So we don't really know how it feels to drive a train, but this throttle would get 99% of us somewhere close.

Until fairly recently I was a truck driver in real life. I enjoyed the job (most of the time!!) but sure as hell didn't want to make models of them in my spare time Nor would I expect a large scale Radio Control model truck to give a 'true to life' experience of what it's like to drive them for real. Some aspects, such as getting on the catwalk to couple the suzies, & negotiating your way through a 4-over-4 gearbox, just cannot be translated into miniature! I suspect that if I could drive real trains (American, naturally!!) I wouldn't bother modelling them as well...!!

So I have no end of respect for real-life Railroaders who model trains as well, but while model diesel trains are powered so completely differently to the way they are in reality, there'll be no way in the world that control of them will be a 100% lifelike experience.

 

I agree with you and Mike. I saw a video of this being used on Tim Garland's Seeboard Central layout. Tim is a full time engineer with Norfolk Southern and he seemed very pleased with it.

[F40Andy]

Not sure if the situation has changed since this thread started with regards sales in the UK.

I have increasingly seen these used at shows in the UK on American layouts.

It would appear that friends in the US have purchased them on the UK residence behalf and shipped them as presents quoting that they are "Model Railway items". Quite what the UK customs would say if they knew, I am not sure.

Sadly this results in a "High Powered" radio unit being used presumably illegally.

If I read the thread correctly, its the cost of getting a unit that emits radio waves, licenced for use in the EU that is the barrier. Does this mean that a DCC fitted loco has to be certified ? my layout certainly plays havoc with my nearby radio.

Reminds me a bit of the CB radio stuff years ago.

I have resisted on the grounds that my bank manager would not approved.

[Prof Klyzlr]

Dear RMWebbers,

 

Just a BTW update, the Pt hasn't "grown a trainline brake valve",
but the latest Firmware update has implemented a "brake test" function,
in "trainline recovery time" and pressure readout...

 

 

...It's also gained an "Engineer Alerter" function,
though for my own experience on small and micro layouts,
I'm never "at rest" or "at constant speed" long enough to loose comcentration,
let alone trigger a "Hey Engineer, you still with us?" Alerter alarm... ;-)

 

Happy Modelling,
Aim to Improve,
Prof Klyzlr

[mdvle]

1 hour ago, F40Andy said:

Sadly this results in a "High Powered" radio unit being used presumably illegally.

If I read the thread correctly, its the cost of getting a unit that emits radio waves, licenced for use in the EU that is the barrier.

 

Not a lawyer, not an electric engineer, etc. - personal guesswork.

 

It is highly unlikely to be a "high powered" radio unit - it runs on 2 AA batteries and while a quick look at their website doesn't reveal the details it will I assume be using the same general low power radio stuff as used by (for those old enough to remember) cordless phones, baby monitors, and a multitude of other lower power radio devices in that band of frequencies authorized by the US government.

 

Given the commonality of electronic parts in this day and age it is likely (unless the UK/EU don't allow public use of the given frequencies) that getting licensed in the UK/EU is simply a matter of cost, a cost that can't be justified given how few would be sold given it is really a US prototype inspired control (my understanding, from comments made by the people making the Protothrottle on podcasts, that total sales are under 1,000 units).

 

1 hour ago, F40Andy said:

Does this mean that a DCC fitted loco has to be certified ? my layout certainly plays havoc with my nearby radio.

Reminds me a bit of the CB radio stuff years ago.

 

DCC doesn't use radio.

 

That said, any unshielded electronic device or electric motor can cause short range interference.

[Andy Reichert]

DCC was never designed in the first place to be a full peer to peer network. Hence many of it's data transfer limitations. But then model locomotive and train mechanisms don't have the equivalent mechanical functionality and heavyweight physics of their prototypes either. And that's without taking into account the excessively compressed time and distance of travelling the trackwork on a typical model layout.

 

My only interest in any form of model controller is to have a seat at a fixed dashboard with a screen showing the appropriate cab or switchman view, and both hands free to operate the various controls.

 

The idea of controlling a prototypically cab driven model by flying magically 100 scale feet above and looking down on the whole train and it's environment is way off in my mind. :) 

 

Andy