VDI-RODERICO

[roderico]

VDI numbers are extracted from the histogram (some kind of average) so many information is lost but that was the option for LCD displays. With a GLCD display you have access to X, Y signals and can make a better judge of the target than with "averages", e.g. via X,Y patterns in the XY display, the easy patterns are a straight line, circle and an ellipse. You see a straight line when X,Y phase difference is 0 or 180 in the scope and a nice peak in the histogram, when you have 90 degrees difference you get a circle (furnace) and in between an ellipse. Irregular patterns would be interesting as you say you can discriminate non-ferrous metals with ferrous metal, it will be interesting to see some sample pictures, an easy way is just to make some air tests with these targets together and different orientations to find out what XY pattern to look for in the fields...

[roderico]

Something is complicated here ... Maybe everything is easier? Here .. such an amplifier was used in the Russian forum ..[ATTACH]48928[/ATTACH]

I gave it a try to the mod posted by SWL and as in the spice simulation (https://www.geotech1.com/forums/atta...2&d=1577791683) it has too much gain and saturates very quickly. I simplified it by removing one op-amp stage (using only a MCP604 or two MCP602 instead of TL072+MCP602) to have something in between (see attached ltspice simulation, green original, blue SWL mod simplified). With two op-amp stages there is no phase shift between the input and output signals (0 at ~ 6Hz) and it also gives a narrower filter (with a slightly more gain that can be tuned). With one MCP602 you might need to trigger in the falling edge for not to miss the signal in some cases as the phase difference is -180? (green curve at ~ 7Hz). I put the simplified SWL in the schematic although this is optional not necessary (other filters will also work well), I also updated the reset circuit (taken from the PIC18F25K22 data sheet) since I had some problems programming some pics. This change however is recommended if you are also having similar problems...

[roderico]

This firmware is just for testing v2.2 it does not include new features but integrates the changes that were already circulating since version v2.1 (e.g. the ST756X driver or kroman01's suggestion in the form of a "theme" in the display menu) except that I expanded the XY graph for better visibility (see attached picture). When integrating the ST756X driver I had to change two pin assignments with respect to previous tests:
RES (reset) -> CS2 (in KS010 and
A0 -> RST (reset in KS010
This is just to make it easier to build a pcb directly from the display. If you did not build a pcb for the ST756X you only need to change these two wires to make it work again. For SD1305 it is not yet clear the 5V -> 3.3V change in v2.x I would just post the source code after a few tests so that waltr could also compile it.

[kroman01]

thank you roderico for your work I currently have nothing to test this firmware on but I can share my insights as soon as possible in a week
regards

[waltr]

Thanks for update. I like the battery Voltage on the main display.

For 3.3V PIC nothing really needs to be done. All just worked.

[roderico]

ok I see but still remains the compatibility with the display, the idea to be compatible with v2.x would be just to replace the current display e.g. ks0108 reusing the pins freed by the old display and in this case also to replace 78L05 -> 78L33. The table below summarizes the pin assignments of current displays in V2.x (if I'm not mistaken), for SD1305 I took them from your display adapter, there are 3 pins that makes the PCB not backwards compatible RA4 (free), RA6 (oscillator), RA3 (battery), moving these to RA2, RA5 and/or to RC[4-7] would make it compatible with v2.x, otherwise this would make a v3.x where all pin assignments could be optimized

MCU --- LCD --- KS0108 --- ST756X --- SD1305
============================================

RB  --- DB  --- DB  ------ DB  ------ DB
RA2 --- RS  --- RS
RA5 --- EN  --- EN  ------ RD
RC4 --- RW  --- RW  ------ WR
RC5 ----------- RST ------ A0
RC6 ----------- CS2 ------ RES ------ RD
RC7 ----------- CS1 ------ CS  ------ WR

============================================

RA4 (NC)   -------------------------- CS
RA6 (OSC2) -------------------------- RESET
RA3 (BAT)  -------------------------- DC

[roderico]

a simple solution for v2.x would be to use the same pin assignment as the ST756X, you can always change back in the source code and/or in a new v3.x

MCU --- LCD --- KS0108 --- ST756X --- SD1305
============================================

RB  --- DB  --- DB  ------ DB  ------ DB
RA2 --- RS  --- RS
RA5 --- EN  --- EN  ------ RD  ------ RD
RC4 --- RW  --- RW  ------ WR  ------ WR
RC5 ----------- RST ------ A0  ------ DC
RC6 ----------- CS2 ------ RES ------ RESET
RC7 ----------- CS1 ------ CS  ------ CS

[waltr]

That would work for your code releases.
Your source code is very easy to modify for other pin-outs.

The reason for the pin-out I choose for my display board is to use other displays.
My board can have an LCD 2-line or a TFT, or the OLED plugged in.

[roderico]

the SSD1305 driver is identical to the ST7567 (they both use the 8080 parallel interface and the same memory addressing) since many code was changed I used the ST7567 as template and rewrote the initialization to make it easier to understand. Many of the settings are defaults and some might not be needed but as I do not have any of these displays I don't know if I broke the driver. Could you test the new code? As you have a working initialization you could easily find out what is missing or wrong in case it fails to initialize. It would be also very good if you could also test the contrast and brightness controls from the menu. For the VREF I removed it from the vdi as it cancels out in the ratio, it would only affect to the str, setting it to 3 could be a good approximation to 3.3V instead of 5. I also added some defines for PIC18F26K22 in the 25k22 file.

[waltr]

Ok, I will setup a project and build the 2.2b2 code and test.

Contrast and brightness control sounds interesting.

This may take a few days.

[waltr]

Ok, got to try the v2.2b2 code with the SSD1305 OLED display.
I did a few code mods to re-map pins-easy enough to do.

After programming the PIC18F25K22 and powering on my TGSL-VDI the display came on but:
It is Mirrored Right-Left....... Oh my.

The X-Y does not look correct- it has very course and multi-lines instead of a clean single width line.

Re-powered and clicked button for Menu:
Looked ok except for mirrored.
Clicked button the scroll through menu:
The line that was 'reversed' became a mess of vertical lines.

Not too bad for first try with this code.
I will dig into and compare to the 2.1 code I mod'ed to see what happened.

[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

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

[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

[waltr]

I will give those suggestions a try.