The examples in the documentation for the #27982 show a sync pulse of 2.4ms to 3ms. The description indicates that this was chosen to be on the order of one or a few character times which makes sense. 3ms should work for 9600 Baud.
Again, I can't help you with the Arduino libraries. All of Parallax's microcontrollers use software defined I/O. The Arduino has both hardware serial I/O (UART) and a software defined serial I/O library.
Well i got ticked off with all the examples and trying to translate between bs2 code and arduino code so I set about working with it from scratch.
From the datasheet i realized that when the data pin is on receive mode it will float because of the background rf noise . So i decided to program the arduino to just go a constant high when it detects a constant high on the datapin.
I set about broadcasting a constant high on the second arduino parallax. Anyway I was able to get the two to atelast respond one-way. Now i have devise a strategy to see if they are smoothly able to switch between the two modes ( rx/tx) using the debug led on port 13 of the arduino.
PJ, I agree if the OP wants help with a lib he should be asking on the arduino forums.
As to libraries being "Black holes" the source code is part of the library and can be modified at will. (like an object)
The simpler solution is to really learn C (which is what Arduino is hiding) and create your own libraries as required. Libraries are merely a file with a group of related C functions provided within one file to ease house-keeping .... nothing really mysterious.
You can use an existing Arduino library as an exemplar to give you some ideas of the functions you need or want, then revise it to suit your personal needs. In sum, don't be afraid to improve on someone else's code to get exactly what you want or need. In some cases, you can strip an overly complex library and get the useful core that is more handy.
I have NEVER relied on OBEX to provide a complete solution to something I wanted to do. It has just been an exemplar resource that provides the user with proof that an interface is functional, or a concept is doable.
At some point, one has to do more than piece together things that were downloaded over the internet... some thought is often required.
To the OP, I think you will do fine if you just apply the basics rather than all the jargon of BS2 or Arduino.
In other words, this seems to be a half-duplex set up that requires one unit to take the lead and be the master, while the slave listens and only replies after the master queries.
The wiring seems to be a hardware layer that is intended to keep the radios quiet and conserving power when not in use by having the transmitters in a stand-by low power mode. Receivers are not as power hungry and need to be listening at the right times. So that pulse, transmits on one end; and wakes up the receiver on the other end. I suppose that whomever sends the pulse asserts that it is the master for that data exchange -- roles might be swapped.
Try to just get communication in one direction to operate first. Have the transmitter remotely blink an LED, cause a beep, or cause a twitch. Trying to get too much functionality at this stage gets very muddled.
After that, have the remote send an acknowledge that the LED blinked,that the beep occurred, or the twitch occured. If you get that far, you are well on your way.
Comments
Again, I can't help you with the Arduino libraries. All of Parallax's microcontrollers use software defined I/O. The Arduino has both hardware serial I/O (UART) and a software defined serial I/O library.
Well i got ticked off with all the examples and trying to translate between bs2 code and arduino code so I set about working with it from scratch.
From the datasheet i realized that when the data pin is on receive mode it will float because of the background rf noise . So i decided to program the arduino to just go a constant high when it detects a constant high on the datapin.
I set about broadcasting a constant high on the second arduino parallax. Anyway I was able to get the two to atelast respond one-way. Now i have devise a strategy to see if they are smoothly able to switch between the two modes ( rx/tx) using the debug led on port 13 of the arduino.
Do you have any ideas ?
regards
leo
http://www.adrirobot.it/parallax/transceiver/transceiver_interfaccia-arduino.htm
That site has the PCB design also taken from the circuit posted. Prolly some parllax dude can make a pcb for 27982 an make a new product out of it :P
The simpler solution is to really learn C (which is what Arduino is hiding) and create your own libraries as required. Libraries are merely a file with a group of related C functions provided within one file to ease house-keeping .... nothing really mysterious.
You can use an existing Arduino library as an exemplar to give you some ideas of the functions you need or want, then revise it to suit your personal needs. In sum, don't be afraid to improve on someone else's code to get exactly what you want or need. In some cases, you can strip an overly complex library and get the useful core that is more handy.
I have NEVER relied on OBEX to provide a complete solution to something I wanted to do. It has just been an exemplar resource that provides the user with proof that an interface is functional, or a concept is doable.
At some point, one has to do more than piece together things that were downloaded over the internet... some thought is often required.
To the OP, I think you will do fine if you just apply the basics rather than all the jargon of BS2 or Arduino.
In other words, this seems to be a half-duplex set up that requires one unit to take the lead and be the master, while the slave listens and only replies after the master queries.
The wiring seems to be a hardware layer that is intended to keep the radios quiet and conserving power when not in use by having the transmitters in a stand-by low power mode. Receivers are not as power hungry and need to be listening at the right times. So that pulse, transmits on one end; and wakes up the receiver on the other end. I suppose that whomever sends the pulse asserts that it is the master for that data exchange -- roles might be swapped.
Try to just get communication in one direction to operate first. Have the transmitter remotely blink an LED, cause a beep, or cause a twitch. Trying to get too much functionality at this stage gets very muddled.
After that, have the remote send an acknowledge that the LED blinked,that the beep occurred, or the twitch occured. If you get that far, you are well on your way.