[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Synchronous bitstream output using ppio_ppdev?

From: Ed Criscuolo
Subject: Re: [Discuss-gnuradio] Synchronous bitstream output using ppio_ppdev?
Date: Thu, 23 Aug 2007 11:49:00 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414

Eric Blossom wrote:
>1) Is ppio_ppdev fast enough to keep up with this bitrate?

I doubt it.  It just bit bangs the serial port.  Thus you've got no control
of the data rate, etc.

I assume you meant the parallel port. I suspected as much. I was just hoping that it would keep up with my low data rate, which is being throttled elsewhere.

3) Are there other, better or easier ways to do this, such as using one of the debug pins on a USRP daughterboard?

If you're willing to hack verilog, you can get it out the debug pins.

I'm willing, but I don't have the time/funding to learn verilog. I'm working under a very small, focused research grant.

If the output needs to be synchronous serial output, the easiest way to
get it out may be to use a serial card with a USART on it.  E.g.,
something that's capable of synchronous serial transmission.  Look for
a card that'll do HDLC, then see if there's a "raw" or "unframed"
mode.  Generally the hardware that'll can do HDLC can also do

Yes, I'm very familiar with HDLC synchronous serial cards, having written several Linux network device drivers for them. Again, this is doable, but probably not under the tight time/money constraints I have.

Another thought occured to me. Since the LFTX daughterboard goes down to DC, shouldn't it be posible to use it to output the bitstream? It's a bit of a kludge, but it should be easy. Comments?

What's the protocol for talking to the equipment?  Is there any
handshaking, etc, or do you just need a raw synchronous stream?

For my immediate purpose, I just need a raw clock and data synchronous bitstream with no handshaking. In reality, the bitstream is carying NRZI-encoded HDLC/Frame-relay, with IP packet payloads that conform to the Multi-Protocol-over-Frame-Relay (MPoFR) standard. This gets fed into a COTS router which is performing all sorts of statistics gathering on the HDLC. I know that I could do all this link layer stuff in software, but I'd essentially be "re-inventing the wheel" when I can't afford to.

Let me give you a little background on what I'm trying to do. I'm working with the US Naval Academy's MidStar-1 spacecraft. Due to an unfortunate design choice, the average of the digital waveform that gets FSK modulated onto the carrier has a non-zero, varying DC offset, dependent on the data content. As a result, once the waveform is demodulated on the ground, a standard 0 volt bitslicer will not work. We were forced to build hardware for an adaptive-level bitslicer, based on a 1970s-era design which uses a pair of sample-and-hold circuits to track the min and max levels in the signal, and slices at 1/2 of the difference (effectively the mean instead of the average). But this circuit performs poorly, especially at points where the DC offset changes abruptly by a large amount. Unfortunately, this is a common occurance in NRZI encoded HDLC. My goal is to use GNU Radio to implement a smarter adaptive-level bitslicer that will outperform our hardware one.

@(^.^)@  Ed

reply via email to

[Prev in Thread] Current Thread [Next in Thread]