Forum Replies Created
-
Posts
-
Hi Marcos,
I did not publish the hardware design on this product, but I may in the future. Some Chinese company made a clone of the Defusable Clock and basically destroyed my sales for a year by selling an inferior product for very cheap. It damaged my reputation because I kept getting angry emails about the poor quality. They even used my real name in their marketing by quoting an interview I gave to a magazine. The counterfeit version even started a fire in one guy’s house.So I’ve decided to be less open about the new one, and it’s a fine line to balance the collaborative nature of the community with protecting my business. I hope that people can understand that.
Nonetheless, I’m VERY happy to share the schematic with you and will email it to you in a moment.
I’ve updated the original Hackvision firmware to work with the newest version of Arduino IDE, and have put a patched, working version of TVout on GitHub.
https://github.com/nootropicdesign/arduino-tvout
https://github.com/nootropicdesign/hackvision
https://github.com/nootropicdesign/arduino-asteroids
https://github.com/nootropicdesign/hackvision-controllersYou are correct — the link on the main page was wrong (I just fixed it), and it should have been pointing to https://github.com/nootropicdesign/arduino-tvout-ve.
I was just updating all this the other day and clearly made a mistake — thank you so much for letting me know! I appreciate that.
-Mike
It was a long time ago, but I know I was experimenting with that. The “odd/even” pad on the Video Experimenter board will be HIGH if the video signal is the odd frame, and LOW if the even frame. Connect this signal to an Arduino pin (in the case below, it is digital pin 10) and make the capture conditional on this pin being HIGH. Remember to do pinMode(10, INPUT) somewhere in your setup().
This is the code at the end of the function blank_line() in TVout/video_gen.cpp:
// BEGIN Video Experimenter // original code //if ((dataCaptureBuf != 0) && (display.scanLine == dataCaptureLine)) { // capture only if ODDEVEN pin is HIGH if ((dataCaptureBuf != 0) && (display.scanLine == dataCaptureLine) && ((PINB & 0x4) > 0)) { render_line = &dataCapture_line5c; wait_until(dataCaptureWait); render_line(); render_line = save_render_line; } display.scanLine++;The shift to the right is caused by processing delay. By the time the code determines a pixel should be on, the scanline has advanced to the right for a few microseconds. I don’t think anything can be done because an Arduino can’t be sped up and a video scan line moves very fast from a timing perspective.
The flickering you are seeing at the top in the second video is timing difference between the video signal and the overlay. Try increasing the frame delay from 2 to 5. That reduces flickering but your overlay will update less often.
The Video Experimenter is very primitive, so I’m sorry there are limitations.
Yes, solder the 330 ohm resistor directly to R2 so that they are in parallel. This creates a resistance of 330/2 = 165 ohms.
Like this:
A solution is to add a 330 ohm resistor in parallel with the 330 ohm resistor on the Video Experimenter board. It is labeled R2 on the board.
Mr. Midi,
Hmm, that is a strange problem. I have never experienced any noise generation from a Lumazoid, but I haven’t used the same setup. The only thing I can think of is to inspect the solder joings on the 3.5mm audio jacks on the Lumazoid to see if there is a short between any pins. In the past, I have accidentally shorted 2 adjacent pins, but this usually just has the effect of attenuating the signal because it shorts the left and right channels together. The ground pin on the jacks is the pin that is furthest away from the signal pins, so it’s unlikely that an audio channel is shorted to ground. But you might want to check with a multimeter to see.
Maybe having an isolated power source for the Lumazoid is necessary for your situation…
Thanks so much for sharing your progress. It looks great. I’ve never connected a Lumazoid to a ring before, and it really looks nice.
What I mean is that a small change to the software allows the visualizations to use 144 LEDs instead of 60, 120, or 180. If you purchase a Lumazoid and want to use it with 144, just let me know and I’ll change the software.
That should all work fine, then. The Lumazoid board just needs 5V, and it draws very little current compared to the LEDs. Sounds like a great project. I’d love to see it when you are done.
Thanks for your kind words and especially your enthusiasm. So the thing with USB is that a USB port doesn’t typically supply more than 500mA of current. To power 120 LEDs (a 2m strip, for example), I recommend a 2A power supply. Little phone charger USB adapters often will supply 1.2A for charging, so you could control 60 LEDs with no problem but could run into issues with 120.
Do you know how much current your USB hub can provide on each plug? Maybe it can supply 2A…
