This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCAN4550-Q1: CAN FD to WIFI gateway possibilities?!?

Part Number: TCAN4550-Q1

Dear TI,

I have a need to understand the possibilities of using CAN FD as a field bus protocol sending IMU data  through a CAN controller and forwarded through a CAN to WIFI gateway to another CAN to WIFI gateway and onward to the slave device. After it exits the wifi bridge it travels to another CAN FD controller (this one receiving masterclock from main MCU for system time stamp). Then forward to another CAN FD Controller at the slave end (apparently the hardware this CAN ports connect to at slave end has a baudrate  of 9600.

I can see you have the hardware to do it in classical CAN 2.0b.  But I’m really hoping to take advantage of the time stamp synchronisation available in the CAN FD 64bit hardware. I’m led to believe the jitter is much lower and data processing + latency adjustment are better served with this hardware than the early classical CAN 2.0b.

The major concern is getting that CAN FD data stream effectively across the Wifi gateway (can you get a can FD wifi gateway, or do you have to wrap the CAN FD in a TCP/UDP wrapper to achieve the stable low latency signal?

If I could send a data stream from one controller node over the wifi bridge to another can FD node and on to the next node at the slave, the my vision would be complete.... unfortunately I’m not away if the HW is available to attempt this design.

Any information as to its possibility would be greatly appreciated.

Many thanks for your time.

Regards

Stu

  • Hi Stu,

    I'm more knowledgeable with respect to CAN, so I will try to pull in another engineer who knows WiFi better. However, I'm not aware of any way you could directly translate CAN (or CAN FD) signaling into WiFi given the differences in both physical layer and data link layers between these standards. It seems like you would need to take the info from the CAN frame (i.e., the header/ID, the data field contents, etc.) and package it up in a compatible data format. Basically keep the links (e.g., WiFi from master to slave node, CAN FD from slave node to rest of bus) functionally independent and use a processor as a gateway between the domains. At that point I'm not sure you would get the latency improvements you want.

    Regards,
    Max
  • Hi Max,
    Thank you for the prompt reply.

    I was looking at a TI project created several years back (www.ti.com/.../tidual1.pdf).
    Page 8 got me thinking that CAN to WIFI gateway could be used in a CAN network to bridge the untethered section.
    The hope is to get IMU date sent from node 1 across the wifi to a Slave Node that instigates to data into a COTS robotic piece. The IMU data from node 1 signalling the movement in the slave. Synchronisation is of upmost importance , hence CANBus... but CAN FD with its low jitter and time stamping hardware + low latency got me pondering on the possibilities of using it.

    I understand what you’re saying about the physical layer issues, I’m just surprised a solution hasn’t been tried.

    I’d love to hear what you and the Wifi folk have to say about this possibility. It’s really the only option I can configure that won’t create vast timing and drift problems with several processors working across a network to lock the master to the mimicking slave.

    I greatly appreciate your thoughtful input and expertise. I’m in the dark as to find a better solution.

    Cheers

    Stu
  • Hi Stu,

    Unfortunately, this isn't a solution we have studied from the Wi-Fi perspective. However, if you want to evaluate it you may want to take a look at our Transceiver mode of operation on our SimpleLink Wi-Fi devices. This will be your best bet for such a system with timing constraints. It gives you a couple different options for inserting the data into different layers of the stack depending on how you need to package it and which parts of the stack you need to remain compatible with. Check out section 13 of our Network Processor User Guide.
    http://www.ti.com/lit/swru455

    Best,
    Ben M