Sciencemadness Discussion Board
Not logged in [Login ]
Go To Bottom

Printable Version  
 Pages:  1  2
Author: Subject: Electrolysis power supply
12AX7
Post Harlot
*****




Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline

Mood: informative

[*] posted on 28-4-2010 at 15:43


Thank you for an excellent explanation.

Another issue more practical: since a poor power factor causes excessive current draw (relative to the amount of real power delivered), you can be drawing about 1000W from an ordinary 120V, 20A circuit, yet blow the breaker! Power factor correction allows you to use the full rated power that circuit can deliver.

Tim




Seven Transistor Labs LLC http://seventransistorlabs.com/
Electronic Design, from Concept to Layout.
Need engineering assistance? Drop me a message!
View user's profile Visit user's homepage View All Posts By User This user has MSN Messenger
quicksilver
International Hazard
*****




Posts: 1820
Registered: 7-9-2005
Location: Inches from the keyboard....
Member Is Offline

Mood: ~-=SWINGS=-~

[*] posted on 15-5-2010 at 09:31


That was an excellent & concise explanation.
Just my opinion but it also bears fruit when looking at certain PSU designed for non-linear operation. However there may be a difficult variable in a formula for the level of the given capacitence & more. Within the solution of an Electrolysis environment there may be "fast or sudden" variables as well as slower variables. {I only say this due to designs using IC's instead of a overly large capacitor. Instead of a "big gulp" they are making corrections hundreds of times a sec.} If the capacitor alone could manage such a thing, there would be designs using the super capacitors common today in Farad level capasitence.

I saw this recently in a HV supply for a plasma unit. The design included a CPU & I realized that the factors affecting the gases would change both very intermittently and over the course of a day (outside temp, etc).
That's not to say that a simple design with a HUGE cap, great method of cooling, etc - would not work funtion but I would think that the "smart" PSU would be easier on the electrodes & produce a larger or faster yield.
View user's profile View All Posts By User
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 16-5-2010 at 00:53


What about using some old PC: The soundcard has it's 40k-samples/second, a good one may have 100k or more ...
==> Some realtime-linux and a c-program might do the trick, evaluating the ingoing data and reacting within 50 microseconds or less ...
==> sending the controlling signals to either soubdcard No. 2 or the same port etc. ...

The outer circuit would have to be some power-parts and some for conversion of the signals frpm/to soundcard-level ...

Anyhow the 50/60 Hz mains-freq. are laughably slow to even an old pentium1/100 MHz, so no expensive things needed at all ...
==> + it would be programmable ... :D
View user's profile View All Posts By User
quicksilver
International Hazard
*****




Posts: 1820
Registered: 7-9-2005
Location: Inches from the keyboard....
Member Is Offline

Mood: ~-=SWINGS=-~

[*] posted on 16-5-2010 at 04:01


-Wish I had 1/2 the time needed to experiment. I just don't (that one of the reasons I bought PSU's instead of working on one. I did try the computer PSU-design & it was great. Had a Fluke meter on it and watched it switch till I ran the battery out. -Was quite impressive.



View user's profile View All Posts By User
12AX7
Post Harlot
*****




Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline

Mood: informative

[*] posted on 16-5-2010 at 07:39


Sound cards are not DC coupled, so that will not work. They also have poor impulse response, being optimized for flat bandwidth rather than flat waveform.

Also, PCs are, in general, not well suited to real time applications (although in this particular case, the PSU section is well enough behaved to be left alone to itself without attention from the computer). A more suitable interface can be provided by a microcontroller, through serial or USB, for data logging, more complex setups, etc. as needed.

Tim




Seven Transistor Labs LLC http://seventransistorlabs.com/
Electronic Design, from Concept to Layout.
Need engineering assistance? Drop me a message!
View user's profile Visit user's homepage View All Posts By User This user has MSN Messenger
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 16-5-2010 at 08:53


What about a real-time linux kernel ? It should straight do busines, within the 50 or 100 microseconds ...
==> Also we deal with changing signals ... : If the voltage drops from 10 to 9.97 V within a millisecond the soundcard will detect it, has 8,16 or more bit of resolution etc. ...
==> The bandwith @ 80 kbit/s is not too small either ...
==> Voltage-levels would have to be transformed into the range of the card, of course, by some simple circuitry, eg. some op-amp ...

Op-amps can be used even to take the logarithm of a voltage, by inserting a diode (backwards) into the line from output to one of the inputs (+ or -, forgot which ...) ... : Thereby even voltages from 0 to 500 V (eg.) could be managed by the soundcard-setup ...

Anyhow the soundcard could have the task of switching the power-supply-circuitry on/off, as well as partially on/off, by the 16bit-resolution ... ... ...

View user's profile View All Posts By User
12AX7
Post Harlot
*****




Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline

Mood: informative

[*] posted on 16-5-2010 at 16:05


If you're going to hack an RTOS, you might as well write your own code. On a microcontroller.

Right now, my code totals 12kB. Beat that with Linux.

Tim




Seven Transistor Labs LLC http://seventransistorlabs.com/
Electronic Design, from Concept to Layout.
Need engineering assistance? Drop me a message!
View user's profile Visit user's homepage View All Posts By User This user has MSN Messenger
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 17-5-2010 at 00:43


Maybe your'e right about that; only I like the universality of the PC:
==> Can be controlled more easily ..., has net for co-functioning with other parts

Also _much_ easier programming ...

A PC ultimately can be blown up to a machine, just by connecting more peripheral things to it ...
==> regulating 5 temperatures, several stirrers as well as some voltages ... and some magnetic valves ... and pumps ...
==> meanwhile logging the data as well ...

Though for the temperatures good PID-units exist for 2-digit €-prices ..., with several I/O-ports ...

View user's profile View All Posts By User
densest
Hazard to Others
***




Posts: 359
Registered: 1-10-2005
Location: in the lehr
Member Is Offline

Mood: slowly warming to strain point

[*] posted on 17-5-2010 at 10:28


Elaborating what 12AX7/Tim says from experience & observation:

Using a PC as a controller inside a feedback loop is a bad idea unless your application can tolerate multi-second delays there. Anything but a real RTOS can go deaf, dumb, and blind for several seconds if there's an unusual condition which causes a long loop in the kernel with interrupts disabled.

Even in normal operation Winloss does it too often for comfort. I'd never use Winloss for anything other than a space heater. If you relentlessly strip almost everything in user space and a lot of modules in the kernel out of Linux it can be made usable but they keep using threads which is inherently a disaster. BSD variants like FreeBSD, OpenBSD, and NetBSD have real time hooks which will get you to 20ms or below depending on some details. Old V7 Unix actually could be relied on for < 10ms actions on a 2MIPS (32Mhz = 0.032GHz) machine if you know how to avoid swapping, etc.

A reasonable microcontroller with all sorts of A/D/A and digital I/O mounted on a board can be had for $20 or less. Isolation or controlling power loads can be added for a few $/channel. Careful programming (don't use threads, they don't work, it's been proven, there are papers) avoiding any chance of looping in an interrupt handler will produce something with < 200us response. A fully dedicated one with nothing else to do can go down to 10us or below if the control algorithm is simple. There's at least one paper describing projects using such a micro in the switching feedback loop of a power supply - the result was a bit sloppy but usable.

Using a PC soundcard as a voltmeter/ADC: It can be done but there are a lot of gotchas. They have the following problems:
They don't go down to DC. You would need to chop the input signal into AC, run it into the soundcard, and then postprocess the signal with a digital filter with low enough bandpass to get rid of all the artifacts and noise introduced by chopping. This needs to be done carefully with regard to the card's sampling frequency (see below).
They are Sigma-Delta types which often have a zero point oscillation which produces noise only when there's no input :o so you have to know when and how to filter it out.
They have a high noise floor - maybe -60 to -80 dB (.1% to .01% of full scale). This is random noise as well as RFI/EMI from the computer.
They sample at a relatively low rate. The highest is 192 KHz (rare) 96KHz (not common) 48KHz (universal) and 44.1KHz (common). This means 20KHz to 88KHz upper limit. The impulse response at the high end by definition causes ringing on fast transitions which you have to be aware of.
They are fairly linear but not calibrated. "Full Scale" can be anything from .5V to 5V so you have to have a reference signal to check against. Stereo ones usually are pretty well correlated from side to side.
View user's profile View All Posts By User
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 17-5-2010 at 11:22


I heare a lot of real-time linuxes ... for industrial applications ...
==> That's what I talked about ; of course no desktop-environment and none of the common packages ...

If the kernel does as much a make possible to run a compiler and read the ports, then a 100 MHz bus will be quite powerful ...

Also: What about using the parallel port ? Eg. connecting some A/D-thing to it for sampling ?
==> The tiny little optimized c-program could wait for each byte from this port, do it's processing at least as good as the microcontroller, and send signals to either the parallel-port again or to another card ... (maybe parallel-port too ...) ...

===================

Also what I thought about a couple of times: Abuse the video-card ... : 3 channels, each in the 100 MHz-range ...
==> could eg. generate some 5-MHz-3-Phases signal for some fun with rotating plasma ...

This wouldn't even be too complicated: Just generating a graphics where some sine-shapes are distributed over the 1024 lines, with 120 deg phase-shifts for RGB ...

[Edited on 17-5-2010 by chief]
View user's profile View All Posts By User
12AX7
Post Harlot
*****




Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline

Mood: informative

[*] posted on 17-5-2010 at 18:05


The video card is capable of extremely complex waveforms (indeed, it's a high resolution, three channel arbitrary-waveform generator with typically 8 bit accuracy), however, your waveforms completely disappear during retrace, both horizontal and vertical. That's not too handy. If you can tolerate that, then it's great for signals that repeat at the sweep rate, but if you want something different, your processing requirement instantly goes up from nil to megabytes per frame.

Now, the old VGA hardware simply has registers, which happen to be given useful values to produce e.g. 640 x 480, and could be assigned arbitrary values to produce oddball scans (most of which aren't supported by monitors), which might be useful for producing different rates. Maybe the same registers still apply today, but if you really want to [ab]use modern hardware, you're SOL as far as what the registers are and how to program them.

In the old days, the parallel port was quite handy. RTOS can run it just fine. Apparently it's possible to use it from Windows as well, but I wouldn't expect that to be very reliable. Synchronous communications (i.e., assign byte, strobe the write pin) are better than more arbitrary bitbanging.

For interfacing microcontrollers, the serial and USB ports are quite sufficient. USB chips are available today to handle the hard stuff, or USB 1.0/1.1 can be bitbanged from a uC as well.

As the number of bitbang routines increases, the demands on any given uC rise substantially. Multiple chips might be used, each one controlling its own system. A more powerful core, like ARM, might also be used. FPGAs also look good, as they provide true parallel processing -- multiple uC cores can be implemented internally.

Tim




Seven Transistor Labs LLC http://seventransistorlabs.com/
Electronic Design, from Concept to Layout.
Need engineering assistance? Drop me a message!
View user's profile Visit user's homepage View All Posts By User This user has MSN Messenger
quicksilver
International Hazard
*****




Posts: 1820
Registered: 7-9-2005
Location: Inches from the keyboard....
Member Is Offline

Mood: ~-=SWINGS=-~

[*] posted on 18-5-2010 at 11:12


IN the early 1990's the standard method of using a outboard backup or data transfer was via the parallel port. There were marvelous DOS access times (products written in assembler & were small & sleek). These were written for DAT tape drive backup, forensic analysis, & a great little data transfer program called "Lap Link". It was an all Assembler program that fit on a diskette & your transfer speed basically depended on the speed of the drive. It really flew for that time.
I STILL have all that stuff. I have a 486 DOS computer with all the low-level programming stuff I studied back then. Legacy stuff doesn't have any market today, but I still have my library, my books, & software that makes all the Microsoft Visual Library look very sluggish & bloated. There were 16bit hex editors that would still be valuable today in certain instances (& they were stunningly fast). It was those products that let you really close to the machine.
Microsoft BOUGHT a product called Visual Pascal from Borland (who bought it from the Univ. of San Diego) & buried it. That was a real shame, for at the time, it was a developer's language that produced graphics products under DOS or UNIX w/ out windoze of x-windows

[Edited on 18-5-2010 by quicksilver]




View user's profile View All Posts By User
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 19-5-2010 at 02:29


There is a program calles "ledblink" for linux, which can control each keyboard led and the parallel-port ...
==> In it's basic configurtion you can switch on/off each of the parallel-port-pins independently ...; I used this eg. for a simple Temp-control, where the temp came in through a voltmeter from the serial port and one of the parallell-pins was connected to a relay, switching on/off the heating: Could regulate the temp of a furnace or even regulate a lightbulb to 100 Cels ... ...

This "ledblink"-program could serve as an example for accessing the port under linux: Link below; only thing you _need_ to do for having it work: Insert into the code the right adress for the parallel-port on your machine ... : I had it run on several different PCs and it worked well ...

================

Besides I remember: Once I compiled a kernel under Debian with 1000 Hz-interrupt-resolution for midi, so it had quick-enough reaction-time ...
==> Those 1 kHz may as well be set to something else, probably ...
==> These days linux is the way to go ... : Well enough documented etc. ...


Now the program:



[Edited on 19-5-2010 by chief]

Attachment: ledblink-aldi.tgz (28kB)
This file has been downloaded 881 times

[Edited on 19-5-2010 by chief]
View user's profile View All Posts By User
quicksilver
International Hazard
*****




Posts: 1820
Registered: 7-9-2005
Location: Inches from the keyboard....
Member Is Offline

Mood: ~-=SWINGS=-~

[*] posted on 19-5-2010 at 06:01


That's my buddy. Have you ever noticed how the good ones are timeless? Norton Commander, Xtree, Lap-link are all "public domain code" (read bought out and undeveloped) and someone gets to port them over to 32 bit or compile them under a certain x-ux?
Since everyone is using wireless it's only a matter of time till we see Novell code being ported to a free Linux package, I'd bet. I can't understand why a serious security conscious company would care SO MUCH about wiring that they'd loose their hard wired networks. But then I'm no millionaire either.




View user's profile View All Posts By User
watson.fawkes
International Hazard
*****




Posts: 2793
Registered: 16-8-2008
Member Is Offline

Mood: No Mood

[*] posted on 19-5-2010 at 06:03


Quote: Originally posted by 12AX7  
If you're going to hack an RTOS, you might as well write your own code. On a microcontroller.
I concur. If you're learning microcontrollers for the first time, I heartily recommend using Arduino. It's a little board with an Atmel AVR chip and in-circuit programming via USB. The little development environment has a "run" button on it that automatically downloads the program onto the target board and starts execution. Easily the slickest way to program an embedded processor I've ever used. From there, once you've got some experience, you can move onto other platforms or programming methods.

Barring that, if you absolutely insist on using PC hardware, with its huge size and power consumption relative to what's needed, there's always DOS, which has no autonomous processing at all and turns your PC into a bulky microcontroller. These days you can use FreeDOS.
View user's profile View All Posts By User
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 19-5-2010 at 07:48


Norton commander is already there: "Midnight Commander", "mc" is the command ...
View user's profile View All Posts By User
quicksilver
International Hazard
*****




Posts: 1820
Registered: 7-9-2005
Location: Inches from the keyboard....
Member Is Offline

Mood: ~-=SWINGS=-~

[*] posted on 19-5-2010 at 08:37


Quote: Originally posted by chief  
Norton commander is already there: "Midnight Commander", "mc" is the command ...

There's also "Free Commander" and Ztree or WinTree. The latter are written in languages w/ assembler subroutines as they are text-based and super fast (I mean it). But a lot of the "Commander" clones are written as full windoz programs and are just explorer with two frames: which seems a shame because if the code is there to play with, why compile it in Visual-whatever instead of a text-based 32bit thing like many do with Linux ports....?


Speaking of micro controllers....There is (was?) a learning toy sold at radio shack that taught basic chip programming. It had a little breadboard and you had a 8-pin dip with 2k of space but it also had the setup inside for working with much bigger chips. There's a PC card it comes with that is basically a chip writer. The whole thing sell for less that $80 or so. That's a lot cheaper than a eeprom writer (used) & NO instructions.
I saw the book it comes with and it's a pretty damn good one.
That was what I thought could be a solution, if you knew enough to make a simple eeprom (the kit would show you what to do - what we are talking after anyway). I've never done that stuff before but I still remember the MASM timing analysis (func time, func + child time, hit count funtion, etc). It couldn't be THAT hard to do. They didn't call it a macro assembler for nothing. Writing code isn't needed if you just pluck macros and cut & paste. It's likely the same shit.
I'm not sure how much space is available today but you look at CMOS chips of today's computers and I'd bet there was more than 64k of space to write something. Likely as not; if you could wipe a CMOS chip and use it, you'd get about 8Mb of room. Thats enough to write anything.







[Edited on 19-5-2010 by quicksilver]




View user's profile View All Posts By User
chief
National Hazard
****




Posts: 630
Registered: 19-7-2007
Member Is Offline

Mood: No Mood

[*] posted on 20-5-2010 at 01:00


Just to share one of my ways: Regulating voltage with the parallel port ...

There are those 8 out-pins, switchable with the "ledblink"-program from above ... : Each connected to 1 relay ...
==> Then you have a transformer with 8 separate windings, following voltages: [1,2,4,8,16,32,64,128] Volt
==> ... each of the relays can swith one of these into series with the others, providing any voltage from 0 to 255 Volt ... , 1 Volt resolution ... :D

The actual Voltage can be metered by the serial port, voltmeter, with the linux-program "cdmm" which is part of the package "qtdmm" ... ..., which gives a stream of the measured values and can read many voltmeters ...

Of course the Voltmeter can be set to read amperage, or temperature ...

Also the relays can switch someting else either parallel or in series, eg. capacitors for regulating the Joule-number, or inductivities or resistors ...
With several parallel-port-cards there are several such relay-banks possible ... ; eg. as well there might be switched different
Pt100=Thermoresistors to the voltmeter, for monitoring 8 Temperatures instead of 1 (would use reed-relays for that ...)

Each relay of course to be connected via a simple optocoupler-circuit, 50 ct each chip ...

[Edited on 20-5-2010 by chief]
View user's profile View All Posts By User
 Pages:  1  2

  Go To Top