Store › Forums › Video Experimenter › Bugs/Problems › Closed Captioning and IR Transmitter?
- This topic has 3 replies, 2 voices, and was last updated 13 years, 3 months ago by Michael.
-
AuthorPosts
-
August 8, 2011 at 4:36 pm #536MattRichardsonMember
I’m working on a project that combines the Video Experimenter Shield’s closed captioning example and Adafruit’s IR code transmitting example so that when a certain keyword comes over closed captioning, the MUTE signal is sent to the TV.
I’ve modified the closed captioning example so that an alert is sent via serial when one of five keywords is mentioned. I’ve modified Adafruit’s example so that it sends the mute IR signal to my TV. Both sketches work independently. However, when I try to combine the examples, I get the serial alert that a keyword is mentioned, but the TV isn’t muting, leading me to believe that the timing on the IR pulses is off. Since my understanding of C code is limited to basic procedural programming, I’m wondering if there’s something going on the the background of the closed captioning example that’s throwing the timing off in the transmission of the proper IR signal. For example, take a look at the pulseIR() function in the IR code, which sends pulses for the duration of n microseconds at 38kHz (as required by many IR receivers):
void pulseIR(long microsecs) {
// we'll count down from the number of microseconds we are told to wait
cli(); // this turns off any background interrupts
while (microsecs > 0) {
// 38 kHz is about 13 microseconds high and 13 microseconds low
digitalWrite(IRledPin, HIGH); // this takes about 3 microseconds to happen
delayMicroseconds(10); // hang out for 10 microseconds
digitalWrite(IRledPin, LOW); // this also takes about 3 microseconds
delayMicroseconds(10); // hang out for 10 microseconds
// so 26 microseconds altogether
microsecs -= 26;
}
sei(); // this turns them back on
}Am I on the right track here? Would adjusting the timing on this help me? Or should I be troubleshooting elsewhere? I’m not expecting anyone to pore over my entire sketch, but I’ll make it available through this link if it would be helpful to solve the problem.
I appreciate the help,
Matt RichardsonAugust 9, 2011 at 3:53 pm #1413MichaelKeymasterMatt, that sounds like a cool project.
The most notable thing about TVout is that it is interrupt driven, so the presence of interrupts would certainly disrupt the timing. But the IR code disables interrupts and then re-enables them, so that should solve it. I would expect some significant TVout disruption when this occurs.Some things to try:
1) get rid of the serial communication. Comment out the HBI hook and the pserial calls. See if that helps.
2) disable all the video interrupts at the beginning of SendMute(). Add this line at the beginning:
TIMSK1 &= ~(_BV(TOIE1));
TIMSK1 &= ~(_BV(ICIE1));
and this at the end to re-enable
TIMSK1 |= _BV(TOIE1);
TIMSK1 |= _BV(ICIE1);
I expect a lot of video disruption with this change….hopefully it will recover when re-enabled.
Let me know if this helps. In general, it’s hard to do timing-critical functions while also doing video processing.August 10, 2011 at 3:33 pm #1414MattRichardsonMemberMichael,
Thank you again for your help with this. The code you suggested to disable the interrupts worked perfectly and I didn’t need to disable pserial. It’s odd, because I tried cli()/sei() and noInterrupts()/inturrupts() at the start/end of sendMute() and neither of those worked.
The overlay glitches a bit when the sendMute() is called, but it seems to seems to get back to decoding CC quickly, most of the time without skipping a word. Now I just have to dig into the keyword search algorithm and see what’s going wrong there, it only seems to work 80% of the time. Do you have any suggestions for the best way to do a keyword search? I’m concatenating each line into a string and then using String.indexOf() to see if it returns anything other than -1. Sometimes, it’s just not picking up a keyword (and not due to case sensitivity). I know that’s outside the scope of the Video Experimenter Shield, but if you have any thoughts/tips on it, I’d appreciate it. Don’t worry about it at all if you don’t.
Anyway thanks again for all your help,
MattAugust 10, 2011 at 4:48 pm #1415MichaelKeymasterI’m so glad the interrupt disabling made it work — I wasn’t sure it would. Such a cool project! And I agree with your choice of trigger words 😀
I’m not sure why the keyword searching is not working perfectly. As I’m sure you’ve noticed, sometimes a letter is dropped from a word due to the transcription, especially in live broadcasts. Your code looks like it would work. Keep fiddling with it and see if you get better success….I’ll keep thinking.
-
AuthorPosts
- You must be logged in to reply to this topic.