Skip to main content

My suggestions to his (dave olsen's) "open question" period is -- why not make the trains (engines) two way on messages?   Give the ability to ask the engines for some info and get something back while running on the track?   Not sensor track, don't give that as the answer Dave.  Likewise a future revision of switches could include that they know their state (straight, or turn -- left/right for Ys) innately ... instead of using the stm2 thing for that...    Next up the lcs wifi is nice but the interface is low-level to get at the LCS packets.   It's all well and good but maybe a "cooked" higher level interface could be created there -- easing developers and adoption... ?    Finally, can we get quieter fastrack on the development path?   I know, I ask for so little... 

 

Severn posted:

My suggestions to his (dave olsen's) "open question" period is -- why not make the trains (engines) two way on messages?   Give the ability to ask the engines for some info and get something back while running on the track?   Not sensor track, don't give that as the answer Dave.  Likewise a future revision of switches could include that they know their state (straight, or turn -- left/right for Ys) innately ... instead of using the stm2 thing for that...    Next up the lcs wifi is nice but the interface is low-level to get at the LCS packets.   It's all well and good but maybe a "cooked" higher level interface could be created there -- easing developers and adoption... ?    Finally, can we get quieter fastrack on the development path?   I know, I ask for so little... 

 

I really wish these were submitted last week at the deadline as they are good questions.   I've already submitted and received answers for the posted questions.  I'll see if he can answer them. 

Trainlover9943 posted:

Will Dave be there to video the meeting? 

Yes.  We will post the video approximately a week after the meet. 

Severn posted:

My suggestions to his (dave olsen's) "open question" period is -- why not make the trains (engines) two way on messages?   Give the ability to ask the engines for some info and get something back while running on the track?

Knowing how the Legacy signal works, I think I can answer this for you. Don't hold your breath for Legacy to be two-way direct back to the base without other products in the mix. TMCC and later Legacy are strictly one-way protocols at this time, major hardware changes to engines and command bases would have to take place to change that. You're talking a whole new product when you start talking two-way from the engine back to the command base directly.

I do get that but hey it's called "legacy" right?  They could probably support something new and the current legacy signal at the same time.   However I might imagine they'd say "Ok technically we could do it -- but why?"
To me the answer there is -- well wouldn't it be nice to get current state, including speed at any time on the track of all engines?   You could do something useful with that given location info that say sensor track kinda provides (assuming you know where you put the things...)   Or some other technique.

Anyway, they might say: "Ok great stuff but that helps us sell how many new engines?"
Answer: if you build it, they will come?  I mean I don't know there, fair pt.

Those however are my thoughts, perhaps they have different ones.

Trainlover9943 posted:

Love the questions. Thanks for using my question in there, can't wait to hear the answers. 

The only questions I usually pull is off topic or production questions that pertain to scheduling and such.  We had a good batch here so they all made it.  FYI Dave Olsen scanned the thread and even answered Severn's questions. 

Thanks for your efforts Marty! 

Background:  so I joined as an LCS partner some time last year, had to sign something ... then got a pile of documents.  I wrote some very basic control software after piecing together the necessary LCS parts & legacy engines over time first.   The documents are good but in some cases some minor updates could be helpful.  (sorry I dont' recall the details of what I didn't like right now)  I got as far as a very basic control of 3 engines -- since that is what I have: speed up, speed down,  quill horn sound,  brake and brake squeal is what I recall I chose to directly control. 

(there's probably "200" commands or so ... one could spend years well months trying to get them all ... ) When the engines go over the sensor track I capture that return packet and display some of the info. 

It was all fine and good I learned quickly that I cannot control 3 engines at one time...   and then I stopped right there and went on to some other things with the intent of going back to it one day... which was weeks ago now.

So from that vantage pt my interests would be along the lines of:   info sharing, possibly code sharing,  new LCS info, etc...

I think it would be interesting if the end user could add their own icons to the remote/base.  Perhaps there could be a few "reserved for user icons" added to it in the future with some kind of interface to add them thru the LCS bus.   (so I'm not asking for the deep insides of the stuff -- just an interface...)

What would such a user icon do? 

Well my thinking interface would associate a user defined icon with a user defined command -- so when selected the remote sends the user command over the LCS bus ...  and that command would be picked up by a user built LCS device(ser2?), and then something would happen as the user has envisioned -- assuming what they've built works of course.

I don't really think the command needs to be radiated out over the wireless portion ... the user can do their own radiating with their own LCS device if they want to do that...(for example one could even envision morphing the TMCC command packet into an appropriate DCC command to wireless DCC controller ... and well use your imagination)

Right now, one might be able to do this with a computer now and the LCS bus.  Just to be clear -- I've never tried it but I suppose one could gen up their own LCS/TMCC?  command ... maybe use any reserved for future use command codes if there are any, etc...   and a device of the users own design could in theory pick it up to do something. (probably thru the SER2?)

But even if all that worked, it would not appear as an option on the remote.

Add Reply

Post
×
×
×
×
Link copied to your clipboard.
×
×