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? Thanks.
on 2009-03-19 18:56
on 2009-03-19 19:46
William Harding wrote: > method like "send_packet(data)." > > 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. @(^.^)@ Ed
on 2009-03-23 14:56
William Harding wrote: > 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. Start with http://en.wikipedia.org/wiki/TUN/TAP and follow the reference links. @(^.^)@ Ed