I need to send a frame from can0 to can1 and vice versa.
So, first I log candump output to a file like this: candump can1 -n 1 > /tmp/CANDUMP &
Then I send the frame: cansend can0 128#00FF00FF00FF00FF
It only works if I send a frame from can1 to can1 or can0 to can0... Wonder why?
It only works if I send a frame from can1 to can1 or can0 to can0... Wonder why?
cansend command takes 2 arguments. The first one is can-device ID, here the device is on which you want to send the data which means cansend can0 will publish the data on the canbus 0 on your system.
If you want to send data from can0 to can1 you can physically connect them to the same bus.
Related
I have a rosbag file, which has recorded messages of several topics.
Is there a way I can know the frequency at which the messages of a particular topic were published (and recorded)?
when I do rosbag info I get something like
path: the.bag
version: 2.0
duration: 60.0s
start: Jul 01 2021 16:58:10.27 (1625158690.27)
end: Jul 01 2021 16:59:10.27 (1625158750.27)
size: 6.1 GB
messages: 37131
compression: none [1188/1188 chunks]
types: sensing_msgs/type1 [621fdfebbc8899ba27ee5fed4fcccaee]
sensing_msgs/type2 [cf69c51b4a51518b0ef7e36af744fc70]
sensor_msgs/Image [060021388200f6f0f447d0fcd9c64743]
topics: /mycamera/image 1187 msgs : sensor_msgs/Image
/mymessage1 29944 msgs : sensing_msgs/type1
/mymessage2/input 6000 msgs : sensing_msgs/type2
If you know message publication is continuous throughout the recording frequency is just total_messages / time. Otherwise you can get frequency via rosbag play <bag_file> and rostopic hz <topic_name>
I'm writing a CAN driver and want to set up some tests for it. I have a simple echo program (accepts a can frame and echoes it back). I'm using can-utils for this and would use cangen to generate random data, log it, then make sure the frames were received and echoed back.
Everything seems to be working but there is some annoying behavior from candump. When sending non-FD frames, it does not print a leading zero for the DLC. See here (messages are sent, and then the echoed message - yes I'm aware it shouldn't use the same node id to echo back this is just for testing purposes):
candump can0
#can FD frames (11 and 29 bit ids)
can0 033FABCD [04] DE AD BE EF #sent
can0 033FABCD [04] DE AD BE EF #echoed
can0 277 [04] DE AD BE EF
can0 277 [04] DE AD BE EF
#non-FD frames sent (11 and 29 bit ids)
can0 277 [4] DE AD BE EF #sent
can0 277 [04] DE AD BE EF #echoed
can0 077AFFFF [4] DE AD BE EF
can0 077AFFFF [04] DE AD BE EF
Both FD and non-FD frames have a 4 bit DLC so I'm not sure why it'd be printed differently. We are only sending FD so the echoed frame is in FD format and gets a leading zero printed.
Obviously I can work around this but the behavior is kind of annoying. Does anyone know what might be wrong here?
No this is intentional to distinguish Classic CAN [x] from CAN FD [xx] frames in the human readable output. It is not the question whether the DLC (4 bit on the physical layer) to be the same, as we always operate with the real length information and not with the DLC on socket level. And when both are 5 bytes you wont be able to distinguish them.
Btw. your CAN driver seems to have an issue, when the echo'ed frame is always a CAN FD type - no matter what has been sent (Classic CAN / CAN FD) ...
Trying to replay CAN codes for 2018 Dodge Promaster using can-utils. From what I've read they use an 11 bit CAN ID. However when I use:
candump -L can0 > can.log
The log shows 29 bit ID's
(1519238827.107818) can0 04394100#00000000F0006000
(1519238827.122395) can0 063D4000#4652000080FE0000
(1519238827.126761) can0 04394000#000000AB
(1519238827.147822) can0 03029000#0000000000000000
(1519238827.152676) can0 06254000#00FFFF00FFFFFF00
(1519238827.157823) can0 03029100#0000000000000000
(1519238827.207842) can0 04394100#00000000F0006000
(1519238827.222727) can0 06314000#0000000000000000
(1519238827.226953) can0 04394000#000000AB
(1519238827.244633) can0 0E094000#001A00000409
(1519238827.247843) can0 03029000#0000000000000000
(1519238827.249614) can0 0E094003#001A
(1519238827.251375) can0 0E094020#000A
(1519238827.253121) can0 0E09400A#001A
(1519238827.254935) can0 0621400A#0000
(1519238827.257940) can0 03029100#0000000000000000
(1519238827.262128) can0 06314020#100000BC
I'm thinking this is why replaying with canplayer is not working. Does anyone know how I can force candump to use 11 bit ID's?
You cannot force candump into using 11 bits IDs as the frame format is defined by a bit in the arbitration field (cf. Wikipedia - CAN bus, "Data frame" sub-section). After a quick look at the article you linked, I saw that the car model is from the 2000s and your car is from 2018. Many changes have probably been made in the meantime.
In conclusion: your problem isn't one, it's your article that is too old and doesn't match your car.
You can use candump command with filter option as per below:
Up to 16 CAN interfaces with optional filter sets can be specified
on the commandline in the form: <ifname>[,filter]*
Comma separated filters can be specified for each given CAN interface:
<can_id>:<can_mask> (matches when <received_can_id> & mask == can_id & mask)
<can_id>~<can_mask> (matches when <received_can_id> & mask != can_id & mask)
#<error_mask> (set error frame filter, see include/linux/can/error.h)
[j|J] (join the given CAN filters - logical AND semantic)
CAN IDs, masks and data content are given and expected in hexadecimal values.
When can_id and can_mask are both 8 digits, they are assumed to be 29 bit EFF.
Without any given filter all data frames are received ('0:0' default filter).
Use interface name 'any' to receive from all CAN interfaces.
Examples:
candump -c -c -ta can0,123:7FF,400:700,#000000FF can2,400~7F0 can3 can8
candump -l any,0~0,#FFFFFFFF (log only error frames but no(!) data frames)
candump -l any,0:0,#FFFFFFFF (log error frames and also all data frames)
candump vcan2,92345678:DFFFFFFF (match only for extended CAN ID 12345678)
candump vcan2,123:7FF (matches CAN ID 123 - including EFF and RTR frames)
candump vcan2,123:C00007FF (matches CAN ID 123 - only SFF and non-RTR frames)
So I need to print out an individual iphone app's memory usage for a soak test. It would help greatly if there was a stored log monitoring usage against time (ran periodically within the automated test).
To do this I've jailbroken the iPhone and installed mobile terminal. My plan was to use top -p to filter out the rest of the processes and then pipe out the output to a log file. Then the data could be reclaimed at a later date and analysed.
Unfortunately, when I run for PID 616:
top -p 616
then all I get is 616 printed off multiple times:
Processes: 77 total, 1 running, 5 stuck, 71 sleeping... 335 threads 02:38:09
Load Avg: 1.23, 0.93, 0.90 CPU usage: 3.33% user, 0.00% sys, 96.67% idle
SharedLibs: num = 0, resident = 0 code, 0 data, 0 linkedit.
MemRegions: num = 0, resident = 0 + 0 private, 0 shared.
PhysMem: 108M wired, 152M active, 39M inactive, 497M used, 519M free.
VM: 28G + 0 904390(0) pageins, 32065(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
616
616
616
616
616
616
616
616
616
616
616
616
616
616
616
616
616
616
I've looked around, and it seems that the flags on the top for iphone are slightly different but I can't find a specific description. Can anyone show me how to print out the data just for one process?
Thanks.
If you want to find out the proper command line switches for top, or anything else, try something like this:
>> top --help
You will see, however, that the PID (-p) switch isn't supported in the version for jailbroken iOS.
However, if you use this:
>> top -l 2 | grep 616
It should give you what you need (in the second line of output). The -l switch gives you N samples. You need at least 2, because top calculates CPU% as a delta between samples, so with only 1 sample, it will always be 0%. If you only need memory usage, though, you can probably use:
>> top -l 1 | grep 616
Using just top | grep 616 doesn't work, because it runs continuously. You probably just want a single value, and then should let top exit.
Note: you'll probably need to install grep from Cydia, also. Just search for grep. It's a package published by Saurik.
Warning: because you're using grep to search for the right PID, you may need to have your code that parses the log file validate its log input. The right output will be in the file, but if the numeric PID matches any other lines, also, you'll get additional data. For example, if the PID you search for also happens to be the number of MB of memory used by another process, you'll get additional lines of output. The first column in your file, however, will always be the PID.
I am currently trying to connect my DIY DC77 clock to ntpd (using Ubuntu). I followed the instructions here: http://wiki.ubuntuusers.de/Systemzeit.
With ntpq I can see the DCF77 clock
~$ ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+dispatch.mxjs.d 192.53.103.104 2 u 6 64 377 13.380 12.608 4.663
+main.macht.org 192.53.103.108 2 u 12 64 377 33.167 5.008 4.769
+alvo.fungus.at 91.195.238.4 3 u 15 64 377 16.949 7.454 28.075
-ns1.blazing.de 213.172.96.14 2 u - 64 377 10.072 14.170 2.335
*GENERIC(0) .DCFa. 0 l 31 64 377 0.000 5.362 4.621
LOCAL(0) .LOCL. 12 l 927 64 0 0.000 0.000 0.000
So far this looks OK. However I have two questions.
What exactly is the sign of the offset? Is .DCFa. ahead of the system clock or behind the system clock?
.DCFa. points to refclock-0 which is a DIY DCF77 clock emulating a Meinberg clock. It is connected to my Ubuntu Linux box with an FTDI usb-serial adapter running at 9600 7e2. I verified with a DSO that it emits the time with jitter significantly below 1ms. So I assume the jitter is introduced by either the FTDI adapter or the kernel. How would I find out and how can I reduce it?
Part One:
Positive offsets indicate time in the client is behind time on the server.
Negative offsets indicate that time in the client is ahead of time on the server.
I always remember this as "what needs to happen to my clock?"
+0.123 = Add 0.123 to me
-0.123 = Subtract 0.123 from me
Part Two:
Yes the USB serial converters add jitter. Get a real serial port:) You can also use setserial and tell it that the serial port needs to be low_latency. Just apt-get setserial.
Bonus Points:
Lose the unreferenced local clock entry. NO LOCL!!!!