the quick answer is: as long as you just use the working democode it will work right after downloading to the EEPROM
if you start changing the code - the SUM of time you need to get it working again can
- be low if you do it step by step (for you I emphasize micro-pico-steps)
- be high even higher than going on with transmitter and receiver if you keep changing things
without testing it and understanding it
when I started programming as a 15 year old boy I did it the same way as you
and the projects turned out to take a lot of time until they worked
Then I got a som ehour per week job in a company in programming and they showed me how
to do it STEP BY STEP and from then on my projects finishes faster and faster the more I did
them STEP BY STEP.
Every single step to understand the code and to test it intensivly took
time and in the beginning I thought "hey why don't they just threw it together in one hour ?"
Why am I forced to test everything intensivly ? well the three hours testing saved me three days
of beeing confused. And so in the long run it saved a lot of time spending time on testing EVERY DAMMED DETAIL
on its own. If a program compiles ist just 20% of that it does what you intend to do it.
Your free to spend another 160 Dollars for two transceivers wait a week until they arrive and then
messing around another month until you get it half working
I recommend to do it in micro-pico-steps and test EVERY DAMMED DETAIL
this will take 4 or 5 days but then it will work
you are correct "the quick answer is: as long as you just use the working democode it will work right after downloading to the EEPROM"
but take this for exmaple if you went out and bought a car but they gave you all parts and said figure it out dont ask for help just figure it out.without any instructions AKA road map.
Are you telling me you would try to put the car together without asking for any help? I would roll with you but i dont think we will roll far.But thanks StefanL38 i know you are geting tired of this post i am still willing to learn and will always learn things the rest of my life not the same stuff i hope but new stuff.Awesome job Beau Schwabe (Parallax) you created a object for the transivers no dout that will help a lot of pepole havein issues with it.
Once agian thanks to all of the pepole who posted on this topic, you may not belive me but i am tring very hard and will pump up my effort to make it work
to stay in your picture with the car as a construction-set:
A newbee would start putting the parts together in a way that he thinks this should go.
An experienced "car-builder" will do it a different way.
The newbee maybe starts with "I want the engine running !" And he quickly starts to build the enginge.
Now the engine LOOKS finished but in his hurry he forgot to include some small parts of the electric-motor
that starts the enginge. Now he can press the start-button as often as he wants the enginge doesn't start
Now asking for help saying just a few words "I connect to the powersupply but nothing happens"
The experienced "car-builder" answers "you forgot this small cable from A to B"
Dooh ! and in a hurry he rips off everything around the electric-starter to add the cable
put all together again.
Press the startbutton the electric-starter is running but the enginge still doesn't start.
You do a recheck:
fuel connected
cylinder-head tightend and sealed
....
.....
...
hm everything ok WHY DOES THE ENGINE NOT START ?
The newbee did NOT understand ENOUGH how the connection between electric-starter and enginge works.
So he put together two small parts in the WRONG ORDER because he did not understand how this DETAIL
works.
Now the way to find out how it works is not to buy another kind of electric starter that is well known as working
the way is to put together only the parts of the electric starter and test the electric starter
on its own to REALLY understand how the starter works and how all the parts have to be put together
next step is the engine.
NOT running but test the functionality by turning the cylinders up/down by hand
checking all cylinders working, all valves working adjusting the valves etc.
Here I want to emphasize ones more my impression is your way is
to put all the parts of the enginge together without adjsuting the valves without sealing
the cylinder-head
the engine starts running but it runs bad stops after a few seconds or minutes...
you are asking for a detail like "what type of cyliner-head-sealing do I need?"
answer sealingg-type xy
but it is still not running because you do not understand how to adjust the valves
you do not understand 2)
you do not understand 3)
you do not understand 4)
etc.
From the code that you attached somebody with experience can see
He knows not very much. There are basic bugs in it
To use the picture of the car again:
there are bugs like if you forgot to put on the wheels of the car
or less obvious like you forgot the gearbox or you put together th etooth-wheels of the gearbox vice-versa
because you don't understand enough of th egearbox
at programming it is NOT so obvious where the bug is (like it is obvious than forgetting the gearbox)
So the way to learn programming is not to "buy a complete construction kit of a car" (your complete code)
But to buy a bicycle construction-kit understand how this works. And then start modifying the bycicle
to transform it to a leightweight motorcycle
then modifying the leightweight motorcycle to a heavy motorcycle
and then modify the heavy motorcycle to a leight-weight car
etc. etc.
I got the impression that you are not patient enough to do all these "in between steps".
You want to START with the complex car construction-set
The programming of these "inbetween steps" don't last so long as building a bycicle, a leight-weight motorcycle etc. etc.
each step takes 30 Minutes to maybe two or four hours and then comes the next stage
I took a look on where this thread started it is for weeks ago.
If you would have followed my suggestions your project would have run after three weeks.
Now you are fiddling four weeks and it is still not working. Impatience slows you down
But I got the impression that you don't believe me and that it will take some more time until you do so
Awesome StefanL38 i understand what you are saying but i have done the steps over and over i have tons of code where i have done it on my own with no help. Its kind of like putting the fuel tank on in your comment but mine keeps exploding . I am trying to get view point workin so i can debug in realtime i think i am use to visdual studio showing me whats wrong.but i will tak ea look at past post to see what steps you told me to take, i think i have an ideal.
1. get the TX working and outputing to screen
2. get the RX working and output to screen
3. display it on my LCD (easy)
What small test code do you think i need to write that will help me with this issue i am haveing?
Post Edited (chris jones) : 11/24/2009 4:03:40 PM GMT
1. get the TX working and outputing to screen
2. get the RX working and output to screen
3. display it on my LCD (easy)
What small test code do you think i need to write that will help me with this issue i am having?
Step 1 - The TX side does not output to a screen, so 1 & 2 work with the DEMO examples I have provided, but don't forget the schematic modification so that it will work with the RF transmitter and RF Receiver units. Get that part working first.
Step 2 - Since the Receiver side does output to the screen, It should be a simple matter of re-directing that output to your LCD instead.
Step 3 - If you want the Transmitter to output to the screen, look at the Receiver side as an example to see what it's doing and then make appropriate modifications to the Transmitter side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
It's really difficult to tell from your picture what is connected to what. Using the RF Transmitter and RF receiver, your setup should look something like the attached images. If you are using the RF Transceiviers your connection should look like what Michael O'Brien posted (btw - Thanks Michael)
Your code in either setup case should be running the same demo, the only difference is a slight modification in hardware wiring.... i.e. the TX DEMO on the Transmitter, and the RX DEMO on the Receiver.
BUT---- in my debug window on the reciver side all i get are 0's? and ideal why
you are the master Beau Schwabe (Parallax) my LED's are blinking i need to send you a big fat turkey for thanksgiving.
ok now i have a few questions the transmitter is not hooked to a pin on my propeller boardit never will need to be hooked or assigned a pin if i dont want to display out a counter etc...
next i will play this weekend and see if i can run both transmitter and reciver on the same board but recive from another board . can i use cogs for this or will it send it to the same board ?
anywho i am happy and will star to play with the code and understand it a bit more you are awesome Beau Schwabe (Parallax)
ok i answered my question i unhooked the transmitter from vss and hooked to pin 7 and i get outputy on the reciver side· with numbers AWESOMENESS
Post Edited (chris jones) : 11/25/2009 6:01:48 PM GMT
from your picture we can see that you are using a demoboard.
The picture is not sharp enough to see into wich connection
you plugged in the wires named RX PIN 1, TX PIN 2
In the attachment you find three SPIN-programs
one for a receive-test
one for a send-test
and one for a send and receive-test with one and the same prop
through a closed loop on two IO-pins
connect your two demo-boards DIRECTLY with each other.
One running the send-code the other running the receive-code
both codes make an DIFFERENT LED flash to give a feednback about sending/receiving a byte
so if the LED flashes you know the programs and the connection is working
As a second feedback you can start PST.EXE with 115200 baud to see the debug-messages
try this and come back with questions if something does not work
i get junk data when i run your exmpale in my terminal window and when i set it to the correct baud rate i get a 0 and the first line of data and it goes away fast and repeats itself over and over.
So this is an example how a hardware-related problem makes a software behave strange
if ONE single parameter is wrong.
I tested it on my propeller-professional-development-board (PPDB)
If you connect your demoboards DIRECTLY with one wire from Prop1 PIN7 to Prop2 PIN7 it should work
If it is NOT connected on the right PIN the FullDuplexSerialPlus-Driver receives zeros all the time
Or if you use the send-receive-code and connect PIN6 directly with PIN7 on the SAME demoboard it should work
sorry for the lond delay on my post over the holiday i had a breakin and lost a lot of my code and stuff so i think i am back in working order kinda and will post some questions i have.
that's another reason to post archived projects here in the forum quite often.
If you don't include the Propeller.EXE this will be less than 100kB per archive
To state the obvoius: did you download the latest uploaded codeversion ?
yes i did download the latest code and , but all my documentation and notes are gone and software so i had to start over in a way.but everything is back up and running.
I have run across the same issue with TX and RX using the original Parallax RF Receiver (#27981) and RF Transmitter (#27980). I have tried following this thread and have performed several of the recommended actions with similar results of characters appearing and disappearing rapidly on the screen. So I went back to the basics where I started. I have written a very basic program that repeatedly transmits 0 to 10 separated by an asterisk. The receiving program just captures the bytes and sends them directly to the serial terminal (PST) screen with a line return between each received byte.
{{BasicRX.spin Using RF Receiver #27981
4.7K 1K
GND >---/\/\---o---/\/\---> DATA
|
P14 >----------o
Vss >---------------------> GND
+5V >---------------------> +5V
}}
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
obj
RFReceive: "simple_serial"
debug: "FullDuplexSerialPlus"
PUB main
RFReceive.init(14, 15, 9600)
Debug.start(31, 30, 0, 9600)
waitcnt(clkfreq/1000+cnt) 'Start the debug terminal
repeat
debug.dec(RFReceive.rx) 'Store the bytes
debug.tx(13)
{{BasicTX.spin Using RF Transmitter #27980
4.7K 1K
+3.3V >---/\/\---o---/\/\---> DATA
|
P0 >----------o
Vss >---------------------> GND
+5V >---------------------> +5V
}}
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
var
byte i
OBJ
RFTransmit: "simple_serial"
PUB Main
RFTransmit.init(1, 0, 9600)
waitcnt(clkfreq/1000+cnt)
repeat
RFTransmit.tx("*")
repeat i from 0 to 10
RFTransmit.tx(i)
waitcnt(clkfreq/10+cnt)
What is being displayed is very different from what is being sent, however, I can see that it is following the proper pattern (see debug1.jpg attached).
You may notice that I am using the simple_serial.spin object. I have also tried using the FullDuplexSerialPlus.spin object with different results being displayed in the PST (see debug2.jgp attached).
I have used these modules before with my BS2 and Prop. The BS2 was transmitting wind speed and direction from a vortex anemometer with the Prop using simple_serial.spin to receive the data, format and display the data to a LCD. This project worked without any issues so this would lead me to believe it is the way the data is being transmitted that is causing the problems.
Simple Serial won't work because the Transceiver needs to operate in an open collector mode and Simple Serial won't let you specify that particular mode... I don't think.
FullDuplexSerialPlus should let you specify the proper operating mode. The line that reads...
Debug.start(31, 30, 0, 9600)
...in your code should look like this to do so...
Debug.start(31, 30, %1100, 9600)
...A breakdown of the mode variable looks like this...
mode bit 0 = invert rx
mode bit 1 = invert tx
mode bit 2 = open-drain/source tx
mode bit 3 = ignore tx echo on rx
...By specifying %1100 for the mode, tx and rx are true, with open drain selected, and ignore echo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I tried that method too. Debug2.jpg is the output when using FullDuplexSerialPlus (FDSP) and %1100 with just the transmitter. If I change them both over to FDSP then debug1.jpg is the output. And I have tried changing the mode in the command too with the same results as debug2.jpg.
If you make the transmitter pin go HIGH, the receiver pin will go HIGH, but
If you make the transmitter pin LOW, the transmitter doesn't actually transmit and the
receiver is suseptable to receiving anything (noise). The receiver does go LOW but it times out
after a few ms of not receiving a signal from the transmitter. This timeout is enough to encompass a single bit-width of data at 9600 baud.
Because of this you need to have some sort of "wakup" pulse prior to a sync character in order to expect to receive anything meaningful ...especially after periods when you are not transmitting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Beau,
Thanks for the code but it would only display 0's on the screen. I fiddled around with it for a while then took a step back, revisited my code, and incorporated your buffer routine. After getting that to work I started making small changes, like using FullDepluxSerialPlus, which broke the code again. Went back to simple_serial with a baud rate of 9600 and it is working again.
Interesting that I do not have this issue with my BS2 collection. I used the BS2 code published with the units and it worked without a hitch. It looks like it comes down to the way the serial commands are implemented in pbasic verses spin.
I will keep playing for a while, then perhaps I will try the xbee's I have on hand.
if the reason why your setup does not work si waht Beau has described, then you should get a almost right receiving if you send
multiple characters at one time.
instead of
RFTransmit.tx(i)
do
RFTransmit.str(string("AAAAAAAAAA"))
and have a look what you receive
10 characters should be enough to wake up the receiver
to get at least some "A"s
"Interesting that I do not have this issue with my BS2 collection. I used the BS2 code published with the units and it worked without a hitch."
Your also not dealing with the 3.3V to 5V voltage level issues with a BS2. This makes a big difference, and the resistor divider is important when interfacing to the Propeller. But still, the BS2 collection issues a transmitter/receiver wakeup sequence before it starts sending actual data("UUUU!"), and the receiver uses a wait command to detect a sync character("U!"). There is a reason for that as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
During my fiddling period I considered the 5v issue and inserted a 3.3v-5v leveler circuit that I use on other devices ... still did not work.
I have taken into account the wakeup sync and even though a single * is enough to lock both tx and rx in sync using simple_simple, now that I am bufering - thanks, I have expanded the code to multiple characters. Wrote two sets of code using simple_serial and fullduplexserialplus and simple_serial is the only one what works.
I do not know why this is the case. So if you can explain to me why one works and other one does not it would further my understanding of serial wireless communication.
"...if I remember right Beau mentioned that simple_serial can not be configured for inverted or open drain-mode." That's only a concern when using the Transceivers in a bidirectional mode because of the shared nature of the pin. When doing so, the transmit pin MUST go into a HiZ mode when not transmitting or you won't be able to receive a signal on the receive pin.
Earl Foster,
I ran all possible code variants and RF unit configurations ... and all passed. The only thing that I did is change the Rx and Tx pins... on my setup Rx is pin 7 and Tx is pin 5.
Use this schematic when using the RF transmitter (#27980)
4.7K 1K
+3.3V >---/\/\---o---/\/\---> DATA
|
TX >----------o
Vss >---------------------> GND
+5V >---------------------> +5V
Use this schematic when using the RF receiver (#27981)
4.7K 1K
GND >---/\/\---o---/\/\---> DATA
|
RX >----------o
Vss >---------------------> GND
+5V >---------------------> +5V
Use this schematic when using the RF transceiver (#27982) as a Transmitter
330
TX >---/\/\---------> DATA
Vss >----------------> GND
+3.3V >----------------> TX-RX
Use this schematic when using the RF transceiver (#27982) as a Receiver
RX >------------------> DATA
Vss >------------------> GND
Vss >------------------> TX-RX
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/16/2009 6:57:51 PM GMT
I tried your suggestion and it would only work if the RX code was using simple_serial. I tried running through the binary count 0000 - 1111 on the receiver code using FDX+ but it would not sync.
Beau, I do not know what to say ... perhaps its my test board but the units refuse to sycn using FDX+.
I started with pin0 and have moved to various pins since. I have also tried both sets of TX/RX units and interchanged the pairs. And this is the only circuit being used to eliminate the possibility of something else is the design interfering.
I guess I will put together a new breadboard version including the Prop and see what happens.
several hours later ...
I took some oscope readings of my working code and non working code. I do see some noise in the received signal and a slight shift but I am not sure what to do about. I have tried using caps on the input signal but that didn't do anything except change the waveform.
i have been away for a while had a rough end of the year.
i have been looking over the code and have it wroking from earlyer posts but i can not see how i can send a caracter.for exmaple i wanted to send "I am here" or"a tempeture 86 degrees. Can anyone point me in the right direction for this
Comments
if you start changing the code - the SUM of time you need to get it working again can
- be low if you do it step by step (for you I emphasize micro-pico-steps)
- be high even higher than going on with transmitter and receiver if you keep changing things
without testing it and understanding it
when I started programming as a 15 year old boy I did it the same way as you
and the projects turned out to take a lot of time until they worked
Then I got a som ehour per week job in a company in programming and they showed me how
to do it STEP BY STEP and from then on my projects finishes faster and faster the more I did
them STEP BY STEP.
Every single step to understand the code and to test it intensivly took
time and in the beginning I thought "hey why don't they just threw it together in one hour ?"
Why am I forced to test everything intensivly ? well the three hours testing saved me three days
of beeing confused. And so in the long run it saved a lot of time spending time on testing EVERY DAMMED DETAIL
on its own. If a program compiles ist just 20% of that it does what you intend to do it.
Your free to spend another 160 Dollars for two transceivers wait a week until they arrive and then
messing around another month until you get it half working
I recommend to do it in micro-pico-steps and test EVERY DAMMED DETAIL
this will take 4 or 5 days but then it will work
best regards
Stefan
you are correct "the quick answer is: as long as you just use the working democode it will work right after downloading to the EEPROM"
but take this for exmaple if you went out and bought a car but they gave you all parts and said figure it out dont ask for help just figure it out.without any instructions AKA road map.
Are you telling me you would try to put the car together without asking for any help? I would roll with you but i dont think we will roll far.But thanks StefanL38 i know you are geting tired of this post i am still willing to learn and will always learn things the rest of my life not the same stuff i hope but new stuff.Awesome job Beau Schwabe (Parallax) you created a object for the transivers no dout that will help a lot of pepole havein issues with it.
Once agian thanks to all of the pepole who posted on this topic, you may not belive me but i am tring very hard and will pump up my effort to make it work
to stay in your picture with the car as a construction-set:
A newbee would start putting the parts together in a way that he thinks this should go.
An experienced "car-builder" will do it a different way.
The newbee maybe starts with "I want the engine running !" And he quickly starts to build the enginge.
Now the engine LOOKS finished but in his hurry he forgot to include some small parts of the electric-motor
that starts the enginge. Now he can press the start-button as often as he wants the enginge doesn't start
Now asking for help saying just a few words "I connect to the powersupply but nothing happens"
The experienced "car-builder" answers "you forgot this small cable from A to B"
Dooh ! and in a hurry he rips off everything around the electric-starter to add the cable
put all together again.
Press the startbutton the electric-starter is running but the enginge still doesn't start.
You do a recheck:
fuel connected
cylinder-head tightend and sealed
....
.....
...
hm everything ok WHY DOES THE ENGINE NOT START ?
The newbee did NOT understand ENOUGH how the connection between electric-starter and enginge works.
So he put together two small parts in the WRONG ORDER because he did not understand how this DETAIL
works.
Now the way to find out how it works is not to buy another kind of electric starter that is well known as working
the way is to put together only the parts of the electric starter and test the electric starter
on its own to REALLY understand how the starter works and how all the parts have to be put together
next step is the engine.
NOT running but test the functionality by turning the cylinders up/down by hand
checking all cylinders working, all valves working adjusting the valves etc.
Here I want to emphasize ones more my impression is your way is
to put all the parts of the enginge together without adjsuting the valves without sealing
the cylinder-head
the engine starts running but it runs bad stops after a few seconds or minutes...
you are asking for a detail like "what type of cyliner-head-sealing do I need?"
answer sealingg-type xy
but it is still not running because you do not understand how to adjust the valves
you do not understand 2)
you do not understand 3)
you do not understand 4)
etc.
From the code that you attached somebody with experience can see
He knows not very much. There are basic bugs in it
To use the picture of the car again:
there are bugs like if you forgot to put on the wheels of the car
or less obvious like you forgot the gearbox or you put together th etooth-wheels of the gearbox vice-versa
because you don't understand enough of th egearbox
at programming it is NOT so obvious where the bug is (like it is obvious than forgetting the gearbox)
So the way to learn programming is not to "buy a complete construction kit of a car" (your complete code)
But to buy a bicycle construction-kit understand how this works. And then start modifying the bycicle
to transform it to a leightweight motorcycle
then modifying the leightweight motorcycle to a heavy motorcycle
and then modify the heavy motorcycle to a leight-weight car
etc. etc.
I got the impression that you are not patient enough to do all these "in between steps".
You want to START with the complex car construction-set
The programming of these "inbetween steps" don't last so long as building a bycicle, a leight-weight motorcycle etc. etc.
each step takes 30 Minutes to maybe two or four hours and then comes the next stage
I took a look on where this thread started it is for weeks ago.
If you would have followed my suggestions your project would have run after three weeks.
Now you are fiddling four weeks and it is still not working. Impatience slows you down
But I got the impression that you don't believe me and that it will take some more time until you do so
best regards
Stefan
1. get the TX working and outputing to screen
2. get the RX working and output to screen
3. display it on my LCD (easy)
What small test code do you think i need to write that will help me with this issue i am haveing?
Post Edited (chris jones) : 11/24/2009 4:03:40 PM GMT
1. get the TX working and outputing to screen
2. get the RX working and output to screen
3. display it on my LCD (easy)
What small test code do you think i need to write that will help me with this issue i am having?
Step 1 - The TX side does not output to a screen, so 1 & 2 work with the DEMO examples I have provided, but don't forget the schematic modification so that it will work with the RF transmitter and RF Receiver units. Get that part working first.
RF Transmitter(#27980):
4.7K 1K +3.3V >---/\/\---o---/\/\---> DATA | P7 >----------o Vss >---------------------> GND +5V >---------------------> +5VRF Receiver(#27981):
4.7K 1K GND >---/\/\---o---/\/\---> DATA | P6 >----------o Vss >---------------------> GND +5V >---------------------> +5VStep 2 - Since the Receiver side does output to the screen, It should be a simple matter of re-directing that output to your LCD instead.
Step 3 - If you want the Transmitter to output to the screen, look at the Receiver side as an example to see what it's doing and then make appropriate modifications to the Transmitter side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
is the connection setup i have correct?
It's really difficult to tell from your picture what is connected to what. Using the RF Transmitter and RF receiver, your setup should look something like the attached images. If you are using the RF Transceiviers your connection should look like what Michael O'Brien posted (btw - Thanks Michael)
Your code in either setup case should be running the same demo, the only difference is a slight modification in hardware wiring.... i.e. the TX DEMO on the Transmitter, and the RX DEMO on the Receiver.
Here is a link to the DEMO software that should be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/25/2009 3:59:36 PM GMT
BUT---- in my debug window on the reciver side all i get are 0's? and ideal why
you are the master Beau Schwabe (Parallax) my LED's are blinking
ok now i have a few questions the transmitter is not hooked to a pin on my propeller boardit never will need to be hooked or assigned a pin if i dont want to display out a counter etc...
next i will play this weekend and see if i can run both transmitter and reciver on the same board but recive from another board . can i use cogs for this or will it send it to the same board ?
anywho i am happy and will star to play with the code and understand it a bit more you are awesome Beau Schwabe (Parallax)
ok i answered my question i unhooked the transmitter from vss and hooked to pin 7 and i get outputy on the reciver side· with numbers AWESOMENESS
Post Edited (chris jones) : 11/25/2009 6:01:48 PM GMT
from your picture we can see that you are using a demoboard.
The picture is not sharp enough to see into wich connection
you plugged in the wires named RX PIN 1, TX PIN 2
In the attachment you find three SPIN-programs
one for a receive-test
one for a send-test
and one for a send and receive-test with one and the same prop
through a closed loop on two IO-pins
connect your two demo-boards DIRECTLY with each other.
One running the send-code the other running the receive-code
both codes make an DIFFERENT LED flash to give a feednback about sending/receiving a byte
so if the LED flashes you know the programs and the connection is working
As a second feedback you can start PST.EXE with 115200 baud to see the debug-messages
try this and come back with questions if something does not work
best regards
Stefan
did you test my program with RF-units ? Did you connect the demoboards on PIN7 ?
If yes with the RF-Units you need a different mode in the call of serial.start.
If I remember right WITH RF-Units you need not mode 0 but mode %1100
So this is an example how a hardware-related problem makes a software behave strange
if ONE single parameter is wrong.
I tested it on my propeller-professional-development-board (PPDB)
If you connect your demoboards DIRECTLY with one wire from Prop1 PIN7 to Prop2 PIN7 it should work
If it is NOT connected on the right PIN the FullDuplexSerialPlus-Driver receives zeros all the time
Or if you use the send-receive-code and connect PIN6 directly with PIN7 on the SAME demoboard it should work
best regards
Stefan
sorry for the lond delay on my post over the holiday i had a breakin and lost a lot of my code and stuff so i think i am back in working order kinda and will post some questions i have.
If you don't include the Propeller.EXE this will be less than 100kB per archive
To state the obvoius: did you download the latest uploaded codeversion ?
best regards
Stefan
{{BasicRX.spin Using RF Receiver #27981 4.7K 1K GND >---/\/\---o---/\/\---> DATA | P14 >----------o Vss >---------------------> GND +5V >---------------------> +5V }} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 obj RFReceive: "simple_serial" debug: "FullDuplexSerialPlus" PUB main RFReceive.init(14, 15, 9600) Debug.start(31, 30, 0, 9600) waitcnt(clkfreq/1000+cnt) 'Start the debug terminal repeat debug.dec(RFReceive.rx) 'Store the bytes debug.tx(13){{BasicTX.spin Using RF Transmitter #27980 4.7K 1K +3.3V >---/\/\---o---/\/\---> DATA | P0 >----------o Vss >---------------------> GND +5V >---------------------> +5V }} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 var byte i OBJ RFTransmit: "simple_serial" PUB Main RFTransmit.init(1, 0, 9600) waitcnt(clkfreq/1000+cnt) repeat RFTransmit.tx("*") repeat i from 0 to 10 RFTransmit.tx(i) waitcnt(clkfreq/10+cnt)What is being displayed is very different from what is being sent, however, I can see that it is following the proper pattern (see debug1.jpg attached).
You may notice that I am using the simple_serial.spin object. I have also tried using the FullDuplexSerialPlus.spin object with different results being displayed in the PST (see debug2.jgp attached).
I have used these modules before with my BS2 and Prop. The BS2 was transmitting wind speed and direction from a vortex anemometer with the Prop using simple_serial.spin to receive the data, format and display the data to a LCD. This project worked without any issues so this would lead me to believe it is the way the data is being transmitted that is causing the problems.
I could use some help.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET
"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
Simple Serial won't work because the Transceiver needs to operate in an open collector mode and Simple Serial won't let you specify that particular mode... I don't think.
FullDuplexSerialPlus should let you specify the proper operating mode. The line that reads...
Debug.start(31, 30, 0, 9600)
...in your code should look like this to do so...
Debug.start(31, 30, %1100, 9600)
...A breakdown of the mode variable looks like this...
mode bit 0 = invert rx
mode bit 1 = invert tx
mode bit 2 = open-drain/source tx
mode bit 3 = ignore tx echo on rx
...By specifying %1100 for the mode, tx and rx are true, with open drain selected, and ignore echo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET
"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
The wireless units...
transmitter(#27980)
receiver(#27981)
transceiver(#27982)
...Do not behave like live wires....
If you make the transmitter pin go HIGH, the receiver pin will go HIGH, but
If you make the transmitter pin LOW, the transmitter doesn't actually transmit and the
receiver is suseptable to receiving anything (noise). The receiver does go LOW but it times out
after a few ms of not receiving a signal from the transmitter. This timeout is enough to encompass a single bit-width of data at 9600 baud.
Because of this you need to have some sort of "wakup" pulse prior to a sync character in order to expect to receive anything meaningful ...especially after periods when you are not transmitting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Thanks for the code but it would only display 0's on the screen. I fiddled around with it for a while then took a step back, revisited my code, and incorporated your buffer routine. After getting that to work I started making small changes, like using FullDepluxSerialPlus, which broke the code again. Went back to simple_serial with a baud rate of 9600 and it is working again.
Interesting that I do not have this issue with my BS2 collection. I used the BS2 code published with the units and it worked without a hitch. It looks like it comes down to the way the serial commands are implemented in pbasic verses spin.
I will keep playing for a while, then perhaps I will try the xbee's I have on hand.
thanks
latest code attached.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET
"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
if the reason why your setup does not work si waht Beau has described, then you should get a almost right receiving if you send
multiple characters at one time.
instead of
do
RFTransmit.str(string("AAAAAAAAAA"))and have a look what you receive
10 characters should be enough to wake up the receiver
to get at least some "A"s
best regards
Stefan
"Interesting that I do not have this issue with my BS2 collection. I used the BS2 code published with the units and it worked without a hitch."
Your also not dealing with the 3.3V to 5V voltage level issues with a BS2. This makes a big difference, and the resistor divider is important when interfacing to the Propeller. But still, the BS2 collection issues a transmitter/receiver wakeup sequence before it starts sending actual data("UUUU!"), and the receiver uses a wait command to detect a sync character("U!"). There is a reason for that as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I have taken into account the wakeup sync and even though a single * is enough to lock both tx and rx in sync using simple_simple, now that I am bufering - thanks, I have expanded the code to multiple characters. Wrote two sets of code using simple_serial and fullduplexserialplus and simple_serial is the only one what works.
I do not know why this is the case. So if you can explain to me why one works and other one does not it would further my understanding of serial wireless communication.
thanks
jpg comparison of code attached
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET
"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
if I remember right Beau mentioned that simple_serial can not be configured for inverted or open drain-mode.
if simple serial is working and FDX+ is NOT working with mode %1100 this would mean that your hardware does work different than Beau mentioned.
As a quick test: can you test FDX+ with mode %0000 again ?
best regards
Stefan
"...if I remember right Beau mentioned that simple_serial can not be configured for inverted or open drain-mode." That's only a concern when using the Transceivers in a bidirectional mode because of the shared nature of the pin. When doing so, the transmit pin MUST go into a HiZ mode when not transmitting or you won't be able to receive a signal on the receive pin.
Earl Foster,
I ran all possible code variants and RF unit configurations ... and all passed. The only thing that I did is change the Rx and Tx pins... on my setup Rx is pin 7 and Tx is pin 5.
Use this schematic when using the RF transmitter (#27980) 4.7K 1K +3.3V >---/\/\---o---/\/\---> DATA | TX >----------o Vss >---------------------> GND +5V >---------------------> +5VUse this schematic when using the RF receiver (#27981) 4.7K 1K GND >---/\/\---o---/\/\---> DATA | RX >----------o Vss >---------------------> GND +5V >---------------------> +5VUse this schematic when using the RF transceiver (#27982) as a Transmitter 330 TX >---/\/\---------> DATA Vss >----------------> GND +3.3V >----------------> TX-RXUse this schematic when using the RF transceiver (#27982) as a Receiver RX >------------------> DATA Vss >------------------> GND Vss >------------------> TX-RX▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/16/2009 6:57:51 PM GMT
Beau, I do not know what to say ... perhaps its my test board but the units refuse to sycn using FDX+.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET
"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
Not sure what to say either... the code that I used is attached to my previous post.
Have you tried another RX TX pin by chance? Is there anything else connected to it? IOW are you sharing it with something else in your design?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I guess I will put together a new breadboard version including the Prop and see what happens.
several hours later ...
I took some oscope readings of my working code and non working code. I do see some noise in the received signal and a slight shift but I am not sure what to do about. I have tried using caps on the input signal but that didn't do anything except change the waveform.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
WWW.HAPB.NET
"Don't ask yourself what the world needs - ask yourself what makes you come alive, and then go do it." - H.T.Whitman
Post Edited (Earl Foster) : 12/16/2009 9:33:23 PM GMT
i have been away for a while had a rough end of the year.
i have been looking over the code and have it wroking from earlyer posts but i can not see how i can send a caracter.for exmaple i wanted to send "I am here" or"a tempeture 86 degrees. Can anyone point me in the right direction for this
PUB TX_Main RF.Initialize(PacketLength) repeat 'RF.PutTX(0,testStr) RF.PutTX(0,Num++ & $FF) RF.PutTX(1,Num>>1 & $FF) RF.PutTX(2,Num>>2 & $FF) RF.PutTX(3,Num>>3 & $FF) RF.PutTX(4,40) RF.PutTX(5,50) RF.PutTX(6,65) RF.PutTX(7,70) RF.PutTX(8,80) RF.PutTX(9,90) RF.Sendthis is the code that sends the counter and i have attached the full code to see if anyone can help
Post Edited (chris jones) : 1/3/2010 5:30:15 PM GMT