Synchronizing blink with camera framerate.

Hi I would like to synchronize blink of an Led on arduino with my camera so I can essentially send bytes without any cables the problem is that 1s devided to 60 or 30 frames is a periodic number which cant be put into delay and even if I round it it kinda works but desync after some time so there is atleast 1 frame error. Even 40 fps does not work flawlessly. And without delay but millis its even more of unpredictable thinga magika. How should I approach it?

unsigned long previousMillis = 0;       
const long interval = 25;
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(9600);
}
bool high = false;
void loop() {

  unsigned long currentMillis = millis();
  Serial.print(millis());
  Serial.print(" : hoj \r\n");
  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    Every25mil();        
  }
  
}
void Every25mil() {
  
  if(high)
    digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  else
    digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW
  high = !high;
  
  /*
  digitalWrite(LED_BUILTIN, HIGH);
  delay(25);
  digitalWrite(LED_BUILTIN, LOW);
  delay(25);
  */
  //delay(25);                   

  
  //delay(16);
  //delayMicroseconds(667);

  
  //delay(33);
  //delayMicroseconds(333);
  
}

Look at the micros() function. Similar to millis() but it counts microseconds

Using one of the hardware timers may also be an option

How exactly is blinking an LED on the Arduino going to send bytes without any cables ? What is on the receiving end ?

UKHeliBob:
How exactly is blinking an LED on the Arduino going to send bytes without any cables ? What is on the receiving end ?

If the timing is super correct the led could blink 1 and s = bits and multiple of them forming bytes which can then differentiate multiple leds of same color for example.

I still don't understand how it is intended to work but it sounds like you are trying to make an asynchronous link behave as if it were synchronous

UKHeliBob:
I still don't understand how it is intended to work but it sounds like you are trying to make an asynchronous link behave as if it were synchronous

Led will blink bit after bit forming byte the camera then can see those 1s and 0s and form it back using opencv or whatever else. Example: I will send out 1000101010 as blinks, each 1 and 0 will have its own frame and then from all the frames opencv on pc connected with the camera can detect it and overlay it with box saying its actually 554. Its similiar to how Oculus did it and its reverse engineered here Hacking the Oculus Rift DK2 | Doc-Ok.org

I will send out 1000101010 as blinks, each 1 and 0 will have its own frame and then from all the frames opencv on pc connected with the camera can detect it and overlay it with box saying its actually 554

It seems to me that any method relying on exact timing on both sides without a common clock or a method of synchronising the two systems is bound to fail

in the USA or Japan, which use NTSC, you want an NTSC sync separator. if you use a different video format, substitute that format for NTSC

UKHeliBob:
It seems to me that any method relying on exact timing on both sides without a common clock or a method of synchronising the two systems is bound to fail

Its only going to send 10 before its synchronized using starting with zero it will only be called each 10 seconds or more if not needed but these 10bits need to be precise.

they had to twiddle with the horizontal line rate of B&W TVs to make color work.

While existing black and white receivers could not decode a signal with a different audio carrier frequency, they could easily use the copious timing information in the video signal to decode a slightly slower line rate. Thus, the new color television standard reduced the line rate by a factor of 1.001 to 1/286 of the 4.5 MHz audio subcarrier frequency, or about 15734.2657 Hz. This reduced the frame rate to 30/1.001 ≈ 29.9700 Hz, and placed the color subcarrier at 227.5/286 = 455/572 = 35/44 of the 4.5 MHz audio subcarrier.

this is why B&W TVs have a bent line that scrolls up from bottom to top when they show a color signal

so you want to use the rock steady timing of an Arduino to synchronize with 15734.2657 Hz and 29.9700 Hz. as my flight instructor was fond of saying: you go ahead. I'll watch.

Are there any controllers which could handle that? or would it be better to have some ic logic?

const unsigned long FlashIntervalMicroseconds = 1000000UL / 60UL;


unsigned long PreviousMicroseconds = 0;


void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(9600);
}


void loop()
{
  if (micros() - PreviousMicroseconds >= FlashIntervalMicroseconds)
  {
    PreviousMicroseconds += FlashIntervalMicroseconds;  // Less drift
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  }
}

johnwasser:

const unsigned long FlashIntervalMicroseconds = 1000000UL / 60UL;

unsigned long PreviousMicroseconds = 0;

void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(9600);
}

void loop()
{
  if (micros() - PreviousMicroseconds >= FlashIntervalMicroseconds)
  {
    PreviousMicroseconds += FlashIntervalMicroseconds;  // Less drift
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  }
}

I did a quick test and it looks its enough(maybe even perfect but I does not have enough frames captured to conclude) probably the less drift part helped bcz the old one accumulated over time.