USB data logging

[Jitterbug]

I have recently bought an Omega PX409 USB data logger. The software that comes with the is crap and will only let you sample at a rate of once a second, I want somewhere between 4 and 10 readings a second.

Their technical support is decidedly useless telling me their is no alternate software, even though the thing comes with drivers for LabView and Visual Studio / DotNet.

Labview looks like labview will do what I want without too much trouble but it seems overkill when all i want to do is record pressure/time, in approx 1 min blocks, and put this into excel for analysis and to draw graphs.

here are the drivers and command references etc:
ftp://ftp.omega.com/public/DASGroup/products/PX409-USB/

I am hoping someone smarter than me will know something about this and can point me in the direction of a simple solution?

[WhiteD3]

Can't you just export the data to Excel and get rid of the data you don't want?


I have recently bought an Omega PX409 USB data logger. The software that comes with the is crap and will only let you sample at a rate of once a second, I want somewhere between 4 and 10 readings a second.

Their technical support is decidedly useless telling me their is no alternate software, even though the thing comes with drivers for LabView and Visual Studio / DotNet.

Labview looks like labview will do what I want without too much trouble but it seems overkill when all i want to do is record pressure/time, in approx 1 min blocks, and put this into excel for analysis and to draw graphs.

here are the drivers and command references etc:
ftp://ftp.omega.com/public/DASGroup/products/PX409-USB/

I am hoping someone smarter than me will know something about this and can point me in the direction of a simple solution?

[Jitterbug]

Can't you just export the data to Excel and get rid of the data you don't want?

The problem is that i dont have enough data, not too much. I need a sample rate of between 4 and 10 readings a second, the program that came with it only gives 1 reading a second.

[Maelgwn]

I would assume that the readings from the software are averaged over the 1 second sample. So sampling faster would not add any information if you are going to average into 1 min blocks anyway?

[Jitterbug]

I would assume that the readings from the software are averaged over the 1 second sample. So sampling faster would not add any information if you are going to average into 1 min blocks anyway?

My initial description might not have been the best, over that one minute period I need to see what the pressure is every 0.1 second.
It is for the bench testing of relief valves to confirm at what pressure they are opening.

[Maelgwn]

My initial description might not have been the best, over that one minute period I need to see what the pressure is every 0.1 second.
It is for the bench testing of relief valves to confirm at what pressure they are opening.

A quick google suggests the bandwidth of the sensor is DC to 3Hz, meaning that the data sampled this fast would not really add any meaning? It is possible i looked at the wrong thing or there is more information regarding freq response somewhere?

[Jitterbug]

A quick google suggests the bandwidth of the sensor is DC to 3Hz, meaning that the data sampled this fast would not really add any meaning? It is possible i looked at the wrong thing or there is more information regarding freq response somewhere?

even 3hz would be a big improvement to the 1Hz the software will let me work to...

[Jitterbug]

even 3hz would be a big improvement to the 1Hz the software will let me work to...

The UK omega site specifies
"Max. Read Rate: 1 sample/second (using Omega software)"which implies software could be the limiting factor. Given it is an analogue signal to the compluter the response of the transducer and processing power of the PC should be the only limiting factor.
The non-USB model that logs to memory will take up to 1000 readings a second.

[Maelgwn]

The UK omega site specifies
"Max. Read Rate: 1 sample/second (using Omega software)"which implies software could be the limiting factor. Given it is an analogue signal to the compluter the response of the transducer and processing power of the PC should be the only limiting factor.
The non-USB model that logs to memory will take up to 1000 readings a second.

No the A to D conversion happens on board the transducer.

I assume this is the thing you are talking about USB Pressure Transducer PX409USB (http://www.omega.com/ppt/pptsc.asp'ref=PX409-USB&nav=)

You could write a program to talk to the device through the serial interface, and see if polling the device gives you a greater sample rate than 1Hz?

[Ferret]

On your link is some supplied C# sample code for interrogating the device. You are going to have to use it or modify it to change the sampling rate.

If you look at that code you will find in method "start_button_Click" the relevant piece of code to modify. (I think)

// Parse the wait time between data collection, and put the while loop to short sleeps while waiting.
int waitTime = 0;
int.TryParse(waitTime_textBox.Text, out waitTime);
int count = 0;
do
{

Thread.Sleep(50);
Application.DoEvents();
count++;
}
while (count < waitTime * 20);

The 'Sleep' parameter and the value of 'waitTime' have some influence on how fast the software samples data from the device. I think :)

The value of 'waitTime' is being set in a 'Textbox', ie it is a value you type in when you run this code so you may be lucky and not need to modify anything at all - again I think.

[Jitterbug]

Thanks for that, on the data log screen you pick the interval from a drop down box from 1s to 1000s.
Any idea how I would get to the code to modify it?


On your link is some supplied C# sample code for interrogating the device. You are going to have to use it or modify it to change the sampling rate.

If you look at that code you will find in method "start_button_Click" the relevant piece of code to modify. (I think)

// Parse the wait time between data collection, and put the while loop to short sleeps while waiting.
int waitTime = 0;
int.TryParse(waitTime_textBox.Text, out waitTime);
int count = 0;
do
{

Thread.Sleep(50);
Application.DoEvents();
count++;
}
while (count < waitTime * 20);

The 'Sleep' parameter and the value of 'waitTime' have some influence on how fast the software samples data from the device. I think :)

The value of 'waitTime' is being set in a 'Textbox', ie it is a value you type in when you run this code so you may be lucky and not need to modify anything at all - again I think.

[Ferret]

Download the sample code 'PX409USB_SampleCodeForCustomers.rar' from your link. Extract it to a new directory of your choice.

Download 'Visual C# 2010 Express' from here (http://www.microsoft.com/visualstudio/en-gb/express) and install it.

Ensure you have the latest updates to the .Net framework installed ~ version 4.something

Looking at the code you will probably need to have installed 'Microsoft Chart Controls for Microsoft .NET Framework 3.5'. If not get from here (http://www.microsoft.com/en-us/download/details.aspx?id=14422)

Open visual studio express. From the 'File' menu choose 'Open Project' and select from within the folder where you extracted the sample code the file named 'PX409USB_AppDemo.sln'. After a conversion process all the sample code will available for you to modify as you wish.

If all the above is gobbilty gook then your on a very steep learning curve. Rather than trying to modify it Just try this.

In the folder where you extracted 'PX409USB_SampleCodeForCustomers.rar' look for a sub folder named

'\PX409USB\Omega PX409USB Sample App (VS.Net 2008)\PX409USB_WinApp\bin\Debug'

you should find a file there named 'PX409USB_WinApp.exe'. double click that ensuring first your device is plugged in and your drivers are loaded. With any luck a window should open looking something like this

https://www.aulro.com/afvb/images/imported/2013/01/291.jpg

Enter your wait time (0.25, I assume in your case - 4 samples / second). Press start. when you have your data, press Export Data. The code says you will be prompted to save your data to a CSV file.

All this is theory - I can't run anything because I don't have the device to test anything. Good luck.