High speed serial data collection

[trailrider]

I am trying to collect serial data that is being transmitted at a 3096774 baud rate.

I would like to collect 300k bytes of data and store it into array X. Then start filling array Y. While array Y is being filled I would like to plot array X. Then plot array Y while array X is being filled and so on.

The device receiving the data is the C232HD-DDHSP-0 by FTDI. I have an FPGA that is sending the data to the FTDI part. It appears Labview can not read the buffer fast enough even with handshaking enabled.

Any suggestions on how to implement this?

Thanks,

Matt

[RTSLVU]

Well.... Without seeing your code we can only guess so here goes.

I am guessing you are using "Bytes At Port" to decide when and how much data to read. BTW: That method rarely works.

Is there a termination character  on the data coming in like a Line Feed or Carriage Return?

In general it works better to:

1. Enable Term Char and set the proper Character in the Serial Setup VI
2. Set your VISA read to read more bytes than you expect to receive
3. Now your VI will read until it read a Termination Character or times out.

Since you are using such a high data rate a Producer Consumer architecture is probably the best way to go. The Producer Loop would be your read loop, placing the incoming data into a Queue. The Consumer loop can then read the Queue to fill your array and graph or save the data without effecting the timing of the receive loop. 

[JÞB]

Another thing to consider is the other USB connections to the HUB.  Are they all USB 2.0? If you have a 1.0 endpoint the whole hub will revert to the slower speed

[trailrider]

Where can I find an emable of a Producer Loop?

It is connected into a high speed USB port.

I am not using bytes at port. i'm trying to read a set number of bytes.

Thanks,

Matt

[crossrulz]

---

@trailrider wrote:

Where can I find an emable of a Producer Loop?

---

Producer/Consumer

Is data constantly coming through the port or by command or at a specific rate?  Can you share any details on the communication protocol?

I have had issues with higher speed ports simply because I had a lot of inefficiencies in my code.  Fixing those fixed my processing issues.  If you want help in that regard, you need to supply some code for us to examine.

[trailrider]

Currently I'm just trying to get consistant number of bytes read. Once I get consistant data collected I will build onto that.

Once the FPGA sees the CTS line he starts outputting data. 8, none, 1. Data repeats CA 2 bytes 2 bytes. Thinking this needs to get changed??

The observasion on the o'scope shows the CTS line changing even though I have instructed labview to read many many more bytes. Why would CTS being changing?

I wil dig into the Producer/Consumer shortly.

Thanks,

Matt

[billko]

What you have so far are fairly wild guesses.  They could become much more specific if you post some code.

[Sam_Sharp]

---

@trailrider wrote:

i'm trying to read a set number of bytes.

---

Are you trying to read all 300k of serial data with one read? Or are you doing reads of fixed amounts of data until you get your total of 300k? If it's the former - I would suspect you would have buffer overflow problems. If it's the latter - that should work if you choose your number of bytes to read sensibly (enough that you do fewer reads, not too many that you fill the buffer).

[trailrider]

I have attached my current version. Ideally I would read one byte to synce to CA then ready another 1023 bytes and then store them. I would do this until I have collected 300K samples. Then I would start processing that data while another 300K is collected.

Cuurrently I'd just be happy with getting 1024 bytes consistanlty.

Thanks,

Matt

[JÞB]

Thanks for showing the code  Its a lot easier to help---After hitting Ctrl+U and cleaningup that diagram

You have an aweful race condition with an abused local variable!

Move that local OUTSIDE the loop!

What you are doing is reading the value 8191 times- and, it might change at iteration 6004 when the top loop overwrites the terminials value.  Also since you need the UI Thread to read the local the thread swithcing is going to slow that loop down

Better yet, use a Queue to move the data between loops and the UI Thread never gets involved! (Plus- you can eliminate the case structures and "captured."  Simplfying the code by removing "captured" will even FIX one of the other 3 bugs seen here! Yup: 3 obvious:

1. The True case cannot execute so no data is sent to the processing loop ever
2. COM port is configured for hardware handshaking, the VISA Read needs a large number for byte count- reading 1 byte at a time makes no sense
3. the Wait should be removed- the VISA read and the hardware handshaking should be setting the loop speed and will garuntee the loop is not greedy

See the attached MOD and check the comments.  Note: Using a Queue really simplifies stuff.