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

[abyrvalg]

There is no protocol itself in the sources, they just use LedCtrl.dll which contains functions like SetBrightness.

Since I did some disasm already, I'll post the results:

Serial link parameters: 115200, 8 bits, NONE parity, 2 stop bits

frame type 50 (single frame at the start) format:
W d8 58 80 - const
   ff 00 - cmd_h cmd_l
   55 - frame_type=50 | (++seq & 7)
   aa 55 aa - const
   55 - param
   d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 d8 - fill
   fa - checksum = byte sum buf[3:]
R c5 c3 - this means "OK"

frame type 18 (frame that repeats 16 times with different data) has the same header (but with frame_type=18) and checksum, but I didn't studied the body part (between type | seq and checksum) yet.

[chinglish]

There is no protocol itself in the sources, they just use LedCtrl.dll which contains functions like SetBrightness.

Looking at the dll and code, it seems EVERYTHING is in there... 5mb? It's really annyoing if you lack the needed asm skills, confuses the sht out of me.

The source is just a cosmetic thing to.. I don't know, maybe slap your company name on it. THANKS LINSN.

Your data looks good though!

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

That's a brightness data containing package. The purple bytes seem to contain the actual brightness data, see the new dump. The 55 or 00 - 'param' - seems to indicate wether a second screen is attached. What I'm most interested in is how the brightness input dec 0-100 gets translated into that sequence... Will look into it too.


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 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 1c 00 22 00 02 00 00 00 00 00 00 00 99 99 99 ff 00 00 00 00 09

That would be 60%.


d8 58 80 ff 00 1e 00 22 00 02 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 3d
...
d8 58 80 ff 00 18 00 22 00 02 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 37
...
d8 58 80 ff 00 1a 00 22 00 02 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 39

That's 100%.

ff ff ff ff -> 100
99 99 99 ff -> 60

Looking at the software it's clear that the brightness value must get written 3 times, because you can also set RBG separatly to change the color temperature.

Also, the frame type bytes of the initial packet correspond to the bytes of the  packet that contains the actual brightness data.

Type 51 -> Type 1a
53 -> 1c
55 -> 1e
57 -> 18

Looking at the dump it's clear that every time such a packet gets sent, the type is incresed by 1 until it hits 57, then repeats, corresponding to your disasm. It's also evident that the type doesn't follow some specific pattern related to the brightness values. It doesn't really matter what type the packet contains, as long as it's in the 8 bit range from 50h-57h and increased by 1 after the first brightness value has been transmitted/was adressed. After It's been transmitted, you can start from anywhere in that range without issues.

Going to bed now, will update as soon as I figured out some more things regarding 2nd screen and seperate values for the 3 colors.

CHeers

[abyrvalg]

The type field is combined with packet sequence: lower 3 bits are sequence, rest is type. There are two types used in your dump: single packets with type 50 (type gets ORed with seq, so you see values like 55 there) and 16x batches of type 18 packets (where the brightness value is). The sequence var is common for all packet types and gets incremented on every send, but since it is masked to 3 bits it rolls over to 0 after reaching 7: 0, 1, 2,...7, 0, 1...

[abyrvalg]

Frame type 18 (write regirsters):
d8 58 80 - const
ff 00 - cmd (I think cmd is wrong name, it's something like board address I guess)
18 - type 18 | (seq & 7)
00 22 00 - regs start address
02 00 00 00 00 00 00 00 99 99 99 ff 00 00 00 00 - regs data
05 - checksum (sum of bytes 3-last)

set brightness:
SendFrame50(0xFF00, 0x55) //start write regs
for(i=0; i<0x100; i+=0x10) //write regdata[0x100] to addr 0x002200 in 0x10 chunks
{
      SendFrame18(0xFF00, 0x002200+i, regdata+i, 0x10)
}
SendFrame50(0xFF00, 0x00) //end write regs

regdata[8,9,A] bytes are 3 separate brightness values (R,G,B channels?). The calculation is simple: 0xFF * 60 / 100 = 0x99 (0xFF * 60%).

Looks like many other params (contrast etc) are just different locations within regdata[0x100].

[chinglish]

Awesome!

Funny though, I actually discovered the code myself during analysis of my disassembly, yet i failed to verify this is the correct sequence for actually setting the brightness. I used hex-rays to generate pseudo-code of instructions related to LNS_SetBright and renamed the vars quite confusingly in a hurry, I guess that was quite a fail. On the other hand, my results are pretty much pleasing considering I know close to nothing about assembler. Just kind of figured it out myself in the process. 

Looks like many other params (contrast etc) are just different locations within regdata[0x100].

So I guess the data regarding image adjustment is all written to a pretty restricted area in memory? This might be interesting to set up several parameters at once using a single frame (or frame sequence like the dumped ones), instead of sending hugh amounts of frames.

The sequence var is common for all packet types and gets incremented on every send

What do you think is the purpose of the seq var?

I'm a bit afraid to test this out on a live card, as I only got one here right now and I need it for live testing of new screen parts that are going to be isntalled within the next 3-10 weeks. I really don't want to write possibly messed up data to locations i shouldn't. You never know how those things react, I whitnessed a lot of strange problems using them in the past few years.

However, as stated before, these frames seem to only write to volatile memory. I will upload a new dump containing the frames to actually write this to flash. I hope these instructions are less complex, maybe something in the style of 'alright, now write this to flash', instead of a completely different instruction containing the actual data..

BTW: What software do you use for disassembly?

cheers

EDIT: I just noticed.... 99 99 99, 3 values... so it actually writes essentially the same data to the same location 3 times in a row?

[bookaboo]

Interesting about the code.

What applications do you have in mind once you can control the modules?
I find the way the screen acts as a 2nd monitor to be great for most applications. Although LED Studio is a rubbish you can just write a small prog in VB to do what you need as its wysisyg.
The only downside is that you need to have a PC running all the time, which is cumbersome if you just want to repeat a cycle of text/images, would it be possible to make a psuedo-interface card that stores a cycle of graphics and just spits it at the screen in a loop?

[chinglish]

What applications do you have in mind once you can control the modules?
I find the way the screen acts as a 2nd monitor to be great for most applications. Although LED Studio is a rubbish you can just write a small prog in VB to do what you need as its wysisyg.
The only downside is that you need to have a PC running all the time, which is cumbersome if you just want to repeat a cycle of text/images, would it be possible to make a psuedo-interface card that stores a cycle of graphics and just spits it at the screen in a loop?

Well, I would't go so far, there are more simple solutions that work nearly out-of-the-box.

For example: Write some small program to control the values you need to set while the screen is running and grab a small pc-like device that runs linux, like the raspberry-pi (which has hdmi/dvi out). You could program the control software to periodically read the config data from a plain text file and run another (already existing) software to display pictures in a specific folder. A simple ftp-server could be installed to update the config file and pictures remotely. As the Pi got an ethernet connection, you just need to plug it into some existend network, set up dhcp, and you're good to go.

Total cost: 25$

Another approach I had in mind would be to build a hardware-controller using something generic like an arduino. It's cheap and quick to program/build, with all those shields available. That way you could update your code to control different types of screens with minimum software overhead, yet you'd have all the advantages of a hardware solution. But that would be something i'd only consider for say public viewing style applications, or other live screnarios where remote management is unnessesary or impractical.

The whole point of this reverse engineering is to eliminate the need for windows, which would reduce costs significantly, and also increase reliability (which are the top concerns in commercial applications).

now that you have started to do something with it, may i suggest you improve the software, name it your own, and sell a new and improved version of this LED wall?

I don't plan on doing so currently. My job is to keep these things running, and this will make it a lot easier. That's all I wanted.

Also, as I wouldn't be able to accomplish this alone, it would be quite unfair to let some of you guy do a major part fo the work, then just sell it for my own profit. However, I can assure the effort one puts in here won't go unnoticed if money will be made from this. 

[bookaboo]

Would be glad to help out in any way I can. I have a test rig with a Linsn LX801 and some P16 RGB modules that were used to make a very customised set up but are now awaiting a suitable project.
I will have to dig the parts out and see what version the send card is (and if the cards are still working). I will report back.

[chinglish]

Would be glad to help out in any way I can. I have a test rig with a Linsn LX801 and some P16 RGB modules that were used to make a very customised set up but are now awaiting a suitable project.
I will have to dig the parts out and see what version the send card is (and if the cards are still working). I will report back.

Good to hear. Please keep in mind that different generations of the sending card need different software, so we gotta make sure those match.

Cheers

[bookaboo]

Sending cards have come down in price a lot, if it makes things easier you could just chose one version and change the send card each time.

[chinglish]

Indeed. For you to test this stuff out though you need a matching one (and I currently only got the one you can see in the first post at my disposal).

[abyrvalg]

chinglish, can you post what exactly do you see in hex-rays there?

[mikeselectricstuff]

Interesting about the code.

What applications do you have in mind once you can control the modules?
I find the way the screen acts as a 2nd monitor to be great for most applications. Although LED Studio is a rubbish you can just write a small prog in VB to do what you need as its wysisyg.
The only downside is that you need to have a PC running all the time, which is cumbersome if you just want to repeat a cycle of text/images, would it be possible to make a psuedo-interface card that stores a cycle of graphics and just spits it at the screen in a loop?

There are versions of this range that will play video from SD cards in standalone mode.

[Myles]

Hello from Myles in Australia
I am very impressed with this post and the forum, I have been looking for information on the Linsn cards with very little luck. Can I please have help with some beginner questions.
1. What is the protocol between the "sending" and "receiving" cards? RS232, RS485 or some crazy Chinese invention
2. Could someone please give me the pin-out of the RJ45 socket on the sending card
3. Is there a way the create a wireless link between the sending and receiving cards ( I want real time synchronous control without the cat5 cable)

Thank you so much for any help you can give

Myles 

[bookaboo]

Hello from Myles in Australia
I am very impressed with this post and the forum, I have been looking for information on the Linsn cards with very little luck. Can I please have help with some beginner questions.
1. What is the protocol between the "sending" and "receiving" cards? RS232, RS485 or some crazy Chinese invention
2. Could someone please give me the pin-out of the RJ45 socket on the sending card
3. Is there a way the create a wireless link between the sending and receiving cards ( I want real time synchronous control without the cat5 cable)

Thank you so much for any help you can give

Myles 

1) OP has figured it to be some crazy Chinese invention
2) Pass
3) This is possible, I've been quoted for such a system and I'm just waiting on the technical info.

There are versions of this range that will play video from SD cards in standalone mode.

Is that a Linsn product? Something like that would be most useful for a probable upcoming project I'm doing.

[Myles]

Hi From Myles again

Could you give me some details of the wireless option you have been quoted, what sort of price are you looking at?

Thank you

[chinglish]

1. What is the protocol between the "sending" and "receiving" cards? RS232, RS485 or some crazy Chinese invention
2. Could someone please give me the pin-out of the RJ45 socket on the sending card
3. Is there a way the create a wireless link between the sending and receiving cards ( I want real time synchronous control without the cat5 cable)

1. Not a widely used protocol outside such products, if at all, probably Linsn only. Don't know for sure. The connection to the screen is made via cat5.

2. I'm afraid not. I didn't spend too much time on going into such detail regarding parts of the system I'm currently not very interested in. I will take a look at the card. In the meantime, go look at adafruit, appearantly theres lots of information on the Linsn.

3. http://www.szlamp.net/LED-controller-and-software-F_i6.html Never seen it, never used it. Probably crap and not what youre looking for. Might be interesting though.

The only (easy and already available) wireless solutions i could think of would be connecting a DVI over ethernet style device to the sending card, then hook it up to a wireless AP (never tried this, but there sure will be limitations regarding range and reliability), or just connecting a (mini-) computer to the card, that streams the video wirelessly. I personally hate WiFi in such applications, because it's limited in transmit power (legal reasons), thus range, and pretty much unreliable, because those freq are used everywhere by tons of people. Even in microwave ovens. Consumer-style hardware is just not the way-to-go if you ask me.

Why exactly do you need a wireless connection?

chinglish, can you post what exactly do you see in hex-rays there?

Can't remember tbh. Have to disassemble the thing again to look it up. Pretty busy right now, so might take a day or two. What exactly do you need to know? Want screenshots? Code?

There are versions of this range that will play video from SD cards in standalone mode.

Do you have any interesting info on the hardware of the Linsn system? Feel free to speculate, guess, whatever. Could be useful to me!

Thanks guys, will be back.

[chinglish]

chinglish, can you post what exactly do you see in hex-rays there?

Code: [Select]

int __usercall sub_10090E40<eax>(signed int a1<eax>, signed int a2<ecx>)
{
  if ( a1 >= 0 )
  {
    if ( a1 > 100 )
      a1 = 100;
  }
  else
  {
    a1 = 0;
  }
  if ( a2 < 0 || a2 >= (signed int)wParam )
    sub_100FF1DD();
  *(_DWORD *)(*(_DWORD *)(dword_10367F04 + 4 * a2) + 8) = a1;
  return sub_100CCF00(a2, 0);
}

Code: [Select]

char __userpurge sub_100CCF00<al>(int a1<esi>, __int64 a2)
{
  int v2; // edi@3
  int v3; // eax@3
  signed int v4; // eax@4
  int v5; // ecx@4
  signed int v6; // eax@7
  int v7; // ecx@7
  bool v8; // cl@11
  int v9; // eax@14
  int v10; // edx@15
  int v11; // ecx@18
  int v12; // eax@20
  char v13; // bl@22
  char v15; // [sp+2Dh] [bp-1Bh]@3
  char v16; // [sp+2Eh] [bp-1Ah]@3
  char v17; // [sp+2Fh] [bp-19h]@3
  int v18; // [sp+34h] [bp-14h]@3
  int v19; // [sp+38h] [bp-10h]@3
  __int16 v20; // [sp+3Ch] [bp-Ch]@3
  __int16 v21; // [sp+40h] [bp-8h]@3
  __int16 v22; // [sp+44h] [bp-4h]@3

  if ( (signed int)a2 < 0 || (signed int)a2 >= *(_DWORD *)(a1 + 16648) )
    sub_100FF1DD();
  v2 = *(_DWORD *)(*(_DWORD *)(a1 + 16644) + 4 * a2);
  v3 = *(_DWORD *)(a1 + 16424);
  v18 = *(_DWORD *)(v3 + 13457) & 1;
  v19 = (*(_DWORD *)(v3 + 13457) >> 1) & 1;
  v20 = *(_WORD *)(v3 + 13461);
  v21 = *(_WORD *)(v3 + 13463);
  v15 = *(_BYTE *)(v3 + 13465);
  v16 = *(_BYTE *)(v3 + 13466);
  v17 = *(_BYTE *)(v3 + 13467);
  v22 = *(_WORD *)(v3 + 13473);
  if ( *(_DWORD *)(v2 + 40) )
  {
    v4 = 0;
    v5 = v2 + 56;
    do
    {
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 14993) = *(_WORD *)(v5 - 2);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 15505) = *(_WORD *)v5;
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 16017) = *(_WORD *)(v5 + 2);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 12945) = *(_WORD *)(v5 + 4);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 14995) = *(_WORD *)(v5 + 6);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 15507) = *(_WORD *)(v5 + 8);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 16019) = *(_WORD *)(v5 + 10);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 12947) = *(_WORD *)(v5 + 12);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 14997) = *(_WORD *)(v5 + 14);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 15509) = *(_WORD *)(v5 + 16);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 16021) = *(_WORD *)(v5 + 18);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 12949) = *(_WORD *)(v5 + 20);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 14999) = *(_WORD *)(v5 + 22);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 15511) = *(_WORD *)(v5 + 24);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 16023) = *(_WORD *)(v5 + 26);
      *(_WORD *)(v4 + *(_DWORD *)(a1 + 16424) + 12951) = *(_WORD *)(v5 + 28);
      v4 += 8;
      v5 += 32;
    }
    while ( v4 < 512 );
  }
  else
  {
    sub_10091370(
      *(_DWORD *)(v2 + 44),
      *(_DWORD *)(a1 + 16424) + 12945,
      (double)(*(_DWORD *)(v2 + 24) * *(_DWORD *)(v2 + 2116) / 100));
    v6 = 0;
    v7 = v2 + 56;
    do
    {
      *(_WORD *)(v7 - 2) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 14993);
      *(_WORD *)v7 = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 15505);
      *(_WORD *)(v7 + 2) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 16017);
      *(_WORD *)(v7 + 4) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 12945);
      *(_WORD *)(v7 + 6) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 14995);
      *(_WORD *)(v7 + 8) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 15507);
      *(_WORD *)(v7 + 10) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 16019);
      *(_WORD *)(v7 + 12) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 12947);
      *(_WORD *)(v7 + 14) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 14997);
      *(_WORD *)(v7 + 16) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 15509);
      *(_WORD *)(v7 + 18) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 16021);
      *(_WORD *)(v7 + 20) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 12949);
      *(_WORD *)(v7 + 22) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 14999);
      *(_WORD *)(v7 + 24) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 15511);
      *(_WORD *)(v7 + 26) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 16023);
      *(_WORD *)(v7 + 28) = *(_WORD *)(*(_DWORD *)(a1 + 16424) + v6 + 12951);
      v6 += 8;
      v7 += 32;
    }
    while ( v6 < 512 );
  }
  v8 = *(_DWORD *)(v2 + 2420) && *(_DWORD *)(v2 + 2156) == 3;
  *(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457) ^= (v8 ^ (unsigned __int8)*(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457)) & 1;
  *(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457) ^= (*(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457) ^ 2
                                                                                                * *(_DWORD *)(v2 + 32)) & 2;
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13461) = *(_WORD *)(v2 + 2160);
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13463) = *(_WORD *)(v2 + 2164);
  *(_BYTE *)(*(_DWORD *)(a1 + 16424) + 13465) = ((signed int)((unsigned __int64)(448600744275i64
                                                                               * *(_DWORD *)(v2 + 8)
                                                                               * *(_DWORD *)(v2 + 12)) >> 32) >> 12)
                                              + ((unsigned int)((unsigned __int64)(448600744275i64
                                                                                 * *(_DWORD *)(v2 + 8)
                                                                                 * *(_DWORD *)(v2 + 12)) >> 32) >> 31);
  *(_BYTE *)(*(_DWORD *)(a1 + 16424) + 13466) = ((signed int)((unsigned __int64)(448600744275i64
                                                                               * *(_DWORD *)(v2 + 8)
                                                                               * *(_DWORD *)(v2 + 16)) >> 32) >> 12)
                                              + ((unsigned int)((unsigned __int64)(448600744275i64
                                                                                 * *(_DWORD *)(v2 + 8)
                                                                                 * *(_DWORD *)(v2 + 16)) >> 32) >> 31);
  *(_BYTE *)(*(_DWORD *)(a1 + 16424) + 13467) = ((signed int)((unsigned __int64)(448600744275i64
                                                                               * *(_DWORD *)(v2 + 8)
                                                                               * *(_DWORD *)(v2 + 20)) >> 32) >> 12)
                                              + ((unsigned int)((unsigned __int64)(448600744275i64
                                                                                 * *(_DWORD *)(v2 + 8)
                                                                                 * *(_DWORD *)(v2 + 20)) >> 32) >> 31);
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13473) = *(_WORD *)(v2 + 52);
  if ( *(_DWORD *)(v2 + 36) && (v9 = *(_DWORD *)(v2 + 2168), v9 > 0) && (v10 = *(_DWORD *)(v2 + 2180), v10 > 0) )
  {
    if ( *(_DWORD *)(v2 + 2176) < v9 )
      *(_DWORD *)(v2 + 2176) = v9;
    v11 = *(_DWORD *)(v2 + 2172);
    if ( v10 < v11 )
      *(_DWORD *)(v2 + 2180) = v11;
    *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13469) = (v9 << 16) / *(_DWORD *)(v2 + 2176);
    v12 = (*(_DWORD *)(v2 + 2172) << 16) / *(_DWORD *)(v2 + 2180);
  }
  else
  {
    *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13469) = 0;
    LOWORD(v12) = 0;
  }
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13471) = v12;
  v13 = sub_100998A0(a2, HIDWORD(a2));
  *(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457) ^= ((unsigned __int8)v18 ^ (unsigned __int8)*(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457)) & 1;
  *(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457) ^= (*(_DWORD *)(*(_DWORD *)(a1 + 16424) + 13457) ^ 2 * v19) & 2;
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13461) = v20;
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13463) = v21;
  *(_BYTE *)(*(_DWORD *)(a1 + 16424) + 13465) = v15;
  *(_BYTE *)(*(_DWORD *)(a1 + 16424) + 13466) = v16;
  *(_BYTE *)(*(_DWORD *)(a1 + 16424) + 13467) = v17;
  *(_WORD *)(*(_DWORD *)(a1 + 16424) + 13473) = v22;
  sub_10091600();
  return v13;
}

I think this is a part of the code. As I didn't rename vars and.. well, didn't do anything at all this time, I'm not 100% sure. Please report back. As said before, am pretty busy atm, so I can't really put much time into this until saturday. Also, check PM.

[bookaboo]

Hi From Myles again

Could you give me some details of the wireless option you have been quoted, what sort of price are you looking at?

Thank you

These are the two wireless controllers I've been recommended:
http://www.ledsign.cc/productK20.html
http://www.ledsign.cc/productA31.html

I haven't had a chance to look at the spec in detail (travelling at the moment), also I have not used this company before so can't vouch for anything.

[chinglish]

LAN/Internet/3G/GPRS/Wifi/RF

Sounds like you can only upload stuff to the attached sd card. Live video over GPRS? Yea..

Don't see any reason to use this if you already have a sending card. The Pi supports SIM, ethernet, USB and HDMI for a little over 25 bucks and you can run a linux distribution of you choice on it. I think I wouldn't even use it if I didn't have the sending card. It's most probably cheaper and supports higher resolutions for big screens, maybe even live video stream (never tested it).

[asasensio]

Hi there,

I work probably in the biggest LED screen suppliers company in Spain. I've been working for at least 6 years with LED screens and I normally use LINSN controllers.

That's a great idea, I'm looking for this project for long time ago. I'm wondering to use a PI for every LED screen controlled with a external server. I talk often with LINSN company developers, there's some people that knows english, unfortunately they are not able to help new external developers or hackers (entrerprise policy). For this project i recomend you to use LedSetp10 (you can download it from linsn website). This application is for change brightness, contrast, send CON and RCG file.

There's some mistakes in your post:


LINSN always is based on the last generation but every new one has new features.

Both outputs U and D works perfectly.


If I could help in some case let me know it. I'm very interested in work together.

[David_AVD]

I have a sign panel at the moment that has a small controller card and 20 8x16 single colour modules.

The LED modules seem like they could be fitted with R, G & B LEDs but they only have the red (or green) fitted on the modules I have.

A preliminary look at the 16 pin data connectors shows that there are 5 signal lines (2 pins each), 4 grounds and 2 other pins that don't seem to be used.

I haven't setup a capture on the signal lines yet, but could it be clock, load (select) and 3 data lines (one for each colour) ?

The modules are similar to these, but have no chips visible and separate screw posts for the +5 and 0V connections.

[amyk]

You may want to watch this:

[David_AVD]

I watched that video the other week, but thought these may be a simpler version as I didn't think the modules I have support intensity control.

Sounds like I need to capture some data and go from there.

[mikeselectricstuff]

I have a sign panel at the moment that has a small controller card and 20 8x16 single colour modules.

The LED modules seem like they could be fitted with R, G & B LEDs but they only have the red (or green) fitted on the modules I have.

A preliminary look at the 16 pin data connectors shows that there are 5 signal lines (2 pins each), 4 grounds and 2 other pins that don't seem to be used.

I haven't setup a capture on the signal lines yet, but could it be clock, load (select) and 3 data lines (one for each colour) ?

The modules are similar to these, but have no chips visible and separate screw posts for the +5 and 0V connections.

I have a panel similar to  this with white LEDs.
I've only given it a brief look, but I think it is structured like this :
The row multiplex is 4:1, so 2 row select lines. For 8x16 it's electrically 4x32
Columns are driven by 74HC595's with no current-limiting resistors (!)
There is no global enable, so can't easily do greyscales, but if you hooked into the HC138 row decoder's enable pin you cpuld probably do it - not quite as fast as a true column select but should be adequate.

The signal lines are
2 row select
Data, Clock and Latch to the HC595's

I just realised it is possible that the Latch line also drives the 595 OE lines, in which case it could do greyscale unmodified - don't recall if I checked this  when I was looking at it.