Possible defective BeadaPanel 5P (or bad firmware)

[bobg2222]

i recently received a black BeadaPanel 5P. The sales people had told me there was actually one black one left in inventory (although the order page said there were none) and I could get it shipped right away by ordering a silver one and including a note that I wanted black.

I have my own personal app (running on the latest update of Windows 10 Pro) which I developed using a BeadaPanel 5C that I got last summer. The app is C# but I developed a C++ DLL which closely follows the sample app from your panelLink github code and the panelLink (and statusLink) documentation. The DLL is then used by the C# app. The app displays the date/time and some weather info from various web APIs on the display, updated once per second. The app sends a PNG to the DLL for the display update.

This was all working perfectly on the BeadaPanel 5C, running 24/7 for weeks on end. When I got the 5P, I unplugged the 5C and plugged in the 5P in the same USB port then started the app. At first it seemed to be working fine. But then I noticed the display had frozen and wasn't updating. I've since found that it always freezes up after 2-10 minutes (since it updates every second, 10 minutes would equal 600 successful updates).

I've debugged this enough to tell you that it always fails on the Start tag. In other words, on the last successful update, it sends the Start tag, the PNG payload, the End tag. Then one second later, it sends the Start tag and this never returns (and this is when the display freezes up). I've even gone so far as modifying the C# code so it just starts your github sample app, panelLink.exe, as a process with a filename as the argument--completely eliminating my DLL from the equation--and it still freezes up after a few minutes.

I think the 5P is defective since everything works perfectly on the 5C. They have different firmware levels though. The 5C is at 8.05 (I updated it once after I got it) and the 5P is at 7.13 and does not seem to have an update. It looks like the 5C firmware is MUCH newer than the 5P. If there is some newer firmware somewhere for the 5P, I'd be willing to try that.

[esky-sh]

This is a quick response to your issue:
1. We have an update to Panel-Link protocol and corresponding documents since July, 2023. and I assume you are developing your code based on these latest specs.

屏幕截图 2024-02-24 200444.png (127.48 KiB) Viewed 341 times

As per this latest spec., multiple png pictures can be sent inside a unique Panel-Link Start/End session. We implement this new feature for performance reason and we strongly suggest you change your code to check if any different results come out.

2. BeadaPanel 5C and 5P preloadded with different firmware since they were based on different hardware platforms. But both of version 805 and 713 all support this new feature as I mentioned in section 1.

[bobg2222]

I saw that but didn't quite understand the difference between putting the "image/png" string there vs all zeros (as in the example code). I DID try putting the "image/png" in--but with Start/End tags for every update. The 5P still froze.

But I can try the multiple images between one set of Start/End tags without too much trouble. I'll probably report back in a couple of days.

[bobg2222]

It's late here (after 2:00 AM) but I wanted to try the "continuous PNG" protocall as you asked. So, my DLL now has a writeContinuousPNG export which makes sure a Start tag has been sent but, if a start tag has already been sent (with "image/png" in the format string), it just sends the PNG payload. It was trivial to modify the C# app at that point.

In other words, the app now sends one Start tag to the display and then PNG payloads over and over.

Of course, this works on the BeadPanel 5C--which has taken everything I throw at it. BUT...this seems to be working on the 5P! At least it has now been running on the 5P for about 45 minutes as I write this. And as I explained, I never saw the 5P run for longer than about 10 minutes without freezing up.

So, why did I have to do this with the 5P but not the 5C? Why does the 5P fail after a few minutes if I send Start and End tags at every update? Is that "normal" behavior??? How is AIDA64 driving the displays?

[esky-sh]

You do not have to have this 'continuous png‘ tag when you send a png picture. But you'd better have it when you send a consequent png picture stream to the display. With this tag, you will have a performance improvement from 5fps to 15fps, whether on a Model 5C or 5P.

For the 5P freezing issue, we will take a look into in our lab but I am afraid we need a little bit time for this work. We will update in this thread as soon as we make any progress with it.

[bobg2222]

I had to shut the 5P down briefly to test that my code for that was still working. I started it back up and it's now been running over 20 hours using the continuous PNG without a glitch. I'm not that concerned about performance since I only update once per second. But I do have timing code in the app that I can turn on. I'll test that at some point.

To test what must be a firmware bug in the 5P, just send the sequence, Start-PNG-End repeatedly every second. This always worked for me on the 5C but it freezes the 5P after <= 10 minutes.

Two quick questions:

1. My DLL handles Status-Link protocol if the endpoints are there. I mostly just want to be able to set the brightness. What is the proper way to do this? If I'm doing "continuous PNG" can i just change the brightness, say, between two of the continuous PNGs? Or do I have to send the End tag, change the brightness, then send a Start tag and continue on?

2. How is AIDA64 driving the display? Does it use one of the continuous protocols somehow?

Thanks!

[esky-sh]

1. In BeadaPanel, Panel-Link and Status-Link are independent and running in separate process space. So you can call to these procotols at any time.
2. Panel-Link protocol is open so customers include finalwire can develop applications on their own. We do not know how AIDA64 doing communications with BeadaPanel so you would like to contact finalwire for this question.

[bobg2222]

Here another oddity about the 5P:

I'm still using the continuous PNG protocol. My app has a digital clock--with seconds--along with the weather data it displays (this is the only reason I update the display every second). This worked fine with the 5C, flipping up each second in sync with the Windows clock display (or even my Apple watch).

But I noticed with the 5P and the continuous PNG protocol, the seconds display was slow by exactly one second.

Here's why that happens: Say we're sending Start-image1-Image2-... I figured out that image1 is NOT displayed until image2 is sent, Image2 is not displayed until Image3 is sent, and so on. If only one image is sent (without an End tag) then it doesn't get displayed at all!

Not too surprisingly, this is NOT true of the 5C which displays each image at the time it is sent (so with my app, the seconds sync perfectly when using the continuous PNG protocol with the 5C; or if only one image is sent, it gets displayed--even without an End tag).

And it isn't just my app; this also happens with AIDA64. I have been using a different brand of LCD (an AX206 display) for AIDA64. I temporarily added in the BeadaPanel to AIDA64, displaying exactly the same data and then added the time to both displays (this displays hh:mm:ss format). In my AIDA64 setup, I have it updating every 5 seconds.

With the 5C, the displays update simultaneously and the seconds always match. But with the 5P, the AX206 display is 5 seconds AHEAD of the BeadaPanel 5P. This is clear both from looking at the time and also CPU usage, temperature, etc.: the 5P matches the AX206 exactly--but always 5 seconds later!

This should probably be reported in the AIDA64 forums--but I'll give you a chance to reply before I do this.

[esky-sh]

First of all you are hero!

That is an issue related with 5P and other models which have same SOC. Currently we send two same pictures after start tag as a temp workaround. We will open a project on GitHub to public for Panel-Link issue tracking soon.

Thanks

[bobg2222]

Yes, after I figured out what was happening, I started just sending two of the same image every time I update. This gets the seconds on the clock display to sync properly on the 5P. It's a waste of USB bandwidth, but that's where my app is for now. On the other hand, the 5P is very fast. With the continuous PNG protocol, sending an image only takes about a millisecond.

Is there an ETA for a firmware fix for the 5P and the others?