data rate issue with Labview VISA Read and multifunction module

[danadu]

I'm reading in digital values through the HP34907A multifunction module with GPIB interface.I want to do continous data acquisition with the attached vi. When I tested the vi with a square wave from the function generator through bit 0 of 1 port, the array output does not shows 010101010101(alternate ones and zeros) as it should for a square wave but showed a different pattern of ones and zeros.

I varied the frequency of the square wave and it seems that VISA Read does not change the rate at which it reads (the HP instrument's reading showed signs of slowing down or speeding up depending on the frequency of the square wave input). Therefore, when the frequency is really slow, VISA read might have read in the same bit more than once, and when the frequency is very fast, it might have omitted some of the bits. I suspect that's the reason why I didn't get the pattern of a square wave put in.
The reason why I need to test it this way is because my actual data needs recording is almost the same. And I want to make sure it reads in every single bit of data for recording. Is there a way to fix this problem or a better way to acquire this data?

If any of the above isn't clear, please let me know for clarification, Additional comment can be found under documentation of VI property. Thanks for helping!

[shoneill]

Hi Danadu,

using the serial port like this is a very inefficient way of recording the data.

I'm assuming you're polling the pin of the serial port using VISA, and not relying on the OS-based serial drivers.

If you can get the polling to work fast enough, it may just be possible to capture the signals. Bear in mind though that most serial ports are limited to 115kbit, which may or may not be linked to the single-pin switch speed, but is certainly a value to consider.

One big problem in doing the acquisition this way is that you have no real ability to do real-time acquisition. The time intervals between the different measured points will vary depending on what the OS is doing in the background.

The best way to acquire these signals is to install a low-cost DAQ card from NI. This will give you moure accurate timing of the acquisition, and is faster and more convenient to use.

Hope this helps

Shane.

[shoneill]

Sorry for the confusion with the serial port. I was still thinking of another problem.

I've looked into the VI, but have no idea what's expected as a reply from the instrument, and it's not really clear to me what you're trying to do based on the Vi diagram.

Why do aou convert the string to a DBL, and then to a U8. Why not convert directly from string to U8? I don't think the problem lies here, but I simply don't understand this step.

Can you post some example data, so that someone can maybe spot where the problem is?

Sorry for the confusion with my first post. I need coffee.

Shane.

[danadu]

I apologize if I have caused confusion. Let me put my question in a more general term.
Supposed you are reading in digital signals into labview, but you only have one single line of signal composed of ones or zeros. You have no clock and no other information on that signal except the baud rate of the signal which is 2.4kbps and a start pattern.
How do you ensure that Labview will read in every single bit of data based on the baud rate? From what I understand, when reading in digital signal, it should counts the rising and falling edges of a clock so that if a signal is low or high for a longer period than 1 bit, it would count all the bits.
So my question is that is there an internal clock in labview that you can set the frequency or baud rate of the signal so that for every rising or falling edge of the clock, it will count 1 bit of the signal? For example, if you have a signal of 8 bits and it's 00001111, can you tell the baud rate to labview so that it will read the high 4 times and the low 4 times and not see that as only 01. Thanks for explaining.

[Dennis_Knutson]

I'm confused too. In your post here, you talked about receiving serial data. I assumed that by serial, you were talking about the serial port on the pc (RS-232). Is this the same project or are you talking about something else. If it's the same and the transmission is RS-232 at 2400 baud, 1 start bit, 1 stop bit as you described in the other posting, did you try the LabVIEW serial port functions? Can you explain a little bit more about what exactly is doing the transmission? If the transmission truly is RS232, reading the data should be fairly trivial. It's one of the most common tasks in LabVIEW.

[danadu]

Hello Dennis and Shane,
Sorry to confuse you both. Let me explain things from the beginning and hopefully you can help me further. I'm a student working on a project that involves collecting data from pressure sensors.

I use a PIC microcontroller to collect the analog voltages from the pressure sensors continuously. The analog voltages correspond to the amount of weight exerted on the pressure sensors. This analog voltage is converted into digital value by the A/D converter in the microcotroller. For example, a voltage of 0.6V is converted into 00011110 (1E hex).

The problem is that this sensor system is about 50 feet away from the data acquisition system and the requirement is that the data has to be transmitted wirelessly from this sensor system to the computer.
Therefore I am using a wireless radio transceiver to transmit the data. The wireless transceiver can only transmit 1 bit at a time. So I programmed the microcontroller to use the buffer and shift out the parallel digital data one bit at a time to the transmitter starting with the LSB. I used asynchronuous transmission, therefore, for each byte transmitted out, the microcontroller automatically generated a start bit and stop bit.

At the receiver side, an identical wireless transceiver recieves one bit at a time in the same format that was transmitted by the transmitter. All of these steps were completed and tested. Data shown from the oscilloscope and the logic analyzer confirms that I have received the same data that was transmitted.

Right now, I'm in the process of collecting all the bits from the wireless receiver. At first I wanted to use the HP34907A and GPIB interface because there's already a VI written in the driver folder. I'm really new to Labview, and I'm having a hard time constructing VIs that do what I want. However, this method seems complicated because I have to extract the bits and get rid of the start/stop bit.

So I took Dennis's suggestion and interface directly with the pc through the serial port. Dennis mentioned that VISA read will automatically strip the start/stop bit. I have tried it but haven't been able to get any data yet. I'm not sure whether it was the vi I constructed that isn't working or the serial interface.

1. I have attached the vi in here. Would you please take a look and let me know if it's correct. The first part reads in the serial data. The second part reverse the byte, since the LSB was received first. And the third part is where I multiplied it by a constant to get back to the same voltage value as the original voltage from the sensors.

2. For the serial interface, there are 9 pins total. I grounded pin 3 and let the data comes in at pin 4 which is the RxD pin. Is that correct or am I missing something?

3. My final goal is write all the voltage results into a file as I receive them along with the time at which it is received. I also need to plot the votages with respect to the time received. Which waveform function should I use? Please be specific about the wiring.

I have been working on this project for months, and I'm at this final step of collecting data. I appreciate any help on this data acquisition/labview issue. Thanks so much. (sorry for the long post)

[Dennis_Knutson]

On a 9 pin connector, pin 4 is DTR (Data Terminal Ready) and is an output. Pin 2 is Rd. Pin 3 is Td and there souldn't be any reason to ground it. I'm still a little confused about your transceiver. Is this a board inside the pc? Does it emulate a serial port? You're connecting the serial port on the pc to what?

[danadu]

I must have been looking at the wrong schematic for the serial connection. The transceiver I'm using is just a simple wireless transceiver module DR3000. It's not a board inside the pc. It's an external device and does not emulate a serial port. It has 14 pins and pin 4 is the RX DATA pin that contains the serial data I described from the last post. I don't have any other information to provide for the serial port on the pc except this single line of serial data.
To be short, I'm only wiring pin 4(RX DATA) on the transceiver to pin 2 Rd on the serial port of the pc. I'm not sure if this works since the other 8 pins are left unconnected.
There has to be some other way of retreiving this serial data if this one doesn't work? I'm willing to consider buying extra daq components if you could help point me in the right direction. Thanks,

[Dennis_Knutson]

I'm not sure extra DAQ equipment is required, though something like the PCI-653x would probably work fine. All it might take is to buffer the output signal of the transceiver to make the output signals conform to RS-232 signal levels (+/- 12V). You might check with RFM to see if they have an app note or any any hints on how this might be done.

[danadu]

I've checked with an engineer and found out that I can collect this signal if I convert it to an RS232 signal level. All I need is a MAX3238 chip to convert the signal into RS232 level and input it into the receive pin and also a signal ground.
Would you please check the serial read Vi I attached in the last post and let me know if it's correct, if not how can I fix it? Thank you very much.