ERF/XRF/URF standby - restart -lo power

[BCJKiwi]

Hi.

Am looking at a solar powered setup with

2 x separate device/picaxe/xrf or erf setups -->> <<-- 1 x URF (both devices sending to the same URF)

Qs
1. how to distinguish between the two remote devices?

2. since both these devices will be running off batteries charged by solar, I plan to shut them down (low power sleep on the Picaxes/power off or low power mode on xrf/erf) whenever it is not light (by readadc of the solar panel output V).

3. one device will be sending data every minute, the other every 30 minutes. How feasible is it to keep puttng this to sleep and waking it up again at these intervals realiably. Have read where sometimes constant recycling of such devices can lead to instability. Are the xrf/erf modules stable in such an environment?

As I have 08M, 14M and 28X1 on hand and only need 08M to do the job, is there likely to be an issue using regular serin/out as opposed to hserin/out?

Thanks

 

[AllyCat]

Hi,

I've no experience of those specific modules (nor any PICaxes except M2s), but as nobody else has answered, here are a few answers/suggestions:

1. By the value of the first byte transmitted in each message?

2. The voltage delivered by a PV panel is not a very good indicator of light level (but obviously good enough to detect when it's night), so I suggest you monitor the charging/available current from the panel.

3. Many systems of this type use a (very low cost) external 32kHz "Watch Crystal" to give precisely spaced transmissions, but there are several issues doing this with a PICaxe. Firstly, the pins used by the external resonator on the smaller PICaxes tend to use pins already allocated to another purpose (Programming Input?), but I believe hippy did get one working with an 08M2. Secondly, PICaxe basic will run VERY slowly with a 32 kHz clock so you'd need to switch to the internal (4MHz?) clock for any "real" processing.

If somewhat less accuracy is required, then the PICaxe internal clock is accurate to about +/- 1% and can be trimmed slightly using CALIBFREQ. However, the SLEEP and similar commands (at least in M2s) use a different 32 kHz internal oscillator, which is not as accurate as the "normal" oscillator, but is not as bad as the -50% / + 100% implied in the PICaxe manual. What you could do is write some code which calibrates the sleep delay oscillator against the normal (high frequency) oscllator.

If your transmitters don't "listen" for a "clear" RF window before transmitting, then there is a risk that their messages will "collide". That may not matter for the 1 minute updates, but might be significant for 30 minute period data. But there are numerous possible strategies depending on what you want/need to achieve.

Cheers, Alan.

 

[Haku]

is there likely to be an issue using regular serin/out as opposed to hserin/out?

When I first started working with XRFs I tried using hserin/hserout but quickly discovered regular serin/serout worked fine and was much easier to use as they'll work on most pins of the Picaxe, meaning 08m2's will work fine.

 

[srnet]

Have read where sometimes constant recycling of such devices can lead to instability

Which devices ?

I see no particular issues with using the PICAXE sleep command to put a PICAXE into low power mode.

The only issue with sleep mode is that the time of each sleep count (2.3s) can vary a bit from device to device and with temperature, although if the receiver is always on this should not be a problem.

 

[BCJKiwi]

Thanks all,

@srnet - wakeup issues not with the picaxe but rf modules in general.

Timing is not critical.

@ Haku - thanks for the input re regular serial.

Will continue on the basis of using the 14Ms I have.

 

[srnet]

You would need to be more specific as to what you mean by 'instability'.

Bear in mind that a lot of RF modules are actually designed to go into low power mode ..............

For instance, how many times do you think the RF module in the average car door lock key fob gets cycled ........