VDI-RODERICO

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

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.

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

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]

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

[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

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

[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

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

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

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

[waltr]

maybe it is just bad luck as you say but these displays are very expensive to fail like this (bad quality components?) a refund makes sense, anyway, very good work of debugging the problem, finding a fix and very well documented in the above link.

Thanks. Just got a notice that they refunded the purchase.

The weather got much better yesterday so got out to the old Farm site. I have hit this place hard for three year but know there is more hidden in the iron junk. So went slow an seep from multiple angles look for and indication of a non-ferrious target.
The X-Y display is excellent for this. With bit ferrous and non-ferrous close the X-Y graph does not show a straight line but the line will curve or bend. Digging these signals did find non-ferrous items along with ferrous. Many were .22 shells (brass) but did get a few great items.
One was an 1865-1889 3 cent nickle (70% cu, 25% ni the diameter of a US dime but thinner).
Best find was an 1813 1st Regiment of Artillerist button. For this button I dug 6" (15cm) down and found an Ox shoe. Re-sweep and now a clean signal. another 3" (7.5cm) down was the button (20mm diameter).
The VDI numbers were uncertain and changed at different sweep angles.Other good find were Early 1800 buttons and the chape from a shoe buckle. In all 5 great finds.

[roderico]

maybe it is just bad luck as you say but these displays are very expensive to fail like this (bad quality components?) a refund makes sense, anyway, very good work of debugging the problem, finding a fix and very well documented in the above link.

[waltr]

good to know the problem and the fix, do you know if this is a common issue of all OLED displays or just a specific problem of some models?

Seems to be a problem with only Some batches of the same OLED. I did post on the Adafruit forum, bought from Adafruit, and Customer support stated many 100's have been sold and only a few have died. A forum search only came up with four having similar issue.
They also offered a refund for the two displays and suggested I Not buy that one again.
Here is a thread I posted on Adafruit with details of the fix:

https://forums.adafruit.com/viewtopic.php?f=47&t=161883

So it seems that this is not a common issue but simply the luck of the draw, or many chip batch, of the Chinese made units..

I did get out detecting for about fours hours today. Display worked without issues.
Today was a local park so more trash than rusty stuff. I am starting to get a better 'feel' on target ID and got to Call the target correctly. Still lots of junk targets, like can slaw, in the low-mod VDI numbers that could be a good target. I do like Nickles and rings so must dig the junk.

[roderico]

good to know the problem and the fix, do you know if this is a common issue of all OLED displays or just a specific problem of some models?