Back to

OLED Display. HELP!

I bought from SeeedStudio a Grove OLED display for my SCK. Unfortunately, they did not send the old one, but the new V2 version:

and it does not work!

Any hope to have it supported in the next firmware release?

I am reluctant to mess with firmware, any error would brick my unique (and expensive) SCK, however, with help and detailed information, I could try.

But an official release would be a lot better.

Things are even worse: I managed to buy another OLED display, the right version and… guess what? IT DOES NOT WORK!!!

50 € thrown into the basket…

So the question: is Documentation reliable?

looking forward to receiving an answer from the developers @oscgonfer, @pral2a

@victor, @pral2a

I found the time to look deeper into the code for OLED display aka groove OLED.

Its clear that the code currently supports Grooove OLED aka SeedStudios Grove OLED 0.96" V1. which uses a control chip SSD1317, and it is explicitly instantiated in SckAux.h in the definition for class Groove_OLED (by calling U8G2 library) and it creates a U8g2_oled object upon which graphical operations are manipulated. That device supports 96x96 resolution. (12 lines of characters) and it is a color display.

Unfortunately, Seeed no longer sell that model of OLED via their direct sales channel, Instead they sell SeeedStudios Grove OLED 1.12" V2 which uses a different chip SH1107 and provides 128x128 resolution (16 lines of characters). This is a monochrome display. I have one of the latter OLED device.

So, I am assuming that issue is likely to be the reason why my own OLED display refuses to work since I have latest device. According to the code, the device should display a Logo when it starts and it does not.
The device is recognised if it is plugged in when SCK starts up and visible on the I2C auxilliary bus.

I am unable to see any code that calls the ‘DisplayReading’ public method of ‘AuxBoards’ object, but I will be able to confirm my analysis when I am able to build the firmware and try it out. I am still working on platformio setup…
For myself, I would like the display working to display sck status and immediate readings in words, as I find it difficult to work out what is going on with the flashing coloured LED.

It would be fair for the display to go dark automatically after a short delay to save power, but light up when the user performs some action such as button press sequence. Perhaps I can somewhere find a touch pad “button” that works on I2C bus.
I also plan to add a GPS ‘sensor’ to add position and altitude readings (useful in a mobile context) which are not currently supported by the central sck servers. The oled display will at least make it possible to display this information.

I am prepared to mess about and try to get the OLED working save you the trouble and I note that others have encountered the same problem as myself, and more will do so in future, so it is useful. The issue is worthy to be fixed IMO, but I concede that maybe its not top of your priority list.

I suggest some mechanism should be found to configure the SCK to use either type of OLED display. I am wondering if its possible to probe the device at address 0x3C and determine somehow what type of chip it is, then act accordingly. In fact there are a myriad of choices for OLED displays available in the U8G2 library, not sure how practical is this idea.


1 Like

Hello, many thanks for the time you spent.
However, I managed to buy a V1 display, this one:

but this also does not work.

It seems to me that some other bug is present in the software.

Hi @nicola.pomaro

@victor implemented a very nice display on the SEEED OLED Display 1.12" V2.2. I am not sure about backward compatibility. Have you tried with the newer version of the firmware (tag 0.9.8 prerelease)?

Temperature (60 sec) - oled
Humidity (60 sec) - oled
Battery (60 sec)
Light (60 sec) - oled
Noise dBA (60 sec) - oled
Barometric pressure (60 sec) - oled
VOC Gas CCS811 (60 sec) - oled
eCO2 Gas CCS811 (60 sec) - oled
PM 1.0 (300 sec) - oled
PM 2.5 (300 sec) - oled
PM 10.0 (300 sec) - oled
Groove OLED (60 sec) - oled
SCK > version
Hardware Version: 2.1
SAM Hardware ID: BB91ACEE50515157382E3120FF10223E
SAM version: 0.9.7-7162299
SAM build date: 2020-10-19T19:35:13Z
ESP MAC address: ----------------
ESP version: 0.9.2-8b3c4e0
ESP build date: 2020-10-28T09:10:54Z

That’s the output of a 2.1 with an OLED v2.2 connected on the bus.



I am still with 0.9.6 firmware.

The change of default PM sensor reading to every 5 min is not acceptable for me, and the procedure to change this interval way too complex. I do not understand the reason for this change, it should be useful maybe for battery operation, but I am using my kit on power supply (and suspect that many others do the same).

I acknowledge that any fix will be done in newer firmwares, so I have no hope to use my two OLED displays

Values like measuring times or calibration factors should be put on SD card and read by the kit, this would facilitate a lot kit management and customization. I suggested this more than a year ago.



Yes, it’s for battery and temperature management reasons. Nevertheless, you can always modify the firmware and compile it to work for 60s again. Otherwise, the settings you modify in the shell are saved in EEPROM.

For the OLED, it would be interesting to see if the previous OLED display still works. However, as it’s production is/will be ended soon, we won’t support it. In general, it is a good practice to keep your firmware (not only for the kit) updated as things are improved.

For the calibration factors, sorry, but that’s not a good approach. If you remove the SD card, or if’s corrupt, then you can end up in complex misdemeanors that can cause unpredictable problems.
What facilitates the kit management and customization is to dig a bit into the different options the firmware provides, and explore the raw data afterwards in a post-processing stage. We are more than happy to help and explain exactly what line needs to be changed for each purpose. It’s far more empowering, plus you won’t lose any raw data for this ease-of-use need.


What I can confirm is that neither V1 nor V2 displays work with 0.9.6 firmware.

About the other comments, it is a matter of what type of users do you think, or want, to be the target of this kit. If all of them must be expert users, that are experienced in using shells, compilers, programming languages and so on, then yes, it could make a sense to compile the entire code only to change a number. Even if, when I took programming exams, they always kept telling that putting numbers along the code was bad programming, you should use constants or parameters, and put them in a common area in order to ease their check and change.

If your target users are common citizens, environment aware, that should be able to exploit all the kit features without specific programming knowledge, then the possibility to simply edit a file to set parameters and calibration factors is way better and safer. I do not even dare to think that you are not smart enough to write a software able to revert to default values should the SD card be absent, corrupted or data not written in the right format.

You should ask yourself if the fact that these products are not so widely known and used could be the so unfriendly way they are supposed to be managed. This is against the idea and philosophy of a product that everybody could have at home and the dream of a global and free access network of environment data.

Anyway, many thanks for your kind answers.

Best Regards

@nicola.pomaro thanks for your comments, we always like to know what people think about the project.

Smart Citizen is a project, not a product. We build hardware and software, we engage citizens, and we support communities because we believe democratising access to tools is not about making another gadget, Google and Amazon and many others are far better and have many more resources than us to do it.

Instead, we design tools to change the way people thinks about cities and technology. Some accessible to almost everyone, like the SCK 2.1 with its easy onboarding. Some advanced like hardware addons or our analysis framework, aimed at community champions to customise the technology to their local needs.

All the project uses open licenses; anyone can contribute, or pay someone to do it, to add a feature or to make it easier to use.

If you are not interested in this approach, I suggest you look at commercial home Air Quality Monitors.

1 Like

@pral2a, actually that was my original idea, to use a commercial product.
I am very interested in the air quality at my home, in my city, in my country and so on.
I am not interested in spending hours of my limited free time on the software details of this kit, no more than I am interested in doing this for my multimeter, my alarm clock, or my oven.

I made a market survey, a year ago, read many reviews and opinions, and the result was that SCK2.1 was the product to buy, for accuracy and value. Many commercial products are friendly and trendy, but the beautiful enclosure hides a poor performing device. I could not care less about aesthetic, reliability and accuracy are my requirements. Or, you pay much more for the same performance.

Only after purchasing, I realized the limits of the kit. It is reliable and accurate, but it is actually a work in progress and resembles more a demo/evaluation board than a end-user product. My fault, I should have investigated better.

I am in process to sort out a similar conundrum at this moment. Whether to build a SC Station and extend it, or buy a commercial weather station that leaves out big chunks of functionality and costs big $$.
I built the SCK 8 months ago and I was satisfied although I too wanted to have an OLED for local display of output data as an immediate feedback the device is doing something, without the need to navigate to the SCK map using my phone or tablet.
So now, in different personal circumstance, I am looking at a more ambitious project, so looking at the Smart Citzen Station. I also compare it with commercial examples.
What I find is that EVERY commercial example I have found contains only a subset of what the basic SCK2.1 can potentially do.
For example most of then will do temp, hum%, barometer, wind and rain (in the top $$ models) but leave out the gasses, light, sound, VOC & dust sensor. Or some combo. But only the SCS can potentially do it all. AND SC provides the source code allowing tweaks, changes to the code if you need it, whereas commercial suppliers do not provide access to the internals, algorithms etc. they supply black boxes, you cannot see inside them to verify they are doing it right.
The limitation with extending SC to do everything is the amount of power required, and that can be solved.
So the big win with Smart Citizen is overall completeness as an environmental sensor system, not just merely weather. It gives the whole picture and allows visualization of correlation between the different parameters.
For example, adding an anemometer will allow correlation between wind strength and direction against noxious gasses and PM aerosol fine dust.Where is that awful stuff coming from ?
Then, moving the sensor around to various places will allow them to be compared (or get others involved too).
With better information, citizens can ask government informed questions and get respectful responses.