Detecting that 433mhz transmitter is out of range

A

Andy1967

New Member
Hi again all,

I would like to use a radio transmitter/receiver setup to detect whether a bike or other object has been moved out of range.

At the moment I am just sending a single bit of data from the transmitter every 100ms which keeps an LED lit but when I take the trnsmitter out of range I want the LED to switch off.

The problem as I see it is that the receiver code only reacts to info read in so when the transmitter is out of range the bit of info is not actually 0 but instead is nothing.

Any help please, my current code is below

***TRANSMIT***
main:
b0 = 1
serout 0, n2400, (85, 85, 85, "safe", b0)
pause 100
goto main

***RECEIVE***
main:
serin 3, n2400, ("safe"), b1
if b1 = 1 then safe
low 2
goto main
safe:
high 2
goto main
 
C

cvrwy

Member
Andy.........

On my project, using the Xbee transceiver, I too had that question in my mind. I have found that the only fool-proof method is to use two-way communication. Using one-way communication, neither unit will realise if/when the other dies or gets out of range.
 
K

krypton_john

Senior Member
Andy, if I understand correctly, the issue is that your receive loop simply remains blocked waiting in a receive when the transmitter goes out of range (or off)?

If so you could use hserin on a 28X1 or 40X1 with a timeout set to jump to a label if no message is received.
 
C

cvrwy

Member
Andy.............

I'm using the 28X1 for the reason krypton_john put to you......
See if my master and slave coding makes sense to you..........
Code: 
'
'Code for main unit
'
#picaxe    28x1
'
setfreq em16
'
Main:    
serout 0,T9600_16,("M",b1,b2)
pause 30
serin [1500,nolink],7,T9600_16,b0
goto linked
'
Nolink:
'
'Put no link code here
'
goto main
'
Linked:
'
'Put linked code here
'
goto main





'
'Code for slave unit
'
#picaxe    28x1
'
setfreq em16
'
Main:    
serout 0,T9600_16,("S")
pause 30
serin [1500,nolink],7,T9600_16,b1,b2
goto linked
'
Nolink:
'
'Put no link code here
'
goto main
'
Linked:
'
'Put linked code here
'
goto main
 

Attachments

Last edited:
lbenson

lbenson

Senior Member
Another option is to have an additional transmitter sending on a regular basis to break you out of serin. Then you can check to see if you have not received a transmission from the bike within a certain time period. Multiple transmissions with differing delays might be needed to reduce the possibility of losing transmissions because of collisions.
 
S

SD2100

New Member
If you are using anything smaller than a 28x1 for the receiver you'll get the serin command hanging problem, it's ok while you are receiving transmissions from the bike but when they stop serin will sit and wait instead of setting the alarm off. One option is to have a timer attached to the receiver picaxe such as a 555 or another picaxe etc, if this timer dosn't get regular pulses to keep it reset then it times out and sets the alarm off similar to a watchdog timer.
 
Last edited:
A

Andrew Cowan

Senior Member
I would use two 08M at the recieving end.

Code: 
main:
serin 0,n2400,(85,85)
high 1
pause 100
low 1
Other 08M:
Code: 
check to see if the pin is pulsing.  If it stops low, goto alarm.
A
goto main
 
M

manuka

Senior Member
That 2 x 08 approach is probably the most rugged SERIN hangup beater, but a recent use of PULSIN (which times out! ) may have some mileage. I've written this up as an 2nd HopeRF article for the April "SiChip" - resources are already at => www.picaxe.orconhosting.net.nz/hoperf.htm Stan
 
Last edited:
W

westaust55

Moderator
As a single 08M improvement over you original code here is a possibility:

Code: 
; ***RECEIVE***
Init:
  ; first a 1 second LED pulse to show PICAXE is working
  HIGH 2
  PAUSE 1000
  LOW 2
Main:
  PAUSE 200
  SERIN 3, n2400, ("safe"), b1
  IF b1 = 1 THEN
    HIGH 2
    PAUSE 1000 ; turn LED on for 1 second
    LOW  2
  ENDIF 
  PAUSE 1000   ; turn LED off for 1 second before repeating cycle
  GOTO Main
If you do not have the LED flashing for 1 second on a 2 second cycle then the transmitter is obviously out of range or the battery is flat.

Another option is to think about the interrupt method.


Code: 
#PICAXE 08M
;***TRANSMIT***
;main:
;b0 = 1
;serout 0, n2400, (85, 85, 85, "safe", b0)
;pause 100
;goto main

; ***RECEIVE***
Init:
  ; first a 1 second LED pulse to show PICAXE is working
  HIGH 2
  PAUSE 1000
  LOW 2
  SETINT %00001000, %00001000 ; to interrupt when input 3 is high
  
Main:
  DO
; can do something else here if you want
  LOOP
  
Interrupt:
  SERIN 3, n2400, ("safe"), b1
  IF b1 = 1 THEN
    HIGH 2
    PAUSE 1000 ; turn LED on for 1 second
    LOW  2
  ENDIF 
  PAUSE 1000   ; turn LED off for 1 second before repeating cycle
  DO 
  LOOP UNTIL pin3 = 0 ; wait until pin 3 is low before returning to main do loop
  SETINT %00001000, %00001000 ; restablish the interrupt for next cycle.
  RETURN
 
Last edited:
M

manuka

Senior Member
"Are you still there?" approaches often relate to application needs- tracking aircraft or wandering children/animals etc. My terrier dog "Jack" can get up to all sorts of mischief in just seconds if accidentally off the property! Bikes can be miles away by the time you respond of course too, yet (say) wandering Alzheimer oldies/yachts/wheelchairs/teenagers sleeping in etc will be pretty pedestrian.

Hence what is it that you're tracking? A bike? How crucial is a rapid alert? PICAXE "sleep" is energy efficient but will miss sudden changes, yet power drain from winking LEDS & rapid TX pulses can be significant. A flat battery may give a false conclusion, so you need to make the system fail safe. A contact "return" needs prompt alerts, so as to avoid a search & rescue false alarm.

I'd say a winking green LED for "safe", & faster red + audio tones for "escaped" may better suit. Stan
 
T

Taniwha

Senior Member
Not a Picaxe solution but...

have a look on Google for "555 missing pulse" or "555 circuits". When i started playing with 555's, i found a cicruit to do exactly what you are asking, it was simply a timer that was reset by the RF pulse, if it did not get the pulse within the time period it would change out put from low to high (or vice versa). This could actually drive two LED circuits, a "safe" and an "alarm".
This was, i believe designed for R/C models, particulary aircraft, to ensure that they shut down if they flew out of signal range.

In NZ at least this would be a cheap option if you did not require logic on the output side.
 
M

manuka

Senior Member
Agreed - RC discharge or 555 missing pulse approaches indeed have appeal! Fellow Kiwi Andrew Hornblow trialled a similar RC combo (to beat the SERIN timeout), but I don't recall the clever FET addition.

433 MHz is often festooned with all manner of digital data transmissions, so a potential weakness with such OOR (out of range) one way simplex systems may arise. This relates to other 433 MHz signals being considered as if they were valid transmissions by your setup. Masking out such 3rd party "noise" by specific preambles & qualifiers may be called for- if possible.

Such false "All OK" systems have a lengthy tradition of mischief- incorrectly positioned navigation aids causing ships to run aground etc. Aside from such Victorian stings, British 1940s spoofing of Luftwaffe WW2 bombing beams was particularly notable for fooling the unwary -Google for R.V. Jones "Most Secret War" - an classic ripping yarn! The recently missing "Arctic Star" freighter may have stooped to similar skullduggery with it's AIS transponder too. Fail-safe considerations & even 2nd opinion verifications may be needed with simplex links!


2 way ½-duplex approaches may show greater reliability, using HopeRF transceivers perhaps. Try the PULSIN approach shown below (although it too may be fooled by other 433MHz activity) -
Code: 
'Simple HopeRF HM-TR TTL half duplex data exchange-Stan Feb.09
'PICAXE08M "Pin"1 -HopeRF TTL pin 6 (ENABLE),and status LED
'PICAXE08M "Pin"2 -HopeRF TTL pin 4 (DRX) data input from 08M
'PICAXE08M "Pin"4 -HopeRF TTL pin 2 (DTX) data output to 08M
'Uses PULSIN command as a handy timed out signal sensor.
'Consider PICAXE brown out detect (BOD) if v9.2 08M firmware
'Ref.schematic=> www.picaxe.orconhosting.net.nz/hopettlapp.gif
'Breadboard=> www.picaxe.orconhosting.net.nz/hopettlapp.jpg

hopettl:
high 1                   'bring HopeRF out of hiberation
serout 2,t2400,(85,85,85,85,"ttl",b0) 'tx beacon
pulsin 4,0,b1            'listen & briefly await any reply
if b1=0 then hopettl     'if nothing heard then resend beacon

serin 4,t2400,("ttl"),b0 'if signal heard then accept serial data 
low 1                    'enter low drain TTL sleep 
sleep 13                 'PICAXE low current SLEEP (~30 secs)
goto hopettl             'repeat routine
Refer diverse HopeRF insights & setups => http://picaxe.orconhosting.net.nz/hoperf.htm
 
Last edited:
You must log in or register to reply here.
Top