This is a decoder for information encoded with USCII-5x7-ENGLISH-C0. Type (or paste) some hexadecimal notation for the bytes in the box. An explanation will appear, but you can also read information on the USCII homepage to learn more.
If you don't have anything in this format, then you can try the encoder to generate something. It also does a pretty good job of narrating the encoding process to explain what this is all about!
Success: ASCII conversion is characters long.
How did the decoding work?
Well, first let's look at what happens when we convert the hexadecimal to binary, and see what patterns we can notice.
The binary format of your message started with seven chunks of 40-bit ranges of zero, and five 40-bit ranges of one at the tail. You wouldn't necessarily notice the significance of the numbers five and seven from those series of bits alone. However, it provides enough context to see that between this "silence" is a kind of structure, with blocks of 35 bits (which may be zero or one) interleaved with 5 bits that are zero.
Setting up the context for realizing these gaps are significant is the fact that after the silence, a signal seems to be bookended by 5 solid 35-bit blocks at the beginning, and 7 solid 35-bit blocks at the end. By this point, we might be cued that 35 is a semiprime number (product of two primes). Thus we can see that the numbers 5 and 7 are supposed to be significant.
If we consider those factors as dimensions of a rectangle, then we can convert the chunks between the solid blocks and what's between them into 5x7 bitmaps:
Ignoring the solid blocks (the "meter"), we can read the message even before we've converted it into ASCII!
But being able to read it isn't the only requirement for a safe ASCII conversion. The specific numbers must be looked up in a standard table, to produce the string. In this case, all the numbers matched our table...so your message could be decoded. It could thus also be drawn in a stroked vector font (for instance).