I have one CAN standard 2.0A frame which contain 8 Bytes of DATA.
e.g
CAN Frame Data "00 CA 22 FF 55 66 AA DF" (8 Bytes)
Now I want to check how many stuff bits would be add in this CAN frame(bit stuffing). standers formula to calculate the Worst case bit stuffing scenario is as following:
64+47+[(34+64-1)/4] ->64 :: Data bits and 47 :: overhead bits 2.0A
How to calculate real stuffed bits in this sample CAN message ??
Any comment, suggestion would be warmly welcome.
There is no way to mathematically "calculate" the stuffed bits. You need to construct the frame (on bit level), traverse the bits, and count.
You could read more about bit stuffin at the link below.
https://en.wikipedia.org/wiki/CAN_bus#Bit_stuffing
Basic principle:
1. Contruct the can frame on bit level
2. Start at frame start bit. When 5 consecutive bits of same polarity is found than insert a bit of opposite polarity.
3. Continue to CRC delimeter (CRC delimeter is excluded)
Related
If you have a sequence of bits in CAN data:
011111000001
There will need to be a stuffed 0 after the ones, and a stuffed 1 after the 0s. But I'm not sure where the 1 should go.
The standard seems ambiguous to me because sometimes it talks about "5 consecutive bits during normal operation", but sometimes it says "5 consecutive bits of data". Does a stuffing bit count as data?
i.e.
should it be:
01111100000011
Or
01111100000101
Bit stuffing only applies to the CAN frame until the ACK-bit. In the End-Of-Frame and Intermission fields, no bit stuffing is applied.
It does not matter what is transmitted.
It is simply "after 5 consecutive bits of the same value" one complementary bit is inserted.
The second of your examples is correct. 6 consecutive bits make the message invalid.
From the old Bosch CAN2.0B spec, chapter 5:
The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing.
Meaning everything from the start of the frame to the 15 bit CRC can have bit stuffing, but not the 1 bit CRC delimiter and the rest of the frame.
Whenever a transmitter detects five consecutive bits in the bit stream to be transmitted
This "bit stream" refers to all the fields mentioned in the previously quoted sentence.
...in the actual transmitted bit stream
The actual transmitted bit stream is the original data + appended stuffing bit(s).
I'm trying to implement a deflate compressor and I have to decide whether to
compress a block using the static huffman code or create a dynamic one.
What is the rationale behind the length associated with the static code?
(this is the table included in the rfc)
Lit Value Bits
--------- ----
0 - 143 8
144 - 255 9
256 - 279 7
280 - 287 8
I thought static code was more biased towards plain ascii text, instead it
looks like it prefers by a tiny bit the compression of the rle length
What is a good heuristic to decide whether to use static code?
I was thinking to build a distribution of probabilities from a sample of the
input data and calculate a distance (maybe EMD?) from the probabilities derived
from the static code.
I would guess that the creator of the code took a large sample of literals and lengths from compressed data, likely including executables along with text, and found typical code lengths over the large set. They were then approximated with the table shown. However the author passed away many years ago, so we'll never know for sure.
You don't need a heuristic. Once you have done the work to find matching strings, it is comparatively very fast to compute the number of bits in the block for both a dynamic and static representation. Then simply pick the smaller one. Or the static one if equal (decodes faster).
I don't know about rationale, but there was a small amount of irrationale in choosing the static code lengths:
In the table in your question, the maximum static code number there is 287, but the DEFLATE specification only allows up to code 285, meaning code lengths have wastefully been assigned to two invalid codes. (And not even the longest ones either!) It's a similar story with the table for distance codes, with 32 codes having lengths assigned, but only 30 valid.
So there are some easy improvements that could have been made, but that said, without some prior knowledge of the data, it's not really possible to produce anything that's massively more efficient generally. The "flatness" of the table (no code longer than 9 bits) reduces the worst-case performance to 1 extra bit per byte of uncompressable data.
I think the main rationale behind the groupings is that by keeping group sizes to a multiple of 8, it's possible to tell which group a code belongs to by looking at the 5 most significant bits, which also tells you its length, along with what value to add to immediately get the code value itself
00000 00 .. 00101 11 7 bits + 256 -> (256..279)
00110 000 .. 10111 111 8 bits - 48 -> ( 0..144)
11000 000 .. 11000 111 8 bits + 78 -> (280..287)
11001 0000 .. 11111 1111 9 bits - 256 -> (144..255)
So in theory you could set up a lookup table with 32 entries to quickly read in the codes, but it's an uncommon case and probably not worth optimising for.
There are only really two cases (with some overlap) where Fixed Huffman blocks are likely to be the most efficient:
where the input size in bytes is very small, Static Huffman can be more efficient than Uncompressed, because Uncompressed uses a 32-bit header, while Fixed Huffman needs only a 7-bit footer, plus 1 bit potential overhead per byte.
where the output size is very small (ie. small-ish, highly compressible data), Static Huffman can be more efficient than Dynamic Huffman - again because Dynamic Huffman uses a certain amount of space for an additional header. (A practical minimum header size is difficult to calculate, but I'd say at least 64 bits, probably more.)
That said, I've found they are actually helpful from a developer's perspective, because it's very easy to implement a Deflate-compatible function using Static Huffman blocks, and to iteratively improve from there to get more efficient algorithms working.
I want to port a 32 by 32 bit unsigned multiplication on a 24-bit dsp (it's a Linear Congruential Generator, so I'm not allowed to truncate, also I don't want to replace yet the current LCG with a 24 bit one). The available data types are 24 and 48 bit ints.
Only the last 32 LSB are needed. Do you know any hacks to implement this in fewer multiplies, masks and shifts than the usual way?
The line looks like this:
//val is an int(32 bit)
val = (1664525 * val) + 1013904223;
An outline would be (in my current compiler style):
static uint48_t val = SEED;
...
val = 0xFFFFFFFFUL & ((1664525UL * val) + 1013904223UL);
and hopefully the compiler will recognise:
it can use a multiply and accumulate command
it only needs a reduced multiply algorithim due to the "high word" of the constant being zero
the AND could be effected by resetting the upper bits or multiplying a constant and restoring
...other stuff depends on your {mystery dsp} target
Note
if you scale up the coefficients by 2^16, you can get truncation for free, but due to lack of info
you will have to explore/decide if it is better overall.
(This is more an elaboration why two multiplications 24×24→n, 31<n are enough for 32×32→min(n, 40).)
The question discloses amazingly little about the capabilities to build a method
32×21→32 in fewer [24×24] multiplies, masks and shifts than the usual way on:
24 and 48 bit ints & DSP (I read high throughput, non-high latency 24×24→48).
As far as there indeed is a 24×24→48 multiply (or even 24×24+56→56 MAC) and one factor is less than 24 bits, the question is pointless, a second multiply being the compelling solution.
The usual composition of a 24<n<48×24<m<48→24<p multiply from 24×24→48 uses three of the latter; a compiler should know as well as a coder that "the fourth multiply" would yield bits with a significance/position exceeding the combined lengths of the lower parts of the factors.
So, is it possible to generate "the long product" using just a second 24×24→48?
Let the (bytes of the) factors be w_xyz and W_XYZ, respectively; the underscores suggesting "the Ws" being the lower significance bits in the higher significance words/ints if interpreted as 24bit ints. The first 24×24→48 gives the sum of
zX
yXzY
xXyYzZ
xYyZ
xZ, what is needed (fat) is
wZ +
zW.
This can be computed using one combined multiplication of
((w<<16)|(z & 0xff)) × ((W<<16)|(Z & 0xff)). (Never mind the 17th bit of wZ+zW "running" into wW.)
(In the first revision of this answer, I foolishly produced wZ and zW separately - their sum is wanted in the end, anyway.)
(Annoyingly, this is about all you can do for 24×24→24 as a base operation too - beyond this "combining multiplication", you need four instead of one.)
Another angle to explore is choosing a different PRNG.
It may have to be >24 bits (tell!).
On a 24 bit machine, XorShift* (or even XorShift+) 48/32 seems worth a look.
I have a Wi-Fi capture (.pcap) that I'm analysing and have run across what appear to me to be inconsistencies between the 802.11 spec and Wireshark's interpretation of the data. Specifically what I'm trying to pull apart is the 2-byte 802.11 Frame Control field.
Taken from http://www4.ncsu.edu/~aliu3/802.bmp, the format of the Frame Control field's subfields are as follows:
And below is a Wireshark screen cap of the packet that has me confused:
So as per the Wireshark screenshot, the flags portion (last 8 bits) of the Frame Control field is 0x22, which is fine. How the Version/Type/Subtype being 0x08 matches up with Wireshark's description of the frame is what has me confused.
0x08 = 0000 1000b, which I thought would translate to Version = 00, Type = 00 (which I thought meant management not data frame) and Subtype = 1000 (which I thought would be a beacon frame). So I would expect this frame to be a management frame and more specifically, a beacon frame. Wireshark however reports it as a Data frame. The second thing that is confusing me is where Wireshark is even pulling 0x20 from in the line Type/Subtype: Data (0x20).
Can anyone clarify my interpretation of the 802.11 spec/Wireshark capture for me and why the two aren't consistent?
The data frame in you example is 0x08 because of the layout of that byte of the frame control (FC). 0x08 = 00001000
- The first 4 bits (0000) are the subtype. 0000 is the subtype of this frame
- The next 2 bits (10) is the type, which is 2 decimal and thus a data type frame
- The last 2 bits (00) are the version, which is 0
The table below translates the hex value of the subtype-type-version byte of the FC for several frame types. A compare of the QoS data to the normal data frame might really help get this down pat. Mind you the table might have an error or two, as I just whipped it up.
You are right that 1000 is a beacon frame, you just were looking at the wrong bits.
You have a radiotap header, you can get the dec representation of the type like so from the pcap API:
int type = pkt_data[20] >> 2;
This is a common error, and has certainly bitten me several times.
It is down to the Byte Ordering.
When you have a multi-byte number to represent, the question arises as to Which byte do you put/send first ?
Natural (human) byte order is to put the big part first, then the smaller parts after it, Left-to-right, also called Big Endian. Note that the Bits in each byte are never the wrong way around from a programmers' point of view.
e.g. 1234 decimal requires 2 bytes, 04D2 hex.
Do you write/send 04 D2, or D2 04 ?
The first is Big-endian, the second is Little-endian.
To confuse it more, the mechanisms involved may use different byte-orders.
There is the Network Byte Order, in this case Little-endian, the Architecture byte order (can be different for each CPU architecture) and the data may be in a buffer, so it will vary depending on whether you read the buffer top-to-bottom, or bottom-to-top.
It doesn't help that the explanation of which bits do what can also be 'backwards', as in your original post.
I am using wireshark version-2.4.3 on windows. My capture file of dataframes is like below.
Frame control field = 0x0842 i.e., in binary format 0000 1000 0100 0010
Framecontrol flag field = 0x42.i.e., in binary format 0100 0010
So, as per my understanding the LSB 8bits in a framecontrol field will correspond to flags.
MSB 8bits will correspond to subtype, type, version i.e. in my case 0000-subtype & 10-type & 00-version.
Which is data frame of subtype 0.
It might be the error with wireshark in your case. It should dispaly frame control field as 0x0822 instead of 0x2208.
Flags field is properly displayed as 0x22.
In My case I am using wireshark-2.4.3 and display of frame control field is correct 0x0842 where flags is 0x42.
My_capture_file:
I am looking for a very memory-efficient (like max. 500 bytes of memory for lookup tables etc.) implementation of a Reed-Solomon encoder for use in an embedded application?
I am interested in coding blocks of 10 bytes with 5 bytes of parity. Speed is of little importance.
Do you know any freely available implementations that I can use for this purpose?
Thanks in advance.
Starting here:
http://www.eccpage.com/rs.c
You can pre-compute alpha_to, index_of, and gg
For the case in the example program that is 16+16+7 ints (do they need to be ints or will bytes work?) or 156 bytes
That example has 9 ints of data and 6 ints of ecc or 15 total, if these are 4 byte ints that is another 60 bytes, 216 total.
Or 54 bytes if this could be done with bytes only. I seem to remember it works with bytes.
The encoder routine itself has a modulo but you can probably replace that with an and depending on your lengths. If your embedded processor has a divide then that is probably not going to hurt you anyway. Otherwise the encoder routine is quite simple. I am thinking that you may approach 500 bytes with the tables, data, and code.
I dont remember how to get from the 9 data and 6 ecc of the example to the 10 and 5 you are looking for. Hopefully the code in the link above will give you a head start to what you are looking for.