Shop OBEX P1 Docs P2 Docs Learn Events
RF Modules - I am stumped — Parallax Forums

RF Modules - I am stumped

Brian RileyBrian Riley Posts: 626
edited 2006-04-11 15:27 in General Discussion
I bought a set of the new Parallax 433.92 MHz transceivers. I coded up the sample code and placed the transmitter on one board with a an OEM BS2 and the reciever on another board with an OEM BS2X and a serial LCD. Loaded up the code and The transmitter works. I got out one of my 70cm HTs and dialed in 433.92 and I could hear the carrier and the data squirts at the two second rate ( I added a two seond pause so I my ears could differentiate the carrier and the data.

However, the receiver just sat there. I tried putting a meter on the RSSI line and it gave me values wandering between 1.15 and 1.5 volts with no correlation to the transmitter being on or off.

I have uploaded my code .... what am I doing wrong?

Note the receive code has a BS2 lable but it's stamp directive and baud rates are BS2SX. - BBR

Edite: 4/11/2006 - please do not use this code, see the new uploads on a later message

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont

Post Edited (Brian Riley) : 4/11/2006 12:23:26 PM GMT
600 x 800 - 89K

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-04-10 23:43
    In your transmit code, where did you get a baud rate value of 16848?· I think you meant 16468?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • Brian RileyBrian Riley Posts: 626
    edited 2006-04-11 04:33
    Chris Savage (Parallax) said...
    In your transmit code, where did you get a baud rate value of 16848? I think you meant 16468?

    OK it is working now, kind of ... the 16848 was a typo from the many things I tried. I corrected it back to 16468, but it still would not work. However ... the real problem came was here:

        HIGH        TXdisable            ' turn on transmitter
        PULSOUT    TXpin, syn            ' sync pulse to receiver
        SEROUT    TXpin, TXbaud,    [noparse][[/noparse]"!", x.HIGHbyte, x.LOWbyte, 
                                 y.HIGHbyte, y.LOWbyte,
                                 syn.HIGHbyte, syn.LOWbyte]
        PAUSE        10
        LOW        TXdisable
    
    



    I had to add a "PAUSE 10" in there to give the transmitter time to get 'up to speed' so to speak after being enabled.

        HIGH        TXdisable            ' turn on transmitter
        PAUSE            15                        ' allow TX to settle
        PULSOUT    TXpin, syn            ' sync pulse to receiver
        SEROUT    TXpin, TXbaud,    [noparse][[/noparse]"!", x.HIGHbyte, x.LOWbyte, 
                                 y.HIGHbyte, y.LOWbyte,
                                 syn.HIGHbyte, syn.LOWbyte]
        PAUSE        15
        LOW        TXdisable
    
    



    I should have seen this when I did it, we have that problem in ham packet radio and have a parameter called TXDELAY which essentially covers the same thing. I will need to play with these units and see if I can define the TXD value for thse units. With the other 70 cm equipment running here at my home it simply is not acceptable to leave that transmitter running all the the time, using PDN pin is the way to go.

    When I started composing this reply, I had made TXD 10 (ms), I was watching it and it was kind of erratic. I stopped what I was doing on this message and made the it "PAUSE 15" and then it was dead-bang, every transmission was received. Now that it is working tomorrow .... errrrr, later today. I will run tests on the length of the SYN pulse to reliably sync the receiver. I did a little playing around already and values under 1000 don't seem to work well at all.

    I have modified my code and re-uploaded the revised modules.

    It might be a good idea if there is revision of the Rf Modules docuemnt to let people know if they use the PDN pin on the transmitter module, that it needs 12-15 msecs to settle down and work reliably.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    cheers ... brian riley, n1bq, underhill center, vermont
  • steve_bsteve_b Posts: 1,563
    edited 2006-04-11 12:12
    You might want to edit your first post and remove the attachments! I'm pretty sure you're able to edit your own posts like that!

    I also have a couple of the same transmitters and am watching your attempts!!
    Thanks

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve

    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • Brian RileyBrian Riley Posts: 626
    edited 2006-04-11 15:27
    OK, I got some sleep and finished two other things I had to do. I settled down to test the value of the SYNC pulse duration. This was at a range of 1 foot on the bench sending WORD vars X, Y, and the SYNC pulse duration with a 2 second pause between transmissions. That way I knew the value as they made it across.

    I started at SYNC pulse duration of 1400 (recommended is 1200) and stepped it down by increments of 5.

    (1) the last sequential transmission was at a SYNC pulse duration of 1050, from there down to 1020 it was every other or every third transmission made it.

    (2) at a SYNC pulse duration of 1015 it essentially stopped receiving transmissions and over the next 15 minutes 'received' maybe 3 more transmissions and the data was garbled.

    Now what needs to be investigated is to see how much range effects it and how much the time between transmissions effects it. If the transmissions are only separated by a few milliseconds the receiver may never lose lock and not need to re-synch. You are then in a situation where your sync pulse takes as much time as your data payload ... I suppose a simple checksum could be done, but that effects the minimum time between transmissions

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    cheers ... brian riley, n1bq, underhill center, vermont
Sign In or Register to comment.