Mechanical TV Project

Forum for discussion of narrow-bandwidth mechanical television

Moderators: Steve Anderson, Dave Moll, Andrew Davie

Re: Mechanical TV Project

Postby Andrew Davie » Sat Jul 28, 2018 1:57 am

FlyMario wrote:Ok here is what I am thinking.
An Arduino has a 16mhz clock. At 12.5 fps 1,280,000 clocks should pass per frame. At 32 Lines, 40000 clocks should happen per line. If I were to sample the ports at 32 times per line I could use 1250 (~1240 realistically) clocks. I do have an adjustable oscillator chip (ICL8038) that I could use to pulse the interrupt line at 12800 times per second. Anyways I have a direction to try. If you guys have any suggestions please let me know. Maybe this is old hat and had a lot of issues.


Have you reviewed my Arduino televisor build? I know you're going about things a different way, but a lot of the timing issues and interesting alternate ways of doing things are discussed in the thread, and it would be such a shame for you to be embarking on an Arduino televisor without at least being aware of what has gone before. see viewforum.php?f=28

In specific answer to your question, the general form of an Arduino setup is that you have a loop() which runs as fast as possible, and a setup() - or something similar to those two. You can, of course, setup various interrupts to get things happening at constant times. I don't quite understand what you mean by "sample the ports" - I assume you are somehow connecting audio to the arduino and having the playback from (say) a CD player external to the Arduino...? Not very clear to me. I went about it a different way, by making the Arduino itself do the playback of the WAV file, from an attached SD card. It made things very simple, as it totally removed the analog conversion/process. Once you are all digital, the timing is inherent in the data - and sychronisation becomes very simple indeed. All of my source code (and Keith's) is available for download/review at... https://github.com/andrew-davie/NBTV - at the very least it's a good example of tightly optimised Arduino code running a televisor.

Good luck!
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1509
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mechanical TV Project

Postby smeezekitty » Sat Jul 28, 2018 2:23 am

My suggestion is just to skip the line syncs all together. A disc of that size has a lot of inertia and doesn't change speed very quickly.
Syncing once per frame (12.5 times per second at the club standard framerate) is plenty often to keep the picture stable. That is what I do and update rate is not an issue.
smeezekitty
Evil Genius
 
Posts: 159
Joined: Fri Jan 29, 2010 11:42 am
Location: USA

Re: Mechanical TV Project

Postby FlyMario » Sat Jul 28, 2018 2:33 am

Andrew Davie wrote:
FlyMario wrote:Ok here is what I am thinking.
An Arduino has a 16mhz clock. At 12.5 fps 1,280,000 clocks should pass per frame. At 32 Lines, 40000 clocks should happen per line. If I were to sample the ports at 32 times per line I could use 1250 (~1240 realistically) clocks. I do have an adjustable oscillator chip (ICL8038) that I could use to pulse the interrupt line at 12800 times per second. Anyways I have a direction to try. If you guys have any suggestions please let me know. Maybe this is old hat and had a lot of issues.


Have you reviewed my Arduino televisor build? I know you're going about things a different way, but a lot of the timing issues and interesting alternate ways of doing things are discussed in the thread, and it would be such a shame for you to be embarking on an Arduino televisor without at least being aware of what has gone before. see http://www.taswegian.com/NBTV/forum/viewforum.php?f=28

In specific answer to your question, the general form of an Arduino setup is that you have a loop() which runs as fast as possible, and a setup() - or something similar to those two. You can, of course, setup various interrupts to get things happening at constant times. I don't quite understand what you mean by "sample the ports" - I assume you are somehow connecting audio to the arduino and having the playback from (say) a CD player external to the Arduino...? Not very clear to me. I went about it a different way, by making the Arduino itself do the playback of the WAV file, from an attached SD card. It made things very simple, as it totally removed the analog conversion/process. Once you are all digital, the timing is inherent in the data - and sychronisation becomes very simple indeed. All of my source code (and Keith's) is available for download/review at... https://github.com/andrew-davie/NBTV - at the very least it's a good example of tightly optimised Arduino code running a televisor.

Good luck!


What I mean by reading the ports is this. I plan to make a circuit that listens to the "video Track" to grab the vertical sync signals and pulsing a port on the Arduino. From this, I should have 3 ports on the Arduino that are getting information. The Frame pulse from the inner mark on my encoder wheel. The second being the vertical line marks being the outer marks on my encoder wheel and finally the vertical sync pulses from the video stream.

If I read the sync from the video stream and it is ahead or behind the line pulse then I know I need to speed up or slow down the disk.

Counting each of the pulses from the video stream will give me the current line we are on with the exception of line 32 which I can have the Arduino know it is time to reset the line counter. In my mind, doing this should hopefully get things in sync.

I know I could use millis from the Arduino but that is only 80 per frame or 2.5 per line. Not what I call good. So if I set an external oscillator at a known frequency I can get an accurate reading based upon that.

I will review your work. thanks!
Attachments
EncoderWheel.jpg
EncoderWheel.jpg (37.46 KiB) Viewed 5069 times
FlyMario
 

Re: Mechanical TV Project

Postby smeezekitty » Sat Jul 28, 2018 2:36 am

I know I could use millis from the Arduino but that is only 80 per frame or 2.5 per line. Not what I call good. So if I set an external oscillator at a known frequency I can get an accurate reading based upon that.


Do you know about micros()?
https://www.arduino.cc/reference/en/lan ... me/micros/
smeezekitty
Evil Genius
 
Posts: 159
Joined: Fri Jan 29, 2010 11:42 am
Location: USA

Re: Mechanical TV Project

Postby Andrew Davie » Sat Jul 28, 2018 2:56 am

The Arduinovisor has just a single timing hole - a frame pulse, so to speak. It proved sufficient to adjust the rotational speed just once per rotation (frame). Note that the speed of the motor is adjusted once per frame - faster or slower so the motor holds the set speed for the rest of the frame. Given that the data is pulled off the SD card at exactly the correct frame rate, and the IR frame pulse comes along at a measurable time, it's easy to see if the frame start is ahead or behind, and speedup or slowdown the motor accordingly. Keith managed to get perfect frame lock with just the single timing hole in about 3 seconds, from memory. Every time. It's pretty impressive. I think I was hovering about 8 seconds or so with my puny little cassette motor.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1509
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mechanical TV Project

Postby Andrew Davie » Sat Jul 28, 2018 3:07 am

FlyMario wrote:What I mean by reading the ports is this. I plan to make a circuit that listens to the "video Track" to grab the vertical sync signals and pulsing a port on the Arduino. From this, I should have 3 ports on the Arduino that are getting information. The Frame pulse from the inner mark on my encoder wheel. The second being the vertical line marks being the outer marks on my encoder wheel and finally the vertical sync pulses from the video stream.


I think you will eventually find that only the frame pulse and vertical sync pulse are required for perfect frame lock. When you have an Arduino driving the thing instead of analog electronics, you have the advantage of an accurate clock that you can use to determine exactly what should happen when!
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1509
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mechanical TV Project

Postby FlyMario » Sat Jul 28, 2018 3:38 am

smeezekitty wrote:My suggestion is just to skip the line syncs all together. A disc of that size has a lot of inertia and doesn't change speed very quickly.
Syncing once per frame (12.5 times per second at the club standard framerate) is plenty often to keep the picture stable. That is what I do and update rate is not an issue.


Yeah I agree. I am way over thinking it really. The disk takes a good while to stop once you stop pulsing the Mosfet. A lot of this is just me trying to get line 1 to happen where it belongs so that I am not tweaking stuff all the time to jog the lines into place. Nothing is really ever going to be perfect. The record isn't even perfectly flat... wobbles in and out as it spins. I was programming in the 80's and early 90's where you worried about clock timing so very much to a point where you would code in assembly to get a few more clocks. I still worry about stuff like that when it is probably not that big of a deal lol
FlyMario
 

Re: Mechanical TV Project

Postby smeezekitty » Sat Jul 28, 2018 3:49 am

FlyMario wrote:
smeezekitty wrote:My suggestion is just to skip the line syncs all together. A disc of that size has a lot of inertia and doesn't change speed very quickly.
Syncing once per frame (12.5 times per second at the club standard framerate) is plenty often to keep the picture stable. That is what I do and update rate is not an issue.


Yeah I agree. I am way over thinking it really. The disk takes a good while to stop once you stop pulsing the Mosfet. A lot of this is just me trying to get line 1 to happen where it belongs so that I am not tweaking stuff all the time to jog the lines into place. Nothing is really ever going to be perfect. The record isn't even perfectly flat... wobbles in and out as it spins. I was programming in the 80's and early 90's where you worried about clock timing so very much to a point where you would code in assembly to get a few more clocks. I still worry about stuff like that when it is probably not that big of a deal lol


Lines and frames are locked together in a Nipkow disk system. So if you lock based on the frame pulse, line 1 will be line one. Just as long as your IR sensor is in the right place or you make the compensation in software.

(This is all assuming you are comparing the phase)
smeezekitty
Evil Genius
 
Posts: 159
Joined: Fri Jan 29, 2010 11:42 am
Location: USA

Re: Mechanical TV Project

Postby FlyMario » Sat Jul 28, 2018 3:58 am

Andrew Davie wrote:
FlyMario wrote:What I mean by reading the ports is this. I plan to make a circuit that listens to the "video Track" to grab the vertical sync signals and pulsing a port on the Arduino. From this, I should have 3 ports on the Arduino that are getting information. The Frame pulse from the inner mark on my encoder wheel. The second being the vertical line marks being the outer marks on my encoder wheel and finally the vertical sync pulses from the video stream.


I think you will eventually find that only the frame pulse and vertical sync pulse are required for perfect frame lock. When you have an Arduino driving the thing instead of analog electronics, you have the advantage of an accurate clock that you can use to determine exactly what should happen when!


Trust me I have thought the same thing. I even think about having the live video signal converted into digital and put into a ram chip with two different counters with latches. Making a very big FIFO buffer so that I can put the picture into sync. That way both the signal and the disk would be independent of each other offset by a certain time dictated from their signals. I have played with the idea of using a CPLD to deal with the timing... or an FPGA using it to control the timing and having its own memory. I even (believe it or not) thought about using one of my Z80 cpu's.

No offense to anyone here but I have some problems with streaming data from an SD card / Arduino combo into the machine. First obvious thing is that I could fudge most of what is going on an control the stream based upon the Disk information. Which to me feels a little over the line into cheating yourself out of some of the issues Baird would have had to deal with. Such as syncing disks to signals. If I wanted to do that I could just have put a bunch of LEDs on a disk and spun it around drawing into the air images for the hole 360° and what have you. What many of us are doing is more challenging. But of course, the other way would look cooler I am sure. Again this is no offense because everyone's sense of what is right is to their own desires. I could argue that using an Arduino or PWM is defying nostalgia as well.

I even want to get an XY Display and run NBTV signals up the display. Which incidentally, if anyone here knows what could be used for this let me know. I want to control the X and Y beam along with the intensity. I see things called Vector Monitors but they seem not really the right thing. Ebay doesn't seem to have anything true XY Display so I feel I must be searching the wrong thing.
FlyMario
 

Re: Mechanical TV Project

Postby FlyMario » Sat Jul 28, 2018 4:33 pm

Tonight I installed the new motor mount, IR sensor mount, and LightBox. I set up some code to read the microseconds between each frame marker and was pleasantly surprised by the readings. The microseconds reading from the Arduino should be around 80,000 cycles per frame and by simply setting the PWM to a constant rate the numbers were pretty stable. I included a sample of the readings. The program only puts out a reading every 1/2 a second (500ms) to not spam me. In the morning I will probably begin trying to get the Arduino to modify the speed to fight errors. Keeping a perfect 80000 microseconds per frame is really a bit much to expect.
Attachments
7 28 18.jpg
Micro.jpg
Micro.jpg (13.39 KiB) Viewed 5046 times
FlyMario
 

Re: Mechanical TV Project

Postby Andrew Davie » Sun Jul 29, 2018 2:23 am

I hope you are triggering an interrupt for detecting the IR pulse, rather than polling. That alone could account for timing differences.
Apologies if you have already mentioned this.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1509
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mechanical TV Project

Postby FlyMario » Sun Jul 29, 2018 2:37 am

I am using an interrupt to capture the IR pulse for the frame marker. As suggested before I will probably ignore the individual line marks on the encoder.

Since I am getting the frame signal, I am concerned how to match that up with the video. Having more than one interrupt triggering would seem risky especially if they are close to the same interval. checking for the video signals in a loop seems just as risky.
FlyMario
 

Re: Mechanical TV Project

Postby Andrew Davie » Sun Jul 29, 2018 12:53 pm

FlyMario wrote:I am using an interrupt to capture the IR pulse for the frame marker. As suggested before I will probably ignore the individual line marks on the encoder.

Since I am getting the frame signal, I am concerned how to match that up with the video. Having more than one interrupt triggering would seem risky especially if they are close to the same interval. checking for the video signals in a loop seems just as risky.


Don't over-think this. Keep your interrupt service routines as short as possible and move everything you can outside them. I did the critical things first, then re-enabled interrupts so others could interrupt the interrupt. You won't notice any clashes, especially as all you're doing is modifying a motor speed which is going to drown out any minor timing differences anyway. My system used a PID on the motor speed, and increased that or decreased that based on the late/early arrival of the IR pulse.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1509
Joined: Wed Jan 24, 2007 4:42 pm
Location: Hobart, Tasmania, Australia

Re: Mechanical TV Project

Postby Robonz » Sun Jul 29, 2018 3:39 pm

Thinking about this e.g. you want to use a live video feed going in to your ADC and an analog comparator to extract the sync pulse. Your video is live so nothing can be adjusted there which means you need to match the wheel speed to the Sync pulse speed. You also need to pull the wheel position (frame) to match the live sync pulse. Not too hard if you simplify things

1) You need to know error before you can do any corrections. I think the error would be "live sync time" minus "ir_pulse_time". You could do one interrupt for the sync and one interrupt for the IR. Each interrupt would just store the current time. In the main loop you would calculate the error and calculate the new motor PWM value.

You only need a PI controller to do this. If you look at this one that Andrew and I worked on it will get the error to a low number.

byte calculatePI(double speedErr, double frameErr) { // pass in error
double now = ( (double) playbackAbsolute ) / singleFrame;
double timeChange = now - lastTime;
double proportional;
float motorPWM;

if (lastTime == 0) { // avoids glitch on first round
lastTime = now;
return 0; // return zero for error (no motor action will be taken)
}
proportional = KP_SPEED * speedErr; // do this multiplication just once

integral += ( frameErr * timeChange ); // this is the integral value

if (speedErr > LARGE_SPEED_ERR) // if speed error is large then turn off integral
integral = 0; // reset the integral

if (speedErr < MAX_FRAME_ERR) // if speed error is small then tune the frame
proportional = proportional + ( frameErr * KP_FRAME ); // this is how aggressive it hunts the frame edge
motorPWM = (proportional + ( KI_SPEED * integral )) + 0.5;
if (motorPWM > MOT_PWM_MAX) // limit pwm to avoid overcurrent
motorPWM = MOT_PWM_MAX;
if (motorPWM < 1) // if smaller than 1
motorPWM = 1; // return 1 for no error

lastErr = speedErr; // store globals for next round
lastTime = now;
return (uint8_t) motorPWM;
}
User avatar
Robonz
Evil Genius
 
Posts: 147
Joined: Sat Aug 12, 2017 7:15 pm
Location: New Zealand

Re: Mechanical TV Project

Postby FlyMario » Wed Aug 01, 2018 12:13 pm

I built another Op Amp circuit tonight to capture the vertical sync signals. The results are pretty clean however sometimes it seems to add extra triggers. It is currently on a breadboard so there is some fear I am getting some extra noise. I normally use a 10K pot for the trigger point but replaced it with a 100k. It seemed better but only time will tell.

After some interesting conversations about glass beads and diffusion, I did get clear glitter and ran light through it. It did seem to diffuse nicely as well. I then poured ice resin into the glitter and lightbox. After a few days, I will know if that maintains a good look. The whole mix went clear so I have no idea what to expect. It is a fun experiment at least.
Attachments
20180731_175912_resized.jpg
20180731_202809_resized.jpg
FlyMario
 

PreviousNext

Return to Mechanical NBTV

Who is online

Users browsing this forum: No registered users and 7 guests