Page 7 of 12
Posted: Tue Aug 12, 2008 6:35 pm
Yes, pixel map helps.
Get back to you on my preference. Will also have comments on panel to panel comm for either system.
Posted: Wed Aug 13, 2008 4:11 am
Irrespective of the form the PIC receiver takes, it will always count the â€˜start bitsâ€™, This is the first â€˜spaceâ€™ after the last â€˜stopâ€™ character. There is no â€˜specialâ€™ bytes sent. The â€˜mark between packetâ€™ is there mainly to allow the system to do some data processing between data packets. The PIC looks for the â€˜Breakâ€™ as a sign that the next data packet is about to start.
If we use the 200 pixels-per-panel scheme, then the DIP switch need only code for the panel number, since the PIC already knows that it will clock 200 bites (25bytes) and that the start bit will either be 1, 26, 76, 101,â€¦.676. As there are only 28 panels, only a 5 bit word is needed to code this on the DIP switch. The difficulty with the 200 pixel scheme is that if the panel doesnâ€™t contain a 200 bit shift register (it has only one 6818 fitted for example), the data for that panel must be in the last 32 clocks of the 200 clock sequence, since all the previous data will have fallen out of the end of the shift register. This complicates the bit-map-to-data stream process. Also the data needs to be sent â€˜backwardsâ€™, but this can be corrected within the hardware by connecting the pixels in â€˜reverseâ€™ order.
If the variable pixel scheme is adopted, this will not slow down the PIC in any way, but you must have more DIP switch settings. In practice, the PIC will read its DIP switches once after initialization, and thereafter it will assume that the DIP switches have not changed. To change the settings, it would be necessary to reset the PIC, i.e. turn off the power then back on. So once running, the amount of processing the PIC needs to do would be very similar between the two versions.
The coloured-in picture further up the page is correct for the simple version with all panels containing 200 pixels where there is a full set of shift registers i.e. all panels contain 7x6818â€™s. You could reduce this in the case of panel 1 for example to 1x6818, but you would need to transmit the â€˜blankâ€™ pixels first.
If you go for the complex version of the PIC, then you only have to transmit the actual pixel data. So for panel 1 will only need 1 byte of data (each bite has 8 pixel data values), of which you would only connect 6 of them to actual pixels. This scheme means only the minimum amount of data need be sent, which means refresh rates are increased. This would allow the data rate to be slowed down which should result in a more reliable system in terms of data errors as well as reducing the amount of RFI that the system generates.
So either scheme is OK by me. The only thing to be decided, if the 200pixel scheme is not used, is how to construct the panels to have a varying number of shift registers and pixel drivers. Ten of the panels will have the full compliment, so I guess the best way would be to use the same PCB for all panels, but just not populate it with all the components.
Posted: Wed Aug 13, 2008 4:37 pm
Thanks a lot!,
I forgot that the â€œmark between packets-break-mark after breakâ€
Posted: Wed Aug 13, 2008 11:38 pm
Whether it is the simple or complex version, the format of the hardware would be almost, if not identical. The only change is in what form the data is sent. In fact it doesnâ€™t matter in what order you send the data for a particular panel , just so long as you know which pixel to connect to which bit. For a receiver with less shift register location than potential pixels, the only criteria is that the actual pixel data doesnâ€™t get clocked out of the end of the shift register. Otherwise you could send the pixel data in a completely mixed up order, so long as you know the order and connected the pixels up accordingly.
I think the consensus is to use the complex scheme, so this is what I suggest we adopt.
I will draw up a spec for this for my brother to look at the coding of the PIC.
So for Dyarker, the PIC will do the following:
1) Count the number of 8 bit bytes, settable between 1 and 512. It will not count individual bits, but rather the start bit of each data block, so the first bit of pixel data must be the first bit of any data block.
2) Count the number of 8 bit bytes to which clocks are applied. Again it works in whole bytes, so you cannot split the data for two panels within one data byte. Setting range is 1-31. (edited from 1-255, since 200 pixels is only 25 bytes)
Posted: Thu Aug 14, 2008 11:30 am
so let's go with the complex system then.
Thanks a lot!, and thanks a lot to your brother too.
Posted: Fri Aug 15, 2008 9:16 am
Here is a more up-to-date schematic, and quick layout just to experiment with different layout schemes.
Posted: Fri Aug 15, 2008 6:11 pm
Sorry I haven't posted anything useful for a couple days. Been rereading the previous posts.
Questions in no particular order:
1. Have the printed circuit boards (PCB) for A6818s and TRIACs been designed yet? If not, I think you will find that 32 TRIACs and 64 connection points for will take up a lot of space. Making one big PCB for all 200 pixels on a max panel is probably not do-able.
Suggest a PCB for one A6818 and 32 TRAIACs (Not all TRAICs need be installed). A panel would have one to seven of these.
2. Does PIC on each panel do strobe when it has all bytes for it's own panel; or does it count bytes for all panels so all the PICs generate strobe at the same time? Would it make programming for the PICs easier if PC generated strobe when all bytes for all panels have been sent? This can be done in PC software by turning RTS off then back on. If CAT-5 is used for EIA-485 (formerly known as RS-485) cable from PC to display, then there are 3 spare pairs; just need one more EIA-485 transmitter at PC end, and one more receiver at display end. (These often come as 2 or 4 per IC anyway).
3. You may have said, but I missed it. How does each PIC know when it is it's turn to capture data from the serial stream? By counting all bytes and comparing the count to dip switch value times 7 times 4? Async serial is mark for idle. A "break" is a steady space for longer than a character time. A character time is 10 bit times (start + 8 data + stop). IF PC sent a 12 bit time break for each panel, followed one byte panel number, followed by data for that panel; THEN all the PICS would know that the byte following an 11 bit (or longer break) was a panel address that could be compared directly with dip switch setting. On match capture data for A6818s, else ignore data till next break. The next break would also mean stop transfering data to A6818s, that way a data line error or mis-count wouldn't carry into next panel. Again I think this would make PIC program easier to write.
Viking, just saw latest schematic/layout. That takes care of first above. But a PIC for every A6818? I thought you meant one PIC per panel (28 PICs, 5 bit address). My third above still valid, just break/address sent more times. ((exceeds number of EIA-485 receivers on buss spec???))
Posted: Fri Aug 15, 2008 10:17 pm
found 16F54 but not 16C54?????
Posted: Fri Aug 15, 2008 11:44 pm
Hello Dyarker, just a quick answer to all your question, I hope.
No, nothing has been 'designed' yet, layouts are just me playing around with different ways of placing the parts. I agree that probably trying to get all 200 pixel drivers on the single pcb will be difficult, so my idea is to have a receiver-6818 pixel driver on one board (similar to that shown above), then have individual 6818 and pixel drivers on separate plug in boards so that you can expand the system to two, three, four right up to seven. So each panel only has on receiver-PIC.
I picked the PIC part from my component library, which is a bit on the old side. We will use the modern equivalent of the 16C54 or some other device, I havenâ€™t decided yet.
The PIC counts the start-bit of each data byte until it gets to it's specified number set by one DIP switch, then it clocks in the data for the number of bytes specified by a second DIP. When all specified bytes have been clocked it generates a strobe signal to latch the data into its complement of 6818's output latches.
There is only a single twisted pair cable which connects all the panels, as in the DMX standard.
I will put together a much more detailed operating specification as soon as possible.....must fly, I'm out of the house any minute, sorry the above is in such a jumbled mess!
Posted: Sat Aug 16, 2008 5:29 am
Was working on this before your last post. Shows strobe coming from PC as I was suggesting before. Don't worry, it's an idea, can be removed.
BTW, RS-485 is a 3 wire interface; a pair for the differential signal, and a wire for common. With CAT-5 being the easiest twisted pair cable to find these days, there is no extra expense to use both wires of a spare pair for common. It makes resistance of common lower. Also, don't forget the 120 Ohm termination at the end of the RS-485 line.
using 0V/5V logic levels for data, clock and strobe from A6818 to next A6818, I suggest 6 conductor flat cable, with every other wire as common. 6 pin RJ connectors would make these connections easy to do. To control ringing and cross-talk, use termination resistors here as well. The 4.7K shown is a guesstimate, pretty sure optimum will be between 2.2K and 10K though.
Additional suggestion: Jameco has 9V regulated switching power supplies. One 100W or 150W supply should take care of 5V for whole project. Put an LM78L05 (or similar) on each PCB. Then you don't have to worry about voltage drop while distributing 5V over this LARGE project. If you want a little more "push" for the TRIAC triggers, the 9V could be used for VBB instead of 5V.
Posted: Sat Aug 16, 2008 1:48 pm
Thanks a lot guys!!
One question Rob, Why do we need a common every two pixels? I was thinking on installing the two electrodes for each pixel on opposite sides and then mount them in columns of 20 units using silicone guides with connectors on the inside, one of this guides will be the ground for all the pixels on the column, the other guide will have electrodes connected to each triac independently.
I really like the idea of designing the circuit on assembling modules, it makes all the sense, but in case is of any help I have access to a CNC milling machine that we have been using to make pretty precise circuits, here we donâ€™t have any size limitation, but we would be able to work with just one layer though.
I looks that pretty soon we will be ready to try all this for real so Iâ€™ll ask the fabricator to start producing two hundred 4.6â€
Posted: Sun Aug 17, 2008 7:29 am
No problem changing arrangement of pixel terminal blocks to remove the common terminals, the layouts were just an experiment to see how easy this was to lay out.
When you talk about CNC milling machine, are you referring to a PCB router, that is a machine that â€˜cutsâ€™ out a pattern of tracks from a blank PCB board?
Regarding power supplies, I had intended to use a separate power supply for each panel to provide galvanic isolation between the panels and thus eliminate the voltage drops associated with power distribution over long wires. Remember that you will get voltage drops on the 0V lines as well as the +V lines, so the 0V potential of the panels will all be different. Also you need to reference the AC supply to the 0V supply on each panel to allow the triacs to be driven properly, so you could have AC currents superimposed on the DC suppliesâ€¦bad news.
Each panel would need a modest size AC transformer (20VAC at ~2A) and a 5VDC at about 2A or so (mostly for the triac gate drive)
Iâ€™m attaching the latest timing diagram, PIC timing and channel assignment for the panels. I will let Dyarker decide how he wants to place the pixel data within the data bytes. So long as the pixel data is clocked into a location which has an actual shift register/pixel driver associated with it, the order doesn'tâ€™ mater. The waveform shows 512 channels, but actually we only need 474.
Posted: Sun Aug 17, 2008 12:43 pm
ThatÂ´s right, a PCB router, it can work on up to 4 by 8 feet size, plexiglass, vynil, wood, aluminum and of course PCB boards. Its deffinition is amazing, We used it for circuits with excelent results.
Posted: Sun Aug 17, 2008 6:22 pm
On timing diagram break between packets is 550uSec and mark after break is 75uSec. In Windows you don't get that kind of time control. (Bit rate for data is set by software, but is run by hardware, and will be accurate.) But length of break and the wait to send the first data byte are just software with Windows inbetween the program and the hardware clock.
Using API GETTICKCOUNT to time the break and mark after break gives a minimum of 1mSec for each.
If PC to be used is Win XP SP1, or newer, then I can use GETSYSTEMTIMES and get times with 200nSec resolution.
With either, it is possible for Windows to do task switching during the timing. That would make break or mark be a little longer. Never shorter, maybe sometimes longer. Is that OK? ((?? PIC identifies break as AT LEAST 550uSec, and identifies mark after break as AT LEAST 75uSec??))
FYI - serial ports put LSB after start bit to MSB before stop bit. (vs MSB to LSB as shown) Does not matter for the job the PIC is doing, but I've got to remember that when figuring which pins of A6818 will appear on.
Federico - Which version of Windows and Service Pack on PC that will be sending data to the display?
C U L -
Posted: Mon Aug 18, 2008 3:41 am
The break time of 550uS is the minimum time, the PIC is looking for this as a signal to reset itâ€™s channel counter. Then you get the 75uS, which again you can take as the minimum, but this is there really just as â€˜paddingâ€™ to take the signal to logic 1, because the first channel starts on the falling edge, this is when the PIC starts its timer to work out when to generate the clocks. The break-between-packets could be almost any length (in the DMX standard it is 1 second).
As stated, data order doesnâ€™t matter so long as we know what it is.
Does your CNC machine take gerber files? I assume it does. If I send you a sample layout around the 6818 for you to try cutting, you could check if your machine can achieve the necessary resolution needed around the 6818.