Determining an unknown signal

[Andrew Cowan]

Hi all.

I use a remote 4 channel switching device to control the light on my garden shed.

I bought one reciever (£50), and wired it up to a light, which works. However, I would like to interface one of the other channels to some solar lights, via a PICAXE.

I have taken the transmitter apart, and found it contains a standard 433.92MHz transmitter.

Datasheet: http://www.rfsolutions.co.uk/acatalog/DS069-8.pdf

I have also reverse engineered the circuit diagram and drawn a schematic - the DipTrace file is attached. Rename the .txt file to .dch to open it.

As luck would have it, I have a 433.92MHz reciever left over from another project, and this is the same product line as the reciever. This means that I can recieve the signal.

However, it will need decoding.

So, the problem: I have a serial signal which I need to decode. The RF chips support a maximum of 9600 baud, although I am sure the data transmition is much lower than this, as it only needs to transmit a very small amount of data.

It could be True or Inverted - I am not sure.

What is the best way to find out what the message is, and what baud rate it is? If I could somehow connect it to the computer, I could use the serial terminal and set it at each baud rate, and see what came in. How can I connect it up? The reciever runs at 5V. Can a PICAXE help in finding out what rate is used?

Thanks for your help,

Andrew

 

[manuka]

Andrew-it may NOT be normal serial! I once went this way myself with a wireless energy monitor, & after much hair pulling & scope work concluded -sniff-that the device used a bizarre coding system instead of our beloved serial. Google the likes of Radio Shack's & Oregon Scientific's weather stations, which I recall use a unique 44 (or was it 196?) bit burst data stream. See extract from Don Lancaster's article below. Makers go to this extra trouble to give interference immunity etc. Stan

EXTRA: Check this excellent 433 MHz wireless data overview => http://www.tinaja.com/glib/muse151.pdf

 

[Andrew Cowan]

True - it may not be.

But it is still worth a go - even if it is not normal serial, it may still be possible to bit bang to recognise it.

Andrew

 

[212]

It's a far chance, but I wonder if there is a PT2262 or PT2272 chip in there???

 

[boriz]

Andrew. Do you have a scope?

 

[moxhamj]

Good point boriz. I'm not sure you can do this without a scope. Even with a scope, it might be tricky, unless you have a storage scope.

If you have a 433 Tx and a 433 Rx, how about hacking into those and use a picaxe to send the data? Detect the keypress with a picaxe, create your custom signal on an 08M (it might be just a few bytes), and send that signal to the radio module. Just an idea. It does get a picaxe into the circuit *grin*.

 

[boriz]

I recently faced a similar problem. Trying to decode an IR signal from a Hitachi TV remote. A storage scope would have been very handy, but my old CRO was just about enough. While remote TX button was pressed, a code was displayed on the scope as a squarewave with various different high/low times. Unfortunately it only got transmitted once then it was followed by a short repeating signal, presumably to indicate a ‘repeat’ command.

I stared at the scope while repeatedly pressing the button and adjusting the position/timing of the signal. Eventually I figured out that each packet started with a long HIGH followed by a couple of dozen transitions and the lows were all the same length. The highs were always one of two different lengths. So then it was simply a matter of using PULSIN commands to measure the actual length of these highs. After I had determined a midpoint that could be compared with the PULSIN readings to differentiate between short-high and long-high pulses, I just used the long-highs to represent a 1 and the short-highs to represent a 0. This way I managed to get a unique code for every button on the remote handset. It took a lot of faffing about and guesswork, but it works fine. (Code here)

I’m describing this here because a similar strategy might work for you.

 

[womai]

Yes Andrew has a scope, and it is even Picaxe based (hint! If the data stream is not excessively large (the scope's record length is 256 samples), it should be well up to the task. It may make sense to hack the system with a Picaxe (which simulates the keypress), that way the signal from the Picaxe can serve as trigger for the scope, too, enabling to start looking a short while before the data transmission starts.

Wolfgang

 

[Andrew Cowan]

The transmitter is simply a PIC12F629 connected to the RF module. When you press a button, the enable key goes high (thus so soes the LED) for about quatre of a second). I'll connect the reciever to womai's scope, and post the pictures on here.

I want to keep the transmitter as it is - maybe I can do something like boriz did if it is not real serial.

Andrew

 

[hippy]

boriz describes the strategy I would use. I wouldn't want to do this without a scope but I did successfully decode an IR remote at least in part without but it's a long and tortuous affair and a mater of luck. It may work, it may not, reliability is uncertain.

Take a sequence of PULSIN commands and display the resulting b0 to b13 values for each button push. Add pauses until something becomes close to consistent and uniquely identifies the different button pushes. Using SERIN might work as well.

The other option is to hack the transmitter to include an 08/08M between button pushes and transmitter so it does send serial or some pulsed signal you can decode. ( Our posts crossed in the ether on this ! )

 

[Andrew Cowan]

Here is the background noise from the reciever with no incoming signal...

Erm...

 

[hippy]

@ Andrew : Don't worry about background noise at present; what the legitimate signals look like is the important thing to start with. Hopefully the decoding mechanism will by its nature automatically filter out any noise.

 

[Andrew Cowan]

This is the signal when the scope is connected to the data out pin of the PIC on the transmitter.

Andrew

 

[hippy]

That looks promising and I reckon PULSIN could do the job. 20ms per divison looks to be around 5ms for a narrow pulse which gives plenty of time for the PICAXE to get ready for the next. That's an equivalent of around 200 baud, SERIN at 300 baud might give some interesting results.

 

[Andrew Cowan]

Right.

First, the version of programming editor on my laptop (5.2) won't use 300 baud, so the readings below are at T600.

serin 0,T600,b1 This gives 165 for all buttons



serin 0,T600,("165"),b1,b2 gives:

Button 1: 77,237
Button 2: 13,45 OR 77,109
Button 3: 77,105
Button 4: 13,173 OR 77,237


serin 0,T600,("165,77"),b1,b2,b3 gives:

Button 1: 237,182,160 OR 109,182,160
Button 2: 109,13,165
Button 3: 105.182,160 OR 73,182,69
Button 4: 237,9,165

Anyway, this looks promising. I will try to hook up the reciever to a PICAXE, and see what serin 0,T600,("165,77"),b1,b2,b3 can find.

Andrew

 

[womai]

Now puts almost tears in my eyes - the first time I see my "baby" (the scope) in action on a real problem

(since I have several high-end scopes in my lab at work, I don't use my Picaxe scope except to play around).

Wolfgang

 

[boriz]

It looks to me like the sampling rate is too low to resolve that signal properly. But I’ll bet that after that first HIGH, the other HIGHs are all the same length and the LOWs fall into two types, long and short.

The packets might carry a preamble or/and an address which can be ignored. This is prolly gonna work using PULSIN. Experimentation time.

 

[Andrew Cowan]

Won't the PULSIN be triggered by all of the background noise, and then mayby miss the first part of the signal?

If I have
pulsin b1
pulsin b2
pulsin b3
pulsin b4

There is nothing to make it put the first bit of the signal into b1 - background noise could have already triggered it.

Andrew

 

[bgrabowski]

The trick is to repeat it several times. Noise is random so a repeated result is likely to be the true signal. Remember to do one set of tests triggering on a rising edge and a second set triggering on a falling edge. This will give you the true timings for the on times and off times. All you then need to reconstruct the signal is the starting signal level so you know if the pulse train starts with a leading or trailing edge. Your scope trace gives this information.

 

[Andrew Cowan]

Just serin 0,T600,(165) on the reciever gives fantastic results. It catches all button presses.

Andrew

 

[Andrew Cowan]

I have just tried at T300. (I was using an 18X - I didn't realise 18Xs didn't work at 300 baud).

The transmitter gives out:
Button 1: 136,69,236
Button 2: 136,77,135
Button 3: 136,299,236
Button 4: 136,77,155

However, the reciever never gets a 136. However, it dos work with 72. Still it works, and that is good enough for me.

Andrew

 

[meridian]

I did it years ago!

Many years ago, sometime in the early 90's, I went through this exercise of decoding Sony TV and Philips VCR remotes.

I used my trusty Commodore 128 (with external 512kB memory!) with a Tandy IR detector on the User port. I had a small ML program read the IR detector while I pressed each button. The data was written into memory, ($C000 from memory [ha!]) then with a monitor I could read the 0's and 1's to get the patterns. Who needs a storage scope?

I then used these data to transmit from an IR LED with a ML/BASIC program so I had a programmable remote, for time, channel, record, etc! It drove the family mad while I was testing though!

paulr