(Last Mod: 27 November 2010 21:37:21 )
The BBC Processing Engine is capable of reading and writing files in several different types of files in several different formats. All of the files can be segregated into one of five categories - command, codec, packet, waveform, or log - based on the type of content: command files contain commands that control the BBC engine; codec files contain the configuration information for a BBC codec; packet files contain the marks that make up a packet; waveform files contain time-sampled data for a signal waveform; and log files contain a variety of information useful for diagnosing problems or analyzing processing performance.
While specific extensions are given for each type of file below, the present version of the BBC Processing Engine is extension-unaware and it is the user's responsibility to supply any desired extensions. A future version of the engine will be extension aware to the degree that it will automatically append the appropriate extension if the user does not supply one.
Command files contain instructions that control the BBC processing engine. At the present time, there is only a single type of command file.
This is a text file containing a list of commands in the same format that would be used to enter commands at the BBC prompt. A script file can contain any command that could be entered directly and will result in the same behavior, except that the RUN command is ignored meaning that, at present, scripts cannot call scripts.
Eventually the script-calling limitation will be removed to increase modularity and decrease data over-definition. For instance, without the ability for a script to call a script, the script for the transmitter and the script for the receiver must both contain identical codec definitions that must be maintained exactly in sync. A much better approach would be to define a smaller script that defines the codec and then have both the transmitter and receiver script call the codec script. This is a relatively high development priority.
It is also the goal to incorporate at least a limited programming capability, but that is not a high priority.
These files contain all of the information to define a BBC codec. At the present time the BBC Processing Engine does not support these files and the file format is yet to be defined, though it is highly likely that the format will be XML. The intent is for the user to be able to tweak the codec parameters interactively and when they find one they want to save, they can generate a definition file that can be read back in later.
Conceptually, packet data is represented internally as a long string of bits in memory with the first bit being the lsb and the last bit being the msb. Since memory is byte-oriented, this means that each byte represents eight bits in the packet with the first packet bit being the lsb of the first byte. It should be noted that this is a conceptual organization only and the actual packet data may be distributed across many different places in memory owing to limitations on the ability of a particular language implementation to allocate sufficiently large blocks of contiguous memory. It should also be noted that these are artifacts that are completely transparent to BBC users and also to most programmers using the BBC open-source modules because the packet data structure is supported by utility access functions that are aware of the underlying physical structure.
Packet files contain raw packet data. This data can be represented in one of several different formats including a direct binary data dump, a list of mark timestamps, or as a two-dimensional image file. It should be noted that the various formats are not completely equivalent due to the fact that not all of the formats have the ability to unambiguously indicated the length of the packet. For instance, when creating an image file from a packet, additional packet bits are appended to completely define all image pixels. Conversely, when a timestamp file is read the resulting packet is only as large as required to contain the last mark in the file. Although no data will be lost, this can result in the lengthening or the shortening of packets as they are read or written in the various formats or converted between them.
This is a standard Windows bitmap file with the restriction that only full-color and monochrome files can be read and only monochrome images can be written. Marks are represented by black pixels and spaces are represented by white pixels. The bits are mapped to the image row-by-row from bottom to top placing the first bit in the packet at the lower left pixel and the last bit in the packet, after extending the packet as necessary, at the upper right pixel.
This is a direct memory dump of the packet to a binary data file. Because no packet length information is included, if the number of bits in the packet is not evenly divisible by eight, then the packet will grow to the next length that is when the packet is read back in. These extra bits will be zero since extraneous bits in the internal packet representation are initialized to zero.
This is a binary format containing the timestamps for each of the marks in the packet. Each timestamp is stored as a 32-bit unsigned integer in the native endian format. These files are normally organized in ascending order, but that is not required and should not be blindly assumed.
This is an ASCII text format containing the timestamps for each of the marks in the packet. Each timestamp appears on a separate line as an unsigned integer. These files are normally organized in ascending order, but that is not required and should not be blindly assumed.
In most cases, a message is encoded into a data packet that is then modulated in some way to produce an analog waveform that is transmitted by the sender and received (including noise and/or corruption) by the receiver. The received waveform is then demodulated to produce a data packet that is then decoded to recover the messages.
This is a standard Windows wave file with the restriction that only 16-bit, uncompressed, monaural files are supported.
This is a ASCII text file in CSV (comma-separated value) format containing two values per line. The first is the time, in seconds, and the second is the signal amplitude at that time. The amplitudes are generic and may be integers or floating point values and they may or may not be normalized in some way. The BBC Processing Engine makes no assumptions in treats them as IEEE double precision floating point values.
This is a binary file format consisting of quadrature (IQ) data pairs represented as IEEE single-precision floating point numbers. The first value was (or will be) mixed with the sine output of the USRP's NCO (numerically-controlled oscillator) while the second output was (or will be) mixed with the cosine output of the NCO. There is no time information stored in this file and it is therefore the responsibility of the user to track and supply any necessary sampling rate parameters.
){kind=link}