communicatioin problems

friis

Senior Member
Hi,
I have a module equivalent to:

Code:
#Picaxe 14M2
#    Edit Post   Quick reply to this message Reply   Reply With Quote Reply With Quote   Multi-Quote This Message  Blog this Post       

Terminal 4800

Symbol TXpin           = B.5
Symbol TXbaud          = n1200
Symbol PreambleLength  = 5
Symbol PreambleByte    = $55
Symbol EOMbyte         = $5C
Symbol Postamblebyte   = $3A

Symbol Data1           = b0
Symbol Data2           = b1
Symbol Dato1           = w1
Symbol Dato2           = w2

Symbol FlashPin        = B.3
		

MAIN:		pause 1000
		sertxd ("Start",cr,lf)
		gosub Flash
		
BEGIN:			
		gosub Flash
		
		Data1 = 11
		Data2 = 1
		
		'convert to word and transmit
		Dato1 = Data1
		Dato2 = Data2
		
		pause 1000
		serout TXpin,TXbaud,(PreambleByte,PreambleByte,PreambleByte,PreambleByte,PreambleByte,"FRIIS",b2,b3,b4,b5,EOMbyte,Postamblebyte,Postamblebyte,Postamblebyte,Postamblebyte)
		
		sertxd ("RecTransTest: ",#b2," ",#b3," ",#b4," ",#b5,cr,lf)
 		
		sertxd ("RecTransTest: ",PreambleByte,"FRIIS"," ",#Dato1," ",#Dato2," ",EOMbyte,Postamblebyte,Postamblebyte,Postamblebyte,Postamblebyte,cr,lf)
		
		pause 1000	
		goto BEGIN

Flash: 
		high FlashPin
		pause 500                                                                              'flash
		low FlashPin
		
		return

/[code]

embedded in SUN and Sat (see the attached sketch).

When I run the above pgm I get in LOG:

RecLogging: 11 0 1 0
RecLogging: UFRIIS 11 1 \::::
RecLogging: 11 0 1 0
RecLogging: UFRIIS 11 1 \::::
RecLogging: 11 0 1 0
RecLogging: UFRIIS 11 1 \::::
RecLogging: 11 0 1 0
RecLogging: UFRIIS 11 1 \::::
RecLogging: 11 0 1 0
RecLogging: UFRIIS 11 1 \::::

It all looks normal.

When I run the systen shown in the sketch with the equivalent modules embedded in SUN and SAT, communications A, B, C, D are OK while E and F only work sometimes. My questions are:

1. Is there something wrong with the module above
2. Can the pgms in SUN and SAT have become too complicated (too many subroutines.....?) I dont think you would get anything out of seeing the pgm listings.

I have spent quite some time fiddling with the pgms in SUN and SAT, with antennas and placement of the breadboards (where it is all installed) without success.
best regards
torben
 

Attachments

Last edited:

hippy

Technical Support
Staff member
It's not clear exactly how you have things set up, whether communications are wired or wireless. From the preamble mention it looks like wireless, so it could be that the RF receivers are tuning into one transmitter and dropping others.

I think we will need a lot more information to figure out exactly what the problem is.
 

friis

Senior Member
Hi hippy,
It is wireless - I am checking the timing of transmissions.
Can the receiver really choose which sender to lock on to? I thought that it would just receive a jumbled mixture of signals.
torben
 

hippy

Technical Support
Staff member
Can the receiver really choose which sender to lock on to? I thought that it would just receive a jumbled mixture of signals.
My limited testing experience a while back showed much as you experienced; two transmitters, one receiver, and that would tend to only pick up from one transmitter not the other unless I powered one transmitter down while the other transmitted.

That was using typical dumb RF modules. Not sure what the explanation was. I imagined RF with just one transmitting at a time would work like any number of car RF key fobs being able to open a car door but it did not seem that way in practice.

One possibility is that I had signal polarities inverted, so the transmitters could have always been sending a carrier and I was looking for loss of signal rather than presence. The receiver syncing and AGC might have been mostly allowing one through but not another.

I think you'll need someone who knows more about actual RF than I do to come by.
 

friis

Senior Member
Hi hippy,
I got the system to work as follows:

SAT: SUN:
TX trans -> RX trans
pause 200 ?
TX log
pause 700 ?
TX log

pause 200 ?

RX trans <- TX trans
pause 200 ?
TX log
pause 1000 ?
TX log
.
.
.

I made it work by suitable use of the pause-statement. Some of the pause-statements are there for timing purposes, but some are longer than needed for that.
It appears that a pause between two consecutive TX and RX statements of at least "pause 200" is needed. That has surprised me.
torben
 

friis

Senior Member
Hi hippy,
What is it I put in for code? I tried to find it on the Forum but I could'nt.
torben
 

The bear

Senior Member
Hi torben,
Post a reply to the thread, go advanced, then you will see '#' symbol, use that for your code.


Good luck, bear..
 

hippy

Technical Support
Staff member
You want this : [code] ... [/code]

And if you want to type that in to appear as above you need this :

[noparse][code] ... [/code][/noparse]
 

inglewoodpete

Senior Member
@friis, The cheap modules can cause all sorts of problems. A receiver won't "lock onto" any particular transmitter. It just decodes any received data that is detected. So, if two or more transmitters are on at the same time, the reception is pretty random. There may be something intelligible received and there may not be. It would help if you could tell us what type of modules you are using. Most transmitters are crystal locked to a frequency but many receiver modules do not have a crystal - my advice is to avoid them.

The receiver code is far more critical than the transmitter. You haven't included your "receive" code in the posting above. Avoid all pauses and blocking commands (excluding the SerIn command, of course), since the law of chance says that the receiver is never ready when the transmitter sends data! That is why I prefer the background serial reception feature of the X2 chips - your code just has to parse the scratchpad buffer for recognisable patterns.

I have had some success with the NKM2401 chips managing the wireless link when using the cheap modules. Which leads to the next question: have you investigated using the RFOut and RFIn commands?

Finally, my wireless module of choice is the HC-12. Once configured, I have found them to be very reliable, even with variable data packet lengths. The HC-12 is a transceiver but can be used as a one-way link if required but I prefer to use the return channel to acknowledge that valid data has been received.
 
Last edited:

friis

Senior Member
Hi hippy,
Thank you
Hi inglewoodpete,
I am using Dorji DRA8,,TX/RX. I hav'nt had any problems with them so far, but I have bought HC-12 and will experiment with them. I am using serin/serout.

I am trying to direct output to different Dorji modules and and receive input from different Dorji modules using different qualifiers/different baud rates within one pgm. So far I have gotten erroneous results - at best.
torben
 

friis

Senior Member
Hi hippy,
It was probably not a good idea to have a test system distributed over 4 breadboards. Anyway, the real system appears to work, but I have to have a "pause 900" between a reception of a transaction and the subsequent sending of a record. Not between the sending of a transaction and the subsequent sending of a record. That surprises me.
Thank you for your help.
torben
 

darb1972

Senior Member
Hello Torben

I echo all of Pete's comments, plus, here are a few of mine. How far apart have you got those breadboards? If the power of the Dorji modules is at max that will definitely result in complete "flooding" or best described as overloading of your receiver.

Frankly I think if you need to have two transmitters and on receiver (or any sort of combination that results in anything more than a simple "point to point" arrangement) then you should consider a mesh arrangement. In a mesh arrangement you can have a "concentrator" module/s (might be where the data originates from) and "nodes" (to either collect and/or distribute the data). The network can be as big or as small as needed. Data can then also be distributed over long distances and/or big areas.

Dorji have a mesh system. I have read much of the literature on these modules and I'm in the process of ordering some for further experimentation. All modules have the smarts and necessary protocols to make the process fairly straightforward. You can completely configure all modules on your computer. Because the modules are "smart" they work in cohesion to distribute data and avoid collisions and pick the best "path" based on many factors including (but not limited to) the best RF path (particularly if the environment is changing) and module power (particularly if run off batteries). They also have an extremely low standby/sleep power usage.

Worth your time to investigate.

Regards
Brad
 
Top