PI CHIP

[sido]

It could be a bug but more likely the original code was never designed to handle very short times ... More conventional timings like 100 us on and 400 off etc. there is prob a race condition in an interrupt handler.

Hey Moodz, i assume you mean T(race) Heheheheh

Quote from Moodz.........
"So you just want an arbitrary pulse sequence to be fired to then repeat. No real prob with that. I'd rather use an FPGA to do this ... Actually I did use one ..but that's another story. So the short answer is yes ... We can do that ...just need to pull the finger out and code it up."

Yes....If it is not a big software code adjustment to add for each pulse output of UNIPI V300 and providing the chip can handle it, I would appreciate it, and assume other's here will too.

We may have to call it UUNIPI (Ultimate UNIPI)....or what ever you may think is suitable for its purpose, maybe UNIPI V400.

BTW, if you say you have already tried it, what do you mean?......If it's something recent, no need to answer...Dont want to know.

I would prefer the UNIPI V300 to add any of the above modification if possible, as i see it as Ultimate uniform platform for most pulse timing needs, more than enough timing requirements that one may need for experiments.

Much appreciated in whatever you may choose there Paul. If it cannot be done with the current hardware, just let me know and i will look into the current FPGA format of your creation, if it is capable of providing the above requirements.

Though i would prefer the added timing adjustments ATM to be done with the current UNIPI, as i have been working on a PCB design based around it.

Only if you can adjust the finger as you say......versus the limited time you may have available.

Much appreciated in what you may come up with.

Cheers Sid

[Stefan]

Hi,

I have a small suggestion with regards to the hole sizes in PCB for home construction. I always reduce the size of the pad holes to minimium size. This allows the pad to be full size after etching and also the small hole size guides the drill to the centre of the pad during drilling. A simple idea but you will find it works well. Nothing worse than drilling out the side of a pad and breaking a connection.

Regards,

Stefan

[IBGold]

Hi I have to agree with Stefan his method does make the boards easier to drill.

Moodz OK after more testing at various timings I find that your code does not allow for sampling in the on time therefore not suitable for the GG Tinkerer project will the UNO32 code allow for it?

Regards, Ian.

[moodz]

Hi I have to agree with Stefan his method does make the boards easier to drill.

Moodz OK after more testing at various timings I find that your code does not allow for sampling in the on time therefore not suitable for the GG Tinkerer project will the UNO32 code allow for it?

Regards, Ian.

It might ... however you will need to provide the timing diagram for the TD.

In the meantime I found another timing diagram lying around on the web ( for SIDO ) and popped some code into the UNO32 to see how it would do .. indeed it is not bad ... very low CPU overhead around 5%, arbitrary pulse trains with patterns that are only limited by the RAM to store them.....and the timing clock is 80 MHz so thats 12.5 nanoseconds of resolution on adjustments. Each mark and space in the pulse train is fully adjustable on the fly and its all generated with 50 lines of code ... not bad if I say so myself

There are 5 outputs on the UNO32 implemented so far ... Pin3 = TX Pin 5 = channel 2 sample A Pin 6 = channel 2 sample B Pin 9 = channel 1 sample A Pin 10 = channel 1 sample B. The ground balance samples are another story ... I ran out of pulse hardware on the PIC32 .. but doable. ... but who needs ground balance when you have the patent pending "moodz" AGB system ....right ? ...

This system would be very busy to manually enter a pulse train and adjust each pulse timing on a simple LCD display ... so I am thinking a bluetooth interface to program it from a smartphone ( prob android ).

Heres the hex so you can verify ... note the menu does not work !!!! ... this is a UNIPI hack to get the pulse generator only going ... its not adjustable ...

I would upload the pix and the hex .. but nothing is uploading to geotech at the moment

[moodz]

...try to upload pix again ...

damn ... cant upload anything even a screenshot of the upload error ?? doh.

[moodz]

The pix are posted at a well known unmentionable web site under this topic.

"pulse generator for doing detector stuff"

[moodz]

The pix are posted at a well known unmentionable web site under this topic.

"pulse generator for doing detector stuff"

...third try ...

comparison of the TX pin to the other pins ... the pulse train is similiar to an expired patent and old detector.

[Mechanic]

Hi Moodz,

I don't know how you have set up the pulse train, but if its using the output compare module, you only need 1 oc for each channel. After the + sample has been taken, re-assign the OC to the - sample pin....

Cheers Mick

[moodz]

Hi Moodz,

I don't know how you have set up the pulse train, but if its using the output compare module, you only need 1 oc for each channel. After the + sample has been taken, re-assign the OC to the - sample pin....

Cheers Mick

....heh heh ... You are right Mick ... It's using all the OCs .. I just implemented the timings as per the diagram .. With pulse steering I will have all the sigs and one OC left over for ... Channel 3 Or even the AGB. I only hammered the basic code out to test for any jitter or funny business in the pulse hardware that microchip implements. So far so good.
Now to add the QED timings from the patent ...for experimental purposes only.

[sido]

....heh heh ... You are right Mick ... It's using all the OCs .. I just implemented the timings as per the diagram .. With pulse steering I will have all the sigs and one OC left over for ... Channel 3 Or even the AGB. I only hammered the basic code out to test for any jitter or funny business in the pulse hardware that microchip implements. So far so good.
Now to add the QED timings from the patent ...for experimental purposes only.

Hi Moodz, great work, exactly what i requested

The pulse train is looking good.....Actually it looks so good that it may create some anxiety in certain corners
This code is for the UNO32?? So for the Dispic4011, is it a bit more complicated to implement a similar code or is it just not worth the trouble since the UNO32 is a better, faster and versatile platform?

I like the user adjustable timing function of the 4011 with LCD interface in UNIPI V300. Saves using a Laptop out in the field for single pulse timings. In saying this though................

Have a few question on the UNO32 platform.
Will you be including the LCD interface (like UNIPI V300) or has it been included somewhere which i may have missed some posts about it?
Will you be making this pulse train user adjustable and if so......you will end up having the ultimate timing setup for field use testing.
Will the dedicated LCD be implemented with user adjustable parameters?

If LCD interface cannot be implemented in UNO32, will we require a laptop out in the field to change timing parameters in code to find the best timings per any given detector design? Then end up settling for the best fixed timing for a given situation?.....(just saw you mentioned bluetooth)

Quote from Moodz
"This system would be very busy to manually enter a pulse train and adjust each pulse timing on a simple LCD display ... so I am thinking a bluetooth interface to program it from a smartphone ( prob android )."

Moodz, i dont mind manually entering pulse parameters, however long it takes. I know bluetooth would make life easier, but prefer one stand alone equipment to be out in the field for testing. Stick with a dedicated simple LCD with user adjustable parameters for now.....and maybe include another version with Bluetooth connectivity

BTW, the other Forum you mention about in a previous post, I cannot register Have tried twice and i seem to go unnoticed, nothing wrong doing on my part, so i have given up. I think my GMAIL account wont allow me, but thats all i have.
If and when you post there, can you please also post here so i can view it, thanks
So many questions....either way great progress

Regards Sid

[6666]

Hi 6666
Can't remember the brand,Iv'e thrown the wrapper away.
It was clear vinyl,looks like contact.
The roll looks white,when unrolled it has blue squares printed on the backing paper.

@sido my printer is an old Brother,with a generic toner cartridge.
The boards turn out very usable. As pete stated,the boards have to be cleaner than a nuns...
I've made 4 boards for the Pickini project,I will post some picks when I recharge my camera.
Cheers
John

Hi John
I got some "contact" from office works to try out
what i found was after it had been through the laser printer
the contact shrunk and pulled the paper in slightly
did this shrinkage cause you any problems when transferring to PCB ?

[johnandles]

Hi John
I got some "contact" from office works to try out
what i found was after it had been through the laser printer
the contact shrunk and pulled the paper in slightly
did this shrinkage cause you any problems when transferring to PCB ?

Hi 6666,I didn't have any problems with laser causing shrinkage.
All the IC holes lined up,even a 14 pin socket was accurate.
Did you also try that print n peel from china?
Cheers
John

[moodz]

Hi Moodz, great work, exactly what i requested

The pulse train is looking good.....Actually it looks so good that it may create some anxiety in certain corners
This code is for the UNO32?? So for the Dispic4011, is it a bit more complicated to implement a similar code or is it just not worth the trouble since the UNO32 is a better, faster and versatile platform?

I like the user adjustable timing function of the 4011 with LCD interface in UNIPI V300. Saves using a Laptop out in the field for single pulse timings. In saying this though................

Have a few question on the UNO32 platform.
Will you be including the LCD interface (like UNIPI V300) or has it been included somewhere which i may have missed some posts about it?
Will you be making this pulse train user adjustable and if so......you will end up having the ultimate timing setup for field use testing.
Will the dedicated LCD be implemented with user adjustable parameters?

If LCD interface cannot be implemented in UNO32, will we require a laptop out in the field to change timing parameters in code to find the best timings per any given detector design? Then end up settling for the best fixed timing for a given situation?.....(just saw you mentioned bluetooth)

Quote from Moodz
"This system would be very busy to manually enter a pulse train and adjust each pulse timing on a simple LCD display ... so I am thinking a bluetooth interface to program it from a smartphone ( prob android )."

Moodz, i dont mind manually entering pulse parameters, however long it takes. I know bluetooth would make life easier, but prefer one stand alone equipment to be out in the field for testing. Stick with a dedicated simple LCD with user adjustable parameters for now.....and maybe include another version with Bluetooth connectivity

BTW, the other Forum you mention about in a previous post, I cannot register Have tried twice and i seem to go unnoticed, nothing wrong doing on my part, so i have given up. I think my GMAIL account wont allow me, but thats all i have.
If and when you post there, can you please also post here so i can view it, thanks
So many questions....either way great progress

Regards Sid

The Microchip digital peripherals take some hammering to get right .. there was a small amount of jitter even though the signals are being generated by "fixed logic" not CPU instructions ... finally got it running ... the CPU on the UNO32 does not support Pin remapping ( as Mechanic suggested ) .. instead I bring out 5 pulse pins and a number of pins to steer the pulses. A simple AND gate can be used to select particular pulses from a pulse sequence. The pulse steering pins actually allow more fancy things to be done than with pulse remapping ( especially for bipolar pulsing and overlapped sampling ).

I think I am going to go with the Bluetooth serial to android because of the sheer number of settings. For 5 pulse outputs having 16 programmable pulse 'windows' each window requires a window length, pulse start and stop in that window and a pulse mapping ( ie which output select pins or pulse steering will be made active ) ..... thats 5 x (16 window slot + 16 start + 16 stop ) which is 240 settings ... not counting the admin controls etc .... maybe 300 settings. Thats just for one pulse set. 10 pulse sets is 3000 settings.

The Bluetooth link will have the following benefits ....

1. Its cheap ( $5 hardware cost and the rest is code )
2. No need to store settings in the detector .. the terminal can squirt them down through the link.
3. The android/iphone/laptop software app is already written .... a bluetooth terminal emulator with scripting or similiar can do the saving and loading of pulse params to the detector box.
4. you can set the detector up for testing ... walk round to wave targets at the coil and see what is happening on the handheld terminal .... excellent.
5. Bluesky application interface for later touch screens or backend processing ( bluetooth can transport 1Mbit/sec)
6. detector firmware can be load from bluetooth for "security" ... if detector stolen it wont work

... a two line LCD is never going to cut it for this application .. the menu would be massive.

I can still hang an LCD and rotary off the box but that would be more for adjusting just a handful of critical values. The values to be adjusted would be mapped via the terminal config.


Typical use.

1. Turn on detector.
2. Start terminal app on phone and connect to detector via Bluetooth.
3. Select pulse profile and load to detector.
4. Start detecting.

[sido]

The Microchip digital peripherals take some hammering to get right .. there was a small amount of jitter even though the signals are being generated by "fixed logic" not CPU instructions ... finally got it running ... the CPU on the UNO32 does not support Pin remapping ( as Mechanic suggested ) .. instead I bring out 5 pulse pins and a number of pins to steer the pulses. A simple AND gate can be used to select particular pulses from a pulse sequence. The pulse steering pins actually allow more fancy things to be done than with pulse remapping ( especially for bipolar pulsing and overlapped sampling ).

Fair enough, so the UNO32 not supporting Pin remapping, makes the whole running code more complex.

I think I am going to go with the Bluetooth serial to android because of the sheer number of settings. For 5 pulse outputs having 16 programmable pulse 'windows' each window requires a window length, pulse start and stop in that window and a pulse mapping ( ie which output select pins or pulse steering will be made active ) ..... thats 5 x (16 window slot + 16 start + 16 stop ) which is 240 settings ... not counting the admin controls etc .... maybe 300 settings. Thats just for one pulse set. 10 pulse sets is 3000 settings.

If you follow the SD2000 timing example, is it not only 62 programmable pulse windows to generate a similar code with the seven pulsed outputs, excluding pulse mapping and admin controls??
The main pulse train i labelled S1 in SD2000 example a few posts above, Is it not 20 pulse windows that initially will require to be set. If so once set its just a matter of altering a couple of pulses here and there once out field testing?

Excluding the last 4 single pulsed outputs S4, and the 3 PWM, the only complex pulsed outputs is S1, S2, and S3.

So, i am not sure what i am missing when you suggest as example 240 adjustments required per single pulse pin output.

The Bluetooth link will have the following benefits ....

1. Its cheap ( $5 hardware cost and the rest is code )
2. No need to store settings in the detector .. the terminal can squirt them down through the link.
3. The android/iphone/laptop software app is already written .... a bluetooth terminal emulator with scripting or similiar can do the saving and loading of pulse params to the detector box.
4. you can set the detector up for testing ... walk round to wave targets at the coil and see what is happening on the handheld terminal .... excellent.
5. Bluesky application interface for later touch screens or backend processing ( bluetooth can transport 1Mbit/sec)
6. detector firmware can be load from bluetooth for "security" ... if detector stolen it wont work

That sounds like a great idea. If it facilitates and simplifies the changing of parameters, as in this case, then this is the way to go, if not only for the UNO32's capabilities.

... a two line LCD is never going to cut it for this application .. the menu would be massive.

I can imagine the extra long coding required.

I can still hang an LCD and rotary off the box but that would be more for adjusting just a handful of critical values. The values to be adjusted would be mapped via the terminal config.


Typical use.

1. Turn on detector.
2. Start terminal app on phone and connect to detector via Bluetooth.
3. Select pulse profile and load to detector.
4. Start detecting.

Looks the way to go seeing the alternative method is way more complex.

Regards Sid

[6666]

Hi 6666,I didn't have any problems with laser causing shrinkage.
All the IC holes lined up,even a 14 pin socket was accurate.
Did you also try that print n peel from china?
Cheers
John

Hi John I have not tried that print n peel from china
but I have tried this

Heat Toner Transfer Paper

http://www.ebay.com.au/itm/A4-10Pcs-...item27ca75648f

The first test worked very good, with iron set to cotton
I need to do more testing.
and you can get ammonium Persulphate from Jaycar.