VDI-RODERICO

[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 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]

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...

[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]

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

[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

[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]

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]

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 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]

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]

I updated the schematics with all the changes so far for v2.2, although you do not need to change your pcb as the firmware should work with all pcb v2.x. I left the voltage divider for 3.3V since there is no clear replacement for MCP1525. The MCP604 is optional but it gives a narrower filter and no phase different between input and output signals, R16 might not be necessary, if there are no more bugs then the firmware could be released as v2.2.

[roderico]

vdi 2.2

This is version 2.2, the main changes with respect to version 2.1:

- ST7567/ST7565 display driver (kroman01's request)
- SSD1305 display driver (waltr's mod)
- initial 3.3V support (waltr's mod)
- "frame" theme (kroman01's request)
- change XY graph to 64x64 pixels
- updated led version

to rebuild the firmware (e.g. if you want to change pin assignments, new pic, etc.) it is sufficient to set define variables in the compiler options of your project, in section "preprocessor macro definitions" or "define macros", e.g. for waltr's mod you would need to add: _P18F26K22, _SSD1305, _VDD3V3 and it should compile fine

[waltr]

Great work again. Thanks.

I do have a feature request. It will need one more PIC pin as an output but should be doable on all existing PCBs.

Feature is a Low Battery Alarm.
Idea is if Battery Voltage drops below a programmable threshold than a piezo buzzer is "chirped' say every 5-10 seconds.
This 'chirp' can be like the low battery warning found in smoke detectors.

Reason is I have left my detector On without noticing and the LiPo battery drain until a cell went to zero Volts. this Killed the battery pack. If it 'chirped' then I would have known to check the detector and turn it off.

??possible??

[roderico]

the code to drive a buzzer could be used for that but it requires to free the backlight pin and move it e.g. to the open drain and but it is not backwards compatible with v2.x (this pin should be freed in v3.x) https://www.geotech1.com/forums/show...896#post263896

IMO a more simple a better solution is to use a BMS for Lipo batteries, they are really cheap in ebay 1-2 USD and have over-discharge protection to avoid to ruin these batteries which are very expensive (the alarm might not always work, e.g. if you are away and left the detector on). I've been using three 18650 batteries with HX-3S-01 BMS and have always worked well for me.