HOPE rf Module Parameters Shifting

G

Grant Fleming

Senior Member
After many weeks of faultless operation I had one of my HOPE HM-TR transceivers not functioning, (after much fault-finding with the PICAXE programme and my circuit) I found the freq had shifted from 433MHz to 315MHz band and data rate from 600bps to 9600bps!
I re-wrote back to the modules the parameters I needed and also this time tied the pin 6 (enable/sleep) to +5V.
Originally I didn't have this pin connected at all, don't know if this was the cause but so far -so good.
 
M

moxhamj

New Member
Yikes!. Hey, 433 or 315Mhz, the data still goes through, right? *grin*

I would very much hope (and probably suspect) that a floating pin is the cause of the problem but please keep us posted if it happens again.
 
G

Grant Fleming

Senior Member
Dr_Acula said:
Yikes!. Hey, 433 or 315Mhz, the data still goes through, right? *grin*
Click to expand...
Yeh, if it was that simple - no problem!
Actually nothing gets taken from the PICAXE to HOPE module to start with as the baud of the PICAXE and HOPE are different also. So no transmision, even if there was the other transceiver is set at different frequency and baud.
Anyway, I will certainly let you know if it happens again!
 
M

manuka

Senior Member
Although not to your degree,I too had flakey operations with that floating pin, & in the final "SiChip" article showed it tied.
 
G

Grant Fleming

Senior Member
manuka said:
Although not to your degree,I too had flakey operations with that floating pin, & in the final "SiChip" article showed it tied.
Click to expand...
Yes you did Stan, I have nobody to blame but myself!
Excellent article by the way, I have already begun a half-duplex exchange routine that works well ...timing is everything! Having serin timeouts certainly helps (am using X1 chips, only a few dollars more and makes things much easier).
 
M

manuka

Senior Member
Yah- already under way! Perhaps we can join forces-do you want to post ideas/pix etc so far? Stan
 
M

moxhamj

New Member
Time to get out my Hope modules and do some tests :)

I thought I had replicated this fault too, as mine booted up at 315Mhz. Then I remembered you have to hit the READ button twice as the first time it reads in incorrect values.

Got the programmer working (thanks Stan for http://picaxe.orconhosting.net.nz/txrxconf.jpg).

Next test - measure the current. It measures 45mA when programming and 30mA when running.

Next test - thinking about getting that current down to an average of 1mA, that means a sleep/wake cycle of 29:1. And the Hope module takes about 1 second to wake up (the leds flash), so that means a minimum sleep/wake cycle of 29 secs and 1sec. So any 'low power' unit needs to transmit for at least 30 seconds to wake up nearby nodes. (Anyone running on mains - pls ignore this ramble!)

Next step - get the whole polarity thing worked out. The RS232 Hope modules are 'resting' at minus 9V, so that is the same as the output of a PC. If you run that into a picaxe directly, I think that means N polarity. (resting=0V) If you run it into a max232 and then into a picaxe, I think that is T polarity (resting=5V, which is what UARTs work at so I'm going to go for T polarity.) I'm going to stick with RS232 ones for the moment, even though it means some unnecessary max232s around the place, because I don't want to get confused. The modules are drawing 30mA so of that, maybe 5mA is the max232 on the module, so it probably isn't worth worrying about that.

Step 1 - get a PC to send "Hello" to a picaxe and have the picaxe reply.
Step 2 - get the PC to send "Hello" to a picaxe via a Hope module and have the picaxe reply.

Addit: Re http://picaxe.orconhosting.net.nz/txrxconf.jpg

I had an idea that maybe tying pin 6 high when programming would fix the 1st read error. It didn't, but it did mean the hope module booted up with the red led on. With pin 6 floating the red led sometimes flickered on and off. In running mode the green led is on. So for ease of use, I wonder if it is worth tying pin 6 high for programming as well as for use?
 
Last edited:
G

Grant Fleming

Senior Member
Setting changed again!

Well Stan, I have hit a bit of a snag.
After much head-scratching again after fine-tuning my code I finally discovered that the stop bit # on one HOPE rf module had changed from 1 to 2. This occured on the other module to the earlier module that had the setting shift and with pin 6 being tied to positive the whole time. Changed it back and all has worked fine again (yes Doc A, I know about the pressing of the read button twice).
I had been powering on and off the PICAXE/HOPE units numerous times while adjusting code in each moving programming cable between the two - whether this has caused the shift I don't know but have the feeling that if just left to do their thing once set-up they are stable.
Was just experimenting with half-duplex comms, one remote PICAXE sending a temp reading from a DS18B20 sensor when it was asked to by the base station PICAXE. The temperature being displayed on the PC through the sertxd command and the base station also being able to send an cool or heat request by the operator. Was all working well for a while...
These settings changing have really caused alot of time to be wasted looking for the fault elsewhere (looking at code/timing etc), let alone the frustration! Think I'll give it a rest for a time and try another PICAXE project. I need to have a couple of wins elsewhere before I come back to this!
 
M

moxhamj

New Member
Hmm - when I get home I might try powering one on and off 50 times and see if the settings are still the same.
 
G

Grant Fleming

Senior Member
Please let us know how you go Doc.
Another thing I noticed was that my 3 AA battery pack was a bit low (3.98 Volts) while under load, (the HOPE rf data sheet states 4.5V min & 5 V max) put fresh ones in now of course, but I wonder if that had affected the settings. But really I would have thought once something is written into non-volatile memory it should remain there.
 
M

moxhamj

New Member
Did the test and it passes with no problems. Running off mains power and regulated 5V though. I wonder if the power supply is the problem.
 
M

manuka

Senior Member
Grant/Doc: Sorry- short posting only.

I too had a degree of Hope woes initially- they're easier when you come back to them! They most certainly need that 4.5-5 V supply, & I also had drop outs etc with low terminal voltages from 3 x AAs. A simple battery work around is to use 4 x 1.2V NiCd/NiMH, or one of the popular mains-5V USB supplies. My 1/2 duplex application was shaping up as a 2 sensor DS18B20 hi res "Frost alarm" for a vineyard - akin to yours by the look of things. Pix ? Layout ? Code swap ? Stan
 
G

Grant Fleming

Senior Member
Doc,

Glad to hear your testing didn't upset the module.
I have had no more shifting of settings either.

Stan,

I have returned after a breather!
Was able to test/tweak my code as the modules remained stable this time. Your project does sound similar to mine. Will post the code later today when I return from work.
 
M

manuka

Senior Member
Grant- will look forward to your ideas- I'd used (with his approval) Peter Anderson's hi res DS18B20 routine. The concept relates to measuring the subtle temp profiles that arise as as frost conditions approach. You probably don't get too many snap frosts in WA, but (even with global warming) they can arise here in NZ.

Frosts in vineyards at flowering time can be pretty devastating of course, & many Kiwi growers are on a knife edge about now as a result. Standard practise involves hiring COSTLY helicopters to hover above the vines all night & stir the air with their blades! Being able to locate frost hollows is hence pretty crucial, & may save $$$$$ on chopper charges & lost vintages. Cheers!
 
premelec

premelec

Senior Member
Hi Stan, In USA I've seen pole mounted motor driven propellors in citrus groves [as well as the good old smudge pots]... In these modern times I'm thinking you could have small wind turbines with reversible function... generating power when a bit of wind and blowing to stir the air when near frost.... perhaps get some green credits for the install... and certainly cheaper than much heli time! PICAXEs cold determine function [I knew we could work them in].
 
M

manuka

Senior Member
Nice thought, & indeed there are a LOT of such wind stirers in NZ vineyards as well, but the blade profiles & turbine height needs differ for "sucking or blowing" air.
 
G

Grant Fleming

Senior Member
Hi Stan,

Have included my project code below, it's nothing special but it took some time to get the timing to work (especially with the parameter shifting issues had previously).

The project is the base unit sending a request (done by a pushbutton) for the remote temperature to be sent back to base. The base then displays this temperature through sertxd to the computer on programming editor's terminal screen (or any other serial terminal on the PC).
The operator can also open or close a valve to heat or cool based upon what temperature reading he sees, this is also done by holding down buttons on the base unit PICAXE inputs. A more elaborate process control could obviously be added later once this stage has been tested.

Only had a 08M and a 40X1 to hand for this project testing, but suggest using two X1 parts as the 08M hasn't really got enough I/O's for the valve control I wanted. The X1 parts having the serin timeout is what is needed, having 2 PICAXE chips the same helps ease of programming between each (not having to change the chip mode each time).

Base station code:
Code: 
'BASE STATION CODE for HOPE rf/PICAXE 40X1 half-duplex comms with DS18B20
' or an X1 part (has 'timeout function) ===================================
'By GJ Fleming
'17 Oct 2008

main:
pause 380                       'good to have these pauses
serin[1000,swcheck],1,n600, b1  'base receives dstemp variable, if not a timeout to switch check
pause 170                       'apparently need this pause between a serin & sertxd! Didn't work without it?
sertxd (#b1,cr,lf)              'then displays the temp variable
pause 150

swcheck:
if pin3=1 then openvv   'if button 'x' is held then open valve  
if pin4=1 then closevv  'if button 'y' is held then close valve 
if pin5=1 then temp     'if button 'z' is held then just get the latest temp
goto main               'if nothing pressed, v/v position remains the same

openvv:
serout 5,n600,(1,b2)    'base sends a valve command...b2 will be a 1 to open v/v for eg
goto main

closevv:
serout 5,n600,(3,b2)    'if button 'y' is held then close v/v
goto main

temp:
serout 5,n600,(9,b2)    'if button 'z' is held then a request made for the latest temp
goto main
Remote station code:
Code: 
'GJF HOPE rf/PICAXE 08M Half-Duplex DS18B20 Comms
'GJ Fleming
'17 Oct 2008
'REMOTE STATION CODE for 08M   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
'jumper must be in correct position for downloading!


'(base^^ unit has 40X1 PICAXE)
'(remote** unit has 08M PICAXE)
'jumper must be in correct position for downloading then moved across to use output 0
'can't use output 0 if using sertxd, sertxd only used for debugging
'DS18B20 sensor connected to pin 1
'serin at pin 4, serout at pin 2
'using LED's to indicate outputs at pin 0

dstemp:
pause 100
readtemp 1,b1
pause 100
'sertxd ("Remote temperature is: ",#b1," deg C",cr,lf) ''USE 4800,n,8,1  for debugging
pause 150
serout 2,n600,(b1)   'remote sends temp to base...NOTE- BRACKETS FOR SEROUT! 
pause 80

takein:
serin 4,n600,b2  'remote then listens ...NOTE- NO BRACKETS FOR SERIN!?
if b2= 1 then openvv
if b2= 3 then closevv
if b2= 9 then dstemp
goto takein

openvv:
'sertxd ("open v/v",cr,lf) 'for debugging 
high 0    'LED on  '!!!!jumper must be moved across after downloading!!! cant use because when 0 is used for sertxd
pause 180
serout 2,n600,(b1)   'remote sends temp to base...NOTE- BRACKETS FOR SEROUT! 
goto dstemp

closevv:
'sertxd ("close v/v",cr,lf)
low 0     'LED off
pause 180
serout 2,n600,(b1)   'remote sends temp to base...NOTE- BRACKETS FOR SEROUT! 
goto dstemp
This will be nowhere as involved as what you are doing but see what you think of my beginnings into half-duplex comms.
 
You must log in or register to reply here.
Top