That chip has four inputs, I assume you're using just one? How well does it perform when all four inputs are used? Or is that irrelevant?
Pretty good weekend effort
- Thread starter joeyd999
- Start date
I require two channels on an ADC to produce one channel of digital data.
Ok, now you've got my attention ... why are you using two channels? I assume it improves precision, of course, but how do you do that? Do you just read the same signal from both inputs, and then average their result? ... if you feel my questions are digging to deep, feel free to ask me to stop. But I'm genuinely interested because I find the subject of analog to digital conversion fascinating.
Oh, no. That would serve absolutely no purpose as there is only one actual ADC with multiple multiplexed inputs.
There are two analog signals that must be combined (via lots of floating point math) to create a signal representative of the real-world signal.
And that's all I can say about that.
Last edited:
That answer is good enough for me ... I'm back into listening mode ... thanks!
I just found some neat open source software:
https://kst-plot.kde.org/
My board streams data out the RS-232 port -- in ASCII -- to the PC. With Kst, I can now do the following:
1. Port the RS232 data into a file (simple to do on Linux command line)
2. Start Kst
3. Drop the file into the Kst window.
Done.
Kst then updates any number of various plots, FFTs, filters, whatever, in real time as the data is pumped into the file.
Makes quick work of what I normally do on a spreadsheet.
Interestingly enough, I wrote a MSDOS app (C++) back in the mid 90's to do exactly this. I had to write my own windowing system under DOS to capture and display the various analysis windows exactly like it is done in Kst.
I always dreamed of writing a similar app for Linux. Now I don't have to.
https://kst-plot.kde.org/
My board streams data out the RS-232 port -- in ASCII -- to the PC. With Kst, I can now do the following:
1. Port the RS232 data into a file (simple to do on Linux command line)
2. Start Kst
3. Drop the file into the Kst window.
Done.
Kst then updates any number of various plots, FFTs, filters, whatever, in real time as the data is pumped into the file.
Makes quick work of what I normally do on a spreadsheet.
Interestingly enough, I wrote a MSDOS app (C++) back in the mid 90's to do exactly this. I had to write my own windowing system under DOS to capture and display the various analysis windows exactly like it is done in Kst.
I always dreamed of writing a similar app for Linux. Now I don't have to.
That's interesting. I have a LabJack data acquisition box. I access it now by treating the various outputs as unix files. I open those in Excel, just because that's what I know and use. It sounds like Kst could be a another option. Higher performance but not as much as work as writing my own plotting routines.
I've just tested the most critical component of my project ... and it WORKS ... 
The very strange part is that it works exactly within the parameters that I had estimated ... I made no previous calculations because they would've been far too complex ... and I have no previous experience with electromagnetism, which is a crucial part of the system ...
It feels a bit uncanny ... almost as if someone up there wants me to succeed ...
The very strange part is that it works exactly within the parameters that I had estimated ... I made no previous calculations because they would've been far too complex ... and I have no previous experience with electromagnetism, which is a crucial part of the system ...
It feels a bit uncanny ... almost as if someone up there wants me to succeed ...
Kudos for your intuition. I work the same way often.
Mostly, though, I try to predict with rigor the expected performance prior to testing (or completing a design) .
Me too ... but sometimes calculations (or simulations) are either close to impossible, or are more expensive (in both time and monetary resources) than actually building the thing and physically testing it... and this was the case ...
As for the rest of the project, I've already had it simmed and meticulously evaluated. And it seems that everything's a go. Now I just have to put a little more time and hard work into assembling this thing, and test it as a whole ... which is something that will hopefully happen this weekend.
Good luck! I'll drink a beer for you.
You're gonna have to settle for a Guinness. It's what I've got handy.[OFF TOPIC]
Have one of these for me:
They've become my latest craving.
[/OFF TOPIC]
I had three, just for good measure.
Here's a small chart I made with Kst showing the temperature sensor output in 1/1000°C increments.
The data rate is 64 samples per second, so this is a little over 2 seconds of data.
And, yes, the temperature is increasing. I'll post another plot when it stabilizes.
The data rate is 64 samples per second, so this is a little over 2 seconds of data.
And, yes, the temperature is increasing. I'll post another plot when it stabilizes.
Ok, so after sitting around for a couple of hours, I finally got some good temperature data. Here is 15 minutes worth at 64 SPS unfiltered:
Couple of notes:
1. Internally, the data is processed as 32 bit floats. I exported the data via RS-232 in 5.3 format (xx.xxx). My float to BCD routine rounds the LSD. I can easily change this to 6.4 or 7.5 to give a better picture of the actual noise -- in fact, I wanted to do this during the warm-up, until I realized I'd have to wait hours more for stabilization.
2. Based on what I see, the noise is just less than 1 mC (as in 0.001C).
3. The long-term undulations you see are caused by my A/C cycling on and off.
Wait, you say...how could I stabilize the temperature to about +/- 2 mC for 15 minutes with the AC cycling???
I am glad you asked.
Remember this project?
I just threw my whole kit into an Igloo cooler -- along with the controller -- and wrapped it (the Igloo) up with a bunch of blankets to minimize the effects of the AC.
I set it to 35C. The new sensor runs just a bit hotter because it generates a little heat during its normal course of operation.
Interestingly enough, the temperature controller uses only the integrated 10 bit DAC of the PIC, resulting in about 10 counts per °C at 35°C, and it was still able to maintain the temperature within about +/- 2 mC.
Neat stuff.
Couple of notes:
1. Internally, the data is processed as 32 bit floats. I exported the data via RS-232 in 5.3 format (xx.xxx). My float to BCD routine rounds the LSD. I can easily change this to 6.4 or 7.5 to give a better picture of the actual noise -- in fact, I wanted to do this during the warm-up, until I realized I'd have to wait hours more for stabilization.
2. Based on what I see, the noise is just less than 1 mC (as in 0.001C).
3. The long-term undulations you see are caused by my A/C cycling on and off.
Wait, you say...how could I stabilize the temperature to about +/- 2 mC for 15 minutes with the AC cycling???
I am glad you asked.
Remember this project?
I just threw my whole kit into an Igloo cooler -- along with the controller -- and wrapped it (the Igloo) up with a bunch of blankets to minimize the effects of the AC.
I set it to 35C. The new sensor runs just a bit hotter because it generates a little heat during its normal course of operation.
Interestingly enough, the temperature controller uses only the integrated 10 bit DAC of the PIC, resulting in about 10 counts per °C at 35°C, and it was still able to maintain the temperature within about +/- 2 mC.
Neat stuff.
I was just about to start typing when I noticed this. Neat.
Actually I would love to publish the temperature controller as a complete project here on AAC. My customer was not successful in selling the product that this board was going to be part of.
Unfortunately, it contains way too much of my secret -- read: competitive -- sauce.
we use the expression "meat" down here ...
