Forum Replies Created
-
Posts
-
Unfortunately, composite video is quite complex when it comes to color. You’d have to provide a sine wave of the right frequency, and also have a precisely timed “color burst” wave. I really don’t know how to do that in any simple way. Everyone wants color, though.
Ok, I understand. I think the problem is that you are only reading in one character from the connection. Try changing:
if (client.available())to
while (client.available())so that it loops and fills the buffer until there are no more characters. I also think you should expand your buffer from 280 to 281 because there is probably a null character terminating the string.
I think you are really close…needle,
I’m so glad you are doing this project — I’ve been meaning to do the exact same thing for months but have not gotten around to it. I hope you figure out how to get the tweets from twitter.com itself, too.I don’t see anything horribly wrong with the code — what behavior are you seeing? Is your tweet the full 140 chars? Does the program seem to “crash”? 280 bytes in your buffer is a lot of memory. There’s not a lot of memory to deal with in Arduino.
I’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.
Matt, 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.The capture ability is limited by the size of the pixels it can grab. So even if you want to capture a subset of the screen, you can’t make the pixels smaller. The Arduino can’t run instructions fast enough to capture smaller pixels. As the scanline flies across the screen, it takes 5 instructions to capture the brightness level, and the time it takes to run those instructions is what determines the width of the pixels.
I’m not sure I understand the question about grabbing multiple frames. You can capture a frame, then process it, then wait and capture more frames later.
There’s nothing in the NTSC or PAL signal about the aspect ratio, so yes a signal with 16:9 image works fine.
Here’s a thread where I talked about how to add a black (dark gray really) bar at the bottom of the screen using a MOSFET.
http://nootropicdesign.com/forum/viewtopic.php?f=25&t=2363I used the MOSFET (also works with a 4066 analog switch) to turn the picture “off” to make a black bar, and then overlayed text onto it.
Problem is, the bar is only as wide as the frame buffer you have defined (e.g. 128×96) so it doesn’t go all the way across the screen. You can try a wider resolution to see if you can make the bar wider.
Hope this helps.
Thanks for providing that information. Using a nunchuk with the TVout library is rather flakey because communication with the nunchuk occurs only at the end of each frame, and the timing of the communication is very sensitive. So, I’m not surprised that the code did not work with PAL, and I’ll do some testing to see if I can remedy it. The behavior you experienced (moving to the upper right) is consistent with what I experienced when developing the TVBlaster code and the timing was off.
By changing the resolution you changed the timing, and that caused it to start working. You can also try to change the delay in loop() from tv.delayFrame(1) to tv.delayFrame(2), or use tv.delay(15) to introduce a delay based on milliseconds. You can try different values.
Sorry this nunchuk stuff is so flakey….That’s great — have fun. There are a lot of cool things you can do with this….
– integrate with Twitter (I specifically designed the Video Experimenter to be compatible with the Arduino Ethernet shield)
– search broadcasts for keywords and trigger some Arduino output. This can be done entirely in the Arduino with no Processing component.
– make a video drinking game. Search for keywords and when they are detected, display them on the screen and also display “Drink!”Some undocumented features of the Processing program:
– click to reset the cloud
– space bar pauses/unpauses the collection of words in the cloud
– ‘s’ saves the current cloud as a .png image.
– ‘r’ starts/stops video recording of the cloud. Large window sizes cause poor performance.Matt,
(Thx for the blog post on Make today)Before you even start the serial monitor, you need to ensure you are capturing data. Are the bits displayed at the top of the TV screen like in the images? This is how you know you are on the right track — the code gives you visual feedback by displaying the two bytes at the top of the TV screen.
Adjust the potentiometers until the pixels representing the data bits are displayed. When there is no dialog, only the parity bits are on. When there is dialog transmitted, the other bits flash. Do you see this? If not, try different values in the code for the line to look on (first arg of dataCaptureStart) and adjust the potentiometers.
Then as the tutorial says, display the bit positions to see if they line up with the bits. Uncomment the call to displayBitPositions(). You can adjust the values in the code based on what you visually see on the screen.
Only then should you turn on the serial monitor, and hopefully you’ll get clean data.
It takes a while to find the data. This is not a plug-and-play project, and that’s why it has a difficulty level of 8.
I’m glad to hear you’ve figured out the root of the problem. Great work, and thanks for posting all the information!
Also, you could try the Video Frame Capture project here:
http://nootropicdesign.com/projectlab/2011/03/20/video-frame-capture/Ok, your board looks fine. At this point, I’m not sure why your LM1881 chip is not working. Maybe it’s defective or damaged. I can only suggest removing it and reinserting it.
I’ll do some experiments tonight and if I don’t figure out anything, I’ll arrange to send you a replacement Video Experimenter (assembled/tested). I’ll contact you via email.
What was the input source in this (sideways) video? A VCR?
This is your setup, right:
VCR -> VE Input
VE Output -> TVR4 is in lowest position? (counter clockwise). Maybe you can send me a clear picture of your VE from the top and bottom.
And your OverlayDemo sketch is completely unmodified? Just to be sure, maybe grab the source from my site again?
It is possible that the TV is more tolerant to poor synchronization than the LM1881 chip. I got a VCR for $10 from someone on craigslist — that might be a cheap way to get a video source. Or borrow a video camera from someone?
Maybe the camera is outputing PAL. Try changing NTSC to PAL in the OverlayDemo sketch.
And make sure you are running the OverlayDemo otherwise unmodified. Don’t change anything else.
