I am working on a concept that would take input pulses from the GPO sequencer and result in certain behavior on a daughter board.
But I am concerned about the precision of the pulse width that the MO generates.
If I tell the Daughter board to watch for 2ms pulses, are they always going to be 2ms +/- 5%? Or more like +/-10%? What tolerance would you recommend I prepare for?
This is an example of what I would want:
1X2ms pulse= routine 1 runs
2X2ms pulse (2ms gap)= routine 2 runs
3X2ms pulse (2ms gaps)= routine 3 runs
and so on.
Using the GPO sequencer on certain events to set a more complicated lighting routine in action.
now, if the logic is counting 2ms pulses, but the MO is "sloppy" and putting out 2.8ms pulses...I could get errors in behavior as a result.
Someone else is making the PCB for me, but I am concerned that using the MO output to trigger a precise behavior could have unpredictable results.
I think if you could say it's +/- 10% or better, I am fine, and will move forward. Much Thanks.
GPO pulse timing
Hello Dgephri,
Thank you for posting on the forum.
Can you please give more details about your project? The pulse that you create from the GPO, does this entail your host sending a GPO on command and then a GPO off command?
I am not quite sure if I understand your GPO situation, but this is what I can say for now:
If the module is not busy receiving other data from the host, be it data for displaying or commands for configuring, then the module should be able to respond quite quickly with the GPO commands. The pulse width depends on the commands as sent by the host.
Thank you for posting on the forum.
Can you please give more details about your project? The pulse that you create from the GPO, does this entail your host sending a GPO on command and then a GPO off command?
I am not quite sure if I understand your GPO situation, but this is what I can say for now:
If the module is not busy receiving other data from the host, be it data for displaying or commands for configuring, then the module should be able to respond quite quickly with the GPO commands. The pulse width depends on the commands as sent by the host.
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital
Say, from LCDC, I have an event: When CPU Temp >70, then play GPO sequence #1, play one time.
In that GPO sequence, I tell the MO to turn GPO #4 On for 2ms, Off for 2ms, then On for 2ms.
Just that.
Now, if my daughterboard is designed to look for, and count, 2ms pulses, it's pretty important that there NOT be 3ms pulses.
So when LCDC sends that to the MO, is the MO counting 2ms, or is LCDC counting 2ms?
This way, the daughterboard only has to watch one GPO 5V line for pulses. I can send multiple actions by programming GPO sequences on say, GPO 4 only.
I may need to contact LCDC as well, but I figured to start hardware and then go see what the GPO sequencer itself is doing.
In that GPO sequence, I tell the MO to turn GPO #4 On for 2ms, Off for 2ms, then On for 2ms.
Just that.
Now, if my daughterboard is designed to look for, and count, 2ms pulses, it's pretty important that there NOT be 3ms pulses.
So when LCDC sends that to the MO, is the MO counting 2ms, or is LCDC counting 2ms?
This way, the daughterboard only has to watch one GPO 5V line for pulses. I can send multiple actions by programming GPO sequences on say, GPO 4 only.
I may need to contact LCDC as well, but I figured to start hardware and then go see what the GPO sequencer itself is doing.
Hello Dgephri,
The counting is done by LCDC. Make sure that LCDC outputs the proper command at the right interval. And yes, it'll be good to contact them as well.
Please keep me posted with your project, it's good to hear about systems with MO displays.
I hope that you get answers soon; I am still here to help if I can.
Best Regards,
The counting is done by LCDC. Make sure that LCDC outputs the proper command at the right interval. And yes, it'll be good to contact them as well.
Please keep me posted with your project, it's good to hear about systems with MO displays.
I hope that you get answers soon; I am still here to help if I can.
Best Regards,
Raquel Malinis
Design and Development
Matrix Orbital
Design and Development
Matrix Orbital
Now 3X 1st place at PDXLANs.-
Paradigm
- Matrix Orbital
- Posts: 255
- Joined: Thu Sep 13, 2001 6:00 pm
- Location: Calgary, Alberta, Canada
Send us pictures of your stuff, we'll be more than happy to post them here. We always love to see what people are actually doing with our displays.
I'd love to make some suggestions, but I'm having a difficult time understanding your exact intensions. You seem to be counting pulses to determine how many times to run a sequence. If there is only one sequence and you are just running it multiple times, then the easier method would be to simply run your sequence for every low to high transition that the GPO makes. Then pulse width doesn't matter. Just keep track of how many low to high transitions occur and do that number.
If you are running different sequences based on how many pulses you are sending, then I would suggest a more complex protocol, I won't get into this unless you really want to.
Finally I would suggest that you maybe think about connecting your daughterboard directly to the PC via another serial port.
I'm really talking off the cuff about your situation. I'm still unclear about
Are you designing this daughterboard from scractch or is it an existing product?
What are these "sequences" you are running?
Are there more than one different sequences?
Either way, post some pictures in the gallery and let us see what you are doing.
I'd love to make some suggestions, but I'm having a difficult time understanding your exact intensions. You seem to be counting pulses to determine how many times to run a sequence. If there is only one sequence and you are just running it multiple times, then the easier method would be to simply run your sequence for every low to high transition that the GPO makes. Then pulse width doesn't matter. Just keep track of how many low to high transitions occur and do that number.
If you are running different sequences based on how many pulses you are sending, then I would suggest a more complex protocol, I won't get into this unless you really want to.
Finally I would suggest that you maybe think about connecting your daughterboard directly to the PC via another serial port.
I'm really talking off the cuff about your situation. I'm still unclear about
Are you designing this daughterboard from scractch or is it an existing product?
What are these "sequences" you are running?
Are there more than one different sequences?
Either way, post some pictures in the gallery and let us see what you are doing.
James McTavish, P.Eng
Director of Engineering
Matrix Orbital
Director of Engineering
Matrix Orbital
each 10 LED sequence is run repeatedly until another signal is received.
The daughterboard PCB designer was thinking that counting the number of pulses would be fairly straightforward in his design.
each pulse count is a different sequence
hard to describe, but I could only achieve the 10LED patterns if the MO actually had 10 low power GPOs.
Waiting on some info from LCDC forums as well. Some of the design I don't want to reveal until it's ready and tested.
Thanks for the direction, I will check with my PCB designer to see his thoughts on this.
The daughterboard PCB designer was thinking that counting the number of pulses would be fairly straightforward in his design.
each pulse count is a different sequence
hard to describe, but I could only achieve the 10LED patterns if the MO actually had 10 low power GPOs.
Waiting on some info from LCDC forums as well. Some of the design I don't want to reveal until it's ready and tested.
Thanks for the direction, I will check with my PCB designer to see his thoughts on this.
-
Paradigm
- Matrix Orbital
- Posts: 255
- Joined: Thu Sep 13, 2001 6:00 pm
- Location: Calgary, Alberta, Canada
Ok, there are two ways to proceed from here:
1) A more complex protocol, for example:
A pulse over 100ms is considered a "reset" pulse
A pulse over 50ms is considered an "end"
A pulse under 50ms is considered a count.
You send a reset, followed by the number of pulses under 50ms you want, followed by the pulse of between 50 and 100ms. These timings should be easier to meet. If you have more pins, so something like:
pin 1 - start
pin 2 - pulse
pin 3 - go
Then you don't have to time the pulses, just look at the low to high transitions. So the protocol would be: Start (reset the counter), count each low to high pulse on the pulse line, then when you get a go you execute the sequence number dictated by the current count.
2) Move over to another serial port. It's obviousl that you are going to have some intelligence behind this peripheral. If I may reccommend the ATMega series from Atmel is a fantastic micro-controller available from Digikey. We actually use the ATMega8535 for our displays. It has upto 32 I/O pins, and it comes with a hardware serial port. Attach it to a 232 chip and you can connect it directly to your computer. Believe it or not, this would actually be easier.
I've seen these types of plans before. We have a customer that until recently was trying to do something even a lot more elaborate than you were planning. It's easy to get caught up in trying to make the display do something it *should* be capable of, but wasn't designed for. Trust me, I know. But at the end of the day, you can hammer in a nail with a wrench, but it is still easier to use a hammer. Only use something else if there is no way that you can do it "the right way".
1) A more complex protocol, for example:
A pulse over 100ms is considered a "reset" pulse
A pulse over 50ms is considered an "end"
A pulse under 50ms is considered a count.
You send a reset, followed by the number of pulses under 50ms you want, followed by the pulse of between 50 and 100ms. These timings should be easier to meet. If you have more pins, so something like:
pin 1 - start
pin 2 - pulse
pin 3 - go
Then you don't have to time the pulses, just look at the low to high transitions. So the protocol would be: Start (reset the counter), count each low to high pulse on the pulse line, then when you get a go you execute the sequence number dictated by the current count.
2) Move over to another serial port. It's obviousl that you are going to have some intelligence behind this peripheral. If I may reccommend the ATMega series from Atmel is a fantastic micro-controller available from Digikey. We actually use the ATMega8535 for our displays. It has upto 32 I/O pins, and it comes with a hardware serial port. Attach it to a 232 chip and you can connect it directly to your computer. Believe it or not, this would actually be easier.
I've seen these types of plans before. We have a customer that until recently was trying to do something even a lot more elaborate than you were planning. It's easy to get caught up in trying to make the display do something it *should* be capable of, but wasn't designed for. Trust me, I know. But at the end of the day, you can hammer in a nail with a wrench, but it is still easier to use a hammer. Only use something else if there is no way that you can do it "the right way".
James McTavish, P.Eng
Director of Engineering
Matrix Orbital
Director of Engineering
Matrix Orbital
I agree entirely, which is why I wanted some info before I went forward.
The guy designing the PCB for me really has a minimalist approach and the programming does most of the work for us.
Unfortunately, I don't have a spare MO to send him for testing, but I think it will work out well.
His programming is set up to count Hi/Low pulses at approx 2ms spacing.
1 pulse=10LED sequence #1-runs continuous until another pulse is received.
2 pulse=sequence 2
etc.
10 pulses turns the unit off, and a certain number of pulses dims the LEDs on the PCB.
I thought using the other 5V GPOs in concert like you suggest might make his programming easier, but he felt confident he could make it all work. I expect to recieve the PCB in a week or so and I can test actual behavior at that point.
The guy designing the PCB for me really has a minimalist approach and the programming does most of the work for us.
Unfortunately, I don't have a spare MO to send him for testing, but I think it will work out well.
His programming is set up to count Hi/Low pulses at approx 2ms spacing.
1 pulse=10LED sequence #1-runs continuous until another pulse is received.
2 pulse=sequence 2
etc.
10 pulses turns the unit off, and a certain number of pulses dims the LEDs on the PCB.
I thought using the other 5V GPOs in concert like you suggest might make his programming easier, but he felt confident he could make it all work. I expect to recieve the PCB in a week or so and I can test actual behavior at that point.