Shop OBEX P1 Docs P2 Docs Learn Events
slow RX/TX with (28180) RF 433MHz RX/TX Modules — Parallax Forums

slow RX/TX with (28180) RF 433MHz RX/TX Modules

$WMc%$WMc% Posts: 1,884
edited 2009-09-06 00:19 in BASIC Stamp
Hello All

I'm trying out the RF chips from Parallax.

TX part#(27980)
RX part#(27981)

I've loaded the demo codes for the RX and TX units. I listed them below

The code seems to run very slow,And Hang up for a few Seconds. Is this the normal speed and behaver of the RX/TX units?

Will the RF units run faster with some better code?

I googled the RF units, But didn't find anything about the speed or transfer rate.

The Demo Code sets up 9600 baud-inverted.

I have the units talking to each other, Their just really slow.

Any help would be greatly App.

_________________$WMc%________

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Truth is out there············································ BoogerWoods, FL. USA

Post Edited ($WMc%) : 7/25/2009 5:24:13 AM GMT

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2009-07-25 05:22
    I don't know why you couldn't find anything about the speed. The Parallax product webpage states very clearly that it works up to 19.2KBaud depending on the controller. The documentation states this very clearly and gives the minimum data rate as 1200 Baud. The BS2 sample code is written for 9600 Baud because the BS2 really doesn't work well at all above 9600 Baud and is kind of marginal receiving data even at 9600 Baud.

    The demo code you posted is slow because it packetizes the data and computes a checksum. That slows down the processing significantly. You may also have enough RF noise present that the RX and TX units are getting a high error rate and may be retransmitting the data repeatedly until it's received correctly.

    Either get a faster Stamp or switch to a faster microcontroller like the Propeller or dispense with the error checking or simplify it and deal some other way with the errors.
  • $WMc%$WMc% Posts: 1,884
    edited 2009-07-25 05:44
    Mr.Green

    The Baud rate is obvious. It was the time between packets that I was getting at. My fault for not being more descriptive.

    I have moved the two units farther apart and I've shut down some other RF equipment and the packet time is improving.I have far less hang ups.

    I think I need to ditch the crc and packet format and try a different approach to get the response I'm looking for.

    I need some kind of error checking.

    Any other Ideas would be greatly App.

    __________________$WMc%___________

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA

    Post Edited ($WMc%) : 9/4/2009 3:01:40 AM GMT
  • Mike GreenMike Green Posts: 23,101
    edited 2009-07-25 14:03
    A simple checksum may be adequate depending on the circumstances and would be faster. So much depends on the circumstances and you haven't said anything about what you intend to use this for. Try describing what you want to accomplish first rather than just "fishing" for ideas. There are too many possibilities and details matter.
  • $WMc%$WMc% Posts: 1,884
    edited 2009-07-25 18:45
    Thanks for the Replys Mr.Green

    I've built a 44" BushHog/Mower with a 17HP B&S. This is a 3 wheeler design just like the BOE bot. I have 2 600watt 24volt DC motors driving this Mower much like the two servos do on the BOE bot.

    I have a BS2 on the mower along with a RX(27981) and a TX(27980) modules. The remote has a BS2 and a RX,TX modules as well.

    Since this Mower is very powerful and potentially dangerous, I need to make sure the remote and Mower are in range and talking to each other.

    --- If no signal from remote in 1000mSec,---STOP DC motor movement, ---If no sig. from remote 1000mSec after the first 1sec timeout,---Shutdown B&S engine.

    I'm trying to make this as safe as possible.

    This morning after coffee, I grab a coke. I set the can down just behind the Pro Dev.Board that I have the remote RX/TX modules on. I started receiving packets on the BOE at a much faster rate with few hangups.

    Did I shield some RF interference or correct a SWR issue with the TX module?

    just a note: I do have a lot of RF. WiFi,Bluetooth,cell phone,cordless phone,Satellite Internet,etc.

    If I can get the error rate below 250mSec. This wold work fine for Me.


    Any help or explanation with this RF modules would be great.


    ________Thanks in Advance___________$WMc%________

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA
  • Mike GreenMike Green Posts: 23,101
    edited 2009-07-25 19:04
    "Did I shield some RF interference or correct a SWR issue with the TX module?"

    Who knows? The can might be acting as a reflector or director. Your neighbor might have turned off something.

    Remember that motors, particularly big motors, make a lot of RF and electrical noise.

    There's no way I can give you any kind of useful specific advice. Too much depends on the particular electrical environment and RF environment of your robot and the remote. At the short wavelengths and low power involved, all kinds of things come into effect.

    My own personal preference is to use xBee modules or xBee-Pro modules. They handle their own packetizing and error detection and correction. They run at 2.4 GHz which is subject to interference from WiFi, Bluetooth, wireless phones, etc., but is very little affected by electrical noise.
  • $WMc%$WMc% Posts: 1,884
    edited 2009-07-25 19:20
    Thanks again Mr.Green

    I'm running a battery of test with the RF modules. Something I should have done before starting A Post.

    Thanks for the Replys

    ________________$WMc%____________

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA
  • Bill ChennaultBill Chennault Posts: 1,198
    edited 2009-07-25 20:56
    $WMc%--

    Ha! (Referring to our PM exchange.) That is why I want good, solid remote control, as well! I want to cut my grass!

    Unfortunately, I do not think Bluetooth will make the cut, pardon the pun, and am looking forward to Parallax's development of the WiFi module they semi-announced on the Prop board.

    --Bill

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You are what you write.
  • $WMc%$WMc% Posts: 1,884
    edited 2009-07-26 01:10
    Hello Bill

    I'm thinking a couple of Beta testers (Bill C. and Walt Mc.) would help Parallax get this WiFi module going!


    _____________$WMc%___________

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA
  • Bill ChennaultBill Chennault Posts: 1,198
    edited 2009-07-26 18:18
    Walt--

    You are a veritable genuis! I am ready, willing, and most of all, WAITING! [noparse]:)[/noparse]

    If done correctly, a Parallax WiFi module will be a tremendous hit.

    --Bill

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You are what you write.
  • xanatosxanatos Posts: 1,120
    edited 2009-07-26 20:10
    OH YEAH! I'll take a few (dozen) Parallax WiFi modules!!!!!!! Count me in... can we pre-order??? smile.gif

    Dave
  • $WMc%$WMc% Posts: 1,884
    edited 2009-07-27 00:55
    Hello all

    I got the RF modules working like clock work. I ditched the code examples for the 27980 and 27981, and wrote some stuff of My own along with some code from the Parallax Lib.

    This is just a DEBUG setup, But its very useful when starting from scratch with the RX/TX modules.

    I have a very advanced code written for this project. But I still have a few bugs. When I debug this program I will post it.

    For now, here is the debug code for the RX/TX 433mHz modules.


    _______________$WMc%__________

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA
  • $WMc%$WMc% Posts: 1,884
    edited 2009-08-02 23:54
    Heres the better RX/TX Code I promised. for the #27980 and the #27981

    Its not the greatest but it works.

    I hope this helps You with the requests in Your E-Mail.

    ______________$WMc%______________



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA
  • RonHRonH Posts: 1
    edited 2009-09-03 11:25
    I would be interested in knowing if you determined the effect of baud rate on the overall time required to get two consecutive good transfers and if the length of the sync pulse can be optimized.

    Ron H.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2009-09-03 19:22
    Hello everyone,

    The documentation is in error. 19.2kbps is too high for these modules. The chipset is only rated for 10000bps. WE obviously need to correct that, however that limits the upper baud rate to 9600bps. As a note I think the example code pauses between packets. If you remove that pause it should be continuous. I’d have to look at the code in detail to see why the author put that in there. Take care.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage

    Parallax Engineering
    50 72 6F 6A 65 63 74 20 53 69 74 65
    ·
  • $WMc%$WMc% Posts: 1,884
    edited 2009-09-06 00:19
    Hello all

    ·Here is a better Code with more inputs

    The communication is pretty fast.

    See Attachment below



    ________________$WMc%___________________This works good for Me______






    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············································ BoogerWoods, FL. USA

    Post Edited ($WMc%) : 9/6/2009 4:55:13 AM GMT
Sign In or Register to comment.