VDI-RODERICO

[waltr]

Yes, I did comment out these lines and it still worked fine.

ok very good, only one more question to simplify glcd_init(), does it work well removing these lines?

glcd_cmd(0x91); // Set Look Up Table (LUT)
glcd_cmd(0x3F); // BANK0: 63 (maximum from 31 to 63)
glcd_cmd(0x3F); // Color A (default)
glcd_cmd(0x3F); // Color B (default)
glcd_cmd(0x3F); // Color C (default)

[roderico]

ok very good, only one more question to simplify glcd_init(), does it work well removing these lines?

glcd_cmd(0x91); // Set Look Up Table (LUT)
glcd_cmd(0x3F); // BANK0: 63 (maximum from 31 to 63)
glcd_cmd(0x3F); // Color A (default)
glcd_cmd(0x3F); // Color B (default)
glcd_cmd(0x3F); // Color C (default)

[waltr]

I gave all your suggestions a try plus some other commands (0x92, 0xD8->0x35) and still no change in brightness or contrast.
Concluding that neither brightness nor contrast is supported.

[roderico]

ok, I guess setting 0 or 255 directly in glcd_init() does nothing

    glcd_cmd(0x81);
    glcd_cmd(0x00);

The other lines that could be removed in glcd_init() to save space in the firmware are

    glcd_cmd(0x91); // Set Look Up Table (LUT)
    glcd_cmd(0x3F); // BANK0: 63 (maximum from 31 to 63)
    glcd_cmd(0x3F); // Color A (default)
    glcd_cmd(0x3F); // Color B (default)
    glcd_cmd(0x3F); // Color C (default)

if you give this a try, then you could test if contrast is working in the menu (as this code was setting the maximum value for BANK0).

If there is no display in dim mode then you might need to adjust the constrast/brightness first, after setting dim mode in glcd_init()

    glcd_cmd(0xAC);

send the commands

    glcd_cmd(0xAB);
    glcd_cmd(0x00);
    glcd_cmd(0x80); // contrast 50%
    glcd_cmd(0x80); // brightness 50%

and set_contrast() and set_brightness() should be adapted as

void glcd_set_contrast(uint8_t c)
{
    glcd_cmd(0xAB);
    glcd_cmd(0x00);
    glcd_cmd(c);
    glcd_cmd(g_disp_brightness);
}

void glcd_set_brightness(uint8_t b)
{
    glcd_cmd(0xAB);
    glcd_cmd(0x00);
    glcd_cmd(g_disp_constrast);
    glcd_cmd(b);
}

probably the effect is small and/or it is fixed in the board as you already mentioned, so I will remove the brightness code and if setting contrast to 0 did not work also the contrast code.

[waltr]

looking again at the data sheet contrast and brightness might work in dim mode, instead of 0xAF at the end of glcd_init you could try it by replacing 0xAF with 0xAC to turn the display ON in dim mode. Then contrast and brightness can then be configured differently than in normal mode with commands like 0xAB, 0x00, contrast, brightness. Another test that might work is to use 0x31 (default value) after 0x91 command instead of maximum 0x3F (only for the first entry) and comment the others that are default values, if none works then this display might not support any contrast and brightness controls

maybe it's just the display, brightness might only work on color displays, but contrast control does work with ST756x driver, if there is no bug in the code setting contrast to 0 or 255 in the menu should have a clear effect, if not then some configuration option after the init sequence in glcd_init() e.g. dim mode, if not then contrast command in glcd_init() is useless since it will always be initialized with the same contrast/brightness...

Got around to trying your suggestions for Contrast and Brightness.

"replacing 0xAF with 0xAC to turn the display ON in dim mode"
Then NO display at all with any value in 0x81, 0x82 or 0xAB.

Seems this display board does not support brightness/contrast adjustment.
A different board with the same controller chip (ssd1305) may support these features.

There is a possibility that the repair I did to fix the Charge-Pump may have disabled the brightness control.
The OLED brightness is related to the output Voltage of the Change-pump. There is a trace from the controller chip to the charge-pump chip. Could not trace this back to know what it did.

[roderico]

I have also updated the LED version using MCP1525 since it will give a precise offset and thus there will not be necessary manual adjustment (which is very difficult without recompiling a new firmware for every pcb), also removing the 4-leds and leaving only 3 leds for vdi-/vdi+/saturation because in the GLCD version it can be seen relatively big errors in vdi numbers so using 4 leds would be switching from one led to another, the boundary between + and ? can be set with RV1 trimmer when +/- are alternating e.g. small foil, the only advantage over GLCD is that it is very small and simple, e.g. the 3 leds can be replaced by a tri-color led or a bi-color led for +/- and 1 additional led for saturation

[roderico]

I think so, you could use a microcontroller with a usb module to connect to your mobile phone and send the digitized signals to the android apk but you would also have double work, the android application and the pic firmware and might have some latency problems when sending the XY signals, IMO it would be easier to interface a simple display in the firmware than the android apk

[dbanner]

I have a question. Would it be possible to develop an Android APK which would be able to process phase information via a USB otg device connected to a metal detector?
You could go to town on colors and graphics, that's for sure. Using the Android developer tools suite

A simpler approach could be to utilize the mic input of the headphone port, proceesing the phases would be done by pic micro, which could turn the results into an analog sine wave whose frequency is dependent on the type of metal.
This signal is then sent to the phone via the mic input for interpretation by the app.

Feasible?

[roderico]

maybe it's just the display, brightness might only work on color displays, but contrast control does work with ST756x driver, if there is no bug in the code setting contrast to 0 or 255 in the menu should have a clear effect, if not then some configuration option after the init sequence in glcd_init() e.g. dim mode, if not then contrast command in glcd_init() is useless since it will always be initialized with the same contrast/brightness...

[waltr]

I haven't tried the brightness code changes yet. I have been re-studying the ssd1305 data sheet.

The v2.2b2 code as is works fine and gives correct battery Voltage once set in menu.
I did select resistor divider from the battery to ensure ADC input is <3.3V.

I will try the VREF code, just added it to the source like this:

//#define _3p3V
    
// ADC
#ifdef _3p3V
#define VREF 26 // 3.3V x 8 
#define adc_to_volts(x) ((VREF*((int16_t)(x)-(int16_t)g_adc_offset))>>3)
#define volts(x) ((VREF*(x))>>3)
#else
    
#define VREF            5 // 5 V
// Vout =  Vref/1023 * (ADC - adc_offset)
// 2^10*Vout ~= Vref * (ADC - adc_offset)
#define adc_to_volts(x) (VREF*((x) - (int16_t)g_adc_offset))
#define volts(x) (VREF*(x))
#endif

So it is easy to select.

[roderico]

Ok, if it is not supported, then I will remove the brightness code, for Vdd=3.3V using VREF = 3 introduces an error of 9-10%, a better fix would be

#define VREF 26 // 3.3V x 8 
#define adc_to_volts(x) ((VREF*((int16_t)(x)-(int16_t)g_adc_offset))>>3)
#define volts(x) ((VREF*(x))>>3)

that would give an error less than 2% and should be fine for this (not using x10 to avoid divisions). I will also update the schematics to rename Vref to ADC offset for not to confuse with this VREF which is the ADC Vref+. The battery scale can be done in the menu and/or in the eeprom if R1 and R2 are known. Using current values R1 = 20K, R2 = 6.8K the maximum battery voltage would be 13V (vs. 20V in the case of 5V) so it might be safer to use a value lower than 6.8K e.g. 5.1K that would allow a maximum battery voltage of ~16V. I didn't find any replacement for the MCP1525, which should give 3.3V/2 = 1.65V, so the resistor divider might work well. MCP1525 is very stable and always gives 2.5V = 5V/2

[waltr]

I will give those suggestions a try.

[roderico]

looking again at the data sheet contrast and brightness might work in dim mode, instead of 0xAF at the end of glcd_init you could try it by replacing 0xAF with 0xAC to turn the display ON in dim mode. Then contrast and brightness can then be configured differently than in normal mode with commands like 0xAB, 0x00, contrast, brightness. Another test that might work is to use 0x31 (default value) after 0x91 command instead of maximum 0x3F (only for the first entry) and comment the others that are default values, if none works then this display might not support any contrast and brightness controls

[roderico]

Very good, then it was missing command 0xA1, to discard a bug in the eeprom+menu and make sure your display supports contrast and brightness a simple test could be to set these values directly in glcd_init() with two tests one for contrast and another for brightness. The default values in your code are 0x32 = 50 for contrast and 0x80 = 128 for brightness, according to the data sheet the chip has 256 contrast steps from 00h to FFh, i.e. you could replace

glcd_cmd(g_disp_contrast);

with e.g.

glcd_cmd(0x01); // or 1 directly

and check if it is very dim or high contrast glcd_cmd(0xFA); // 250 almost maximum, and the same for the brightness, e.g. 0 brightness and 255 maximum. The data sheet says brightness affects color banks so it might not do anything but it does not say anything about contrast.

[waltr]

Now v2.2b2 is working properly.

Mirrored display fixed by adding this line to "void glcd_init(void)" in ssd1305.c
After the command to setup brightness.

glcd_cmd(0xA0 | 0x01);                      //wr- SEGREMAP
                                                  // this Mirrors display

The bad menu scrolling and X-Y display was my error.
I assigned the wrong pin to SSD1305_nRD.

I realized this once I went into the "glcd_invert_line_color" & "glcd_draw_point" functions and saw they both do a 'read' of the display before writing.

The Brightness and contrast adjustments do nothing. Maybe these do not make much change on the OLED.
These are nice to have features but not required.

Nice code. Thanks