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) ...
Related
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.
This is not a programming related question. It's a question about where to find the right documentation.
If this is not the right place to ask, please let me know and I'll move the question
I'm working on a C++-Deamon for parsing recieved BLE Advertising Packages (like hcidump from bleuz). For this I'm focusing on parsing only LE Advertising Report events (Bluetooth Core Specification 7.7.65.2, S. 2382 ff)
E. g: I need to extract the local name and the 16-bit UUID. This information can be found (if broadcasted) in the field "data".
I can extract the data part from the Advertising Event Packet (since it's described in the Core Specification how these packages are arranged) but I can't parse the data. I wasn't able to find a description of the codes used in this data frame.
I also went through the Core Specification Supplement, but I couldn’t find the corresponding codes. I only found some examples:
See Site 26: Apparently the byte 0x09 indicates that the following n bytes are the broadcasted name of the BLE-Device.
Or Site 25: 0x03 seems to indicate that a "Complete list of 16-bit Service UUIDs" is following.
So far I gained my knowledge about this by just going throught these (incomplete) list of examples I found and from looking at the source code of hcidump.c.
Now the question is: Where can I find the official complete list to those bytes/codes?
Just an example of the package content I revieve:
Respone: 04 3E 1C 02 01 04 01 55 19 19 E4 8D FE 10 0F 09 54 65 73 74
20 49 50 53 50 20 6E 6F 64 65 C5
It should be able to extract the following data
HCI Event: LE Meta Event (0x3e) plen 28
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr FE:8D:E4:19:19:55 (Random)
Complete local name: 'Test IPSP node'
RSSI: -61
After going throught the whole Bluetooth SIG, I finally found the site where these codes are described:
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/
I am new to the CAN-BUS protocol. So was going through the CAN Bus Specifications and related documents.
I have always used the CAN ID and Frame at the application level.
CANID like 0x1a1 CAN Frame like ff 22 ff 33 co 33 ee 44 (8 bytes).
In the specification, they mentioned that the Frame consists of identifier field.
I doubt what is that.
Is that the CAN ID like 0x1a1 or CAN ID + some other stuff.
No documents mentioned that clearly.
If that is not CAN ID.. Where is CAN-ID in CAN Format.
Can anyone clarify that doubt?
In short, a single CAN message consists of CANID, the CAN data and other stuffs,
https://en.wikipedia.org/wiki/CAN_bus#Data_frame
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)
I am new to the Bluetooth system and I am trying to understand the data used for the new Apple's technology : iBeacon.
There is already some nice answers which explain how it works and I have been reading everything I could find (especially the Bluetooth Specification). Still, I am missing some points and I will go for an example first : (I am using the Set Advertising Data Command, it misses here the hcitool cmd before the OGF)
0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00 00 00 00 C5 00
I will list here what I didn't understand or find information about.
Is there any information anywhere about the OGF (here it is 0x08)? I know it stands for OpCode Group Field, but contratry to the OCF which follows the OGF, I didn't find anything.
What does the 02 01 1A 1A bytes line stand for? I know that the first byte, 1E, tells the length of the rest of the data and after that line, starting with FF, you get the manufacturer specific data. But I couldn't find anything about those 4 bytes.
How does the power byte work? Here it is C5. I know that what I get is the dBm value when ranging my iBeacon (on my iPhone for instance). And I know that the higher the value (on that power byte), the higher the power which means more accuracy but also more energy consumption. But how do you use that byte? What are the min and max values you can set? Or is there any kind of formula there? Do you get a set dBm value (at one meter from your iBeacon) for a set value on the byte?
Thank you.
Answers to the first two questions can be found in the gigantic Bluetooth 4.0 Core spec.
The OGF of 0x08 groups OCF commands for LE Controllers:
For the LE Controller Commands, the OGF code is defined as 0x08.
(Bluetooth Specification Version 4.0 [Vol 2], page 1114)
Because the 0x0008 OCF command is a controller command, you have to use the 0x08 OGF code with it. Confused? Forget it. Just know you use 0x08 0x0008 to set the advertising data using hcitool.
The byte sequence starting the advertisement is as follows:
1E Number of bytes that follow in the advertisement
02 Number of bytes that follow in first AD structure
01 Flags AD type
1A Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
1A Number of bytes that follow in second (and last) AD structure
FF Manufacturer specific data AD type
4C Company identifier code LSB
00 Company identifier code MSB (0x004C == Apple)
02 Byte 0 of iBeacon advertisement indicator
15 Byte 1 of iBeacon advertisement indicator
-- Bluetooth Specification Version 4.0 [Vol 3], "ADVERTISING AND SCAN RESPONSE DATA FORMAT" p. 375
-- Bluetooth Specification Version 4.0 [Vol 3], Appendix C (NORMATIVE): EIR AND AD FORMATS", p. 401
The power field is simply a one byte two's complement number representing the "measured power" in RSSI at one meeter away. In simpler terms
Here is how that works:
Hold an iBeacon scanner (like Locate for iBeacon for iOS) one meter away from your iBeacon transmitter.
Read its signal strength in RSSI. It will be a number between -1 and -127. (-1 is very strong, -127 is very weak)
Convert this number into a hex using two's complement. (Add 256 then convert to hex)
Note: The power field can be 80-FF. If it is 00, iOS will not do a distance calculation at all. You can read more on how this is used here.