I would like to implement a module which keeps a constant carrier
running
and transfers packets of data at different times. In other words, using
ASK
(or OOK) modulation, I would like to always be transmitting ones
(carrier is
at full amplitude) except for certain periods where I will “pause” the
carrier (carrier amplitude is zero or some smaller amplitude).
How can I do this without supplying an “infinite” number of ones (with
zeros
inter-weaved where I want them) in my packets? I would like to be able
to
have a constant “full carrier amplitude” until I call some method like
“send_packet(data).”
Any thoughts/suggestions/examples? Corrections in my thinking?
Any thoughts/suggestions/examples? Corrections in my thinking?
Thanks.
Generally, this approach is a bad idea, as it intoduces a large
dc-offset in the baseband signal. This can vastly complicate
the bitslicing needed at the receiver to reconstitute the
1’s and 0’s. I speak from experience, where we designed a
spacecraft comm system that included such a dc bias, and we are
suffering with the results to this day.
The usual approach to this is twofold.
First, in order to eliminate the dc-bias, you should use a randomizer
on the bitstream just before it goes to the modulator, and a matching
descrambler on the receiver.
Second, what you are really talking about is the difference between
synchronous and asynchronous protocols. In a synchronous protocol,
the link is always kept busy transmitting a bitstream, even when there’s
no packet data to send. One of the most widely used synchronous
protocols is HDLC. HDLC sends a continuous stream of “flag” bytes
when there’s no data to send. This allows your receiver to maintain
lock on the data clock at all times, even there’s no packets.
There’s an example of HDLC sink and source blocks in CGRAN, in
the GMSK Spacecraft Groundstation project. The hdlc source block
takes packets in from the network and takes care of generating
any flag bytes needed in order to produce a continuous bitstream.
The hdlc sink block does the reverse, detecting and decoding the hdlc
packets, and puting their payloads out on the network.
Would it be feasible to simply pass the desired transmit data (1?s and
0?s) to the HDLC block (which you mentioned) by just having another
method in the block, say “tx_data(char[#]),” which would take in an
array of bytes; and then, after tagging on the CRC, SOF, EOF etc, go
through the array stuffing ones and zeros into the FIFO buffer? This
tx_data() function would be called in Python, in some kind of control loop.
In other words, could I do it just by calling a method to pass desired
data from the Python code?
Certainly, as long as your Python code could keep up with the datarate.
Otherwise, you’ll have to call the method from C++.
Also, I am not familiar with TUN/TAP devices do you have any examples
about how this works on both ends? Or any references?
The TUN/TAP device is a pseudo ethernet device driver. To the network
stack in the kernel, it looks just like any other ethernet device. But
instead of delivering its packets to some ethernet hardware, it
instead delivers them to an application program running in user space.
Similarly, for reception, it accepts packets from a user space program
instead of from some ethernet hardware.
It can operate in one of two different modes. The a “TAP” device
deals with the raw ethernet packets. The full packet, including
all header and trailer bytes, is delivered to the application program.
Similarly, in the other direction, it is the application program’s
responsibility to fabricate a complete and correct ethernet packet.
The “TUN” device takes care of the ethernet portion of the packet
and only delivers it’s payload to the application program. Similarly,
in the other direction, the application only needs to provide the
payload. The “TUN” device driver takes care of encapsulating it in
an ethernet packet.