# Next Gen Interfaces - emerging schemas



## VictorSpear (Oct 19, 2011)

Over the holiday we had some fun evaluating interface schemas for the iPod Touch and Androids as submitted by a couple of my students for a colleague who requested them for introduction into his lineup for the New Year. Here are a couple that I found very simple and intuitive:




















Hope to have many more designs coming through..

Cheers
Victor


----------



## DKRickman (Mar 25, 2008)

I still cannot understand the fascination with touch screen controls. If the controls are on the screen, then you have to LOOK at the screen to use them. There is NO tactile feedback. That's ok for getting a train running on a loop and then sitting back to watch, but useless for switching. I want to look at the trains, not the control.


----------



## Greg Elmassian (Jan 3, 2008)

Was just going to say, you need speed controls that you can use w/o looking at, and also you need feedback when you have bumped the speed up and down. 

I have used both my smart phone and tablet... for running trains that only need occasional use, like running in an unobstructed loop on the flat, they are fine, but for any kinds of real "driving" of a train, it's worthless, and just a curiosity. 

For programming a loco on DCC, it's convenient, and more portable than a laptop, there's a good application. 

If you want to improve your interface, you need finer control of the speed at slow speeds, the circle does not work well, have tried it on other speed controls. 

The multiple train lookup is ok, but you don't need a lot of screen space to display 5 locos... even the best "engineer" I know can barely run 2 trains at once in anything other than a "toy" layout. 

I'd at least have the horn and bell buttons on all screens where you have a throttle. 

Greg


----------



## VictorSpear (Oct 19, 2011)

The latest version of the schema has the following tabs:
Control - Trains - Tracks - Turnout - Lights - Sounds

The Horn/Bell on the Control tab would be more useful than on separate Light/Sound tabs - I agree.


Only two trains at once - in which world ? Try 16 over remote Command & Control. 


Cheers
Victor


----------



## Greg Elmassian (Jan 3, 2008)

The post was about the interface on a smart phone. 

So, the person using the smart phone would have to be very adept at running 2 trains at the same time. 

If you were going to have the smart phone be the "nexus" for a complete automated command and control system, the amount of real estate is quite small for a programming interface. 

If you are just going to start and stop a completely automated program, well all you need is an on off switch... that's not the type of train running I want to do. 

Anyway, the WiThrottle and EngineDriver apps work ok for the people who use them, so their interfaces can be a starting point. 

If you have a wide "throttle" bar on one side, you could probably change the train speed without having to look at the throttle, have it work as an incremental "knob" as opposed to using an absolute position on the screen for an absolute speed. 

Regards, Greg


----------



## VictorSpear (Oct 19, 2011)

The Feedback layer has now been added to the Control tab. Speed feedback can driven from the rotary encoder if fitted for accuracy, otherwise from the motor driver feedback circuit. By having the Sound and Light controls on their own tabs, various sounds for different model locos can be selected although the debate of including at least one horn/bell combo on the main tab is still going on here.

We are approaching a design that is different from the Wiithrottle, EngineDriver or TouchCab as they all involve a broad DCC infrastructure to support them...Herein, the layout is inherently 'shareable' and the guest simply arrives with their own communicators (a.k.a smartphones). They download the local layout plan at the host facility wirelessly, select an available loco and begin navigating their trains. Also the design does not involve DCC, command stations or decoders - being a 100% wifi/radio alternative. Ideally suited for local clubs with large visitor attendance like our campus layouts where guests stay for an hour or two.

Cheers
Victor


----------



## Brandon (Jul 6, 2011)

Posted By VictorSpear on 28 Dec 2011 08:30 AM 
Also the design does not involve DCC, command stations or decoders - being a 100% wifi/radio alternative. Ideally suited for local clubs with large visitor attendance like our campus layouts where guests stay for an hour or two.

Cheers
Victor



What hardware (inside the trains) are they using to the motors, lights, sounds, smoke, etc? Are they also providing motor speed feedback (or another method of detecting speed), or other useful features back to the UI? As you know I'm always looking for information on what hardware people are using inside the trains to do the controlling as this is still a grey area in my personal project.


----------



## VictorSpear (Oct 19, 2011)

More than 30 different MCU implementations are being tested by 4 University teams in different countries. The most popular family of MCUs in our field layouts is the ATMEL 32 bit AVR UC3 and last month the UC3L was brought into a design challenge competition theme proposal. The focus is picopower - around 165 *micro*amps/Mhz in* active mode* ! This is usually combined with 'sleepwalking' features of the OBC with parrotpower for sound/light control. The target run time is 7.5+hrs/charge on certain models at 14.4 V NiMh. As mentioned in my earlier posts, location/speed/distance/velocity/acceleration/braking feedback is achieved with a fitted quadrature encoder (plus some integral calculus) where the UC3s have the encoder inputs built-in. There is an active University program too.


More recently, about a dozen* TI ARM *(Sitara) Cortex have arrived as 'Beaglebones'. Let's see what this gives us. 


Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

Strange, since one of the problems we do NOT have is power, either from the rails, or batteries. 

The power used by the cpu is nothing compared to running motors, lights and smoke. 

This does not sound like a project focusing on model trains. 

The "university program" is a little misleading... Atmel, who maufactures chips, makes certain hardware available at a discount for use by university students. 

That's like saying Apple or Microsoft has a university program. 

I've designed several products using Atmel hardware, but none of what I have seen except your pictures of a screen mockup have anything to do with trains. 

Do you have any links/reading on train oriented development? 

What you need is low cost, wireless built in, high current outputs, and some form of networking. 

Greg


----------



## VictorSpear (Oct 19, 2011)

I don't think you have kept up with the breadth and offering of the Atmel University program.Visit Cornell if you get a chance.



If your objective is to pull 50+ cars by supplying 24V/30Amps to the wired rails - sure you can use DCC plus 'boosters and 18 guage wiring' and blow the horns loudly all day . We've moved far beyond the power sucking push model methods. In our world the modeling precedes the 'prototypes'. In an all battery/wireless radio environment you may note the 2 to 4 hrs of charging frequency in most of the current implementations, for example. Sure power is not a problem, if you want to load up trailing cars with fat batteries and run trains all day.


BTW that is not a mock screen at all. 


Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

You miss the point, I understand, I read the page... it's as I said... if it's different, point to the information. I was most likely designing devices with CPU's before you were born. I've done cutting edge stuff. There is no University class in a new train control system. 

Cut through the bluster, technospeak, and provide some real information. 

There's no question that Atmel helps people understand their hardware so the will use it when they get jobs... this is not a new or foreign concept. 
Get back to the application of trains. 

What is the blue blazes are you talking about here?* "We've moved far beyond the power sucking push model methods." 

*Huh? you have trains that move without power? You have new electric motors that defy the laws of physics and can do work without consuming power? 

You are going further out in left field here... 

What galaxy is "your world" in? You state:* "In our world the modeling precedes the 'prototypes'." 
* 
That statement is patently absurd... the idea of modeling is to mimic the prototype.... how can you precede a prototype from the 1940's in 2012? 

Really, you need to stick to facts and what you can do to make a new control system. 

That's not a mock screen? Well, send me the hardware and software, send it Fedex to my house, get it here in a week and I'll send you $1,000.... 

Yeah, right, the word "mockup" is not the same as "mock".... mock means fake in a way, mockup means like a prototype of the "look" in this case, but NOTHING behind it... 

The $1,000 is waiting... 


Make something, come with with a hardware design, analyze the costs, come up with a software architecture.

I've designed and implemented products before. 

*
* Greg


----------



## Brandon (Jul 6, 2011)

Posted By VictorSpear on 02 Jan 2012 08:34 AM 
More than 30 different MCU implementations are being tested by 4 University teams in different countries. The most popular family of MCUs in our field layouts is the ATMEL 32 bit AVR UC3 and last month the UC3L was brought into a design challenge competition theme proposal. The focus is picopower - around 165 *micro*amps/Mhz in* active mode* ! This is usually combined with 'sleepwalking' features of the OBC with parrotpower for sound/light control. The target run time is 7.5+hrs/charge on certain models at 14.4 V NiMh. As mentioned in my earlier posts, location/speed/distance/velocity/acceleration/braking feedback is achieved with a fitted quadrature encoder (plus some integral calculus) where the UC3s have the encoder inputs built-in. There is an active University program too.


More recently, about a dozen* TI ARM *(Sitara) Cortex have arrived as 'Beaglebones'. Let's see what this gives us. 


Cheers,
Victor 

Do you have any links/info on parrotpower? I tried searching a little but didn't see anything that would be replated to sound or light control from a MCU (don't know if parrotpower is either software or hardware). 

Is part of the goal to create a hardware device that can be bought by modelers in either kit or assembled form or is the hardware and software mainly for university research and thus not going to be an actual product? 


Also is the scale HO are are the various universities running G scale? I think MIT that you've referenced is HO only? I can see why battery running is more limiting on that scale. 

Edit: Curious too, how is communication being achieved? I didn't think the Atmels had wifi? Are you sending binary, xml, or another format over sockets or a zigbee/zwave connection? (You mentioned wifi but I'm curious what hardware is handling this as I don't imagine you're runnning an embedded OS on the ATMEL are you?


----------



## VictorSpear (Oct 19, 2011)

Brandon,

I'm still framing a response to Greg's barrage ... but yours is simpler to answer  ....you do have an open mind and do not dismiss what you don't know or have not (yet) heard about.


You may find the parrot event-driven DMA model interesting....if you haven't missed the point about Power Modeling Efficiency that I am making. Others will dismiss it as '*BS*cale' of course since their decoders will need over 3 amps to blow a horn at the rate they are going. Where is the modeling there, one may ask, if you want to stuff more amps into a wired train to make things happen ? 


Much of the research is sponsored by manufacturers of course...our Universities just cannot afford it otherwise. Outdoor, solar/battery powered robotics are a top subject here. Our famous auto industry that went near-bankrupt twice is one shining example of the 'power is plenty, fool, don't worry about it' approach.


Take a good, hard, non-cynical look at this. Your next question should be " What sort of micro-amplifier can drive the output with stereo sound " ?



Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Greg,

_ "I was most likely designing devices with CPU's before you were born" -- _Very likely to be the case..with all due respect....but age seems to cloud thy thinking now - methinks. It should be the other way around.


"_I've done cutting edge stuff_" - Why have you stopped ? 

_" There is no University class in a new train control system" --- sigh, _which University have you visited recently ? I have a list of over 30...look at this list...just look at it..?


http://www.railml.org/web/index.php/supporters.html ( See if you can spot a University here)
http://www.city.ac.uk/engineering-maths/undergraduate/student-projects/model-train-set ( This is in an undergrad course )

http://www.tsd.org/papers/IEEE 1473-L Communications Protocol.pdf (Where do you think the next generation of this is being researched ?)
....

http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/ ( If you don't see model train applications here...you never will) Maybe Santa will.


"_You have new electric motors that defy the laws of physics and can do work without consuming power_" ( Consuming much less power and doing more. If you use the cheap $20 or less junk motors in the model trains that you now use....this may not be of interest).


_ "You are going further out in left field here.." _And why not ? Almost everything you use today came from way out in left field. Not from mainstream status quo, I assure you.


_ What galaxy is "your world" in? You state:* "In our world the modeling precedes the 'prototypes'."* _Yes, a paradigm shift. See the definition of 'prototype' in any way you choose. Then simply chose the way you want to interpret it. Model first or prototype first ? Here is a good statement that may help one out: China is the only country in the world to have a fully functioning, production-ready, German designed Maglev daily run. What came first, the model or the prototype ? Yes the implementation can be patently absurd to most.


_Really, you need to stick to facts and what you can do to make a new control system. _- Myself and a team of engineers from a known University are re-defining in a forthcoming IEEE paper, the very meaning of Command & Control. I'm uncertain if many can handle it. Hint: Follow the US Coast Guard model.


Mockup ? Here's something I call a mockup to people  http://www.youtube.com/watch?v=9ZOqhPbj7rs


"The $1,000 is waiting..." No thanks, we are are talking about thousands of hours of student/faculty work here but your offer is generous. Look for a release at the end of March/April 2012 when the manuals and documentation are in place. When things are dismissed as BScale, it can wait. It will be a lot cheaper than that. Instead, send the money to MIT/Reas/Fry who support the Processing language. Incidentally, Fedex shouldn't be taking a week to get anywhere (my jab). 


"I'm not intentionally giving you a hard time, but this is going from techno-bluster to BS." - No you are certainly not giving me a hard time, Sir...I have 200 minds that do more than that every day. But as for techno-bluster to Bscale ...do you really want me to respond ?


"Make something, come with with a hardware design, analyze the costs, come up with a software architecture." - It's what we do for a living but it may not fit some minds...


" I've designed and implemented products before."- Why have you stopped ? Just curious.


Cheers,
Victor


----------



## Brandon (Jul 6, 2011)

Vic, took a look at the video, when I get more time I'll check into its hardware, quite nice for the low usage on parrot. Can I ask for answers to my other questions you missed? Thanks.


----------



## Del Tapparo (Jan 4, 2008)

Since I am subscribed to this forum and really don't want to miss out on most of the discussions here, and I don't know how to unsubscribe from just this thread, I guess I will just have to endure it 


At first, I found this to be of some interest. I'm a technical guy, but this stuff is way over my head, and I am assuming the same for 98% of MLS members. That is not to say it isn't still of interest to some, even though they don't understand it all. For me personally, the posts are way too long, way too complicated to be of any real interest, as far as real garden railroading goes, 


I will continues to read the first two lines of each post with my delete key at the ready.


----------



## VictorSpear (Oct 19, 2011)

Sorry, didn't notice the edit on your post as I was toweling dry in my corner while refuting some jabs from another savant. Okay, here it is:

Communications: REST web services using URIs (not URLs, no SOAP), UDP, Zigbee. Core comm and network layer hardware (amongst several candidates) is here... - an SOC.


Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Del,

If I spent all my time responding to your jabs, yes I wouldn't have a job. Try CTRL+ALT+DEL ... it might be faster on your machine 

Funny, you don't post much...you simply respond as "Nope", "BS..." etc...nice manufacturer vested style. I thought the forum was about sharing.


Cheers,

Vic.


----------



## VictorSpear (Oct 19, 2011)

A brief list of institutions that offer teaching, research, projects and industry JVs with scale models and real world applications

Australia
http://itee.uq.edu.au/~mint/
http://www.eng.monash.edu.au/railway/
http://www.qut.edu.au/study/courses/master-of-engineering-railway-infrastructure
http://itee.uq.edu.au/~aupec/aupec99/zou99.pdf

India
http://www.iitk.ac.in/me/Presentation/Mechanical.pdf

China (Beijing Jiaotong University, Beijing, China)
http://www.at0086.com/SJTU/Courseview.aspx?pid=78839
http://www.chinatefl.com/gansu/teach/lzru.html (tangshan Railway Institute)
http://en.cnki.com.cn/Article_en/CJFDTOTAL-TDXB201105017.htm
http://en.cnki.com.cn/Article_en/CJFDTOTAL-ZGTK200501022.htm
http://www.cnngo.com/shanghai/life/china-maglev-train-hits-1200-kph-636051

Germany
http://www.integratedsoft.com/CaseStudies/IFW-Dresden
http://www.uni-stuttgart.de/iev/

Korea
Hanyang Univ - Dept. of Transportation
http://www.hanyang.ac.kr/english/

Russia
Petersburg Government University of Railways
http://www.pgups.ru/

Swiss
http://www.ethz.ch/index_EN
http://www.ifor.math.ethz.ch/publications/2007_caimi_trainscheduling.pdf

UK
http://www.york.ac.uk/inst/irs/

US Universities

Several have railroad clubs (MIT, RIT..) where you can do your thesis/project

And also..
Carnegie Mellon/U of Michigan 
www.ri.cmu.edu/ 


US (Next Gen)
Appalachian State University - 
http://hydrail.org/
http://hydrail.org/node/44

...
...
NYU ITP with the Processing course (the core language for our models)

http://itp.nyu.edu/itp/


----------



## Cougar Rock Rail (Jan 2, 2008)

I'm finding this all very interesting, educational, and quite entertaining as a bonus. I'm a firm believer in using models to create prototypes and unless you take a stab at it you'll never make incremental progress...poking theoretical holes is really a waste of time. 

Keith


----------



## East Broad Top (Dec 29, 2007)

Gentlemen, 

*QUIT THE PERSONAL ATTACKS OR THIS THREAD IS LOCKED!!!* 

Got it? 

(This thread is too convoluted to try to weed out all the attacks from the good information to try to delete all the offending posts. Consider _all_ parties involved equally warned.) 



Del, you can uncheck the "subscribe to this thread" box at the top of the page to stop getting notices in your inbox. 


K


----------



## Dwight Ennis (Jan 2, 2008)

QUIT THE PERSONAL ATTACKS OR THIS THREAD IS LOCKED!!! 


Got it? Seconded and affirmed.


----------



## Brandon (Jul 6, 2011)

Victor, will RailML be implemented on both sides or will it be a new communication protocol? Are there any white papers on how communication will work? Both data protocol as well as basic information such as if the consumer device talks directly to the loco or do the consumer device and the loco talk to a third party server that's managing the railway?


----------



## VictorSpear (Oct 19, 2011)

Ok, now that Squelch mode is turned on, conversations can be more focused on the subject of the thread - *schemas*. Yes, 2-way messaging from the start using the RailML open messaging format. If it works for the billion dollar industry consortium in the EU, it works for us. The sample RailML DTD examples provide wonderful ways to establish RESTful messaging between:

1. Object to Object ...{Loco to Loco, Loco to Switchyard, Loco to Station(s)}

2. Object to Coordinator (Handheld)
3. Object to Monitor (Repository of all known artifacts in the layout) 


Our first model (Model 100A) provides for the simplest of loco-to-coordinator 2-way messaging.


Best.
Victor


----------



## DKRickman (Mar 25, 2008)

I am confused. 

Is this a new wireless control system designed for a model railroad application? If so, what scale is it intended for? Will it require users to buy new motors, gears, etc. in order to install in their current locomotives? Is it be battery or rail powered? 

Please, no tecnho-jargon, no arguments. This is a model railroad forum, so I'd really like answers to real-world questions that a real-world model railroader can use to decide whether he is interested in this system. What does it do, what does it cost, and why is it better than what is already on the market?


----------



## VictorSpear (Oct 19, 2011)

Kenneth,

Points Noted.
The latest post was a direct response to a direct question from an active member involving communication modes. I was reminded by the requester to elaborate at least twice 

To answer your specific question:


 The original post (Next Gen Interface Schemas) was to discuss taking a look at the emerging trend towards using commonly-available-household-devices for model railroading of any scale. Naturally, Large Scale is where it is easier to implement
 In an earlier post, Cougar I believe, had already mentioned Marklin's introduction of the phone/tablet interface at Nuremberg in early 2011. Why would the industry leader in our sport introduce this -> They are intensely studying the demand patterns of the age groups buying their products. (I know this. My colleagues worked on the current Marklin web site in German.)
 Touchscreens have entered the combat battlefield in the deserts today out of necessity and battlefield commanders insisting they be provisioned. See the General Dynamics implementation. Why ? Surely, there is a place for it in household garden railroading too. (See especially, the sunlight rendering issue addressal)
 IF 1,2,3 above are not on the confusing siding, then the post is suggesting starting with a simple 4 button, scalable, shareable, inheritable interface that any 10 year old can also use (including mine).

The question then is about costs. To a Club registering a new member, providing the latest layouts should be a matter of emailing the layout file to them or downloading it at the club sites like we do - for free. It also contains the turnout settings, available tracks.
The Touch interface has various look/feel options that can be changed on the fly. Some like wheels, some sliders...some RED big buttons that vibrate when pushed.
And so on...we just provide a dynamic adaptation since it is possible now.

A handheld controller costs at least $150+ today, does it not ? While it does give you a 2 line display your guest may not have even that. Yet they may have one of these communicators (iphone, android). First quarter 2011, Gartner reported 428 million phones sold in the first quarter with smartphones accounting for 26%. That's a little over 111 million phones in one quarter,* last year*. Purists may argue, so what anyway ?

Anyway, the post was intended to argue what could be the cheapest, simplest, stupidest, 4 button controller that one could pass on to a friend when they visited your layout. Hope this clarifies ? 

Cheers,
Victor


----------



## Brandon (Jul 6, 2011)

If/when you find that RailML lacks support for something you need will you either extend RailML's grammar or [re|mis]use part of the schema to make something like turning a smoke unit on or off or a scenery piece of that's outside of the RailML scope?

Are there any whitepapers or api references that I could look through to learn more? As you know I'm doing the rfid location to make my own autonomous railway and if I can build off and/or integrate what I'm doing into what you're doing that might save me time, if that's doesn't create some sort of problem with the overall project. I know you're doing a lot more ir and laser sensing rather than rfid so I'm curious how sensor, control, communication is being developed and how scalable it may be to other things.


----------



## VictorSpear (Oct 19, 2011)

One should start a post on the Messaging layer and leave the Human Interface layer schema (this post) right here to the simple look/feel side of things.. But to provide a brief, specific answer:

You are on the right track if you are looking at what today's prototype is manifesting but prefer to roll your own. So you should roll your own schema where needed. Why not ?


I'll take the liberty of posting technically again what is meant by this. 

Take a good look at the sample schema that defines the characteristics of trainid rse002 for real world loco BR186 in the 'samples' from RailML. The schema has shared publicly the Bombardier transportation key elements that my interface needs to determine what I'm dealing with: Electric, Braking effort steps, ..Speed steps. Simply replace this with the type of motive power for the exact model you are offering on your layout and whatever attributes are* known to you*. For example, the sound triggers now should trigger to the exact Braking effort in the BrakeEffort graduating tags in RS_tablesample.xml - now they are synchronized to the real world as opposed to a pre-recorded screech that suddenly appears and disappears because someone recorded something somewhere. If I am modeling the braking characteristic (with sound) of the Bombardier BR 186, I'm using the same data as the prototype that's in the no-argument public domain. QED.

Cheers
Victor


----------



## Brandon (Jul 6, 2011)

RailML thread: http://www.mylargescale.com/Community/Forums/tabid/56/aff/98/aft/123199/afv/topic/Default.aspx


----------



## lownote (Jan 3, 2008)

@import url(http://www.mylargescale.com/Provide...ad.ashx?type=style&file=SyntaxHighlighter.css);@import url(/providers/htmleditorproviders/cehtmleditorprovider/dnngeneral.css); Posted By VictorSpear on 03 Jan 2012 12:07 PM 
One should start a post on the Messaging layer and leave the Human Interface layer schema (this post) right here to the simple look/feel side of things.. But to provide a brief, specific answer:

You are on the right track if you are looking at what today's prototype is manifesting but prefer to roll your own. So you should roll your own schema where needed. Why not ?


I'll take the liberty of posting technically again what is meant by this. 

Take a good look at the sample schema that defines the characteristics of trainid rse002 for real world loco BR186 in the 'samples' from RailML. The schema has shared publicly the Bombardier transportation key elements that my interface needs to determine what I'm dealing with: Electric, Braking effort steps, ..Speed steps. Simply replace this with the type of motive power for the exact model you are offering on your layout and whatever attributes are* known to you*. For example, the sound triggers now should trigger to the exact Braking effort in the BrakeEffort graduating tags in RS_tablesample.xml - now they are synchronized to the real world as opposed to a pre-recorded screech that suddenly appears and disappears because someone recorded something somewhere. If I am modeling the braking characteristic (with sound) of the Bombardier BR 186, I'm using the same data as the prototype that's in the no-argument public domain. QED.

Cheers
Victor 

I have read this message multiple times and I have to say I have no idea what is even being discussed. It's a train control protocol? 

"Take a good look at the sample schema that defines the characteristics of trainid rse002 for real world loco BR186 in the 'samples' from RailML." 

Ok, I'd like to do that, I think.


----------



## VictorSpear (Oct 19, 2011)

Let's try an example:
Do you know how far your rental car from the airport will travel when you apply the brake at a certain pressure ? Do you know how much distance it travels before it comes to a full braking stop when you jam the brakes at 55 ? 

More often than not, we can sense this distance after getting used to our car. With heavy locomotives, this is a known and published value. There is no guess work. *There cannot be any guess work.* It must be known and declared based on the model's characteristics, type of braking mechanism, gradient, speed, ... Otherwise disasters will occur with certainty. The RailML.org site has examples for this in their samples for various trains in the Eurorail system. There can be no ambiguity or unknowns in an intermodal, multi-partner rail network carrying millions of passengers from country to country on a daily basis. Hence the table to define the loco characteristics. So we have a reference table with a known format so that other 'guest' trains in our model layout can be identified with certain characteristics. The important thing here - the format to exchange information is standardized. No ambiguity = no accidents.


----------



## VictorSpear (Oct 19, 2011)

In the meantime, on Dec 16th, 2011 the FAA has approved the use of the iPad inside the cockpit for AA on *all *in-flight operations (takeoff, landing, gate ops...) after receiving the 'commence hard' signal in June of last year. UA/Continental will distribute them to over 11,000 pilots....

I wonder what the reactions to this as a potential command station would be: See-through-and-touch - 2 fingers. Or this more recent ping from Sony shows it is around the corner ?


Just wondering.... my current train command stations have 2 LEDs and heat is wafting out from all sides....good for hand-warming, though







.


----------



## DKRickman (Mar 25, 2008)

Victor, 
I think I understand a little better. The purpose of this discussion is the human interface part of model railroad control, independent of any technical means of implementing the commands given. Right? 

Given that, I would submit that you are starting from the wrong point. It seems that you're starting with the assumption that a touch screen (and especially a touch screen ONLY) device is going to be readily available AND that it is the ideal tool for the job. To the first point, it may not be available. I do not have one, and I have no desire or intention to buy one. I am sure that I am in the minority, but not alone. To the second point, the use of touch screens in aircraft cockpits and battlefields is interesting, but not especially meaningful in this case. A touch screen is ideal for a situation in which the user needs to interact with the system in some way, both sending and receiving data. I generally do not need to receive date from my throttle, however. I want to send data, giving a command to go faster, slower, reverse, etc. I would also submit that the fact that Marklin is doing it does NOT mean that it is better, or even good. Ford (one of the largest car manufacturers int he world at the time) made the Edsel, which was a complete flop. Big companies make mistakes and have failed experiments as well. 

I would argue that a touch screen is not the appropriate device for a model railroad throttle, for much the same reason that it would not be the appropriate device to control the throttle and brake on a car. To use it, you MUST look at it, and that means you cannot be looking at other things that require attention. There is no tactile feedback, no realistic way of using it "blind". The same feature that makes it possible to have a knob, slider, or any other control scheme means that they are all equally impossible to use without looking. 

It's an interesting subject, and it might be desirable to find a way to use a less than perfect tool for the same of convenience, but I would suggest that your time might be better spent finding a way to make a simple, inexpensive and universal throttle that actually fits the application to the greatest degree possible.


----------



## VictorSpear (Oct 19, 2011)

Kenneth,

"The purpose of this discussion is the human interface part of model railroad control, independent of any technical means of implementing the commands given. Right?" - Bingo. Right on the nail head.


You may not be alone in that you do not need to receive any data from your throttle. That's the fire-and-forget method that doesn't work for some like me and a few others. What if your loco wasn't listening to your orders? 

Isn't there at least 5 seconds to look at your throttle when you don't have to look at your locos in the garden layout normally .... or does it demand constant riveting attention ?  


Point: Ford Made the Edsel. Counterpoint: They *learnt *from mistakes didn't they ? -> Ford = Still the only US auto company that has never filed for bankruptcy and was the least needy of the tax payer bailout, remember ? 


To some extent the argument is influenced by economics and supply/demand. Here's an interesting couple of charts telling us what the consumer thinks of companies that missed the consumer-demand boat and catchup is going to slow, hard, painful. 


1. June 26, 2008, 144.56 .....Jan 5, 2012, 15.05

2. Nov 26, 2007, 29.33 ..... Jan 5, 2012 5, 27

3. ...

4. ... 

(Above is adjusted for splits/dividends). 


Meanwhile, while keeping another eye on the 'prototype' world, can you take a look at these two items and the source/date of the report from where they are ?


* Fra.dot.gov 1* ( See page 13, then page 14 if you want to glance through)

* Fra.dot.gov 2 *


....Sometimes the trend is your best friend.



Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

Being forced to look at your throttle to do ANY control is unacceptable to EVERY person I know that runs trains at shows, for example. 

It's unacceptable to me, and I have a G scale and Z scale layout. I have a number of backlit touchscreen devices already, IOS, Android, WEBOS... none of them is preferable (to me) to my hand held throttle with buttons and knobs. 

I agree that making the initial assumption that this is a backlit (not very visible in sunlight) touchscreen device (no tactile feedback, and no way to find the stop, reverse or throttle by touch) is a mistake. 

Why not make a poll and see how people respond to the following: 

What is preferable to you to control your train? 

1 = touchscreen in color (limited visibility in full sun) 
2 = touchscreen in black and white (excellent visibility in full sun) 
3 = knob for speed and button for direction - all else touchscreen 
4 = knob and buttons for everything 

If you have the ability to seek other's opinions, people in the hobby, then I think you will find your basic assumption flawed. 

Greg


----------



## Brandon (Jul 6, 2011)

At shows the most used tactile button is Emergency Stop. For hand held devices I think there will always be a battle between touch screen and physical buttons. Being able to create virtual buttons that are unique for the exact situation (switch layouts, train functions that can be unique to different trains, and so on) will always be a huge desire as the model industry gets more technology. There will also be those who don't technology and prefer tactile buttons and knobs but if we were to ask this question 50 years ago people would probably want levers instead of knobs. 

The great news though is there will likely always be both for some time (you can still get levers for lionel transforms...) and I imagine when the day comes that touch screens can alter their physical feel and push out the surface to create physical buttons we'll see a huge decline in the number of plain touch screen and knob/button controls. 

The last thing I'd mention is cost. Touch screens/tablets are taking off because they can do so many different things across different areas that people will happily give up tactile feel for the other features they get. If I had to pick between a 128 function keypad with tactile buttons and a touch screen with no tactile buttons with 10,000 functions with the ability for 'improvements' to layout in the future.


----------



## DKRickman (Mar 25, 2008)

Victor,

First point, on the need or lack of need for two way communication. I think you misunderstood my point. If we are strictly discussing the human interface, and not the control protocol, then the point is that I do not need to receive data from the throttle in my hand. I need only to give it data in the form of a command - speed up, slow down, reverse direction, etc. The feedback comes from the actions performed by the locomotive in question.


Next, on taking time to look at the throttle. No, I cannot always look away from the train. For example, when trying to make a coupling, or to uncouple a locomotive, I need to focus my attention on the coupling in question and possibly (presumably, especially in the smaller scales) on some form of uncoupling tool. I need to be able to control the motion of the locomotive fairly carefully, but I cannot look at the throttle do do so. If for no other reason, that would stop me from buying any throttle which REQUIRES me to look at it in order to use it.


Ford/Marklin. Yes, Ford learned from the mistake. By the same logic, we could in a few years be discussing Marklin's abysmal failure at developing a touch screen throttle, and how they learned their lesson.


FRA touch screens. The examples you provided are railroad related, but not in any real sense relevant to model railroad control. They are both (based on a brief overview) systems designed to allow users to access and manipulate data. Most tellingly, you will notice in the example about locomotive touch screens, the illustration at the top VERY clearly shows a manual throttle, reverse, and brake handles. The ability to control the movement must not require that the engineer look away from what is going on outside.

Now, the last point, on using what is available. I concede that it is valid, if unfortunate. Having given the matter some thought, I may have a solution that would satisfy most of us. Let me try to describe it...


I start with the assumption that there are only two things which a user wants to do while NOT looking at the throttle - control the speed and direction. Everything else can be afforded a second or two to glance at the screen. The problem is that one cannot find a speed or direction control on a smooth screen without looking at it. The solution is to make the control a relative motion, not a location. In other words, moving my fingertip in a clockwise circle anywhere on the screen should make the engine go faster, and of course counterclockwise makes it go slower. Any linear reverse (left, right, left; up, down, up; etc.) should cause the engine to reverse direction. Furthermore, the control should allow me to place my thumb tip on the screen and without lifting it perform all the actions in sequence. It might also have a separate switching mode in which dragging my finger left makes the engine go left, stopping makes it stop, right goes right, etc. In other words, the motion (for the purposes of spotting, uncoupling, etc.) should directly mimic the motion of my finger.


I hope that makes sense. It's not quite as easy to program, I'm sure, but it's the only way I can imagine for a touch screen to be useful without some form of tactile feedback about where the controls are located.


----------



## Greg Elmassian (Jan 3, 2008)

Not sure I would make the same choice as in your last sentence, based on what I NEED to do to control my train. Again, I am responding about a hand-held wireless throttle. 

The number of things people want to do with a throttle, while "driving" a train is limited pretty much to speed, direction, lights and more recently sounds. Add in coupler control on the locos (would love to have it on every car too) and maybe animation of some aspects of the loco (although there's again a finite number of things people can animate reasonably). 

I keep trying to pull the "goals" back to what people want to do, and logical extensions. Comparing 128 functions (more than anyone has now) and 10,000 functions in a throttle is just not germane to current, and even 10 years from now interest or capability, again, in terms of a THROTTLE. 

Now, controlling an entire railroad from one point, maybe more stuff..., sure, you want a full blown computer, although making something complex on a touch screen only has been a dismal failure in the real world. Why? Because of fatigue by users. 

It's interesting that you state the most used tactile button in your experience is emergency stop, not the throttle speed or direction. That means trains are stopped more often than moving? Literally that would have to be true. 

I would like to visit the show where you use stop more often than go... there has to be a problem there, seriously. 

Think about it... no matter though, emergency stop is important, and needs to be found in an emergency... another strong vote for a button you can locate without looking. (Note, does not need to be tactile, you could set it up so that just throwing the phone at the floor would break the connection, and call for an emergency stop. (ha ha). 

Seriously, if you dedicated one end of a screen to something that would interpret clockwise as faster and counterclockwise to slower, you could do speed changes sight unseen. 

The problem I see is dedicated functions... maybe you do a double tap to reverse direction... triple to stop... 

You CAN come up with a limited number of functions that work sight unseen... 

Greg


----------



## VictorSpear (Oct 19, 2011)

Good points indeed. Time will tell. I do read the FRA summary documents very differently for the 2 person crew in the cab though.

*Times are a changin.*...( I couldn't resist).

Cheers,

Victor


----------



## VictorSpear (Oct 19, 2011)

Found a couple of off-watch hours to beam down some software stubs to test the QUICK tab yesterday, based on various intriguing suggestions from several modeling savants for a minimalistic option to control trains.

Had some issues with getting the interrupt handlers for Stop/Bell/Horn debounced correctly. Speed damper routine needs finer adjustment. Need to test more this weekend with rain forecasts galore.

Added the bell/horn at the same level as the Fwd/Rev layer. The kids fingers are too small to use just the thumb, but the adults were ok. Need to re-adjust thumb spacing with a selectable menu item perhaps.














(Vimeo does not appear to work at all after 6:00 PM Eastern and I complained loud and hard to the vimeo CSRs, but they appear to be wearing gunnery mufflers on their ears all the time)

Anyway the testing 'crew' managed to get a clip up here

http://vimeo.com/35374727
Cheers
Victor


----------



## DKRickman (Mar 25, 2008)

Victor, 
I have a few critiques, if I may be so bold. 

I would find the action of the direction function very frustrating. Specifically, the fact that setting a direction automatically starts the train moving at a pre-set speed in that direction would make switching frustrating, if not impossible. In addition, I noticed that the train starts off at the default speed and then slows and re-accelerates as you adjust the speed. Both of these problems could be resolved by not letting the train move based solely on the direction function. 

The video mentions using the vibrate feature when the stop button is pushed. Since the train stopping is visual feedback, I would not think that you would need tactile feedback of that as well. On the other hand, if you allow the direction to be changed without the train moving, it might make more sense to use vibraton as a confirmation that the direction command or conditon has been altered. 

Finally, it seems that the system has some degree of momentum built in. It might be a good idea to make that variable, or to eliminate it. Not everybody likes to run with momentum, and there is no single setting that is realistic for all conditions.


----------



## VictorSpear (Oct 19, 2011)

Very good observations. 

"_Both of these problems could be resolved by not letting the train move based solely on the direction function._" The test 'crew' ignored my RailML update tag for some settings and set the FWD/REV tag to_ auto at 6 mph_ so the kids would simply push one button or the other without having to stop and then raise the throttle ! I need to override this in a check-loop so they don't try the lazy approach 

"_some degree of momentum built in_" - added a speed ramp function to prevent the kids (and bigger kids) from simply raising the throttle from zero to 90 and back all the time...they have expressed a lot of irritation at this momentum feature too and tried to override it 

Cheers
Victor


----------



## VictorSpear (Oct 19, 2011)

I was wondering what sort of collision control mechanisms are being used in the model train world running DCC ? 

While working on the sound modules, we decided to go deeper into sound sensitive *reactions *where the loco blows the horn when it 'senses' an impediment on the track and automatically slows down to a user defined speed - and comes to a graceful stop around 12 inches from the obstacle. Extending it further we want to trigger sounds when approaching a crossing, or slow down when approaching a station or crossing. We decided the 'sound activator' location markers must be portable so that it could be moved around the layouts without digging magnets or reeds - with zero permanent wires under the track. This brought us into a form of sonar collision control that can be turned on and off from the handheld. 


(Most importantly the objective was to defeat the junior sappers who constantly set up impediments and road blocks on the tracks or in some cases try and get too close to the locos in an attempt to peek inside the running engine. One genius placed a soccer ball in front of the expensive loco to see what would happen...)

The current setting was - Slow down to 1/3 speed if an object is sighted within 36 inches line-of-sight on the track. Stop within 13 inches.
The sonar pinging with sound travelling at 1130 ft/second (29 microsecs/cm) requires us to set the ping round trip interrupts accurately but it finally produced some good results after a week of alignments. We want to compare this with light sensing so we replaced the pingers with the IR sensors to study the sensitivity. In terms of aesthetics and accuracy, and current draw at 25mA, IR wins. The reflection from the track if the interceptor slope is less than 15 degrees will cause strange behavior if mounted incorrectly. Will try and post a clip, but I think we have the sappers in for a surprise this weekend.








--- Sonar mounting









--- Infrared mounting









---InfraRed mounting. The bashed lens cap was from a prior experiment.



Cheers

Victor


----------



## TonyWalsham (Jan 2, 2008)

Would it not be simpler and cheaper to properly supervise the children??


----------



## rmcintir (Apr 24, 2009)

Infrared is tough with the ambient light outside. Automation is fun but I like actually running my trains, no disrespect as I love investigating the complexities of control. 

I've found the best way to control the children is with RC shock collars. They keep the dogs in the yard, why not the kids...


----------



## Brandon (Jul 6, 2011)

I believe this layout Victor is currently working on is inside so IR would be a great choice, especially if there's a vast difference over sonar (I didn't see a current amount listed for sonar but I'm curious what it was). As for the rules, kids don't follow the rules 100% and I think it's a rather creative way to experiment with technology more than anything else (which is the main reason for this layout I believe). It will be interesting to see how well the sensors can be hidden. For my automated layout I plan to have a 'test' (aka I don't care too much about) loco that will be send out before I run with a cleaning brush on the front and some 'clearance' markers like I saw used on a car for testing a tunnel for clearances and if it makes it all the way back I'll know the railroad is clear for other locos. However if victor comes up with a great way to do object detection this way easily I'd be interested in maybe trying it on the test loco so it doesn't smack into things if there is a problem. 

Victor, have you thought about using a camera to relay video back to a computer to do digital signal processing to look for objects on the track and/or horn/bell queues? 

Tomorrow I'm helping the local club out at a show again, aka reminding parents not let their kids reach over and try to touch the engines as they pass. At the last show a local TV cameraman almost sat his camera on the outside loop track to get a shot of the train on the inside track coming from the opposite direction. :O


----------



## VictorSpear (Oct 19, 2011)

Yeah supervising the juniors has it challenges if it has to be done constantly. Even more difficult from remote. Anyway, we claim 'victory' if we can get them out into the yard and thinking with their own heads while *away from* SpongeBob and the Xbox for 3 to 4 hours.

The sonar pingers have the following characteristics:

• Supply Voltage – 5 VDC
• Supply Current – 30 mA typ; 35 mA max
• Range – 2 cm to 3 m (0.8 in to 3.3 yrds)
• Input Trigger – positive TTL pulse, 2 uS min, 5 μs typ.
• Echo Pulse – positive TTL pulse, 115 uS to 18.5 ms
• Echo Hold-off – 750 μs from fall of Trigger pulse
• Burst Frequency – 40 kHz for 200 μs
• Burst Indicator LED shows sensor activity
• Delay before next measurement – 200 μs
• Size – 22 mm H x 46 mm W x 16 mm D (0.84 in x 1.8 in x 0.6 in)

I'm waiting for some ultrasonic Maxbotics versions, but meanwhile the crew uploaded a brief video here. Waiting for the outdoor results comparing Sonar to IR in direct sunlight. Still many more tests needed to validate Sharp's claims about ambient lighting with the new triangulation sensors. Let's see.


Cheers
Victor


----------



## VictorSpear (Oct 19, 2011)

Noticed that Vimeo video servers are still not scaling so it is hard to tell if the train is slowing down .... or the Vimeo is choking. They are still the 'underdog' so we prefer to support them and give the Tube some competition over their monopoly. 

Anyway the Tube version ....  is here


----------



## VictorSpear (Oct 19, 2011)

IR pinging test indoors with fair accuracy even with fuzzy objects near or on the track. The IR sensing/braking gradient is non-linear (hyperbolic) so had to use floating point processor calculations to calibrate and took some trial/error. Crew reported that the triangulation ranging IR sensor must be at least 4.2 inches above the track to avoid signal bounce back from the track itself. Sonar provided a more elliptical Line of Sight but IR provides a more precise - conical LOS. *http://www.youtube.com/watch?v=G-Yai3ObjX4&feature=youtu.be*

*

Animals/Kids avoidance testing*.....more testing needed but the Bowl has priority this weekend.


----------



## VictorSpear (Oct 19, 2011)

The IR tests ranging and detection tests were started in varying levels of sunlight from bright Sun at 11:00 am high through 2:00 PM. Had little or no issues with ambient sunlight. More tests continuing. 

Track conditions were grueling as the yard is also used for archery target practice sometimes. Borrowed a precision alignment method from some French colleagues and it helped a lot.









*Received a clip from the base crew.*


----------



## VictorSpear (Oct 19, 2011)

Progress was slow over the last two weeks while waiting for the custom sound processor board (Chinese holiday delay on pcb !) but it finally came. To support 18 sound input triggers and fire the triggers with just serial control on two pins without a lot of cluttered wiring, I need to redesign the board for better aesthetics.

To avoid guessing true velocity (by estimation or other sensing methods) the triggers fire directly from the shaft mounted rpm sensor output - it works well but only after getting the chuff sync calculations re-worked with smoothing. With the sensors (collision, rpm, track) and two more to come, I'm still at 4.5V with a 40mA draw on the sound processor but now can play over 1,500+ sounds (or Nessun Dorma at night when the prototype purists are not around) thanks to the 4gb microSD card.




























Added the Anti-Collision blanket button with default = ON. Any of the six trains that have the sensor now turn on and fire the sound trigger when sensing imminent collision and then slow down -to- full stop.

Haven't had time to set the stopping distance sensor range selector - where do I put it ? Against each train or blanket control the full fleet ? Hmmm...














Two feedback buttons added to provide Actual RPM and Actual Distance traversed.

More field trials next week when I return to base. Hope to get some clips going.


----------



## Greg Elmassian (Jan 3, 2008)

On the stopping distance, because different trains will have different stopping distances, you probably need individual control, but one "blanket" should be provided for ease of getting started/setup. 

I would not bother with RPM, really means nothing, SMPH is better, and you had to figure the "gear ratio" at least to do chuff sync/speed. 

I have android, will you have ICS versions available. 

Greg


----------



## VictorSpear (Oct 19, 2011)

Yes, the dist traversed reading could be calibrated to give SMPH additionally.

I'm waiting for a couple of Samsung Nexus trade-ins to come in to try the ICS...hopefully soon. 

Cheers, Vic


----------



## Brandon (Jul 6, 2011)

Victor, This might be slightly off topic but have you looked at either the Pololu usb motor controllers with or without feedback? I've wondered if one or both of these would provide any sort of help to know speed (although probably not as accurate as a motor rpm counter). The feedback one does provide voltage and current (I can't tell from their site of the non-feedback does as well) but the feedback controller from what I can tell requires a stepping motor or some other pot based or tachometer to track distance. If the non-feedback still provides voltage and current I wonder what you really get with the feedback model. 

On topic, how likely will your motor rpm be do-able for a wider variety of locomotive types? I can't imagine it to be too easy to work a motor rpm counter into an aristocraft or USA train motor block would it be?


----------



## VictorSpear (Oct 19, 2011)

I've looked at the Pololu Jrk series a while back. They are good designs with a small and neat form factor but since they only supported 1 motor channel at a higher per unit price than some others, I didn't procure any yet. I plan to test their current sensing metrics for comparison one of these days.

I'm mounting the rev sensor on a U25B diesel this weekend which should be interesting. As it stands now, I've mounted it under a trailing battery car because the wife keeps asking me why I need to keep ordering those empty box cars on ebay - so there's her answer.

Cheers,

Vic


----------



## Brandon (Jul 6, 2011)

Why would you need more than 1 channel for a locomotive? You're not driving say each motor in a U-25 independently are you? 

What are some other USB motor controllers at a lower price? I've hunted but the pololu were the cheapest I had found. Maybe you're not doing usb though, but I do have my Raspberry-Pi on order (I was up late through that whole ordering fiasco and should have mine in about a month). 

Too bad I already have enough box cars, that's a great idea for the wife...  I keep wondering if I can somehow expense any of my railroading costs (as I own a business that does content management for the home automation industry) but since what I'll be doing is OSS software I'm not sure there is a way that I could justify with my accountant.


----------



## Greg Elmassian (Jan 3, 2008)

If your processor is fast enough, running back emf for 2 motors separately greatly simplifies things and would also enhance performance and pulling power (my opinion). 

So, having 2 separate motor controllers sounds like a good idea to me. 

Greg


----------



## VictorSpear (Oct 19, 2011)

More for the same price but primarily FA/FB reasons...we have a few ALCOs lying around with different motor blocks...some new with bearings, some 12+ years old that shudder like banshees at different speeds when consisted so fine grain adjusting is possible with dual-channel independent drivers (true consist). Haven't been specifically researching USB only motor controllers. Any reason ? You could hack-rig a USB FTDI to anything if you absolutely need it.

Cheers
Vic


----------



## VictorSpear (Oct 19, 2011)

Finally we got the SMPH feedback functions working and upgraded the "Quick" to also include the Location Marker. Have to review the calculations.










The location marker records every tee_id during calibration (tie) now and displays the precise track location of the loco on the feedback location marker at the bottom. Need to get the beacons to reflect switches and siding movement.













Fitted a custom sled to house the controller. SD card slot is easier to reach for the RailML format updates.


Added Rue's whistle to sound library - as the junior modelers insisted that it just must be in there (Hunger games fever). 


Configured the mesh landscape protocol after more than 2 weeks of frustrating packet addressing issues that were solved by another RF teammate. 
Now extended the mesh signals to 900 meters (2970 ft) at sea. Actual testing on land should prove interesting.

Android interface is moving forward..some issues with ICS need to be resolved.

Victor.


----------



## Brandon (Jul 6, 2011)

Victor, could you explain a little about what motor controller you're using and why? Is it taking pwm for input? What type of overload protection and bemf sensing does it support? I'm still debating on a Pololu but I've been stalled on ordering since my r-pi won't ship until may and I'm wondering if your hardware choice might work (potentially better) than what I was considering.


----------



## VictorSpear (Oct 19, 2011)

The Pololu range of drivers is good and I plan to order a few for eval.
I'm currently testing Sabertooth 2x5 regeneratives (dynamic battery charging on deceleration). It controls two brushed DC motors with peak currents of 10 A, 5A continuous with thermal, over current and current limiting protection and is pretty safe with Lion/LiPoly packs due to the built in cutoffs 

Operates at 32Khz ultrasonic and supports packetized serial for consisting. Took it out of a combat class robot. One nice feature is the exponential response curve at very low speeds. For sensing look for circuits that supports the TI INA 169 which I'm using.










Cheers,
Victor


----------



## Cougar Rock Rail (Jan 2, 2008)

dynamic battery charging on deceleration

You're out of control Victor!









Keith


----------



## Greg Elmassian (Jan 3, 2008)

Not bad, I wanted to see the underside, looks like the output fets are there with an aluminum cover

$60 is a good price I guess, but we can pay $60 for an entire DCC decoder.










Very cool idea for battery powered locos, the regenerative braking! 



Regards, Greg


----------



## Brandon (Jul 6, 2011)

Does sabertooth controller offer anything that Pololu ones don't besides regenerative power? Either the pololu feedback or none feedback? 

The pololu are less expensive and support a higher voltage. An SD-45 loves 18V-20V and the sabertooth is max 4s lipo (15v). 

Maybe the sabertooth has better stall circuitry than the pololu or something?


----------



## VictorSpear (Oct 19, 2011)

Yes these are little on the pricey side... The absolute input V on the Sabertooth 2x5 is 18V nominal/20V max (see documentation). You could also look at the SyRen 10 which is very similar and has 24V nominal/30V max input - but cheaper at $49 . The Pololu built-in current sense ratings are 140mV/A. Is that accurate enough for you ?


Victor


----------



## Brandon (Jul 6, 2011)

I have no clue what is accurate enough or not yet.  If I have an rev counter then I wouldn't need to know current use at all (or at least it wouldn't be needed except for a non-critical feature) 

Victor, you don't know if the non feedback pololu model also has limited current sensing do you? I wouldn't imagine it did but the docs somewhat sound like it may have some. I still can't really tell what the difference is between the two Pololu controllers. 

Also does the sabertooth have the ability to set a cutoff voltage? And if so is it can it be set to a 5s lipo voltage or could it be limited to 4s and smaller packs?


----------



## VictorSpear (Oct 19, 2011)

The Pololu motor controllers have the position/freq/tach feedback options depending on the specific model (Jrk ..Claw) but the motor drivers do not. Most of the drivers do have a basic current sensing option.
The Syren 10 has 2s to 6s LIon/LIpo. Cutoff voltage is pre-set at 3.0V per cell to prevent cell damage - (it detects the number of lithium cells in series on startup.) 









Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

@Greg,

Heat shield removed for the Sabertooth 2x5, showing

20V Dual N-Channel Logic Level PowerTrench MOSFET - By Fairchild - FDS6911.










Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

Thanks Victor, would assume they don't make much heat, did the "shield" have any kind of thermal gasket between it and the FETs? 

At high amps they might want a bit of heat sinking... although it looks like they met the 1/2 square inch of copper for the 78 degrees C per watt spec already. 

Greg


----------



## VictorSpear (Oct 19, 2011)

My colleague radioed back from base: " No gasket. Looks like it was bonded with a thermal adhesive, probably Loctite 384 and flooded with high viscosity thermal grease" Will put a temp sensor on it and try and do some overload testing next week.


Victor.


----------



## VictorSpear (Oct 19, 2011)

Touch Cab's recent update. 


I thought there would be more features in TC 1.7 but it looks like the upgrade focus is on more accessory controls with the standard Lenz/DCC.


----------



## Brandon (Jul 6, 2011)

Victor: How are things going? Also I've been wondering how you're controlling the Saber tooths, pwm, voltage range? Also curious how you're getting feedback for knowing speed, is it purely a tach on the trialing car? My r-pi will be here within a month so I'm just trying to decide on which speed controller to get... :-/


----------



## Greg Elmassian (Jan 3, 2008)

Nice, but why use touchcab when it only supports the iphone and Lenz, ESU and Marklin only? 

There are 2 free programs to suit Android and iPhone (free) which connect to JMRI (free) which connects to tons of different DCC systems, expecially ones made in the US? 

Greg


----------



## VictorSpear (Oct 19, 2011)

Price at $7.99 is ok for me but I don't understand their rationale either. Why spend more than 3 years on designing a touch interface that supports just 3 systems today and is so Lenz Expressnet centric - and without Android support ?


----------



## VictorSpear (Oct 19, 2011)

Brandon,

I've been using various devices for rpm/speed sensing from a quad encoder to a simple photo-interrupter. Each has its own merits. Have you worked out the GPIO and control logic code for the R-pi already ? Haven't found good ref/spec doc links yet.

Got stuck in some pressing projects last week but with the Saber 2x5, I managed to find a small enough enclosure and fit it inside the diesel block of an FA-1. Fits snugly and venting is now easy. Found very smooth characteristics at slow speed using the exponential mode. 





























--------
By calibrating the track layout once, I added the station/siding coordinates and am able to feedback alert the approaching marker on the handheld 











e.g. NEXT STOP: Penn Station, NY 


Set up the sound matrix tab to select different sounds/volumes for different loco models. WIP...










Cheers,
Victor


----------



## Brandon (Jul 6, 2011)

I don't have my r-pi yet, I guess only 800 have shipped and those were all UK based. Word is 2k units are shipping in the next week or two, I'm hoping mine is one of those units but they said those were 12:01am buys and it was about 6:00am before the site came back online and I got my order in. 

I agree, there's a lack of control logic info posted so far but being gpio pins there's not much to them. 

The slow speed is good on the saber is good news. I'm still debating on the pololu 18v7a. Half the cost of the saber and has usb input which gives the ability to read some stats back, just different pro's and con's of each. 

How are you attaching the quad encoder and photo interrupter to a u25? I'm moving away from the idea of a trailing car for electronics on the sd-45's and maybe the u-25's so I'm trying to figure out how to run everything from the loco's which makes attaching these on the motor block a little tricky.


----------



## VictorSpear (Oct 19, 2011)

In G-scale there is plenty of space to do almost anything inside the engine, but I prefer the 'intelliCar' hookup and its versatility....instead of hauling empty cars all over the place - just MHO. 


Mounting and aligning the photo-interrupter was straightforward beneath the truck of the intelliCar, but for the quad encoder we extended the shaft at the worm end of the Aristo motor block and mounted it on. The extender should be a precise fit to allow the encoder's collet to snap right on.



















Cheers,


Victor


----------



## Brandon (Jul 6, 2011)

Which photo-interrupter are you using, what is it detecting (ties, segmented disk) and what other hardware or software is counting? 

Have you also considered an optoelectronic sensor, possibly a mouse with a different lens that can focus at 1cm-2cm rather than a few mm to detect movement? 

I put my purchase through for the r-pi this morning, strange though since I had already put in an order I thought but maybe all those orders were reset, that or a second unit is on its way... Either way I should now have a r-pi by the middle of the month. 

I also ordered a 18v7 simple pololu speed controllery so I'll be able to start testing how useful it really is.


----------



## VictorSpear (Oct 19, 2011)

I use axle mounted photo-interrupters in the 3mm to 5mm range that can handle harsh outdoor/wet conditions. The o-e sensors can be expensive.

Considering the lead time on the r-pi, did you order just one sample ? A colleague of mine in Europe just 'bricked' his r-pi by accident with incorrect GPIO voltage addressing within 3 hours of unboxing. 


Cheers
Victor


----------



## Brandon (Jul 6, 2011)

Optoelectronic sensors do seem expensive, I keep waiting to hear you've found a cheap way with laser mice and new lenses to focus a few cm out.  

I think I only have one on order, but I think my CC was charged back on release night and when I 'finalized' an order the other week it was charged that time for sure, so maybe there's two on the way?... I've heard the gpio's are fragile, the 3v3 is a direct line to the r-pi's core. On my ARail thread I posted my 'schematic' for my wiring plans. I'm expecting to fry a r-pi at some point, but for the first few weeks I'll just be doing motor control and rfid, nothing risky, no gpio probably, so hopefully if/when the day comes the boards aren't as back ordered. Word is 75k boards will be ready by end of June. 

BTW, the 'schematic' is ugly, I'm no EE and a week ago I only knew transistors acted as switches so at some point I'll probably need input on how much was left out and what protection is needed. In the end, I'd like to have a schematic people can download that has the pin lineups for aristo's DCC plug, a 2803 chip for toggling lights and smoke, some circuits for ditch and mars lights, and a header that can connect to a r-pi or arduino so people can drop a board in and have custom control of the locos.


----------



## VictorSpear (Oct 19, 2011)

At the test tracks....simple night operations testing with 2 stations mapped and attempting to identify approaching stations with just the *handheld controller* (clip) and the on-board locator sending feedback, all lights turned off.


Cheers, 
Victor


----------



## Brandon (Jul 6, 2011)

Is this purely by distance traveled that it knows the stations?


----------



## VictorSpear (Oct 19, 2011)

The distance traversed is a resultant calculation triggered by the Locator counter (lower left reading) and not used to determine the station location. That would be error prone when you have different routes traversed with reversals, curves, sidings, and wheel slip over time that give you different distance readings from point A to point B. The more important metric being the tie_id (tee) that is obtained from the locator continuously. This is referenced with the embedded db that has every tie coordinate with waypoint heading checks to retrieve the current location using a 2 step determine-and-verify process.

If the loco with IntelliCar wheel base X mm, is now reaching position 979, having started at position 2 (ranging) and compass at NE 7 deg (bearings, after passing way point headings P, Q ...), then it is arriving at Station X. 


Although we do not use GPS due to its small distance inaccuracy errors we need to at least be in compliance with the prototype's V-PTC final report *where no track based components are allowed to determine location*. This includes magnets, reeds or rfid tags embedded in tracks 











Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

While waiting for some mini-acutators to arrive for wireless remote switching, added the direction heading and turnout indicator feedback LEDs. 

Operation: As the loco approaches the 'next' turnout, the current position of the thrown switch on the approaching turnout is shown. Toggling it once will throw the switch to the next logical position for Left or Right throws or back to Normal position (with center green indicating fully charged condition of battery).
The plan is to have all switches completely wireless and actuated by solar charged LiPos outdoors.

Cheers
Victor


----------



## Greg Elmassian (Jan 3, 2008)

You should at least use the track as a power bus. Putting batteries and chargers and big ugly solar cells at each turnout is not going to fly, too expensive. 

Greg


----------



## VictorSpear (Oct 19, 2011)

Yes I was thinking along those lines....until I found a neat little charge panel that could fit on the side of a track side hut. Indeed the 6"x6" panel will still diminish the layout aesthetics, no doubt.








Courtesy: From AppliedImaginationinc.com web site

http://ep.yimg.com/ca/I/sundancesolar_2211_20986369









Courtesy: Sundance Solar

Cheers,
Vic


----------



## Greg Elmassian (Jan 3, 2008)

It just takes a lot of space to get enough energy to charge the size of batteries you will need to run the switch motor is the problem, as well as the cost for the chargers and batteries, and the recurring cost of replacing batteries, not to mention how to handle freezing temperatures or arizona heat. 

You normally have metal rails, so use the rails as a power bus, you can tolerate voltage drops, etc. 

Greg


----------



## VictorSpear (Oct 19, 2011)

Began work on expanding the Ipad interface to add more layout control objects compared to the ipod/iphone layout. 
















Found a colleague in Japan to work on miniaturizing the wireless switch controller to actuate the Piko 'weather-proof' switch machine wirelessly.
















Working on the solar charge circuit next two weeks. Will test and record the minimum force (Nm) required to 'switch' with the overpowered motor which throws fine at 9V - 12V.

Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

A manufacturing colleague of mine who recently got into modeling but specializes in medical robotics asked for a layout with the wireless/solar option for an outdoors kids hospital play area. I convinced him to include the bus powered option. Work in progress:


----------



## VictorSpear (Oct 19, 2011)

I've been working on autonomous sensor based location, guidance and collision avoidance in a non-GPS model for some time now with varying results while friends at MIT and the Office of Naval Research/Army Research Office (Micro Autonomous research project) recently presented their research algorithms on gps-denied navigation.

Of particular interest - the entire simplicity of the autonomous concept consisting of just Laser range finder, Inertial Measurement Unit (IMU) and Intel Atom MPU + onboard camera. What does this have to do with model trains ? _Just use thy imagination_ and watch the video again !





Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Completed the IntelliCar's Powerpath circuits for dynamically switched constant track+battery power where dirty old track conditions prevail. Our track outdoor has not been cleaned for 1.5 years and the indoor track is even worse. The IntelliCar also sends feedback of the precise tee_id where dirty track conditions exist - so the highly paid 'swabs' can clean more efficiently in areas where its needed (and when they eventually get down to it.)

















The solar panels for the outdoor switch motor battery maintainer finally arrived. Each wireless charging hut can operate up to 4 switch motors over I2C in sequential pulses.









Weatherproofing in progress - the great outdoors beckons. Now using mini-SLAs with large temperature extremes.










Outdoor field tests in 2 weeks.

Cheers
Victor


----------



## VictorSpear (Oct 19, 2011)

Updated the switch control interface to sweep and obtain the status of all switches in the layout. Clicking a switch toggle now refreshes the feedback status with thrown indicators (L = Left, II = Normal, R=Right)

The solar switching hut circuitry upgraded to a fully solid state switch controller (no relays) and will now handle both solenoidal and slow motion turnouts. Switch will activate for n seconds and then slew down turnout motor voltage to 0 with only the radio listening in microamp sleep/wake cycle consumption. Have left one switch on outdoors for about nine days now. Continuing to refine the charging circuit to send out a charge state if requested by user.










.


----------



## VictorSpear (Oct 19, 2011)

A facilities management colleague requested a few layouts for a building lobby display during the forthcoming holiday season and had another friend narrate some IntelliCar version 2.0 sensing features.


----------



## Greg Elmassian (Jan 3, 2008)

I have a couple of suggestions. 

(First that low speed control is not that astounding. I have Aristo locos that will take minutes to cross one tie, you cannot even see the motion unless you stare) 

Your motor slider should be a non-linear scale, or adaptive with ballistic control. 

That will allow the human finger to have greater control. 

Also, I assume you have momentum capability? That will also allow slower starts and stops. 

Regards, Greg


----------



## VictorSpear (Oct 19, 2011)

The suggestion for 'non-linear' speed control at very slow speeds is excellent. I'd like to set an auto invoke of that feature where speeds between 0.75 to 1.25 smph are desired but turn it off at higher speeds. 

For starters, we do allow the user to set the threshold 'momentum' desired with the inertial slider:










While testing, I tend to use a self imposed standard of a weighted consist of 9 freight cars + intelliCar with battery + Dash 9 with a new Aristo motor + smoke+lights on etc.. We try to avoid the inertial jerk while starting, and transforming to a smooth feedback sensitive ramp. (Most of the examples I've seen do not test with a loaded consist - so just the loco by itself at very low speeds, normally displays a smooth transition of course but can begin to chatter and jerk when loaded or traversing a grade or curve at very low speed.)

I'd be keen on implementing a Reference Adaptive Control integrated with phase-correct PWM and a 16 bit timer as opposed to a fixed PID or pure ballistic approach.

Cheers
Victor


----------



## VictorSpear (Oct 19, 2011)

Did some testing this weekend and a colleague assisted remotely in testing some turnout control protocols with the solar charged/controller left on continuously for a few days.



Cheers
Victor


----------



## VictorSpear (Oct 19, 2011)

Working on integrating miniature bi-directional stepper motors with the wireless interface for hands-free box car uncoupling. A slow motion control is preferred instead of the single shot solenoids or servos. Objective here is to control both fore and aft couplers of different brands (Kadee, Aristo, LGB...) with a single micro linear stepper in each car or loco.

The rolling stock with couplers now have their reporting numbers pre-entered in the database with unique id constraints so that a couple/decouple operation does not affect more than one car at a time. No limit on the number of cars that can be remotely uncoupled. More importantly, we want the feedback status of the coupling operation with reporting number and coupler position returned to the handheld control. I would use an Alphanumeric 4 character code for asset identification (e.g. F219, A002,...) but still mapped to the long AAR reporting number in the DB. It's just easier to enter smaller numbers on a touch screen to identify the target car.


Cheers
Victor


----------



## Greg Elmassian (Jan 3, 2008)

So are you going to count steps to set the throw? 

Will you have a stall indication for "safety"? 

Greg


----------



## VictorSpear (Oct 19, 2011)

Yes the stepper has a 1.8 degree step @200 steps for 1 revolution (1.8 x 200=360 deg). I'm able to adjust speed of step and traversed length from center to fwd/bwd. I'm leaving the linear traversal controllable from the touch slider so the user can wirelessly control the open/close of the coupler jaw visually although a default auto mode would just be easier to set and forget. 

The sample drivers I have now only offer basic current limiting, over current cutoff and thermal protection (Allegro A4988) but I need to look at the L9942 with built in programmable stall detection for a reasonable price. With my target BOM of under $20 excluding the coupler, the range of built-in stall guards are very limited.

Cheers
Victor


----------



## Greg Elmassian (Jan 3, 2008)

Yeah, cost becomes an issue. But just remotely eyeballing when the coupler is open (which is what I glean from 3rd sentence) is most likely to overtravel and damage. You would have to be looking carefully and be right there. You might also have some overshoot, mostly the human releasing the control in time and a few step commands left in buffers, or the communications pipeline. 

The stall detection is the way to go I believe. 

Greg


----------



## VictorSpear (Oct 19, 2011)

My test team's next assignment, scheduled for installation at a large layout before Christmas, is to configure the WTANs (Wireless Train Area Network) for the uncoupling tests on individual car within the main WRAN network. Cars are added/removed in the WTAN consists wirelessly if they are a member of the WRAN.










Updated the Mobile interface to select cars with the slider instead of punching in codes. 











Still working on those Stepper motor settings.

Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Experimenting with different torque values and mount positions - the Kadee's need very little to pry the coupler jaw open. The micro-steppers arrived without any documentation (torque-speed *curves*) as usual. Makes the experiment an intriguing guessopoly as to final outcomes.









The 10 mm dia. one on the right has a small plastic 'slip-clutch' to allow over-torque conditions. Need to verify if it works as claimed.











Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Finished up the board design for the wireless coupler/lighting control module of the WTAN. Boards should be here in 2.5 weeks. Will test the ipod/ipad interface with small 2.5 g servos in different cars in the interim. The objective is to do a little more than visual coupling/decoupling by instructing the loco to perform an automated operation on a specific car by moving it to a precise location # on the layout and then signaling back when done. The interface simply selects ( loco_id, car_id, location_id) and transmits request into the network.


Started work on meshed wireless signaling and found some prototype color-light signals to fabricate. I'm puzzled why something with 3 LEDs and a pole would cost $30 on average in today's market. Wondering aloud if there is anything out there that is low-cost digital printed or laser cut for final assembly ?




















Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

While waiting for supplies/boards to surface, began testing some coupler operations in manual/auto modes using some micro-servos instead. Still looking for decent coupling/decoupling sound bites.


----------



## VictorSpear (Oct 19, 2011)

Ok, found the general scale market offerings ridiculously overpriced, so decided to get several 3-D printed versions of this Shapeways design in 1:29 scale ... working with the author to use some old diagrams for the Chesapeake & Ohio signals to make a simple modular 'hybrid' that will allow the multi-aspect wireless signaling. The 'model' as usual, precedes the Alstom 'prototype' in this regard









I'd like to get the BOM down to between $7 to $8 per mast, LEDs included thru bulk pricing.









The Alstoms:


----------



## VictorSpear (Oct 19, 2011)

The rolling stock control boards (Agent Module of WTAN) finally arrived. Scheduled for testing is wireless range and control of couplers, lights and digital signboards for individual passenger cars. 

For wireless lighting control in passenger cars, I took it a few steps further in the Use Case and elevated the design to control each of the six overhead lights in any car in terms of 
a. Color
b. Intensity
c. Individual control of each light and digital sign board remotely from the smartphone.

Item b gives me a way to keep the rear restroom lights a different color from the car's main cabin lights (and dim them for privacy when needed or turn them off to satisfy the green-energy purists). Purely an idiosyncratic feature - but fun to be able to control the intensity of lights at a siding differently from the mainline.


----------



## VictorSpear (Oct 19, 2011)

Using a 'cartridge' type of housing to protect and mount the module and servos inside the cars with a guidance sleeve for the control cable between the servo (or stepper) and couplers.









.


----------



## Michael W (Oct 10, 2012)

You are making great progress there victor, when can i expect to see your system on the shelf? 
) 
But on a bit more serious note this looks really promising, I was thinking to look into Arduino boards using wireless usb and track power... However you are lightyears ahead with your project... 
Keep up the good work this is really inspirational 
Kind regards michael


----------



## VictorSpear (Oct 19, 2011)

Yes the boards are performing well and the fine-grained lighting control inside the passenger cars is done. I'm able to turn off the bathroom lights from remote, trim the first class lights dim-blue and leave the coach class lights in yellow. In terms of coupler control the Aristo couplers are a challenge - they have a higher spring force than needed (hooke's constant). But I think I've found a way to avoid that ungainly banging of cars to enforce Aristo style coupling with a weaker spring replacement (still testing those coarse action couplers). Never a problem with the Kadees of course.

The shelf railway is always on  but I hope to send the stuff down to my colleague who can test it outdoors and get some video at night. 

Cheers,
Victor


----------



## Michael W (Oct 10, 2012)

I am happy to test it for you......


----------



## VictorSpear (Oct 19, 2011)

Updated the Lighting+Aux control UI to handle the wireless control of lights/couplers/other assets 










ID/LOC is used to select specific nodes (e.g. The Asset selector/Device selector has chosen Car #006 with lamp #002 to be set to a particular RGB number).


----------



## VictorSpear (Oct 19, 2011)

Now that Warren's railway (BNSF) will start (resume) aggressive testing of gas powered locos with towed LNG tank cars like the CN experiments below, the prototype will be towing fuel instead of carrying fuel. Ok then. So batteries can be towed in our model tank cars along with all the other electronics and never too far ahead of the prototype







. 










Article: http://thekneeslider.com/locomotives-may-shake-up-the-transportation-fuels-market/


Now all we need is a 'rechargeable' tank car with the sides that can be screwed open/close to house the solid fuel we use (batteries). It shouldn't be too long before the tank car is made an integral part of the loco itself eh EMD ? Meanwhile I just spent all winter miniaturizing everything to fit inside the locos and testing relatively 'safer' LifePO4s with the safety circuitry for running in hybrid mode (dynamic track/battery power).























Cheers,
Victor


----------



## Brandon (Jul 6, 2011)

Nice... Specs?


----------



## VictorSpear (Oct 19, 2011)

Just the LiFePO4 battery pack itself - Available as a custom order from Batteryspace.com


*Voltage* Voltage: 19.2 V (working) 21.9 V (peak) 15.0V ( cut-off) * Capacity* 3.3 Ah (63.4Wh) * Cycle life * >1000 cycles (80% of initial capacity @ 0.2C rate, IEC Standard) * Protection* 
[/b] [*]Included PCB-LFP19V7A for protection 
[/b] [*] Must use a 19.2V (6 Cells) LFP charger to recharge this pack
[/b][/list] * Prewired* [*]Charge / Discharge terminal: 6.0" long 24 AWG open end wire[/list] * Charging rate* 1.0 A up to 2A Max (limited by battery)  * Max. Discharge Rate* [*]*7** Amp ( continuous ) * [/list] *Dimensions (LxWxH)* 106mm(4.2") x 75mm(2.9") x 84mm(3.3")

* Weight* 640 grams (1.0lbs 6.6Oz)


----------



## VictorSpear (Oct 19, 2011)

For some reason the picture of the LNG tankered prototype disappeared, then re-appeared. Re-posting with link to article.


----------



## VictorSpear (Oct 19, 2011)

My colleague who wants to introduce a custom line and is testing some of the concepts here asked for an upgrade to the touch interface so that trains could be run in the lobby of one of the building facilities he manages.










@MichaelW : I'm working on FCC compliance (Part 15) tests for the Mobile Command & Control Modules and the modules are being tested by a few colleagues in the US, Germany and Japan. May take some time here but we have the Command Module done. The Control and Agent Modules are next.


----------



## Michael W (Oct 10, 2012)

Great article about the gas powered diesel, over here a lot of buses got converted quite successfully to gas.... 
Anyhow keep up the good work! 
Kind regards michael


----------



## VictorSpear (Oct 19, 2011)

Added real-time guages for RPM and SMPH feedback based on user-settable driver wheel diameter in the Rail-ML database.

While a single handheld controller can control any number of locos, switches, lights or other assets (no channel limit restrictions) we have introduced the ability to have simultaneous Command and Control for a single loco from multiple handhelds while broadcasting real-time feedback simultaneously to all authenticated handhelds. (Unlimited handhelds and roles, unlimited locos). Anyone with a smartphone (controller) can log into the network and control assets based on pre-defined roles (Chief Engineer, Maintenance Crew, Inspector, Guest, ......Wife, Daughter, Pesky Neighbor's son...)


Upgraded the 'Quick' interface to have both color (indoor) or B&W options (outdoor) to take advantage of new retina displays and e-Ink (KindleFire).















Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

All components of the Mobile Command & Control Digital Railway System being configured for a robotics supplier for FCC testing in their lab for building automation products. 


Command Station, Agent Module, Wifi n/g Router, Ipod Controller









Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Started work on some intriguing Use Cases from a University colleague for *LPVS *(non-GPS) for Automated Train Control Operations in large layouts using 'Dynamic Virtual Blocks' (no wiring). 

Handheld:
a. Establish Origin, Destination, Intermediate Stops and Wait Times (beyond simple back-forth-stop trolleying)


Locomotive On-Board Inference:
b. Broadcast Intent, Check Constraints, Turnouts, Signals, Impediments and Occupancy, Right-of-Way
c. Optimize Route, Speed, Pathways - within Constraints 

d. Broadcast Location, Route Intention and request point-to-point Right-of-Way

Command Station:
a. Allow/Reject Traversal
b. Lock/Release Right-of-Way










Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

The basis for the Use Case drivers for our LPVS modeling stems from the Congressional Research Report by John Fritelli and Jeffrey Peters and summarized below:


Positive Train Control (PTC): Overview and Policy Issues 

Congressional Research Service 
Summary 
The Rail Safety Improvement Act of 2008 (RSIA
08) requires implementation of positive train 
control (PTC) on railroads which carry passengers or have high-volume freight traffic with toxic- 
or poisonous-by-inhalation hazardous materials. 
PTC is a communications and signaling systemthat has been identified by the National Transportation Safety Board (NTSB) as a technology 
capable of preventing accidents caused by train operator or dispatcher error. *PTC is expected to *
*reduce the number of accidents due to excessive speed, conflicting train movements, and engineer *
*failure to obey wayside signals*. It would not prevent incidents due to trespassing on railroads’ 
right-of-way or at highway-rail grade crossings,where the vast majority of rail-related fatalities 
occur. 
Under RSIA08, PTC is required on about 60,000 miles of railroad track by December 31, 2015. 
Many railroad companies are uncertain of their ability to fully implement PTC by this deadline. 
The Federal Railroad Administration (FRA) estimates full PTC implementation will cost 
approximately* $14 billion.* Although the larger freight railroads are well along in planning for 
PTC, some smaller railroads and commuter lines have not yet identified sources of funding for 
implementation. 
*PTC uses signals and sensors along the track to communicate train location, speed restrictions, *
*and moving authority. If the locomotive is violating a speed restriction or moving authority, on-*
*board equipment will automatically slow or stop the train. A more expansive version of PTC, *
*called communications-based train control (CBTC), would bring additional safety benefits plus *
*business benefits for railroad operators, such as increased capacity and reduced fuel consumption. *
However, CBTC is not currently being installed by any U.S. railroad, due to the additional cost 
and to uncertainty about implementation of PTC before the *2015 deadline*


----------



## VictorSpear (Oct 19, 2011)

Continuing with the Positive Train Control (PTC) aspect with signaling determinants, I allow the railway operations manager (layout owner) to set the movement authority on virtual blocks, speed constraints, braking curves....and directly control the signals. Attempting to run the loco by ignoring the determinants, would simply override the handhelds and bring the loco to a halt or slow down to the restricted speed, enforcing the fore and aft safety cushion of the consist. 












This is challenging....as can be seen from some interesting clips that have influenced this PTC derivative:


----------



## Greg Elmassian (Jan 3, 2008)

Victor, I heard there is now a brand name and a web site for the product/project... can you post it here please?

Thanks, Greg


----------



## VictorSpear (Oct 19, 2011)

@Greg: Some of my robotics buddies, VJ, Thomas and Andrea have been working over the last two years on their building facilities with robotics venture with some Universities and introduced a 'model railway line' for their automation project based on some of these concepts. Unfortunately I don't have much access to land based layouts to play with trains so I've relied on them for feedback but it seems they have made a lot of progress in adopting some of the designs. They also introduced their first lineup at the NGRC in Ohio this month (although VJ and Thomas spent more time at the bar instead and on the slides at the water park next door) I will try and get the updates on the site/project but some of this was presented at this gallery about a year ago.

The gallery is maintained by Bob Faludi of New York University's ITP http://gallery.digi.com/

Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

A recent addition to our Digi (Faludi gallery)


----------



## Treeman (Jan 6, 2008)

I had a chance to spend a short time with VJ in Cincinnati at the convention. I connected to his router with my I Phone and was controlling his train in a very few minutes. I was astounded, I admit I am not a real technical guy. But it was very easy to connect and take control. I can see the average kid really taking to the Phone control. I also understand Greg's concept of feeling the control knob or button. I would find the possibilities of automation very interesting, while others want manual operation.


----------



## VictorSpear (Oct 19, 2011)

That's right Mike, connecting to the railway layout should be a 45 seconds process as there is no PC/Laptop computer needed or wires to hook up nor is there any App to download from the Apple or Android stores with the Turret-Bahn implementation.

With the ios 7 support for game controllers now available, we've been waiting for this Kickstarter project to get out of beta and adapt it for those needing some core tactile feedback buttons:


----------



## Treeman (Jan 6, 2008)

Can those extra buttons be set up to run trains via your router?


----------



## VictorSpear (Oct 19, 2011)

Yes, via the wireless Command Station/Router. Apple has exposed the Game Controls API to the community in IOS7 due in Autumn.


Cheers
Victor


----------



## Treeman (Jan 6, 2008)

That would seem to be a great advantage. Interested to hear other opinions.


----------



## VictorSpear (Oct 19, 2011)

Received some of the modules being integrated into the Turret-Bahn MCC.
































The command gondola above allows the gondola cover to be snapped on and can run off battery or regular AC power, enabling it to be located anywhere around the layout. 








The Control Module TB-DRS-AM-003 version has been designed for pluggable support of different radios from several manufacturers including Digi and Synapse. 
Input voltage range 7V to 36V.


----------



## Stan Cedarleaf (Jan 2, 2008)

Lookin' right promising... Right promising..









Stay afloat.


----------



## VictorSpear (Oct 19, 2011)

Stan,
I understand you had assisted on the artwork and the O/G scale power tips - thanks !


Victor


----------



## Treeman (Jan 6, 2008)

Is that antenna required.


----------



## VictorSpear (Oct 19, 2011)

For most model layouts outdoors or indoors, the ceramic antenna on both the Synapse or the Xbee is sufficient.

















If you want extended range, up to 4,000 feet (1 mile) like we do in these environments here, yes it would be good to have the 1" whip (only to stay Afloat, Stan)

Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

A brief clip on lighting aspect control. We can turn strings of RGB lighting on or off - no problem, but we prefer to have fine grained control of any single lamp in any string - anywhere around the layout or inside locos, cars, signals, or structures - and wirelessly from the handheld smartphone with three clicks.


----------



## VictorSpear (Oct 19, 2011)

Now moving along to wireless Controlled Aspect Lighting of Signal nodes, we decided to implement the NORAC 10th edition Rule Sets for the initial evaluations of a University railroad club. I chose these operating rules on account of the clear and simple descriptors for each Rule. Data was easily imported into a RailML like format. A handy reference app from Matt Patenaude allows us to use full screen controls to simply select the Rule - and transmit the three aspect state to the selected signal node wirelessly.



















This allows the Layout Supervisor to set the aspect and expect the wireless Signal-to-Locos Node communication to be in force. The key test for us would be observing that the loco slows down to the desired target speed on approaching the Signal node and then comes to a full stop as per Rule 286 (for example)

286[/i]
MEDIUM[/i]
APPROACH[/i]
Proceed prepared to stop at the next signal. Trains[/i]
exceeding Medium Speed must begin reduction to[/i]
Medium Speed as soon as the Medium Approach[/i]
signal is clearly visible [/i]


----------



## VictorSpear (Oct 19, 2011)

Added an Auto-Couple/Decouple function that operates with a single button on the phone. Problem was the cumbersome page swapping from Loco Control screen to Coupler Control screen. Testers reported in that it was 'frustrating' to flip different pages back and forth while trying to : slowly reverse, ...stop, ...open Kadee jaw remotely, slowly move forward, close Kadee jaw, etc.....on two separate screens. 

So we went for one button that toggles the whole operation at slow speed and lets the decoupling process auto-happen:

Click DeCouple button:

1. Nudge the train back a few inches, slowly. On board location/motion controller monitors this setting - shunting adjustable from 2" to 12". Constantly report this motion to the phone.
2. While reversing, open the loco's Kadee coupler remotely.
3. STOP after jaw is gradually opened. Flash/blink lights.
4. Go forward to release the attached car, stopping a few inches away again. Blink lights with different color.
5. Close Kadee coupler jaw.
6. Signal completion of operation to phone and flash some lights on loco (useful for night ops).

Repeat same process in reverse while coupling. Pundits may claim all this is non-prototypical ? No way....it's happening* here *;-) 

Waiting for video clips to come back to me after next round of tests. _In Latin - "Videre est Credere"_

Cheers
Victor


----------



## Greg Elmassian (Jan 3, 2008)

congratulations, you have just duplicated the "waltz" function that has been around for a number of years in Zimo, ESU, and or Massoth decoders. 

 Nice to see that you followed the same evolution, and came to the right answer. 

Greg 

p.s. this is not a negative comment... you now have a function that is already proven to be desired by model railroaders, a good thing...


----------



## VictorSpear (Oct 19, 2011)

Noted. Thanks. I'm wondering if Zimo or the others provide the ability to GoTo a specific location and Couple/Decouple - something we now provide to precisely target the decoupling location, whether it is 8 feet or 800 feet away on the track - without trackside reeds or embedded trinkets.


Cheers,
Victor


----------



## Greg Elmassian (Jan 3, 2008)

That is, of course, where your system will shine, and others cannot go. 

In terms of "programmability" your system has it all over the others. 

In your design, I would say that the "decoders" are more part of a system, than independent components. 

Greg


----------



## livesteam53 (Jan 4, 2008)

Victor, 
Looks like this is going to a Winner! 
Keep up the good work.


----------



## VictorSpear (Oct 19, 2011)

Been stationed off Helsingborg, Sweden and Copenhagen throughout the whole darn winter. Got to study the fascinating rail system Öresundståg during off hours. Wasn't able to do a darn thing with model trains and planes - all winter. Now I know why them Danes claim to be the happiest nation on the planet. The rail system works.

Vic


----------



## Brandon (Jul 6, 2011)

I've been hoping by the time I finished my layout, your projects would be done and I could piggyback on them for my AI layout. Problem is now I'll have my track layout done enough in a month or so to start running trains. Did any work get done back at the labs while you were gone or is there anything new and exciting to report on hardware or software?


----------



## VictorSpear (Oct 19, 2011)

Have been working on two separate streams : Proactive Polyphonic sound processor and in-situ battery charging to allow onboard charging in designated spurs...

The latter is much needed for the project apparently.


----------



## VictorSpear (Oct 19, 2011)

Finally got down to the belated Sound Project area this week and now steaming (limping) through Use Cases for dynamic activation of polyphonic sounds based on known State (Coupling, Uncoupling, banking, braking, shunting, slowing, ....speeding) and Location sensing feedback - to trigger sounds from a User Created portfolio of samples.

The fun part is creating your own concoction of sounds as .wav files 16-bit stereo 44.1kHz with the same fidelity as basic audio CD’s, sticking it in a micro SD card and letting the software play a polyphonic adaptation based on what the loco is doing and whether it is approaching (sensing) a crossing, siding or station etc...with up to 12 tracks that can be blended and played simultaneously.

I earlier created deep diesel sounds from boats in the harbor. I also created some whistles from holding a spoon over 2 steam kettles and have impressed only myself so far when running an old Annie. But it is the process of collecting live sound samples from railway yards and mixing some horn,bell, and clanking rumble that is fun.

My allowed budget $75....rather unfair, but that's part of the fun too..eh ? And I need to get all this done by Labor Day for that club in Seattle.

Cheers,
Victor


----------



## VictorSpear (Oct 19, 2011)

Got the dynamic track+battery design and proof of concept done.

A universal problem that every G scale forum had with vociferous divided factions - Track power or Battery die-hard followers. What about a circuit that optimized battery charging on spotty, dirty track so you could run trains 24 hrs, 7 days ? The intriguing use case got me thinking for at least a year and I now have a design that works.

Essentially I now feed 24 volts DC to the track. A set of power pickups charges the onboard 22 V LifePO4 batteries (inherently safer). Track or battery path switching is optimized by the ICs. When track power is available the batteries are switched to intelli float charging. When dirty track is presented, it switches to battery. No capacitors or manual switches.

As an added diversion, I enable the smartphone to wirelessly select track or battery circuits as primary. This means that if battery is primary, it switches to track only when battery is below a threshold voltage. Vice versa, which is the preferred default, the system is always on track power till a break in track power is hit. The system switches in microseconds so you don't even know the engine is now being fed by the battery. Simply leave the trains running all the time, or stationary on the track. Charging happens when needed. No plugging or unplugging, manual batt switches, swapping or praying that it has charged before the kids arrive.

When track conditions are really dirty, simply clean a two foot section or spur and bring the engine in to rest for some time after running awhile. No one knows (or cares) that the batteries are being charged at that spot.

So now the on board sound boards will not be interrupted. Horns shall blare and bells shall ring with continuity.

Cheers
Vic


----------



## VictorSpear (Oct 19, 2011)

Back from the freezing baltic seas...at least I have a few holidays to finish the Hybrid dynamic track/battery power model for outdoor G with the following features:

a. Supply 24V DC to the track or sections of the track anywhere for unlimited run time.
b. Fast IC circuit design monitors onboard battery and switches to track power when available in near real time
c. Auto Switches to battery at specific sections, reversing loops
d. Battery is always in charge/sensing mode when track power is on

1. Stationary charging: The objective is simple...reduce the cleaning time on track by maintaining a few clean sections of minimum one foot and send the loco there till charging is sufficient. No switches to flip.

2. Charging while running: Sensing circuitry to isolate/switch automatically from track to battery or vice versa. No switches to flip. Safer LiFePO4 battery pack - wire it and just forget about it.

3. Full control from smartphone to switch Track only, Batt only, or *Hybrid Real Time sensing mode*

4. Just keep running those trains all day or night outdoors/indoors !!

Using the new intel Edison chip. Very cool. Micro sized and smaller than my thumb.










Inspiration :









Merry Christmas !
Victor


----------



## East Broad Top (Dec 29, 2007)

Far be it for me to stifle creativity. What you propose sounds great--it's been proposed for as long as people have been running battery power (though quite unsuccessfully met for a variety of reasons). I don't know that I see a whole lot of commercial opportunity for this, though, if that's where you're looking to take this. The folks who "go battery" do so specifically to _avoid_ cleaning track. Battery technology has improved to where we're getting upwards of 8 hours run time out of a battery pack the size of two decks of cards, so run time isn't near the issue it was even 10 years ago, and as technology improves, that's only going to get better. That, and the Lithium batteries hold their charge long term, so we've almost always got enough of a charge on one pack to run long enough to charge another battery or locomotive if needed.

I do see potential for those who run track power primarily as a "back-up" similar to what folks are doing with super caps. If running on battery power over long expanses of track (such as a reverse loop, etc.) is the intended goal, the control system has to be wireless-based so you can get the commands to the loco while over these stretches of track. From the systems you've been talking about over the course of this thread, I'd say that's not an issue, but in terms of applying the technology to those who are running DCC, your market might be a bit thin. 

Just food for thought. Again, my comments aren't meant to quash your momentum. It sounds like you've got an application for which this is particularly well-suited, and if it solves your problems, that's all that's important! 

Later,

K


----------



## VictorSpear (Oct 19, 2011)

I visualized the use case like the built - in batteries in laptops and phones at airports etc- but notice every one still rushing to find the power outlet and invariably at another gate 

Removing batteries for recharging, picking up locos to plug in chargers, waiting for charging, swapping batteries, incorrect battery, completely discharged or partial charged battery, wrong charger...all seemed like risky drudgery for me even with the smart chargers..

Then there is car lighting, switches, sign boards, announcements, signals, yard and building lighting, billboards, pumps,... all of which need a constant power source... so you are still in need of supplying 24V steady power to the layout anyway. Why not use it then for the primary reason - run trains.

So I just want an always available - always charged battery source in the loco for running all year... plug it and forget about it.. Like my laptop.. 

And it works at least at the test layouts who wanted it for non-stop 24x7 runs in the cold and rain...the wireless aspect does let you send the loco to that clean section of track for charging. Or wherever track power is available in any section of track - while running. 

Cheers,
Vic


----------



## Pete Thornton (Jan 2, 2008)

> Removing batteries for recharging, picking up locos to plug in chargers, waiting for charging, swapping batteries, incorrect battery, completely discharged or partial charged battery, wrong charger...all seemed like risky drudgery for me even with the smart chargers..


Victor,
When I did my first battery conversion in an Aristocraft Pacific many moons ago, I also contemplated having a piece of powered track in the engine depot where the loco could sit and quietly recharge. I set up the tender track pickups to do just that.
But I was still thinking like an indoor, table-top railroader. Once I moved to the great outdoors it became less obvious that I would need to recharge on the track - the batteries outlasted my afternoon running, and providing power in the garden required a whole new set of electrical skills.

So I never needed the track recharge, and I never missed having it.


----------



## Greg Elmassian (Jan 3, 2008)

I've seen this on track recharging idea come and go many times over the years.

From a top level perspective, the extra electronics to make this right is not worth the extra cost. The bottom line is that you need a charging system that can be interrupted and do a proper, high current restart quickly after each interruption. This does not exist in commercial products.

If you really want to do this right, it's just too complex with too little payback. Running power to rails is not an electronic challenge, it's mechanical, get good joiners, keep things clean and tight, use good wire. Nothing complex about it at all, and if you have various tracks providing recharge power, then it's a small step to powering the entire layout.

And then, there's no limited run time, no replacing batteries, no limited current so you cannot have sound and smoke and lights, i.e. no limitations.

Greg


----------



## IPTRAIN (Jun 1, 2012)

VictorSpear said:


> I visualized the use case like the built - in batteries in laptops and phones at airports etc- but notice every one still rushing to find the power outlet and invariably at another gate
> 
> Removing batteries for recharging, picking up locos to plug in chargers, waiting for charging, swapping batteries, incorrect battery, completely discharged or partial charged battery, wrong charger...all seemed like risky drudgery for me even with the smart chargers..
> 
> ...


Hi Vic,

I can just confirm - two of my WiFi controlled Locos (V3 - Switchers) are LiIon Battery equipped with continuous track reacharge (when power on track is available). These are the most easy care stuff in my railyard.



I never care about DCC addresses when being a guest at DCC events - radio IP adresses link my locos
I can drive without power restrictions - even at live steam events - for hours without any recharge
I am recharging "on the fly" when powered tracks are under my wheels
The prior "electronic pimping" is paying back now during usage.

Regards

Karl


----------



## VictorSpear (Oct 19, 2011)

There you go....cool power.


----------



## toddalin (Jan 4, 2008)

I hypothesized, and it was then demonstrated, that the speed increase is more or less linear relative to the power (square of the voltage), rather than just the voltage applied to the rail.

If you really want to make your system different, and really improve the low speed characteristics of the trains making it stand out from the others, throttle the _power_ rather than the _voltage_ . I did a post on this a while back and it should be in archive.

While the current generation of equipment may set a minimum start voltage, I think that they still ramp up the voltage in a linear fashion. This "ramp up" should be based on the power and not the voltage and the trains will follow the throttle in a linear fashion.

The calculation is relatively simple.

The output voltage = sqrt ("throttle fraction") x input voltage where the "throttle fraction" simply represents that spot on the dial.

So, if 24 volts were available and you set the dial at 5 (out of 10), the output voltage is sqrt (5/10) x 24 volts = 16.97 volts

At 1 (out of 10), the output = sqrt (1/10) x 24 volts = 7.59 volts

At 9 (out of 10), the output is sqrt (9/10) x 24 volts = 22.77 volts.

This translates directly to DCC substituting the "throttle fraction" for the "step fraction."

So with 24 volts available, at step 128 out of 256, the output = sqrt (128/256) x 24 volts = 16.97 volts

The minimum output would be step 1, so the output = sqrt (1/256) x 24 volts = 1.5 volts

And step 255 would sqrt (255/256) x 24 volts = 23.95 volts


----------



## VictorSpear (Oct 19, 2011)

*Location tracking with NFC RFID*

Started work on the final stage of the location tracking and reporting module with a new board - a small Near Field Communications (NFC) reader transponding at 13.56 Mhz with 5cm distance reading. The board is flat profile and slim enough to affix under the loco chassis or fuel tank so it can hover pretty close to the track (1 to 3 cm).

By sprinkling low cost epoxy covered and waterproof on-metal tags (25 mm rad was minimum radius to produce 100% readings at high speed) all over the layout, I'm able to report current location, next marker and ground speed checks nicely. The Goto_Location_XXX function to dispatch a loco to a precise spot is now achievable with precision. The tags are easily hidden under fine gravel or dirt between the rails. 

The PN532 chipset I'm using gives me a wide variety of NFC tags ($0.50 to $1.00 in bulk, Amazon Prime) to experiment with beyond the standard MiFare types. 

In earlier experiments, I had issues with NFC RFID readers being too slow when the locomotive was running at higher speeds - always produced erratic reads. Now using a faster I2C protocol and a faster processor on the main board lets me reliably catch tags spaced 6 to 12 inches apart. The reader is also SPI capable so speed reading isn't the issue now.


----------



## Brandon (Jul 6, 2011)

What's the reason you went with nfc rather than laser diodes? 

When we talked a couple years ago you were leaning towards using lasers for mapping the track. I went with rfid and sourced some rid tags encased in glass for $.21 each. I found the range was 2-5cm based on the rfid antenna. I also liked the glass rfid tags because they fit inside of hollow track ties really nicely and I'd just dab with a hot glue gun to secure them.


----------



## VictorSpear (Oct 19, 2011)

Yes, I remember you were experimenting with RFid back then. The NFC ultra low power 13.56 MhZ high speed read/write range is an appealing Use Case plus I can tag/write the tags straight from my phone. I had originally designed it to track a neighbor's duck flotilla. 

I still optionally use the Laser Diodes for line tracking, but around switching operations now instead of the magnetometer.

Essentially I find it easy to sprinkle the tags all over the track layout, mark the tags with 'names' using an iphone + NFC adaptor and upload it to the layout database. Then while running I ask the loco to go straight to that specific tag and wait. At a friend's location, I arrive with a bunch of tags and name them (1, 2, spurA, siding B,....etc) so he can have his own markers.

Victor


----------



## jbooker (Jan 15, 2008)

Victor,


Do you know if your pals will launch the product soon? I only see a silly Bartender Train on the Turret web site, and http://www.turret-bahn.com/ is no-op.


TIA,
Josh


----------



## VictorSpear (Oct 19, 2011)

Scheduled launch is at NGRC 2015, Denver - I am told. They've been busy with the dineTrain concept all last year in Europe.


----------



## VictorSpear (Oct 19, 2011)

While no point-2-point network can ever match the resiliency, redundancy, self healing deterministic optimization of a mesh network in noisy interference heavy environments, an example to illustrate capability is worth more than many arguments where the use cases are clearly different.

In this video, one can visualize the true nature of ultra low latency optimization in the hover regime as demonstrated by Kmel (now Qualcomm). In this case one does not care if any single robot has expunged itself from the network while the rest continue to fly and communicate holistically with micro second anti-collision adjustments. 

Note: This figure 8 formation cannot be performed in a point to point or a point-to-multi-point network. There is no single point of failure for example as it does not rely on a single asset like the other two to control the formation pattern and forward collaborative motion.






Victor


----------



## Homo Habilis (Jul 29, 2011)

Here's the URL (I think) from Victor's last reply if it doesn't show up in your browser. You might need to cut/paste it into another tab/window. You'll need to remove the spaces in the "h t t p s" part of the address.

> h t t p s://www.youtube.com/watch?v=YQIMGV5vtd4 <

It didn't for me on Chrome.


----------



## VictorSpear (Oct 19, 2011)

The journey continues with the arrival of a first prototype test board for the rails2battery sensing/charging circuit. It is now pre-loaded with charging algorithms for both in-loco Li-ion batteries as well as gel cell lead acid batteries that can reside in the layout's intelliCar designed to be left outdoors in all harsh weather conditions.

Some available features:
Up to 35V input, 25.2V float charge preset output, 0.5 A to 4.3 A max adjustable
Li-ion and gel cell charge algorithms
±0.5% Float Voltage Accuracy
±5% Charge Current Accuracy
Dynamic power demand pathway sensing
Instant-On bus power delivery for Heavily Discharged Batteries
Onboard Timer for Protection and Termination
Bad Battery Detection with Auto-Reset
NTC Input for Temperature Qualified Charging
Binary Coded Status Pins for continuous feedback


----------



## Greg Elmassian (Jan 3, 2008)

That looks like a commercial charging chip, not a custom programmed, custom designed charging system, i.e. the charging "program" is designed already.

I'm not trying to pick holes in this, but I have NEVER seen a charging system designed for many interruptions that keeps a "memory" of where it was, so it can pick up where it left off without re-analyzing the battery and starting off from scratch again.

Greg


----------



## VictorSpear (Oct 19, 2011)

Correct. The chip is commercial, the state analysis and recording is not. (Binary Coded Status Pins for continuous feedback)

Victor


----------



## Greg Elmassian (Jan 3, 2008)

Please tell me more about the "recording", I've always thought that someone could really make this work if they put more smarts into the charging system.

Greg


----------



## VictorSpear (Oct 19, 2011)

It's a subject of a slightly longer conversation but I can attempt to summarize:

Recognizing important criteria - Safety, Reliability, Availability, and layout condition Awareness (SRA2) for outdoor opportunistic power supplies. We considered two Use Cases for measurement and battery management: Batteries embedded in a loco or by the use of a towed box car array. We divided ourselves into 2 teams to address this and I got involved the latter two criteria.

_The aspect of Awareness required the Know-Your-Track conditioning run where the loco is run one full loop in one direction and reversed in a second run to record the desired warm spots for deterministic float charging. In other words in this 'awareness run' we record the spots that have dirt jitter, areas to avoid like frogs, and other areas that vary the input impedance from the rails. _

_Dynamic charging - We record the opportunistic areas to enable float charge mode while running through optimal locations of track that are at least 10 feet clean. In other words, there is no need to switch the float charge controller on if the there are too many dirty spots in a section of track - instead automatically switch purely to battery only and wait for the next clean section approaching as the train moves. In the clean zone, we switch to track+float charge algorithm turned on._

_Stationary location charging - A report is presented on the handheld screen to indicate locations_ _of track that are dirty versus clean runs (at least 2 feet) so that the user can dispatch the loco to that area for stationary charging. We capitalize on the fact that Li-ion chemistries do not need to be fully charged for instant availability in the opportunistic mode of a short duration._

The integrated circuit only provides us with a DC/DC Buck Boost controller and multi-chemistry battery charger offering constant voltage/constant current modes. We are also recording the actual charge cycle durations and actual discharge current patterns that occurred over the prior runs and we are capturing the critical time duration parameter that was incurred during each stage of charging to support the float charging algorithm 

The loco sends back the required parameters every 500 ms and historically stored in the embedded database. For example, we know how many charge full-cycles already incurred to-date on the battery pack in use, for example. 

The small form factor 'install and forget' sealed gel SLA battery actually gives us the best float characteristics with Safety being a primary concern when left in the outdoor layouts summer or winter. 

Our encompassing objective was to safely leave the battery in the loco sealed for at least 2.5 years without any external charging jack, while charging from the rails in the opportunistic support mode - criteria 2. The primary running mode is track power with the battery as secondary on-demand motion support. The mode can be reversed.

Victor


----------



## Greg Elmassian (Jan 3, 2008)

Interesting, a lot of work to determine the "good power" spots, but that makes sense, since you have positional awareness. 

My question was a bit more specific, but perhaps you mentioned it, since you refer to "float charge" several times. That is a low rate charging term NEVER applied to lithium battery chemistries.

Yes, just fine on gel cells, and can be ok with some limitations on nicad, but "float charge" cannot be applied to modern lithium types.

So, if my interpretation is correct, you just turn on or off a current appropriate for float charge. In this case, you really don't need a battery charger circuit, just the correct terminal voltage.

I was trying to find out how you could "resume" an interrupted charge cycle, where the IC monitors and calculates charge current, duration, etc. It appears that you do not use these modes and therefore have no problem resuming just a simple float charge.

Not "dinging" you at all, this is probably the easiest way to do it. The other way is to basically create your own charger, with the proper algorithms, and then ADD a way to interrupt and resume.

Regards, Greg


----------



## VictorSpear (Oct 19, 2011)

We've been only using the inherently safer LifePo4 batteries from day 1 that are float-chargeable and since they have become popular in the field, they should be getting a more compact form factor to compete with the Li-ions.

The intelli-charger is capable of float charging NiMh, SLA, LifePo4 and Li-ions but we are only exclusively testing with SLA and LifePo4. (In the last 3 years interruptible float charging of the new 4.2v li-ions has become possible with special conditioning algorithms but in every case it is charged below this voltage and charge stage duration controlled for shorter periods of time). 

I'd be interested to learn from anybody why controlled float charging is not possible safely with Li-ion. We do avoid the cheap inrush chargers sold in the market today that actual reduce the expected life substantially.

Victor


----------



## Greg Elmassian (Jan 3, 2008)

I did some more research, there are indeed articles on "float charging" li-ion, but the term is deceptive, by the judicious use of terminal voltage, you will terminate charging when the cell is full... there is no more charging. 

Float charge really means continuing to charge, but the battery can handle the "unnecessary" current, i.e. the battery is full, but the continuing current does not damage it.

So, by some people's definition of "float charge" you can do this to lithiums.

But you need the CURRENT terminal voltage of the cell(s) which varies over their lifetime, and you need to go about a tenth of a volt per cell under this.

Funny thing, this is how I charged batteries for years, where I determined the terminal voltage when fully charged, marked it on the battery pack, then charged it with a laboratory grade power supply controlled to 0.01 volts.

At the "end" of the charge, if the current did not go to zero, then I knew the cells had aged, and noted the new terminal voltage.

This worked very well for many years, as I also current limited the supply to 1/2 to 1 C (depending on the pack and chemistry).

Perhaps this is what you are doing for lithium ion and polymer. The newer LiFePo4 is great stuff, and I should have known that your reference to gel cells was I guess not an indication that you were stuck years back, but are more current than most!

(My apologies for even thinking that ha ha!)

Greg


----------



## VictorSpear (Oct 19, 2011)

While working on the onboard Power Harvester for outdoor battery management, upgraded the UIs for a simpler finger friendly touch on the smartphone. 

It now switches from color to grayscale making it a lot easier to use in the afternoon when bright sunlight ambient conditions may prevail.










Added the lighting control UI to control trackside, garden and interior lighting










Updated the menu to include Sound Control as a similar control to the lighting UI method for the polyphonic sound channels with independent gain control










Just having fun !

Victor


----------



## VictorSpear (Oct 19, 2011)

The underlying engineering beneath the simplified UI allows for real-time synchronization of all handhelds and mobile devices on the layout. 

When controlling a train, all users see the same speed, location and other parameters on their screens simultaneously in real-time. This allows for:

1. Many users controlling one locomotive. Last User's command overrides previous user on the synchronized UI if permissioned by layout Brakeman.

2. All locos, switches, lights, sounds, signals, couplers controlled by more than one user simultaneously without channel resets or handovers.

3. Instant zero-configuration permissioning and release of user devices into layout. Just arrive with a phone or tablet, sign-in to the layout network and run trains.

Ah, a lot more to cover this summer with testing.

Victor


----------



## VictorSpear (Oct 19, 2011)

VictorSpear said:


> Continuing with the Positive Train Control (PTC) aspect with signaling determinants, I allow the railway operations manager (layout owner) to set the movement authority on virtual blocks, speed constraints, braking curves....and directly control the signals. Attempting to run the loco by ignoring the determinants, would simply override the handhelds and bring the loco to a halt or slow down to the restricted speed, enforcing the fore and aft safety cushion of the consist.
> 
> 
> 
> ...


Exactly two years ago we embarked on introducing Positive Train Control (PTC) for the model - in tandem with the prototype's deadline of Dec 2015. We got it built into our system but - Tragically this PTC topic is very much in the news today as we lament the consequences of the slow pace of implementation for the modern prototype which will reach $14 billion in spending on this initiative alone nation wide.


----------



## jbooker (Jan 15, 2008)

Hey Victor,

Any info about the turret-bahn release? 

They said via email they'd release some info in advance of the Denver convention - perhaps as early as May - I was told. 

We're days away from the convention and I still find nothing here: 

http://www.turretbotics.com
nor here:
http://www.turret-bahn.com/

Would love to get my hands on it this summer.

Thanks,
Josh


----------



## VictorSpear (Oct 19, 2011)

Josh,

The Turret Bahn team working with Stan Cedarleaf and Mike Kidman for G scale parts and getting some demo units readied - I'm told. 

They had spent all of Spring to date on getting the MCC designs for http://www.Dinetrain.com which chewed up all available muster on deck and crew now re-focusing on the show prep. 

Wish I could attend...
Cheers
Vic


----------



## VictorSpear (Oct 19, 2011)

After a long hiatus, resumed some work on the MCC model again. In the three test layouts in operation at friends garages and backyards (who demonstrated a superior degree of patience in dealing with my ever-changing methods), I got 7 months of written feedback and data on numerous operational experiments. 

I've now embarked on expanding the layout mesh concept with some real reasons to handle real-time messaging and feedback signals in a different and 'graceful' way. 

Considering that all assets (locos, switches, structures, sounds, animation, lights, gates...) in the layout are either sending or receiving data (message packets) constantly, I had to invoke a management layer to handle the thousands of burst packets coming in from all directions at the Command Module.

I've now added telemetry processing with the MQTT ver 3.1 publish/subscribe protocol - an IBM 'giveaway' that works fine for lightweight assured messaging. Now, regardless of the volume of messaging activity, I handle multiple locos or other assets that can be controlled by multiple handhelds/tablets simultaneously without conflict - and all assets synchronized in real time without any linking/de-linking or conflict issues. 

The simple case in point - the RPM or location data for any selected loco showing on one handheld is the exact same synchronized reading on any other handheld, even when switched on/off. If a speed step is changed on one handheld, all other handhelds are updated simultaneously. 

So if someone joins the mesh layout and is permissioned to operate a specific loco, they enter instantly at a synchronized state with all other handheld controllers operating that loco. This just means that they are 'subscribing' only to the data flowing across the mesh that they are interested in - and ignoring everything else being 'published'. (pub/sub via MQ for those of us that chatter constantly). This is a little more advanced fun for my gang than the old websockets methods we had going. 

Why would I care to use this? When operating a loco and needing to take a p-break, any one else can instantly take over control with their own handheld and when I return, I take over control without any hesitation or latency and with a single click I'm instantly at the same assured-synchronized state as they are. No linking/syncing latency. Zero wait state.

Nice to be able to deal with nature breaks by having extra eyes watching the trains.

Cheers
Vic


----------



## jbooker (Jan 15, 2008)

I check this thread a couple times a year and sadly no news on the availability of the turret bahn digital rail system. Bummer.


----------



## VictorSpear (Oct 19, 2011)

JB,
Several kits were shipped out to those that attended NGRC 2015 and 2016. They are using a distributor to ship it in kit form for evals - since the Xbee ZB radios arrive separately from Digi. Almost all of the ver 2 units are being deployed into their next-gen restaurant automation project commercially, so there are only a few robotics eval kits sent out. Send an email to [email protected] requesting a kit for TBDRS 2.0 - you should get a response from the eval program.

Here are some pics of my own kit showing with and without the sound processor card with add-your-own sound files. The assembly requires no soldering. This is the 12 amps continous (28 amps peak) motor load version, polyphonic sound processor.


----------



## Cataptrra (Mar 16, 2015)

Me, I'll stick with simple DC via a wireless linked transmitter, trying to read through this thread to learn about this system just started to give me a headache trying to understand all the statements here about this stuff. And I worked in prototype engineering labs designing things, but this thread just seemed to go everywhere and nowhere.

Finally I had enough, skipped to the end and stating my preference. it's simple and sure doesn't cost as much as one stupid smart phone would cost me, which I don't care for smart phones, don't own one, don't want one. And then add all this external stuff to that cost, no, I don't think so.

And if this stuff works where anyone can just link in to your railroad and download and start running trains, just how well is that going to work if you have a neighbor that may have a Garden Railroad using the same system? Seems to me there could be some interference here. And smart phones always seem to get hacked, not that a hacker may want to hack into such a program, but you never know.

Sorry, I'll stick to simplistic running with DC power, wireless systems like the Aristo-Craft TE for me. I don't need a lot of fancy gadgetry to run/operate my railroad. And I prefer the modules embedded in the tracks to control things on the side lines, in a rail car or reed switches and magnetic to blow the whistle and ring the bell.

Just by far a simpler alternative for me over this system, which sounds extremely complex and confusing to say the least.

If its for you that's fine, but it is definitely NOT for MY Garden Railroad!


----------



## VictorSpear (Oct 19, 2011)

Cataptrra, To Each His Own - a saying made famous in the 1946 movie starring Olivia De Havilland, and the adage still applies today!!

http://www.imdb.com/title/tt0039040/mediaviewer/rm1006048256

Anyway this was also an experimental system designed for another generation of users studying STEM including trains, planes and driverless cars. They use it weekly in their BattleBall exercise with 10 running simultaneously without interference, reaching 30 amp peak at stalls several times over. With parents and grandparents attending. The prize? $30 million in scholarships that sustain this effort. http://www.firstinspires.org/scholarships If Garden Railroading is to survive the economic headwinds coming, it needs this generation to be involved - now.

It also doesn't have anything to do with just 'smartphones' but more the Internet of Things (IoT). It can be run by any 'thing' including PCs, tablets, ipods, droids, even voice if you so adapt it to do so. It just happens that it can be run by anyone who is part of the 2.6 billion smartphone community (now more than 1/3 of the world's population). Yes it is DC/wireless/mobile.

Anyway, the older 27Mhz TE should work fine for what you want to do! We've been through the rants several times before. To Each His Own.

Cheers
Vic


----------



## VictorSpear (Oct 19, 2011)

After a year-long hiatus from the hobby due to work, I'm back. During that time I built an Alexa voice activated hydroponic *pumping *system to enjoy some fresh salads at home. 



I'm planning to integrate that into my outdoor '*trailway*'. Given that the new Alexa upgrade recognizes voice authority (not just voice but who), I have Start, Stop, Slow, Goto Marker,...working with just my voice. So onward with that...

Meawhile, being following Apple patents since 1996, with this one from Jul 2016 - I've been looking to add tactile controls as an add-on to the SmartPhone controls using this concept:

Pic: *SmartTactile Sleeve*

Pic *Sleeve Open*. 

While the knobs can be machined to varying spec, they need the encoder electronics now to fit that sleeve.


----------



## VictorSpear (Oct 19, 2011)

The Bourns 9 mm quadrature incremental encoder is first choice. Given that the typical sleeve of the i-6, 7, 8 models are 12 mm this would be it for the first *proto*.

For a different project, I needed a much slimmer form factor, but larger dia was ok - and managed to wedge a microquad encoder (12 cpr) in between the wheel and the axle - giving a reasonably precise incremental reading.

*Pic 1*

Pic 2

*Pic 3*


----------



## VictorSpear (Oct 19, 2011)

Came back to the hobby after spending a lot of time with flight control and drones. Now working on fully voice activated controls with Alexa and similar (Mycroft) with backup smartphone controls. Has anyone experimented with Voice Activation Command & Control? (VACC  

Here's an interesting link indicating innovation is still around in the hobby:






Lionel announces voice control of trains!


During yesterday’s TrainWorld virtual roundtable event, Lionel's president, Howard Hitchcock, announced Lionel Voice Control (LVC), which will enable voice control of trains via Lionel's LionChief App. The 5.0 update to Bluetooth makes this possible. A small icon will be added to the LionChief...




ogrforum.ogaugerr.com




Cheers
Vic


----------



## David293 (Feb 19, 2021)

VictorSpear said:


> Came back to the hobby after spending a lot of time with flight control and drones. Now working on fully voice activated controls with Alexa and similar (Mycroft) with backup smartphone controls. Has anyone experimented with Voice Activation Command & Control? (VACC
> 
> Here's an interesting link indicating innovation is still around in the hobby:
> 
> ...


I got curious about your hobby what drones do you use? I have never used it before but I would like to. I’m not really expecting to be called into film the next James bond film, more take a nice photo/passable video of the boat in an anchorage or the canoe out on a loch type thing. So I am searching for a rather cheap but good drone 5 Best Drones under 250 Grams: In-Detail Reviews (Sept. 2021) . Is DJI mini a good option for me?


----------

