Possible defective BeadaPanel 5P (or bad firmware)

[esky-sh]

Will let you know the timing soon.

[esky-sh]

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?

After some investigations done in our lab, we will have a bug fix release for BeadaPanel firmware in middle of March. We will address issue of 5P freezing and this continuous PNG feeding issue in the release.

Thanks for your work and reporting to us.

[bobg2222]

Thanks! I'll be glad to test it.

You were able to reproduce the freezing then?

[esky-sh]

Thanks! I'll be glad to test it.

You were able to reproduce the freezing then?

Yes it can be reproduced in our lab. And we appreciate if you can have a test with this v715 candidate firmware image.
-->https://www.nxelec.com/service/download ... 121.tar.gz

[bobg2222]

I downloaded that 1gB compressed tar and unpacked it. It's a big Linux directory hierarchy with 10s of thousands of files. Where is the actual v715 firmware? In other words, using beadatools, where do I point it to update the firmware?

[esky-sh]

There is a button to choose this tarball on BeadaTools Firmware Update page. Just start upgrade after then. You will be prompted with a series of operations to complete the procedures.

[bobg2222]

Ok. Pointing the web Beadatools at the tarball successfully upgraded to the v715 candidate.

I had a little time to check it out. Here's what I can tell you so far:

1. Using the code as it was (using continuous PNG protocol and sending the same PNG twice for every 1-second update), it works--but the seconds display gets WAY behind, 10s of seconds behind after running for a little while. Also, there was a long delay after exiting the app where the display just kept updating the seconds for around 30 seconds or so and then finally exited--as if a LOT of images were queued up in the display itself somehow, updating at 1-second intervals???!!!

2. Then, I changed the code to use continuous PNG protocol but sending each image just once. This seemed to be off by a couple of seconds--but I didn't let it run for long. It DID exit right away this time though. I then activated some code in my app which times how long the actual block send call to the DLL takes to return; after the first call, it's running about 1 millisecond like before--but, of course, I can't say how long the display is actually taking to show the PNG image. I think it might take considerably more time than the 1 millisecond--but I can't time that.

3. Then, I reverted back to the original code which sends Start tag, PNG image, End tag on each 1-second update. This was the version where the display always froze after 10 minutes or less. As I type this, it's been running for over 30 minutes without freezing! I'd say that's fixed! But the seconds display is still about one second slow.

So, this is a lot better. Does v715 have some kind of delay (like, um, 1-second) built into it?

[esky-sh]

We use a different middle ware to render this picture stream in v715. But apparently there is timing issues with of. I will let you know as soon as we investigate it out.

Thank you very much for you constructive work and that work make our devs easier to follow up. Actually we should validate it more precisely before expose for the black box test.

[bobg2222]

After some more testing of v715:

1. Using the Start-image-End protocol, the seconds display does work correctly. I guess I was mistaken on that.

2. The continuous PNG protocol is definitely not fixed. If I send just one image (with a Start tag but no End tag), it doesn't get displayed until I exit from the app (the app sends the End tag on exit). If I send just two images, the first one displays but not the 2nd one (until exit again). This explains why I observed delays with the continuous PNG protocol. And like I said before, if we send two of each image, there are very strange and much longer delays.

3. The 5P display does not work with AIDA64. First, trying to use the Preferences window to enable the BeadaPanel display (i.e., checking the box) triggers an error dialog box:

Access violation at address 00E7B1D5 in module 'aida64.exe'. Read of address 0000022C.

If you click the OK button on that dialog, it enables the 5P. But (even after a restart of AIDA64) the 5P display updates 2 or 3 times and then just stops updating at all. Plus at that point, you can no longer start the Preferences window at all! Starting Preferences triggers the above error dialog, but now when you click the OK button the Preferences window comes up mostly blank. The only way I've found to fix this is to exit from AIDA64, start my app (so it has the connection to the 5P), then start AIDA64. Now you can start the Preferences window (and there is NO error dialog) and uncheck the BeadaPanel box.

[esky-sh]

We did verify this v715 firmware with AIDA64 and no issues found in our lab before uploading. Could you double check with file name of firmware image on your hand?
The file name should be beadapanel-i6-v715-202403121.tar.gz.