Thursday, 5 May 2016

Software Engineering with 252117761

What's with this strange number Xel?... Well, this is a very useful number to help you determine how a remote system, or your network, is presenting numeric values.

When we program, we generally stick to one system or one platform at a time, however, life is never always so vanilla, and we've had a problem in the office today of talking to a raw network connection from a remote system.  We didn't know anything about this remote system, through a combination of lingual differences and a total lack of documentation (SNAFU).

So, we didn't know what endianess the remote processor was treating numbers as, and we also didn't know if the network was doing conversion between endian settings.

Apparently someone else had puzzled over this for a few weeks before giving up.

I however, channelled the power of the number 252117761.

What's so special about this number?... Well, it's a 32bit number, so we have four 8 bit bytes in there, and it's binary pattern is:


If you can't see the use of this pattern already in checking your networking and endieness, then you might have a problem.

It helps you check out the received values back, if you know you assign a value on one side as this integer, and we call for it across the link, we can see whether we get the above, or a change of order:


For example was the return we had, which is a change or ordering.

But you can also see whether you get:


Which is a short reordering.

Why 32 bit?... Well in this case, because we did know that the word size of the remote system was 32bits, but you can use this trick with any number of bits, just total up your values...


Might be a good 64bit pattern, and has the value 9187131167487755009.


  1. Hey Xelous! I'd like to give you a review at How about you bid on my project for a dollar, I award you and then I paste any review you write? That ought to give you a good kickstart for the site.

    1. Hi there bud, I'll get back to free-lancer later today, hope your project got somewhere... and keep coming back to these pages, I'm still trying to figure out a "best approach" to your particular technical challenge... If I solve it, I'll wrap it in a nice app/dll and explain it all here :)

    2. The project expires tonight! I haven't awarded it to anyone, so for now I'll rely on that autohotkey script. So make sure you bid for u$s1 so I award you the project and give you a nice review!

  2. So, why do you transfer 32 to 64? wouldn't it become a different value? Thank you.

    1. Why, because the remote end is an embedded system which we have complete control over, but it's a closed box which is senting rX and tX over two wires, which I'm reading off at a known baud rate, parity and stop-bit setting (it's not serial yet, but we're using serial comms as a starting point in our development of this new board). But the board we developed uses a chip designed by a company long since gone from this wet old world of ours, so we have no documentation, well beyond a simple schematic. And we have several thousand of these boards laying around for re-use.

      As for "wouldn't it become a different value"... Read the post mate, that's the point of it, we send a known value, in raw, and in a raw reply if it's changed we can determine the operation of the remote side.

    2. Oh yeah and I forgot to mention, you might use this trick to check whether a raw net socket on your TCP/IP stack is converting values endianess. Many NICs are little endian, and so you have to convert numbers sometimes; this is a good way to figure out if you have to convert or not.