Serin Serout issue on 18M2

Reefrich

New Member
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.

Trans:
main:
symbol TXD = b.5
do
for b1 = 0 to 15
debug
pause 10
serout TXD , n2400 , (b0,b1,b2,b3,b4,b5,b6,b7)

pause 500
next b1
loop

Receiver:
Main:

serin b.2, n2400, (b0,b1,b2,b3,b4,b5,b6,b7)
debug
goto main
 

Reefrich

New Member
I'm using the APF03 Transmitter and the APRXB12 receiver. I've tried the Rfin and RFout command which is what I usually use but with no joy.
 

Reefrich

New Member
You're right, i've removed the brackets, not sure why I put them in when I typed it out on the forum page. Still doesn't like it though.
 

lbenson

Senior Member
I would always try to make communications between chips work with wires before trying RF--make sure you connect 0V between the two chips.
 

Flenser

Senior Member
You said "the debug is giving me random values"
Post some example output from debug so we can see what the receiving chip is reporting.

neiltechsp has already spotted one bug but other than that your code is pretty simple.
When you switched from RF to wires, did you add a connection between the GND pins on the two chips?
One classic reason for getting scrambled characters received is when there is no common ground.

Also take a picture of your picaxes and their wiring and post it so that your connections can be reviewed.
 

PhilHornby

Senior Member
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!
 
Top