Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Circuit for replicating bell codes - any suggestions

Status
Not open for further replies.
To try out a DTMF 'keypad' input option, I think I would probably go for a cheap phone like this one: **broken link removed**

which is available easily in the UK.....and it includes a DTMF generator as well!!
 
It doesn't go to 16.

==

Some thoughts on construction:
1. Daughter card that mounts on keypad.
Power GND and (SDL SCL GND and Interrupt) x 2 the latter for daisy chaining. Call it the I2C connector.

2. The octopus-like cable that breaks out the bell connector (maybe) and the I2C connector.

3. The +5 V and ground connector.

4. A +12 (assuming +12 for the bell) to +5 breadboard converter (purchased)

5. A nice Bell 1 - Off - Bell 2 switch. Maybe an LED that's always co-incident with the bell.

6. The bell supply - whatever that is.

7. What you could do, is use a tiny switchmode converter and power the processor. Then when needed power up the larger power supply for the bell if your concerned about energy efficiency. It does add another output, but it would make it more energy efficient and cost more.

8. Power inlet connector including fuse and power switch. Use a Triac or relay to tun power on for the big supply. You might have to delay the transmission of the first code for 10-50 mS. If there is no more bell codes, then turn off the big supply.

aside: If you can measure the resistance of the bell, that would be very cool. Even if you use a 1.5V battery and the 300 mA scale on a meter, you could read R=0.005/(300e-3) ; Basically saying that you might be able to resolve 5 mV, you could possibly measure to 0.016 ohms.

Remember, that you MUST use an ammeter AND a voltmeter simultaneously to make this measurement. You have to measure the current through the device and the voltage across it to measure a low resistance. That will give us an idea of the peak current, knowing resistance, providing the voltage is known. You can size the power supply based on this peak current or you can add capacitance.

Still toying with the idea of an injector driver, but we need to protect the bell with something.

This reminds me, of writing computer programs based on specs. when someone knows nothing or very little. You show them something and then they add or subtract.

9. A nice engraved legend panel with the codes
e.g.
Code:
1  1      Attention
2  16     Testing
...
F  1-1-1- Whatever it is

I'm trying not to get too carried away, but my methodology is always:
What would I want if I had all the time and money in the world?
What do I need?

It's never really failed me. The reason why it doesn't is it anticipates and that anticipation adds "hooks" in the software/hardware. Those "hooks" prevent re-writes and re-do's.

So, when it comes to the "low-power" mode, the hooks might be:
1. Chose a port for that function and make the cable to support it.
2. Assure that the box has the space to add it.
3. You could purchase a line operated low wattage 5V supply instead of the DC-DC converter.

Is there any benefit of having the power supplies near the bells and/or having a power supply for each bell?
 
So, the "long pause" is the start of another message?
It was unclear that ATTENTION had to get a response from the other documentation found online. Note that some codes actually begin with a 1 and some don't require it. I think 16 bells didn't require the ATTENTION signal.
Ah, so your idea is to select one of two bells demonstrating the receipt? i.e. The other bell is supposed to ring to replay to a message?

Sorry, I was trying to keep my explanations to a minimum to avoid confusion people, but maybe I've not succeeded! Let me run through an example of how a demonstration to the public would work. There is a volunteer (the signaller) who is performing the job of the signalman as it would have been done originally. There is a second volunteer (background man) who is replicating the responses from the next signal box to the north (Bell A) AND the next to the south (Bell B) - the two bells. Trains are passed between the boxes (ie North Box -> Our Box - > South Box, or vice-versa) to simulate a train passing by. The background man is operating the 16 buttons, and the electronic circuity being discussed here. The bell codes/sequences mentioned below are purely to show an example, but apart from the attention bell, could be any of the possible options. The equipment used by the 'signaller' is separate to this and is not included within the electronics, nor does its response have to be processed by electronics - thats all down to the human ear for the purposes of keeping things simple.

Background: Presses a button, which causes a single bell to ring in the signal box on Bell A. (Call Attention)
Signaller: Repeats the one bell back
Background: Presses a button, which causes a specific bell code to ring in the signal box on Bell A. For example 3-2 ... ie ding-ding-ding-pause-ding-ding.
Signaller: Repeats the same bell code back

Short Wait

Signaller: Sends a single bell to South Box on Machine B
Background: Presses a button, which causes a single bell to ring in the signal box on Bell B. (Call Attention)
Signaller: Responds, sending the required bell code on Machine B - For example ding-ding-pause-ding-ding-ding-pause-ding-ding
Background: Presses a button, which cases the same bell code has he has just heard to ring on Bell B.

Obviously the demonstration includes other aspects, and goes into more depth, but for the purposes of the electronics being discussed here, that those to parts get repeated numerous times.
 
So - the 'background' guy, in the second case of the South Box has to be able to make sure he has identified which code the 'signalman' has generated manually, and then select and press the equivalent sequence code button from his button 'bank'.
Why does he not simply generate the response code manually himself?
He has had to listen carefully enough to identify which sequence the 'signalman' has just generated, so he might as well generate his response manually, rather than hoping he remembers which sequence button to press correctly.....
I can't see what the electronic sequence generator is for at all?... just let 'background' use a single bell push, and generate his own sequences..?....
 
.... or, you could chuck away most of (or all) the electronics and do things electro-mechanically. A motor-driven set of co-axially arranged wheels (one wheel per signal sequence) with notches on their peripheries could operate one or more microswitches to energise a remote bell. Not so instructive, though :).
 
Nigel Goodwin (an ETO super moderator) has some PIC tutorials that cover just about anything you need to do this project.



His PIC16F628 based main board has more than enough pins to do everything with just the one chip.

Tutorial 9 covers reading a 16 button array. If you need 24 buttons just add two more columns. I would suggest adding a ~1K resistor between the four row outputs and the switch matrix. This will prevent problems if two switches are pressed at the same time.

The output driving the bell is a effectivly a very slow serial data output. Tutorial 7 has code for doing that. Use it to send out a sting of 1s and 0s where a 1 rings the bell and a 0 makes a space. By coding the bits in each byte you can create any pattern you need. The bit rate will be equal to the shortest time interval you need. (or one half, one quarter, etc.) And the number of bytes in each pattern is enough bits to encode the longest sequence needed. Give all of the sequences the same number of bytes, and fill the end bytes of shorter patterns with 0s.
 
So, the signalman is trained to make real bell codes and the demonstrator uses the prop (electronics)?

Because you don't have enough people willing to learn "morse code:eek: (signal code).

Your explanations had:
Two bells, two places and what I thought was two units (now one human and one machine)

In one of LeeedsNorth's quotes above "replay to a message?" should have been "reply to a message".

My intent was to:
Get an idea of the bell separation distance.
Get an idea of the wire lengths.

Earlier, my thoughts were:
One demonstrator, two bells.
Demonstrator selects what bell to ring.
The bells are ____ metes/feet apart.

I'm trying to get a handle on the premise wiring.
One bell power supply or two or do you already have one?

Is it the signalman can operate either bell with a (push button switch each) and the demonstrator each bell (with a selector switch and the keypad)?

or something like:

The bells are 1000 feet apart mounted (outside/inside)
The signalman/demonstrator is 100 feet from each bell.
The signalman/demonstrator can ring either bell.

Some wiring in to form of ___ is in place.
 
So - the 'background' guy, in the second case of the South Box has to be able to make sure he has identified which code the 'signalman' has generated manually, and then select and press the equivalent sequence code button from his button 'bank'.
Why does he not simply generate the response code manually himself?
He has had to listen carefully enough to identify which sequence the 'signalman' has just generated, so he might as well generate his response manually, rather than hoping he remembers which sequence button to press correctly.....
I can't see what the electronic sequence generator is for at all?... just let 'background' use a single bell push, and generate his own sequences..?....

Two reasons really, one is that there are other things going on, and its easy to listen and then respond to a button, and b) we are hoping in the future to replace the 'background' guy with a computer. So triggering the different buttons becomes easier at that point - however, there is no timescale or budget for doing that at the moment, but what im trying to do is to avoid having to change the wiring etc, at the appropriate time in the future.
 
So, the signalman is trained to make real bell codes and the demonstrator uses the prop (electronics)?
Because you don't have enough people willing to learn "morse code:eek: (signal code).

Yes in the main. When you've done the job for 30 years, explaining the function of a signal box, as well as listening and sending bell codes is easy - its second nature. When your new to it, and doing everything else that is involved in the demonstration, its difficult!

Is it the signalman can operate either bell with a (push button switch each) and the demonstrator each bell (with a selector switch and the keypad)?
Yes

In the first video that was linked earlier - the signalman is shown operating the block bell in the signal box, treat that as Bell A and Equipment A. Bell B and Equipment B would be at the other end of the shelf/signalbox. At most about 10-12 foot apart. The 'background' person is downstairs - about 10-foot below - so the cable runs are 10-12 feet maximum from either bell to the buttons.

Same power supply for both bells (normally they would be different, but as its not going outside the box with us it can be the same). At the moment, they are not wired up, i've not taken that step until, we've the electronics in place!
 
Think about "cheating" at this point. Allow the ability to create a serial link so you don't have to interpret the codes or for that matter use a bigger processor that can do both.

Now, do you see what I mean about "anticipating" and how it can help a design. You could build "box a" and when box "b comes along", you have to redo box a.
 
Think about "cheating" at this point. Allow the ability to create a serial link so you don't have to interpret the codes or for that matter use a bigger processor that can do both.

Now, do you see what I mean about "anticipating" and how it can help a design. You could build "box a" and when box "b comes along", you have to redo box a.

Yes, I know what you mean by anticipating, I was just trying to keep things simple! How do you mean ... a serial link? The only thing with a bigger processor that can do both is that it has to generate the bells (for a train coming towards the signal box) and repeat the bells in response (for a train going away from the signal box) - does that not start to complicate things?
 
Last edited:
Oh and my railway electrical contact has come back to me - he's still trying to find out the amps/watts etc, but says that 90% of bells were 9-12v DC - which would probably explain why it worked fine with a car battery.
 
b) we are hoping in the future to replace the 'background' guy with a computer.

That sort of confirms your need to use a 'future proof', software controlled system ...so it's over to you software guys then....
(although I might knock something up on breadboard one day, to prove my simple post#48 circuit could have worked! :))
 
That sort of confirms your need to use a 'future proof', software controlled system ...so it's over to you software guys then....
(although I might knock something up on breadboard one day, to prove my simple post#48 circuit could have worked! :))

Not necessarily! My thought was that it would be reasonably simple to change the buttons out to another way of working, so that the 'commands' to the electronics are still getting a momentary pulse, hence the electronics dont need to change.
 
So, do you have some sort of power supply at this time?

Both bells will not run simultaneously, correct?

So, even for a demo, the idea of selecting bell 1 or bell 2 makes sense if the signalman calls in sick?:nailbiting: That way, you can run a one-person demo.
 
So, do you have some sort of power supply at this time?

Both bells will not run simultaneously, correct?

So, even for a demo, the idea of selecting bell 1 or bell 2 makes sense if the signalman calls in sick?:nailbiting: That way, you can run a one-person demo.

Thats correct. Only one bell will ever sound at once (in a real box it could happen that both sound, but for our purposes that gets confusing, so only one at once!) Kind of makes sense, yes - its a bit like demonstrating TV Channels 1-4, without having ITV and Ch4!!! But yes, in a dire situation, it would be useful I guess.

EDIT: We have a 12 volt transformer, that was donated to us, which can be used for power, which im told was one of these ... **broken link removed**
 
A transformer by itself generates an AC voltage. When full wave rectified and filtered, it generates a much higher voltage like (1.4 * 12 Vrms) DC. Discussion is still open ended at this point.

LeedsNorth said:
Yes, I know what you mean by anticipating, I was just trying to keep things simple! How do you mean ... a serial link? The only thing with a bigger processor that can do both is that it has to generate the bells (for a train coming towards the signal box) and repeat the bells in response (for a train going away from the signal box) - does that not start to complicate things?

May or may not. Remember I don;t have the full picture either, but what I mean by a serial link is:

When the bell codes are generated, a future, RS232 generates something like "Button10" so whatever it is on the other side, doesn't have to figure out how to decode the bells. No one has to know, they talk via another link.

A larger processor would let you be able to grow into some other system.

BUT, you may have to prove to your superiors that you can do a proof of concept cheaply first.

I could be saying that with the right design, you might be able to pull some ultimate design. Let's just say that ultimate design is:

Send code to bell #1.
Wait for some input (train presence sensor)
Send reply to bell #2

so let's say that was the case, In order to implement this:
1. The ucontroller has to be able to select the bell.
2, Their is another input.

It can change things from a simple DPST switch to select the bell to a different scheme entirely, Expansion is still possible via I2C untill you run out of code space,

Prepare yourself for:
Supervisor: Great! Can it do this?
You: No, we have to start over

to

Prepare yourself for:
Supervisor: Great! Can it do this?
Probably, if I add a few more parts.
 
Or --- off the wall:

Hey, on my tours, I think it could be really neat if we can use a Universal TV remote. You respond. I'l ltry. I think it can be done. Next you here: I keep loosing the remote, can you do this on a smart phone?
 
the maximum number of gaps would be two, for example eight dings-gap-two dings-gap four dings is the longest code, one bell being the shortest. In a perfect world there are 24 codes to be replicated, but the minimum number is 11.
Since this is for public demo use rather than actual loco control, would Joe Public (assuming he's not an ex-signalman!) be any the wiser if you used a shorter sequence, namely a randomly-selected code of 8 bits (including gaps) ? This would be relatively simple to do using a few discrete logic ICs, e.g. a counter and latch to grab a random 8-bit code (one of 255) and a shift register to send the code out serially (twice) to the bell(s). Just 3 buttons: respectively to send the 'attention' pulse, to enable the latch, and to 'play' the code. Signaller and Background would be the same guy, pressing the 'attention' and 'play' buttons twice. There would also be a 2-way switch to route signals to the appropriate bell A or B. With duplication of ICs the system could be extended to 16-bit codes.

Edit: The counter and latch could be replaced by DIP switches or binary-coded rotary switches, for setting predetermined codes rather than random ones.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top