Forum Replies Created
-
Posts
-
Hi guys, sorry for the slow response. I’m on vacation out of the country and only have limited net access.
Bottom line is that you must use polling serial comm provided by tvout. The project in my blog shows that I successfully read gps info and overlaid it. But you can’t read too much data using the polling approach. I configured my em406 gps to emit only the rmc and gga sentences. And my gps is only 1Hz. Joey, what doesnt work?
Hmm…I can’t imagine why you had issues with the PORTD pins. They aren’t used. Did you set the pinmode after initializing overlay?
Yes you should be able to use D9 with overlay.
I’m on vacation so I can’t do any testing …
A resistor won’t dim/blacken selective areas of the image being overlaid. I tried n-channel MOSFETs p-channel MOSFETs and the 4066 analog switch ic and found that the 4066 does the best job. The background is gray but looks good.
Ok I cleaned out my email so you can try again.
Coincidentally, I happen to be in London this week. I don’t suppose you are near Central London…!
Ok, here’s what I did. I used an IRF510 MOSFET but any n-channel enhancement-type MOSFET should behave the same. I would just breadboard this first to see if it works.
1) Connect the Video Experimenter INPUT pin (on the 6-pin breakout on the right of the board) to the MOSFET drain pin.
2) Connect the OUTPUT pin to the MOSFET source pin.
3) Connect Arduino digital pin 10 to the MOSFET gate pin.
4) Add pinMode(10, OUTPUT) to your sketch setup.
5) Remove the SYNC SELECT jumper from the Video Experimenter board.
6) Set the OUTPUT SELECT switch to SYNC ONLY.
7) Add these lines to the beginning and end of the function render_line5c() in the TVout library video_gen.cpp:
void render_line5c() {
// For the lines at the bottom of the screen, turn off the video feed by
// setting D10 low.
if ((display.scanLine > 216) && (display.scanLine < 231)) {
PORTB &= ~(_BV(2)); // video off for lower lines
}
...
// turn on video signal again by setting D10 high
PORTB |= _BV(2);
} // end of render_line5c
That gave me a dark gray bar at the bottom of the screen where I could overlay white text. You can add more dark lines at the top of your screen as needed. I did notice that my dark bar has a vertical line of white pixels at the far right — not sure why.
I want to achieve true black, but my MOSFET is not turning off the current completely. I have a 4066 analog switch on the way which I will try. You may also try different types of MOSFETs (like a p-channel depletion-type) if you have them. The logic might be opposite for different MOSFETS (gate HIGH to turn off current, LOW to turn on). You may know more about MOSFETs than me…
Joey, I have been working on a solution for that. I have accomplished white letters on a black bar at the bottom of the screen. Would a black bar at the bottom and top of the screen solve your problem? The bar is not entirely black (dark gray) but I’m waiting for a new part that may help me make it darker. The readability is still much better than the current overlay.
The solution involves an n-channel MOSFET. Do you have any handy? If so, I can help you get started.
I think I know what you are trying to accomplish, but it seems you are contradicting yourself. If you want higher resolution, you need to capture more information (more pixels) and that requires more memory, not less.
The bottom line is that the resolution of the captured image cannot be higher because the capture routine is running as fast as it can. In other words, the pixels are “wide” because it takes several assembly instructions to read the analog comparator value and store the pixel value (on or off) in the frame buffer. There are only 128 pixels captured for a line of an image because we can only measure the signal voltage 128 times in the time it takes the NTSC input signal to cover one line. The timing of the NTSC input from the camera is fixed according to the NTSC standard.
Does that make sense?
If your camera zooms in on a number, that should be plenty of resolution to identify the number. But how are you going to match the image against a template? Are you planning on doing some neural network code? I had considered implementing a backpropagation network, but am not sure I’d have enough memory. And you need memory to store the templates, but you could use flash PROGMEM for that.
Have you looked at the troubleshooting guide: http://nootropicdesign.com/hackvision/build/#troubleshooting
How many TVs have you tried?
Are any components warm?
Does the Arduino IDE recognize the device?
Where are you located (what country)?
Please feel free to send hi-resolution good quality photos of the back of the board so I can have a look at the soldering.
michael [at] nootropicdesign [dot] com-Michael
That’s a good question, but no, you can’t use the Video Experimenter with a ChipKIT board. The Video Experimenter is very specific to the AVR architecture and the real heavy lifting to perform video capture, video generation, etc. are done in AVR assembly.
Always be careful when someone says “Arduino compatible”. They mean compatible at the most basic level (I/O). But many shields take advantage of specific features of ATmega microcontroller.
I’m very sorry about the slow reply — I’m having problems with spammers on my forum, so legitimate posts are getting overlooked.
I think you should try another TV. Per the original author of TVout, the vsync implementation does not exactly conform to standards, so he expects the vsync to not work with a small number of TVs. This is the first I’ve heard of someone actually experiencing this problem, though, and I suspect that other TVs may work fine.
I also suspect your soldering is fine.If you really think it’s the crystal, you could try replacing just that component. 16MHz crystals should be readily available.
The red, green, and blue RCA connectors on your TV are component inputs, not composite. A composite input is a single RCA input and is usually yellow. The Hackvision outputs composite video. I’m very surprised that a TV does not have a composite input. I’m not sure what an SCART adapter is (is that European?).
Processing 1.5 seems to have made changes to the paint() signature. To make sketches work with 1.5, use a paint method like this:
void paint(java.awt.Graphics g) {
if (layers != null) {
layers.paint(this);
} else {
super.paint(this.getGraphics());
}
}Thanks for the info, I’ll have to take a look. I haven’t done much with Processing Layers lately, so I need to dust it off and see if I can provide a fix. I wasn’t sure anyone was actually using Processing Layers!
Ok, here’s a question for you: have you been trying to use the Serial interface in your program (before using it for debugging)? Serial communication won’t work well with TVout because it is interrupt driven. So, the absence of the “3” may not mean that the program is hung (although your use of interrupt driven serial communication may cause it to hang).
TVout comes with a polling version of serial communication in the “pollserial” library. There is an example called NTSCserialTerm.pde. Basically, declare an object like this:
pollserial pserial;and then use it just like Serial:
pserial.print("3");Question 2: When the bounding box disappears, do the coordinates written in the upper left of the screen also stop displaying?
It’s hard to imagine tv.resume() freezing because it just sets a variable. What hardware are you running on (ATmega328?) and what resolution are you using?
