Model Railway - Turnout control using servos and a microcontroller

Go To Last Post
107 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

Or do you mean send the other DCC signal through wires?

 

Yes.

 

The usual way to wire a DCC layout seems to be that you run some heavy gauge 'bus' wires around the layout which you connect to the track at regular intervals to reduce voltage drop and discontinuities at things like turnouts and track joins. Some people use a self-adhesive copper tape to do this. So you do this for the track power. In addition you have a completely separate set of bus wires to send power and commands to your turnout motors.

 

A picture is worth a thousand words...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian,

 

But in that picture the only reason for feeding the DCC to the track is to actually "talk" to DCC receivers in the loco's isn't it? If you weren't doing that you presumably only need one set of wiring don't you? In fact if your only "comms" is from controller just to point switchers and nothing more you could use the "track bus" for that couldn't you? Or is the implication that you are going to be so "hooked" by the whole DCC concept that you are bound to want to talk controller->train as well?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is a piece of wooden board with a schematic of the track plan drawn with switches to activate the turnouts.

My kids had a trainset.  It worked great until one day my nephews decided to hookup both transformers to the track to make the train run faster.

That quickly blew up both transformers...

 

Anyway, isn't a wooden panel with switches a little bit old fashioned these days?

 

Old PC's are cheap, as are LCD panels.

 

I think I'd consider the user interface as running on a PC/LCD, with wither a mouse or a touch screen to trigger the switches, (points?). 

The layout would be "drawn" on the display.

The color of the switch would indicate if it was straight, turned, or in motion.

A colored blob next to it would indicate the color of the signal arms (?).

 

Add some icons along the edge for as many automated actions as you want.

 

The PC would talk to the Master microcontroller via USB and a FTDI chip connected to the uC.

 

This, of course, is a User Interface design, and only indirectly impacts how you connect / control the switches.

 

Programming a bunch of uC's for the individual switches shouldn't be a concern.

 

You develop your own control protocol, with ID, action, feedback, reset, echo test, etc.

 

You use one Arduino as a testbed master to generate the various signals.

You work to develop your code for the Tiny and the switches until it works exactly as you want.

Then you take a pile of Tinies and program them in one (boring) sitting, < 1 hr.

 

BTW, you might also consider implementing your design on two switches, first, to test / verify that your Protocol does what you want it to do, and the switches behave as expected.

Then expand on the tested and working system.

 

JC 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Anyway, isn't a wooden panel with switches a little bit old fashioned these days?

 

Indeed, and this is the way I love....  Unfortunately I do not know how, and probably do not want go through all the hassle, to make an old style DCC control panel for the trains themselves. Perhaps some day in the future but not now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Yes.

 

The usual way to wire a DCC layou....

 

Thanks for the sketch.

 

form what I saw you suggest to construct a network based on DCC instead of I2C or similar. When you were talking about DCC I thought you meant classical DCC where the signals are sent through the track. Frankly I do not know if the DCC switch/accessories control goes thorough the track or a separate bus. I always assumed DCC goes only through the track.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

I always assumed DCC goes only through the track.

 

This is how most DCC layouts are wired...

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

Quote:

 

You don't; you run two sets of DCC around your layout. It'll still be a lot less wiring than any other way.

 

 

I am confused here. What I understand is DCC signals are carried by the track. If I generate an additional set to control the turnouts how am I supposed to load it to the track with the first one used to control the trains? Or do you mean send the other DCC signal through wires?

 

Nothing confusing here. The track is just two conductors, just like two wires.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

Quote:

Well, if you go with DCC, you throw away your control panel and use the handy DCC remote that you carry around with you to run it all instead. 

 

This brings us back to position 0. I want the control board with the switches to imitate signal tower rather than a tablet or a DCC keypad. Furthermore, I wanted to use servos instead of the standard MRR components because of realism and costs.

 

I don't see any reason why using DCC means you can't use servos? The DCC just sends commands, it doesn't know how they are implemented.

 

Although it seems without DCC you only need 3 wires, gnd, power and a comms line (e.g. UART). You can daisy chain those to each turnout. The comms is broadcast to every slave from the controller. There would be minimal wiring, hardware and coding. I did a similar thing for a lighting controller.

Bob. Engineer and trainee Rocket Scientist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes of course. By the track I meant a single pair of wired, be it the track itself or the wires feeding the track.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't see any reason why using DCC means you can't use servos? The DCC just sends commands, it doesn't know how they are implemented.

 

It was not clear whether you meant ready DCC systems or only the signal.

 

Quote:

Although it seems without DCC you only need 3 wires, gnd, power and a comms line (e.g. UART). You can daisy chain those to each turnout. The comms is broadcast to every slave from the controller. There would be minimal wiring, hardware and coding. I did a similar thing for a lighting controller.

 

If we use commercial DCC station) DCC would spare these three wires, if not, we will have to have two wires (custom DCC case). As mentioned earlier, I tend to use the primitive switch-attiny/turnout. But who knows... if I can find a DCC code that I can understand I may go for my own DCC system using a master and slaves.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems like someone offers a solution already:

http://megapointscontrollers.com...

 

Not cheap, but not horribly expensive.

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like he uses Mega328. For multiple panels they are connected by I2C.

 

As I said, it doesn't take much hardware and is quite easy to build your own. You could prototype with Arduino type hardware. DCC seems to be a complication that you don't need.

Bob. Engineer and trainee Rocket Scientist.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Looks like he uses Mega328.

 

Yes, and shift registers for multiplexing, which I am trying to learn right now.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been studying the subject for a couple of days now. Probably the easiest thing is to use multiple shift registers connected in series to convert the signals from the control board to a serial input to a master MCU. Since in my case only the master need to talk to the slaves and not vice versa, I2C or whatever TWI  seems to be an overkill. I will probably create a DCC-like protocol in which the master broadcasts a series of bits forming the address of the desired slave. All slaves will read the address bits and only the respective slave will act and simultaneously switch indicator LED on the control panel. Something like that:

 

Could it be made simpler?

 

Regards

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Salaam Walid

It seems very 'expensive' to have a single wire running back to simply control an led for each servo location. That is why I suggested an RS485 based communication highway. But if you have stocks or shares in copper wire business... :-)

Cheer,

Ross

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Wed. Aug 17, 2016 - 08:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Salaam Valusoft,

 

It is indeed expensive to have a wire going back to each LED. It is also messy and contradicts the basic idea single (or two) wire communication approach.  It has one advantage though. Switching the LEDs will serve as confirmation that the respective MCU received, acknowledged and executed the command. I may connect two additional LEDs to the MCU directly under the table for this purpose, and leave the indicator LEDs to be operated directly by the switches

 

As for the RS485, I am open for all option, and learn something new each day through exchange of ideas and brain storming in this forum.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Walid

There is no reason to believe that this confirmation of command receipt cannot be achieved with the RS485 hardware layer. An addressed servo would recognise its own address, decode and perform the enclosed command and respond with a reply to the master that it 'obeyed'. The master would recognise the incoming confirmation message and light the matching led. This could all be achieved within the protocol named 'SNAP'. It is simple and sits nicely on the RS485 layer. The minim wiring would be 2 wires for the daisy-chained comma plus a.ground wire and whatever power supply is needed. POE (power over Ethernet) supplies and cabling are relatively common and affordable.

Just my 4 cents worth inclusive of taxes and inflation. :-)

PS
The S.N.A.P. can be viewed/obtained from hth.com

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Wed. Aug 17, 2016 - 10:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft

 

Quote:

There is no reason to believe that this confirmation of command receipt cannot be achieved with the RS485 hardware layer.

 

I never said that. I am still learning. Whether I will follow the advice or not, I will certainly learn about new possibilities by studying it.

Quote:

Just my 4 cents worth inclusive of taxes and inflation. :-)

You forgot to include your Cayman Islands account number to transfer the 4 cents to laugh

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:
It has one advantage though. Switching the LEDs will serve as confirmation that the respective MCU received, acknowledged and executed the command.

But as Ross says, whether you used RS485 or Ethernet or LIN or CAN or DDC or any other two-wire "network" topology the clients could report back to the server to acknowledge that they had received, understood and acted upon the command they had been sent.

 

By the same token I'm not sure I understand the purpose of the "multiplexer" in your picture above? Surely any multiplexing is a software process? You just address the messages to the right client and send them off down the wires.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson

The idea behind the multiplexer is to reduce the number of needed pins. I would connect say 10-20 maybe 30 switches to a single pin of a master MCU through an array of parallel in/serial out shift registers. The master MCU will monitor the status of the switches, and once a switch state changes, it will issue a command to the respective slave to operate a servo. At that point there are several options. Do I really need a handshake between the master and slaves? Do I really need a feedback at all? Actually a feedback would be nice to have but not essential. So if it will make life complicated better not.  If I go with the feedback option I have to search for a way of communication based two-wire, otherwise, a single wire bus will be sufficient. Alternatively I can go for optical feedback, meaning to me, rather than a software feedback between the slaves and master by using LEDs to indicate the status of the slaves. This can either be local LEDs on the underside of the layout, or wiring the slaves to the control panel as indicated in the sketch. Now you suggest to perform the feedback via software, and let the master control the LEDs. But if the number of LEDs exceeds the number of free I/O pins in the master I will have to do demultiplexing.

Or did I get your comment wrong?

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A few thoughts...

 

 

1) Use a full-duplex RS485 bus to connect your master to your slaves.

2) Use RJ45 CAT5 cables to interconnect everything - this is often a cheap way to buy cables.

3) Each Salve has a pair of RJ45s on it connected as loop-through.

4) The master sends out a command to an addressed slave and the slave responds with a status message.

5) The master can send otu status requests to addressed slaves and the slave will respond.

6) You will have 2 pairs left over in the cable, use one for 0v a,d one for your +ve.

 

 

re: multiplexing...Microchip make a good range of IO expanders which have an SPI or I2C  interface to the uC.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Small suggestion: 

 

Consider a large printed circuit board (PCB) for the back of your control panel (or two or three plugged together).  Homebrew PCBs can run up to 8.5"x11" (A4-ish) size, and with an 11x17 laser printer you could make one that size.  You only need to get the alignment perfect around the AVR, and all the traces and spacing can be coarse as gravel.

 

Various board shops have different maximum sizes, and the big ones can get expensive, even if they're quite simple.  Still, for complicated wiring that's easy to assemble and reliable, they're hard to beat.  I regularly order 15"x6" boards for US$30ish (although in quantity 100).  Your CAD package may not want to make big boards either.

 

Anyhow, have fun,

 

S.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian, Scroungre,

 

Thank you both for your suggestions.

 

Brian,

 

Currently I am trying to understand the difference between RS-485, I2C and DCC. I know they are all communications protocols, but which one is easier to implement, or the best choice for the task is still not clear to me.

 

Scroungre,

 

As for the PCB, certainly there will be a PCB for the control board, and several copies of another design(s) for the slaves. Whether home made or ordered will be decided later. Since I am not printing boards each week, I guess I will leave it for a professional. I have some experience with Eagle. Do you have suggestions/recommendation for a better package?

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:
I know they are all communications protocols

That's your first mistake. A protocol is a description of the traffic on the wires. Meanwhile RS485 and I2C (and perhaps DDC though I don't know) are definitions of the actual wire signalling - not what 0's and 1's are expected to be passed using that signalling. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

 

That's your first mistake.

 

 

Good it did not take long to be corrected.

 

Can we then call I2C and RC-485 communication schemes? I mean messages transported by either two must have a certain form "start... contents... end..."

Last Edited: Thu. Aug 18, 2016 - 11:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I could remember my days in college and the OSI 7 layer model I could probably tell you that the cabling is at level N and the comms protocols that travel across the wires is an level M - but that was decades ago and I've forgotten the actual layer numbers.

 

...

 

OK I had to Google it. So the cabling is layer 1 ("Physical") and I guess the bits on the wire are layer 2 ("Data link") though depending how deeply you look into those bits I guess you may really be talking about layer 3 ("Network") or 4 ("Transport").

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

Currently I am trying to understand the difference between RS-485, I2C and DCC. I know they are all communications protocols, but which one is easier to implement, or the best choice for the task is still not clear to me.

 

I2C = IIC = Inter-IC. It is designed for talking between ICs on the same PCB or over very short cables, typically no more than a few metres. It is also susceptible to noise and interference.

 

RS-485 is designed for long distance reliable communications in industrial environments.

 

Which one do you think you want to be using?

 

 

Once you choose how you want to electrically interconnect your master and slaves you are then free to devise you own protocol.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Which one do you think you want to be using?

 

Based on your previous comment RS-485 is definitely the better choice. The intended layout will not be huge, and will probably not exceed 6 meters (from one extreme to another). But why choose the less reliable when a more reliable option is available? Now it remains to think of a "code" for the communication, or will probably adapt DCC "language" if the slaves do not have to talk to master.

 

Regards

 

Walid

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason I had some doubt above about "DCC" and what OSI layer it represents is that it appears to be a definition of everything, covering several layers of the OSI interconnect model. Both the physical interface, low level bit signalling and so on but also the high level definition of messages passed over that wiring/signalling. As it seems to be the standardized solution for this particular activity one cannot help but wonder WHY it has been adopted as the standard method? I'll bet that over the years people have tried/used other solutions like I2C, RS485, LIN, CAN, Ethernet but have determined that it is the "best" solution for the job. (otherwise it would presumably have died off into obscurity).

 

Of course there is a cycnical view of these things that says - it's adopted because it's in the financial interests of the equipment suppliers to implement a "proprietary" system to preclude others from "muscling in" on their market. However, from what I've read it looks "open" which further suggests that it's adopted because it is the best solution for the job.

 

But I'm just looking at this from an outsider's perspective. If it were me I'd be looking to see how I could make my micros talk/receive to DCC signalling.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, you raise an important point here . I guess we have to at the development of digital control in MRR from its historical perspective. I do not claim I am an expert nor aware of all the details, but when digital control came to MRR it was first introduced by Maerklin, and it was not an open thing to anyone, but a product of this company. Others followed developing their own systems: Fleischmann FMZ, Roco with digital is cool, TRIX with seltrix, which many claim to be the best system ever developed BTW. Probably other systems were developed also on the other side of the Atlantic. Most (if not none) of these systems were not compatible, making it a big mess to run various locomotives on the same system unless you cut and solder the decoders yourself. This can be annoying in small locomotives especially to those with two left hands. I guess this was the point NMRA decided to issue a unified standard  code including wire colours, socket shapes, and of course communication,  to facilitate the use and future development of digital control in MRR. Indeed, as we can see now, almost all manufacturers except Maerklin replaced their systems with DCC compatible system.

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

 

Which one do you think you want to be using?

 

 

I have been reading about RS85. I got confused by few points:

 

1-Atmel MCUs have UART, USART, USI, or whatever. All these interfaces allows micro controllers to talk to each other.  What the benefit of the RS85? Range? Noise?

2-When a pin goes high, this means 5V. What is function of the RS85/87 chips then? inverters? Couldn't this be made by software? Signal boosters? Noise filters?

 

Regards

 

Walid

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:
1-Atmel MCUs have UART, USART, USI, or whatever. All these interfaces allows micro controllers to talk to each other. What the benefit of the RS85? Range? Noise?

RS485 cabling uses "differential signalling" - that is 2 wires to carry the info. When one wire is high (1) the other is low (2). Like USB and LVDS cabling this way makes for a far more robust signal than just one wire that is relative to Gnd. The alternative (for use with UART) is RS232 in this one the signals are made "robust" by being boosted up/down to +12V/-12V but differential is a better solution at the cost of wires. For RS232 you can carry duplex on three wires (Tx, Rx and Gnd) but in RS485 it's 2 wires per direction.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
RS485 it's 2 wires per direction
Unless using half-duplex, where a single pair carries both TX and RX data.

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks for the clarification. Some of this information was known to me but linking them together was missing. Does this mean I should simply write what I wish through the UART (or whatever I come with) to the max485 IC and it will take care about the rest to deliver the data to the other side ?

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

Ok, thanks for the clarification. Some of this information was known to me but linking them together was missing. Does this mean I should simply write what I wish through the UART (or whatever I come with) to the max485 IC and it will take care about the rest to deliver the data to the other side ?

 

Regards

 

Walid

 

No, you still need to control the driver and receiver enables on the MAX485 chip.  For example you want to enable the transmitter before you send data to the UART, and leave it enabled until the last bit of the last byte has transmitted out, then you disable the transmitter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall wrote:

No, you still need to control the driver and receiver enables on the MAX485 chip.

 

Not if he follows my suggestion back in post #72. And I'd suggest using the SN75176B instead of the MAX485.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Not if he follows my suggestion back in post #72.

 

You mean full duplex communication?

 

Quote:

And I'd suggest using the SN75176B instead of the MAX485.

 

I always thought the MAX485 is the modern RS485 converter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

You mean full duplex communication?

 

Yes. It's by far the easiest way to go.

 

 

walidkhier wrote:

I always thought the MAX485 is the modern RS485 converter.

 

It might be but it's also very expensive. I've just checked and I can buy 11 x SN75176B in a DIP package for the price of one MAX485.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apologies for the "forwardness" of this being my very first post here, but...

 

I'm very much a hack at electronics design, but I've done this exact same project recently. My circuit is a six-channel servo controller, meant to control turnouts on a model railroad (N Scale), and operated by N/O push button switches, and having LED position feedback. I did this in the Arduino environment. In fact, the reason I'm back on this forum after a long layoff is because I want to learn to rewrite the firmware native to the AVR.

 

Each channel works like this:

 

- Push button is connected to an input of a 74HC165 shift register (PISO), input is normally held low. When button is pressed, input goes high.

- on loop iteration, AVR (Arduino) reads the byte of serial output from 74HC165, and parses the first six bits. if a channel's input is high, servo movement is triggered for that channel.

- Servos are powered separately, but driven by six lines directly from the AVR. Using a servo library, two endpoints and a travel speed can be specified for each servo. (I've gotten my servos to move quite slowly and realistically).

- Servo's current position is read, and then it is sent to the opposite position. Updated end point is noted, an output byte is formed, and written to the serial input of a 74HC595 shift register (SIPO). This is to administer position feedback via LED.

- Parallel output of 74HC595 is fed to input of a 74HC04 hex inverter.

- Red and Green lines of an RGB LED are used to display turnout position feedback. 74HC04 input is also tied to LED's red anode, output is tied to LED's green anode. LED has a common cathode.

 

In operation, when a button is pressed, that channel's servo moves to the opposite endpoint. If it is to the straight position, the LED lights green, if it is to divergent position, the LED lights red.

 

Here is a demonstration video of the circuit in action:

https://www.youtube.com/watch?v=wBkgIGGErtg

 

Next steps for this circuit are:

- modify to control eight servos. I'm currently constrained to six channels due to the fact that the 74HC04 is a hex inverter. I've been looking for a "single-unit" solution to invert eight channels. I haven't found one, and will likely end up using NAND gates with inputs tied together. (two 74HC00s).

- Incorporate DCC control. There is a DCC library available for Ardiuno, but I don't know enough about this stuff to know whether it can be adapted directly into native AVR. I also wish to incorporate Loconet control - this is a networking protocol used by a specific DCC manufacturer

 

Like I said, I'm a hack, but this circuit works reliably, and as ugly as it looks, I got a tremendous amount of satisfaction developing and building it.

 

And finally, hello to everyone here! I've been a (non-active) member for a few years. Hopefully with this, I'll participate a bit more!

 

Cheers

-Joe

Last Edited: Thu. Aug 25, 2016 - 02:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome Joe.

 

Nice video. As it is sometimes said... don't be a stranger.

 

Cheers,

 

Ross

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

walidkhier wrote:

You mean full duplex communication?

 

Yes. It's by far the easiest way to go.

 

 

walidkhier wrote:

I always thought the MAX485 is the modern RS485 converter.

 

It might be but it's also very expensive. I've just checked and I can buy 11 x SN75176B in a DIP package for the price of one MAX485.

 

I have just returned from a holiday to find 4 of these little converters in my mailbox.

 

http://www.ebay.com/itm/4x-MAX48...

 

The 4 cost me less that US$3 delivered. That is like 75 cents each!

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ross - Probably like the MAX487's that ended up in some of my boards - they weren't MAX487s though....I guessed they were 75176s - I stopped short of decapping the device to find out. Fine if you're not relying on certain features of the MAX487.

 

Joe -  I've been looking for a "single-unit" solution to invert eight channels. You want a 74HC240 then.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It might be but it's also very expensive. I've just checked and I can buy 11 x SN75176B in a DIP package for the price of one MAX485.

 

This is similar to the prices I found at local suppliers. In the far east, however, the price differences are not that drastic. Bad point is, DIP chips almost disappeared there, SOP is all what I found. Soldering SOP ICs is tedious, at least for me, and requires professional PCBs (I am not going to develop so many PCBs at home). Programming SOP MCUs is equally tedious and I have not tried yet.

 

This might be a bit off topic, but I always wondered how low the prices of electronic components in China are. I understand that the labour cost there is low, but how could a non-Chinese chip cheaper in China than elsewhere? The only explanation I could guess is: because all chips are made in China.....

 

From what I could learn until now, full duplex is more comfortable when it comes to programming, but means additional bus (not a big deal) and double the RS485 converters and repeaters. I will have to wait until I understand how the project will look like and see if the elegant solution is feasible for my skills or should I go a similar way as described by  Joe.

 

Regards

 

Walid

Last Edited: Thu. Aug 25, 2016 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

 

Apologies for the "forwardness" of this being my very first post here, but...

 

 

Nice project and nice video. Thanks for sharing. I am swinging between central control, where a single master controls every thing, and local control, where each servo is controlled by a single driver. Your concept falls somewhere in between.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Joe -  I've been looking for a "single-unit" solution to invert eight channels. You want a 74HC240 then.

 

That's brilliant, thank you!

 

Cheers,

-Joe

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

walidkhier wrote:

I am swinging between central control, where a single master controls every thing, and local control...

 

Here's a tip from someone who's been doing this for a while now...pick one way and just do it. It's easy to spend months, or even years, evaluating different approaches, trying to decide which is the 'right' way. The right way is the one that gets finished.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

 

Here's a tip from someone who's been do....

 

 

 

You are absolutely right. However, before making a decision I should estimate the scope of each approach first, weight the benefits against effort then go ahead. Besides, I try to learn and apply something new in each project. Building a network would be such a nice novelty. Bear in mind two weeks ago I neither knew what UART is nor heard of RS485. After a (hopefully) short learning period about UART and its implementation with RS485, I will have a nearly complete overview of what is needed in terms of soft- and hardware to construct such a network. If it is too much for my skills, time and pocket, I may revert to simpler solutions.

 

Regards

 

Walid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

walidkhier wrote:

I am swinging between central control, where a single master controls every thing, and local control...

 

Here's a tip from someone who's been doing this for a while now...pick one way and just do it. It's easy to spend months, or even years, evaluating different approaches, trying to decide which is the 'right' way. The right way is the one that gets finished.

 

This is no lie. My circuit is for a little 3x5 N scale layout. I've been working on it for over a year, and it's only about 40% finished. This has been caused by way too much analysis paralysis.

 

Cheers,

-Joe

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now the last piece of the puzzle.... how would you assign an address to a slave MCU? I came up with the following options:

1-Software assignment: take the chip out, code the address in the software then load each slave with a unique code.

2-Hardware assignment: attach dip switch to each slave.

 

Option 1 means a little mess, especially if SMD chips are used. Perhaps a suitable ISP adapter should be added to the PCB.

Option 2 means bye bye to little chips.... at least 6 pins must be free to read the dip switch.... OR a shift register between each dip switch and slave.

 

Are there other/better options?

Regards

Walid

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1.5. keep the "address" in EEPROM ;-)

 

 (it's a bit like software DIP switches though you obviously need some kind of UI to be able to set an address) 

 

Oh and

3. something like DHCP on TCP/IP where a node "requests" an address to use (and may then keep the "lease" in EEPROM for a while) 

Pages

Topic locked