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

[David_AVD]

Thanks for that Mike.  I'll take a closer look at the driver board and what chips it uses.

The LED modules I have have all of the electronics hidden (potted), except for 2 electrolytic caps so no chance of probing or examining any chips on them.

I'll take a photo today when I get into work.

[David_AVD]

The controller board has a micro (8051 ?), RS485 transceiver and a couple of HC245 buffers.

Here's some pictures of the controller board and LED module:

[mikeselectricstuff]

The controller board has a micro (8051 ?), RS485 transceiver and a couple of HC245 buffers.

For non-greyscale control, bandwidth requirement is fairly minimal, so easy to drive from any micro.
I think I noted the pinouts of the one I have - will take a look tomorrow.

[David_AVD]

I removed the silicone fill from part of one of the dead LED modules and it uses MBI5023 chips. (looking for English data sheet now)

There are 2 unpopulated chip positions for every populated one, so I guess they just fit whatever chips and LEDs are required for the colour type.

[mikeselectricstuff]

I removed the silicone fill from part of one of the dead LED modules and it uses MBI5023 chips. (looking for English data sheet now)

Google finds a chinese datasheet with enough info to ID it as a standard 16-channel constant-current driver
http://www.lantec.cn/Private/Files/MBI5023%20Preliminary%20Datasheet%20V1.00-SC.pdf
Looks very similar to MBI5024 :
http://www.autcomp.com.br/fichas/macroblock/drivers/dcdc/MBI5024%20Datasheet%20VA%2002-EN%20.pdf

[David_AVD]

Thanks for the links.  I think I already have the first one.

I've mapped out most of the 16 pin connector now so should be able to create a test jig for them when I get a chance.

I actually have a new product application for modules like these so driving them with my own hardware is the ultimate goal.

[poorchava]

Those drivers are made by Macroblock. Strange that there is no info on their website. They are Taiwanese company, but they know what they're doing. They have a distributor in EU: www.maritex.com.pl (https://www.maritex.com.pl/en/shop/products/33061/?cid=33061&views=&form%5B378%5D%5B%5D=3103)

[amyk]

The info is there on their site, it's just in Chinese.

http://www.mblock.com.cn/products.php?KindID=4&ID=72

[CaCtus491]

I'm currently looking at a new project that would require a library that allows control of the Linsn cards from Linux. This thread is an excellent starting point

Is anyone still interested in working on such a library? I'm particularly interested in controlling brightness and dead pixel detection.

As a longer term project, a Linux framebuffer driver would be interesting that talks via Ethernet directly to the receiving card - we can do away with the sending card entirely!
http://www.linsnled.com/images/solutions/linsn-led-gigabit-network-card.png

[firehopper]

I have one of those adafruit type displays 32x32 xrgb. I'm currently driving it using a teensy 3.1 and smart matrix shield. they dont have any pwm to controll brightness.. thats handled by writing the display repeatedly.

look at the smart matrix/fastled lib's to see how they do it.

[CaCtus491]

Thanks for the reply.
In this case we're specifically working with Linsn 'sending' and 'receiving' cards. As described earlier in this thread, the USB port on the sending card is just a serial over USB interface. It is this protocol I'm interested in learning about and creating a library for to adjust brightness amongst other things.

[azaghi]

I known it is an old post but i think my infos can be of interest 
I have a similar goal. I want to do basic commands and monitor from remote LINSN ledwall.
I have found a different command sniffing serial in order to READ/WRITE the LINSN "register" and inquiring a chinese exporter:
Register read and write mode of the specified register read and write, need to be a new version of sending card program (D5 or above) or ninth generation send cards to support this mode. Read and write using the same command.
The command consists of 8 bytes, as follows:
nbyte     Value
1           0xD8
2           0xD8
3           0x70
4           0x98
5           0-127 register where perform read or write
6           bitmask field 1 - write that bit  or  0 doesn't write that bit (0xFF write all, 0x00 only read)
7           value to write
8           accumulation (sum of bytes 5+6+7 casted in a byte)

it returns with 4 bytes of data, the following composition:
0xC5, bytes 2 and 3 is the same as the original value of the register, 0xC3

With this command i can set some register like brightness of whole screen
register 98 brightness 0-255

or reading register 112-115 i can get the status of the receiving card (the first one or what i put in register 39)
but that reading status i can't get a sense... this is what i got as docuemntation from LINSN:
Register112 - 115: to form a 32-bit register
  Bit0 -11: receiving card temperature
  Bit12: receiving card smoke
  Bit13: receiving card smoke
  Bit14 -23: receiving card humidity
  The bit24 -31: receiving card operating voltage

but i get something like
45 85 69 36 (hex value from register 112 to 115 in order). These values are in my office so internal enviroment and i can get values that seem good....

If someone can solve this puzzle i will be very happy.
Bye,

Andrea

[EdwinB]

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

How can i fix this problem, i have it also with 2 different screens.
Kindly regards
EdwinB

[tantrwm]

Hi Guys
Brilliant, brilliant and very informative thread.
It has inspired me to get back into this field (I have been out of it for since 1996!)

I have recently bought a pile of second hand 64 x64 panels http://www.lighthouseaudiovisual.co.uk/eurolite-pixel-wall-panel-led-pixel-mesh-64x64-video-panel-50696-p.asp?gclid=Cj0KEQiA4JnCBRDQ5be3nKCPhpwBEiQAjwN1bmNvdxV85PFBVugZi3TdbNJxJzkLS6t_UceTfc4-500aAkgB8P8HAQ along with a Linsn SB-8 sender and numerous receiver (linsn).
The problem i am having is that the SB8 has an RJ11 telephone style socket on the back instead of a USB port. The enclosure is labelled with USB but it is not there. On opening the enclosure the Rj11 socket seems to be factory installed and not a retrospective fit.
I have trawlled the Linsn site and cannot find mention of this implementation.
The system came with a rj11 to rs232 cable. Alas i have no computers with RS232 inputs. I purchased a USB to 232 adaptor but this does not seem to function or recognise the SB-8 when connected.
Any help would be appreciated.
Andrew

[mikeselectricstuff]

Is there any reason to think the Lighthouse units have any similarity to  or compatibility with the Chinese units?

The pics in the link look like the tiles have a completely different architecture

[CaptainMurdoch]

Did anyone ever make any progress in deciphering the protocol or packets used between LED Studio and the receiver boards when not using a sender card?  I work on an Open Source program called the Falcon Player (aka FPP) available via http://FalconChristmas.com    FPP can currently be used to drive the LED panels directly from a Pi or BBB using a couple different Open Source libraries, but I would like to add support for driving Linsn receiver boards directly over Gig-E as well.  I already have code to drive ColorLight receiver boards directly over Gig-E, but they use a different protocol.

I'm not currently interested in configuring a sender card, I would like to bypass the sender and send packets directly to the low-cost receiver boards.

I have been able to look at the packet capture posted earlier in this thread as well as some others I have performed and I made a simple script to take the data and put it into a raw data file which can be viewed using ImageMagick or any other program that can display raw RGB data.  The image is discernable, but not exact.  The Linsn protocol is not as simple as the ColorLight protocol which uses one packet per row of display.  The Linsn protocol appears to pack the data together to have a more efficient packet-per-frame count, but it also appears to be padded or encoded in some way because the data in the file does not match the colors on the actual computer screen or LED panel.

I have written some test code and am able to make the LED panels blink by sending packets from Linux to my RV908T, but the panels don't display any correct data because I am not formatting the RGB data correctly in the packets.

Has anyone else made any more progress on this, or is currently working on or interested in driving the Linsn receiver cards directly?

[james_s]

This thread reminds me a year or two ago I drove down the freeway and a huge LED video screen in front of a casino was displaying the Win9x desktop with an error that the program had stopped responding.

Those screens are obnoxious though. I wouldn't mind them except they're SO bright at night that it's blinding. They really ought to have a light sensor with a night mode and maximum allowed brightness if they're along a road.

[rankink]

Does anyone have any active questions regarding LINSN sign architecture at this point?  I just saw this and have spent a bit of time focusing on these cards.

[zamboni]

Does anyone have any active questions regarding LINSN sign architecture at this point?  I just saw this and have spent a bit of time focusing on these cards.

hi, yes I am just starting to looking at the LINSN products such as RV908 receiving cards and very interested to find out the communication protocol and whether it is possible to control these using custom hardware (RPi/BBB/FPGA/etc)? 

[fpgaarcade]

I've got a bunch of p3 64x64 modules with an RV908 rx card. I've also got the video processor, sender and contacts with the factory (kinda).
My aim is to drive the RV908 direct from an FPGA.
Has anybody made any progress figuring out the protocol, or is it time to get the logic analyzer out?
/Mike