Packaged vs Non-packaged Messages

The aim of this article is not to explore the topic in depth but to provide a general understanding of the differences between a packaged and non-packaged message. These are terms which I use in other articles on this website and here you can find clarification on what I mean. Roughly speaking, when talking about sending a non-packaged message, I usually mean transmitting a specific number of bytes from one device to another, with the transmitted information containing only the logical value of the message.

With the packaged messages, in addition to the logical value of the message, extra information is also sent which guarantees the recipient that there is no incorrect or random information in the received data and that the arriving data is intended specifically for the recipient.

The difference between a packaged and non-packaged message is best understood with the help of a graph. Examine the image. For the purpose of this article I have used a model representation describing a method for packaging messages, part of one of the most popular fiscal device communication module.

If you assign one letter from the alphabet to one byte and you send a device a sequence of bytes coding the message “Hello world!”, then that is a typical example of sending a 12-byte non-packaged message. If we’re dealing with a standard ESC/POS printer in non-protocol mode, then it will print out this text because its default command is to print received bytes (if they’re printable).

 

In other cases (such as when communicating with a fiscal device) we have to send a packaged message.

• You send a precisely defined byte as the start of the packaged message. This is a definite sign in the sequence of bytes received by the printer which signifies the printer may have just started receiving a message, on a precisely defined protocol at that (its own);
• After that you send a precisely defined number of bytes which tells the printer that the length of the message will be a particular number of bytes;
• After that you send a precisely defined number of bytes which tells the printer that the number of the packaged message on the sender’s side is…;
• After that you send a precisely defined number of bytes which tells the printer that the information in the message are related to command number…;
• After that you send the bytes which code “Hello world!” (this is the logical message or the so-called data area);
• After that you send a precisely defined byte which tells the printer that data transmission is over and that everything it will receive after this point is additional information related to the message;
• After that you send a precisely defined number of bytes which contain the value of a checksum - the device’s calculating the checksum will prove to it that there is no mistakenly sent data in the message and that this isn’t a random coincidence and that the data was sent by something which knows how to send messages using this exact protocol;
• The last step is to send a precisely defined byte which signifies the termination of the packaged message. The fiscal device will know that any subsequent bytes of information which it may “hear” or receive would not concern this message;

Every subsequent sequence of bytes may be a new message or static noise - the result of an eruption in the nearest star. Whatever follows, for the moment the device has received a packaged message with a command.

It’s fairly obvious that the packaged messages are larger in volume and are consequently received/processed slower in comparison with the non-packaged messages. Aside from that, they tend to make life harder for programmers. Why do they exist at all, then? One of the answers consists of the fact that the static noise from a stellar eruption isn’t a joke. If you’ve ever heard the hissing sound made by a radio when you’re not tuned in to a specific station (frequency), you should know that in 99% of cases you’ve actually heard radio noise created by accelerated solar particles decelarating in the upper layers of the atmosphere. Of course, your device may be subject to interference from various other sources, such as a nearby mobile phone sending data to a GSM cell tower. The reasons truly are numerous but whatever they may be, if your electronic device isn’t protected in some way (for example, in a hardware manner through shielding) and interprets absolutely everything it “hears” on its incoming channel, then it will probably received a sequence of bytes “meaningful” to it sooner or later and will execute a command nobody ever sent to it. Packaged messages are an additional, strong mechanism for protecting devices from unwanted noise when communicating with them. In practice, the odds of executing a “random” command are virtually zero.

If your device is located in a protected, shielded network and a controlled environment, the need for packaging messages is lessened. However… no fiscal device developed will ever consent to even the slightest chance of a fiscal transaction occurring due to static noise. Remember:

With the packaged messages, in addition to the logical value of the message, extra information is also sent which guarantees the recipient that there is no incorrect or random information in the received data and that the arriving data is meant specifically for the recipient.

The fiscal devices I write about in this series of articles on the website use packaged messages.

---

If you think anything in this article is incorrect, incomplete or insufficient, please do write to me and I will correct it.