Proton Boron Consortium

There is a new kid on the block when it comes to Polywell Fusion. The Proton Boron Consortium. It is working on an open source Polywell type design. You can also find the group on Facebook Proton Boron Consortium - Facebook. I am personally associated with the effort. They haven't started serious fund raising yet but if you would like to donate to the electronics part of the work you can use this PayPal button.

Please note if it is for the PB (Proton Boron) Project. Or the KW (kilowatt hour) offer.

Screaming Very Low Power Microprocessor

I have a new article up at ECN Magazine about a microprocessor that can do 90 billion instructions per second for a power cost of about 1 watt. Pretty good huh? It gets better. The chip has 144 processors in the package and when they are all idle the chip uses only 14 microwatts.

GreenArrays (the company that makes the chip) has partnered with another company to make the processor available to hobbyists.

CAN Bus And System Control

I like CAN (Controller Area Network) Bus for control systems. It has moderate speed (1 Mbs), it is deterministic., it has priority control for multi-master operation, and because of its use in autos it is robust and low cost. In addition it has been on the market for about 10 years so it is well established with lots of vendors to choose from. In addition there are a number of MCUs with built in CAN.

For test reactor operation I see a hierarchy of CAN buses, each devoted to a given function and then all melded into a master bus. Let me start with the sub nets.

1. Vacuum Gauge/Vacuum Pump Control Bus
2. HV Power Supply Internal Buses
3. Instrumentation Buses (Temp Monitoring, Flow Monitoring, Master Clock, Neutron Counter, Electrical Power Measurement and Control, etc.)
4. Auxiliary Control (Electrical Power Measurement and Control, etc.)

And then a master bus to send messages to/from the sub buses.

I haven't decided on an MCU yet. One of the requirements would be that it is FLASH programmable and have a built in CAN bus. I have been thinking about pressure measurement lately so I'd like to lay out what a CAN bus interface would look like.

The pressure transducers I have in mind (MKS 722 and MKS 626A) have a 0 to 10 V output. I haven't picked any other components yet. So we will just look at functions.

1. Pressure (dependent on transducer - from 1000 torr to .1 torr full scale, 17 bits)
2. Board temperature (0 to 100 deg C, nominal 30 deg C 10 bits nominal - 8 actual)
3. Board power bus voltage (20 to 60V, nominal 48VDC, 10 bits nominal - 8 actual)
4. Board power bus current (0 to 255 mA, nominal TBD, 10 bits nominal - 8 actual)
5. Various internal power supplies (TBD, TBD, 10 bits nominal - 8 actual)
6. Isolated CAN supply, Isolated Pressure transducer supply, Isolated MCU supplies.

Lets start with the transducer front end. It should have an op-amp (fully differential).

For the 24 bit converter I like the AD7767 it has an accuracy of 17 bits which matches the one part in 1e5 resolution of the pressure transducer.

The ADA4941-1 is a nice companion amplifier. And the ADR425 looks like a nice reference. Good specs, not too expensive.

That covers the main parts of the analog side. What about the computing side? I have been looking around and I think I like the Fujitsu CAN bus microprocessors the best. Its architecture is a mixture of a FORTH engine and a Z8 register bank.


Fujitsu 16 bit microcontrollers

Fujitsu 32 bit microcontrollers

Fujitsu microcontrollers

I haven't addressed the CAN interface yet. It is pretty simple: a few high speed optocouplers, a bus driver chip, a separate isolated power supply, some protection components and away we go.

Let me add that Fujitsu has 8 bitters that I have yet to take a serious look at. I'll probably remedy that in the next few days.

The Atmel CAN processors would be a good second choice. The reason I like the Fujitsu stuff better is that it has a very good migration path and I'd like to use one software model for as many of the process tasks as possible.


I also like the Infineon TC1166 32 bit processor with CAN. Digikey sells them for about $39 ea. Quantity one. Since programming and hardware design is going to be the big cost for the initial units I'm going to do what Chuck Moore suggests. Get the biggest fastest processor you can afford to start. Then reduce the foot print if volumes warrant.

The Fujitsu part is more open ended and has a very simple CALL structure. However, there are no automatic register saves with calls. Thus every CALL must have at least one PUSH and one POP if you expect nested calls. The Infineon has a more definite programming model with user space registers and system space registers. They each save registers on a CALL (but different sets). The cost is 2 to 5 clocks. Not a big hit (but they could have done better). The Infineon part also seems like it might be harder to learn due to instruction pipeline flushing requirements in some situations that require an instruction to finish before the following instruction(s) are executed. I do like the floating point and some other features of the Infineon, but I will set it aside for now. Well I read on and find that the Fujitsu Part also has a 5 deep pipeline. I guess when you need to flush it you just do a bunch of no-ops.

The Fujitsu also is more deterministic and can do tail end recursion since the pipeline is only one level deep (actually it is five deep also but it can do tail end recursion.). However the divide routines are not as mechanized as they are in the Infineon. Since I hardly ever use them except with user input to precalculate multiply constants that is not such a big hit.

Update 09 Jun 1534z

I have been looking at the Freescale MPC551x MPUs. I like them. Plus Freescale gives away an assembler good enough to get a FORTH up on the chip.

I like the Atmel ATA6660 CAN bus physical interface. There are later and greater chips out with more functionality , however I like to keep the interface simple and electrically isolated. You can do that with three high speed optocouplers and an isolation supply. A 48 V to 5 V job at about 1 W would be good.

FORTH Is Back

The FORTH programming system is one of my favorites. The language is simple, compact, and extremely powerful, and almost dead. It has been kept alive over the years by a few fanatics including myself. Well, it looks like it is coming back in a big way. A lot of big names are now into the game.

By INQUIRER staff: Friday, 07 December 2007, 2:40 PM

PATRIOT SCIENTIFIC, which jointly owns a microprocessor related patent porfolio, said that Taiwanese firm Lite-On has bought a licence, becoming the third firm in a week to do so.

According to the firm, it's the first Taiwanese system company to buy a licence. Daewoo and a US manufacturer said they'd buy a licence earlier this week.

The firm's "Moore Microprocessor Patent Portfolio" that holds IP including seven US patents covering microprocessors, system on chip stuff, and microcontrollers.

This lot have also signed up for licences already. AMD, Intel, Hewlett Packard, Casio, Fujitsu, Sony, Nikon, Seiko Epson, Pentax, Olympus, Kenwood, Agilent, Lexmark, Schneider Electric, NEC Corporation, Funai Electric, Sandisk, Sharp Corporation, Nokia, Bull, Lego, DMP Electronics, Denso Wave, Philips, TEAC, Daewoo Electronics. And now Lite-On.

Now that looks like a rush. Why? Well, a dual stack architecture is pretty well fitted to C. Although C is no near as efficient as FORTH with such an architecture. EE Times Asia has more on the story.

06 Mar 2006

Alliacense announced that Fujitsu Ltd has licensed its intellectual property protected by the Moore Microprocessor Patent (MMP) portfolio. Alliacense is the subsidiary created last year to administer the portfolio on behalf of owners Patriot Scientific Corp. and TPL Group Financial terms of the licensing arrangement were not disclosed.

Fujitsu becomes the third system manufacturer to publicly disclose licensing of the MMP portfolio, following Hewlett-Packard (HP) in January and Casio Computer Co. Ltd last week. In announcing the Casio deal last week, Patriot Scientific revealed that semiconductor makers like Intel Corp. and Advanced Micro Devices (AMD) are not being required to pay royalties on MMP licenses.

Note the earlier date. About a year and a half before the Dec 007 announcement. Also note that I have a friend who works for the TPL Group. I'll have to ask him what happened.

In any case a little more background from the March 006 article:

Patriot and TPL came together in June 2005 to settle a long-standing patent dispute so they could jointly pursue licensing revenue from third parties. The TPL Group has been granted full responsibility and authority for the commercialization and licensing of a unified portfolio of 10 patents.

The MMP portfolio is named after inventor Charles H. Moore, chief technology officer of TPL Group, who is known for inventing the Forth software programming language and for his work in the 1980s on stack-based microprocessors.

It looks like FORTH as a chip architecture is back big time. I wonder if the language will come back as well.

In any case I really like the Fujitsu 16 bit and the Fujitsu 32 bit versions of the architecture.

The Infineon TC1166 32 bit processor looks nice. Digikey sells them for about $39 ea. Quantity one. Since programming and hardware design is going to be the big cost for the initial units I'm going to do what Chuck Moore suggests. Get the biggest fastest processor you can afford to start. Then reduce the foot print if volumes warrant.

ITER Control

Emerging Technologies takes a look at ITER control and safety systems. They plan to sample at 5 MHZ for data acquisition.

Here is a nice pdf to get you started.

Detectors

I have been giving some thoughts to ionization gauges lately in terms of pressure control. What if we used one without a filament to detect ions? Put it in line with a beam path but out of the way of the beam so it doesn't become an added loss mechanism and see if you get a good signal. Bursts of high energy Heliums.

There will be problems. High energy Helium ions are going to be a heating problem. Secondary ionizations will be a problem. If the bias voltage needs to be in the MV range that will be a problem.

Still, I think something useful could be worked out. Low power test reactors can probably get by with some high temperature wire. For higher powers we may need to think of something else. By then of course we ought to know a lot more and the solution will be obvious.

Ionization Pressure Guages

In my effort to map out a control strategy for reactor pressure control I have been studying ionization gauges. Depending on cathode emission and plate voltage they are very linear. Given their construction and plate voltage (in the 200 to 350 volt range) their response speed should be at least in the low MHz range.

The limiting factor is going to be the current amplifier (because current is proportional to gas density). At low currents - current amplifiers tend to have low bandwidths. Should that be a problem in controlling the reactor the gauge operating conditions could be optimized for the desired control range. A second gauge operated normally could be used to turn off the gauge if pressures got too far out of range. That should give us a readout bandwidth in the 100s of KHz.

With a valve bandwidth of 1,000 Hz and a reactor fill time of 1 second with a full open control valve, pressure control to within 1% ought to be easy. A little work could bring that in to .5%. Dr. B. said that his suggested pressure was 1E-7 torr because his control system was lousy. He said the real number was about 30X higher. If that is the case an increase of density with better control should allow at least a 10X increase in pressure. For D-D that means a reactivity increase of n²/2 - about 50X. If we could keep things tight enough to get the whole 30X increase in pressure it would give a gain improvement of 450. Tight pressure control is one of the critical keys to making this work.

You can get a nice first pass of ionization gauge theory and practice from this page. Click on Introduction to Bayard-Alpert Gauges. It will bring up a [pdf] "open or save" block.

Which has got me to thinking. If POPS causes density waves in the plasma and those density waves get coupled to the neutrals it may be possible to use an ionization gauge to measure POPS frequencies. You would use a diplexer. The low frequency signals would go to the pressure controller and the high frequency signals would feed the POPS frequency controller phase detector (after suitable division if required).

BTW if you are going to use CMOS I used to highly recommend the Philips 74HC4046 however Philips is no longer in the Semiconductor business. Instead that business is now called NXP. So here is NXP version of the 74HC/HCT4046A[pdf]

Thinking About Control

I keep thinking about test reactor control issues - things that need controlling, signals to use for control. I want to leave off things like cooling and other secondary functions which are quite important but are easily controlled and instrumented and happen on relatively long time scales.

Reactor controls are going to be a bitch. Let me run down the list of what needs controlling, some of the interactions and what signals we can use for feedback. This will be in relation to a test reactor about 1 meter across in total dimensions designed for continuous operation burning D-D.

1. Anode (called a grid in the Bussard Reactor) HV
2. POPS frequency, POPS voltage (added to Anode DC)
3. Gas Pressure
4. Electron Injection

Controlling the pumping speed of the turbo pumps is an option but that is rather slow and need only be done to set the base gas flow from the gas pressure controller. We could also vary the magnet current, but again that is slow and is relatively easy to do a set and forget based on the well voltage and the system geometry. So that sets out what we have for plant controls.

What kind of feedback signals can we get?

1. Neutrons - they tell us the fusion rate.
2. Light (PMT amplified) - electron density.
3. X-Ray output with energy binning - who knows what we might learn
4. High Energy Alpha Output - fusion rate
5. Pressure gauges - gas flow
6. High Frequency Current Transformer in the Anode Circuit Ground - you can learn a lot by watching

Burning D-D simplifies things. So far as we know there are no peaky resonance regions in the curve so we don't need to figure out how to keep the reactor anode voltage at some process determined level. So that is one complication out of the way. Second off we can use a high vacuum pressure gauge with out worrying about readings being gas composition dependent.

So we have pressure control. From a quick look at what is out there in terms of pressure measuring equipment it looks like ten measurements a second is a reasonable rate. That means that we probably will have a first order roll off on the loop of about 1 second. That is not too bad as the way the system works helps us. If it takes a certain time T to reach a given pressure it takes 10T to get to 10 times the pressure. Given that fact and the fact that the flow is initially designed to fill the reactor in 1 second control within a 2 to 1 range ( from .6 times the set point to 1.5 times the set point) should be easy. Tighter control of course would be better. We should try to get faster updates from the pressure measuring eqpt. Or we could opt for lower flow from the gas delivery system. Since most of the flow rate will be determined by the capacity of the turbo molecular pumps we could also go for a flow system calibrated to deliver 80% of the required flow and then just have a variable valve to make up the difference.

So gas density should be another set and forget.

That really leaves us only one thing that needs to be controlled on the fly. POPS frequency. Since we plan on impressing it on the Anode the anode current would not be a good place to read it out. If we used an antenna inside the reactor it would have the same problem. What we need is a signal read out that is independent of moving charges. The most likely signal for that is either the X-ray detector or the neutron detector. Since POPS for a drive voltage of 50 KV is expected to be in the 2 to 30 MHz range we will need a neutron measurement or X-Ray measurement system that can give us output at those frequencies. Also the detector efficiency should be such that it can detect at least .3E9 photons or neutrons a second if we are to reliably detect 30MHz. That will be tough. POPS experiments may need to be done with a sweep generator without feedback on small reactors.

Ideally if enough alphas are generated it should be possible to turn off the electron guns and just use the electrons left behind by the fusion alphas as the electron source. Of course if the electron guns must be left on they could be modulated at the POPS frequency and read out could come from the Anode ground current, considerably simplifying matters. The light output (PMT Amplified) could be used as a signal to throttle back the electron guns.

However, we really do not want continuously operating electron guns in a power reactor except for startup. They get in the way mechanically unless they can be placed on the walls of the reactor.

Processing Power

As you know I like FORTH a lot for control applications. I was estimating that with standard off the shelf hardware we might get a PID loop interval in the 4 KHz range.

However, there is a new kid on the block. The SEAforth 24B.

This kid is a screamer. It has 24 cores that each run at 1 G instructions per second (Ips). Peak of course is 24 G Ips.

For a PID loop that means loop cycle times in the 10 MHz to 50 MHz range. But that is not all:

* Static/dynamic memory interface
* Eleven SPI I/O ports
* Two 18-bit A/D converters
* Two 9-bit D/A converters
* 32 Parallel I/O lines

C18 Processor Features

* 18-bit stack oriented engine
* Runs VentureForth™ programming language as native code
* Executes 1 VentureForth instruction / ns
* 512 words RAM / 512 words ROM
* Hardware 18x18 multiply/accumulate
* Automatic sleep mode at <1mW dissipation

The multiplier will be very handy for PID loops. If you design your PID loops correctly they will consist of adds, subtracts, and a few multiplies.

Update 02 Sept 007 1023z

The A/D is a VCO and a counter. Which means conversion times on the order of 15 to 20 uSec. The D to A is a VCO type device as well.

What that means is that for actual high speed operation the SPI ports will probably be required.

In any case for low speed signals these ports should be fine.

Also the multiplier is actually a 9 bit by 9 bit bitwise hardware multiply. Nine or more clock cycles to complete a multiply. Some stack manipulation will be required to to do an 18 bit by 18 bit multiply. It will probably be somewhat slow. Probably 50 to 100 clock cycles. Meaning about 1E7 multiplies per second for each core. Which means that if you have one core for P one for I and one for D you could probably do a PID loop at a bit better than 5 million loops a second. If you cut down the number of bits to 12 or 14 you could tune the multiplies to make them faster.

Update 03 Aug 007 0743z

It appears the 24B is not currently being offered. The A version has the following specs:

* Twenty-four C18 core processors capable of combined sustained 24 Billion operations / second
* Completely asynchronous for faster processing and lower power
* Static/dynamic memory interface
* One SPI I/O port plus a broad set of serial and parallel ports
* Two 18-bit A/D converters
* Two 9-bit D/A converters

C18 Processor Features

* 18-bit stack oriented engine
* Runs VentureForth™ programming language as native code
* Executes 1 VentureForth instruction / ns
* 64 words RAM / 64 words ROM
* Automatic sleep mode at <1mW dissipation

A more detailed look at the chip can be found at SEAforth 24A.

Update: The SEAforth 24a pdf is no longer available by direct link. The above link now takes you to the page where you can order a copy.

Reactor Building and Reactor Controls

I have been thinking about a reactor building. Hexagon or octagon? I lean towards octagon. Open top cell. I'll have to look at gamma ray "sky" factor scattering to see if that is a problem. An open top would make it easier to string unanticipated wires or pipes.

I'm thinking partial shield at this time. I think that would be OK since I'm contemplating a switch gear yard to one side of the building. That would allow a truck entrance from the switch gear side. I'd rather not have to crane in the heavy stuff. Forklifts and rollers. Also we are going to have to put an LN2 tank in there some where.

For viewing during operation I'm thinking one periscope - very simple design and only for confidence. Plus multiple video cameras. Cameras will each have their own video cable and control wiring.

I have been giving the bus question some thought. I think Ethernet for data collection and CAN for control. A PC104 system for control spots. Wireless will not be used for any functions. An isolated (to 100KV) 24 VDC supply and back up battery will be used for incidental power and control an the high voltage side. Isolation from the low voltage side will be handled by transformers for power and fiber optics for data.

Safety controls (master breaker trip etc.) will be hard wired as well as computer controlled.