Networkable Fast Clock Frequently Asked Questions (FAQ)

Networkable Fast Clock Frequently Asked Questions (FAQ)
Hardware Questions

#1 - How should the clocks be wired together?

Slave unit are connected to a master via two sets of wires - one carrying power, the other carrying data. My recommendation is that twisted pair be used at least for the data connection - this will maximize the network's immunity to noise. Personally, I've been using 26AWG Category 5e network cable to connect mine for testing for both power and data. Be aware this small wire has high resistance, and consequently won't really carry a great deal of current for powering remote nodes. Each node will consume about 90-120 milliamps of current depending on how many segments are on. I'd suggest if you want to use the Cat 5e for powering nodes as well, use the three remaining pairs of wires in parallel to run power.

Both are polarity sensitive, though both are resistant to reversed connections as long as the actual design matches my schematic (namely the reverse-polarity power diode on the +Vin line and the two 27-ohm input resistors on the data lines.) Otherwise, all bets are off unless you know what you're doing and implemented your own protection scheme. The data lines, if reversed, won't damage anything, but it won't work either. In addition, the bus is passively biased such that if the network wires are broken or disconnected somewhere along the line, the slaves won't go nuts.

#2 - What should I use for a power supply?

While the devices are powered off +5VDC, I've decided that in a normal layout environment it makes much more sense to transmit at a higher voltage and regulate down locally. Nominally I picked +9VDC, since the half watt being dissipated by each 7805 regulator was low enough not to require a heatsink. Higher distribution voltages would cause additional voltage drop, and thus additional power to be burned off as heat in each regulator - thus requiring the builder to add a heatsink or move to a switching converter design (and if you don't know what a switching converter is, you really shouldn't try to build one). This also means that resistive loss can only really amount to a volt or two between stations, so I'd recommend you use decent-sized wire to move power between boards (the three remaining pairs in a 26AWG Cat5 cable should be fine, otherwise I'd recommend 18-20AWG wires). If you start experiencing problems, I suggest measuring the voltage at each node to see if it's adequate (7.5V should be adequate).

Whatever power supply you use, be sure it can supply enough current. Typically, I've found that each of these nodes will consume 90-120mA, depending on how many segments are turned on. Figure 140mA per clock for safety and you should be fine. My personal, readily available power supply is the Radio Shack #273-1770, 9V 800mA wall-wart.

If you choose not to bus power around but use some other existing built-in layout power network (or separate transformers at each clock, for whatever bizarre reason), make sure that all the clock boards share a common ground - otherwise the RS-485 data network may do very odd things, right up to killing itself due to voltage differentials.

#3 - Why RS-485 instead of just straight serial?

Data is sent over a highly noise-immune RS485 bus, which involves differential signalling. While it does add an extra part to each board (the MAX483/487 transceiver), it does help protect the devices from static discharge into the bus wires, inductive spikes and coupled noise, and human wiring errors. It's not perfect, but it should help significantly. Due to the relatively low baud rates at this time, there shouldn't be any concerns with network layout (star versus linear chain arrangements, etc.), and the small level of signal reflections that do occur should be dealt with effectively by the terminating network built into the devices.

If you want, the 485 transceivers can be eliminated, but I really, really don't recommend it. In this case, just tie the TX pin from the master to the RX pins on the slaves.

#4 - Do I have to include the real time clock (and DS1306)?

Certainly not. The real-time clock was included in the design because it was a requested feature. Since DS1306s are a little expensive and something that not every hobbyist has in his/her parts bin, the firmware is completely capable of running without it. If you do not want real-time functionality, or are content to set the fast clock to 1:1 and reset the time every time you want it, you can omit the DS1306 and associated parts. Just tie pin 23 of the PIC to ground and leave the rest of the lines to the DS1306 floating. REAL mode will still display as an option, but you'll get a time of 00:00 consistently that will never update.

#5 - There's no v2 slave clock firmware. How do I build one?

For right now, just use the old 1.1 firmware and set the unit up as a slave (probably by poking the right switch pins with a wire, since slave clocks typically wouldn't have control buttons - note you'll still need to pull the switch wires to the appropriate rails to prevent noise from being interpreted as keypresses). The wire protocol has not changed between them, and consequently I haven't gotten around to v2 slave firmware.

Software Questions

#1 - How do I program the PIC?

Well, you need a PIC programmer or somebody to do it for you. Since these are flash parts, they can be programmed with many of the free designs found on the net. On the downside, it means you have to build even more hardware. On the upside, they're usually fairly simple. If you just want the programmed processor, drop me an email. I'll send you one for the price of the part plus nominal shipping. The PICs are generally about $8, and figure a buck or two to ship it here in the US (no matter how many you order, one shipping fee for the whole thing).

  Questions? Email Nathan Holmes
© NDHolmes, but freely usable under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.
Last modified on January 10, 2006, at 08:10 PM
Edit Page | Page History