Leon, I would expect that they would all come up in the off state, but I would never count on it. Particularly not if it could cause a lot of fireworks to go off at once. I am a graduate of the paranoia school of design.
I am attending that same school right now, especially when the cost of a simple flaw in design here could be costly in more ways than just money. I already have about 100 extra key switches that I bought for this project a few years ago (I needed 2, but I ordered 50 instead, bulk is cheaper and then the company double shipped the order). Besides, the key switches are the final step in arming each of the slaves. I may put a double key switch on each of the slaves, one to power the contenuity LEDs and 1 to actually arm the relays just before the show starts. Any thoughts on that (going for my graduate in advanced paranoia, we use a lot of MS Paint)?
By the way to Cole. Most of the LEDs I saw on that wholesale site are the chip type not the bulb type, for my project, that is just fine since everything is PCB mount anyway.
kwinn said...
Leon, I would expect that they would all come up in the off state, but I would never count on it. Particularly not if it could cause a lot of fireworks to go off at once. I am a graduate of the paranoia school of design.
Keeping the Enable pins high until the outputs are configured should prevent any problems.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
chaosgk, sorry, I missed the post about the MC3486P drivers. The answer is yes, those are fine. Things have been quiet with work since Christmas, but it looks like I will be back to the 50-60+ hours a week again so I may be a little slow reading the posts and responding, but I will be doing so.
Leon, you are right, keeping the enable pins high until the outputs are configured should work, but a little extra insurance won't hurt.
chaosgk, I think the first LED's to power up are the red ones showing if any of the relays are activated, then the green ones showing igniter continuity, and finally applying +24V to the relay contacts. Whether you use one key with multiple positions or multiple keys doesn't really matter. Just make sure it's wired so the led circuits key has to be on to be able to arm the slave. This is beginning to sound like the arming sequence in a missile silo. Maybe you can rent the units out as a movie prop when not in use for fireworks.
By the way, for batteries have you considered using an 18V cordless drill battery? You do have a cordless drill...right...I mean you must...right?
How much current can the nichrome wire handle before it blows. Must be at least 5-10 mA to light a LED, but have you actually measured it on a few pieces?
chaosgk, I forgot to mention this a while back, but the reason I put two 8 pin headers on the relay board layout was that I expected each one would go to an individual RJ45 connector. I work with robots and other automation equipment and it is standard procedure to make both contacts of a relay available for connecting to external equipment. No reason to do so in your case, but it will make the software, programming, and connections slightly more complex. Would you consider going to 7 boards per slave?
I think 7 per board would be fine, can I run more boards then, or can I run slaves off the slave boards later if I need to?· I'd like to make the system upgradeable so I can add more to it later if I need to.· I have plenty of RJ45 Jacks and cable so If I need to run more then 1 cable to each board, that's fine too.
Also, the more I think about it, I will probably need a higher resolution then 1 second since music rarely falls to beats that happen on the exact second.· Will having it as Msec be a problem?
I was looking at 7 boards per slave so you would have 8 RJ45's per slave with 7 igniters per RJ45. Makes numbering easier and more consistent which leads to less chance of making mistakes. The master console could handle more than 8 slaves if you need more than 448 igniters, Easily 12-16 if desired.
Msec timing is not a problem - 268,435,456 mSeconds is 74.56 hours which is probably enough for even your longest show. Just be aware that it takes some time to send each command out so each ignition command will be at least a few mSeconds apart. Exactly how far apart will depend on how fast we can send the data over the cat5 cables.
For instance, if we can run at 10K bits per second then each slave would take 0.1 x 56 = 5.6 mSec to load, so if all 8 slaved had to be loaded that would require 44.8 mSec. Of course a slave only needs to be loaded if one or more igniters has to be fired at that particular time, so having to load all 8 would be rare.
Yes, loading all 8 slaves would be rare in less then·100 mSec, but I do see it happening in the finale. I would expect 2-4 slaves loading at the same time during the main show as a lot of the ground stuff will fire symetrically, 2-4 shots at a time. Some of the relays may fire more than one igniter anyway, I haven't quite worked that out yet.
What are your opinions on using thinner circuit boards. The 10 boards I have are the .062 thickness double sided boards. I can get the .030 boards for pretty cheap. Those should be fine for all of my distribution boards wouldn't they?
I don't see a problem with the thinner boards as long as they are well supported. They should be fairly small so that should not be a problem. As for speed, differential signals speed over twisted pairs should be more than fast enough for what you want. Also, the slaves can be pre-loaded with the data first and then all outputs updated at the same time.
I may be a bit tardy answering this week so please bear with me. I am out of town trying to cram 2 weeks of work into one.
That's cool, I have stuff going on this week anyway, I'll be ordering everything here in a few days, just getting some other projects rapped up before I start this big one.
Ok, I've got some test parts in, two TPIC chips, and a quad line receiver and driver and all 2000 led's. Holy Smile are those led's sensitive and brite. I made a simple circuit to test a few of them for surface mount soldering to a pcb because they are pinless and after I soldered them, I used my multimeter to test contenuity to make sure I didn't solder across the contacts by accident and all 4 LED's lit up, just from the minimal power coming from the meter for a ohm test.
Anyway, I'm working on a simple board to test the two tpics and 16 relays.
I looked again at your post on how each of the tpic's get addressed and correct me if i'm wrong on my logic and understanding here.
Basically, the propeller sends out a pulse to the system, that pulse is picked up by each chip and repeated with a bit added to it every time it repeats. So on the pulse, tpic 1 gets assigned bits 0-7 and it repeats the pulse to the next one, the next tpic picks up the pulse and add's it's 8 bits to it and so on. Then when the propeller sends out a command to activate bit 9, the 2nd shift register on tpic 2 turns on, the relay picks up the current, triggers the ignition, and boom?
If that is correct, does the propeller send out a different set of bits to each of the slaves, 0-63 on each and then when it sends out the ignition command, it only sends that out to the slave that is being addressed and not to the rest of the system.
I'll be posting a completed layout of my test pcb in the next few days for you to check out and tell me if I have it correct before I make the board for testing.
I've also been hard at work on my CNC machine so I don't have to drill all 7000 holes myself for this project. I'd rather draw it on the computer, send it to the machine and come back ever half hour or whatever to swap out slave boards.
Make sure you put a high enough resistor in the circuit to keep from blowing the LED. It must be very sensitive to light up from just the ohmmeter.
I am not sure if I am just misunderstanding your explanation of the PIC shift registers or you have it wrong so I will try explain it step by step.
Since we are not sure how fast we can send data over the cat 5 cable I will refer to time as a "time period" or "tp". Referring back to the controller schematic here is the sequence of events.
1 - SRCLR goes low for one tp to clear all the input shift registers.
2 - RCK goes high for one tp to shift the data (all zeroes) to the output registers.
3 - SER IN goes high (or low) to present the first bit of data to the input of the first PIC
4 - SRCP goes high for one tp to shift the bit into the first position of the shift register. All the bits (all 0's at first) will be shifted right one position
5 - 3 and 4 are repeated 8 times for each PIC in the controller. If you have 7 PIC's (56 relays/igniters) then it would be repeated 56 times. Ultimately that first data bit ends
up in the end bit of the last PIC.
6 - Steps 3, 4, and 5 are repeated for each controller that is connected to the master console.
Now all the ignition data has been shifted out to all the slaves and they are ready to be triggered at the appropriate time.
7 - RCK goes high for one tp, transferring the data that was shifted out to the output registers. The relays connected to outputs that were set to one should now close and
things should go boom.
chaosgk, in going through the drawings to answer your previous post I noticed a couple of minor mistakes which I will fix and then resend the drawings, There is also a decision that needs to be made as to how the triggering is done. Once you decide on one of the two choices outlined below I will update the drawings.
The choice to be made relates to how the PIC's are cleared and how they are clocked to fire the igniters. If you look at the master console you will see that the DS96174 line driver is split into 2 sections, each of which can be controlled separately. This allows you separate the shifting of the data from the clearing and firing of the igniters.
Option 1 is to have both sections controlled by one line. That means that each slave will be selected in turn to have data loaded and to be fired. The disadvantage is that the firing on different slaves is not truly simultaneous, although they will only be a few milliseconds apart at worst. The advantage may be lower peak currents since only one slave is firing at a time.
Option 2 is to control the clearing and firing from a separate line and have it go to all the slaves in parallel. The disadvantage is that one more control line from the prop is needed, and the peak current may be higher. The advantage is that firing is truly simultaneous, and all the slaves are cleared in one step.
Ok, that's basically how I understood it. So the propeller puts out those commands to each of the line drivers seperately so that's what keeps slave 1 from getting the same information that slave 2 has and therefore slave 2 doesn't trigger it's relays at the same time that slave 1 does.
Yes, those LED's are sensitive or my multimeter just sucks. I'll be checking with my brother on what size resistor to use for them, he understands this end of it a lot better then I do.
Can you explain how the drivers and receivers work.· I'm looking at your Master.bmp from an earlier post and looking at the connection diagram of the receiver going "WTF am I missing here?".
attached is my interpretation of it.
Here is how I read it.
1.··· 1A, 2A, 3A, 4A,· are all the data inputs coming into the driver from the propeller.
2.··· Pairs 1Y & 1Z convert the data and send it acros pair 1 to the receiver.· This happens for all Y&Z pairs.
3.··· Receiver Pairs 1B & 1Y pick up the data, convert it and put it back out on 1A again.· (this is where I got confused, how are the pins arranged on this side.)· This happens for all B&Y pairs on the receiver.·
4.··· From the Receiver, 1A goes to SER IN on tpic 1, and from SER OUT to Tpic 2 and so on,
5.··· The SRCP, RCK, and SRCLR are common to all TPIC's on the slave.
6.··· What is the E1,2 and E3,4 for on the driver?· I see that coming from P4 on the propeller.
7.··· How do I know what pin is assigned what function on the propeller, for example, P0 being SER OUT, P1 being SRCP, P2 being RCK, and P3 being SRCLR.· Is this in the software somewhere and we just tell·it·what to send where?
8.··· How many slaves can I have coming off the master board?
9.·· With SRCP, RCK, and SRCLR all being common on the slave, are these also common to all slaves, or does each slave get it's own set of those.· I would expect SCLR and RCK to be common to everything and SER IN and SRCP to be common to each slave.· that way each driver would send out two common data streams and two unique data streams to each slave.· So each slave would take two of the pins from the propeller.·
1 - Your drawing has a wiring error. Driver "Y" pins go to receiver "A" pins, "Z" to "B". The "Y" on the receiver is the output and connects to the PIC's.
2 - Correct.
3 - Almost correct. Receiver pairs 1A and 1B pick up the data and put it out on 1A. The two lines between the transmitter and receiver are differential line drivers. When one line
goes high the other one goes low and vice-versa. This makes them much more resistant to picking up noise.
4 - Almost correct. 1Y goes to SER IN ON TPIC1. SER OUT from TPIC1 goes to SER IN on TPIC2. This is how the data bits get shifted through each TPIC.
5 - Correct.
6 - E1, 2 and E3, 4 are the enables. E1,2 are controlled separately to select which slave is to receive data. E3,4 is connected to a common line for all the slaves in order
to send the SRCLR and RCK to all the slaves at once. This is one of the things I have to correct on the schematic.
7 - This would be decided in the software. The ones I chose were arbitrary and can be changed.
8 - With no additional decoding it depends on what else is connected to the prop. Easily could be 12 slaves. With additional decoding it is essentially unlimited. The real limitation
will be the current drawn by the slaves and the time it takes to download data to the slaves.
9 - All 4 signals going to the slaves are common to all the line drivers in the master. By enabling the half of the line driver that sends SER IN and SRCP independently we can
select which slave gets the data. The other half of the line driver can be controlled by another line or using a pullup resistor so SRCLR and RCK will go to all the slaves
at one time. Using only prop pins for this would require 4 lines for the slave signals, 0 or 1 line for the SRCLR and RCK enable, and 1 enable line for each slave. That
would be a maximum of 13 lines for 8 slaves or 17 lines for 12 slaves. With the addition of a single decoder chip you could have 15 slaves using 9 lines.
Ok, everything made sense except #9.· I'm at work right now so I'll have to look at it a little more when I get home tonight.·
Thanks for all of the other information, I can at least get my test slave going now that I know how the receiver is configured and what pins do what.
How do the drivers know if they are to be turned on, how are they addressed by the propeller.·
It makes sense to send out all data to the line of drivers, then the drivers in turn send the data to the recievers and tpics, and that works in my head.· I understand now how each tpic is addressed with the SER In and SER out and the shifting.· Was there some in and out on the drivers I missed that allow the same type of shifting and therefore addressing to happen? Or is the enable pin on the SER In side of the driver a seperate connection to the propeller.· If that's the case, everything makes sense.· The propeller would then control each driver independently through that enable pin for the SER IN and SRCP side?
Ok, now that I read it again a few times, it makes sense to me.
So here is how i am understanding it.
1.· Propeller sends out the commands to the E1,2 pins of the drivers telling them baiscally to either repeat the next set of signals or ignore them.
2.··Propeller then ·sends the data·out to the entire chain of drivers.
3.· All drivers that are enabled repeat the bit data to the recievers and then they convert it to data again for the tpics.
4.· Any slave boards listening at that time all assign the same bit addresses to their respective tpics.
5.· Propeller sends out the command to tell the tpics to turn on whoever is assigned to the ignition mode.
6.· Propeller sends out a command to the entire system telling all tpics to reset.
Concerns and a little confusion,·maybe not, either way it will work.
1. If for example the Prop sends out a command to enable channel 1 on tpic 1, all listening #1 tpics will be set to ignition mode on channel 1 assuming the E1,2 are set to enable on that slave driver. when the propeller sends out the ignition command, all tpics that were enabled will·switch on·at the same time.· So if Slave 1 and 2 were both enabled at the time the commands were send out, they would both trigger at the same time.·
2. To make the tpics·independantly addressable, does the propeller send out the bit data to slave 1, then send out the bit data to slave 2, then to slave 3 and all the way down the line, then after all of the tpics have been addressed on the slaves, it sends enables all of the drivers at the same time and sends out the turn on command to the entire system and any channels on the tpics that were set to high (?)·turn on.
3.· Remember, I may need relays to stay on for up to a second, I will have to test this, but I would expect 1/2 second minimum.· Am I going to be limited to a 1/2 second resolution on the timing or is ther a way to tell each tpic to stay on for 500ms then shut off.
4.· What kind of time frame are we looking at to address all of the tpics across all slaves and get them ready to fire.· 1ms or less, 100ms? I'm assuming all of the addressing is happening instantly (to you and me).
Basically you have it right. Each driver will be enabled one at a time, the data for that slave will be shifted out, and then the driver for the next slave is enabled, data shifted out, etc... Once all the data has been shifted out to all the slaves and the scheduled time for this command is reached the second pair of drivers (RCK and SRCLR) on all the driver chips is enabled, RCK goes high for 1 tp to turn on all the relays that have a 1 bit in the shift register. The relays can stay on as long as necessary, but if the unit is battery operated the shorter the better. The on time should be software controlled. The way I envision the software working is to have a list of commands that are read and executed by a small program on the prop. I am assuming 56 relays per slave and each command taking one long (64 bits) of memory on the prop. So far the commands are:
R, n R (8 bits) is relay on time command, n is the time in milliseconds (56 bits)
@, n @ (8 bits) is the time to execute this command, n is the time in milliseconds from when the program started (T0)
S, b S (8 bits) is the slave number to send the data to, b is the bit pattern (56 bits total, 0 is relay off, 1 is relay on) to send to the slave.
The hard part will be generating this table. My suggestion would be a program on the PC where you do the following:
Create a table of the relays to be turned on. One line for each time point and one for each slave. Each relay to be turned on is listed on the same line as the slave number.
Have the program start a time counter at the first key press, step to the first time (@) command, and record the elapsed time at the next key press. Repeat until all the times have been entered. This way you can listen to the music and press a key at the time you want have something fired off. You could also record the times first and then fill out the rest of the table.
THAT is AWESOME!!!! I didn't realize I could program it based on key presses for the timing of the firing.
Battery power shouldn't be a problem on the slaves, remember there are only going to be 56 slaves per board, and so at most each slave is only going to have active relays for 56 seconds total for the entire show.
Each slave will probably have it's own set of batteries for the chips themselves and a common 24v in for the relays. (suggestion?)
The hard part for me on the programming the times is going to be timing to the beat of the music on shots that arent instant. Like mortars, there will be a delay of 3-7 seconds from the ignition time to when they actually explode in the air. Each size shell should be consistent 3" should be 3 sec, 4"should be around 4 sec, 5 should be around 5 sec.
I should be able to go into the time table and subtract the time from there to offset for the lift delay right?
I'd be interested to see the calculations on the back EMF produced by 400 relays all shutting off at the same moment. Even if your well shunted on every relay, if you collapse that many fields at once and it's going to see a very, very big load on the ground.
Talk about pyrotechnics.
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.
The way it works, only·a few of the relays will be on at the same.· Also, the relays are split up to 40-60 per slave board, all independantly controlled from their own TPICs and power supplies so it shouldn't be a problem.
I've got the prop code to run a 74hc595 8 bit SIPO cascade-able shift register.
Might be a bit too late to help but???
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When your problem seems insurmountable, read the forum for a while.
Solve someone else's problems and yours won't seem so bad.
Jim, as far as I am concerned any help is welcomed and appreciated.
chaosgk, what I had in mind was programming a PC to save the timing between key presses (on the PC key board) into a table and adding the relays to be closed later. While having the prop do everything may be possible it would be a monumental task. I prefer to do things as simply as possible with the tools available, and to me the PC is the best tool for creating the program and downloading it to the prop along with the software to execute it.
To be more specific about creating the "firing program" what I had in mind was the following:
Start the PC program to record elapsed time.
Start the music you want to use for the fireworks and press the "s" key to set the start time (T0) (records current time or 0)
Press a key for each time you want to set off one or more fireworks (maybe a different key for each type or group of fireworks). (records current time or elapsed time)
At the end press a key to save the data and terminate the program
You end up with a text file that looks like the following:
@ 00.000 s
@ 13.000 a
@ 17.500 b
@ 31.000 c
etc.
You would then use a text editor to add the slave and relays to fire after each time:
@. 00.000 s
@, 13.000 a ' at 13.000 seconds
s 1,1,9,53 'slave 1, relays 1, 9, 53 turn on
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
By the way to Cole. Most of the LEDs I saw on that wholesale site are the chip type not the bulb type, for my project, that is just fine since everything is PCB mount anyway.
Keeping the Enable pins high until the outputs are configured should prevent any problems.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
chaosgk, I think the first LED's to power up are the red ones showing if any of the relays are activated, then the green ones showing igniter continuity, and finally applying +24V to the relay contacts. Whether you use one key with multiple positions or multiple keys doesn't really matter. Just make sure it's wired so the led circuits key has to be on to be able to arm the slave. This is beginning to sound like the arming sequence in a missile silo. Maybe you can rent the units out as a movie prop when not in use for fireworks.
By the way, for batteries have you considered using an 18V cordless drill battery? You do have a cordless drill...right...I mean you must...right?
How much current can the nichrome wire handle before it blows. Must be at least 5-10 mA to light a LED, but have you actually measured it on a few pieces?
Post Edited (kwinn) : 2/7/2009 5:27:08 AM GMT
Also, the more I think about it, I will probably need a higher resolution then 1 second since music rarely falls to beats that happen on the exact second.· Will having it as Msec be a problem?
Post Edited (chaosgk) : 2/9/2009 4:07:10 PM GMT
Msec timing is not a problem - 268,435,456 mSeconds is 74.56 hours which is probably enough for even your longest show. Just be aware that it takes some time to send each command out so each ignition command will be at least a few mSeconds apart. Exactly how far apart will depend on how fast we can send the data over the cat5 cables.
For instance, if we can run at 10K bits per second then each slave would take 0.1 x 56 = 5.6 mSec to load, so if all 8 slaved had to be loaded that would require 44.8 mSec. Of course a slave only needs to be loaded if one or more igniters has to be fired at that particular time, so having to load all 8 would be rare.
What are your opinions on using thinner circuit boards. The 10 boards I have are the .062 thickness double sided boards. I can get the .030 boards for pretty cheap. Those should be fine for all of my distribution boards wouldn't they?
Post Edited (chaosgk) : 2/10/2009 10:23:30 PM GMT
I may be a bit tardy answering this week so please bear with me. I am out of town trying to cram 2 weeks of work into one.
·
Anyway, I'm working on a simple board to test the two tpics and 16 relays.
I looked again at your post on how each of the tpic's get addressed and correct me if i'm wrong on my logic and understanding here.
Basically, the propeller sends out a pulse to the system, that pulse is picked up by each chip and repeated with a bit added to it every time it repeats. So on the pulse, tpic 1 gets assigned bits 0-7 and it repeats the pulse to the next one, the next tpic picks up the pulse and add's it's 8 bits to it and so on. Then when the propeller sends out a command to activate bit 9, the 2nd shift register on tpic 2 turns on, the relay picks up the current, triggers the ignition, and boom?
If that is correct, does the propeller send out a different set of bits to each of the slaves, 0-63 on each and then when it sends out the ignition command, it only sends that out to the slave that is being addressed and not to the rest of the system.
I'll be posting a completed layout of my test pcb in the next few days for you to check out and tell me if I have it correct before I make the board for testing.
I've also been hard at work on my CNC machine so I don't have to drill all 7000 holes myself for this project. I'd rather draw it on the computer, send it to the machine and come back ever half hour or whatever to swap out slave boards.
I am not sure if I am just misunderstanding your explanation of the PIC shift registers or you have it wrong so I will try explain it step by step.
Since we are not sure how fast we can send data over the cat 5 cable I will refer to time as a "time period" or "tp". Referring back to the controller schematic here is the sequence of events.
1 - SRCLR goes low for one tp to clear all the input shift registers.
2 - RCK goes high for one tp to shift the data (all zeroes) to the output registers.
3 - SER IN goes high (or low) to present the first bit of data to the input of the first PIC
4 - SRCP goes high for one tp to shift the bit into the first position of the shift register. All the bits (all 0's at first) will be shifted right one position
5 - 3 and 4 are repeated 8 times for each PIC in the controller. If you have 7 PIC's (56 relays/igniters) then it would be repeated 56 times. Ultimately that first data bit ends
up in the end bit of the last PIC.
6 - Steps 3, 4, and 5 are repeated for each controller that is connected to the master console.
Now all the ignition data has been shifted out to all the slaves and they are ready to be triggered at the appropriate time.
7 - RCK goes high for one tp, transferring the data that was shifted out to the output registers. The relays connected to outputs that were set to one should now close and
things should go boom.
The choice to be made relates to how the PIC's are cleared and how they are clocked to fire the igniters. If you look at the master console you will see that the DS96174 line driver is split into 2 sections, each of which can be controlled separately. This allows you separate the shifting of the data from the clearing and firing of the igniters.
Option 1 is to have both sections controlled by one line. That means that each slave will be selected in turn to have data loaded and to be fired. The disadvantage is that the firing on different slaves is not truly simultaneous, although they will only be a few milliseconds apart at worst. The advantage may be lower peak currents since only one slave is firing at a time.
Option 2 is to control the clearing and firing from a separate line and have it go to all the slaves in parallel. The disadvantage is that one more control line from the prop is needed, and the peak current may be higher. The advantage is that firing is truly simultaneous, and all the slaves are cleared in one step.
Let me know what you prefer.
Yes, those LED's are sensitive or my multimeter just sucks. I'll be checking with my brother on what size resistor to use for them, he understands this end of it a lot better then I do.
Can you explain how the drivers and receivers work.· I'm looking at your Master.bmp from an earlier post and looking at the connection diagram of the receiver going "WTF am I missing here?".
attached is my interpretation of it.
Here is how I read it.
1.··· 1A, 2A, 3A, 4A,· are all the data inputs coming into the driver from the propeller.
2.··· Pairs 1Y & 1Z convert the data and send it acros pair 1 to the receiver.· This happens for all Y&Z pairs.
3.··· Receiver Pairs 1B & 1Y pick up the data, convert it and put it back out on 1A again.· (this is where I got confused, how are the pins arranged on this side.)· This happens for all B&Y pairs on the receiver.·
4.··· From the Receiver, 1A goes to SER IN on tpic 1, and from SER OUT to Tpic 2 and so on,
5.··· The SRCP, RCK, and SRCLR are common to all TPIC's on the slave.
6.··· What is the E1,2 and E3,4 for on the driver?· I see that coming from P4 on the propeller.
7.··· How do I know what pin is assigned what function on the propeller, for example, P0 being SER OUT, P1 being SRCP, P2 being RCK, and P3 being SRCLR.· Is this in the software somewhere and we just tell·it·what to send where?
8.··· How many slaves can I have coming off the master board?
9.·· With SRCP, RCK, and SRCLR all being common on the slave, are these also common to all slaves, or does each slave get it's own set of those.· I would expect SCLR and RCK to be common to everything and SER IN and SRCP to be common to each slave.· that way each driver would send out two common data streams and two unique data streams to each slave.· So each slave would take two of the pins from the propeller.·
2 - Correct.
3 - Almost correct. Receiver pairs 1A and 1B pick up the data and put it out on 1A. The two lines between the transmitter and receiver are differential line drivers. When one line
goes high the other one goes low and vice-versa. This makes them much more resistant to picking up noise.
4 - Almost correct. 1Y goes to SER IN ON TPIC1. SER OUT from TPIC1 goes to SER IN on TPIC2. This is how the data bits get shifted through each TPIC.
5 - Correct.
6 - E1, 2 and E3, 4 are the enables. E1,2 are controlled separately to select which slave is to receive data. E3,4 is connected to a common line for all the slaves in order
to send the SRCLR and RCK to all the slaves at once. This is one of the things I have to correct on the schematic.
7 - This would be decided in the software. The ones I chose were arbitrary and can be changed.
8 - With no additional decoding it depends on what else is connected to the prop. Easily could be 12 slaves. With additional decoding it is essentially unlimited. The real limitation
will be the current drawn by the slaves and the time it takes to download data to the slaves.
9 - All 4 signals going to the slaves are common to all the line drivers in the master. By enabling the half of the line driver that sends SER IN and SRCP independently we can
select which slave gets the data. The other half of the line driver can be controlled by another line or using a pullup resistor so SRCLR and RCK will go to all the slaves
at one time. Using only prop pins for this would require 4 lines for the slave signals, 0 or 1 line for the SRCLR and RCK enable, and 1 enable line for each slave. That
would be a maximum of 13 lines for 8 slaves or 17 lines for 12 slaves. With the addition of a single decoder chip you could have 15 slaves using 9 lines.
Thanks for all of the other information, I can at least get my test slave going now that I know how the receiver is configured and what pins do what.
How do the drivers know if they are to be turned on, how are they addressed by the propeller.·
It makes sense to send out all data to the line of drivers, then the drivers in turn send the data to the recievers and tpics, and that works in my head.· I understand now how each tpic is addressed with the SER In and SER out and the shifting.· Was there some in and out on the drivers I missed that allow the same type of shifting and therefore addressing to happen? Or is the enable pin on the SER In side of the driver a seperate connection to the propeller.· If that's the case, everything makes sense.· The propeller would then control each driver independently through that enable pin for the SER IN and SRCP side?
Post Edited (chaosgk) : 3/11/2009 5:09:04 PM GMT
So here is how i am understanding it.
1.· Propeller sends out the commands to the E1,2 pins of the drivers telling them baiscally to either repeat the next set of signals or ignore them.
2.··Propeller then ·sends the data·out to the entire chain of drivers.
3.· All drivers that are enabled repeat the bit data to the recievers and then they convert it to data again for the tpics.
4.· Any slave boards listening at that time all assign the same bit addresses to their respective tpics.
5.· Propeller sends out the command to tell the tpics to turn on whoever is assigned to the ignition mode.
6.· Propeller sends out a command to the entire system telling all tpics to reset.
Concerns and a little confusion,·maybe not, either way it will work.
1. If for example the Prop sends out a command to enable channel 1 on tpic 1, all listening #1 tpics will be set to ignition mode on channel 1 assuming the E1,2 are set to enable on that slave driver. when the propeller sends out the ignition command, all tpics that were enabled will·switch on·at the same time.· So if Slave 1 and 2 were both enabled at the time the commands were send out, they would both trigger at the same time.·
2. To make the tpics·independantly addressable, does the propeller send out the bit data to slave 1, then send out the bit data to slave 2, then to slave 3 and all the way down the line, then after all of the tpics have been addressed on the slaves, it sends enables all of the drivers at the same time and sends out the turn on command to the entire system and any channels on the tpics that were set to high (?)·turn on.
3.· Remember, I may need relays to stay on for up to a second, I will have to test this, but I would expect 1/2 second minimum.· Am I going to be limited to a 1/2 second resolution on the timing or is ther a way to tell each tpic to stay on for 500ms then shut off.
4.· What kind of time frame are we looking at to address all of the tpics across all slaves and get them ready to fire.· 1ms or less, 100ms? I'm assuming all of the addressing is happening instantly (to you and me).
·
R, n R (8 bits) is relay on time command, n is the time in milliseconds (56 bits)
@, n @ (8 bits) is the time to execute this command, n is the time in milliseconds from when the program started (T0)
S, b S (8 bits) is the slave number to send the data to, b is the bit pattern (56 bits total, 0 is relay off, 1 is relay on) to send to the slave.
The hard part will be generating this table. My suggestion would be a program on the PC where you do the following:
Create a table of the relays to be turned on. One line for each time point and one for each slave. Each relay to be turned on is listed on the same line as the slave number.
Have the program start a time counter at the first key press, step to the first time (@) command, and record the elapsed time at the next key press. Repeat until all the times have been entered. This way you can listen to the music and press a key at the time you want have something fired off. You could also record the times first and then fill out the rest of the table.
Post Edited (kwinn) : 3/15/2009 5:03:27 AM GMT
Battery power shouldn't be a problem on the slaves, remember there are only going to be 56 slaves per board, and so at most each slave is only going to have active relays for 56 seconds total for the entire show.
Each slave will probably have it's own set of batteries for the chips themselves and a common 24v in for the relays. (suggestion?)
The hard part for me on the programming the times is going to be timing to the beat of the music on shots that arent instant. Like mortars, there will be a delay of 3-7 seconds from the ignition time to when they actually explode in the air. Each size shell should be consistent 3" should be 3 sec, 4"should be around 4 sec, 5 should be around 5 sec.
I should be able to go into the time table and subtract the time from there to offset for the lift delay right?
Talk about pyrotechnics.
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent, only $1.
Send cash and signature to CannibalRobotics.
Might be a bit too late to help but???
Jim-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When your problem seems insurmountable, read the forum for a while.
Solve someone else's problems and yours won't seem so bad.
chaosgk, what I had in mind was programming a PC to save the timing between key presses (on the PC key board) into a table and adding the relays to be closed later. While having the prop do everything may be possible it would be a monumental task. I prefer to do things as simply as possible with the tools available, and to me the PC is the best tool for creating the program and downloading it to the prop along with the software to execute it.
Start the PC program to record elapsed time.
Start the music you want to use for the fireworks and press the "s" key to set the start time (T0) (records current time or 0)
Press a key for each time you want to set off one or more fireworks (maybe a different key for each type or group of fireworks). (records current time or elapsed time)
At the end press a key to save the data and terminate the program
You end up with a text file that looks like the following:
@ 00.000 s
@ 13.000 a
@ 17.500 b
@ 31.000 c
etc.
You would then use a text editor to add the slave and relays to fire after each time:
@. 00.000 s
@, 13.000 a ' at 13.000 seconds
s 1,1,9,53 'slave 1, relays 1, 9, 53 turn on
@, 17.500 b
s 7,13
@, 31.000 c
etc.