Reverse-Engineering a chinese LED screen control.. thing. | INTERESTING!

[chinglish]

Dear Constumer,
You may warned by this thread potentially strengthen your thinking ability.

I love chinglish!

The screen control system to be 'tamed' is manufactured by a company called 'Linsn'. 'Linsn' produces the de facto standard hardware for chinese big-a*s LED screens (really big ones). I dug up some information about the system for you guys, so that you know what we're dealing with:

'The eighth generation [of the Linsn control system] is developed based on the seventh. Compared with the seventh, the eighth has all the functions of the seventh.'

So, yes... Essentially, it's all the same. Just different! 'Linsn -- think different, do the same'. Or whatever their slogan is.

As much as I love their ability to present new products, I desperatly need to find a solution to the following problem. Linsn kind of developed some software to control their LED system. It's Linsn, it's Windows, it's great! No. So I thought... Maybe I could reverse engineer the serial protocol to control our screens with my own software (or anything that won't crash every 2 hours giving you lots of '?' with a frustrating 'OK' button).

HOWEVER, I never reverse engineered such a piece of kit, and I probably will never do it again. Anyway... I managed to capture some serial data to lear how the software controls the brightness. To get a better picture of how such a system works, take a look at this information I kindly provide for your enlightenment (or kindly skip this section if you're only interested in the serial data stuff... NERD!):

FUNFACT: What you are looking at is - you guessed right - a PCI card. Thing is... it's not PCI. It only draws power from the slot, you have to wire it up using loop cables! Oh, and yes, you can power it with a 4-pin molex, which actually came in very handy by the time I discovered that the PC i bought for our next project had it's PCI port covered by the graphics card. Well done, chinese friends! The actual reason behind this weirdness is that Linsn sells a 'sending box' that contains exactly this card screwed into a metal box for customers that want to use a laptop, or no PC at all. Compared to the PCI card, the box has all the features of the PCI card. Only costs a lot more.

Anyway, this so called 'sending card' works as follows.... Get a device that provides DVI/HDMI digital video output (preferrably mirrored output) and hook it up to the board using a DVI connector on the Linsn side of things (dvi - hdmi - it's the same, just different). The card then grabs a piece of the input in the size of your LED screen like this:

Most big-ass screens have a very limited resolution, so most of the time it's a tiny window of like 240x180 up to 800x600. Fortunately (or maybe unfortunately) you can/have to specify the position of this windows using the Linsn software, ugh, and you can't resize/stretch/skew or something. The card then converts the DVI signal into some kind of unknown chinese noodle bit stream format and sends it through 1 or 2 of the 2 RJ45 connectors to your actual screen(s). You can send 2 different screen areas over those 2 connectors, or combine them for a higher resolution, but only configure the screens over the one labled 'D'. The other one is labled 'U', which most probably stands for 'useless'.

The screen itself typically consists of several elements (thats what we call them in germany, might be bad english), which are daisy-chained by standard cat5 network cables, each one containing a so called 'receiving card'. They grab a 'chunk' of the signal ('their' chunk of the screen area'), passively pass the full video signal to their own output and slap on a 'stamp', saying... 'FIRST!!!', kind of like in other forums. The second one then recognizes it and says 'SECOND!!!', and so on. So they actually 'know' what position in the singal line they're in, but only in a 1-dimensional sense. That's why you need the 'D' connector -- It is able to program the receiving cards with stuff like 'If you are first, display 64x64 px at 1x1, if you are second, show the chunk at 1x65', and so on.

The good thing is, once the data is pushed into the non-volatile memory (you have to 'save' manually after 'sending' the config data), you won't need the Linsn software again... Well, most the time. Because if you want to install those screens fixed on.. say a building, you want to control the brightness, contrast, etc.. to avoid astronomical eletrical bills. To give you a better idea of the costs: 1 'element' of a 1x1m P16 screen (16 mm pixel pitch) draws up to 1kw full white. That doesn't sound like much, but a rather small screen of 4x3 meters consists of 12 of those, and running for 16 hours a day, this adds up to typically 4kWh a month, which will cost you about EUR 1.000 (in germany). There are sensors available, but I really don't like those. They tend to over-dim or over-brighten the screen. So... I need to control the brightness with some custom software (or maybe even hardware) that runs on linux (or android, whatever). The 'sending card' connects to a PC via the USB connector, which is actually just a SL CP2102 UART-Bridge.

Besides the bad software, the Linsn hardware proved to be pretty realiable and easy to repair. The solder jobs are decent (for a chinese product), they use generic chips you can get everywhere for cheap, and best of all... The nice Mrs. Sarah that kindly provides phone support to all international customers.

To my surprise, Mrs. Sarah is actually a guy that doen't speak english. The first time I called her I was so confused, I accidently ordered some fried noodles to go.

Alright, now that I wasted several hours of my valuable time, let's start with the 'fun' stuff!

Code: [Select]

START 60%

W d8 58 80 ff 00 55 aa 55 aa 55 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 fa

R c5
R c3

W d8 58 80 ff 00 1e 00 22 00 02 00 00 00 00 00 00 00 99 99 99 ff 00 00 00 00 0b
  d8 58 80 ff 00 1f 00 22 10 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59
  d8 58 80 ff 00 18 00 22 20 00 00 00
W d8 58 80 ff 00 1e 00 22 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bf
  d8 58 80 ff 00 1f 00 22 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0
  d8 58 80 ff 00 18 00 22 a0 00 00 00
 
R c5
R c3
R c5
R c3 c5
R c3 c5
R c3 c5
R c3
R c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3

W d8 58 80 ff 00 56 aa 55 aa 00 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 a6

R c5
R c3

W d8 58 80 ff 00 57 aa 55 aa 55 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 fc

R c5
R c3

W d8 58 80 ff 00 18 00 22 00 02 00 00 00 00 00 00 00 99 99 99 ff 00 00 00 00 05
  d8 58 80 ff 00 19 00 22 10 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53
  d8 58 80 ff 00 1a 00 22 20 00 00 00
W d8 58 80 ff 00 18 00 22 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9
  d8 58 80 ff 00 19 00 22 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ca
  d8 58 80 ff 00 1a 00 22 a0 00 00 00

R c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3
R c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3 c5
R c3
R c5
R c3 c5
R c3

W d8 58 80 ff 00 50 aa 55 aa 00 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 a0

R c5
R c3

W d8 58 80 ff 00 1a 00 22 00 02 00 00 00 00 00 00 00 99 99 99 ff 00 00 00 00 07
  d8 58 80 ff 00 1b 00 22 10 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55
  d8 58 80 ff 00 1c 00 22 20 00 00 00
W d8 58 80 ff 00 1a 00 22 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bb
  d8 58 80 ff 00 1b 00 22 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cc
  d8 58 80 ff 00 1c 00 22 a0 00 00 00

R c5
R c3
R c5
R c3 c5
R c3 c5
R c3 c5
R c3
R c5
R c3 c5
R c3 c5
R c3 c5
R c3
R c5
R c3 c5
R c3 c5
R c3 c5
R c3
R c5
R c3 c5
R c3 c5
R c3

W d8 58 80 ff 00 52 aa 55 aa 00 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 a2

R c5
R c3

STOP
What you can see up there is the communication that takes place after setting the brightness to 60%. 'W' means that the software 'writes' to the card, 'R' that it receives/reads stuff. Every 'W' or 'R' indicates a new package. Appearently, the 'sending card' and PC don't do fancy hand-shaking stuff for this, you can just open the software, go to the brightness slider, plug it in, no comm taking place, and this pops up after setting it.

Let's go into some detail. As soon as you click and release the slider, the card always first sends data in the following flavour:

d8 58 80 ff 00 55 aa 55 aa 55 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 fa

Now I don't know for sure - as I have zero exp with this stuff - but this it what I came up with as a newbie:

Green bytes: Those are some sort of instruction to write to a certain type of memory (there are several: DDRs, NVRAMs, EPROMs), and these exact ones are always sent when adjusting brightness, in every package.

Orange byte: Seems to indicate wether it wants to actually write data to this location or skip it.

Blue byte: Probably checksum/parity stuff.

Red bytes: Seems to be the location in the memory the instuction points to. Every time you adjust the brightness, no matter what percentage, it points to 6 different locations. I first thought... Well, this must be some simple shift register, converting the serial data into parallel output for the control circuit. BUT - maybe I just lack the needed experience - I don't really understand how this system works. There seems to be a pattern that doesn't make sense to me:

There are 8 different 'locations'. Every time you start the program, it always points to 57 first. Now the orange bytes tell me if the program will write more data at this point. It always writes to the first location. The card then replies with c5, then c3. After that, the actual data that contains the brightness level is sent (more on that later).

Take a look at the example above again. The orange bytes say '55', indicating that more data specific to this instruction will follow. If the orange bytes are set to '00', it skips to the next instruction after the generic reply from the sending card.

Code: [Select]

W d8 58 80 ff 00 56 aa 55 aa 00 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 a6

R c5
R c3

W d8 58 80 ff 00 57 aa 55 aa 55 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 fc

R c5
R c3

W d8 58 80 ff 00 18 00 22 00 02 00 00 00 00 00 00 00 99 99 99 ff 00 00 00 00 05
  d8 58 80 ff 00 19 00 22 10 05 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53
  d8 58 80 ff 00 1a 00 22 20 00 00 00
W d8 58 80 ff 00 18 00 22 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b9
  d8 58 80 ff 00 19 00 22 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ca
  d8 58 80 ff 00 1a 00 22 a0 00 00 00
In the first package sent, the orange bytes are 00, so the card replies as usual, program skips, then the next instruction in the same flavour follows. Only this time, the red bytes are increased by 1, and the orange is set to '55', and after the reply, data containing brightness follows.

Change brightness for the first time:

Red 57 + Orange 55 -> data follows
Red 50 + Orange 00 -> skip
Red 51 + Orange 55 -> data follows
Red 52 + Orange 00 -> skip
Red 53 + Orange 55 -> data follows
Red 54 + Orange 00 -> skip

Stop. Then if I change it again (or re-set to the same values once more):

Red 55 + Orange 55 -> data follows
Red 56 + Orange 00 -> skip
Red 57 + Orange 55 -> data follows
Red 50 + Orange 00 -> skip
Red 51 + Orange 55 -> data follows
Red 52 + Orange 00 -> skip

It cycles thru the total of 8 'locations', over and over again, and almost always only writes to the odd ones. In rare cases, it seems to mess up and start with even bytes, and only writes to those. I suspect that it may write to 1 location per LED color, and 1 extra per extra screen. So... Red, green, blue, 1 screen -> 3 of 6 writes. Red, green, blue, 2 screens (remember the 2 connectors) -> 6 of 6 writes, BUT i can't confirm this.

As I said, this doesn't make sense at all to me, because why whould it write the SAME value is just wrote seconds ago to a different location? Are these even locations? Why am I doing this stuff?!?!!!!

At this point, you probably know if you even want to continue reading this sort of crap.

There are more patterns and things I recognized.... But I'm really tired right know, and need a break. I will add more information as soon as I'm replenished with chineses crap energy. If you are interested in more of this stuff, or already know what I'm dealing with, need more information/logs, etc. -- Feel free to reply!

Also, if you got (kind of off-topic) questions regarding those big-ass screens or Linsn, or if you're just lonely... whatever... Please don't hesitate to ask/reply here too!

Cheers.

[SeanB]

I have seen the OS of some of these units, and one I saw was running Win98, just from the mouse cursor and the portion of the error box it was half displaying. Funny how most of these get bad blocks with time, you get either one colour missing or stuck on always. At night they can be incredibly bright, especially with flashing graphics.

[chinglish]

Well, most of the screens you see, I estimate around 80%, got configured once, then... nothing. You'd be surprised by how many companies buy screens and don't even know how to config them properly. There aren't many people around (at least here in Germany) that know this kind of tech, and the rest doesn't want to know it.

Try for yourself -- You can download the Linsn software for free. It's a horrible mess, counter-intuitive and unstable. If you press the wrong button at the wrong time you may have to desolder all the EPROMS on the receiver cards or the screen is just dead. I guess most of them are also scared to damage the hardware, which actually happens quite fast. One customer chose the wrong timing, so his LEDs all died within a matter of days because of too much heat/current. The screen wasn't designed for such high active cycle rates, and the software doesn't know the screen-hardware it's talking to. Well, it was a rather small screen, around 15 m², purchased it used.. Still, about Euro 20.000 just gone. Try to find someone who will solder 200.000 thru-hole LEDs onto your segments. Most of them are covered in silicone too... We ended up desoldering all the chips to use them as spare ones.

The bad blocks you discribe are actually quite common and not the software's fault. 90% of the time it's due to moisture, simply drying the segments with a hair dryer fixes it. I cover them with lacquer to prevent this. Works pretty good. The actual LED segments aren't manufactured by Linsn, they do just the control stuff afaik. What also happens a lot is costumers not caring for those block faults, so the pins corrode and eventually just vanish into rusty dust. You can solder new memory chips onto there in a matter of minutes, so it's not really a problem. In most chinese screens, the segments contain several of those memory chips. Because the data is just shifted from left to right thru them at a rather low rate, they need to store the pixeldata locally.

I really wonder why so many people use Windows for critical commercial applications. It's not like you have to output your video from a Windows pc. I never do that. Most of the time, I set up a single linux PC with a windows virtual machine. Linux for the video output runs bare metal, and the hypervisor hosts a headless windows os for the config stuff (we use Windows Embedded, which gives you all the good windows thing without most of the bad stuff. you can even use it as a full desktop without problems). One good thing about the Linsn software is that it's networking capabilities. I connect the Windows guest to our Server with vpn, then manage the screens remotely via webcam.

[dannyf]

I really wonder why so many people use Windows for critical commercial applications.

For the same reason that so many people buy Ford or Chevy, or for the same reason that you fly commercial: you wish you could fly on a Golfstream, but you don't, for a variety of reasons.

The fact that you cannot figure out why others do what they do is no indication of others' irrationality, but only your lack of imagination.

[SL4P]

My first question would be to understand the in-panel decoding and display topology.
This may help understand how the data packets are organised and their contents.

I've built test controllers for some differing Chinese displays (eliminating the provided units for diagnostics purposes) - to specifically test for addressing, bad/sticky LEDs, comms and other issues.

Is each LED pixel or cluster driven by a local micro?
Is the brightness set for the whole panel, by sub panel, or on a pixel-by-pixel basis by the 'local' controller?

Once you have the display panels figured out - it's often productive to build a simple controller for the above reasons - and to understand 99% of the design intentions... which are not always the best way of doing things (;-).

[Psi]

When reverse engineering something like this don't try and understand every single byte in the protocol. Just try things and make your software reproduce the communications you see in the official software.
As you implement more and more of this the understanding of the protocol will come naturally.

e.g. If you can't work out why a particular byte is 0x4F don't worry, send 0x4F when the unit expects it and move on to the serial data which contains more interesting stuff.

At least, i find this a better approach than trying to figure out the exact protocol from the start.

[nuhamind2]

My first question would be to understand the in-panel decoding and display topology.
This may help understand how the data packets are organised and their contents.

I've built test controllers for some differing Chinese displays (eliminating the provided units for diagnostics purposes) - to specifically test for addressing, bad/sticky LEDs, comms and other issues.

Is each LED pixel or cluster driven by a local micro?
Is the brightness set for the whole panel, by sub panel, or on a pixel-by-pixel basis by the 'local' controller?

Once you have the display panels figured out - it's often productive to build a simple controller for the above reasons - and to understand 99% of the design intentions... which are not always the best way of doing things (;-).

Check out adafruit for the led display this controller control (uh).  It is basically ton of  shift register.  The control signal is latch, output enable and clock the data is R1,G1,B1 and R2,G2,B2. They both provide data for upper half and bottom half of display.

[chinglish]

The fact that you cannot figure out why others do what they do is no indication of others' irrationality, but only your lack of imagination.

Well, I thought about it a bit more, and I realized that I actually don't wonder why they do. However, I can't quite figure out what you were trying to say. My imagination works fine, it's just that I don't like to rely on assumptions, rather than asking a question.

Regarding irrationality... I hope you don't consider using consumer-targeted desktop OS for such applications rational. Even Microsoft won't recommend this. Maybe... :p

e.g. If you can't work out why a particular byte is 0x4F don't worry, send 0x4F when the unit expects it and move on to the serial data which contains more interesting stuff.

At least, i find this a better approach than trying to figure out the exact protocol from the start.

Couldn't agree more, but it's quite complicated to test this 'live' with an actual screen attached. Will have to wait till I got one @home. The other thing is... I don't really like this kind of approach. Yes, it works, and may be faster, but to me, it's the 'figuring out' what brings most of the fun, the moment where you realize that you understand everything, rather then hard-coding some bitstreams into an application. I will probably end up doing it, however, my goal is to completely eliminate the need for any Linsn software, and that requires a LOT more knowledge, because those other instruction seem to be completely different. My first, smaller goal is to understand the basic things. Where these values are stored, and how.

Check out adafruit for the led display this controller control (uh).  It is basically ton of  shift register.  The control signal is latch, output enable and clock the data is R1,G1,B1 and R2,G2,B2. They both provide data for upper half and bottom half of display.

This basically. Although it depends on the type of screen what the receiver does with the 2 seperate RGB data signals. Sometimes they divide the whole screen, sometimes the segments are divided... Never know whats comming next. The configuration of the screen is quite complex. Altho I do understand most of it, I often spend days on figuring out how this certain type of segment is adressed. Try to find a manual for these things....

It's getting a bit late here (4:20 AM), will provide you with some more info regarding the Linsn universe tomorrow.

Thanks so far!

[nuhamind2]

This basically. Although it depends on the type of screen what the receiver does with the 2 seperate RGB data signals. Sometimes they divide the whole screen, sometimes the segments are divided... Never know whats comming next. The configuration of the screen is quite complex. Altho I do understand most of it, I often spend days on figuring out how this certain type of segment is adressed. Try to find a manual for these things....

I don't have the display myself, but adafruit tutorial show it clearly how it's work. They even make tutorial how to drive these display by arduino and fpga. The smallest module is 16x32 or 32x32. On the 16x32 you drive 8x32 upper half with rgb1 and the 8x32 bottom half with rgb2.On 32x32 rgb1 drive 16x32 upper half and rgb2 drive 16x32 bottom half. Oh and I forgot on thing, there is more control signal a,b,c for 16x32 and a,b,c,d for 32x32. These signal is for multiplexing which line you're powering. For 16x32 you only need 3 select signalsince you select 1 line over 8 (1/8 duty cycle) and for 32x32 you need 4 select signal (1 from 16).
The chip count and the led count is matching. A single module has 12 16-bit shift register (constant current output) that's mean 6 shift register for each half . 6 shift register equal to 96 output equal to number of led in a row which is 32 pixel times 3 (R,G,B)
A bigger screen is basically those small module tail chained.

[Psi]

Couldn't agree more, but it's quite complicated to test this 'live' with an actual screen attached. Will have to wait till I got one @home.

True, if you only have limited access to the screen then you're really forced to do it the slow way.

I would assemble a long test plan of things you want to try sending the display (to confirm your assumptions or prove them wrong).
You want to be able to rock up to the display and quickly fire many commands at it while recording the communication and noting down exactly what the display does.
Then you can analyse the data you collected later and start to understand the protocol during the times when you don't have display access.
At first this will just create more questions.
So write more tests to run next time you have access and repeat.
Try to fork the tests a bit to maximize your results, like, "if test Y does what i expect then try test A and B but if test Y fails try test C and D"

Eventually you will have so much data you can confirm/reject assumptions by looking at your previous communication logs without needing physical access .

[Artlav]

Also, if you got (kind of off-topic) questions regarding those big-ass screens or Linsn, or if you're just lonely... whatever... Please don't hesitate to ask/reply here too!

Germany, right?
Do you have legal restrictions on where you put such screens over there?

There are a few places in Moscow where you drive along an avenue at night, curve out of a turn, and get a face full of building-sized LED screen with blinking advertisements.

I was kind of wondering if such triumphs of commerce over safety are common in other parts of the world.

[abyrvalg]

chinglish, why don't just try their source code? http://www.linsn.com/LED/LedSetSp.exe

[poorchava]

Dunno how about Germany but in Poland we have a huge problem with this. Those screens are typically mounted at big crossings / communication hubs. Theoretically there is a ragulation, that it is forbidden to place near public roads any devices that emit of reflect light in a manner that can blind or distract drivers. The problem is that there is no hard limit (eg. that much lux, that much lumen blablabla) and there is no penalty specified for this.

Most of the owners of such billboards set them to 100% all the time, because their boss or client cannot ask "why they are not using all the attention attraction possible" (that's an actual quote...). There have been few cases, when people from nearby apartament blocks dealt with the billboard. In some cases by repeatedly calling police on the owner, in some cases they sued the owner, but in most cases there were more direct countermeasures (bricks, stones, spraypaint, paintball guns, boltcutters at the power cable etc).

[amyk]

Now I have a much better understanding of how this could happen:

[dannyf]

I hope you don't consider using consumer-targeted desktop OS for such applications rational.

Why not?

Even Microsoft won't recommend this.

Who cares about what Microsoft recommends or not.

Microsoft didn't recommend you to reverse engineer the board; you did it anyway;
Microsoft didn't recommend you to go to sleep last night; you did it anyway;
Microsoft didn't recommend you to date that girl; you did it anyway;
Microsoft didn't recommend you to drink that 6-pack; you did it anyway;
....

If you have to live your life by what Microsoft (or any other company/entity) recommends, it is a life not worth living. You are a human, not a computer. So live by what you think is right, not what Microsoft thinks is right.

[TerraHertz]

Minor point, but sequences like "55 aa 55 aa 55" are usually present as 'magic numbers' where the programmer though something like "I know, lets have some bytes here to check the comms link is working and there are no stuck bits or stuff."

Because those are alternating bit patterns: 55= 01010101, aa=10101010.

[made2hack]

What's a Constumer?

Is that a Consumer-Customer?

Some kind of new economic model hybrid???

The Chinese are way ahead of the rest on this one  O0

[chinglish]

Dunno how about Germany but in Poland we have a huge problem with this

None so far, because...

Do you have legal restrictions on where you put such screens over there?

We got lots of restrictions. Some years ago, you couldn't even show animations, or pictures with a lot of green or red content for example, because of - quote - "possible confusion with traffic lights"... I'm no expert on traffic safety, but that seemed a bit silly and over the top. They eventually came to that conclusion too it seems, as the restrictions get less and less, but still, it's a lot of trouble even getting a building permission for smaller ones. However, I think that's a good thing, and if you install such screens, you should apply some common sense yourself to not cause any issues. There's enough money out there to make without pushing the law to it's limits. But that's just my POV.

chinglish, why don't just try their source code? http://www.linsn.com/LED/LedSetSp.exe

I don't exactly consider some buggy binaries 'source code'. I might end up disassembling some libraries, but this is far too complex for my untrained mind to understand, I presume.  You are welcome to try if you know that kinda stuff.

Who cares about what Microsoft recommends or not.

Microsoft didn't recommend you to reverse engineer the board; you did it anyway;
Microsoft didn't recommend you to go to sleep last night; you did it anyway;
Microsoft didn't recommend you to date that girl; you did it anyway;
Microsoft didn't recommend you to drink that 6-pack; you did it anyway;
....

If you have to live your life by what Microsoft (or any other company/entity) recommends, it is a life not worth living. You are a human, not a computer. So live by what you think is right, not what Microsoft thinks is right.

Please stop wasting my time by trolling this thread. Thank you. 

Minor point, but sequences like "55 aa 55 aa 55" are usually present as 'magic numbers' where the programmer though something like "I know, lets have some bytes here to check the comms link is working and there are no stuck bits or stuff."

I see, but would there be any reason to use such a 'magic' sequence to actually control stuff (see my first post) too? And if you are right... To what conclusions might this lead? E.g., I assume using such safety measures would only be reasonable if the code is somehow processed further by something that has control over way more stuff than just simple settings.

Let me ask some more noob questions....

Is there any pattern you recognize that might be typical for a certain type hardware? Or the other way around? For example... "Such code can only be processed by XXXX", or " a YYYY is not capable of that kind of stuff", and so on.

What I do know is, that the brightness settings get saved locally somewhere on the sending card, and that they're first written to some volatile memory. If I power down the card without pressing 'save', the previously stored values are displayed upon opening the software, and they do get stored without a screen attached. Looking at the hardware and fpga datasheet, the Spartan seems to be running in Master SPI Mode (see http://www.xilinx.com/support/documentation/user_guides/ug332.pdf page 101...), because of the DDR chips and spi flash underneath. This would also allow for storing user data in the spi flash thing, which seems to be the only non-volatile memory onboard.

Because all the interface pins are user I/O after configuration, the FPGA application can
continue to use the SPI Flash interface pins to communicate with the SPI Flash PROM, as
shown in Figure 4-5. SPI Flash PROMs offer random-accessible, byte-addressable,
read/write, nonvolatile storage to the FPGA application.

There are some other interesting things in the Spartan datasheet, like

the [...] Winbond W25X-series PROMs support a feature
called Dual-Output SPI that transmits two data bits per clock cycle but requires a special
read command. The FPGA does not support this command for configuration, but the
FPGA application can issue the command after configuration.

or

The FPGA does not contain a dedicated SPI interface, except for configuration.
Consequently, to access the SPI Flash or other SPI devices after configuration, the FPGA
application must contain an SPI bus master interface. Xilinx provides SPI interface cores, as
described below.

They talk about MicroBlaze, PicoBlaze, etc... which are Microprocessors 'coded' into the fpga.

I think it might lead better understanding of the data if anyone could confirm some of these assumptions. The Spartan and everything related to is very well documented.

I'll keep you updated. Will be doing some more practical tests tomorrow, as suggested.

Cheers

EDIT: Btw, this is not just about reversing the board, it's also about learning stuff. This is my style of doing things... I rather spend 10x the hours to understand what I'm dealing with, because it WILL come in handy. Always does.

[dannyf]

This is my style of doing things..

I suppose that's recommended by Microsoft?

[dannyf]

Because those are alternating bit patterns: 55= 01010101, aa=10101010.

It can be and is often used for baud rate detection.

However, it could also be the result of wrong baud rates. Renesas has a paper on that.

[abyrvalg]

Your dumps doesn't match the things I see in LedCtrl.dll: the fill byte should be CA, not D8. Are you tapping TxD/RxD lines directly? Use 115200 8-N-2 (2 stop bits !) params in this case. Or just use some sw-side COM/USB monitor.

Reading Spartan docs is a waste of time: this protocol doesn't originate from Xilinx, it just runs on this chip, but is coded by Linsn.

[chinglish]

However, it could also be the result of wrong baud rates. Renesas has a paper on that.

I appreciate your constructive feedback.

I tried to send some commands using different baud rates, but 115200 was the only one that got me some response. The software I used to cap the data also detected that rate. See below.

Your dumps doesn't match the things I see in LedCtrl.dll: the fill byte should be CA, not D8. Are you tapping TxD/RxD lines directly? Use 115200 8-N-2 (2 stop bits !) params in this case. Or just use some sw-side COM/USB monitor.

I captured the data using some sw called 'Serial Port Monitor'. As the board is missing some components near the RS232 port (there are 2 versions, we use the USB one), I figured it might be safer to monitor the communication this way. Have to check on the stop bits though. I assumed the software was able to detect the correct settings. Is that not the case?

What LED software did you download? There are different models of the sending card, each uses a different version number. The correct one for this type would be LedStudio9.60D. There is also a simplified version called LedSet, which seems to work. The library you mentioned presumably belongs to V10, which is incompatible.

I uploaded the working one to my dropbox: https://www.dropbox.com/s/0k2jzdldri4x41s/LedSoft8.zip

Reading Spartan docs is a waste of time: this protocol doesn't originate from Xilinx, it just runs on this chip, but is coded by Linsn.

I see. I assumed it may be possible that Linsn didn't actually code that stuff, leaving the (generic) serial communication/data storage stuff to some pre-built soft-micro (see my previous post), and just reading the values from the mem using their own code. Dunno if that's even possible, as I never used FPGAs in my (rather simple) projects, but such an approach would fit their general attitude...

EDIT: I just read a paper about decompiling xilinx bit files, but it seems it's only been done in therory... Anyone know anything about this?

[abyrvalg]

I've tried a dll from this package http://www.linsn.com/LED/LedSetSp.exe first. Your software is different - it uses D8 fill bytes, so your dumps gets sense now.
Which LedSet are you talking about? I would like to check that one too: your sw has all comms linked into LedStudio.exe, which isn't so handy. Perhaps LedSet will have a separate dll for that.

[chinglish]

Unbelievable! Looking into that LedSet folder, which I never did before (because I never really used this software outside this 'reversal').... There actually IS source code... What the hell?! I feel pretty dumb right now, I thougt you were (jokingly) referring to the binaries as source code... LOL

However, the version you were looking into is still different from mine, use this one: LedSet10.zip

I skipped thru the files, and didn't find information regarding the serial data, but it really looks promising and might even be sufficient to implement this into a custom, more stable application with only core features!

Thanks so far, really appreciate your effords.

Oh, and here is a more complete serial data dump: https://www.dropbox.com/s/61l7wgoqp7ivt2l/60percent100percent.html

What I did there is setting the brightness to 60% 3 times, then 100% 3 times in a row. Looking at the time stamps you can distinguish these events, as I waited for like 3-5 seconds till the next click.

I'll try to contact Linsn tomorrow... Maybe they just send me the source for the precompiled bit.

[chinglish]

I updated the dropbox link, packed the wrong version (the one you were using). Sorry!