DPRG List  

FW: DPRG: Ming Transmitters/Receivers

Subject: FW: DPRG: Ming Transmitters/Receivers
From: Dan Miner miner at centtech.com
Date: Mon Aug 16 15:24:24 CDT 1999

(resend...  first copy got "lost"?)
>From: Dan Miner 
Sent: Sunday, August 15, 1999 11:10 PM

> From: Dan Miner 
> Sent: Sunday, August 15, 1999 8:37 PM
> I just hooked up the first pair of my group buy Ming modules.
> I'm having trouble too.  Low of 1.4V, high of 5.0V.  *BUT*
> the "high" signal (detecting carrier) is *VERY* erratic and
> unstable.  Where the signal should be high for 1msec (as an 
> example), instead I get hash (high frequency noise) in the
> range of 1kHz to 1Mhz that is not periodic - just noise.


Boy - I love it when I'm able to solve my problem before 
the list mailer even sends out my plea for help!  :-)

Some information that will hopefully make it easier for
others to make the Ming modules work:

1) When connecting directly from a UART or a "serial" output
  of a microcontroller, you need to invert the signal.
  (See Footnote #1 below for more details.)

2) The duty cycle of the transmitter (at the DATA pin of the Tx)
  *MUST* be less than 40%.  It must be low (not transmitting)
  more than it is high (transmitting).  Pretend that it 
  "Overheats" when you transmit more than this.  It's not really 
  heat, but is some RF electrical effect that works like that.
  (See footnote #2 below.)

3) Untested so far but I think it'll work:
  9600 baud (or more??) can be achieved reliably with a simple 
  circuit on the Rx consisting of 2 inverters (74HC14), a diode,
  a resistor, and a capacitor.
  (Details after I confirm that my theory actually works.)

Footnote #1:
- ------------
I used Kam Leang's circuit.  http://www.mech.utah.edu/~kleang/
Click "Robotics", "Robotics Information and Articles", "RF Serial 
Communication ..."

A little background for those of you that don't know the details
of RS-232...  Directly from a UART pin (or serial output of an
MCU), the TxData pin is typically high.  This is the idle state
when nothing is being transmitted.  Then this gets translated to
a +/-12V signal for "real" RS-232.  *BUT* it also gets inverted:

UART +5V  -->  RS-232 -12V
UART  0V  -->  RS-232 +12V

Watch out for this when you are interfacing to a "real" RS-232
port.  (Like a "serial" port on a PC - this is real RS-232.)

When a character is transmitted, the signal at the UART (or MCU)
pin looks like this:    (ASCII pictures suck!)

- --------------+ +-+ +-+ +---+   +-#--------
              | | | | | |   |   |
              +-+ +-+ +-+   +---+
               S 0 1 2 3 4 5 6 7 Z

S = Start bit=0V;  Z = Stop bit = +5V
The data is sent LSB first and is NOT inverted here.
(Data in above example is 35 hex.)
If parity is used, it comes between bit 7 and stop (Z).
The "#" indicates the location of the end of the character
and the place where another start bit could occur.

So you ask "Why do I need to invert the data?"  Go back to
rule #2 from above.  When you do not want to transmit a
character, you want the Ming Tx DATA pin to be LOW.
(I wasn't doing this when I had all the trouble...)

Now, if you're hooking directly to RS-232 (or a PC serial 
port), you don't want to invert but you will need to level
shift:  (Schematic left as an exercise to the reader.  :-)

RS-232 -12V  -->  Ming  0V
RS-232 +12V  -->  Ming +5V

Of course, since you inverted the Tx data, you need to invert 
it at the Rx end again to get what you wanted...

Footnote #2:
- ------------
Note this comment from the data sheet: "Our RF boards must
be used with their intended motherboards (TX-01 & RE-01) and
cannot be used for continous serial data applications."
I think it's safe to skip their encoder/decoder board but
the "not continous" part MUST be heeded.

Because the data is inverted from rule #1, it is also true
that the "worst case" stress test is a continous stream of
NULL (00 hex) characters.  I was able to get a good signal 
(at 6 inches) my making sure that I delayed between characters 
so that 00 hex was still only a 40% duty cycle.  *MAYBE*
(but not tested) longer range can be achieved by extending 
the delay between characters.

This also explains why Aaron had such good luck with them -
he was only using SHORT BURSTS of data.  I suspect that
full speed 9600 baud can be done for ~50 characters or less
bursts IF a "rest" period is used after this.

- ---------------------
Enough typing for now - back to the workbench...

				- Dan


More information about the DPRG mailing list