Type Casting

[kiwimunzy]

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

[Ton Plomp]

Hi Paul,

it seems strange to me as well, but here are my thoughts. First I don't think you need 4.x conversions. The only thing (as far as i know) that changed is the storage of booleans that were stored as single bit and now are stored as bytes (but we can use that).

I'm not sure about 7.1 but maybe you are converting EOL/EOF? these shouldn't be converted (right click on the read file vi).

Now to control what happens you have to make sure you read the same data from the file and then do the following:

The boolean array will show (bitwise!) where the data differs, you can check this after every conversion made also have a look at the length's of both converted boolean array if these differ by 32 you are reading the length of the data as well

One addition in the not-working state you can skip the first type cast and how does you're endian conversion work on 15000 csg's?

Ton

PS could you add a sample file?

[kiwimunzy]

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

[Kevin Boronka]

The boolean array will show (bitwise!) where the data differs, you can check this after every conversion made also have a look at the length's of both converted boolean array if these differ by 32 you are reading the length of the data as well

One addition in the not-working state you can skip the first type cast and how does you're endian conversion work on 15000 csg's?

Note that a boolean in labview is actually 8bits. I would typecast the double array into an array of U32's then convert each U32 into a boolean array using the Number to Boolean function if you need an array of booleans.

[kiwimunzy]

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

[Ton Plomp]

Note that a boolean in labview is actually 8bits. I would typecast the double array into an array of U32's then convert each U32 into a boolean array using the Number to Boolean function if you need an array of booleans.

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

[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: