I'm looking at designing a low-level radio communications protocol, and am trying to decide what sort of checksum/crc to use. The hardware provides a CRC-8; each packet has 6 bytes of overhead in addition to the data payload. One of the design goals is to minimize transmission overhead. For some types of data, the CRC-8 should be adequate, for for other types it would be necessary to supplement that to avoid accepting erroneous data.
If I go with a single-byte supplement, what would be the pros and cons of using a CRC8 with a different polynomial from the hardware CRC-8, versus an arithmetic checksum, versus something else? What about for a two-byte supplement? Would a CRC-16 be a good choice, or given the existence of a CRC-8, would something else be better?
In 2004 Phillip Koopman from CMU published a paper on choosing the most appropriate CRC, http://www.ece.cmu.edu/~koopman/crc/index.html
This paper describes a polynomial selection process for embedded
network applications and proposes a set of good general-purpose
polynomials. A set of 35 new polynomials in addition to 13 previously
published polynomials provides good performance for 3- to 16-bit CRCs
for data word lengths up to 2048 bits.
That paper should help you analyze how effective that 8 bit CRC actually is, and how much more protection you'll get from another 8 bits. A while back it helped me to decide on a 4 bit CRC and 4 bit packet header in a custom protocol between FPGAs.
Related
I am working on an LSTM to generate music. My input data will be a BooleanTensor of size 88xLx3, 88 being the amount of available notes, L being the length of each "piece" which will be in the order of 1k - 10k (TBD), and 3 being the parts for "lead melody", "accompaniment", and "bass". A value of 0 would symbolize that that specific note is not being played by that part (instrument) at that time, and a 1 would symbolize that it is.
The problem is that each entry of a BooleanTensor takes 1 byte of space in memory instead of 1 bit, which wastes a lot of valuable GPU memory.
As a solution I thought of packing each BooleanTensor to a ByteTensor (uint8) of size 11xLx3 or 88x(L/8)x3.
My question is: Would packing the data as such have an effect on the learning and generation of the LSTM or would the ByteTensor-based data and model be equivalent to their BooleanTensor-based counterparts in practice?
I wouldn't really care about the fact that the input is taking X instead of Y number of bits, at least when it comes to GPU memory. Most of it is occupied by the network's weights and intermediate outputs, which will likely be float32 anyway (maybe float16). There is active research on training with lower precision (even binary training), but based on your question, it seems completely unnecessary. Lastly, you can always try Quantization to your production models, if you really need it.
With regards to the packing: it can have an impact, especially if you do it naively. The grouping you're suggesting doesn't seem to be a natural one, therefore it may be harder to learn patterns from the grouped data than otherwise. There'll always be workarounds, but then this answer become an opinion because it is almost impossible to antecipate what could work; an opinion-based questions/answer are off-topic around here :)
I am a little confused about the BER. I found that the BER of 16QAM is better than that of 32QAM. is this right, if so, why we go to higher QAM (i.e. 32, 64, and etc).
thank you in advance
If one would target the best BER, you wouldn't even go up to 16QAM and stick at 4QAM / QPSK. You'll have a secure transmission, with the downside of a low spectral efficiency.
16QAM can achieve a spectral efficiency of 4 Bits/s/Hz, where 64QAM has already 6 Bits/s/Hz. This means, you can increase the bitrate by 50% compared to the previous setting. This is especially important if you have limited resources like channels or bandwidth. In Wireless transmission you'll have a bandwidth of a few MHz and there's no parallel channel for other users, so spectral efficiency is the key to increase data throughput. (In fact there's something like an parallel channel, called MIMO, but you get the key)
See the table here for an overview of wireless transmission systems and their spectral efficiency. Spectral Efficiency
Even for more robust transmission systems (in case of BER) you can pick relatively high modulation grades and use the increased number of bits for redundant information. In case of a bit error the receiver is able to repair the original content. This is called Forward Error Correction
How do we use one hot encoding if the number of values which a categorical variable can take is large ?
In my case it is 56 values. So as per usual method I would have to add 56 columns (56 binary features) in the training dataset which will immensely increase the complexity and hence the training time.
So how do we deal with such cases ?
Use a compact encoding. This trades space for time, although one-hot encodings can often enjoy a very small time penalty.
The most accessible idea is a vector of 56 booleans, if your data format supports that. The one with the most direct mapping is to use a 64-bit integer, each bit being a boolean. This is how we implement one-hot vectors in hardware design. Most 4G languages (and mature 3G languages) include fast routines for bit manipulation. You will need get, set, clear, and find bits.
Does that get you moving?
I have a feedforward neural network that I want to train using a genetic algorithm. I have read that the best option is to use a binary string of the weights represented as grey codes. But in my case, with 65 weights for each chromosome, this would result in a string of length 2080 (65*32 bits). I understand that this is a complex problem, so it would take longer to reach an optimal solution than having a smaller number of bits in the string, but is 2080 too long for the GA to work at all? Is there a better way to encode such a large number of weights?
I don't think the size of the string would be too much of a problem, but it may be problem-dependent.
If you are worried about the size of the strings, perhaps you could reduce the precision to a lower number of bits per weight and observe the effects that it has on the learning performance. As you have stated, grey codes are likely best for the representation of the weights. I've used GA's in other application areas with gene sizes around the same length and have evolved well.
Of course, you would need to ensure that the population size and number of generations is sufficient enough for the problem and fitness function.
I am looking for a good algorithm for bit stream compression (packet payload compression).
I would like to avoid algorithms that are based on symbol probability. I have already tried the LZ family algorithms, and found none of them useful, even with BWT.
I am trying to accomplish a minimum compression percentage of 30%, but have only managed 3-5% using RLE.
What is a good algorithm that has a compression above 30%?
If you have no knowledge about your input data, it's hard to achieve good compression (just like a general purpose compressor).
But at least you can try some context-based model. use several prefix bits as context and predict the probability of next bit, then pass the probability to a range coder.
Further compression can be achieved with a context mixing model without byte-alignment. see http://mattmahoney.net/dc/dce.html#Section_43.