Wireless Remote Question

#1
I’m trying to simulate a 433 MHz wireless remote control but have been unable to do so.

Below are two Saleae screen grabs of two radio transmissions received on an ASK wireless receiver. The first is from the genuine remote transmitter while the second is from a 08M2 programmed to simulate the remote and connected to an ASK wireless transmitter.

1553940462289.png
1553940489128.png
In general the signal seems to consist of a header with a high of 6.5 mS followed by 15 bits (110101111010111) with the 1 having a width of 3.75 mS and a 0 being 1.7mS wide. The gap between bits is 1.55 mS wide. The pattern is repeated continuously while the remote button is depressed.

To my very untrained eye, the signals look identical but clearly there is something I’m missing going on here.

Has anyone got any ideas as to why my generated radio transmission is being ignored by my device?
 
#3
There is a small amount of shifting of part of the signal. If the real one is close to some timing limit, then the copy may be outside allowable tolerances.
CompareSignals.png
 

steliosm

Senior Member
#4
The speed is not correct though. The transmitter on the second capture is sending the signals slower than the transmitter on the first capture.
 

hippy

Technical Support
Staff member
#5
Inglewoodepete beat me to it. They look close, but not quite. It could be enough to throw things -

Diffs.gif

One thing I have found is that the entire transmission path and choice of transmitter can alter pulse widths and their timing, but it's usually high or low pulses being shrunk or stretched, the overall timing consistent.

This seems to have divergence throughout. I'm wondering if that could be a result of your bit-banging timing being out, where code is placed in your program causing different timings as things get executed.

The trick I have found to work best is to have an output routine at the start of the code, which is jumped round, which will then have fixed and accurate timing once tweaked. Create a list of timed pulses to send and just feed that to the output routine, let it rip -
Code:
Goto Main

SendBitStream:
  @bPtr = 0
  bPtr = 10
  Do
    High TX
    b0 = @bPtrInc
    Select Case b0
      Case 1 : PauseUs ? : Low TX : PauseUs ?
      Case 2 : PauseUs ? : Low TX : PauseUs ?
      Case 3 : PauseUs ? : Low TX : PauseUs ?
    End Select
  Loop Until @bPtr = 0
  Return

Main:
  Do
    bPtr = 10
    @bPtrInc = 1
    @bPtrInc = 2
    @bPtrInc = 3
    Gosub SendBitStream
    Pause 1000
  Loop
Measure the individual high and low times as received from the genuine as accurately as you can and tweak the PICAXE output routine timing to match that regardless of what they actual values are.
 

AllyCat

Senior Member
#7
Hi,

I've only encountered one 434MHz OOK system where I was unable, with a PICaxe, to synthesise an acceptable waveform for the receiver. I concluded that its decoding relied on the very high (frequency) accuracy of crystal oscillators, i.e. using a long data packet with little or no resynchronising to the data transitions. Generally, the duty cycle (mark-space ratio) of the individual data bits is not too critical, because OOK is basically a low-bandwidth analogue system where variable propagation delays may occur (e.g. dependent on signal strength).

Do you have an analogue 'scope to check the "data eyes" of the received signal? A problem with the Saleae clones (and most Logic Analysers) is that they have a fixed slicing (data threshold) level which might not be the same as the receiver is using ("CMOS" inputs are usually 50% of Vdd, whilst "TTL" are lower and more constant, etc). Very often the received rise and fall times will be different (so the slicing level is significant), or with weaker signals the waveform may even "grow grass" (noise) from one of the logic baselines, which might not show up with a Logic Analyser.

Cheers, Alan.
 

hippy

Technical Support
Staff member
#8
In general the signal seems to consist of a header ... followed by 15 bits.
That does allow for simpler sending than I previously suggested. I would start with this -
Code:
Goto Main

SendBitStream:
  High Tx
  PauseUs w1
  Do
    High TX
    If bit15 = 1 Then
      PauseUs w2
    Else
      PauseUs w3
    End If
    Low TX
    PauseUs w4
    w0 = w0 + w0
  Loop Until w0 = 0
  Return

Main:
  Low TX
  w4 = 155      ; Gap Time    - 1.55 ms
  w3 = 170      ; Zero Time   - 1.7  ms
  w2 = 375      ; One Time    - 3.75 ms
  w1 = 650 - w3 ; Header Time - 6.5  ms
  Do
    w0 = %110101111010111
    Gosub SendBitStream
  Loop
 
#9
Thanks to everyone who has replied. I’ll try to respond to all of the comments made.

Firstly, the device is an old (late 1970’s) B&D Controll-a-door that was used to open a garage door so I would expect that the technology used then would be relatively unsophisticated.

As has been noted by a number of you, the transmission rate is likely to be the most critical requirement. I spent some time aligning the transmission rates and I think I’ve finally got them in good alignment. The transmission of 10 sequences of the 15 bit pattern takes 825.2 mSecs and my program takes 825.6. This difference of only 0.4 mSecs is only about a quarter of the narrow “0” pulse so shouldn’t be a problem. Also I’ve confirmed that the genuine remote only needs to be depressed for 500 msecs for it to be accepted by the controll-a-door so in fact only about 6 sequences are required. I’ve also found that the transmission rate of the genuine remote varies slightly with battery voltage. The battery that was in it when I made my initial measurements was old and I later noted that its voltage dropped to below 8 volts when actually transmitting. When a new battery was installed, the transmission time for 10 sequences actually increased to 827.7 mSecs.

I’ve also thoroughly investigated the pulse width for the “1” and “0” and found that the variation in width of the 08M2 generated pulses is actually less than the genuine remote. Added to this, the width of both lots of pulses (ie from the genuine remote and the 08M2 controlled transmitter) widen significantly when the transmitter is brought closer to the receiver. So again, I’m pretty confident that the width of the generated pulses is not the reason for the controll-a-door not to respond to my simulated signal.

Alan, I do have a genuine Saleae but I don’t think that that will make much difference in this case as I am doing all my timing measurements on a cheap Chinese receiver and not the actual receiver in the Controll-a-door. However, for the reasons given earlier, I don’t think that pulse width is the problem for the old slow signal protocol that is used here.

I feel that there must be something else about this signal that is causing the problem but I can’t imagine what that is, so I’d be grateful for any other suggestions on areas that I can investigate. One thing that I did spend some time on was that I noted that the first sequence after the button was pressed on the genuine remote had a header that was 10.6 mSecs long compared the normal 6.6 mSecs for later sequences and I even altered my code to roughly incorporate that but it made no difference. On later reflection, I expect that the wider header pulse width is probably caused by the very low voltage as the capacitor charges up just after the button is pressed.

Thanks to you too Hippy for providing your programs. I didn’t actually use them as your second one was quite close to mine but I did re-arrange mine so that variable assignment was at the end of the program. Mind you, I still found it very frustrating actually “tuning” the timings and that changes to constants further down in the code often affected other timings whose values were set earlier in the code.

Again, thanks to everyone who offered suggestions and I still welcome more. Also, if someone knows of a commercial product that can be used with this old controll-a-door, please reply with the details.
 

hippy

Technical Support
Staff member
#10
I would also have expected the decoder to be quite tolerant of timing to cater for variations in transmitter voltage, temperature and whatnot.

Decoding of such data often seems based on pulse lengths being multiples of the gap period which makes it fairly easy to determine what a signal stream is with a wide tolerance.

I would expect the 10.6 ms pulse is quite important, is the actual 'start' header, the 6.5 ms being a 'repeat' header.

If sending out the 'same data' there's no reason the receiver shouldn't treat it as actual data. If it's not a matter of timing, it must be a matter of something else. Hard to tell though what that is.
 

AllyCat

Senior Member
#11
Hi,
I am doing all my timing measurements on a cheap Chinese receiver and not the actual receiver in the Controll-a-door. .
I'm still suspicious that the "digital" waveform which the actual decoder is "seeing" is in some way different to what the Logic Analyser shows. Of course this is difficult to identify if the "data slicer" is an unknown threshold detector buried within an Integrated Circuit. So I can only suggest that you try to work with "strong" (i.e. noise-free) radio signals, but not so strong that they might overload the receiver. Remember that the basic transmitter-receiver part of the system is ANALOGUE, so try a range of signal strengths (TX-RX range).

Again clutching at straws, have you checked that every data packet is (digitally) identical? I did encounter a similar signalling system which contained a "running sequence number" in part of each data packet. Not something I would have expected in a system of that vintage, does the encoder even use a microcontroller? Of course the better, modern systems use a pseudo-random rolling sequence (synchronised in transmitter and receiver), to prevent "recording" and spoofing of the signal.

Cheers, Alan.
 
#12
Thanks Hippy & Alan for your further thoughts.

I'm still suspicious that the "digital" waveform which the actual decoder is "seeing" is in some way different to what the Logic Analyser shows. Of course this is difficult to identify if the "data slicer" is an unknown threshold detector buried within an Integrated Circuit.
I think that’s right Alan. I have a hardware problem here that won’t be fixed by software. I don’t know what modulation system is being used by this old 1970’s remote transmitter and its decoding by a modern OOK receiver may not properly represent its true configuration. Similarly, I don’t know how the radio receiver in this controll-a door will decode the signal put out by a modern OOK transmitter and it could be far from what I expect or it may not extracts any signal at all.

I think I’ve gone as far as I can go with this.

Thanks again everyone.
 

hippy

Technical Support
Staff member
#13
I have a hardware problem here that won’t be fixed by software.
I am not convinced that is the case. The protocol has to be tolerant to day-by-day variations in transmission rates so it shouldn't matter if your timing isn't absolutely accurate. And I would have thought that if they matched using a third-party receiver, they would match closely enough for the genuine receiver to be able to handle that.

More likely in my opinion is that it's not sending the start code, that transmissions from the genuine transmitter aren't the same every time, or it depends on some aspect of the transmission which hasn't been identified yet.

Having a rolling code or a changing sequence number wouldn't be that surprising given the application of garage door opener, which one would want to be immune to playback attacks. And effectively you are attempting a playback attack.

I would consider a PICAXE program which can in the first instance report the data stream timings, in the second, decode those to meaningful data streams. That way you can more easily see what the transmitter is putting out. I'd start with -
Code:
#Terminal 38400
SetFreq M32
Do
  w0 = 0
  Do : Loop While RX = 0
  Do
    w0 = w0 + 1
  Loop Until RX = 0
  SerTxd( #w0, CR, LF )
Loop
 

AllyCat

Senior Member
#14
Hi,
The first is from the genuine remote transmitter while the second is from a 08M2 programmed to simulate the remote and connected to an ASK wireless transmitter.
Reading your original post again, I think the issue might be more fundamental: Are you sure they're actually transmitting at the same frequency? The "nominal" frequency for this ISM band is usually 433.92 MHz, but the cheaper (most) systems can be off by hundreds of kHz. So the receivers often have a very wide reception bandwidth, sometimes 1MHz or more. It's only quite recently that "better" (integrated circuit) hardware has used frequency synthesiser technology and Superhet receivers, etc..

However, your "controll-a door" might precede the intermediate "cheap and nasty" phase. In the 70s, the "digital" hardware could have been relatively expensive so the designers might have spent proportionally more on the wireless link, for example a crystal-controlled transmitter and narrow-band receiver (not necessarily 433.92, but maybe 433.00 ?). The wireless protocol you've shown is quite narrow-band (~1 kHz ?) so the receiver could have a correspondingly narrow bandwidth, if the analogue hardware had been designed accordingly.

Cheers, Alan.
 

hippy

Technical Support
Staff member
#15
Are you sure they're actually transmitting at the same frequency?
That's a good point; you might not be seeing what the actual receiver is seeing. If you can tap into the genuine receiver that would be better.

I have seen similar effects to what AlleyCat describes with IR, where the PICAXE driven IR LED or carrier frequency doesn't match the genuine remote; with the genuine IR receiver showing differences to what a test IR receiver has shown.

Differences can usually be adjusted-out in PICAXE software but that may not be so effective or even possible for radio.
 
#16
More likely in my opinion is that it's not sending the start code, that transmissions from the genuine transmitter aren't the same every time, or it depends on some aspect of the transmission which hasn't been identified yet.

Having a rolling code or a changing sequence number wouldn't be that surprising given the application of garage door opener, which one would want to be immune to playback attacks. And effectively you are attempting a playback attack.

Hippy, I actually spent some time investigating this start code but I’m now convinced that it’s not the problem. I don’t think they had the ability to process anything as complicated as a rolling code back in the 70’s. Security wasn't seen as much of a problem back then and their principal concern was to stop your neighbour’s garage remote from opening your garage door and a 15 bit code would have been more than enough for that.

However I did investigate it and it was actually quite difficult to get a good look at that first sequence because it takes some time for the Chinese OOK receiver to wind down its AGC so most of the first sequence is lost in the noise you get when there is no RF. I ended up getting it by using a relay to trigger the remote and precede that with my own generated RF to keep the AGC down. When I got a clear signal to look at, I could see that not only was the initial start bit longer (wider) but also the first couple of code bits were also a bit wider but soon reduced so that they were back to normal after it had transmitted about 5 bits. So I’m convinced that it’s just a transient caused by switching on the power to the remote.

However, your "controll-a door" might precede the intermediate "cheap and nasty" phase. In the 70s, the "digital" hardware could have been relatively expensive so the designers might have spent proportionally more on the wireless link, for example a crystal-controlled transmitter and narrow-band receiver (not necessarily 433.92, but maybe 433.00 ?). The wireless protocol you've shown is quite narrow-band (~1 kHz ?) so the receiver could have a correspondingly narrow bandwidth, if the analogue hardware had been designed accordingly.
Yes Alan, I think that’s very likely. I have no idea what the actual transmission frequency of the remote is and I was somewhat surprised when I initially found that I could extract a signal from it using the Chinese receiver. I think there is a good chance that the controll-a-door receiver doesn’t decode anything at all from the Chinese OOK transmitter.
 
Top