Picaxe instruction timing repeatability

PhilHornby · Mar 13, 2016

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:

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

inglewoodpete · Mar 14, 2016

I don't really know the answer to your dilemma.

However, some of the problem could relate to your code structure. Any two apparently identical commands in PICAXE code will not necessarily take the same amount of time to execute. This is because the PICAXE tokens generated from your source code are not 4 or 8 bits long but 5 or 6 bits long (I can't remember any more

). The fact that each token is packed nose-to-tail but not necessarily aligning with the normal byte boundaries means that there will be variation in the time taken to unpack each command for execution.

It will be quite a challenge to get your pulse gaps aligned while using a PICAXE. You need an asynchronous data stream. If you use hSerial output, there are start and stop bits that don't always appear where you want them. If you use hSPI (while ignoring the clock pulses), you do not have control over the bit rate. Maybe it is just too big an ask for a PICAXE.

inglewoodpete · Mar 14, 2016

Hmm. Today, the forum software has turned "Edit Post" into "Delete Post"! Having recovered my previous post, I'll add my further thoughts below.

Due the command execution time depending on the location of each token, it should be possible to structure your program to always load the time-critical code in low addresses and the evolving code above that. So your first command would be "GoTo Main/Init" and then execute the main loop in high(er) memory. The time critical routines, each structured as a complete subroutine for each 'keypress' of your remote control emulation, must be placed between the "GoTo" command and the Init/Main loop structure. Your fine tuning of the on/off sequences must be done from the top down as each change in earlier code could upset the location (and therefore timing) of subsequent commands.

Rick100 · Mar 14, 2016

Hello Phil,

Can you post your code? I've done several remote control projects and it seems the timing is never perfect, but I can't remember the exact amount of error. I like to use inline code and pull the timing values from eeprom into ram.
Here's a code snippet of the bit banging:

Code:

[color=Black]pr63: 
      [/color][color=Blue]high c.0
      [/color][color=Purple]carrierOnL [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      carrierOnH [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      [/color][color=Blue]pauseus [/color][color=Purple]carrierOn
      [/color][color=Blue]low c.0
      [/color][color=Purple]carrierOffL [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      carrierOffH [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      [/color][color=Blue]pauseus [/color][color=Purple]carrierOff      [/color]


[color=Black]pr62: 
      [/color][color=Blue]high c.0
      [/color][color=Purple]carrierOnL [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      carrierOnH [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      [/color][color=Blue]pauseus [/color][color=Purple]carrierOn
      [/color][color=Blue]low c.0
      [/color][color=Purple]carrierOffL [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      carrierOffH [/color][color=DarkCyan]= [/color][color=Purple]@bptrinc
      [/color][color=Blue]pauseus [/color][color=Purple]carrierOff[/color]

If you want I can post the whole program but it's for an IR remote with code for mixing the carrier signal.

Good luck,
Rick

PhilHornby · Mar 14, 2016

Thanks

inglewoodpete said:
The fact that each token is packed nose-to-tail but not necessarily aligning with the normal byte boundaries means that there will be variation in the time taken to unpack each command for execution...

...Due the command execution time depending on the location of each token, it should be possible to structure your program to always load the time-critical code in low addresses and the evolving code above that.

Rick100 said:
I like to use inline code and pull the timing values from eeprom into ram.
Here's a code snippet of the bit banging:

Code:

pr63: high c.0 carrierOnL = @bptrinc carrierOnH = @bptrinc pauseus carrierOn low c.0 carrierOffL = @bptrinc carrierOffH = @bptrinc pauseus carrierOff

Thanks for the ideas - I now have a few things to try.

Here's a simple version of my code with the o/p it produces. The error it shows is consistent, which ties in with the idea of it being related to the time taken to do the 'instruction decode', as opposed to random background events.

Rich (BB code):

#picaxe 14M2
#Slot 0
#No_data
;
; 2 pins control the FS1000A 433MHz RF module
;
;symbol EnablePimote       = B.3                            ;different experiment
Symbol EnableRF            = B.4                            ;Power for RF module, only when req'd
Symbol RFDataPin           = B.5                            ;connects to RF Xmitter DATA input.
;
; Symbols used in Pulsout command
;
Symbol T_ON_ONE         = 161                               ;160=202.1, [161=203.3uS], 162=204.6
Symbol T_ON_THREE       = 486                               ;485=608.9uS, [486=609.6uS], 487=611.3uS
;
; Symbols used in Pauseus command (not very linear with small no.s)
;
Symbol T_OFF_ONE        = 31                                ;30=202uS, [31=203.1uS], 32=204uS
Symbol T_OFF_THREE      = 335


;
;     Macros to generate the correctly timed RF data pulses
;
      #macro Send_PREAMBLE(pin)                            
            pulsout pin,T_ON_ONE :  pauseus T_OFF_THIRTY_ONE
      #endm                                                
     
      #macro Send_ONE(pin)                     
            ;pulsout Pin,T_ON_THREE:      Pulsout B.0,25   
            pulsout Pin,T_ON_THREE: pauseus T_OFF_ONE
      #endm                                    
     
      #macro Send_ZERO(pin)                    
            pulsout pin,T_ON_ONE : pulsout B.0,350
      #endm      
      
setfreq M32
;
;     Set o/p ports.
;
      dirsb = %00111000                                     ;B.3,B.4 & B.5 are o/p
     
      high EnableRF                                         ;Power to RF transmitter
     
      Send_ZERO(RFDataPin)
      Send_ZERO(RFDataPin)
      Send_ZERO(RFDataPin)
      Send_ZERO(RFDataPin)
      Send_ZERO(RFDataPin)


      pulsout RFDataPin,1     ;mark the end.
      low EnableRF
      end

Signal timings: (click for viewable image)

hippy · Mar 14, 2016

Here's one way to generate a pulse stream with consistent timing ...

Code:

Goto Main

Send:
  Low B.5
  bPtr = 0
  Do
    pinB.5 = @bPtr
  Loop Until @bPtrInc > 1
  Return

Main:
  bPtr = 0
  @bPtrInc = 0
  @bPtrInc = 1
  @bPtrInc = 0
  @bPtrInc = 1
  @bPtrInc = 0
  @bPtrInc = 1
  @bPtrInc = 0 + 2 ; Zero and End of Stream Marker
  Do
    Gosub Send
    Pause 100
  Loop

For your own case, perhaps something like ...

Code:

Send:
  bPtr = 0
  Send_PREAMBLE(B.5)
  Do
    If @bPtr = 1 Then
      Send_ONE(B.5)
    Else
      Send_ZERO(B.5)
    End If
  Loop Until @bPtrInc > 1
  Return

PhilHornby · Mar 14, 2016

hippy said:
Here's one way to generate a pulse stream with consistent timing ...

I tried something along these lines (based on Rick100's contribution.) The issue I've got is the length of the pulses and the clock speed of the M2 series (I'm using 08M2 and 14M2) for these projects. I need a 200uS pulse followed by a 600uS gap ("0") or a 600uS pulse followed by a 200uS gap ("1"). There isn't time to get around the loop to process the next bit, without the gap always being substantially greater than 200uS

I've had some success with inglewoodpete's method - but it's mighty infuriating! Having sat down with the logic analyser and tweaked each of the 24 'gaps' individually, I then made a tiny change to the preceding code...and I've broken it all again

Still, I now know what is happening, whereas before it all seemed a bit "Eye of toad, leg of newt"

Rick100 · Mar 14, 2016

Hello Phil,

After examining your timings a little closer, I'm not sure my method will be useful since it can only produce pulses of approximately .000266 seconds or greater. You could modify the code to use byte
variables instead of words for the pauseus commands. That might get it down to .000200 seconds, but then it might not produce pulses long enough for your needs. I'm not sure it would be any more repeatable though.

I'm surprised the timing variation is causing a problem. It doesn't look that bad to me. I did a project to control a set of Stanley remote outlets through a 433 Mhz transmitter. It was written in C for a Pic16f876. Each code had to be sent at least 4 times with 13 milliseconds between them. In your actual program, do you send the code just once or multiple times? In your stripped down code you turn on the transmitter immediately before sending the codes. Is that the same in your actual program? These 433 Mhz remotes have never seemed very reliable to me.

Good luck,
Rick

PhilHornby · Mar 14, 2016

I've tried a few variations on a theme, in my bid for reliability. Hooking the RF transmitter directly to a Picaxe pin was probably not my finest moment - and trying to get rid of the subsequent fluctuations in its power supply with a 10uF capacitor will not win any design awards

... that now means that the program has to wait 30mS or so for the supply to stabilise, after it's applied power. I've also noticed that the first 6.3mS pulse isn't always detected properly by my cheapo RF receiver - I don't know if the Energenie socket has the same issue with it.

The odd aspect, is that some of this code has run successfully 24x7 for several months - and then misbehaved. Uncontrolled Lighting is not the end of the world, but I recently lost control of a convector heater in a holiday home

. I calculated that the cost of the petrol for the round-trip to switch it off, was about the same as the electricity it would use if it didn't start working again. Fortunately for me, it did start working again (and I must have left the heater's own 'thermostat' on quite a low setting too, because the room only reached 17c).

The latest generation of RF sockets can report back if the action was successful or not: https://energenie4u.co.uk/catalogue/product/MIHO005 - I'm not sure if that actually helps though. Knowing you've got a problem isn't much of an improvement on strongly suspecting it!

I don't know for a fact that these timing issues are the cause of my problem - but it's something that's not quite right, so it seemed a good place to start.

hippy · Mar 14, 2016

The best I could come up with is a pulse time of 240us or so using the following code ...

Code:

SetFreq M32
Goto Main

Send:
  Low B.1
  Do
    Toggle B.1
    PauseUs @bPtrDec
  Loop While bPtr > 0
  Return

Main:
  bPtr = 3 * 2
  @bPtrDec =  0 : @bPtrDec =  0 ; 3
  @bPtrDec =  0 : @bPtrDec =  0 ; 2
  @bPtrDec = 10 : @bPtrDec = 10 ; 1
  Do
    bPtr = 3 * 2
    Gosub Send
    Pause 100
  Loop

Like Rick100 I am surprised that 191->206uS and 608->627uS is too far out of spec for the nominally expected 202uS and 607us. These types of signalling protocols are usually chosen to have wide tolerances.

It is RF so I am wondering if there's something else to it, perhaps the receiver not being pre-conditioned with just a single preamble bit, or whether there's a polarity issue ?

When you measure your signals are you doing that on the signal to transmitter module or the signal out of the receiver module ? It might be worth doing both to see what the differences are when the PICAXE-based remote stops working.

PhilHornby · Mar 14, 2016

I tried some Arduino code (running on an ESP8266) that claims to decipher various RF protocols. The author didn't seem to expect that particular protocol to be used with a pulse length as short as 200uS, but once 'tweaked', I could successfully decipher 2 Energenie Remote Controllers and the HS1527-based Pimote board. I could not get it to decipher any of my bit-banged output though. I wondered if the decoding software in the Energenie was having the same difficulty, which is why I started investigating the exact timing of the signals I was sending.

In the past, I've relied on the output of a Receiver module, but I've now soldered some wires onto the Energenie stuff, to look at it 'at source'. I noted quite a big difference in absolute timings between the commercial units - but, as I mentioned earlier, the data stream is always stable - whereas mine isn't.

Regarding the 'pre-conditioning': it's looks like it would be useful, as my receiver module doesn't always the get 6.3mS Pre-amble first time (it thinks there's an oddball 47uS double pulse in the middle of it, for some reason).

westaust55 · Mar 15, 2016

@Phil,

from a different project by others working towards a DCC encoder for model railways where time intervals of 58 usec and 200 usec were sought using a PICAXE (eg 20X2) at 64 MHz it may be worth your reading this thread for background information:
http://www.picaxeforum.co.uk/showthread.php?20127-Model-Train-DCC-Controller

I have not created a DCC encoder myself but a DCC decoder I created still required a front-end PICAXE running at 64 MHz to pick up the signals and I used a 74HC123 monostable (or 74HC221 could also be considered) for some pulse stretching for the shorter period.

hippy · Mar 15, 2016

PhilHornby said:
Regarding the 'pre-conditioning': it's looks like it would be useful, as my receiver module doesn't always the get 6.3mS Pre-amble first time (it thinks there's an oddball 47uS double pulse in the middle of it, for some reason).

It could be that the commercial modules use a more powerful RF transmitter which is able to precondition the receiver better and reject subsequent noise than the ones you are using.

Rick100 · Mar 15, 2016

Hello Phil,

Have you seen this guys blog on decoding the Energenie remote?
https://www.pitt-pladdy.com/blog/_20140111-171131_0000_energenie_Remote_Control_Socket_Protocol_ENER002_/

From his blog:

'0' pulses are ~320us, '1' pulses are ~1020us and the overall period is fixed at ~1400us with 10ms gaps between packets.

It looks like he's using the same units but got different timing results.

Good luck,
Rick

PhilHornby · Mar 15, 2016

I think I encountered that blog early in my investigations, but ignored it, since it didn't bear any resemblance to the measurements I'd taken for myself

I do know that there are several (identical looking) versions of the actual Energenie socket floating around. The later models can learn two different controllers ids, whereas the earlier ones can only learn one. I don't think the controller itself has changed though. Certainly the three that I have in front of me now - from a variety of sources - all use pulses of around 600/200uS.

What I meant to ask (anyone): is there a hardware decoder for the HS1527 'style' protocol? Most of these type of encoder seem to have a matching decoder - but not this one. Yet it seems to be quite widely used - eBay is full of 'learning' RF controllers, who's adverts mention it. (Used for garage door openers, apparently). Having dismantled the Energenie Remotes and Sockets, there are no parts in there I can find datasheets for - I assume they're microcontrollers of some description, rather than dedicated decoder ICs.

hippy · Mar 16, 2016

PhilHornby said:
is there a hardware decoder for the HS1527 'style' protocol? Most of these type of encoder seem to have a matching decoder - but not this one.

I had previously looked and did not find anything. I guess this is because they are expecting something 'smart' in the receiver so no real market for hardware which itself would have to be smart.

One interesting thing looking at xx1527 modules, is that the basic unit time period is usually around 2ms when run at 400kHz from its on-chip oscillator. That would be expected to become 200us when run from a 4MHz oscillator. There seem to be two variants; those at around 400kHz and those around 4MHz.

The protocol preamble does seem to be a single bit 1T pulse then 31T pause. That is probably okay for IR but might not be good enough to condition an RF receiver well. It could be that the packet is sent multiple times, the first to condition the receiver, subsequent packets would then be received and correctly actioned. If only sending the packet once there would be a reduced chance of that getting through and being actioned.

MikeM100 · Mar 16, 2016

Just a thought - these simple encoders/decoders are usually very tolerant of bit timings as they use RC clock oscillators at both encoder & decoder.

The decoders however require that the code is received correctly two (or three times) consecutively. Are you sending the code a minimum of three times ?

MikeM100 · Mar 16, 2016

Just had a look at: https://www.pitt-pladdy.com/blog/_20...ocol_ENER002_/

Yes, there is a vital preamble/sync period and yes there is a start bit !

It is worth having a background look/read of the original (1970s) National Semiconductor MM53200 encoder/decoder and a perusal of this page on the Holtek web site:

http://www.holtek.com/english/tech/faq/212_faq.htm

PhilHornby · Mar 16, 2016

MikeM100 said:
The decoders however require that the code is received correctly two (or three times) consecutively. Are you sending the code a minimum of three times ?

Yes.

My issue is that my code (in three different projects, on two different sites) works as expected for months on end and then decides to misbehave (for a day or two). I think one of the issues I'm facing, is that the Decoder (i.e. the socket) isn't necessarily simple; it seems to be a microcontroller, with its own idea of how this protocol works. I spotted a possible difference between the data I am sending and that sent by the commercial controllers and was trying to make it a better match.

My original question was why my simple bit-banging code wasn't producing consistent results, but I seem to have wandered a long way off topic

PhilHornby · Mar 16, 2016

Datasheet

hippy said:
One interesting thing looking at xx1527 modules, is that the basic unit time period is usually around 2ms when run at 400kHz from its on-chip oscillator. That would be expected to become 200us when run from a 4MHz oscillator. There seem to be two variants; those at around 400kHz and those around 4MHz.

Which data sheet did you get that info. from? I've searched for all variants, but the results are basically all the same PDF. The pulse length seems to be set by a single resistor, but there's no formula given to work out its value - just a sort of 'cause-and-effect' table, giving the results of a few select values at different supply voltages. FWIW, the Energenie Pimote has a surface-mount resistor that measures 129K on my meter.

I've been battling my way through my code, individually altering the delay times in my bit-generating macros:

Rich (BB code):

      #macro Send_ONE(delay)                   
            pulsout RFDataPin,T_ON_THREE: pauseus delay
      #endm                                    


      #macro Send_ZERO(delay)                  
            pulsout RFDataPin,T_ON_ONE : pauseus delay
      #endm

I found that to send a "1" (On for 3 periods, off for 1), I have to use one of the following values for delay: 19,23,28 or 31. For the "0" (On for 1 period, off for 3), the delay is: 330,333,336,345 or 348. In other words, not entirely random, but presumably related to some boundary or other that the code finds itself being located on.

Unfortunately, I've found that I can't store all the codes I would like in a single 14M2 slot - I'm a good 520 bytes over. This is due mainly because each code has to be repeated with in-line code - 'for next' introduces a variability I can't get rid of

With this in mind, I'm going to do some more detailed testing with the socket to find out what it does respond to ... and what it doesn't. It may be that I can use much longer pulses, generated using some of the methods proposed earlier.

(I've just looked at the pulses the HS1527-based Pimote is producing today: 243.4uS, 730.2uS with a 7.541mS preamble. All in precisely the correct ratios, but radically different to my earlier measurements

)

hippy · Mar 16, 2016

PhilHornby said:
My issue is that my code (in three different projects, on two different sites) works as expected for months on end and then decides to misbehave (for a day or two).

I think it's not the timing but something else. Your pulse times appear to be within microseconds of what they should be and the protocol should cater for far more variance than that.

I would suspect external interference, and perhaps your command regime not being ideal. Rather than being unlucky occasionally, it may be that you have so far been lucky most of the time.

Perhaps you could clarify what regime you have. I would be tempted to send a complete set of on/off commands every minute or so, and repeat each of those individual commands.

I think I was wrong on the 400kHz = 2mS claim, I seem to have misinterpreted resistance as frequency and on second reading it's not clear what period any time values refer to, as per your original datasheet link.

PhilHornby · Mar 16, 2016

My various projects all use slightly different 'regimes' - supposedly, each is an improvement on the one before.

The latest project with a problem, involves a modified Drayton commercial Room Thermostat. I can remotely change its setting - via connections to its UP/DOWN buttons, and its DEMAND o/p is monitored and used to send ON/OFF commands to an Energenie socket. There is a heater plugged into the socket.

On any change in DEMAND state, the appropriate ON/OFF command is sent shortly afterwards. The same command is repeated regardless of change, at approximately one minute intervals. The RF interface sends a stream of pulses to condition the Receiver AGC, then repeats the Socket ON or OFF command 10 times. This was in action 24x7 throughout December to February, with no glitches that I'm aware of; certainly nothing major.

Then one day last week, the heater was powered on and stayed on for a day and a half. (The project uses a separate DS18B20, purely for monitoring). Because it's 310 miles away, I couldn't be sure what was going on - but increasing and decreasing the thermostat set point had no effect. It then returned to normal operation of its own accord, before having a minor repeat performance. At the moment, all appears well...

I'm not due to visit the site for another week - when I'll find out if anything physical has happened - but I'll bet there's nothing to see.

The other projects that have ceased to function have all had one thing in common - "OFF" commands stopped working, but "ON"s were OK. The Energenie "OFF" commands all have "0" as their last bit.

I don't think it's RF interference, because it lasts too long and is too specific in its nature. In the case of my holiday cottage, it's in a hamlet consisting of 3 houses in the middle of fields ... it's not exactly a hive of activity and 20" granite walls do a good job of keeping stray RF out.

From my latest code modifications (with the individually crafted delays), I've learned some things though:

There is no STOP bit in the Energenie implementation of this protocol. No extra trailing pulse is req'd to terminate the 'gap' after the last bit.
It only requires two consecutive matching codes to turn the socket On or Off. To teach it the code in the first place needs somewhere between 10 and 15.
It does indeed have a very wide tolerance of pulse width.

I mentioned earlier that I have an ESP8266 running some Arduino-based RF receiving code. It didn't work with my bit-banged output, but it did with all the Energenie products.

With my newly-honed code, it suddenly burst into action. It's not easy to see exactly what its previous objection was (due to un-documented 'C' code

) but it's happy now. The change I have made of course, is to make the pulse timings consistent.

I tried a test, replacing my 'SETFREQ M32' with a 'SETFREQ M8' and it's still happy! I've tried with an Energenie socket and that works as well - the basic pulse-width now being 800uS, due the lower frequency.

With that in mind, I'm a fair way through re-writing my code to use a much longer pulse width, that can be generated with the coding techniques previously proposed.

Flenser · Mar 19, 2016

The HS1527 protocol looks pretty robust. I'm surprised that the recevier would be having trouble distinguising between a 0 and a 1 just because your pulse timings are not ezactly 202ms and 607us.

And the HS1527 protocol may not be the whole story. I had a bit of a google but I could not find any specification of the complete protocol being used by this Energenie Pi-mote controller.

There are others trying to reverse-engineer these wireless remote-controlled type power plugs and I found this git repository for one person's work on the Energenie product line https://github.com/whaleygeek/pyenergenie which has this comment:

The Energenie product line uses the HopeRF radio transciever, and the OpenHEMS protocol from Sentec. Energenie have built a RaspberryPi add-on board that interfaces to the HopeRF RFM69, and allows both control and monitoring of their products from a Raspberry Pi.

In the code named legacy.py https://github.com/whaleygeek/pyenergenie/blob/master/src/legacy.py the protocol he uses is to send each command 8 times in-a-row. For this type of remote control, where you send commands out into the aether without getting any confirmation back as to whether they were successfully recieved or not, a protocol of sending each command multiple times seems like a reasonable approach.
- Have you looked at the signal being sent between the HS1527 and the PT4452 for a longer period of time to see if you can confirm whether multiple frames are being sent for a single button press?
- You say that you have have an ESP8266 running some Arduino-based RF receiving code that works with all the Energenie products. Can you check this Arduino code to confirm what the higher level protocol is?

For improving your pusle timings I have one suggestion, which is to choose values for pulsout and/or pauseus that minimize some aspect of the absolute timing error.

the short ones range from 191->206uS and the long ones range from 608->627uS

The variation in the range of values for the two pulse lengths are similar, 15us for the short pulses and 19us for the long pulses. However, expressed as an error range this is 202 -11/+5 us for the short pulses and 607 +1/+27 us for the long pulses. The worst-cast absolute error is 11us for your short pulses and 27us for your long pulses. You could try choosing values for pulsout and/or pauseus that minimise this absolute error value for both short and long pulses.

The total period of each short and long pulse pair is 809us from your HS1527 measurements, no matter which order the long and short pulses are sent. You could try choosing a combination of values for pulsout and/or pauseus that minimize the absolute error value for pairs of short and long pulses.

You could also try choosing values for pulsout and/or pauseus that minimize the absolute error value for the whole frame length (preamble + C0-c19 + D0-D3) or just that part of the frame after the preamble (C0-c19 + D0-D3)

Good Luck!

PhilHornby · Mar 19, 2016

That GitHub repository's a good find - I've clicked the "Watch" button! He's concentrated on the newer Energenie socket's though - from the Mii Home range. These use the "Openthings" protocol .. which may turn out to be a good thing...except Energenie's usage of it isn't that open... Certainly not enough info in: https://energenie4u.co.uk/res/pdfs/ENER035 user guide.pdf to interface with their product without resorting to more reverse-engineering.

Regarding the 'legacy' socket's protocol, I don't know exactly what is being checked. The decoder is certainly looking at 'ratios' of pulse timings, rather than absolute values - because you can train it with 200uS pulses and it will still work with 800uS ones (and vice-versa). May be it looks at the gaps between pulses as well? ... I don't know - but that's my current (unproven) theory

I've finished my implementation of the ideas put forward earlier in this thread, and am in the process of retrospectively applying it to my existing projects. Whether it will help or not, who knows?

PhilHornby · Mar 21, 2016

Energenie Socket Control software

I posted the code I came up with: http://www.picaxeforum.co.uk/showthread.php?28662-Code-for-controlling-Energenie-(and-similar-)-RF-Remote-Control-Mains-sockets&p=295921#post295921

So far, so good. (With an improvement over the Energenie hardware, in that you can have a group of 7 sockets, rather than 4 - i.e. which can all be switched ON/OFF together).

Picaxe instruction timing repeatability

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Technical Support

Senior Member

Senior Member

Senior Member

Technical Support

Senior Member

Moderator

Technical Support

Senior Member

Senior Member

Technical Support

Member

Member

Senior Member

Senior Member

Technical Support

Senior Member

Senior Member

Senior Member

Senior Member