this makes no sense at all

lenny1337

If someone can tell me why this happens ill be really darn impressed.

The project i'm working on requires three independent units communicate over RF to a central unit. The way i set it up is they keep transmitting and listening for the head unit to ping their name back - in which case they'll know that the transmission went through.

heres a section of the code:

send:
namen = 0
PAUSE (name)
GOSUB blink
PULSOUT 15, 1200
SEROUT 15, 16468, [noparse][[/noparse]"!x!", counter.HIGHBYTE, counter.LOWBYTE, name]
SERIN 8, 16468, 40, send, [noparse][[/noparse]WAIT("!!!"), namen]

IF (namen <> name) THEN
GOTO send
ENDIF

however, it stops 'blinking' after two or three times regardless of whether the central unit is on or off. if its on, then it pings and only takes about one run through for the data to get through. If its off, then it might blink three times or four times, or 8 times, but it will always stop blinking.

HELP

Post Edited By Moderator (Chris Savage (Parallax)) : 7/26/2007 5:39:50 AM GMT

Larry

We need the rest of the code

You don't show how name, namen and counter are defined, why namen is reset each time, or what values for namen can be expected in the Serin statement

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

stamptrol

lenny,

Overall, what you want to do is pretty reasonable. Don't quite see why you PULSOUT the same pin you are using for serial comm, though.

But, I think with the field units all just blasting away, your chances of success are less than if you let every field unit just sit and listen. When a field unit sees its unique id, it will send data back to the central unit. At that point, if you want to do a check of some kind, you have the conversation limited to a single master-slave.

To set up a classic master-slave arrangement, in your SEROUT line, let "!x!" be a unique address for one slave. When the appropriate slave sees the address, it responds, and the master's SERIN command grabs whats coming in and either stores the info or acts on it. Then the master fires out another SEROUT with another unique id and a second slave responds, and so on.

Doing it this way gives predicabilty to the communication. This system has worked for me with 5 or more slave units, wired or wireless communication.

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

lenny1337

thank you for the reply. the only issue i have with that is that the central unit does now know when the slaves are done with their calculations....only they do

Tracy Allen

What kind of radios are these? If they are simple ones without built-in error checking and automatic retry, then there can be trouble with the SERIN command. Unsquelched noise at the input continuously resets timeout. Any random noise in the 40 milliseconds will reset the SERIN time-out. The fact that you don't see any blinking after the first few tries indicates that something like that is happening. Of course, I haven't seen the rest of the code. A lot depends on the transmitter and the signal strength. If the signal is fairly strong, the transmitter can send a preamble that silences the data slicer, then comes your WAIT string and then your data. The same thing must happen in the transmission from the slave back to the master, but I don't see any preamble in what you posted. It starts right in with the "!1! ... ". The usual preamble is something like $5555 to give an alternating pattern of 0s and 1s to center the data slicer.

Could you give an idea of what the time spans are for "when the slaves are done with their calculations.". If that is a relatively long and random time then it is possible to have multiple devices with little (but finite, as you know) chance of collision. A statistician can calculate the odds.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

lenny1337

Thanks for the reply - this is really helpful information, i think you're absolutely right and thats what's happening. The antennas i'm using are these:

http://www.parallax.com/detail.asp?product_id=28180

and i have a total of 4 receivers and 4 transceivers...when you say to send a preamble to silence the data slicer do you mean litterally send a string of data - 5555?



The three units are done anywhere from 500ms to 2s. They do finish at random times· - it is essentially these times that i am broadcasting. When they're really close together they finish almost simultaneously, however when they're far apart there is a significant pause between terminations.

The way i do it now is pause a function of these times between transmisisons which keeps collisions at a minimum.

Tracy Allen

Another thing, you are trying this at 9600 baud, but that could be trouble. Try it at 2400 baud first.

The preamble is a binary pattern of %01010101..., which happens to be the number 5=%0101, or HEX $55 for a whole byte. The AM transmitter is keyed on an off repeatedly and the receiver can see that and set its automatic gain to the optimum level to "slice" between the zeros and the ones before it gets to the meat of the transmission. So your transmission would look something like this:

SEROUT 15, 16870, [noparse][[/noparse]REP $55\3,"!x!", counter.HIGHBYTE, counter.LOWBYTE, name] '<- note change to 2400 baud

What that does is send 3 repetitions of the on off pattern, then your ID header and then your data. Three repetitions should do it, but even one might work. On the receiving master end the SERIN command ignores the repeating pattern but has a WAIT("!x!") and then receives the data bytes. When the master transmits, it does the same thing, REP $55\3 preamble followed by the unique handshake that you have as WAIT("!!!"),namen".

The SEROUT above sends 8 bytes, which will take about 35 milliseconds. Are you doing some kind of ultrasonic+RF positioning system?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

lenny1337

Roger, wireless positioning system but not ultrasonic - light based. When all is squared away ill be happy to send you a little video of the prototype.

Is there a reason i might not want to do 9600? When you say about 35ms for 8 bytes do you mean @ 2400 baud? Also do you know off hand what the correlation for the number in the serout syntax and actual baud rate is?

As I know close to nothing about RF this has been incredibly helpful Tracy, I really appreciate your time.

Thanks again,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lenny Bogdanov
Systems Concept Center

Tracy Allen

I'm not sure about the 9600 baud. The Stamp is an interpreter, and when it receives data, there is a latency period between bytes where it is not ready to receive. In generaal, it will not be able to keep up with strings of data sent to it at 9600 baud. On the other hand, there is also a latency on the transmitter side from the Stamp, as it in effect adds more stop bits to each byte that it sends. Thus, Stamp to Stamp communication is possible at 9600 baud. It is just something to keep in mind if it doesn't work. Another option is to add a millisecond of pacing between bytes transmitted at 9600 baud.

I took a look at the Parallax documents for that transceiver pair and they do indeed use 9600 baud in the BS2 example. Instead of the $55 preample, they suggest a single 2.4 millisecond PULSOUT to the transmitter, and I see now that you have that in your program. I still think that the $55 would serve better if the signal strength drops.

One thing I would change in my suggestion is to separate the preamble from the actual data by at least one byte time, so that there would not be any ambiguity about the start bit.
SEROUT 15, 16468, [noparse][[/noparse]$55] ' one byte preamble followed by delay time before next statement
SEROUT 15, 16468, [noparse][[/noparse]"!x!", counter.HIGHBYTE, counter.LOWBYTE, name] '<- back to 9600 baud,

or with pacing...

SEROUT 15, 16468, 1,[noparse][[/noparse]REP $55,"!x!", counter.HIGHBYTE, counter.LOWBYTE, name] '<- 9600 baud with pacing between bytes.
That would take about 12 milliseconds to transmit.

The manual has the formula for computing baud rate, under SEROUT and SERIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com