Let's made a PC-base metal detector with usb interface !!!

[Aziz]

Hi WM6,

Hi Aziz, avoid problems.

How you can do usable PI timing and sampling at hundreds od kiloHertz?

Best wishess
WM6

no, there isn't any problem at all. I can exchange Timer0 and Timer2 now.

Regarding your question:
Could you specify your question? I do not understand it right.

Aziz

[WM6]

I will look further, whether this change causes other problems. But it shouldn't be a real problem at all.

Aziz

Hi Aziz, avoid problems.

How you can do usable PI timing and sampling at hundreds od kiloHertz?

Best wishess
WM6

[Aziz]

Some changes necessary.

Hello friends,

during implementing an internal time base for several internal tasks (using Timer0), I have found some conflicting issues.

Timer0 is coupled to Timer1 when initiating a synchronisation (timer 01 prescaler reset). Timer1 is reserved for two PWM outputs (A and B) to make a synchronized DAC output to cycle periods. The DAC output could be well used in a VCA (voltage controlled amplifier). But it has to be fully synchronized to cycle period. This is a must have criteria.

So it would be more convenient, to change the former Timer2 operation into Timer0. The PWM on Timer1 can then only be operated on /1 (no prescaling) as the timer delay instruction has to reset the prescaler. So the PWM frequency can be set from 305 Hz into hundreds of kHz (16 bit timer).

The internal time base could then run on Timer2 instead and won't disturb the PWM outputs. I have defined a 10 ms timer interval (using prescaler /1024) for the time base and it should allow an efficient operation resolution.

The internal time base is used for:
- checking battery on x sec intervals
- checking user interface on intervals (pots, knobs, push-buttons, debouncing of it)
- communication (timeouts, live, status messages, ...)
- status lights (LED's blinking)

I will look further, whether this change causes other problems. But it shouldn't be a real problem at all.

Aziz

[Aziz]

Hi all,

some more notes on the threading model above:

It is obvious, that the cpu simulation thread is being triggered by the external cycle clock coming from the laptop (sound card). The controller instructions were decoded and executed in their presense in the controller program memory (stored in the SRAM). Timer delay will release the MCU for the time period defined by the timer delay instruction parameters (prescaler, count). After the timer is expired, the CPU simulation continues with the next instruction (Timer2 IRQ triggered). At the end of a cycle period, a particular controller instruction signals the end of the cycle and will relase the MCU to continue in the main MCU thread.

A multi-cycle controller program code can also be implemented easily by coding multiple cycles program (each cyles will have its own program code).

I have to implement a special controller assembler program to generate the controller program object code. Depending on the mode of operation, there can be several controller program codes, which will be downloaded on the demand (user interface action). Each operation mode will have its own controller program code of course.

A controller program code could be like this (symbolic interpretation for understanding only):

 
; this is start of cycle
setup hardware (pga, vca, multiplexer, ..)
 
turn transmitter on       (tx pulse)
timer delay 200µs
turn transmitter off
 
active wait 10µs          (damping period)
 
switch amplifier on
nop..
nop (amplifier settling)
 
enable integrator 1 i+
active wait 10µs
disable integrator 1 i+
 
enable sample on channel 1
delay 1µs  (S&H settling time)
hold sample on channel 1
 
timer delay 100µs         (wait for next sampling window)
 
enable integrator 1 i-    (subtracting the previous sampling window)
active wait 10µs
disable integrator 1 i-
 
enable sample on channel 2
delay 1µs  (S&H settling time)
hold sample on channel 2
 
switch amplifier off
clear integrator 1
end of cycle instruction
 
; here could start another cycle code
; ..

So there are many different controller program codes possible. There is almost no limit in implementing different operating modes. So the user can controll all controller hardware parts individually.

Aziz

[Aziz]

Threading Model

Hi all,

below is the basic threading model of my PI controller platform. It shows roughly the interaction between the CPU simulation (CPU code = controller code) and MCU execution mode (AVR microcontroller code).

There is a strict seperation of program codes and the MCU (AVR microcontroller) won't store any CPU code in the flash memory. So it comes with controller code free and should not infringe any existing patents. The user is responsible to meet international patent laws by providing a convenient CPU code, which does not infringe patented methods. The CPU code will be downloaded from the laptop.

The threading model shows also the difference between active delay and timer delay. Active delay won't release the MCU and it stays in the CPU simulation mode. This makes accurate short timings possible. On the other hand, timer delay will release the MCU and switch to the main thread. This will give much processing power for other controller tasks (communication, user interface, .. ) .

The main thread won't know, what the CPU simulation thread is really doing. So it could run either asynchronously or synchronously to the cycle time (with synchronisation status flags or instructions).

I very likely will use Timer0 as an internal timebase for the main thread to signal some states or tasks. To meet accurate timings with less timing jitter, I only will use INT0 and Timer2 interrupts (see below). No other interrupts sources will be used.

The communication part will be the biggest part of the firmware code, on which I will work much longer. It will support upto 256 commands and will be an ASCII based communication protocol. So any ASCII terminal software could be used to test some parts of the hardware. The decoding and processing of the commands will also be very efficient.

Aziz

[WM6]

Hi all,

. It will help to debug and test the target platform.

Aziz

Good luck Aziz -- waiting on your test report.

[Aziz]

Hi all,

I did some interrupt resonse measurements on the oscilloscope:
The timing jitter is exactly as expected: 100 ns width (2 cycles), which has a statistical deviation of +/-50 ns (+/- 1 cycle). This is due to some MCU instructions having two cycles atomic processing time. This jitter can even be reduced further into +/-25ns with special tricks .

The triggering of the INT0 works fine. The timing is quite stable (low jitter). The timer delay CPU instructions will make the main program thread more efficient but is causing +/-1 cycle jitter (interrupt response jitter). We have long delays for TX-on pulse, ground balance and earth magnetic field (external static magnetic field) cancelling delays. So the main thread could get more processing power.

I will focus to and implement the communication part soon. It will help to debug and test the target platform.

Aziz

[Aziz]

Hi all,

I am thinking of changing the external port ALE control signal from PD6 (ICP1) into PD3 (INT1). The PD6 (ICP1) could be eventually used in the Timer1. It is also intended to use either Timer0 or Timer1 for PWM output. Timer2 allows two different PWM outputs (OC1A, OC1B) and would complete use of the PortD (my favourite).

I will buffer all digital output signals from the MCU with a bus buffer (74HC541) to reduce the noise from MCU.

The PWM signals could be used to generate a control voltage to a voltage controlled amplifier (VCA) and offset voltage error compensation. A clean reference voltage is also necessary to make a very clean PWM-DAC output. The PGA-port (Port E) will stil exist to make fast gain changes and LP-filter possible (and probably multiplexing the signal path too).

Synchronisation of the timers is critical then and should be handled well. Fortunately the CPU simulation supports direct peripheral access of the MCU and would allow easy synchronisation and access (platform dependent).

The Timer2 is reserved for timer delays and will allow more processing power to the main program thread (TDLY instruction, no active wait).

As the hardware has only one critical interrupt request input (INT0), no other interrupts will be handled. Peripheral device functions must poll in the main thread for their finish. This will allow only -1/+1 cycle timing jitter (-50/+50 ns) for the pulse cycle triggering.

It seems, that I have to develop my own discrete PGA/VCA and DAC port.


Aziz

[Mechanic]

Hi Aziz,

Great work there. It looks fantastic!

Cheers

[Aziz]

Hi all,

there is a faster version of the PCH (port change and write) instruction:

  ...
  ; Write Address
  out   EXTPORT_CTRL, REG_ONALE_OFFDLE ; (1) Enable Address Latch, Disable Data Latch
  out   EXTPORT_PORT, PI_Param1        ; (1) Write Port Address
  out   EXTPORT_CTRL, REG_OFFALE_OFFDLE; (1) Latch Port Address
 
  ; Write Data
  out   EXTPORT_PORT, PI_Param2        ; (1) Write Port Data
  out   EXTPORT_CTRL, REG_OFFALE_ONDLE ; (1) Enable Data Latch
  ...

Three pre-defined registers have the control signals already initialized. Only single cycle out-instructions necessary to make port change and write. This will save 5 cycles (20 MHz: 250 ns). PCH instruction would require only 750 ns (former: 1000 ns).

Seems to work save.

Aziz

[Aziz]

Current Work

Hi all,

below is the current work of my slow going project. Four boards now finished and the port expander is working as specified and desired (the 74HC238 did arrive today). I did test the port expander with LED's and a test code (seems to work). Final test with scope should be done later.

I have to develop now the following parts yet:
- Coil driver + pre-amp
- PGA (+VCA)
- Integrators (two)
- General user interface module (switches, pot's, ..)
- Software

There is still huge work in the software part to do. Anyway, I am again total bankrupt and have to wait until next month. I have another bunch of parts to order yet. Fortunatelly, the software part does not cost me anything and will fill the gap in the mean time.

Aziz

[slimabidi]

Go Aziz, go!

[WM6]

Hi Slim,

The laptop has sufficient processing power for what you want. The application itself has much reserves. There is no problem at all. But the flexibility is huge. I should get my darn PI controller finished soon.

Go Aziz, go!

[Aziz]

Hi AZIZ,

What about digital lock-in amplifier for your application? This would
be a quite useful feature.

Regards,
slim

Hi Slim,

I am already using the digital lock-in amplifier in my project (laptop side). But I am not following the VLF technique anymore. I am working on the next level pulse induction (PI) detector, which will be capable to be developed just-in-time in the field (for unknown ground conditions). The work will help to develop better PI detectors.

The laptop has sufficient processing power for what you want. The application itself has much reserves. There is no problem at all. But the flexibility is huge. I should get my darn PI controller finished soon.

Aziz

[slimabidi]

Thinks AZIZ

Interesting and fascinating project

Good Works



Your friend Slim