Electronics > Microcontrollers

Coding information into flashes of light (from 60Hz PC LCD)

(1/1)

Psi:
Hey Guys,

I was just wondering if anyone on here has any ideas about how i could improve my data coding scheme. So i'll explain what i'm doing and what i've already tried.
So bear with me for a few paragraphs.

I'm working on some electronic ID tags/badges for a gaming event.
They have 4x 5x7 LED matrix displays in landscape for displaying a message (name/handle of person etc)

Here's a very early prototype on homemade pcb (proper one will be much smaller, i can't etch 8mil doublesided tracks myself  ;D )


They have a MCU (ATMega165) to multiplex the led arrays and display the message. The message will be customizable and able to be changed to whatever the person wants to display. All the LED code is working well and i've moved on to working out how the messages will be configured into eeprom.

What i've been testing is a method where the person enters the text they want into a computer program running on their PC/laptop and then holds the tag up to the computer screen where the message is programmed using flashes of light.

I have a phototransistor connected to the micro ADC and have written the code to sample the data then figure out the min/max of the analog waveform in realtime and then detect high and low states (white and black) from the LCD .

The first method i tried to encode the data was just sending bits represented by black and white clocked at whatever the refreshrate is.
so white,white,black,white,black would be 11010, so at the normal 60Hz lcd refresh rate the bit rate is 60 bits per second.

To read that using the mcu i sampled 10 times faster and counted the number of samples between state changes to work out the data.
For example
- 30 counts of high time (white) = 1
- 60 counts of high time (white) = 11  and so on..
And the same for black, 30 counts of low time (black) = 0 etc..
Where 30 counts is the length of 1/60hz

The issue i had with that is the ~125Hz backlight PWM that is done to set the brightness on lcds. It needs to be filtered out and doing so results in a waveform that's not a square wave. Also timing varies quite a bit between lcd brands and computers. I found that unless you have the lcd brightness at 100% the error rate is awful. And even at 100% brightness variations in the refreshrate cause errors around every 60bits.

So the next thing i tried was to forget timing the length of high/low states and instead send the information as a number of state changes.
So for example
If the mcu detects 3 changes between black/white or white/black within a set period then that means the data 010
- 8 changes means 111 ,  1 change means 000  etc..
The 3bit block of data is considered finished if there is no more changes within a set time period (around the width of two black/white state changes)

here's an example, this is with the lcd at 100% brightness, so its a nice waveform.


This result of that was instant, now it was able to detect data from a heavily filtered signal at almost any LCD brightness setting and it worked on all computers i tried it on.  The downside is that its much slower, since it takes between 1+4 and 8+4 refresh rate clocks to send 3 bits of data.
(depending on the data in question, since 000 requires less pulses to send than 111).
The (+4) bit above is 2 bits required for the timeout (end of this frame) plus 2 bits worth of idle time.

I've done a few calculations trying different block sizes, 2bits per block, 4bits etc.
3 seems to be the fastest so far.

I've also had a look at coding the information like this
1 state change   = 0
2 state changes = 1
3 state changes = 01
4 state changes = 10
5 state changes = 001
6 state changes = 100
7 state changes = 0001
8 state changes = 1000

but it seems worse than a static 3 bit frame.

Does anyone have any ideas how i could speed this up a bit. I don't want to change the hardware much, so no external comparators, opamps or extra ICs between the sensor and mcu. Currently it just has the sensor and some passive filtering.
Also keep in mind any encoding scheme as to be simple enough to code into a micro.
I'm open to ideas of using the analog nature of the adc signal if anyone can think of a simple way to implement it in a micro. (currently i'm using the adc and lcd as digital devices but the adc and the lcd are analog in nature)

Also keep in mind the signal varies in amplitude and dc offset between different lcds and computers and brightness settings.
Currently the micro homes in on the min/max value so it can calculate the center value of the waveform and detect the state changes at that point.

jwrodgers:
Hi,

Looks like a very cool project. Have you considered using manchester coding? http://en.wikipedia.org/wiki/Manchester_code

Manchester code uses only 2 states per bit, but always has a transition in the middle of the bit. This makes clock recovery very easy.

Also, as the DC component is always halfway between the high and low state, it is possible to create a simple algorithm to detect a good state threshold voltage input, meaning the detection should work well at different brightness levels and different background lighting levels (provided background lighting does not saturate your detector circuit.)

Also, are you using any framing for your data, e.g. a preamble to sync the clock and detect timing, a start of frame sequence, data packet, crc or checksum, end of frame sequence?

This will allow detection of errors in the badge, and allow it to wait for the next frame transmission.

An interesting project, let us know how you get on.

Regards,
JR

Psi:
Thanks, i will have a look at manchester coding and see how it works.

Currently the way it detects the position of the waveform is by using two variables, a min and max, each is updated if a new min,max value is detected.
Also, each is intentionally pushed to one side to trigger repeated min/max updates.

So the 'min' value is updated if a value lower than the current min is detected.
It's also gradually incremented to force these updates to occur.
Same with max.

yeah, i'll have a sync period, start of frame header and checksum.

daedalus:
if you are filling a conference with people wearing these badges, it might be fun to hack a torch to allow on-the-fly renaming of delegates, that would be good for a laugh :)

Psi:

--- Quote from: daedalus on December 14, 2011, 07:57:00 pm ---if you are filling a conference with people wearing these badges, it might be fun to hack a torch to allow on-the-fly renaming of delegates, that would be good for a laugh :)

--- End quote ---

Yeah, that is on my list of things to code if i have time.
As well as a duplicate tag mode where you hold tags together to copy the message.


Only the (~25) organizers will get the LED display tags. We couldn't afford to make 400 of them for everyone.
Regular attendees will get a simpler tag with just a battery and two leds illuminating some silkscreen text.

Navigation

[0] Message Index