Forum Replies Created
-
Posts
-
I think your sensor code is working fine since the temperature value is changing (I’m looking at your live feed).
Maybe your string buffer handling isn’t working right. I use sprintf, like:
sprintf(temp, "%.1f", tmp);You can verify whether your string handling is working by just printing a constant string to the screen and see if it jumps around.
tv.print(0, 80, "foo");It’s better to set a flag in your VBI hook function, then act on that flag in loop(). The reason is that you don’t want to do sensor communication in the TVout interrupt handler.
So I’d try this:
Declare a flag and a count variable at the beginning of your code.volatile boolean inVBI = false;
int vbiCount = 0;In setup(), do this:
tv.set_vbi_hook(&setVBIFlag);Implement setVBIFlag as you did before:
void setVBIFlag() {
inVBI = true;
}loop() should inspect the inVBI variable and get sensor data only once per second
void loop() {
if (inVBI) {
if (++vbiCount == 60) {
// only fetch temperature every 60th frame (once per second)
getTemp();
tv.print(23, 80, "*F");
dspData(); //Display the recieved temp from getTemp
vbiCount = 0; // reset counter
}
inVBI = false; // reset flag
}
}Also, keep in mind that comminicating with a sensor like this in an interrupt driven program is not really a beginner project. It’s much easier to simply read an analog sensor versus one that has its own communication protocol. The current version of the OneWire library turns interrupts on and off, and that interferes with video.
endlessplanet, your soldering looks good. I think your microcontroller may have failed. I will ship you an assembled/tested defusable clock. Sorry for this inconvenience and delay.
pinkstond, if you want people to help you with your code, you need to organize it and format it so it’s readable. People are busy, so you need to make the effort…
You have a delay(2000) within the “if (inVBI)” block. The VBI is only a couple of milliseconds long, so you can’t wait for 2 seconds. Move that delay out of there.
Is your version of the OneWire library disabling/enabling interrupts? The current version does this, and that will interfere with the video timing. The TVout library relies on interrupts to perform the timing.
How often are you polling the sensor? You could arrange for the sensor reading to only happen during the video blanking interval. TVout has a way to set a hook function to be called during the VBI. You pass a pointer to the function you want called.
tv.set_vbi_hook(&readSensor);Where you have a function called readSensor that does the work:
void readSensor() {
// do the work of reading the sensor
}And you certainly don’t need to read the sensor 60 times per second. Use a counter to arrange for it to happen every 60th call to readSensor or something. Make sense?
The example on that site has the sensor connected to pin 2 on the Arduino. Is that what you did? Because that would mess up the video timing, since the Video Experimenter uses pin 2. If so, you could try another pin (like 3).
That sounds good. It is possible that the board had a defect and caused a short. Or, sometimes a little extra solder will cause a short to the ground plane if the solder mask is melted away a little bit. Or maybe one of the transistors was defective. I’m sure you were careful, but these things happen sometimes.
It sounds like there is a short between +5V and GND. If the voltage regulator is very hot, then something is very wrong. Some components are probably damaged, so it’s not worth trying to repair the clock.
Since you are in Russia, you don’t have to send the unit back. I will send you an assembled/tested replacement. Sorry for the bad luck.
TeamAWS, hope you can send a good photo for the gallery, because there’s an Airsoft place in Florida that’s been building some crazy devices. Look what Combat City has done: http://nootropicdesign.com/defusableclock/gallery.html
That looks great. Don’t worry about a video — I can make that, and I really want to host the videos on the nootropicdesign YouTube account anyway. Can’t wait to see the game when you’re done.
I think we are using the term “overlay” differently. The text and graphics that your code generates *should* be present in the output for *all* settings. The switch setting “OVERLAY” means that the input should be included in the output such that the text/graphics is overlayed on top of it.
If the video input is passed to the output when the switch is set to SYNC ONLY, then there is a short. Have you looked at the soldering for the switch and jumpers?
I expect garbled overlay when the switch is set to SYNC ONLY and the jumper is across the middle pin and leftmost “D9” pin. You are connecting the jumper so that it connects the middle pin and either the left pin (for D9) or right pin (to use the sync signal from the input), correct?
It’s very easy to set an output pin with Arduino. Just set the pin as an output pin in your setup() function:
pinMode(thePin, OUTPUT);then to turn it “on” (5V) and “off” (0V), use
digitalWrite(thePin, HIGH); // set it to 5Vand
digitalWrite(thePin, LOW); // set it to 0VThat’s all there is to it. So, you can use the object tracking example and based on the coordinates set pins HIGH and LOW based on your needs. Keep in mind that the Video Experimenter uses pins 2, 6, 7, 8, 9 and A2. There are plenty of other pins left for you to use.
See the Arduino site arduino.cc for everything you need to learn Arduino coding.
Hmm. so you are saying that even with the OUTPUT SELECT switch in the SYNC ONLY position, your input video source is passed through to the output? It should not be. This switch controls whether the input video is also included in the output. In the “SYNC ONLY” position, only the text/graphics generated from the code should be in the output signal.
The SYNC SELECT jumper set to D9 is for the case when you want to generate graphics, but don’t have any video source connected to the input. That is, the Arduino generates the synchronization pulses on the D9 pin.
Is this making sense?
Yes, pins A4 and A5 are broken out as part of the nunchuk connector. See the circuit board images.
A Wii nunchuk also uses I2C communication. It was really tricky to get the nunchuk to work with Hackvision because the constant interrupt generation to make the video signal interferes with I2C. I trimmed down the size of the I2C library and it is now part of the Hackvision controllers library. See the nunchuk controller code for some ideas on how to use it. Basically, the code waits for the vertical blanking interval at the end of a frame to perform the I2C communication.
Timing issues make it tricky…if your heart rate monitor responds quickly, then it will be easier to do. Sounds cool!
