Im using MCP25625 which is MCP2515+integrated MCP2551 and trying to send messages in a loop.
For some reson I dont see any signal at all on CANH, CANL lines.
SPI communication works correctly
I use software reset procedure
There is clear 20Mhz sinewave from Crystal
There is TXCAN signal
At the moment there is nothing at all connected to CANL,CANH, just the probe.
I also tried to run in LOOPBACK mode and it works, but in the NORMAL modethere is nothing coming out.
Seems like transciever is broken? I changed 2 chips already, so it shouldnt be the problem.
Any suggestion guys?
Schematics
have you considered the modes of operation of the CAN transceiver?
In your schematic, the pins value is not clear.
If you have connected it to the MCU, Please pull it to LOW to select the normal operation mode for the transceiver (it is different configuration then the CAN controller settings, hence might cause some confusion!).
Controlling it by MCU is a good choice as it gives more control to prevent network communication from being blocked, due to a CAN controller which is out of control.
Else, connect it to ground to ensure normal operation mode specifically for the build in transceiver.
I have referred the data-sheet's of MCP25625, MCP2515 and TJA1050 to bring out this conclusion.
TJA1050 has pin-S for selecting high-speed mode and silent mode. Both modes are similar to normal mode and standby mode respectively of the transceiver of MCP25625.
Also, pin-S configuration in TJA1050 is similar to pin-STBY configuration in MCP25625.
0(LOW) for high-speed/normal mode of TJA1050/MCP25625-Transceiver
1(HIGH) for silent/standby mode of TJA1050/MCP25625-Transceiver
Hope this helps.
At the moment there is nothing at all connected to CANL,CANH, just the probe.
Hope you have connected the termination resistor? It is on the schematic, but ...
Related
I am making a CAN simulator for GPS trackers, they only record CAN data and doesn't send ACK. Is it possible to send CAN data with raspberry, using mcp2515/tja1050, without any device on bus that would trigger ACK?
This will usually generate a continuous retransmit.
Some devices have a "one-shot" transmit mode when just sends the CAN frame and does not attempt a retransmission. If you transmitter has this mode you can do what you describe, otherwise you will get a lot of retransmissions.
No it isn't possible, you need at least 2 nodes that are actively participating in the communication. This can however be fixed by just providing another CAN controller on the bus, which doesn't have to do anything intelligent except the ACK part.
For development/debug/test purposes you can however put your own node in "loopback mode", meaning it will speak to itself. Can be handy if you have to proper hardware available yet.
You can try to set the controlmode presume-ack to on.
Assuming you are using the ip command for creating your can sockets that would be something like
ip link set <DEVICE> type can presume-ack on
This will ignore missing ACKs. However I am not sure whether this works with all controllers.
I created a custom topology in mininet and added flows rules to the switches. I can ping the hosts but cannot see the topology on DLUX. I tried with other topology such as single and linear, these work fine. I do not understand what is the problem with the custom topology. If someone could shed some light.
try restarting ODL, like this person is doing. I would be suspect that
you are hitting some bug in the l2switch project. But, you can debug further
by inspecting the flows on each switch in your custom topology. Each switch
should have a flow with dl_type=0x88cc that punts to the CONTROLLER. Those
are the LLDP packets, which is how ODL will learn the links, which in turn
is how DLUX will paint them in your GUI. If the flows aren't there, then
you would want to try to figure out why? maybe the switches are ignoring
the flow programming (check switch logs), or maybe the flows are not even
being sent (you could check ODL logs, or even do a tcpdump to see if
openflow rules are being sent to the switch). If the flows are being
programmed, and the LLDP packets are being punted to ODL then the problem
could be internal to ODL and DLUX.
To be fair, DLUX is a stale project that is slated for removal. There
may be bugs you are hitting.
It's strange that I can ping all of a sudden now without making any changes. I have faced this problem earlier too, where the controller doesn't work for a week or so and then starts running suddenly.
the problem is not from ODL but it's from OVS switch u need to this script for your switch controller
sudo ovs-vsctl set bridge s1 protocols=OpenFlow13
http://kspviswa.github.io/Installing-ODL-BE.html
When flight testing in the room, the flight controller's GPS is lost and it automatically switches to A mode. At this time, data can not be sent using "sendVirtualStickFlightControlData" method. The connection with the transmitter has not expired.
Although data transmission outdoors was successful, I do not know the reason why indoor communication does not go well.
Data can only be sent when the aircraft status indicator is flashing green light slowly.
Is there a relationship with GPS when doing data communication?
The drone you are using is "Phantom 3 standard".
MobileSDK
Virtual stick definitely works indoors.
It seems that the main culprit is wireless interferences.
For a P3 standard, you are looking at wifi interferences.
It's a real issue when working in indoor dev environment.
You can check if there is a lot of wifi network with any wifi diagnostic application like this app on Android: https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer&hl=en
Now for solution, the best of best is a conductive setup, but it's really not trivial to do and will void your warranty.
Non-intrusive solution would be controlling the bands (keeping your wifi at 5Ghz, leave 2.4 free for the P3). This could help but doesn't guarantee to solve it all.
I hope this helps.
I am working with openmote-cc2538 for the project: https://github.com/cetic/6lbr/wiki
Here when I was trying to flash openmote with this command
sudo make TARGET=cc2538dk BOARD=openmote-CC2538 bootload0/dev/ttyUSB0 slip-radio.upload
This error message is displayed
ERROR:Cant CONNECT TO TARGET:Ensure bootloader is started(no answer on sync sequence)
cc2538 bsl.py script is available for uploading binary to openmote. But I don't have much experience about this. Can anybody give me some suggestions regarding how to proceed??
Grab a scope and probe different digital I/O pins on the CC2538. Typically a bootloader will initialize all the ports on the chip and you will see them change state, which is an indication that the bootloader is indeed running. I would guess one of the LEDs would change state as well (which doesn't require a scope).
I'm building an application that uses TCP sockets to communicate. I want to test how it behaves under slow-speed conditions.
There are similar question on the site, but as I understand it, they deal with HTTP traffic, or are about Linux. My traffic is not HTTP, just ordinary TCP sockets, and the OS is Windows.
I tried using fiddler's setting for Modem Speed but it didn't work, it seems to work only for HTTP connections.
While it is true that you probably want to invest in an extensive set of unit tests, You can simulate various network conditions using VMWare Workstation:
You will have to install a virtual machine for testing, setup bridged networking (for the vm to access your real network) and upload your code to the vm.
After that you can start changing the settings and see how your application performs.
NetLimiter can also be used, but it has fewer options (in your case, packet loss is very interesting to test and is not available in netlimiter).
There is an excellent utility for Windows that can do throttling and much more:
https://jagt.github.io/clumsy/
I think you're taking the wrong approach here.
You can achieve everything that you need with some well designed unit tests. All of the things that a slow network link causes can be simulated in a unit test environment in controlled conditions.
Things that your code MUST handle to deal with "slow" links are just things that you should be dealing with anyway, including:
The correct handling of fragmented messages. All of your network reading code needs to correctly assume that each read will return between 1 byte and the size of your read buffer. You should never assume that you'll get complete 'messages' as TCP knows nothing of your concept of messages.
TCP flow control causing either your synchronous sends to fail with some form of 'try later' error or your async sends to succeed and potentially use an uncontrolled amount of resources (see here for more details). Note that this can happen even on 'fast' links if you are sending faster than the receiver is consuming.
Timeouts - again this isn't limited to "slow" links. All of your timeout handling code should be robust and tested. You may want to make sure that any read timeout is based on any read completing rather than reading a complete message in x time. You may be getting your data at a slow rate but whilst you're still getting data the link is alive.
Connection failure - again not something specific to "slow" links. You need to know how you deal with connections being reset at any time.
In summary nothing you can achieve by running your client and server on a simulated slow network cannot be achieved with a decent set of unit tests and everything that you would want to test on such a link is something that could affect any of your connections on any speed of link.