LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the maximum Sinewave Frequency that can be transmitted across CAN?

What is the Maximum Sinewave Frequency that can be transmitted across High Speed CAN set to 1 Mbit and retaining maximum amplitude information (sample rate of 10 to 20 times frequency content)?

0 Kudos
Message 1 of 13
(3,490 Views)

Not enough information is given to answer the question.  That's like asking what's the highest resolution a video can be played off of the internet...well it depends on your internet speed (1Mbit) and the amount of data encoded in it, along with the amount of buffer you are allowed.  Are we talking about streaming a video or downloading it and playing it back later?  But even with streaming there is some level of buffering taking place.

 

If you are sending a time stamp along with your CAN data there is no limit to the frequency of your wave.  I can send one frame that says at time = 0 my voltage is 1, and a second frame that says at time = 0.00000001s my voltage is 2.  Now those two frames will take more time to go out than it will to take so you are always going to be lagging behind but you can encode any waveform with it.

 

The next question is how many bits does it take to send a frame?  Well what is the Arb ID?  Is it extended?  How many bytes are being sent?  Because at 1Mbit sending 8 bytes of payload on extended will take more time than byte of data on standard.

 

Another issue is CAN is meant to be robust but not deterministic.  You will get lost frames and CAN is okay with that, it will retransmit data when lost, but that will effect your answer.  This all depends on the wiring of your network, the electrical noise, length of the wires, and number of nodes on the bus.  These variables will effect the number of frames dropped.

 

Then there is the issue of priority.  Other CAN frames on the bus may have a higher priority and your data won't be put on the bus until it is idle, and there are no other higher priority frames.

Message 2 of 13
(3,483 Views)

In case it's helpful as a starting point, the theoretical maximum speed for 1mbit CAN is approximately 9000 packets/second, assuming 11-bit identifiers and a full 8 bytes of data per packet. I ran a speed test a few months ago and came close to those numbers, transmitting just over 8000 frames/second from a single sender to a single receiver, with the packet contents not optimized to avoid bit-stuffing (which adds extra bits and therefore decreases overall speed). So, if all you're doing on the CAN network is sending this sinewave data, you can expect to get about 8000 frames/sec * 8 bytes/frame * 1 kbyte/1024 bytes = 62.5 kilobytes per second, or 0.5 mbit per second (so, the overhead is roughly half the overall bits transmitted, which is about what you would expect given that a full CAN packet with an 11-bit identifier is 44 bits overhead + 64 bits data, plus interframe space and bit stuffing that add a few more bits).

Message 3 of 13
(3,463 Views)

I'm learning and experimenting with CAN to find out its' limitations and if it's a viable solution for transmitting 15 channels of accelerometer vibration data and 1 channel of sound level noise data. My understanding is that there is a desire to have 15 accelerometer channels of freqency and g force data to be analyzed on the receiving end. The 1 channel of sound data is to be transformed into 1/3 octaves which are transmitted utilizing 1 byte per octave. I can see how the sound level 1/3 octave data is a possiblity but I don't see a serial interface transmitting 15 channels of vibration data deterministically over a serial interface. I'm thinking of possibly performing an FFT on the 15 channels of accelerometer data and transmitting the results with a timestamp. But performing an FFT on 15 channels in parallel utilizing a cDAQ unit seems quite demanding.

I've noticed that all the CAN Xnet examples that I have looked at utilize a 100 ms loop timer in both the transmit and receive end. I'm coming to the conlclusion that determinism and parallelism is not feasable. However, maybe recording only the peak g force of each of the accelerometer channels with a timestamp may be a possibility.

0 Kudos
Message 4 of 13
(3,423 Views)

That 100ms is just to give your system time to do other things.  The frames that the hardware sees in the previous 100ms will all be queued up and ready to be read when you call the read function the next time, and each frame will have a timestamp of when that frame was seen from the hardware.  The number of frames you get after that 100ms wait is going to be determined by how many frames came in (the rate of transmission from all other nodes).

 

CAN isn't deterministic.  It has priorities, and retransmissions.  If you are looking to react to a signal within 1ms of the CAN signal being sent, you probably won't be able to (without a dedicated microcontroller).  If you are looking to capture a whole bunch of raw data, CAN can do it.  

 

Oh and also don't forget that the newer XNet cards support CAN-FD with flexible data rates and burst payload transmission, make a theoretical maximum of up to 8Mbit (with large payloads)

Message 5 of 13
(3,413 Views)

@sfrosty wrote:

What is the Maximum Sinewave Frequency that can be transmitted across High Speed CAN set to 1 Mbit and retaining maximum amplitude information (sample rate of 10 to 20 times frequency content)?

I did a little experimenting utilizing two cDAQ windows 7 embedded controllers housing a cDAQ 9826 CAN module in each and Xnet. One system configured as a transmitter and the other configured as a receiver. I contnuously transmitted 5 CAN frames 8 paylod bytes each CAN frame. Two of the bytes in one of the CAN frame payloads contained sine wave frequency data. The maximum sine wave high fidelity sinewave I was able to receive was 10 Hz without CAN frame dropouts. I had to utilize a 100 ms delay timer in both the transmit and receive loops in order to prevent CAN frame dropouts. This was a dedicated continuous transmission with nothing else connected on the bus. My input was a 100 Hz sinewave connected to a 9205 analog input module. The 9205 would start to distort the sinewave above 100Hz although the frequency was still intact. So in reality, as far as the frequencty ability of the CAN Frame transmission, it will exceed a bit above 10 Hz and still contain frequency content.


 

0 Kudos
Message 6 of 13
(3,391 Views)

Post your code, it sounds flawed.  The fact that you have a 100ms wait means you aren't using hardware timing but are forcing an update rate of no more than 10 frames per second which it sounds like why you are seeing a 10Hz limitation.

Message 7 of 13
(3,387 Views)

@Hooovahh wrote:

Post your code, it sounds flawed.  The fact that you have a 100ms wait means you aren't using hardware timing but are forcing an update rate of no more than 10 frames per second which it sounds like why you are seeing a 10Hz limitation.


Code attached. If I don't utilize the 100ms delays, I get CAN dropouts. Smiley Mad

LabVIEW 2015. Top level VI: "Third-Octave Analysis voltage in simulate accelerometer.vi"

0 Kudos
Message 8 of 13
(3,362 Views)

Thanks for posting your code.  I don't have the Sound and Vibration toolkit installed but I think I understand the CAN parts.  Frame Out Stream is the correct mode for this, and will send out the 5 frames you ask it to as fast as the hardware is able to send it out.  Just a few pointers, you could use a single for loop for generating the first 4 frames, using the array subset or delete from array, making this a bit easier to follow and will be more scaleable.

 

As for the CAN my only question is why are you using the CAN Single Shot function?  If you aren't aware what this does is force a frame to only be sent once no matter what.  CAN is pretty robust, and part of the reason it is so robust is the hardware has retransmit capability built into the transceiver.  If a frame is lost due to noise, or a higher priority frame being sent at the same time from another device, then your lower priority message will be lost, and no device on the bus will acknowledge it.  When this happens a retransmit of the message is sent until an Ack is seen.  With single transmit that message goes out once no matter what.  If the message is lost it's gone for good.  In very few situations would I suggest using this function due to the fact that dropped messages in CAN is somewhat expected.

 

So lets say we turn single shot off, (default) and we are putting new messages on the bus faster than they are being read.  Well your write queue will fill up and you will have an error.  So one technique is to read the write queue buffer (Number Of Values Pending Property on the session) and only add new messages to be written once that number goes down, meaning they have been read by the receiver.

 

Another thing to mention is that if I just look at the raw frames with a CAN device I don't think you have a way of knowing which frame is which.  It looks like you have 4 frames for the Power Octives (20 through 100, 125 through 2001, 800 through 4001, and 5000 through 20001)  And you then have one frame for the G Force.  But nothing identifies what frame is what.  If I just get a single frame I don't know if it is for the G Force, or for a Power Octive.  I'd suggest either giving a unique CAN ID to each frame, or dedicate one byte in your payload to have a value of 0 through 5 indicating what the frame contains.  The second method is called multiplexing and isn't as common in CAN as simply giving a unique ID, but both can work.

0 Kudos
Message 9 of 13
(3,351 Views)

One other thing to consider when using CAN is the medium across which the signal is sent.  CAN expects to drive a 120-ohm impedance and use cabling with a low linear capacitance and matching impedance.  You will want to place matching 120-ohm termination resistors across the CAN lines (CAN-H to CAN-L) at the source and destination of the transmission.  Using a cable similar to Beldin 9841 for optimal signal transmission would be preferred in a room-temp environment.

 

Using regular cable with no termination may cause CAN to need to retransmit.  CAN Communication Protocol will allow the device to retry transmission 3 times before throwing an error.  Any retransmit will cause havok with your throughput and waveform recreation.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 10 of 13
(3,345 Views)