C-OOK: Customizing OOK for Optical Camera Communication

C-OOK stands for Camera ON-OFF Keying, is also an operating mode being standardized in IEEE 802.15.7m. This post reviews the operation of this mode and highlights its characteristics.

See video demo 1 (Manchester coded for Rolling shutter OCC):

See video demo 2 (4B6B coded for Rolling shutter OCC):

C-OOK for OCC and its applications

Figure 1 – Indoor Application of OCC applying C-OOK, the same as CM-FSK

Figure 1 illustrates an indoor application of OCC applying C-OOK, which is the same as CM-FSK. The similarity of the intended use case between these two is because rolling shutter cameras are to receive modulated data in both systems.

Comparing C-OOK and CM-FSK

The use of alternative waveform for rolling shutter OCC has impacts on the communication performance and promising application accordingly. A brief comparison is given as follows.

  • C-OOK decodes multiple asymmetric symbols (i.e., line coded symbol consisting of OOK binaries) from an image. In contrast, CM-FSK decodes single frequency from an image.
  • As a consequence, C-OOK can take advantage of delivering a higher amount of data per rolling shutter image, and thus its data rate is higher than that of CM-FSK.
  • Because C-OOK is designed with multiple symbols within an image so that it requires a preamble per payload unit perceived by an image. A preamble and its following payload unit together form a subpacket.

In comparing, CM-FSK does not require any redundancy for differentiating two adjacent frequency symbols because only one symbol is decoded per image.

C-OOK System

A reference architecture for C-OOK is illustrated as in Figure 2.

Figure 2 – A reference architecture for implementing C-OOK
  • Forward Error Correction (FEC): is needed for any communication system, as always.

Because C-OOK frame format consists of subpackets so that we combine the use of inner FEC and outer FEC for better data protection from error.

Inner FEC is to protect the payload within subpacket, while outer FEC is to protect the entire frame packet.

  • Asynchronous bit (Ab): is particularly customized from M-ary-FSK for CM-FSK in dealing with camera frame rate variation.

Any camera equipped to a personal device with an operating system (Android, Window, etc.) shall face this frame rate variation problem. Herein, Ab acts as the minimal sequence number of the PHY frame subpacket for supporting the downsampling process at Rx while Rx has a high deviation in the sampling interval.

  • RLL code: Because OOK itself does not provide DC-balance so additional line coding is used to gain DC-balance.

Manchester code or 4B6B are suggested in the C-OOK system due to its reasonable redundancy fraction at chosen clock rates.

C-OOK Decoding

To demodulate the entire data sub-packet DS, the distance from a camera to the LED transmitter should be close enough. Figure 3 shows the relationship between the amount of data being captured by the camera and the distance from the camera to the LED transmitter.

J.4. -Fig 1 -C-OOK -Fig B8---distance.png
Figure 3 – Decoding: Amount of data per image varies with distance

From the Figure 3, the maximum distance achieved is the distance at which the camera gets the amount of data equal to the amount of the sub-packet.

Decoding case 1: Fuse incomplete parts of a sub-packet into a complete one

At this distance far, the distance d1 as shown in Figure 3, the camera detects the preamble symbol and then demodulates the amount of data enough for a sub-packet; however, the uncertainty whether the forward part and the backward part counted from the position of the preamble belong to a sub-packet or not is problematic. The problem of a small amount of data also happens at a shorter distance when the transmitted subpacket is long.

Asynchronous bits representing the clock information of the packet are used for the asynchronous decoding algorithm in this case.

J.4. -Fig 2 -C-OOK ----Figure B9 ---decoding data fusionFig. 10.png
Figure 4 – Decoding algorithm at a far distance

Figure 4 illustrates the decoding algorithm to recover a packet of data from the forward part and the backward part of an image when the size of LED is small in the captured image. By observing the values of an asynchronous bit before and an asynchronous bit after the preamble, two statements of fusing those two parts of a subpacket are addressed:

  • Case 1- Inter-frame data fusion: Fusing two pieces of a packet at two different images into a complete pack.

This type of data fusion is applied in case two Ab on an image is different.

  • Case 2- Intra-frame data fusion: Recovering a complete packet from an image.

This type of data fusion is applied in case two Ab on an image are similar.

Decoding case 2: Combination of Data Fusion and Majority Voting

When the camera goes closer to the LED transmitter, the amount of data being captured per image is higher than that of a sub-packet. Therefore, the extra amount of data is used for correcting the possible error by applying a majority vote.

At distance d2 on figure 3, the amount of data equivalent to two sub-packets is captured. The majority voting is used in this case to correct the error throughout the entire sub-packet.

Figure 5 shows an experimental example of decoding under Intra-frame data fusion. The extra data after fusion a sub-packet is used for correcting the error by voting.

Assume that the camera frame rate may vary but be higher than the packet rate of transmission. Therefore, any extra data after fusion is used for the error correction by grouping multiple images which belong to a sub-packet to vote. The voting is on the amount of data grouped from all of the forward parts and backward parts of images as well as extra data.

J.4. -Fig 3 -C-OOK -----intraframe fusion Fig. 9.png
Figure 5 – An example of decoding employing intra-frame fusion


  • The customization of OOK for OCC is crucial to making it work.
  • The fundamentals of C-OOK have been discussed. The brief comparison to CM-FSK is given.
  • Rx decoding with data fusion technique is suggested to extend the communication distance.

7 thoughts on “C-OOK: Customizing OOK for Optical Camera Communication

  1. I am so glad to find your page. Your work in the field is excellent. I and my students I highly appreciate your work. We are beginners in the field of VLC and have little knowledge of communication. We have a background in cloud computing and IoT. However, we strongly feel VLC could be next-generation technology, and we wish to learn and contribute whatever little we can.

    Please me know about accessing source codes and norms for citing your work. We are looking more into simulation and implementation of the OCC system and handover effects. Please help us in any way possible.

    Thank You,
    All the best for future fantastic work.


  2. Sir, I am one of your admirers who follows your website. Your website is a blessing for those who work on Optical based projects and research. We feel that Optical Camera Communication is one of the few emerging technologies that will lead in near future. I am a student of Khulna University Of Engineering & Technology at Khulna in Bangladesh. I am a 4th year student and studying B.Sc Engineering in Electronics and Communication Engineering. In 4th year, I have my thesis work which is based on Optical Camera Communication. But I don’t know how to access open source code in your website so that I can progress my further work. Please help me about this.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s