PI CHIP

[mickstv]

I will look into the timing on the rotary encoder also.

This one isn't really an issue the control does still work.

Hows the blocking fet electronics going ?




Mick

[moodz]

errr dont change that setting for now ... there is a bug I noticed where there is no safety net for the frequency value ... it goes to zero when you change it and the interrupts arrive too fast crashing the chip. I will look into it but having too much fun with my blocking FETs at the moment.

Paul

I will look into the timing on the rotary encoder also.

[moodz]

Hi Paul, i've just installed the crystal and caps software loaded ok and I'm happy to say it all looks good no more jitter. The only think I did notice which isn't really a problem is when you turn the rotary encoder fast it seems to some times stop or reverse in number change but at a slower pace it's fine. Also notice the inclusion of the Damping menu.

EDIT : Just noticed if you try to change any settings in TXF Per once you select either X1, X10, or X100 the LCD blanks out.



Mick

errr dont change that setting for now ... there is a bug I noticed where there is no safety net for the frequency value ... it goes to zero when you change it and the interrupts arrive too fast crashing the chip. I will look into it but having too much fun with my blocking FETs at the moment.

Paul

[mickstv]

Hi Paul, i've just installed the crystal and caps software loaded ok and I'm happy to say it all looks good no more jitter. The only think I did notice which isn't really a problem is when you turn the rotary encoder fast it seems to some times stop or reverse in number change but at a slower pace it's fine. Also notice the inclusion of the Damping menu.

EDIT : Just noticed if you try to change any settings in TXF Per once you select either X1, X10, or X100 the LCD blanks out.



Mick

[moodz]

10 mhz I have thanks
I see jaycars have 8 mhz

8 mhz would work however I would have to change the timing constants in the code. A bit more effort and I could add it to the LCD menu

Use 10 Mhz for now ...

moodz

[moodz]

clarification

... My code should not be touching the tx and sampling timing hardware except at initialisation and if you change it on the menu.

moodz.

[moodz]

This should have read:

and look at the waveform at the far RIGHT of the trace and see if there is jitter there.....



Paul, are you sending all of your data to the lcd in one go? If you are, try sending 1 byte/ tx cycle.

Cheers Mick

Hi Mick ... I think the jitter issue was related to my use of the internal RC clock ... it runs at 7.37 mhz and probably isnt that clean to start with then the PLL multiplies it by 16 which would amplify any jitter issues. The code is built around the TX pulse .... The TX pulse itself is generated by a dedicated PWM generator inside the chip that is driven directly by the clock and code wont affect it unless you access a config register. My code should not be touching this after initialisation. At the start of each TX pulse an interrupt is generated. DSPICs are supposed to guarantee a hard / fixed 4 cycle latency for interrupts and the first thing the interrupt does is fire the sample pulse timer that will trigger the sample pulses at preconfigured times after TX cycle start. Again the code does not need to touch the sample pulse on / off times as these too are "hardwired".
I have run a Tx pulse and two sample pulses with spacings of 25 ns and not a single glitch over 2 hours ( 10 Mhz crystal fitted ). This sucker can generated a 50 ns wide sample pulse if such a thing could be used ??!!

The down side of using the overclock crystal at 10 Mhz is that the chip sucks alot more power now from the 5 volt supply because everything is spinning over much faster inside.

The LCD loop runs in the background main loop ..... however it does make use of a low priority interrupt for a timer ( strobing the LCD control lines etc ) ....it is just possible that there is clash with the top priority TX interrupt and that is somehow violating the "guaranteed" 4 cycle interrupt latency ... that would cause an issue. I could remedy by replacing the timer interrupt with a looping counter subroutine ...

Paul.

[6666]

10 mhz I have thanks
I see jaycars have 8 mhz

[Mechanic]

.....and look at the waveform at the far left of the trace and see if there is jitter there......

This should have read:

and look at the waveform at the far RIGHT of the trace and see if there is jitter there.....



Paul, are you sending all of your data to the lcd in one go? If you are, try sending 1 byte/ tx cycle.

Cheers Mick

[mickstv]

Here is the 10 meg hex file ... I think I got all the timing updates OK . It has to run with 5 volts ... it will be a little unstable running the chip off the Pickit supply with the increased speed. Programming is ok though. The 10 meg crystal connects across the two osc in pins 9 and 10 .. disconnect the SATLOCK push button and pullup resistor. The two caps run to ground from each osc input.


[ATTACH]16805[/ATTACH]
Paul.

Hi Paul, Thanks I'll load that in tomorrow and do the mods and see how it goes.



Cheers Mick

[moodz]

I have a surf pi type frontend partially built so i'll finish that over the weekend and see how it compares to the diff frontend.

I've found a 10mhz crystal and a couple of 22pf ceramics so I'll have them on standby once the code is finished and your happy with it.

25ns steps we won't need it any better than that.



Mick

Here is the 10 meg hex file ... I think I got all the timing updates OK . It has to run with 5 volts ... it will be a little unstable running the chip off the Pickit supply with the increased speed. Programming is ok though. The 10 meg crystal connects across the two osc in pins 9 and 10 .. disconnect the SATLOCK push button and pullup resistor. The two caps run to ground from each osc input.

Metal23_10MhzV2.hex.zip

Paul.

[mickstv]

Thats not too bad Mick ... what would a surfpi get ? Anyway I have had the 10 Mhz version running whilst working on other bits here and it seems to be quite stable. Another good outcome is that the clock resolution is now 25 ns steps for sample pulses ....so you can dial up exact figures like 1.250 microseconds for example.

Paul.

I have a surf pi type frontend partially built so i'll finish that over the weekend and see how it compares to the diff frontend.

I've found a 10mhz crystal and a couple of 22pf ceramics so I'll have them on standby once the code is finished and your happy with it.

25ns steps we won't need it any better than that.



Mick

[moodz]

Thanks for looking at it Paul. My div counting may have been a little wrong but still close. I'll put the detector on the back burner for now.

I did manage to get the diff frontend working better it can now detect a 3 gram lead sinker at about 17-20cm in air which is not too bad. just have to tidy up the wiring. The coil I made is just one pair out of a length of cat5 cable and about 22turns and about 25cm diameter.



Mick

Thats not too bad Mick ... what would a surfpi get ? Anyway I have had the 10 Mhz version running whilst working on other bits here and it seems to be quite stable. Another good outcome is that the clock resolution is now 25 ns steps for sample pulses ....so you can dial up exact figures like 1.250 microseconds for example.

Paul.

[mickstv]

Thanks for looking at it Paul. My div counting may have been a little wrong but still close. I'll put the detector on the back burner for now.

I did manage to get the diff frontend working better it can now detect a 3 gram lead sinker at about 17-20cm in air which is not too bad. just have to tidy up the wiring. The coil I made is just one pair out of a length of cat5 cable and about 22turns and about 25cm diameter.



Mick

[moodz]

Thanks Mick TV and Mech .... Ok I have poked around and there is some jitter there but not quite as bad as 8 us as reported ... though I dont dispute this.

I have added a 10 Mhz crystal to both the 4011 and the 4012 and they are running stable even though I have effectively overclocked by 33% from an internal MIPs of 30 to 40 ...I did this mainly to test the head room in the PLL multiplier .. so no problems there.

The TX pulse is generated by the fixed hardware in these chips ... apart from initialisation the code does not touch this hardware again .... so if there is jitter present on this pulse no amount of code will improve it.

The sample pulses are generated by interrupt code though ...

The sample pulses show a 2 - 4 us slip every 5 - 6 seconds ...however in this time a tremendous amount of cycles have been averaged. This points to a clash of interrupts .... I do update the LCD using interrupts and this may be clashing with the interrupt that drives the main sample pulses. There is a another no code way around this but I only thought of it after I wrote this lot and would have to change my processing loops a fair bit.

5 seconds x 32 mainloops x 16384 samples = 2.6 million samples processed.

I wont get too caught up with a chase for perfection as the timing is quite accurate for my purposes and the aim of this exercise is to develop all the parts of a working detector signal chain.

I have got to keep my eye on the main game and that is descrimination and depth with a monocoil format ... both of which I am very very close to nailing as soon as my blocking FETs start working properly ...actually I was going to do that tonight but have sidetracked into this jitter investigation not that it isnt important also.

I will put up the hex files with the changes for running with 10 Mhz crystals as soon as I change all the timing constants ( timing is set for 7.37 Mhz calculations )

moodz.