Modifying Average Power of Binary Signal

[rxwontfit]

Hello everyone,

My colleague and I are transmitting serial data over a visible light communication channel.

How can we eliminate flicker? - i.e. when the signal is 01000100 the LED is dimmer than 01111011.

When long strings of data are sent, it causes the LED to flash and it's detectable to our eye. You would think that upping the bitrate would fix this because it would go out of our visible range (40Hz), but the data is not periodic, and unpredictable...

I've heard of NRZ encoding - would this help?
We've also thought about encoding the data from the software side before pushing it out the serial port.

It's almost as if we need to first detect the 8 bits, count the 1's and scale the actual amplification levels before passing the signal to the LEDs...

Any help is appreciated.

Cheers,

JoAr

 

[vk6kro]

You are using a form of pulse width modulation and this has to affect the brightness of the LEDs.

To get constant brightness, you could use an FM system where you jump from one frequency for Zeros to a different frequency for Ones.
The human eye would see this as a constant brightness.

You can get receiver chips for remote controls which receive at different frequencies around 38 - 40 KHz. So, maybe, if you had two of these on different frequencies, you could combine the outputs so that one gives a Zero out and the other gives a One out.

There was also a chip called a TCM3105 which was for slow speed modems.
This chip can receive on two frequencies and give a One or a Zero depending on which frequency was received.
Another of the same chips could generate the frequencies accurately from its crystal depending on the data you fed to it.
I found a source for these chips:
http://cgi.ebay.com.au/TCM3105NL-TCM3105-FSK-MODEM-IC-/110328304599?pt=LH_DefaultDomain_0&hash=item19b01453d7
but they were used for Packet Radio modems so there might be lots of them around.

 

[skeptic2]

I believe the data you are transmitting is NRZ and what you may be looking for is RZ encoding. What is the limiting factor in the bit rate of your data? Most, but not all RZ encoding schemes, require double the baud rate for the same data rate. How are you recovering your clock?

What is your transmission medium, air or fiber? If fiber, the edges of the pulses tend to get rounded over long distances. Over long enough distances that effect becomes significant and if the detection threshold for the receiver is halfway between a 1 and a 0 then due to the rounding effect, a single 0 in a long string of 1s may not make it across the threshold to be detected as a 0. To avoid that effect various encoding schemes have been devised to transmit the same number of 1s and 0s regardless of the data. These are known as RZ encoding schemes. Manchester encoding is the best known.

By sending the same number of 1s and 0s, the average value stays close to the threshold of the receive detector. The amplitude of the pulses may decrease over distance but because the 1s level stays above the threshold and the 0s below it, they are still decoded correctly. As a side benefit the average power also stays constant.

 

[rxwontfit]

@ everyone:

I'll give everyone a little more background information and our current architecture...
What we have at the moment are two laptops. One acting as a transmitter, and another a receiver. On the transmitter side, we're running a simple Visual Basic script that interfaces with the Windows VCP drivers. The interface allows the user to type in text data and the user clicks Send, it is sent out the serial port. I say serial port, but technically it's the USB since we're utilizing an FTDI chip to use Rx and Tx.

I have a couple of questions regarding this as well... In an effort to transmit the data as fast as possible, we've implemented baud FTDI baud aliasing:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_120_Aliasing_VCP_Baud_Rates.pdf

We're capable of pushing data out of the serial port at 3 MegaBaud. This is the maximum bitrate the FT232R module can Rx/Tx...

One of the goals of our project is to be able to transmit at wifi speeds, or faster - (54 MegaBaud)... Which mean's we're going to have to completely scrap the FTDI chips all together. But does this mean we have to write our own Windows Drivers to interact directly over USB? The USB 2.0 maximum bandwidth is 300 MegaBaud, so that is certainly not a limitation. Neither of us are well versed in Driver programming, so we thought perhaps we could 'hack' a usb-thumb-drive by tapping into it's data lines. The speeds of these thumb-drives are quite fast in comparison to wifi - see: http://usbspeed.nirsoft.net/ (note the values are in megaBYTES, multiply the read and write speeds by 8 to convert!)

@ vk6kro: I looked at the TCM3105 datasheet and it's only capable of very low baud rates. We're going to need fairly fast circuitry.

@skeptic2: The limiting factor is our FTDI at the moment, which operates at a maximum of 3 MegaBaud. The process is asynchronous serial communication, no clock. (Think of tying Rx to Tx and self communicating via PuTTY)... The transmission channel is air. It looks like RZ encoding is what we'll be needing here - But because of the reduced number of combinations, we'll be sacrificing bitrate for average power - correct?

Thanks everyone...

Cheers,

JoAr

 

[vk6kro]

You may have a problem getting distance at such speeds, with direct modulation of light beams.

Usually, even for remote controls which use very low speeds, the useful range is only a foot or so unless a carrier system is used. Remote controls for TVs etc use a carrier frequency of 38 KHz or so and they switch this with their data.

What range and speed are you getting now?

 

[rxwontfit]

Recent technological advancements in the fabrication of LEDs have made it possible to utilize the visible spectrum as a high-speed communications channel. The potential applications for communication through light are essentially ubiquitous; lights illuminate our homes and buildings, streets…etc

Because LEDs are low power devices, they are a viable and probable candidate for civilization’s next generation lighting systems. The fact that these LEDs can carry modulated information is an additional benefit that can be appropriately taken advantage of to create secure channels.

Furthermore, lighting in homes and buildings is pervasive; because of it’s networking capabilities, it introduces an opportunity to eradicate wired networks, and thus save homeowners and companies money.

We're currently only capable of transmitting at these rates.
We're waiting on parts in the mail to build the receiver... However, tying Rx to Tx on the FTDI chip we are able to perform successful loopback tests.

So if we can get the levels stabilized in the receiver (perhaps using a fast schmitt-trigger) to the RS232 levels, receiving will not be an issue...

Still though, 3 MegaBaud is too slow!
We're looking for faster alternatives... I still wonder if we absolutely need to write our own Windows drivers? Can someone tell me if this is what HAS to be done?

@vk6kro: Specifically, what do you mean by a carrier system?

At 9600 Baud we were able to get a couple of meters no problem...
If the light was more focused and if a mirror-like reflector was built at the receiver to concentrate the light we'd probably be able to achieve much greater distances.

As mentioned above, we're out to prove a concept that large LED lighting systems and arrays could be modulated and information transferred throughout buildings; only on a much smaller scale.

Need all the help we can get!

Appreciate your comments thus far.

Cheers,

JoAr

 

[vk6kro]

@vk6kro: Specifically, what do you mean by a carrier system?

Remote controls for TVs etc use a carrier frequency of 38 KHz or so and they switch this with their data.

So, the LEDs are switching rapidly at 38000 times a second and these bursts can then be received and filtered from the steady light from room lighting. This filtering gives much greater distances than you would get if you just switched the LEDs on and off at data rates.

Even then, they have to use tricks to get speed. If a number of 1's occur in succession, no switching is done until a Zero is encountered. Likewise, if a number of Zeros occur in succession.

LEDs are usually driven via resistors or other types of current limiters and these do not lend themselves readily to high speed switching.

 

[skeptic2]

- But because of the reduced number of combinations, we'll be sacrificing bitrate for average power - correct?

Yes, you do sacrifice bitrate for average power but I don't know what you mean by reduced number of combinations.

Usually, even for remote controls which use very low speeds, the useful range is only a foot or so unless a carrier system is used.

I think in the case of an RZ system such as Manchester encoding, the RZ encoding itself could serve as a carrier.

So if we can get the levels stabilized in the receiver (perhaps using a fast schmitt-trigger) to the RS232 levels, receiving will not be an issue...

What type of optical detector are you thinking of? What logic family are looking at? For instance http://ics.nxp.com/products/fast/datasheet/74f14.pdf You may want to put several stages of RF amplifiers between the detector and schmidt trigger to improve your range. Likewise you may need a decent RF power amp to drive the LEDs at a sufficient level.

 

[Bob S]

Here is an example of the Manchester self-clocking code. Between data bytes, a continuous series of "0"s produces a standby clock carrier signal that is used to synchronize the reciever (usually a phase locked loop). The recovered clock signal is then used to demodulate the data signal by shifting it into a shift register, for example two "1"s (for initializing the receiver), followed by an 8-bit byte and a parity bit, for a total of a 11 bit word. Because each bit is bipolar, there is no threshold skewing due to a long series of "0"s or "1"s as discussed by skeptic2. Creating a Manchester code is easily done by combining the clock signal and the data signal in an exclusive OR or NOR.

Bob S

 

[skeptic2]

It looks like someone is already doing this.

http://news.yahoo.com/s/ap/20101227/ap_on_hi_te/us_tec_internet_via_lighting