I'm stuck trying to format a MIDI Sys Ex message that a device keeps rejecting as invalid. The problem is a section of the message that involves a type of data encoding described below.
According to the manual,
the device "will encode/interpret a consecutive group of 4-bytes"
Byte #0 - b31b30b29b28b27b26b25b24
Byte #1 - b23b22b21b20b19b18b17b16
Byte #2 - b15b14b13b12b11b10b09b08
Byte #3 - b07b06b05b04b03b02b01b00
as the following 5 consecutive SysEx bytes:"
Byte #0 - 0 b06b05b04b03b02b01b00
Byte #1 - 0 b13b12b11b10b09b08b07
Byte #2 - 0 b20b19b18b17b16b15b14
Byte #3 - 0 b27b26b25b24b23b22b21
Byte #4 - 0 0 0 0 b31b30b29b28
where "b" is the bit number. Notice the bit numbering has been flipped. Which way are you supposed to read the bits? MIDI data is, by convention, reverse bit ordered (MSB=7), if that helps. Also, the manual notes that "all data types are in Motorola big-endian byte order."
Here's a description of the message I'm trying to format correctly -
"A command will allow a consecutive group of one to four bytes to be edited. When 3 or less bytes are specified the device expects the Parameter Value field to be bit ordered as if it was performing a full 32-bit (4 byte) parameter change. For example, when editing a two byte parameter, Byte #0 will occupy the bit range of b24-b31, while Byte #1 will occupy bits b16-b23. The remaining bits (b00-b15) in the parameter value field should be set to zero."
bb Parameter Offset - 0 b06b05b04b03b02b01b00
bb Parameter Offset - 0 b13b12b11b10b09b08b07
bb Parameter Offset - 0 b20b19b18b17b16b15b14
bb Parameter Offset - 0 b27b26b25b24b23b22b21
bb Parameter Offset - 0 0 0 0 b31b30b29b28
0b Parameter Byte Size (1 to 4)
00
00
00
00
bb Parameter Value - 0 b06b05b04b03b02b01b00
bb Parameter Value - 0 b13b12b11b10b09b08b07
bb Parameter Value - 0 b20b19b18b17b16b15b14
bb Parameter Value - 0 b27b26b25b24b23b22b21
bb Parameter Value - 0 0 0 0 b31b30b29b28
So, when trying to enter offset values of 15H, 16H, 17H, and 18H, with respective values of let's say 00, 01, 02, 03 respectively, how would I encode those hex values, or do I even need to encode them? If I do need to, which direction do I write the bits so the binary values are correct?
When written, the order of bits in a byte is always big-endian, i.e., MSB first.
This can be confirmed by the fact that the MSB must be zero for data bytes.
Four bytes:
15h -> 00010101
16h -> 00010110
17h -> 00010111
18h -> 00011000
SysEx bytes:
0 0011000 -> 18h
0 0101110 -> 2eh
0 1011000 -> 58h
0 0101000 -> 28h
0000 0001 -> 01h
Four bytes:
01 -> 00000001
02 -> 00000010
03 -> 00000011
04 -> 00000100
SysEx bytes:
0 0000100 -> 04h
0 0000110 -> 06h
0 0001000 -> 08h
0 0001000 -> 08h
0000 0000 -> 00h
The basic approach to this conversion is to combine the four 8-bit values into a 32-bit value and then successively move the least significant seven bits into five bytes. Here's a sample program that does what you need.
#include <stdio.h>
#include <stdint.h>
void convert(uint8_t byte0, uint8_t byte1, uint8_t byte2, uint8_t byte3, uint8_t *outBytes) {
uint32_t inBytes = byte0 << 24 | byte1 << 16 | byte2 << 8 | byte3; //combine the input bytes into a single 32-bit value
for (int i = 0; i < 5; i++) {
outBytes[i] = inBytes & 0x7F; //Copy the least significant seven bits into the next byte in the output array
inBytes >>= 7; //Shift right to discard the seven bits that were copied
}
}
void printByteArray(uint8_t *byteArray) {
for (int i = 0; i < 5; i++) {
printf("Byte %d: %02xh\n", i, byteArray[i]);
}
printf("\n");
}
int main(int argc, char *argv[]) {
uint8_t sysExBytes[5]; //Five bytes to contain the converted SysExData
convert(0x15, 0x16, 0x17, 0x18, sysExBytes);
printByteArray(sysExBytes);
convert(0x00, 0x01, 0x02, 0x03, sysExBytes);
printByteArray(sysExBytes);
return 0;
}
Output:
Byte 0: 18h
Byte 1: 2eh
Byte 2: 58h
Byte 3: 28h
Byte 4: 01h
Byte 0: 03h
Byte 1: 04h
Byte 2: 04h
Byte 3: 00h
Byte 4: 00h
Your question is a bit confusing. 1 byte is 8 bits, therefore the following lines:
Byte - #0 b31b30b29b28b27b26b25b24
Byte - #1 b23b22b21b20b19b18b17b16
Byte - #2 b15b14b13b12b11b10b09b08
Byte - #3 b07b06b05b04b03b02b01b00
Do not make sense to me. The first line #0 has 8 bytes in it. I did some searching and this is a better explanation (http://www.music.mcgill.ca/~ich/classes/mumt306/midiformat.pdf). Taking the contents from page 2 and editing them for clarity.
Offset | Byte 0 | Byte 1 | Byte 2 | Byte 3
-------- bits | 24-31 | 16-23 | 8-15 | 0-7
00000000 | 00 | | |
00000040 | 40 | | |
0000007F | 7F | | |
00000080 | 81 | 00 | |
00002000 | C0 | 00 | |
00003FFF | FF | 7F | | <--- example
00004000 | 81 | 80 | 00 |
00100000 | C0 | 80 | 00 |
001FFFFF | FF | FF | 7F |
00200000 | 81 | 80 | 80 | 00
08000000 | C0 | 80 | 80 | 00
0FFFFFFF | FF | FF | FF | 7F
Example at offset 3FFF
Hex format 0xFF7F_0000 (32-bit number, unused bits are 0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Does this help?
Related
I have the following truth table (a and b being my inputs and r the result):
a
b
r
00
00
00
00
01
01
00
11
01
01
00
01
01
01
01
01
11
01
11
00
01
11
01
01
11
11
11
The issue is that I can't find the boolean expression to express this truth table.
Another similar thread pointed out that karnaugh maps could solve it, but I can't find any implementation working with several bits inputs.
Note that to my model, the second bit doesn't matter is the first one is set for a specific input, thus if it facilitates the boolean expression, I can force it to 0, to 1, or not even force it.
Truth Table (given):
a0 a1 b0 b1 r0 r1
0 0 0 0 0 0
0 0 0 1 0 1
0 0 1 1 0 1
0 1 0 0 0 1
0 1 0 1 0 1
0 1 1 1 0 1
1 1 0 0 0 1
1 1 0 1 0 1
1 1 1 1 1 1
Kmaps:
r0:
\a0a1
b0b1 \ | 00| 01 11 10
00 | 0 | 1 1 1
---
01 1 1 1 1
11 1 1 1 1
---
10 | x | x x x
| |
r1:
\a0a1
b0b1 \ 00 01 11 10
00 0 0 0 0
01 0 0 0 0
---
11 0 0 | 1 | 0
| |
10 x x | x | x
---
Boolean Expressions:
r0 = a0 + a1 + b1
r1 = a0a1b0
we have a requirement to make our serial numbers Base 36 (0-9,A-Z). My initial thought was store the counter in decimal and convert to hex only when required for display. This makes the counting simple, however there is another requirement to not use I or O because it'll be confused with 1 and 0 on the barcodes human readable portion. This makes it a bit of a nightmare.
Language is unimportant, but the counter itself will be held in SQL Server 2012+.
Anyone have any experiences with this problem?
Edit:
I've rewritten a method I found to test in C#. It allows any string of base characters to be passed in.
ie. string baseChars = "0123456789ABCDEFGHJKLMNPQRSTUVWXYZ";
It's not pretty but its a start!
private string GetCustomBase(int iValue, string baseChars)
{
int baseNum = baseChars.Length;
int value= iValue;
string result = "";
while( value > 0 )
{
result = baseChars[ 0 + (value % baseNum)] + result;
value = value / baseNum;
}
return result;
}
private int GetDecimal(string strValue, string baseChars)
{
int baseNum = baseChars.Length;
string strAmendedValue = strValue;
int iResult = 0;
//Each char one at a time (from right)
for (int i = 0; i < strValue.Length; i++)
{
string c = strValue.Substring(strValue.Length - i -1, 1);
int iPos = baseChars.IndexOf(c); //get actual value (0 = 0, A = 10 etc.)
int iPowerVal = (int)Math.Pow((double)baseNum, (double)(i));
iResult = iResult + (iPowerVal * iPos);
}
return iResult;
}
An implementation of the suggestion in the question comments. As language is unimportant, here's a Ruby version:
class Integer
def to_34_IO_shifted
to_s(34).upcase.tr("IJKLMNOPQRSTUVWX", "JKLMNPQRSTUVWXYZ")
end
end
class String
def from_34_IO_shifted
upcase.tr("JKLMNPQRSTUVWXYZIO", "IJKLMNOPQRSTUVWX10").to_i(34)
end
end
puts 170.times.map { |x| x.to_34_IO_shifted }.join(' ')
x = 73644
x34 = x.to_34_IO_shifted
x10 = x34.from_34_IO_shifted
puts "\n#{x} -> '#{x34}' -> #{x10}"
puts "'10' -> #{'10'.from_34_IO_shifted}"
puts "'IO' -> #{'IO'.from_34_IO_shifted}"
Output:
0 1 2 3 4 5 6 7 8 9 A B C D E F G H J K L M N P Q R S T U V W X Y Z 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 1G 1H 1J 1K 1L 1M 1N 1P 1Q 1R 1S 1T 1U 1V 1W 1X 1Y 1Z 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 2G 2H 2J 2K 2L 2M 2N 2P 2Q 2R 2S 2T 2U 2V 2W 2X 2Y 2Z 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 3G 3H 3J 3K 3L 3M 3N 3P 3Q 3R 3S 3T 3U 3V 3W 3X 3Y 3Z 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 4G 4H 4J 4K 4L 4M 4N 4P 4Q 4R 4S 4T 4U 4V 4W 4X 4Y 4Z
73644 -> '1VQ0' -> 73644
'10' -> 34
'IO' -> 34
EDIT: made it so that I and O are interpreted as 1 and 0, in case someone does misread it.
I have been working on viterbi decoder in matlab2009 on simple 1/2 rate convolutional encoder.
Here is my code
trel = poly2trellis(3,[7 5]);
msg = [ 0 1 0 1 1 1 0 0 1 0 1 0 0 0 1 ];
code = convenc(msg,trel);
% Traceback Length
tblen = 5;
ucode = real(awgn(1-2*code,tblen,'measured'));
dcd = vitdec(ucode,trel,tblen,'cont','unquant');
According to this input code
i am getting the code = 00 11 10 00 01 10 01 11 11 10 00 10 11 00 11
which is correct
but talking about the dcd which is output after viterbi decoder is coming incorrect
i.e 000000101110010. which is far different from my msg input.
guide me where i am going incorrect
The decoded output depends on the type of opmode Input you selected.
In case of cont, there is a delay in the output equal to tblen number of symbols whereas there are 'term' and trunc modes as well.
You can compare the initial msg(1,end-tblen) symbols with dcd(1,tblen+1:end). They are same!
You may check vitdec at Matlab help.
I need to know what tm->when means, but proc(5) doesn't mention anything helpful,
So, does it store the creation time of the socket? The number seems to be decreasing each time I view the file.
root#ubuntu-vm:~# cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:0CEA 00000000:0000 0A 00000000:00000000 00:00000000 00000000 104 0 17410 1 dddb6d00 100 0 0 10 -1
1: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 7959 1 dddb4500 100 0 0 10 -1
2: B238A8C0:0016 0138A8C0:9C96 01 00000000:00000000 02:00061444 00000000 0 0 8243 4 daa3c000 20 4 27 10 16
3: B238A8C0:0CEA 0138A8C0:8753 01 00000000:00000000 02:0009C787 00000000 104 0 19467 2 daa3e300 20 4 18 10 -1
From Exploring the /proc/net/ Directory
The tr field indicates whether a timer is active for this socket. A value of zero indicates the timer is not active. The tm->when field indicates the time remaining (in jiffies) before timeout occurs.
Which of the following give back 63 as long (in Java) and how?
0x0
0x1
0x2
0x4
0x8
0x10
0x20
I'm working with NetworkManager API flags if that helps. I'm getting 63 from one of the operations but don't know how should I match the return value to the description.
Thanks
63 is 32 | 16 | 8 | 4 | 2 | 1, where | is the binary or operator.
Or in other words (in hex): 63 (which is 0x3F) is 0x20 | 0x10 | 0x8 | 0x4 | 0x2 | 0x1. If you look at them all in binary, it is obvious:
0x20 : 00100000
0x10 : 00010000
0x08 : 00001000
0x04 : 00000100
0x02 : 00000010
0x01 : 00000001
And 63 is:
0x3F : 00111111
If you're getting some return status and want to know what it means, you'll have to use binary and. For example:
if (status & 0x02)
{
}
Will execute if the flag 0x02 (that is, the 2nd bit from the right) is turned on in the returned status. Most often, these flags have names (descriptions), so the code above will read something like:
if (status & CONNECT_ERROR_FLAG)
{
}
Again, the status can be a combination of stuff:
// Check if both flags are set in the status
if (status & (CONNECT_ERROR_FLAG | WRONG_IP_FLAG))
{
}
P.S.: To learn why this works, this is a nice article about binary flags and their combinations.
I'd give you the same answer as Chris: your return value 0x63 seems like a combination of all the flags you mention in your list (except 0x0).
When dealing with flags, one easy way to figure out by hand which flags are set is by converting all numbers to their binary representation. This is especially easy if you already have the numbers in hexadecimal, since every digit corresponds to four bits. First, your list of numbers:
0x01 0x02 0x04 ... 0x20
| | | |
| | | |
V V V V
0000 0001 0000 0010 0000 0100 ... 0010 0000
Now, if you take your value 63, which is 0x3F (= 3 * 161 + F * 160, where F = 15) in hexadecimal, it becomes:
0x3F
|
|
V
0011 1111
You quickly see that the lower 6 bits are all set, which is an "additive" combination (bitwise OR) of the above binary numbers.
63 (decimal) equals 0x3F (hex). So 63 is a combination of all of the following flags:
0x20
0x10
0x08
0x04
0x02
0x01
Is that what you were looking for?