PhilHornby
Senior Member
I have several projects that communicate via 433MHz RF to commercial Energenie Remote Control Switches. Most of these use bit-banging to feed a cheapo FS1000A transmitter in order to emulate the supplied Remote Control. Just one of them uses Energenie's "Pimote Interface", which is intended for use with the Raspberry Pi. This board has an HS1527 OTP encoder, feeding a PT4452 transmitter.
I have experienced several occasions when commands appear to 'not get through'. (These are invariably "OFF" commands for some reason). The occasions in question can be quite lengthy - sometimes up to several days - during which time, manual control with the supplied Remote Control still works. This has only ever happened with my bit-banged controls, never with the Pimote. On occasions when I've investigated, I've concluded that my timings are wrong - and been left wondering how they ever worked in the first place!
I recently sat down to finally nail this and come with some definitive values for my code (armed with my Siglent DSO and clone Saleae logic analyser). What I noticed with regard to the official Remote Controls and the HS1527 o/p, is that although they were all markedly different, each one was stable (at least over a period of a few seconds). In contrast, my own bit-banged output isn't stable over a few milli-seconds.(Picaxe 14M2@32MHz)
Here are example of the signals involved: the top trace is the bit-banged output, the bottom trace is the signal sent between the HS1527 and the PT4452. (click for readable version)
On the face of it, they are very close but analysis of timings of the two reveals the difference.
The HS1527 'high' pulses are either 202uS or 607uS. The 'gaps' between pulses are the same.
My code produces 'high' pulses that are either 203uS or 610uS (well within spec. I think), but the gaps are all over the place - the short ones range from 191->206uS and the long ones range from 608->627uS.
I produce the 'high' pulse with a PULSOUT command, and have tried a variety of methods for the 'gap'. Originally I was using PAUSEUS, but I have tried everything else I can think of (including another PULSOUT to an unused pin). I cannot get rid of the instability.
To my mind, the obvious reason, is that the Picaxe firmware is doing something between commands that does not take a fixed amount of time.
So:
I have experienced several occasions when commands appear to 'not get through'. (These are invariably "OFF" commands for some reason). The occasions in question can be quite lengthy - sometimes up to several days - during which time, manual control with the supplied Remote Control still works. This has only ever happened with my bit-banged controls, never with the Pimote. On occasions when I've investigated, I've concluded that my timings are wrong - and been left wondering how they ever worked in the first place!
I recently sat down to finally nail this and come with some definitive values for my code (armed with my Siglent DSO and clone Saleae logic analyser). What I noticed with regard to the official Remote Controls and the HS1527 o/p, is that although they were all markedly different, each one was stable (at least over a period of a few seconds). In contrast, my own bit-banged output isn't stable over a few milli-seconds.(Picaxe 14M2@32MHz)
Here are example of the signals involved: the top trace is the bit-banged output, the bottom trace is the signal sent between the HS1527 and the PT4452. (click for readable version)
On the face of it, they are very close but analysis of timings of the two reveals the difference.
The HS1527 'high' pulses are either 202uS or 607uS. The 'gaps' between pulses are the same.
My code produces 'high' pulses that are either 203uS or 610uS (well within spec. I think), but the gaps are all over the place - the short ones range from 191->206uS and the long ones range from 608->627uS.
I produce the 'high' pulse with a PULSOUT command, and have tried a variety of methods for the 'gap'. Originally I was using PAUSEUS, but I have tried everything else I can think of (including another PULSOUT to an unused pin). I cannot get rid of the instability.
To my mind, the obvious reason, is that the Picaxe firmware is doing something between commands that does not take a fixed amount of time.
So:
- Is that the cause, or have I missed something?
- Can I stop the Picaxe firmware doing whatever it's doing? - or at least make it more predictable.
- Is there another way of generating this signal, that I've not thought of.
Rich (BB code):
; This is what the radio data looks like:-
;
; +-+ +-+ +---+ +---+ +-+ +-+
; | | | | | | | | | | | |
; |1|<------- 31 ------>|1|<3>|<3>|1|<3>|1|1|<3>|1|<3>
; | | | | | | | | | | | |
; -+ +-------------------+ +---+ +-+ +-+ +---+ +--- ... etc
;
; <-----Preamble------> 0 1 1 0 0 ... etc
;
;
; Where a "1" time period is approx. 200uS and "3" is approx. 600uS
Code:
Picaxe HS1527
Times in uSecs
Pulse Gap Pulse Gap
203 612 202 607
203 627 202 607
610 206 607 202
610 206 607 202
610 191 607 202
203 608 202 607
203 612 202 607
203 623 202 607
610 191 607 202
203 623 202 607
610 195 607 202
203 623 202 607
610 202 607 202
610 191 607 202
203 616 202 607
203 612 202 607
203 608 202 607
203 612 202 607
203 623 202 607
610 202 607 202
610 206 607 202
610 202 607 202
610 191 607 202
203 ? 202 607
Last edited: