Artemis Open Log and micro OLED - should it just work?

Hi all, I have been trying to get the demos working with my Artemis Open Log and have had no luck at all. I’m assuming the micro OLED board is OK as it’s brand new. I would have expected some sign of life when powering up but nothing. The demo sketches all compile OK but nothing happens on the OLED.

I recall when getting the Neo9 GPS board working I had to change a few things to get the I2C working so I’m wondering if there is something special I need to do the get it communicating with the micro OLED board.

I’ve checked that I’m getting 3.3V on the micro OLED board, not much else I can check. Unfortunately I don’t have a “regular” Arduino board to test the micro OLED board out, this is actually my first foray into the world of Arduino.

Stu.

Hi Stu,

If this is your first foray into the world of Arduino, you will find it much easier if you use one of our standard boards to begin with and build up to developing code for OpenLog Artemis. Most of our boards have Qwiic connectors, some have microSD sockets for data logging.

However, if you are up for a challenge, here’s a summary of what you need to do:

We are in the process of adding some new examples for OLA which show, for example, how to log GNSS data directly to the microSD card. You won’t find them in the regular (“master”) branch of the code yet, they are in the “release_candidate” branch (which means they work and have been tested, but they have not been released yet). You can find those new examples here:

https://github.com/sparkfun/OpenLog_Art … 20Sketches

The GNSS_Data_Logging example contains the code you need to get your Micro OLED up and running. But it contains a lot of extra code dedicated to logging GNSS data too. The essential bits for you will be:

Set up the Qwiic Port (the port will be called “qwiic” not “Wire”, you will need to pass the name “qwiic” to the microOLED begin function):

https://github.com/sparkfun/OpenLog_Art … no#L57-L59

You also need to call beginQwiic which in turn will call qwiicPowerOn to enable the 3.3V power to the Qwiic bus:

https://github.com/sparkfun/OpenLog_Art … #L457-L463

https://github.com/sparkfun/OpenLog_Art … #L416-L433

You will need to include some of the pin definitions too, PIN_QWIIC_POWER being the main one:

https://github.com/sparkfun/OpenLog_Art … ng.ino#L81

With those changes and additions, the Micro OLED will work on OLA. Straight forward, but a big ask for your first Arduino project…

Best wishes,

Paul

Hi Paul,

Thanks for the quick reply. I have managed to write my own code which communicates with the GPS board and logs velocity and time to an SD card. I wanted the OLED board so I could display various data logged such as max velocity. I will need to add some sort of push button board to it so I can start/stop logging as well as cycle thru various significant data.

The goal is to have a small high-ish speed logger I can wear when doing sprint training, logging velocity at 10-20Hz so I can track my progress during training. It will probably find its way into one of my RC planes as well - I’m keen to see just how many G’s the Neo GPS IC really can take - my pylon racer will do 30-40G in a full speed turn. Rumor has it the PLL in a GPS IC can’t handle that, not sure why but I’m keen to find out.

Stu.

BTW, something odd I noticed is the red LED on the OLA board doesn’t come on at full brightness on power up, it takes about 5 seconds of slowly getting brighter then flashes. Any idea why?

Hi Stu,

The red (PWR) LED is powered directly by the Artemis pin D29. If your code is setting the pinMode to OUTPUT and doing a digitalWrite HIGH, then it should be full brightness all the time. Slowly getting brighter and flashing may indicate a power problem e.g. that your battery cannot deliver enough current.

Best wishes,

Paul

Hi Paul,

I took the GNSS_Data_Logging.ino example and cut out most of the non-relevant bits for testing the mico OLED and pasted in some examples from the mico OLED library. No luck. The code compiles and runs but nothing shows on the OLED.

My code is below. Any ideas? Is it possible my OLED board is dead?

// OLA Specifics:

//Setup Qwiic Port
#include <Wire.h>
TwoWire qwiic(1); //Will use pads 8/9
#include <SFE_MicroOLED.h> //Click here to get the library: http://librarymanager/All#SparkFun_Micro_OLED

#define PIN_RESET 9

// From version v1.3, we can instantiate oled like this (but only for I2C)
MicroOLED oled(PIN_RESET);

//Define the pin functions
//Depends on hardware version. This can be found as a marking on the PCB.
//x04 was the SparkX 'black' version.
//v10 was the first red version.
#define HARDWARE_VERSION_MAJOR 1
#define HARDWARE_VERSION_MINOR 0

#if(HARDWARE_VERSION_MAJOR == 0 && HARDWARE_VERSION_MINOR == 4)
const byte PIN_MICROSD_CHIP_SELECT = 10;
const byte PIN_IMU_POWER = 22;
#elif(HARDWARE_VERSION_MAJOR == 1 && HARDWARE_VERSION_MINOR == 0)
const byte PIN_MICROSD_CHIP_SELECT = 23;
const byte PIN_IMU_POWER = 27;
const byte PIN_PWR_LED = 29;
const byte PIN_VREG_ENABLE = 25;
const byte PIN_VIN_MONITOR = 34; // VIN/3 (1M/2M - will require a correction factor)
#endif

const byte PIN_POWER_LOSS = 3;
const byte PIN_MICROSD_POWER = 15;
const byte PIN_QWIIC_POWER = 18;
const byte PIN_STAT_LED = 19;
const byte PIN_IMU_INT = 37;
const byte PIN_IMU_CHIP_SELECT = 44;
const byte PIN_STOP_LOGGING = 32;
const byte BREAKOUT_PIN_32 = 32;
const byte BREAKOUT_PIN_TX = 12;
const byte BREAKOUT_PIN_RX = 13;
const byte BREAKOUT_PIN_11 = 11;
const byte PIN_QWIIC_SCL = 8;
const byte PIN_QWIIC_SDA = 9;

void setup()
{
  Serial.begin(115200);
  Serial.println(F("testing microOLED"));
  beginQwiic(); // Turn the qwiic power on as early as possible
  // This is the new way of initializing the OLED.
  // We can pass a different I2C address and TwoWire port
  // If 0x3D does not work, try 0x3C
  oled.begin(0x3D, qwiic);    // Initialize the OLED

  // Print the total number of fonts loaded into memory
  Serial.print(F("There are "));
  Serial.print(oled.getTotalFonts());
  Serial.println(F(" fonts available"));

  oled.clear(ALL); // Clear the display's internal memory
  oled.display();  // Display what's in the buffer (splashscreen)

  delay(1000); // Delay 1000 ms

  oled.clear(PAGE); // Clear the buffer.

  if (oled.setFontType(4) == 0)  // Set font to type 4 (fontlargeletter31x48)
  {
    Serial.println(F("Could not enable font 4 (fontlargeletter31x48)!"));
    Serial.println(F("Have you changed the #define INCLUDE_FONT_LARGELETTER to 1 in SFE_MicroOLED.cpp?"));
    Serial.println(F("not Freezing..."));
    while (1)
      ; // Do nothing more
  }
  
} //end setup

// =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

void loop()
{
  // Demonstrate font 4
  // There are 58 possible characters in the font 4 type: A - z
  // Lets run through all of them and print them out!
  for (int i = 'A'; i <= 'z'; i += 2)
  {
    oled.clear(PAGE);     // Clear the screen
    
    oled.setCursor(0, 0); // Set cursor to top-left
    
    oled.write(i);    // Write a byte out as a character
    oled.write(i+1);  // Write the next byte out as a character
    oled.display();   // Draw on the screen
    Serial.println(F("writing stuff on OLED"));
    delay(1000);           // Delay 1000 ms
  }
} //end loop
// OLA Specifics

// =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

void powerLEDOn()
{
#if(HARDWARE_VERSION_MAJOR >= 1)
  pinMode(PIN_PWR_LED, OUTPUT);
  digitalWrite(PIN_PWR_LED, HIGH); // Turn the Power LED on
#endif
}
void powerLEDOff()
{
#if(HARDWARE_VERSION_MAJOR >= 1)
  pinMode(PIN_PWR_LED, OUTPUT);
  digitalWrite(PIN_PWR_LED, LOW); // Turn the Power LED off
#endif
}

void qwiicPowerOn()
{
  pinMode(PIN_QWIIC_POWER, OUTPUT);
#if(HARDWARE_VERSION_MAJOR == 0)
  digitalWrite(PIN_QWIIC_POWER, LOW);
#else
  digitalWrite(PIN_QWIIC_POWER, HIGH);
#endif
}
void qwiicPowerOff()
{
  pinMode(PIN_QWIIC_POWER, OUTPUT);
#if(HARDWARE_VERSION_MAJOR == 0)
  digitalWrite(PIN_QWIIC_POWER, HIGH);
#else
  digitalWrite(PIN_QWIIC_POWER, LOW);
#endif
}

void beginQwiic()
{
  pinMode(PIN_QWIIC_POWER, OUTPUT);
  qwiicPowerOn();
  qwiic.begin();
  qwiic.setPullups(0); //Just to make it really clear what pull-ups are being used, set pullups here.
}

Hi Stu,

If you add the line:

oled.enableDebugging();

before the oled.begin, you will get extra debug messages on the Serial console. Those should provide a clue as to what the issue is.

Cheers,

Paul

Hi Paul,

Did that and got this:

testing microOLED

There are 5 fonts available

writing stuff on OLED

writing stuff on OLED

writing stuff on OLED…

Was it supposed to give a result after testing it?

Stu.

Hi Stu,

In your code, you are defining pin 9 as the microOLED reset pin (“#define PIN_RESET 9”). Pin 9 is the Qwiic SDA pin. Using it to reset the OLED will conflict with the I2C communication. I got your code working by changing the reset pin to 11. 32 should work too.

I am using version 1.2.1 of the Apollo3 boards. I have the SparkFun RedBoard Artemis ATP selected as the board type.

One other change which may help is to tell the Artemis to use its internal pull-ups on the I2C pins. You can can set them to 6K by calling qwiic.setPullups(6); in beginQwiic. The u-blox GNSS works best with no pull-ups, which is why the example code contains qwiic.setPullups(0); . If your OLED board has on-board pull-ups (the Qwiic version does), then you don’t need to do this.

Best wishes,

Paul

Hi Paul,

Thanks for the quick reply. I changed to pin 11 and pin 32, still no luck. I’m using 1.2.1 of the Apollo3 boards and using Redboard Artemis ATP as board type. I tried setting the pullups as you mentioned but it made no difference. I still get no sign of life on the OLED board. I even tried both qwiic sockets on the OLED board.

Is there any way I can check if the OLED board is actually OK?

Clutching at straws here:

Check your Qwiic cable - maybe you have a bad cable?

Check the ADDR jumper is clear (if that has been soldered, the I2C address will be 0x3C not 0x3D)

That’s about all the help I can offer - sorry,

Paul

Now it’s getting strange. With the micro OLED board connected (I tried a couple of other quiic cables BTW, no difference), the com port drops out and comes back about once every second. It’s not possible to program or run a serial monitor, the Arduino IDE finds it then loses it. If I disconnect the micro OLED board it’s fine - I can program the Artemis board but even if I power it off a battery with the micro OLED board connected, it doesn’t display anything and the com port drops in and out. Interestingly, without the OLED board connected the serial monitor shows different messages:

"testing microOLED

There are 4 fonts available

Could not enable font 4 (fontlargeletter31x48)!

Have you changed the #define INCLUDE_FONT_LARGELETTER to 1 in SFE_MicroOLED.cpp?"

So it must be communicating? I am suspecting something wrong with the board, though, perhaps it’s draining power and causing the Artemis board to reset, no idea why it would suddenly do that. BTW, the ADDR jumper is clear and I tried both addresses.

Success! I suspected that my Artemis board may be different to yours, mine is the older black one. I commented out the “qwiicPowerOn();” and now it’s displaying characters.

Regarding:

#define HARDWARE_VERSION_MAJOR 1

#define HARDWARE_VERSION_MINOR 0

should I have defined HARDWARE_VERSION_MAJOR = 4?

Ah, yes, that would definitely do it! Nice detective work!

Change:

#define HARDWARE_VERSION_MAJOR 1

#define HARDWARE_VERSION_MINOR 0

to:

#define HARDWARE_VERSION_MAJOR 0

#define HARDWARE_VERSION_MINOR 4

and all will be well.

Best wishes,

Paul

Ahhh, now the comments in the example code make sense! Perhaps modify the example to be like this for dummies like myself:

//#define HARDWARE_VERSION_MAJOR 1 //uncomment for new red board

//#define HARDWARE_VERSION_MINOR 0 //uncomment for new red board

//#define HARDWARE_VERSION_MAJOR 0 // uncomment for old black board

//#define HARDWARE_VERSION_MINOR 4 //uncomment for old black board

One last question. Does it matter where in the chain of boards the GPS and OLED board is? I’m thinking that if the GPS board is getting its power from the Artemis board it probably should go first as it most likely uses more power.

Thanks so much for you patience and continued help!

cheers,

Stu.

Hi Stu,

Yes, putting the GNSS first in the chain would be sensible. But, if that makes the wiring difficult, then there should be little harm in having it further down the chain.

Best wishes,

Paul