Just some general info on the subject of ad-hoc/experimental IO from within the Windows environment. I personally think, that if you want to keep a T'Bolt at a constant temp, it's best done with an independent control system (hardware or software) than any attached PC. In the long term anyway. However, to prove the point, and for general experimental messing and fiddling... Take a look at INPOUT32.DLL http://logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_9 8/2000/NT/XP.html It allows you to have almost direct control of any IO space port the system has. Common "targets" for this are otherwise unused LPT ports, but it has to be a "Real" hardware port, not a USB<>LPT device. (You can still send control bytes to those via the OS though, and read the status likewise, but the delays can be a pain!) It will pass through commands and data if running on a Win9X system, or install a Kernel mode driver on a NT (2k, XP, etc) system. You can use just about any common programming language to drive it, so long as can call external DLL routines and pass data to, and receive it back from such routines. There is a "Huge" amount of info on t'interweb, about how to use the venerable LPT port for general purpose digital IO. Otherwise, take a look at any of the USB<>Digital IO experimental kits that abound the web. In this case, if the T'Bolt can report it's internal temperature over RS232 as you describe, then using a serial port, with one or more of the handshake lines "re purposed" to control the heater/cooler should do the job, you just need to get a bit creative. Though many Windows based SW development languages are poor in their handling for COM ports, it is possible, and once you have the grasp of how to directly manipulate the port via the OS, things like that work very well. (Some versions of VB though have some interesting "Features" in the way they handle the serial port, that can really annoy you, just to make it difficult to send/receive binary data. ASCII OK, Binary seems to get some bytes filtered out!) DO NOT try to command IO ports directly on NT systems from your own code. They will at best object with a popup, at worst crash with a BSOD, or just reboot on you unexpectedly! You will need something like INPOUT32.DLL (or other similar tools.) Even then, sometimes unless you tell the OS you are going to use the port, there can still be trouble. Best with COM ports, to go via the OS, at least it'll be aware of what you are doing, so should prevent any other app from trying to grab it. I recently implemented a 4bit IO control bus via the LPT port, to interface to an old ICOM HF receiver to a much newer control system. It works well, and is stable for weeks/months at a time... It even survives a reboot without screwing up, and it doesn't just sit there dormant all the time, as it is controlled and polled repeatedly from another program, with the inter-program communication via some virtual com ports courtesy of Eterlogic's VSPE tool. http://www.eterlogic.com/Products.VSPE.html or N8VB's virtual null modem. http://www.philcovington.com/SDR.html Scroll down to "Open Source Software". I have used MarshallSoft's serial IO library (WSC at http://www.marshallsoft.com/ not free, but very good value and stable) with both "Real" and USB<>RS232. You can't tell the difference for most purposes, but avoid Belkin adapters. They seem to have some "interesting omissions" in some of their USB drivers! FTDI seem to be about the best chipsets to use, and the documentation is excellent from FTDI's website. http://www.ftdichip.com/ There are also USB<> Parallel IO chipsets too. I've yet to need to explore them With both real or USB<>RS232 ports, with the Marshallsoft library (and with my own native Win/Delphi code) I have had simultaneous serial IO, and used the DTR/RTS lines as power and control lines for a hardware interface, swapping them over +-/-+ to control TX/RX on a radio as well. No problems. In some ways, once you have all the needed code baggage in place, it's easier in Windows to do that sort of stuff, than it ever was with DOS. It just eats more memory to do so. (But looks nice!) Oh yes.. Also, since Win2k SP3 (I think) MS disabled by default any low level (DOS mode) access to the COM ports. There is a registry tweak that can re-enable such things but I've lost sight of it, as when we got hit by that at work, I bit the bullet and learnt how to program in Windows with Delphi, and re-wrote many of our tools and utilities (originally written for DOS in QuickBasic) for Windows. It was painful, but well worth it in the long term. Don't let MS's latest bloatware OS's put you off from experimenting with IO on modern PC's. If anything, with the later GUI OS's and some good (sadly not all dev' tools are "good", paid for or otherwise) SW development tools, you can still take over the world in odd ways, as you wish. Ulrich's EZGPIB tool, also has easy serial port handling (mind you, I've not tried the handshake tricks yet) and has minimal impact on a system, unlike installing a full development package! Highly recommended. http://www.ulrich-bangert.de/html/downloads.html I have to say though, my experience stops at XP (but includes 3x, 9x, ME & 2k). I now have a Vista machine in the fold, but have not tried any of this on that OS, yet.... I suspect I'll be in for a surprise of some sort, as it only has USB ports, nothing "real" sadly... If you want to "go for broke". Check out SIB (Small Is Beautiful) http://www.grc.com/smgassembly.htm or hints as to how to program in native assembly language for Windows! Scroll down for all the useful links etc. Just my sixpence worth anyway. Regards to all. Dave B G0WBX.

> I have used MarshallSoft's serial IO library (WSC at > http://www.marshallsoft.com/ not free, but very good value and stable) > with both "Real" and USB<>RS232. You can't tell the difference for most > purposes, but avoid Belkin adapters. They seem to have some > "interesting omissions" in some of their USB drivers! FTDI seem to be > about the best chipsets to use, and the documentation is excellent from > FTDI's website. > http://www.ftdichip.com/ FTDI is the way to go, IMHO. Parallel ports were great back in the day, but even the I/O access code probably won't work on your next PC. On my desktop machine, they don't even pretend to associate the LPT port with its traditional ports. It's useful only with OS printer support. > Oh yes.. Also, since Win2k SP3 (I think) MS disabled by default any low > level (DOS mode) access to the COM ports. There is a registry tweak > that can re-enable such things but I've lost sight of it, as when we got > hit by that at work, I bit the bullet and learnt how to program in > Windows with Delphi, and re-wrote many of our tools and utilities > (originally written for DOS in QuickBasic) for Windows. It was painful, > but well worth it in the long term. http://www.beyondlogic.org/porttalk/porttalk.htm will work fine, as far as allowing your Windows app to bit-bang the ports goes. But Bill only knows what it would take to get it working under Vista, and, again, the trend is away from legacy LPT-port compatibility at the hardware level. > Don't let MS's latest bloatware OS's put you off from experimenting with > IO on modern PC's. Well, in principle, I/O protection is one of those security features that MS would be roundly mocked for lacking, if they hadn't implemented it by now. -- john, KE5FX

> -----Original Message----- > From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On > Behalf Of John Miles > Sent: Thursday, August 27, 2009 5:10 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Tbolt temperature Control & ad-hoc IO from > Windows. > > > > Well, in principle, I/O protection is one of those security features > that MS would be roundly mocked for lacking, if they hadn't implemented it by > now. > Actually, what I'd like to see is a very cheap (<$10-20) simple parallel I/O that is USB (or even better Ethernet) compatible. The Labjack at around $100 is close. The $25 DATAQ DI-194RS is the sort of model here.. http://www.dataq.com/products/startkit/di194rs.htm They have a USB version for $50 (DI-148U).. but getting up to there, I'm starting to think that just going to $100 for a better ADC, etc. is nice. This would make doing science projects for kids (and grownups) a lot easier, because getting them in the habit of automated data acquisition, rather than tediously writing numbers in a log, and then transcribing them.. (I note that DATAQ will give a kid a free DI-194RS, if they fill out the app and send them a picture of the project when they are done) (Heck, to be honest, *I'd* give them a free widget, if their cause was worthy) If you need a lot of DAC channels, there's a $50 eval board for an 8 channel 16 bit DAC (LTC2600) from Linear Technology that has a usb interface, but it's emulating a serial port, and you can trivially reverse engineer the protocol. (which is available from LTC in any case).. You're looking for the DTC590 eval board controller, too (which is $125). You dump LTC's drivers, and install FTDI's Virtual Com Port (VCP) drivers. (or devise your own SPI interface to the DAC eval board) The labjack ue9 has Ethernet, but is in the $400/500 price range, as opposed to the U3 at $100