Shop OBEX P1 Docs P2 Docs Learn Events
Radio transmission question — Parallax Forums

Radio transmission question

max72max72 Posts: 1,155
edited 2009-09-04 11:13 in Propeller 1
I'm trying to use the quasar QMA RX4 and TX1 modules.
I'm doing a minimal set-up on a single demoboard.
I tested the serial protocol directly connecting (with a 1k resistor) the two pins of the propeller, and the simple program here attached works.
Nonetheless when I connect the radio modules I only get gibberish from the terminal.
Am I missing somethiing obvious? Are they too close?

Thanks in advance,
Massimo

Comments

  • Clock LoopClock Loop Posts: 2,069
    edited 2009-09-02 16:15
    The RX4 data sheet says it has a 5Vdc Operating Voltage. The transmitter says it can work with 3.3v.

    Is it possible that the 5v input into the 3.3v prop is messin something up?
    (or if your running the RX4 at 3.3 that might explain your problems.)

    I see you are running at 600 baud, so that doesn't seem to be the issue. Try other baud rates after you fix the 5v issue.
  • LeonLeon Posts: 7,620
    edited 2009-09-02 16:16
    You might need to use Manchester code when sending data.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
    Suzuki SV1000S motorcycle
  • max72max72 Posts: 1,155
    edited 2009-09-02 16:37
    I have both running at 5V, the serin and serout pin have a 1k series resistor. I tested also other speeds with no success.

    I'll check for the Manchester code.

    Thanks,
    Massimo
  • Clock LoopClock Loop Posts: 2,069
    edited 2009-09-03 05:10
    max72 said...
    I have both running at 5V, the serin and serout pin have a 1k series resistor.

    Uhh, this dosen't mean the prop will be protected or operate properly.

    You can try a voltage divider circuit to be sure its not the issue. A voltage divider is simple and easy to figure out. Just look up voltage divider calculator on the net, and it will tell ya what resistor values to use to get from 5v to 3.3.

    But I do not know for sure if this is really your issue, but I do know that a series resistor will NOT protect a device from too high voltages. (the prop might be different, but generally most devices NEED the proper voltages)

    I once had to control a 3.3v lcd with a 5v BS2. I did it by putting a voltage divider on all the lines between the lcd and BS2. It worked fine.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-09-03 05:31
    Clock Loop,
    A 1K series resistor is quite adequate for handling a 5V logic signal. You don't need a voltage divider with the Propeller and with many current microcontrollers. Most CMOS logic devices have diodes connected between the I/O pins and the power rails so they will conduct any input voltage more than one diode drop above Vdd to the Vdd rail or any input voltage less than one diode drop below Vss to the Vss rail. On the Propeller, these diodes are rated at 500uA, but can transiently handle more, hence the 1K resistor ((5V - 0.3V) - (3.3V + 0.6V) = 0.8V = 1K x 800uA).
  • Clock LoopClock Loop Posts: 2,069
    edited 2009-09-03 06:37
    Mike Green said...
    Clock Loop,
    A 1K series resistor is quite adequate for handling a 5V logic signal.


    Oh. I have always followed the datasheets when it comes to chips.
    My downfall in life is apparently following the rules, as I am beginning to realize this in more than one way.
  • dMajodMajo Posts: 855
    edited 2009-09-03 08:51
    Ciao (come va a Mantova?)

    I think Leon is right: as you can see in the typical application they use the RF600D/E chipset which, beside encrypting the data because of security reasons, uses manchester encoding to enforce reliability. Using manchester code the signal is selfclocking thus you have two transitions per each bit and you lose half of the RF bandwidth, but the communication is much more reliable.
    Try a forum search for prop transmitting directly on ethernet (IIRC you will find Hippy's manchester encoding code)

    As per wiring I also suggest to respect datasheet so for receiver (powered @5V)·R=(5v-3.9V)/500uA so 2K2/2K7 ohm.
    For the transmitter you can power it with 3.3V and go directly without any resistor (or with 5V power using a open-collector/5Vpull-up scheme): depending on how it is internally build, sometimes having a higher Vpp incoming signal means a deeper modulation and so a higher S/N ratio

    Because of the raw RX/TX data transceiver set you will need also to implement a software error correction/check in your communication protocol.

    Dario


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · Propeller Object Exchange (last Publications / Updates)
  • max72max72 Posts: 1,155
    edited 2009-09-03 09:12
    Thanks,
    I'll check the forum for the encoding.

    Ciao,
    Massimo
  • LeonLeon Posts: 7,620
    edited 2009-09-03 10:18
    The main reason for using Manchester is the NRZ feature, IIRC. Those simple modules are really intended for basic on/off control of something, rather than data transmission.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
    Suzuki SV1000S motorcycle
  • Ken PetersonKen Peterson Posts: 806
    edited 2009-09-03 14:13
    I have successfully used these modules to transmit data at 1200 and 2400 baud. Whenever the transmitter is not sending, the receiver pumps out garbage on the data pin. But I found one way to get around this.

    You need to design a message-based protocol that begins with a sync header. I started a message with a series of $F0 bytes to allow the receiver to sync on the start bit. Then I sent a couple of fixed bytes to identify the message, followed by a byte indicating the message length (fixed-length messages obviate the length byte). Then I send the payload of one or more bytes, followed by a checksum.

    The receiver would look for $F0 to start a message and then throw away all subsequent $F0 bytes. I would send several in case it didn't sync on the first one. Once something other than $F0 is received, the message is clocked in per the protocol. If the two fixed bytes are not what they're supposed to be, or the checksum doesn't add up, then the message is rejected. In the system I implemented, I also sent each message twice.

    Using $FF for a sync byte may work well too. It seems the receiver might lock onto it sooner, but might not be as noise immune as $F0. I didn't really do a lot of analysis to determine an optimum sync byte.

    Hope this gives you some ideas.

    Ken

    Post Edited (Ken Peterson) : 9/3/2009 2:36:33 PM GMT
  • max72max72 Posts: 1,155
    edited 2009-09-03 16:59
    Thanks,
    I'm trying to do same approach. A couple of throw away bytes to wake up the receiver, a start character and then the data.
    Did you use the manchester encoding?

    Thanks for the help.

    Massimo
  • Ken PetersonKen Peterson Posts: 806
    edited 2009-09-03 17:02
    Nope, just the standard SimpleSerial object for the Physical Layer and my own object described above for the Data Link Layer.

    I think the important thing about the sync byte is that it must only have one space / mark transition per byte so that there's no question which transition is a start bit. It can be any of the following: $FF, FE, FC, F8, F0, E0, C0, 80, 00. Experiment with the different values to see which one gives you the best results.

    Regards,
    Ken

    Post Edited (Ken Peterson) : 9/3/2009 5:15:29 PM GMT
  • max72max72 Posts: 1,155
    edited 2009-09-03 17:11
    Thanks!
    So I'm not so far away.
    I'm probably missing something obvious...

    Thanks again,
    Massimo
  • Ken PetersonKen Peterson Posts: 806
    edited 2009-09-03 17:17
    Hang in there. I had it on the oscilloscope before I figured out what was going on.

    Regards,
    Ken

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."

    - Bjarne Stroustrup
  • max72max72 Posts: 1,155
    edited 2009-09-03 17:24
    Ok. I'll grab my oscilloscope too..

    cheers,
    Massimo
  • Ken PetersonKen Peterson Posts: 806
    edited 2009-09-03 17:29
    Here's a theory I have about how the RX4 and TX1 modules work. It may not be accurate, but it seems to explain things.

    The modules use ASK (Amplitude Shift Keying) to modulate the bits. This much is in the data sheet. This a fancy way of saying that it turns the carrier on and off based on what's on the state of the input pin. This means that if there's 0V on the input pin, there's no carrier being transmitted at all. Or perhaps a 1 turns off the carrier and a 0 turns it on. Can't remember for sure now. It's important to note that if your application is battery powered, a space should result in no carrier so adjust your polarity accordingly.

    On the receiving end, the receiver outputs a 1 or 0 based on whether or not it detects the presence of the carrier. I believe it also has an automatic gain circuit in it, because while you're transmitting a series of bytes it comes through fairly clean, but soon after you stop transmitting it starts producing garbage on the output pin. I think that is because after some time without a carrier it bumps up the sensitivity and picks up a bunch of noise.

    So your first few sync bytes give the receiver the opportunity to re-adjust the gain back to a level that gives you accurate data without all that background noise.

    That's just my theory based on my oscilloscope observations and my attempts to explain them.

    Regards,
    Ken

    Post Edited (Ken Peterson) : 9/3/2009 5:34:43 PM GMT
  • max72max72 Posts: 1,155
    edited 2009-09-03 20:02
    Thanks for your insight, I'll test it, and let you know if I'll get it.
    Do you think if the two modules are too close it will cause too much noise?

    Massimo
  • Ken PetersonKen Peterson Posts: 806
    edited 2009-09-03 20:56
    I don't think so. I had them within a foot of each other for initial software debugging before going across the room with it. I think the noise you're getting is ambient noise.

    Start with a simple test. Switch the input of the transmitter on and off and put your scope or voltmeter on the output of the receiver and see what happens. Then put a steady series of pulses into the transmitter and see if you get pulses on the output of the receiver.
  • max72max72 Posts: 1,155
    edited 2009-09-04 06:17
    I'll do that.

    Thanks again for the suggestions.

    Massimo
  • VIRANDVIRAND Posts: 656
    edited 2009-09-04 06:57
    If the radio system is low power and doesn't interfere with anything else and doesn't have to sleep,
    then I find that it's more reliable to leave the radio transmitter on when it's not sending data
    (assuming that otherwise it doesn't transmit RF for both bit states). Static almost never creates false data
    in the receiver when it is within practical range of the transmitter if it's always transmitting.

    That is the results I got when I made my own simple serial radio link using a CW or AM serial digital signal.
    I'm not sure but it seems to me that any radio link which receives static then outputs bad data must be that primitive.

    My link probably consisted of only a shortwave ISM-Frequency crystal, two common quad NAND logic chips mainly used
    like op amps, a basic variable-coil-and-capacitor-tuner, and a few resistors, for all of the transmitter and the receiver.
    CHEAP!
  • Ken PetersonKen Peterson Posts: 806
    edited 2009-09-04 11:13
    VIRAND: If you have a schematic of your setup, I would be interested in seeing how you did your "cheap" radio setup. I'm interested in sprinkling a few microcontrollers throughout my house for home automation, and I'd like to see how economical I can make them and still have them operate more reliably than X-10.

    The project that I did with the TX1 and RX4 units (or something similar) was battery powered temperature monitor and I wanted to minimize power use. I cut power to the transmitter with a transistor controlled by the microcontroller, which would awaken from sleep periodically to send a packet of data and go back to sleep. In my case I was intentionally shutting off the transmitter so I had to deal with the static on the receiving end.

    Ken

    Post Edited (Ken Peterson) : 9/4/2009 11:20:03 AM GMT
Sign In or Register to comment.