I've been playing around with a couple Arduinos and some CAN bus receiver/transmitters. Right now, I've only set it up for one to send and one to receive.
I'm starting to work on bi-directional communication, but I'm wondering how it is typically set up.
My thinking was to have each node always listen for messages, and when a node wants to send a message, I would use an interrupt. This works great for things like buttons, and I would use timer interrupts for the rest.
Is this a good way to do it or is there a better/proper way?
Related
I am writing code for a Debian 11 Linux platform that needs to control multiple 3.5kW motors using an intelligent motor controller. I started using CAN_RAW sockets since I was familiar with them from past work. However, I discovered that the timing requirements on sending certain tx messages (1200-2000 identical messages spaced at 5ms intervals) required me to use CAN_BCM mode and let the CAN hardware do the work. The motor controller doesn't reply to any of the TX_SETUP messages, it only replies to the individually sent TX_SEND messages.
The transmit side works great, I can send single or multiple messages. I don't know how to receive messages in BCM mode. I only need to receive the reply messages from the TX_SEND messages above. What setup do I need to do (if any) to receive all messages that are sent back to my Linux board? A good example is worth everything.
Thanks!
I tried calling read() and recvfrom() but I need some good documentation or an example.
Hey Stackoverflow community :)
Im looking into making a camera stream video from a an RC device into a computer using wifi.
After considering all of the options I had Im left with two:
use UDP to transfer video in packets
use packet injection and packet sniffing on the receiving device.
I was wondering what are the pros and cons of each method (for that specific purpose of video transmission)?
after looking around I found many implementations for both ways but nowhere have they specified why one is better than the other.
few things that I have not mentioned:
I know UDP does not have error correction which can make the video weird- I dont care about the quality of the video as long as it will be recognizeable.
I dont want to use connection based protocol (TPC, etc)- I dont want to wait for handshake when I get disconnected.
thanks :)
I'm trying to do a similar thing. My take on this is basically when you use the wifi cards in monitor mode (i.e. using packet sniffing/injection) you don't actually need to be connected to that network. Typically, you still need to be connected to an Access point as a client then you can communicate using UDP through that connection. But, in this case, the UDP messages are routed to the Wifi cards and the packets are injected out without being associated with any client. Then, any 'client' just has to sniff or listen on that same channel to get the transmission. So the benefit is not only does UDP not check for lost frames/etc, but also in this case you don't need to be connected to the network to get the packets.
In my case, this is preferable, since basically you will need to connect to the AP in the former case and that would require more capable hardware on the receiver side typically (more range is needed for the association part since you need to send messages back over TCP essentially to get it connected).
FYI here are the links/repos I am using and it also is a reference to what I am talking about
https://docs.px4.io/master/en/tutorials/video_streaming_wifi_broadcast.html
https://github.com/svpcom/wifibroadcast
I am using an off the shelf 'solution' in the short term, the Accsoon Cineye Air, which basically transmits HDMI 300ft line of sight over WiFi. You need an android phone to receive it, and basically I'm using the Vysor application (paid version is $40) to mirror the screen to my desktop. It works, but the latency is still more than I want : 60ms at least from the cineeye, so you can drive it around but its not as quick as DJI which is around 30-40ms ), which is my goal.
I am looking to test a scenario, how my software will respond to disconnection of a particular CAN message coming from an external device. This external device will send many CAN messages in the bus, so I cannot control it to stop just a particular message.
Therefore, I am looking for a way in CANoe just to stop one particular CAN message coming into the bus.
Please need your suggestions here.
I tried to provide as much information here, if more is require kindly put in the comment. Thanks.
You would have to split the bus into two and configure CANoe to act as a gateway:
You need a network interface with two CAN channels.
You connect your DUT to one channel (say CAN2) and the remaining bus to the other channel (CAN1).
You then configure both busses in CANoe and add a node to both busses in the simulation setup.
This node should listen to all messages received on CAN1 and output them to CAN2 and vice versa.
If you want certain messages not to reach CAN2, you have to adapt the logic of this node.
Refer to this article in the Vector knowlegde base on how to setup a gateway between two CAN busses and how to control the message flow between those busses.
I have used poll in the past where a server has multiple connected file descriptors, but how does one use poll in the case where one wants to listen in to various multicast groups? From my understanding this would entail multiple upd sockets wanting to call recvfrom after joining a group but never connecting these socket..would one just poll on these descriptors anyways and then call recvfrom when the events trigger? Is there any small simple example of this on the web?
Thanks
The polling is exactly the same - you wait for any of your several sockets to become readable, figure out which one is, and then call recv(2) or whatnot. The difference from TCP is that each read on UDP socket de-queues exactly one datagram, so this is a bit easier.
The sockets you put into poll set are usually set to non-blocking, in which case you'd need to handle EWOULDBLOCK error from recv(2).
Also remember that UDP is not reliable, so if you are not consuming those datagrams fast enough they fill socket receive buffer and kernel starts dropping them.
I am using TIdCmdTCPClient and TIdCmdTCPServer. Suddenly I find that I might like to have bi-directional communication.
What would be best? Should I possibly use some other components? If so, which? Or should I kludge and have the 'client' poll the 'server' to ask if it wishes to communciate anything?
This is a very small system. Two clients and ten servers, with a burst of one tarnscation every 30 to 60 seconds for a few minutes once a day, so overhead for polling is inconsequential.
I'm just woder if there is a 'correct' way.
Update: this really is an incredibly simple system. Very little traffic and all of it simple. All transmissions are an indication of even type an an optional single parameter.
<event type> [ <parameter>] e.g. "HERE_IS_SOME_DATA 42"
This can be sent in both directions, hover here is no "reply" as such. Just fire off a message (and hope that it got there)? Receive an Ack with no data? Non-catching of an exception indicates that message was successfully sent?)
Would it be possible (would it be overkill) to use two TIdCmdTCPServer?
Both TIdCmdTCPClient and TIdCmdTCPServer continuously poll their socket endpoints for inbound data during the lifetime of the connection. You do not have to do anything extra for that. So, as soon as a TIdCmdTCPClient connects to the TIdCmdTCPServer, both components will initially be in a reading state until one of them sends a command to the other.
Now, there is a problem with doing that - as soon as either component sends that first command, the receiving component will interpret it as a command and send back a reply, which the other component will interpret as a command and send back a reply, which will be interpretted as a command and send back a reply, and so on, causing an endless cycle of replies back and forth. For that reason, it is not wise to use TIdCmdTCPClient and TIdCmdTCPServer together. You should either use TIdTCPClient with TIdCmdTCPServer, or use TIdCmdTCPClient with TIdTCPServer. Depending on what exactly your protocol looks like, you may have to forgo using TIdCmdTCPClient and TIdCmdTCPServer altogether and just use TIdTCPClient with TIdTCPServer so you have more control over reading and writing on both ends. It is hard to answer with actual code without first knowing what the communication protocol should look like.
A single TCP socket connection can be used in two directions. The server can send data asynchronously to the client at any time. It is up to the client however to read the socket, for asynchronous processing this is done in a listener thread which reads from the socket and synchronizes incoming data operations with the main worker thread.
An example use case in the Indy components is the Telnet client component (TIdTelnet) which has a receive thread listening for server messages.
But you also asked about the 'correct' way - and then the answer depends on other factors such as network stability, guaranteed delivery and how to handle temporary server outages. In enterprise environments, one central messaging hub is preferred in many use cases, so that all parties connect only to this central server which is only responsible for reliable message delivery, and keeps messages until the recipient is available.
You can download the INDY 10 TCP server demo sample code here.