Page 4 of 12
Posted: Fri Jul 25, 2008 7:11 am
thank you so so so much Rob!
this is so helpful, I'm trying the Max355 now but I'll be getting the 6818 in a couple of weeks and I'll give it a try.
Posted: Fri Jul 25, 2008 1:20 pm
I mean, a couple of days...
Posted: Fri Jul 25, 2008 10:52 pm
There is a slight difference between the operation of the interface of the two devices, but will not matter in practical terms since you will need to construct quite an elaborate interface/drive unit between the control (PC?) and the display. Apart from a simple clocked serial interface, you will need some way of selecting specific panels and initiating an update of the pixels after writing to the shift register.
Iâ€™m giving some thought at the moment to practical realisations for the construction of the display, especially as some of the 28 panels (4 to be exact) only drive 6 pixels, 10 have the full 200 compliment and the rest varying numbers.
Posted: Sat Jul 26, 2008 8:22 am
we were thinking on the possibility of getting 28 individual RS485 Serial lines out of the embedded processing unit. each line will connect to one Microcontroller that will send the signal to the cascaded 6818 ICs.
someone suggested me to use DMX instead of RS485, but I don't know too much about this.
it's true that the number of pixels varies dramatically from one panel to the next, one one point I was thinking on making all the panel 200 pix but that was too expensive.
Posted: Sun Jul 27, 2008 8:23 am
I was about to suggest using RS-485, as the RS-422 standard only supports 10 receivers on a single line and we need 28. RS-485 will support 32 at least, (and probably more in this particular case).
I havenâ€™t heard of DMX, but was refreshing myself on interfaces over the weekend while enjoying the good weather we have been having over the past few days. Will have to study DMX.
The scheme I currently working on would have a pare of RS-485 lines from the control PC, which daisy-chain to each of the 28 control boards and 28 individual board select lines, again using RS485 to each of the control boards. If you used a third RS485 channel from the control PC, to write to the board selector circuit, you should be able to control the complete display with 3 RS485 ports I reckon.
More to follow.
Posted: Sun Jul 27, 2008 2:27 pm
Thanks a lot for your amazing support! When I try tomorrow Monday the Prototype I'll let you know how it goes.
Thanks and have a wonderful weekend.
Posted: Sun Jul 27, 2008 11:04 pm
Had a quick look at DMX, looks like it is a RS-485 port as far as the hardware is concerned, and transmits data as a packet, repeating over and over again. Looks like it can support 512 individual receiving stations (presumably with repeaters).
Could probably be made to work in your application, but would need 'intelligence' at each receiving station. So each of the 28 display blocks would have a microcontroller to â€˜siftâ€™ out the data being sent specifically to it.
Posted: Fri Aug 01, 2008 6:58 am
I put together this diagram based on the info you gave me to assemble the prototype. What do you think?
Another idea I'm considering is using DMX instead, since it works with a multi-drop bus I'll be able to use one single data line from the controlling unit to the screen instead of 28 (as with RS485).
This will mean more work on the programming but less on the hardware.
Thanks a lot
Posted: Fri Aug 01, 2008 10:00 am
I donâ€™t see anything fundamentally wrong with this scheme. I see you have a micro controller at the receiving end which actually makes things a lot easier. You could make this work with a single pair of high speed serial lines, data and clock, the select signal would not be needed. In effect you would be creating your own version of DMX. Data would be sent as a packet:- first a device identifier to select the particular panel, followed by a packet of data for that panel. Each panel would be assigned an address (using a simple 5 bit DIP switch) and only the selected panel would clock the data packet into its shift register.
Iâ€™ve been a bit busy this week, but I managed to put the following together:-
(By the way, the schematics were done on my CAD PCB package Ranger2, which I have used for countless designs over the last 10 years or so.)
Panel circuit, page 1
Panel circuit, page 2
With this circuit, there is no â€˜intelligenceâ€™ at the receiving end so the controlling circuit must perform all the select and clocking of the shift registers itself. The clock and data daisy-chain to each controller as before, but an individual select line to each panel controls which panel receives the data. Although there would be 28 RS485 lines, they would all be driven of a single control PC port. The interface circuit would have 28 individual line drivers, and the control PC would activate only one at a time, possible using address data from a fourth port.
Or you could do this as you show in your diagram, Iâ€™m not familiar enough with the hardware you intend to use. I would imagine that there will be a commercially available PC squirreled away somewhere in the building, controlling everything.
But I like your approach better, I think it has potential to make a very simple and flexible system. Would need to think about the timing issue e.g. how fast does the system need to operate in terms of the data transmission in order to refresh the display with the desired rate. I would imagine that you BASIC STAMP would need to operate at quite a high speed in order to keep up with the data rate from the control PC. Would have to sit down an put some actual numbers to the data rate in order to see if the STAMP will cope.
Also been thinking about the practical realisation of this, i.e. the best way to build this. I see in your drawing that the triac is separate from the rest of the circuit and within the pixel model? Is this intentional?
Have you tested any of this yet, for example the triac and pixel to see if this will work as predicted, in other words the triac switches properly on each half cycle of the AC supply.
More to follow
Posted: Sat Aug 02, 2008 8:50 am
Iâ€™ve had a more detailed look at DMX and I think we can use this in more or less itâ€™s original, unaltered form. It sends a repeating packet of information with up to 512 individual receiving stations, we would only need 28. Each panel would be assigned a channel number and the data would be sent starting with channel 1 through to channel 28, then the process would repeat. We would have to work out if the data sent to each channel, I think it is 8 bits (0-255) or could also be 16 bits, could be used to decode the on-off states of the 200 pixels of that panel.
Even if it could not and we had to increase the data sent to each channel, we would still use the DMX standard hardware and connections. This would mean that there would only be one daisy-chaining cable connecting all the panels. No other connections other than power would be needed.
I need to give some more thought to this.
Posted: Sat Aug 02, 2008 1:36 pm
Thank you so much!
I just draw a Chip-Centric diagram for me to understand better the layout you sent me, is this right?
So the idea is to use SN75175 instead of the SN75176, right? So the PC generates the clock and latch signal instead of the PICs installed on each panel. We would transmit the two signals to all the panels in series using two RS485 lines.
And then there would be individual select-lines going from the Line selector device on the PC to each one of the panels. This lines will select to what panel are we sending the data at any moment, right?
So from the PC and the panels there will be thirty RS485 lines in total, one for data and one for the clock shared by all the panels, and 28 panel-select lines. Iâ€™m I right?
Thanks a lot for the info about Ranger2, seems to be a great program, Itâ€™s kind of silly hand drawing the circuits.
If we end incorporating the microcontrollers to the panels then we will use a low level microcontroller instead. The Basic Stamp uses interpreted code instead of compiled one so is not too fast (supposedly around 4000 operations/sec), thatâ€™s more than enough for what we need (at 4 FPS 800 bit/sec max), but I would rather prefer to use something faster. Iâ€™m using the stamp just for the prototypes.
I think youâ€™re right. The Triacs shouldnâ€™t be with the pixel but remain with the all the circuitry on the panel. I got fifty Z0402 Triacs yesterday so Iâ€™ll try them Monday and Iâ€™ll let you know how it goes.
If we end using DMX we wont need to use the Device Master RTS (http://www.comtrol.com/products/specifications/99456-5
) that itâ€™s actually kind of expensive ($2,000). A simple RS485 interface will do the trick. This is a easiest hardware solution (just one cable for both DATA and CS ) but harder in terms of software.
Is the local microcontroller who decide based on the incoming data if the package of data is directed to him or not, right?
Posted: Sun Aug 03, 2008 12:28 am
Yes, as far as I can see, you diagram is correct.
The purpose of the two 74132â€™s is to generate a latch pulse on the rising edge of the CS line and prevent further clocks from reaching the shift register. With the 6818 strobe input low, the outputs remain in their previous state i.e. the panel continues to display the last information sent. Data can however still be sent to the shift register, then taking strobe high allows the data in the shift register to appear at the outputs (the display updates). After a certain minimum time, about 50nS, taking the strobe low latches the data into the output latches of the 6818. Now new data can be sent to the shift register without the update process being visible on the pixel display.
I used a 75174 (4off line drivers) and 75175 (4off line receivers) as I needed at least three receivers on each panel. The 75176 contains a driver and receiver connected together to form a transceiver and so I would have had to use three of them.
But if we go for the DMX option, then one RS485 line is all we need.
And we should be able to use it as it stands, because we can assign more than one packet of information to a receiver. Assume we want to have each of the 200 pixels on a panel alternatively on and off. The binary pattern would be 10101010 for each 8 bit word, and with 200 pixels that would need 25x8 bit words. So the address of panel 1 would be channel 1. Panel 2 would be channel 26 and receive the next 25 data packets, the third panel would be channel 51 and so on.
The limit for DMX is 512 channels or data packets. So the total number of bites is 512x8 equals 4096. This system will work if the total number of pixels is less than this, which I seem to remember is around 3700?
If all 512 DMX channels are used, the refresh rate is 44Hz or once every 22.7mS which is an order of magnitude greater than we need for our display.
I will look at the timing requirements for the micro-controller on each receiver to see if they could cope with the data rate. But as the DMX data rate is ten times faster than that required, there is no reason not to slow everything down to that required. It would not be strictly DMX standard any more, but it should not really matter. And we get the added bonus in that at the lower data rate the data transfer will more reliable (fewer errors) as the DMX standard doesnâ€™t incorporate error correction. In fact, if we are not adhering to the strict DMX standard, we could introduce a 26th byte as a checksum. The receiver would only update its display if it received a valid checksum, and so would wait for the next data packet. That we would avoid any glitches from being displayed.
Posted: Sun Aug 03, 2008 3:11 am
Here is a quick sketch of the DMX timing.
The receiver (micro-controller) would need to be able to cope with events on a 4uS time scale, so would suggest that it should have an instruction cycle sufficiently short to allow 20-30 instructions within this time (~125nS cycle time). We can of course slow this down considerably, so this should not be a problem, in deed there are benefits from running at a reduced rate.
Posted: Sun Aug 03, 2008 1:59 pm
Thanks a lot!
Using the 74132's and the 75175 seems such a simple, direct and nice solution, kind of fail proof, but if we can get rid of the 28 individual lines (and the Device Master RTS) by using DMX I guess this is the best way to go, right?
It'll be much easier to carry the RS485 line from panel to panel, down the screen until the controller, kind of plug and play.
There are 3,700 pixels in total. An alternative to the Basic Stamp we could use the Propeller and SX Microcontrollers from parallax too as a receiver. They are much faster, compiled and people have worked with DMX and the Propeller before.
Do you think that the fact that we have different number of pixels on each panel could somehow mess the addressing system?
Thanks a lot again
Posted: Mon Aug 04, 2008 4:24 am
I have probably overestimated the number of instructions that are needed within the 4uS time frame. And we can slow everything down about 10 times if we had to.
It would be possible to make a â€™discreet logicâ€™ receiver, as the process of reading the data from the packet is not that difficult, but it would be much easier with a micro.
Although I cannot do programming myself, I know someone who is good with PICâ€™s (actually it my brother), and although he is always busy, this should be quite a simple and quick thing for him to write the code for a basic version PIC, to extract the data from the packet and clock it into the 6818 shift register and latch it. I will ask him if he would be available and would have some spare time.
Regarding the fact that some panels only have 6 pixels etc. Two way we could get around this that I can think of.
1) We add additional setting to the receiver so that we can tell it how many data packet is should respond to, so for example we would have a DIP switch to tell it to use only the first six bits or the first 150 or however many pixels are on the panel. Disadvantage:- makes the receiver code more complicated.
2) Receiver always assumes that it has 200 pixels. The transmitter will send 200 pixel data bits to the panel, but most of them will be â€˜blankâ€™ data. By knowing how the pixels in that panel are connected to the shift register, the data will get to the correct place in the shift register even though most of the data gets pushed out of the end of the shift register. Advantage:- Receiver code is simple and all receivers are configured the same, just the start channel position.
Just a thought about the construction of the shift register module. Some panels will contain the full 200 pixels and so need the full 7x6818 and some will only need 4 and 3 and four of the panels will only need 1. So an idea is to construct the shift register as sub-modules contain only one 6818. You would end up with about 100~115 modules, which you would populate the panels with in a quantity depending on the number of pixels on that panel. Would make the modules easy and quick to design and build (mass production techniques), but would take time to assemble together with the added disadvantage of possible reduced reliability with the increased number of interconnections.