New Frankenproject -

[Pete the Builder]

G'day all!

I'm currently working on a few things, but my pet at the moment is a project based loosely on BW's UPIM front end and cap switching. (This isn't just the resurrection of the UPIM, but it has similar design goals). At the moment, it's PI, but I'm hoping to learn enough to make it three-mode and fully automatic, with an option to go full manual. I have much to learn before that happens, though!

Right now, I'm about to smoke test a new front end with automagical damping. It's not particularly brilliant (more 70s era than hyper-complicated modern), but it's something I've wanted to try. The rest of the device will use the UPIM switching caps feature, a "generic" MCU interface, a GLCD to show what's happening, and even a couple of knobs to twist!

The point is to make it suitable to attach to just about any MCU - Atmel, PIC, Arduino (I'm using the new Due as my core board), even eZ80 for us old 8-bit farts; and there's no reason it wouldn't work with modern 8051 architecture devices either. I'd like it to be able to be used on the PicAxe family, although speed and pincount might be an issue. (There are workarounds I'm considering to make it absolutely universal - using I2C to perform all the I/O, so if the MCU has two pins spare, it should be attachable. But that's a bit airy-fairy right now - I'm trying to sort out the pointy end first!). So the goal is to have a fairly reasonable and stable front end, with basic software that will work to find metal, but the option to 'soup it up' software-wise, much like an Open Source project.

The basic version, for fast processors with lots of fast RAM, just needs one ADC channel and optionally one or two DAC channels.

The switched-cap version is less demanding in terms of speed, but perhaps more complex in terms of RAM storage and floating-point functions. It needs the same analogue resources as the "basic" model, but also requires up to 9 outputs to do the cap multiplexing and management.

Both models will use the exact same front end. The only real difference is the optional cap stuff. All the rest of the functions will be automated, except for the user interface, which will vary between fully digital (up/down/prev/next/select/esc/enter/menu buttons and a LCD menu) and analogue (no buttons, just pots to do the same thing, all functions visible on the LCD). So it should appeal to modern button nuts and us older knob twiddlers.

If the testing succeeds (I'm hoping to get some data tomorrow), I'd like to publish/present the idea here, but I need to be sure I'm doing the right thing as far as creating a new thread or forum somewhere.

Since it's based on the UPIM, I guess it makes sense to create a new thread there, but I just wanted a quick confirmation that that would be appropriate?

Anyway, that's the idea and overall plan, and I'll try and update as soon as possible once I know the front end is working. Meanwhile, if you have any suggestions or comments, please let me know (bear in mind, I'm still learning, and if you start talking technical, I might cry). So please be gentle...

Thanks for reading all this. I hope I haven't stood on anyone's toes, or missed something silly, or violated any patents. It's all about fun, for me and for anyone using it.

Cheers guys!
PtB

[Pete the Builder]

Hmm. All quiet n the Western Front.

I have a very small amount of really nice news. I figured out how to twist Pspice's arm on my resurrected Win7 laptop, and my active damping circuit seems to do what it's supposed to do! And I've literally just verified it (very roughly) on perfboard...

I'm so happy I could pee!

What I've managed to (probably accidentally) do is to 'eliminate' the initial return pulse spike, without interfering with the signal of interest - i.e. no damping resistor/cap. Actually, in terms of BW's simple front end, the NE5534's inputs invert during that pulse (I don't fully understand why, but that's exactly what happens), then within about 8-10 uS of the falling edge's return to 'normal' signal level, are able to begin amplifying the slope of the returned decay signal. (Forgive my improper terminology). I hope that makes sense... I'll put up a screendump of the analysis shortly (I'm working on an old laptop with very dodgy networking, and I'm posting this from my ipad, so I'm snookered in the image upload department).

The next step is to fire up my Stingray CRO and get some screen grabs for comment. I need to ensure I'm looking at the correct part of the returned waveform... The sim seems to indicate I could begin sampling within 12-15 uS of the spike's falling edge, but I'm sure that must be wrong. If only I had better maths skills...grrr...

I noticed with Pspice, that varying the sim time made a huge difference to how long the rising/falling edge damping 'rang' - obviously, this is without changing anything else in the sim run. So I need to learn how and why this behaviour occurs. Any suggestions or tips would be most welcome at this stage... I really hope I'm not doing something utterly unforgivable and working on a hypothetical-only circuit...

I'll get the screenshots first, and maybe they will show something I've missed.
-PtB

[mikebg]

Hi PtB,
Please explain what means term "automagical damping" used in post #1.

[Tinkerer]

Hmm. All quiet n the Western Front.

I have a very small amount of really nice news. I figured out how to twist Pspice's arm on my resurrected Win7 laptop, and my active damping circuit seems to do what it's supposed to do! And I've literally just verified it (very roughly) on perfboard...

I'm so happy I could pee!

What I've managed to (probably accidentally) do is to 'eliminate' the initial return pulse spike, without interfering with the signal of interest - i.e. no damping resistor/cap. Actually, in terms of BW's simple front end, the NE5534's inputs invert during that pulse (I don't fully understand why, but that's exactly what happens), then within about 8-10 uS of the falling edge's return to 'normal' signal level, are able to begin amplifying the slope of the returned decay signal. (Forgive my improper terminology). I hope that makes sense... I'll put up a screendump of the analysis shortly (I'm working on an old laptop with very dodgy networking, and I'm posting this from my ipad, so I'm snookered in the image upload department).

The next step is to fire up my Stingray CRO and get some screen grabs for comment. I need to ensure I'm looking at the correct part of the returned waveform... The sim seems to indicate I could begin sampling within 12-15 uS of the spike's falling edge, but I'm sure that must be wrong. If only I had better maths skills...grrr...

I noticed with Pspice, that varying the sim time made a huge difference to how long the rising/falling edge damping 'rang' - obviously, this is without changing anything else in the sim run. So I need to learn how and why this behaviour occurs. Any suggestions or tips would be most welcome at this stage... I really hope I'm not doing something utterly unforgivable and working on a hypothetical-only circuit...

I'll get the screenshots first, and maybe they will show something I've missed.
-PtB

We really need to see the screen shots. There must be no ringing at all. 12 to 15us is long.

[Orbit]

That's great ,I read almost in one forum for detector flying saucer !!

[Pete the Builder]

Hi PtB,
Please explain what means term "automagical damping" used in post #1.

I'm so sorry, Mike, I shouldn't use colloquialisms or "nerd-ish"... "Automagical" is a computer/tech slang word meaning "beautifully automatic" (in the engineering sense). I should just use "automatic" instead.
My apologies for the confusion.
-PtB

[Pete the Builder]

That's great ,I read almost in one forum for detector flying saucer !!

I like that! Except, there was no anal probing or mass hallucinations! Maybe too much wishful thinking?
-PtB

[Pete the Builder]

We really need to see the screen shots. There must be no ringing at all. 12 to 15us is long.

Tinkerer, please allow for youthful exuberance here. I really am dysmathic, and this is my first attempt at a major modification of someone else's modern, properly designed PI front-end. I'm lucky the damned thing didn't catch fire, fall down, and sink into the swamp!

But I appreciate the feedback... Now that I know this is a good starting point, I can begin to tune my little circuit to improve it, step by step.

At least it seems I'm in the right ballpark. Thanks for the information!

-PtB

[Pete the Builder]

A little proof...

OK. I have good news, and I have bad news. The bad news is that I've fried my Due module, and they're going to be on backorder for 3-4 weeks.

The good news is, I've managed to grab a spice simulation shot for the falling edge of the inductor's pulse. Please note, I was out by an order of magnitude of my estimate of the damping time. My apologies for that, I'm still getting to grips with PSpice!

Now, I apologise for everyone with modem connections, but I can't seem to use one inline image (I prepared a thumbnail to help those people) AND just have another larger image as an attachment.

At the moment I'm snookered re: getting an MCU I can easily program and use as a simple pulse generator to drive my TX butterfly coil with variable pulse widths, frequencies, etc. I have a box of old demo boards from Microchip and others, but they're all a bit old, and very difficult for me to program. But I think I've got an ARM Cortex M7 lying around somewhere. I'll try this afternoon to not blow that up too. Fingers crossed, I'll have some real information up in the next day or so.

So, here is the theoretical proof of your aliens, Orbit!

-PtB
[EDIT] : Sorry, forgot the legend.

The purple trace is the coil + voltage.
The red and blue traces are the ones I'm interested in, they are the front-end amp's - and + inputs (I think! This version of spice is very unfriendly in terms of naming and identifying signal traces),
The yellow trace is the derived signal for controlling the damping.
The green trace is just a bias signal between ground and the + input of the op amp.
Note that I don't have an op-amp device in the circuit, as none of the models remotely reflects any of the devices I'm evaluating! I might actually build an equivalent differential input circuit from discretes and try that. But later...

Yes, I realise I have much to do. I know I need to reference one end of the differential (diode-clipped) inputs. As I keep saying, I'm a self-taught electronicist with bugger-all maths skills, so every circuit I build, I learn something new. That's why I build them! Having said that... any obvious things I'm overlooking? Comments are most welcome, I need to learn so much. And - thanks for looking. I feel totally embarrassed about submitting even this to you guys! So please be gentle with me.

[mickstv]

You could post the frontend circuit so others here can have an experiment with your design ?

[Pete the Builder]

You could post the frontend circuit so others here can have an experiment with your design ?

Yes, you're absolutely right - I could post the circuit here, but I have a few issues with doing that.
1) It's not tested nearly well enough to even prove that it works outside the simulation! I've perfboarded the circuit, but it will be at least a week before I get my MCU replaced so I can continue the testing.
2) People will most likely just laugh at me. This is a very rough prototype, and I'm an absolute amateur when it comes to PI front end design. Not that that worries me, any mistakes or assumptions can be learned from, and that's why I'm here! But mainly...
3) Just in case it turns out to be a real, practical, useable front end, I don't want certain companies to obtain the design. It's quite obvious that this has already happened, here and on other sites. So, until I'm sure I can be sure the design will go into the public domain with no possibility of companies or individuals illegally and unethically copying the idea and making it difficult for others to adapt or use, I must keep things a little bit quiet.

I wanted to post the photos I've done of the perfboard model, to at least show that something is really happening, but a good friend who's an electronics dabbler, as well as being a lawyer/shark (but not a patent specialist) pointed out that the, um, unusual components would give away the whole idea.

I'm truly not hiding anything deliberately, I promise you. I just do not want this design, IF it works, to be stolen instead of being available for everyone to try. Even if the darn thing doesn't work, I'll post full details, just so people might get a spark of an idea themselves! But right now, it's in "limbo".

Have the bad guys won? Yes and no. It's going to take longer for me to make the design public, but it WILL become public. And I'll do everything I can to make sure it stays that way.

Of course, this all might just be a load of crap, and the thing might be a huge joke because I don't understand the theory very well. But then, I'll learn something, and that's always a great result.

Sorry for the long reply. I wanted to make sure you understood I'm not trying to be clever or pretend I've got things that I haven't got.
-PtB

[Pete the Builder]

Power supply ideas

I've been thinking about power supply design for the Frankenproject. That's kind of my specialty, so I want something that works well and meets all the requirements.

Linear regulators are out, obviously. I need high voltage and current, as well as differential low-voltage supplies for op-amps and a lower core voltage for the MCU. Linear regs just waste too much power as heat. Great if you've got cold hands, but not so good for power drain!

So, while I haven't decided the TX coil voltage yet, it's going to be in the 20s-80s of volts, so a boost converter is essential.

Likewise, I need ultra-stable and very quiet +/-5V, +12V, and probably also -12V. And I definitely need either 3.3V or 1.8V, depending on the MCU used.

Rather than jump in with separate switching buck regulators for the logic/analogue supplies, plus a separate boost for the HV and 12V supplies, I've decided to use a camera PSU chip.

That gives me the option to have up to 5 separate supplies, with varying voltages from 90V to 1.8V. It will be a very high switching frequency (2.2MHz or so), which means small inductors and caps, and no need for low-pass filters everywhere.

Plus, although they're not available in Australia (don't get me started!), they can be obtained by hobbyists and individuals reasonably cheaply, from Mouser and Digikey and probably Element14.

Right now, I'm looking at the Maxim MAX1585. So once I get vertical again, I'll put together a small circuit and verify it all works as expected. And that's a circuit I CAN post online!

So that's where this is at right now. If anyone has ideas they'd like to see, or if anything seems unclear, please ask away!
-PtB

[Carl-NC]

If you are doing PI then a TX boost reg can be difficult at high voltages. A typical TX with 2A@10V@10% requires 200mA from the boost reg. This level isn't difficult, but as you move up into the 20V or 5A level it is. Most boost reg datasheets describe how to calculate max output current given the inductor, duty cycle, input & output voltages. The more you try to boost (3V -> 20V) the worse it gets.

I suggest starting with modest goals. Use a 12V battery pack so you don't even need a boost reg, then use a buck reg for the circuitry. That gets into another problem... despite high-f switching the switching noise can still be an issue. Some regs are horrible, some not so bad. Use an IB coil or a cap-coupled front-end so you don't need an inverted supply, use a simple rail splitter instead.

I'm currently working on a PI that runs on a 6V battery pack, and just finished helping on a VLF design that runs on 2-AA batteries. Getting reasonable power supply designs was a fair challenge. Save that challenge for another day, and focus on making the PI part.

- Carl

[Pete the Builder]

If you are doing PI then a TX boost reg can be difficult at high voltages. A typical TX with 2A@10V@10% requires 200mA from the boost reg. This level isn't difficult, but as you move up into the 20V or 5A level it is. Most boost reg datasheets describe how to calculate max output current given the inductor, duty cycle, input & output voltages. The more you try to boost (3V -> 20V) the worse it gets.

I suggest starting with modest goals. Use a 12V battery pack so you don't even need a boost reg, then use a buck reg for the circuitry. That gets into another problem... despite high-f switching the switching noise can still be an issue. Some regs are horrible, some not so bad. Use an IB coil or a cap-coupled front-end so you don't need an inverted supply, use a simple rail splitter instead.

I'm currently working on a PI that runs on a 6V battery pack, and just finished helping on a VLF design that runs on 2-AA batteries. Getting reasonable power supply designs was a fair challenge. Save that challenge for another day, and focus on making the PI part.

- Carl

Thanks for the tips, Carl, it's much appreciated.

I'm a HV kinda guy, so I'm reasonably happy working with boost converters, I've come up against nearly all their limitations! My biggest HV project was a coil gun, I'm still working on that, but it dumps around 7J into three coils in about 4uS via "hockey puck" SCRs. It's frustrating trying to maximise dV/dT in a portable device like that. But hey, it's fun!

I will be designing the detector around a 35W SLA 12V gel cell. I have about a dozen of these, after downgrading my studio UPS. I know and love the SLA technology, from discharge curve to recharger circuits, I really cut my teeth on 'em! I prefer them in many ways to LiPo technology - SLA doesn't have near the power density, but then it doesn't have the price or awful charging constraints either! Although the price has been steadily dropping for a year or more now (I'm using a pack of 35Cs in a quadcopter I'm designing and programming).

I understand what you mean about HF noise. I found out the hard way that although it does get "naturally" filtered through good layout and bypass techniques, it still radiates like crazy, especially under duress. Ground planes help, but again my maths lets me down a bit and it ends up being a "suck it and see" when it comes to actually testing out such a design.

Again, thanks for the suggestions, I really do appreciate the interest. I'm really hoping not to disappoint too much in the wash...

Cheers mate!
Pete

[Pete the Builder]

Ha!

For anyone reading, I think you'll appreciate this...

I was about to post a CRO dump of my über-fast TX coil FET design, to see if anyone had some feedback that would help improve the design... So I doubl-checked the specs for the FET (60nS), and compared my über-fast design real time data... Which was 120nS!

Perhaps I should patent this as a "Spec Stretcher" circuit instead?

As soon as I'm up again, I'll post the little schematic and screendump anyway, so we can all have a jolly old laugh...

*shakes head and sighs*

Cheers,
Pete the Pulse Stretcher