I have this code and am trying to send data between 2 18m2's. I can't get it to receive the packet and the debug is giving me random values in the registry. Can anyone spot an issue.
Code:
Receiver:
Main:
serin b.2, n2400, (b0,b1,b2,b3,b4,b5,b6,b7)
debug
goto main
I can't find any details of the RF modules you've used - but if the receiver has an 'adjuster' on it, swap it for one that hasn't!
(If it is adjustable, when was it last adjusted - and how will
you adjust it in future, when it drifts out of spec?).
The accepted wisdom seems to be that Superheterodyne receivers give superior performance to TRF designs. The presence of an 'adjuster' in itself, doesn't distinguish one from the other, but the Superhet. designs -being more expensive -
seem to always use a crystal or other resonator technology and
tend not to have one. My receiver of choice is the "Hope RFM210LCF-433D-A" (or whatever their latest and greatest new model is).
One advantage of the Hope receiver, is the drastically reduced, background noise, in the absence of a signal. It certainly isn't zero, but is much less than you get from most of these devices. (The transmitter spends most of its time, powered OFF. In the absence of a signal, the receiver winds its gain up to max. and listens as hard as it can. The result is a constant stream of noise).
This background noise, is the essence of your problem. Commercial 315MHz/433MHz devices send a 'preamble' to 'condition' the receiver, so it can adjust its AGC and start to produce a signal that matches that being sent. Without it, the first few bytes of any transmission are lost/garbled or otherwise mis-interpreted. Once this step is complete, there will normally be a known 'Message Start' sequence, then the data itself, followed (often) by a CRC. The receiving program waits till it sees the 'Message Start' and discards all data (ie Noise) up until that point. The CRC is used to perform an integrity check on what has been sent.
In your sample program,
Serin
will be seeing all manner of junk coming out of the Receiver - and every now and then, it will think it's seen a valid RS232 character. When it believes it's seen 8 of them, it completes and
debug
prints the baffling result. It's just random, background noise
It's also accepted wisdom in most quarters, that you shouldn't even try to send RS232 data via RF, but lots of Picaxer's have succeeded, so we'll perserve
Your sending program needs to send a preamble first. Use a short string of "*" or "U" characters (in binary, these are both alternating zeroes and ones and serve to condition the receiver). Then send something that signifies the start of the message, like "ST". (A longer string increases the selectivity of the message detection (less likely to be generated by chance), but is more likely to get lost/distorted, I suppose.)
Finally, unless the data is fixed length, you'll want something to signify the end of it. Personally, I would then follow it up with a CRC (or at least a Checksum) of the data.
(I experimented with
RFIN/RFOUT
myself, and while they 'help', they can't fix noisy comms. by themselves.)
The Receiving program's
SERIN
now needs a tweak. First of it needs to use the 'qualifier' to wait until that 'Message Start' sequence shows up. Use of a
Timeout
parameter, is a good idea, just in case any data gets lost. A carefully-tuned, very short timeout is a first line of defence against data going missing in mid-message.
Then, of course, it should check that CRC...
There is an easier way - it's called
the HC-12!