The Universal Wireless Remote Control Topic (Design is Finished!)

And now for something completely different.  Explain to me some real-world scenarios/applications of 4-channel operation.  What's neat about the PIC is you can queue triggers.  So if both CH1 and CH2 are triggered simultaneously, you can queue up the CH2 trigger to present to the TX module after the CH1 trigger is dispatched.  

One question is CH3 and CH4 which are separate and do not go thru the PIC.  As drawn, the PIC has no visibility into what CH3 and/or CH4 are doing.  The TX module can only transmit one command at a time.  Now that I think about it, I have no idea what the TX module does if more than one trigger is active at a time (?).

Anyway, getting back to the "universal" flavor of your motherboard, I'm trying to get straight exactly what applications need (up to) 4 channels of triggers and "who" is responsible for insuring that multiple channels are NOT simultaneously triggered/active. 

The four channels are there because you might want to control stuff in multiple locations from one source.  Remember, I'm making single channel receivers that will react to individual channels.  I can see the locomotive having the four channel board installed, and then using the individual receivers, react to a coupler signal, a headlight signal, markers, and perhaps smoke off/on status.  Also, you don't have to use all four channels, but I can envision plenty of times you'd want to use more than one.

Fun fact, the four channels appear to be totally independent.  That is, I can hold continuous transmission on one channel and manipulate the other channels with 100% recognition. The transmitter board we're using, as well as several different brand keyfobs, all will transmit one or all the channels and they're perfectly recognized by the receiver, and when any one goes active or inactive, it's immediately recognized.  Given that fact, I don't see why I have to insure the other channels are not triggered simultaneously, this seems to be a non-problem.

A different problem does exist, that being multiple transmitters.  If you have two transmitters trying to send at exactly the same time, then the messages do get lost.  That's not something that is easy to control, I don't have a solution for that, but it has nothing to do with the design of my transmitter board.  In point of fact, multiple transmitter boards are a problem.

@gunrunnerjohn posted:

...

Fun fact, the four channels appear to be totally independent.  That is, I can hold continuous transmission on one channel and manipulate the other channels with 100% recognition.

The specs are scant for the TX module from the qiachip website.  So this may be a roll-of-the-dice if they go to V3 or whatever.  Anyway, for the record let me understand exactly what you're saying:

So if you continuously trigger say CH1, the TX module will transmit continuous packets (~22 msec long, every ~30 msec).  But if CH1 is transmitting and you additionally press, say, CH3 then the packets switch to CH3 packets?  Or are the packets alternating CH1, CH3, CH1, CH3, etc.?  Then you release CH3 and the packets revert to continuous CH1 packets?

When you say "totally independent" I'm a bit confused.  If all 4 channels are triggered simultaneously, what is transmitted?

Apparently, they just mux them all, I can sit there with either the transmitter (with my four buttons to trigger it), or a keyfob and press one, two, three, or all four buttons, and all the receiver lights react properly at all times.

@stan2004 posted:

So if you continuously trigger say CH1, the TX module will transmit continuous packets (~22 msec long, every ~30 msec).  But if CH1 is transmitting and you additionally press, say, CH3 then the packets switch to CH3 packets?  Or are the packets alternating CH1, CH3, CH1, CH3, etc.?  Then you release CH3 and the packets revert to continuous CH1 packets?

Correct, exactly what you'd expect to happen happens.  It's like the four channels are muxed, and they always transmit what they should to manage the channels.

@stan2004 posted:

When you say "totally independent" I'm a bit confused.  If all 4 channels are triggered simultaneously, what is transmitted?

I confess, I can't trigger them truly simultaneously, but I suspect they're managing that internally since as close as I can get with two buttons, I never see anything anomalous in the received data.  My belief is they manage the four channels in the keyfob or transmitter module and trigger the outputs properly.

I wouldn't be at all surprised to see that the transmitted word has a bit for each channel, and they're just setting and resetting one or more of them based in their inputs.  I know that's how I'd design it if I were doing it.  I suspect finding a specification for the 1527 protocol might answer that question.

Here's a brief data sheet on the EV1527 OTP Encoder.  From the sheet, it looks like my guess about the operation is probably correct, the packet contains bits for each input.  That seems to match up with my observations of the behavior of the parts.

Everything is becoming clear.  As the "datasheet" suggests each burst sends the state of all 4 inputs so any combination of inputs can be simultaneously active.  What's a little confusing at first glance is that successive bursts are back-to-back without skipping a beat so to speak.  That is, the Preamble of the next burst immediately starts after the last data bit of the previous burst.  So what appears like a gap between bursts is really the 31 clock gap of the preamble.

Anyway, for the record, since it appears you'll be using the TX-118S-4 V2 module, the above scope photo shows the timing for a CH1 and a CH2 burst.  The only difference as per the datasheet is the data bits.  As measured, the (1+31) clock preamble + (20 x 4) clock address + (4 x 4) clock data is about 32 millisec for 128 clock periods.   Since each clock cycle is 250 usec and it takes 4 clock cycles to send 1 bit of address or data, that's equivalent to 1000 bits/sec.

I think the value-added of the PIC is to limit the TX module transmission time to a few bursts whenever the 4-bit data field changes.  I realize that as configured the CH3 and CH4 will cause the TX to be on continuously if either are triggered continuously.  This would limit the user to having only 1 of these systems in place on a layout. So the idea would be to only use CH1 and CH2 for any triggers that can stay on for sustained intervals. 

That's my thinking Stan.  I'm also assuming that some of the outputs would be like couplers that only come on briefly, so they wouldn't be a factor.  Obviously, as I mentioned, having continuous transmission from one of these does knock out any other 433mhz system, not a good thing.

I sat down and coded up the PIC functionality, now I just have to get my boards back in and see how close I am.   I'm still up in the air as to the length of the burst, I programmed in 100ms, but a stroke of the pen can make that any value.

I think having the four operating modes of the two channels will be a nice plus over my first cut, it should fill a lot of the holes.  I was tempted to do all four channels, but that would require a larger part and I'd probably have to surface mount it and program it on the board.  I kinda' like the feature of having the chip in a socket so someone can have a replacement if new functionality is desired.

BTW, nice scope, I am still muddling along with the dual-trace model, I keep looking at the 4-trace ones, but I can't really justify it.

Stan, did you happen to notice that the TX-118S-4 V2 (and V1) have swapped the #1 and #2 outputs from any other transmitter? 

I have three or four keyfob transmitters, all of them are consistent that A = 1, B = 2, etc.  However, these transmitters send output #2 to the first receive channel and output #1 to the second receive channel!  I have to wonder if that's why they're being sold so cheap, someone ordered them and they were screwed up, so they had to fix them and go again.

I'm going to swap those two channels on my transmit board so these boards agree with all the other transmitters.

I can only speak to V2 as I don't have a V1. But yes I did notice looking at the physical scope signal that the TX pin labeled "1" actually controls the 2nd data bit slot (D1)...and the TX pin labeled "2" controls the 1st data bit slot (D0).

Stan, the V2 one does the same thing.  I swapped the pins in my code so that it'll match what the keyfob transmitters send.  I always like one to be one, two to be two, etc.   That has to be a screwup with the transmitter module design.  The encoder chip specs clearly indicates it sends them out right, so they must have just wired the board wrong.  Unless that's actually a design screwup and that's the reason they're dumping them cheap, I can't imagine why they'd do that.

Of course I'm obsessed with the possibility of a 2-wire self-powered PS2 version.  To that end I reduced the 470uF cap to 220uF as you have in your size-matters module.  I also added a 4.7K resistor across the 5V 78L05 output to simulate the ~1 mA load of a PIC.  Then I triggered it via the 2-wire coupler with both 18V command voltage and then only 12V AC on the track.  As scope photo above shows using short PS2 coupler pulse, 220uF is enough to power ~6 bursts at command voltage!  And even with a lower 12V track voltage it still put out 3 bursts...and reliably activates the receiver.  In other words, I think your 100 msec TX time which would be ~3 bursts is long enough.

So, again, I think by simply parallel'ing your 2 track power inputs and a trigger input pair, there is enough energy in the 220uF to release a valid burst in 2-wire self-powered mode!  I'm undoubtedly the only person who finds this exciting...but I've learned to be thankful for the small things in life! 

Mine has the addition of the opto coupler in the path, not sure how that will affect it.

The results are in, doesn't work.  I suspect whatever load/delay the optos inflict are the culprit.  This is the version without the PIC, so it's not in the picture.  This module just had the trigger go through the opto and on to the transmitter module.  I see the pulse, but it doesn't ever trigger the receiver, I don't even see the LED on the transmitter flash at all.  In an interesting twist, just connecting it that way to the transformer works a time or two, then it insists I power the board first and then trigger the transmitter.

Gunrunnerjohn

Is this new system you propose completely independent or will you be able to use it with any existing system?

If completely independent will it be like EOB?

I don't think I understand, Sorry. 

This isn't a train control system, it's for remote controlling stuff like accessories, operating cars, switching lights in passenger cars, etc.  The receivers can be triggered by the transmitter described or with a 4-button keyfob, depending on the application.

The receivers will be placed in various locations, either on the layout for accessories or in rolling stock, and even locomotives, again depending on the application.

Oh, OK thanks.

Stan & John,

I find this exciting, but, being an electronic idiot I can't begin to think of any helpful comment or advice I could give.

Keep up the good work. Hope it all works out. Some interesting uses.   Joe

Send lots of money Joe, that always helps with these kinds of projects!

@stan2004 posted:

Of course I'm obsessed with the possibility of a 2-wire self-powered PS2 version.  To that end I reduced the 470uF cap to 220uF as you have in your size-matters module.

What is the actual diagram of what you have working there?  It would seem it would be very simple to make a tiny board plug the transmitter module into.

I was looking at the components to do the transmission without their board, where did you find this little board?  Adding the 8-pin chip and this board is all it would take to transmit the data, a very compact board.  In truth, making the transmitter with our power requirements wrapped around it would be simple if the components and spec sheets were available.

The most recent experiment was to replace the 470uF cap with only 220uF as in one of your schematics for the TX side.  Also added was a 4.7K across 5V to simulate the 1 mA draw of a PIC.  Again, this was "only" to see if a 220uF momentarily charged by a brief PS2 coupler pulse can power the TX module for long enough to transmit a valid command.

There are many versions of the TX module, try search "433MHz ASK modulator".  For example:

As discussed earlier the PIC would then be back to heavy-duty-lifting to generate the 1527 protocol.  I don't see this as particularly heavy lifting since the data rate is only about 1000 bits/sec but then again No Job is so easy...well you know the rest!  I think the bigger challenge is how to create (up to) 1 million unique addresses.  As mentioned I recall you might be able to buy PIC chips with factory-programmed "unique" serial numbers that can be re-purposed.  I'm sure there are other methods as well depending on what kind of programmer you have, etc.

I revisited my remote control project and finished up debugging the code for the transmitter uP.  I made some tweaks to the board because of component fit and I'm going to get one more set of prototypes from OSHPark to verify everything fits properly before I make a volume order. 

I'm trying to gauge interest in the remote control project, but I'm thinking maybe there isn't as much demand for this as I initially thought.  If this project strikes a responsive chord with you, please speak up.  It may be time for me to put this all back in the box and move on if there is no interest.  No sense in putting in more effort if there's no market for the end result.

@gunrunnerjohn posted:

I'm trying to gauge interest in the remote control project, but I'm thinking maybe there isn't as much demand for this as I initially thought.  If this project strikes a responsive chord with you, please speak up.  It may be time for me to put this all back in the box and move on if there is no interest.  No sense in putting in more effort if there's no market for the end result.

John,

mentioned above it was only for accessories and such.  Not for a train control, correct?  With DCS control gone, I still think there is room for a high end replacement.

I'm interested if I can use this in my postwar barrel car or milk car. I can see it simplifying layout wiring for my sawmill, log loader, and barrel loader as well. 

@Bryant Dunivan 111417 posted:

mentioned above it was only for accessories and such.  Not for a train control, correct?  With DCS control gone, I still think there is room for a high end replacement.

I don't think DCS control is going to disappear, and I'm certainly not going to try to invent a new full featured command system for model trains!

@Darrell posted:

I'm interested if I can use this in my postwar barrel car or milk car. I can see it simplifying layout wiring for my sawmill, log loader, and barrel loader as well.

That's pretty much it's intended use, rolling stock and accessories.  For stuff like the milk car and barrel car, the one channel relay model would work great, it switches up to 5 amps.

I like the idea.  How would it work, would you need a control board for each piece of rolling stock or one master board and a number of receivers?

@NYC 428 posted:

I like the idea.  How would it work, would you need a control board for each piece of rolling stock or one master board and a number of receivers?

It's actually a modular system.  In it's simplest form, you'd just use the little 4-button keyfob to trigger one or more receivers in rolling stock or controlling layout accessories.  If you wanted to trigger the action automatically from either an accessory, track sensor, or a locomotive and/or rolling stock, you'd use the transmitter board and one or more receivers, depending on the specific application.  The individual boards are really building blocks for remote control tasks.

First production configuration receivers, the 4-channel relay output model and the one-channel FET output model.

I've decided on the use for my first installation of the 4-channel relay model.

I have a number of the Lionel sound boxcars, wouldn't it be cool to have remote control of not only the sound being on or off, but also the MIN/MAX switch on the car.  Also, given that I have four channels and I've only accounted for two, how about remote volume control?  A couple of low value resistors in series with the speaker (20 ohms is a good starting point), will give you three step volume control.  In this application, I'd simply use the 4-button KeyFob transmitter to control the car.

@gunrunnerjohn posted:

I'm trying to gauge interest in the remote control project, but I'm thinking maybe there isn't as much demand for this as I initially thought.  If this project strikes a responsive chord with you, please speak up.  It may be time for me to put this all back in the box and move on if there is no interest.  No sense in putting in more effort if there's no market for the end result.

John,  My hat is off to you for the time and effort you've put into creating this simple to use control system.  I would definitely be interested in buying a few of the boards depending upon price.  Are you planning to supply the remote with the control boards?  How about instructions for configuring the FOB buttons' to trigger specific relays or would this be pre-programmed?

Not sure if this would be good forum etiquette to ask (if not please email me) do you have selling prices in mind for the 1 and 4 channel boards, remote FOB, and any other necessary components (other than resistors and wiring) for turnkey installation in a sound car or operating car?

Haven't established firm pricing on anything as that's dependent on volume.  So far, I'm not sure there's enough interest to support a production run, hopefully that will change.  Perhaps the spring has slowed down the folks interested in train projects and I'll have to see what transpires in the fall.  I'm also still waiting on the "final" PCB for the transmitter and the one-channel relay receiver so I can show a couple of what production units would look like.

Given the modular construction of the various components, I'm considering that these would be Ala carte products, you'd just buy the pieces you need.  For instance, you may just need a couple of one-channel boards and a transmitter board.  Or, you might want to pair the boards with the keyfob instead of the transmitter, depending on how you want to control the remote units.

As for a practical application of one of the receiver boards and a keyfob, take a look at this topic.  This is something I've been wanting to do for some time, and now I have the stuff to upgrade all my sound boxcars.

Remote Control for Lionel Sound Boxcars

Updated the first post to the current state of the project, we're certainly on the home stretch!

I think we crossed the finish line.  I put the preliminary documentation for all the modules in the first post, so who's the first Guinea Pig to remote control something?

For those following along, here are a couple of practical applications for the remote controls.

Another Remote Control Sound Car Upgrade

Remote Control for Lionel Sound Boxcars

I'm fully aware of that It would be wired to one of my z1000 brick just like the the wireless remote that I have that operates a led strip and the light in a operating tower. I'm just not sure on the wiring for this device and or load.

The reason I prefer wireless remote switches is because I have a wall / shelf layout.

For discussion purposes, here's the eBay example:

The diagram suggests that when activated the receiver applies (via White and Black) 12V DC.  While anything is possible I find it unimaginable that the MTH water tower would take kindly to having 12V DC applied to the 2 wires meant to go to a momentary push-button activation switch.

There are many wireless relay modules that provide "un-assigned" relay contacts rather than pre-wire to 12V DC or whatever.  They typically operate on 5V or 12V DC so you still need a source of DC voltage.  They should also be less expensive than $19.  It's been a while but I think they are $5-10 shipped for a remote plus the receiver with un-assigned relay contacts.  Press button on remote and relay closes for as long as you hold down the button.