No announcement yet.

Images from SD card no longer working

  • Filter
  • Time
  • Show
Clear All
new posts

  • Images from SD card no longer working

    Hi All

    I have been using the SGC 128 Rev g for some time with no problems. Then when the display mylar cable got damaged and a few lines stopped working I replaced this with the same display except that it is a rev g1h.

    Now the uOLED won't display the images from the SD card.

    I had loaded three 128 x 128 images and a five frame video clip onto the SD card into hex addresses 00, 40, 80 and c0. The program ran as expected and different accumulated input values triggered the appropriate image or video clip to display on the uOLED.

    The images are still there and can be read from the card and displayed both on the utility display and the uOLED using the Fat Controller utility. I can write to the uOLED display from the Arduino using text, circle and rectangle commands. The Arduino code has remained unchanged from the previously working prototype.

    The relevant code used is provided below:

    if (finHR < zoneTwo) {
    heaColour = 0x00;}
    if (finHR > zoneOne && finHR < zoneThree) {
    heaColour = 0x40;}
    if (finHR >= zoneThree) {
    heaColour = 0x80;}
    delay (1000);

    Can you please provide some possible things I can try to fix this problem?

  • #2

    Well, since the Display works with FAT Controller you can pretty much eliminate the display.

    When you establish communications with the display from Arduino, how long are you waiting before sending the autobaud ('U') character?

    What happens if you increase that delay, a bit, a lot?

    You don't seem to be waiting for the ACKs to commands, this could lead to all sorts of issues, maybe you are issueing commands before the previous command has completed, if you don't wait for ACKs how can you tell?

    Have you updated your Arduino environment? Apparently there was an incompatible change to the way serial worked at one stage.


    • #3

      Hi Support

      Sorry for delay in responding, I have been working out of town.

      I have been using the uOLED for some time with the unchanged code in respect of serial communications between the Arduino and the display.

      The display is initialised in the setup process before the main program loop starts.

      The communication between the uOLED and the Arduino is handled by a library written by Oscar Gonzales some years ago. The Acks and Naks are handled by his uOLED library which is added to the compiled code before uploading to the Arduino.

      As I have stated in the previous post, there is no problem writing to the uOLED using Oscar's text and draw cicrcles, lines and rectangles commands. The problem only occurs when trying to write images from the SD card to the display.

      I have changed the additional delay times and added extra "get uOLED response" commands but nothing has changed the problem.

      I am referring this to the electronics lab where the replacement displays were installed in case somthing has been inadvertently changed in the PCB electronics.

      This problem is actually ocurring on both prototypes I have had built (both have the uOLED 128 rev g1h version), one using an Arduino ATmega 168 and the other an ATmega 328.

      I have also reverted the compiled code back to Arduino version 012 which is very out of date now but the same bug persists. This includes using the softwareserial libraries that were supplied with each relevant version. The only version I haven't tried is the new Arduino series verions 1.0 and 1.0.1, namely because I cant figure out how to replace the dropped "BYTE" keyword with the new "Write" command.

      Anyway I will keep this forum updated as I continue to work through the issue. Any other ideas welcome.


      • #4

        You said at the start that the displays worked correctly with FAT Controller.

        Since it would appear that when using FAT Controller the power supply method probably changes I think it would be a good idea to check your power supply. As the power becomes less 'reliable' the uSD card is thr first to suffer.


        • #5

          if you have a lot of code and your program is running from Ram you are probably out of memory ... try this #MODE RUNFLASH and download the program to the flash memory


          • #6

            Thanks for replies

            Resolved by moving the uOLED Ack receive ahead of the delay command, so must be a command timing issue.

            Don't know why but time to move on...