Anyone have code that works with 433mhz TX/RX with prop

stamped

I am playing around with the Parallax 433mhz TX/RX components with a single spinstamp. I am having a few issues getting communication happening. I have been doing a little scoping and there are voltage changes on the TX and RX lines at the appropriate times (note the TX and RX are on separate cogs). So there is definitely signal transfer between the units. I am however having trouble reading in the data with the Extended_FDSerial object. Either that or the data being sent is garbage.

Does anyone have any simple example code that they have verified works with the·Propeller and·these units? I had them working on the BS2 but cannot get them running on the Prop.

CON
    _clkmode = xtal1 + pll8x
    _xinfreq = 10_000_000
 
VAR
   long stack1[noparse][[/noparse]50]
   long stack2[noparse][[/noparse]50]
 
OBJ
   Serial : "MultiCogSerialDebug"
   SerialRF : "Extended_FDSerial"
   SerialRX : "Extended_FDSerial"
 
PUB main | debugSemID, problem, local
    local := clkfreq
    debugSemID := locknew
    problem := Serial.start(31, 30, 0, 115200, debugSemID)  ' Debug via USB
                                 
    SerialRF.start(4, 7, 0, 16468)
    SerialRX.start(2, 6, 0, 16468)
    
    cognew(RF_Receive, @stack1)
    cognew(RF_Transmit, @stack2)
    
return

 
PRI RF_Receive | rxByte
    repeat
      SerialRX.rxflush
      Serial.cprintf(string("waiting on data"), 0, false)
      SerialRX.Rxstr(@rxByte)
      Serial.cprintf(string("rec data:%s"), @rxByte, false)
      
return
 
PRI RF_Transmit | local
   local := clkfreq
   repeat
      waitcnt(local*3 + cnt)
      SerialRF.str(String("Hello World!", 13))

 
return

bambino

Sorry, no code, but noticed your code.
Maybe someone with a little more experience can confirm, but the main routine calls the serialX.Start routines, then terminates.
This possible leaves the two other cogs to run an uninitualized object.
Try changing the "return" command in main to "repeat", leaving it to run. This isn't efficent code, but could confirm my theory.

If it is the case, try calling the .start rountines from inside the newly started cogs.

Rayman

Code looks like it might work to me...· Might double check RX and TX pin assignments.· Also, try a lower baud rate, if possible...

Wait a sec...· I don't think you're allocating any actual buffer space for the string "rxByte".
Try adding a DAT section with this in it:

DAT
 
rxByte byte 0[noparse][[/noparse]200]

and remove the "|rxByte" declare from the rx routine...

stamped

Thanks guys for the responses.

Rayman, I overlooked the array creation in my post. Thanks for the tip. That said, it is not outputting any data. It is getting reads, but the Serial.cprintf(string("rec data:%s"), @rxByte, false) is outputting decimal 58 (if I use a %d in the cprintf) every single time (if using the %s it is not outputting anything). Something not right is going on as the Rxstr is triggering (which waits for data), but not populating. It does not appear like interference as it only triggers when a pulse is sent otherwise it waits indefinitely.

Any other ideas?

Dgswaner

I tried the BS2 code and couldn't get it to work. Ok I'm totally shooting in the dark here... take a look at this:
http://forums.parallax.com/forums/attach.aspx?a=3022

I was working on a serial circuit and found this diagram. it talks about the RF module being, in inverted mode. Could this have anything to do with it. you said that your receiving stuff but it's garbled up. every time that I've run in to the "garbled text" issue it's been a baud or timing miss match.

I'm a total spin noob, but I'll give your code a try asap.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

stamped

I do not think it is the inverted mode that you are refering to. The code is pretty much the same as the code that runs (I have verified it) with the BS2. It would be great if we could get some more tips as I hope this thread will serve as the compatibility reference thread for the Prop and the Parallax RF units.

deSilva

For most RF units the power supply has to be extraordinary stable and ripple free. Some will not work with just the 5V from a 7805 or similar, but need an additional RC-filter. However this depends on internals.. What I read hear sounds as if this is a more complex device you are taklking about, doing that internally...

stamped

Thanks deSilva for the note. I am running the Parallax RF modules http://www.parallax.com/Store/Accessories/Communication/tabid/161/CategoryID/36/List/0/Level/a/ProductID/111/Default.aspx?SortField=ProductName%2cProductName

Dgswaner

Stamped, I tried your code out. with the same results you had. I tried this on the same proto board and 2 different proto boards one doing just RX on doing just TX. I'm going to try getting a bs2 to communicate with a propeller, I'm curious to see if I can get one side or the other working.

I'm using a lm7809 to power the proto board. and I'm also using a wallwart to power the other. I've had all of my RF modules working on LM7805's

anyone at Parallax Have a few minutes to try this out?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

stamped

I am waiting on an Oscilloscope to arrive so I can make some more sense out of this. I will try the Pulse trick to see if that helps it a bit... That said, I am almost certain that this is not an interference issue as the RX receive only triggers when the Serial Comm is transmitted from the TX.

Dgswaner

I would agree that it doesn't seem to be an interference issue. I have the parallax O-scope I could try it if you told me how you wanted it connected. I'm still learning how to use it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Dgswaner

I tried the bs1 to propeller @ 2400 baud, with a little luck. it appeared to work when xmitting data from the propeller, I say seems because I was receiving data but the code I had was for receiving variables not a string, when I powered off the propeller the bs1 stopped receiving. I was too frustrated at that point to break out the manual to figure out the bs1 code to receive a string.

trying to receive on the propeller did nothing at all. I think I'm going to bail on these modules and keep them for my stamp projects and go with the already supported X-Bee modules.

I'm wondering if these modules are approaching end of life and that's why there isn't new code for them. IDK.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Andy Lindsay (Parallax)

Hi,

Attached is an example (RF Loopback...zip) with the RF transmitter connected to P2, and the RF receiver connected to P14 through a 10 k resistor.· RF modules are powered with 5 V.· The data path goes like this:

HyperTerminal -> P31 at 57600 8N1

-> P2 -> RF transmitter -> RF Receiver -> P14 at 2400

-> P30 -> HyperTerminal at 57600 8N1

I also couldn't get it to work at 9600, and I think it's because the receiver module isn't matching the high signal times the transmitter receives from the Propeller chip. Maybe that's because of the 3.3 V vs. 5 V high signals.· Not sure yet...

Andy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay

Education Department
Parallax, Inc.

Post Edited (Andy Lindsay (Parallax)) : 1/9/2008 9:31:03 PM GMT

stamped

Andy,

Firstly many thanks for venturing over to the thread. I am pleased to say that I have tested your code and I now have the RF units communicating.

Thanks for taking the time to test this out and provide some code. This thread can now sit as a reference for Propeller users that want to run the Parallax 433mhz TX/RX units.

One note; When using Hyperterminal (start -> run -> hypertrm) everything is just fine. When running PropTerminal the output is garbled (Possibly the Baud settings).

stamped

One additional note is that a baud rate of 7200 for the 433mhz units TX/RX works reliably. Anything over 7200 seems to fail under my limited testing.