Output 1/3 octave sound level thru 1 byte CAN channel

[sfrosty]

I'd like to know if once I convert a Sound Level signal input through a NI 9232 (BNC) sound module and then convert that sound level signal to 1/3 octave band utilizing the Sound and Vibration Toolkit, if I am able to output that 1/3 octave band sound level signal value thru a NI 9862 CAN module utilizing a one byte frame.

[Hooovahh · Accepted solution]

Yeah sure you can.  If you only have one byte you'll only have 256 possible values of amplitude.  Is that enough precision?  You have up to 8 bytes in a single CAN frame to work with.  Post more code to show what the value you are starting with looks like and how you were trying to turn it into a CAN frame.

[sfrosty]

Thanks! Now that it's confirmed. I'll work on the rest and post back asap.

[sfrosty]

Oh, the addtional 7 channels are to be utized for vibration. 1 channel per accelerometer input per byte.

[Hooovahh]

You do know a channel (signal) doesn't have to be in increments of one byte right?  You can have 64 channels each taking up one bit.  My point to this is you can set the level of precision where ever you want with whatever scaling you want.  If you want values between 0 and 100 in increments of 1 then that only takes 7 bits, and you can then use the remaining 57 bits however you choose.  You can also choose to have 8 different frames, where each one can take up 8 bytes.  It is all up to you how to pack your data.  The XNet Database Editor is a good place to visualize signals and bit packing.  You can then export that into a CAN DBC to be used in other APIs.

[sfrosty]

I do realize the signal does not have to be restricted to one byte. The specification stated that each signal would be one byte in length. Then the issue came up, as you had mentioned, will this give us enough resolution. Then it was decided to convert the sound signal to 1/3 octave values, concluding  that a log signal would generate better resolution. But now I'm thinking why not forgo the 1/3 octave analysis and increase the signal to 2 bytes in length to obtain better resolution. Or for that matter, an entire frame of 8 bytes could be used to represent one sound channel. Am I correct in my analysis? Thank You!

[Hooovahh]

I still haven't seen any code so I can't say how or what is being packed, but you certainly can take data and scale it to 1 to 8 bytes of data.

[sfrosty]

Sorry for not providing any code. I'm just not there yet. Other priorities.

[sfrosty]

I utilized one of your suggestions and wrote code to convert the byte values to correspond to the specified engineering units. For example I utilized 2 bytes, x0 thru x65535 to represent engineering values of -327.68 to 327.67 g's in .01 increments with an offset of -327.68.

I'm now having an issue with the CAN data 2 byte 159.2 Hz 102.634 mV/g sine-wave that is being transmitted dropping out periodically. I'm utilizing the Frame Out Stream function at 1 meg transmitting from a 9862 CAN module in a cDAQ 9132 chassis to a second cDAQ 9132 chassis with a receiving 9862 CAN module. Code attached.

[Call.Me.Wilbur]

Do you still get the same behavior if you set the Single Shot Transmit property to false? It might be the case that you're getting occasional failed transmissions but since that property is set to True you never attempt to retry transmission and that data is dropped.

It might also be helpful to narrow down whether its a problem writing or reading. Are you confident that the receiving module is working fine and nothing is going wrong there? You could use Bus Monitor on this end to eliminate any issues that might be occuring in the recieving VI.