kiwimunzy

That's why I use the 4.x conversion

The reason the endian conversion went wrong was because you endian-conversed the whole data-set as one. The following code should work:

The decimate and interleave array split the array in byte-order (I use 8 arrays) and reconnects them reversed.

Ton

Cheers for that. Worked a treat.

I just assumed that because the signal had been demodulated and was playing that the endian conversion was alright. It wasn't till I had a signal of known values and tested each part of the circuit that I could see the error.

Anyway, it is working a treat and its a lot faster.

Cheers fellas :thumbup:

Ok, I'm back.

I have had a wee play around and it seems the casting wasn't the issue. It is the endian conversion that is screwing things up.

Basically, if I do the conversion while looping through the array everything is fine. If I try convert the whole array it mucks the values up.

I have attached a copy of a VI and a data file to illustrate.Download File:post-5499-1156314691.zip Download File:post-5499-1156314871.vi

Now I have a new problem. Looping through the array to do the endian conversion is too slow. Is there a better or faster way??

The data is output to the sound card which now has a issue with cpu timing (sound starts and stops buffer length dependent). Even when using queues.

Any suggestions on how to speed the conversion up??

Regards Paul

Thanks.

The data file is about 200MB. I will record a smaller one, or trim the one I have down, when I get a chance. Time is not my friend at the moment.

The choice of 15000 is not a good one i know, considering csg is 64bit. This was just a value I had in there. The endian conversion works ok, well at least when the readfile.vi with cast is used. I did have the "remove white space VI" in the string section and it didn't seen to make a difference.

I will have a look at the bitwise comparison when I can. Hopefully there will be a obvious pattern.

Cheers

I am reading a radio signal of complex type from a binary file. When I use the readfile.vi with a complex constant as the byte stream type everthing works fine. It outputs an array of correct complex values.

However, when I don't cast the type on the readfile.vi, but type cast it using the typecast.vi, using an complex array as the type,it gives me different values. They are close, but not the same. I need to use this method as I plan on using TCP and the readTCP.vi does'nt have a cast input.

I am using LV7.1 on Linux

Any ideas on whats going how the read file cast and the type cast is different??

I have attched a VI with the 2 different methods.

Download File:post-5499-1155677245.vi

Cheers for any help

Paul

I would suggest using a parallel loop for the SO Write function, and passing the data from the read/calc loop to the SO Write loop through a queue. I've attached a quickly modified version of youR vi for review.

If your data set is large (or continious) you should place some sort of wait next multiple in the producer (read/calc) loop so you don't eat up all your system memory by producing SO data faster than the output rate.

Also, performance almost always improves when you keep the data types as integer and provide the correct type input to the primative functions. I believe you are writing doubles to the 8 bit mono input of the SO write, after adding a constant of type double to an I8.

Download File:post-949-1153827402.vi

Thanks guys, I'll have a look later on in the week. I was unsure how to implement queues...

Cheers Paul

Glad to hear that you got your sound card working with LabVIEW mate!

That problem still exists. Gave up and moved onto anther computer. I'l try sorting it out again when I get a chance. Same old story tho, not enough hours in the day.

Ok, so i figured out the slowness problem was because I was reading a single sample at a time. Now I read a whole lot and the program can keep up.

There is still a slight gap though. There was a mention of a artical somewhere about gapless sound and buffering. Does anyone know where I can get a copy of this??

Here is the VI I have been using. It isn't much good to test without the data file (the data file is rather large), but you may be able to see room for improvment in regards to the loops and buffering.

Cheers Paul

Download File:post-5499-1153801763.vi

Here is my story....

I am working on a software defined radio implemented in Labview. At the moment I am reading a binary file which contains I & Q radio samples (eventually I will read from a pipe or TCP).

The way it is set up at the moment, I have a while loop containing a for loop and the sound

Paul: I would recommend talking to NI about this one. It is probably an issue with LabVIEW talking to the Linux sound system.

Cheers for the advice guys. I'll give them a bell. I am planning on upgrading the OS soon, so i'll do that first (Just in case).

Regards Paul

Kia ora Paul! Please post any example VIs of things you've tried so far to we can point you in the right direction...

Hey hows it going??

I have added my FM demod VI I am working on. It won't be any good without the data file tho. Download File:post-5499-1152144442.vi

The other VI I have tried is the "Continous Sound Output.vi" in the labview examples folder. Download File:post-5499-1152144397.vi

They are both set up the sound in the same way same really.

I am thinking it maybe a config problem.

Thoughts??

Cheers Paul

I have been delevoping a VI to demodulate FM. Everything was going fine till I went to hear what the result was. I have no sound at all. However I dont think the issue is in my VI. I tried using the example "Continuous Sound Output.vi" and that doesn't work either. The error that's produced is: "Error 10403 at SO Config.vi in Continuous Sound Output.vi"

I haven't tried to use sound in labview until now. I have also tried closing the music programs etc (the obvious ones) in case they had reserved the sound card, but to no effect.

Any help would be much appreciated. This is part of a project which needs to have sound from labview.

Regards Paul