Forum Replies Created
-
Posts
-
I don’t see anything obviously wrong. I assume you are using a 9V 2.1mm center-positive plug? Polarity must be correct. Does the regulator get hot? Does anything happen when you press the red button?
If you are using the correct power, contact support@nootropicdesign.com to arrange an exchange.
I had thought of the UNO32, also, and I now have one. It is reported to be compatible, but it is really not. Only for the simplest of sketches, and it’s not compatible with many shields. Also, much of the Video Experimenter code is written in AVR assembly, so it would need a total rewrite.
I wrote up an article about compatibility here:
http://nootropicdesign.com/projectlab/2011/11/01/chipkit-uno32-review/Thanks, I’ll try to clarify. I didn’t think it mattered too much how I described the geography since the LM1881 supports major standards. Even SECAM is likely to work since it has the same timing as PAL. Maybe I’ll just change it to “supports NTSC and PAL”.
I’m afraid I have no experience with TTL video (never heard of it). If the timings are the same as NTSC, then maybe it will work.
Odd. Have you tried different video sources? It’s almost as if the voltage levels are too high from your source and the TV is scaling it down.
Have you tried different TVs?
You should find 75ohms resistance between the TV input and ground. This is standard and internal to the TV.
With the switch set to sync only, the white pixels are bright and opaque? But when in overly mode and the camera image is black (e.g. hand over camera) the pixels are faint gray? These two cases should not differ.
Did you buy as a kit or assembled? If as a kit, have you checked to see if you put the resistors in the right places?
Are you overlaying onto a very bright image? Is overlay light even on a dark image? I would expect the overlay to be washed out on a bright image…
Not a dumb question at all. You’re right that the memory of the Arduino is a limiting factor for resolution. Adding external SRAM seems like it would help, except that it takes too long to access the memory. The frame capture and video generation requires very high speed code (that’s why it’s in assembly) to be fast enough. When capturing a frame at low resolution (128×96), the code only has 6 instruction cycles to read the analog comparator register and store it in memory. To do higher resolution would require us to do this in 5 or 4 cycles (the time it takes the scan line to cross a narrower pixel). Low res means wider pixels, which means more time to do the work required. Bottom line: memory is a constraint, but so is speed. Make sense?
You should be able to supply 5V to the 5V pin on the shield, and connect the shield GND pin to GND on your nano and everything should work, no jumpers on the board needed. The ground connections on the RCA input and output are connected together. All board grounds are connected to the GND pin.
Can you give some more details about your Arduino? Which MCU does it have? How did you connect the shield to a nano?
Joggle, if you want an assembled one with some parts *not* assembled, just be specific in your order, and we’ll send it how you like it.
Have you looked at the closed captioning standard to understand the character set?
http://en.wikipedia.org/wiki/EIA-608
Compare with ASCII: http://www.asciitable.com/The characters you mention are differences between the CC standard and ASCII. So, if you decode a character ‘{‘ (code 0x7B), it is actually a ‘รง’ character (ASCII 0x87). So, you can just do a translation in your code, I guess.
