Announcement

Collapse
No announcement yet.

Goldelox uOLED-160-G2 Intermittently Fails to Respond

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • andrewm
    replied


    We have many times thought of creating a list, but when you have two cards purchased at the same time, from the same manufacturer, one of which Windows recognises in an SPI reader and one of which Windows doesn't, you begin to wonder just what use such a list would really be.
    Well that is certainly baffling! I'm sure that causes no end of headaches on these forums. I'll find a new SD card and try it out-- with any luck it'll work.

    Thanks for the clarification on the orientation. It's good to know about the potential problems of switching the screen size.

    Cheers,
    Andrew

    Leave a comment:


  • ESPsupport
    replied


    A cursory forum search indicates that Sandisk the best bet. Is this the case? We have not seen a SanDisk that didn't work. We also sell Phison from our site, because we have tested these and we know they are coming direct from the manufacturer, not through some third party chain that we have no control over.

    We have many times thought of creating a list, but when you have two cards purchased at the same time, from the same manufacturer, one of which Windows recognises in an SPI reader and one of which Windows doesn't, you begin to wonder just what use such a list would really be.

    I'm afraid I'm not really following what you're saying about screen orientation.
    Some Goldelox display models, when in non-native orientation end up writing the first 'scan line' last, eg
    2
    3
    4
    5
    1
    Since you have tested the 160-G2 and found it is not doing this, then fine, continue doing it the way you are, just be aware if you change to another Goldelox display model, that the images may not appear the same.

    Leave a comment:


  • andrewm
    replied


    Why? They are documented in the FAQ section of this forum.
    Whoops! My apologies-- I was looking in the SPE Documentation PDF and came up short. The second bit is a problem on my end-- I already have a dozen screens seated in place with SD cards not accessible. I was hoping not to have to unmount the screens to mess with the cards, but it's looking like that will be unavoidable. For the record, I have a single screen that isn't in place for testing purposes.

    I have to admit I wouldn't have guessed that the SD card brand would be the problem-- I just chose a card that was less than or equal to 2GB and supported SPI. Do you have a list of other brands to avoid, or a list of recommended brands? I see there is a post about it in the FAQ about the SD cards with a few brands listed, but I don't see any sort of official comprehensive list.A cursory forum search indicates that Sandisk the best bet. Is this the case?

    I'm afraid I'm not really following what you're saying about screen orientation. I'm aware of the issue with displaying images in Landscape (I posted about it in this forum a few weeks ago) and I came to the conclusion that without physical access to the SD cards ViSi wasn't an option and the best plan was to simply rotate the images before writing them to the card. Upon doing so it seems to work correctly-- the images are displayed in the correct orientation and position. Is there another reason I should not be doing this?

    Cheers,
    Andrew

    Leave a comment:


  • ESPsupport
    replied


    The 128-G2 does suffer from the orientation issue common to Goldelox, but not as bad as some.

    I suspect you didn't notice it because of the way you generated the images yourself, because you hadn't come across the FAQ you effectively reverse engineered in a way such that it appeared correctly in the Portrait orientation (to see what I mean, try displaying one of your 'non square' images in Landscape)

    I wrote a short routine to cycle through 10,000 Set Address, show image pairs, similar to your logs. There was no issue found at 115200 baud.

    I'm confident the issue is with the uSD card.

    Leave a comment:


  • ESPsupport
    replied


    I had to reverse engineer the image format (How much easier life would be if those screens weren't already mounted!).
    Why? They are documented in the FAQ section of this forum.

    What do you mean by the second bit?

    The SD card is a Transcend 2GB MicroSD card.
    That's probably it, I have two Transcend cards and they both exhibit 'random' 'power cycling' issues when used in SPI mode. I have a Windows SPI mode reader and it if I copy a file to them or from them Windows keeps 'seeing' them being unplugged and replugged.

    The native orientation for Goldelox is the orientation it starts in, for the 160-G2 that is landscape.

    If you use ViSi to generate your screen images and paste the code, you will see how it adjusts the orientation back and forwards for you. It is possible the 160-G2 isn't adversely affected by the wrong orientation, I'll know in a little while when I try your setup.

    Leave a comment:


  • andrewm
    replied


    Hi Mark,

    I'm afraid I don't see anything in the PDF documentation about native mode. Could you expand a bit on how to set the screen to that mode so I can be sure it isn't the issue?

    I've set the baud rate of the screen to 115200, but have also tested it and had it hang at 9600. Both of these were set as the default baud rates, not changed with a serial command.

    The USB cable is approximately two feet long, but it's worth noting that I verified the incoming commands using a separate USB to serial adapted hooked into the adapter attached the to screen. The incoming data that the second adapter recorded was identical to the data that I recorded on my machine before sending it. That is to say that the screen adapter is getting the same commands that I send, meaning that the problem does not appear to lie in either the software serial interface or the cable itself.

    The power supply voltage is 5V.

    I'll go ahead and send you an email in a few minutes with the graphics and their locations on the SD card. For good measure I'm also sending the code that controls the generation of the image write messages. I had to reverse engineer the image format (How much easier life would be if those screens weren't already mounted!). I can't think of a scenario where a wrong image format doesn't fail catastrophically every time, but anything is possible.

    The SD card is a Transcend 2GB MicroSD card. I've reproduced the error using another card of the same model, but unfortunately don't have any different model SD cards on hand.

    Leave a comment:


  • ESPsupport
    replied


    I can't spot anything obviously wrong with the commands or responses.

    The only thing that is NQR is that on Goldelox images should always be displayed when the display is in native mode, however I'm not sure whether that will cause issues with the 160-G2 and normally I would just expect to see screen corruption with this issue and nothing more.

    What baud rate are you using?

    How long are the wires between your driving system and the display?

    What is the power supply voltage where it enters the display?

    Can you post the image suite you are using 'changed into colors', or something so that I can replicate the commands being sent exactly (or maybe email the unaltered set to mark at 4dsystems dot com dot au)?

    What make and model of uSD card are you using? Can you try a different card?

    Leave a comment:


  • andrewm
    replied


    I've attached more log files with responses: one set that shows a single successful run and one set that shows an error run. You will note that the error file does not have a response for the final command-- this is because it hung indefinitely and never sent a response.

    I didn't include responses in the human readable files, but they are matched to the hex logs that do have responses so I'm sure it should suffice.


    Andrew



    EDIT: For the record, the spaces after the responses are a result of the file creation and were not sent as part of the response.
    Attached files hexLog_error.txt (6.3 KB) hexLog_noerror.txt (15.1 KB) humanReadableLog_error.txt (10.3 KB) humanReadableLog_noerror.txt (24.7 KB)

    Leave a comment:


  • ESPsupport
    replied


    That's a good start, I also need to see the responses from the display mixed in with that, eg

    FF 68 00 02 [06]
    FF D7 [06]

    Leave a comment:


  • andrewm
    replied


    I've attached two logs for your perusal-- one is the hex values sent (not their ASCII equivalents, but I can provide that if you would like) and the other is a human readable list of messages sent. Java messages have a single equivalent SPE function, with one exception: Draw Rectangle and Draw Filled Rectangle SPE functions have been combined to one Java message which is translated into the correct hex when it is written to the serial port.



    Cheers,
    Andrew
    Attached files screenOutHex.txt (11.9 KB) screenOutPlain.txt (24.7 KB)

    Leave a comment:


  • ESPsupport
    replied


    To be clear, you want me to reproduce the bug using the Serial Commander tool that is accessible from the 4D Workshop? As in, the graphical tool where I manually select each command and send it one at a time?
    Not necessarily, if you add logging to your Java App, so it looks similar to what you get with Serial Commander, that will be fine.

    Leave a comment:


  • andrewm
    replied


    Hi Mark,

    I've updated my Java program to wait for a full response (with length varying on the type of command) from the screen before sending the next command. As far as I can tell, it performs to the specifications that you are requesting. I can still reproduce the bug, albeit less frequently. It still hangs after repeated testing.

    To be clear, you want me to reproduce the bug using the Serial Commander tool that is accessible from the 4D Workshop? As in, the graphical tool where I manually select each command and send it one at a time?

    Thanks,
    Andrew

    Leave a comment:


  • ESPsupport
    replied


    The display has an input buffer so that not consistently waiting for the ACK (or ignoring extra data in responses which might have the appearance of the next command receiving an ACK when it hasn't really) will not necessarily cause an error on the very next command and, depending on time delays involved in sending the next command, could cause the problem to become apparent at different places.

    Please check your code very closely, perhaps try replicating the issue with Serial Commander and checking what it is getting back with what you are waiting for as a sanity check.

    If you can get a log of a failing command sequence maybe you can post it here

    Leave a comment:


  • andrewm
    replied


    Hi Mark,

    I actually tested that under Test Case 3: the Python code sending the messages blocks for input from the screen before sending the next message. No further commands are sent until the ACK is received. It would still crash intermittently.

    Cheers,
    Andrew

    EDIT: Just double checked the Python docs to make sure that it blocks and re-ran the tests. Everything still checks out-- the serial port is blocking for input before sending more output, and the tests did reproduce the bug. Interesting to note, however, is that it failed on a draw rectangle command this time around, which rules out Display Image being the culprit.

    Leave a comment:


  • ESPsupport
    replied


    You need to wait for the ACK, the amount of time an image command takes will vary according to all sorts of variables, you must wait for the ACK.

    Leave a comment:

Working...
X