I was wondering, how I can track data using a PC. I could buy some expensive equipment for tracking, but I could also find an ADC and connect it to a serial port or USB or.... I guess there are equipment like that available. Maybe even ICs for that.
Data can be polled or sent automatically. Doesnt matter.
PCs track data. PCs process data. PCs create and compile information. Information is defined as processed data. So PCs perform simple compilation (a list) or complex processing (SETI at home or protein folding), depending on what you need.
It is up to you to do a requirements analysis where you define the type of data and how the data elements get acquired by the system and what subsequent processing of the data needs to be done to deliver the final product to you, which is "information".
Then you do another analysis where you define what your budget for equipment and such is, if the data elements require scanning, etc.
There are a few more steps, but a big part of using a PC to assist labor and logistics is performing the initial analyses needed to perform the needed tasks in the most cost effective ways.
Modern systems use optical codings (barcodes, etc) and even RF based (RFID)non-contact proximity based systems.
And ADC with input say 0-2V, where I from the PC can poll and get the number is ok. I can write the software myself as needed, but I ask for any HW availble such as ready ICs or circuits.
The input 0-2V can be virtually anything I can add what I need for the given situation.
A serial ADC and some logic with the right speed can be an RS232 ADC. A PIC can do it too. But I expect that such things have been done.
On a sunny day (Tue, 19 Apr 2011 04:55:38 -0700 (PDT)) it happened Sonnich Jensen wrote in :
First find out what sort of data, how fast (bytes / second), how much at any one time, latency allowed, input protection?, temperature range, humidity range, air pressure range, vibration resistance in G, accuracy!, any filtering, etc etc etc
Not really important. Say, once a minute or so, and as I wrote and 8 bit resulution is ok. An analog input, some voltage. Depending on the need I can apply some opamp or so. I'd like to check data from a solar changer, and I need various information over time during development. So, applying some additional opamp is not a problem.
I found this, which will do it.
formatting link
However, I was thinking more in using Rxd and Txd. But this will do.
Take a look at the USB-connected data acquisition modules from various venders. Both MCC
formatting link
and DataQ
formatting link
have some relatively inexpensive modules that you can just plug in and start collecting data.
I like the MCC modules -- they've been around the business for a long time, originally as "Computer Boards, Inc." back in the dark ages and then "Measurement Computing." The modules come with out-of-the-box data capture software but also include interface DLLs that let you write your own apps that control and read the modules.
When you're evaluating the modules, from any source, do pay attention to the input voltage range; some of the least expensive may have a fixed range, while the others support programmable gain settings.
q.com/have some relatively inexpensive modules that you
Most of the functionality of these modules can now be replaced with a single chip USB controller. I like the PIC24FJ256 for the large 96K sram for buffering. If you need more, you can always hookup a USB flash drive for storage. There are plenty of evaluation kits available for quick experiments.
Yep, that's true. Well, except for the gain scaling. And the bipolar inputs. The case and screw terminals. And the API kit and application software. ;-)
Like a lot of build versus buy comparisons, there are always trade-offs. It sounds like the OP just needs a tool so he can get on with the real project.
Having been bruised by fighting the WREG in the past (I know, the PIC24 arch is better, but still...), I'd probably go with one of the STM32F103 Cortex M3 chips, with 16 A/D channels feeding a pair of 12-bit converter peripherals. Nice chip. USB or CAN but probably CAN for the longer cable length. But in the end, it's all just chips on glass.
PIC24 (16 bit) is fine, just avoid anything less than 24. I told the microchip rep that I would not design anything less than 24. In terms of high level arch, PIC24 is closer to ARM than AVR. At least we don't have to deal with Program/Data space issues. I also told the rep that I would not want to start arguing low end AVR vs. PIC. We will be using 8 bit AVR, 16 bit PIC and 32 bit ARM.
Yes, but we have to use PIC, because of the upcoming PIC/Android framework (Ops, a leak, but I didn't sign any NDA).
I would say that is a very excellent suggestion since NO "cloe" or HD copy scheme would be decently useful between such different computers. Any M$ GUI would need to re-configure itself shortly after booting because it would "see" the hardware being different; starting from the simplest and working "up", video, audio, HD, north and south bridges, etc.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.