Rick's b.log - entry 2017/01/01

Hello 2017

I get to go to work tomorrow. Christmas holiday, my week off, has passed in the blink of an eye. Tomorrow is Monday, so back to work. France, so often maligned by Brits for their billions of national holidays, doesn't have the culture of pushing weekend holiday days to the nearest Monday. There's no such thing as "Bank Holiday Monday". Christmas and New Years both fell on Sunday this year, so tant pis, better luck next year!

It's cold

This just says "Brrr!":

Whoa!

The willow tree has turned into the hanging gardens of Babylon:

Whodat?

Here's a video I put together yesterday:

Playing with the oscilloscope

The next idea was to have a go at 'seeing' the IR transmissions of my PVR's remote control. The way that the controllers work is basically to send a serial signal that is a start bit followed by a number of data bits. However in order to guard against accidental triggering, such as evening sun or the like being misinterpreted as control signals, the signal is actually modulated by a frequency in the 30-40kHz range.

The first step was to select a timebase where each individual pulse sent to the LED is visible. From this, we can determine our carrier frequency. Here is the pulse shown with a 20µS time-per-square. Note the oscilloscope is on the "NORM" setting, so it will capture a data set when it spots a valid trigger, and will hold that on the screen when there is no trigger available. Very useful, that!

So, we are at the 20µS timebase, which means each square on the screen corresponds to a period of 20 microseconds. To convert this to something more useful, there are a million microseconds per second. Divide that by twenty to give us the value 50000. That means a signal lasting one square will be a 50000Hz (or 50kHz) signal.
If we now take a closer look at this waveform, we can see that the waveform does not correspond to the squares. So this isn't a 50kHz signal. That's okay. We simply look for a place where the start of a pulse corresponds to the start of a square, and count off both squares and pulses until the end of a pulse corresponds to the end of a square. I've marked this process to make it clearer:

If we pass through five squares to send four pulses, then we can derive the actual frequency as follows. Multiply four (pulses) by fifty (kHz, timebase), then divide that by five (number of 50kHz squares travelled). This gives us the result of forty. In other words, it is a 40kHz signal.

You might wonder - if the oscilloscope has all these clever features and can tell frequencies and such, why don't we just rely upon that?
Good question. With a simple answer. Basically put - we are not sending a fixed signal. We are sending data with a modulated carrier. What that means in plain English is that the signal is not reliable and constant. As such, it will be misread.
It is also good to know how to do this sort of thing so you can double-check the readings, because this... is believable but quite simply wrong.

Now we can step out by increasing the timebase until we can see the entire data stream that is sent. This happens when we hit 2ms per square, which corresponds to 500Hz.

Very very conveniently, the data stream pretty much starts and ends on a square boundary. Covering eleven squares, this gives us a 20ms pulse.

But what are we looking at, actually? Well, there's a big-ass wodge which will be the start bit. This will be used to wake up and synchronise the receiver. This is followed by short bursts and long bursts.
Let's take a closer look:

If you look carefully, you will see that the '1' pulses are twice the width of the '0' pulses, and that there appear to be about three "pieces" per square. That is to say, a '0' or a gap is one "piece" long, while a '1' is two "pieces" long. If we divide the square by three, we get 0.66' milliseconds. But this isn't quite right, as all of the pulses are not aligned with the squares.
So back to some maths. The start is four "pieces" long. There are five "1"s (plus ten pieces), and seven "0"s (plus seven pieces). Finally there are twelve gaps. That gives us 33 pieces, in a signal spanning 22ms. Divide time by pieces, we arrive at a time of 0.6ms per piece.

Thus, the start runs for 2.4ms. The '1' bits are 1.2ms long, the '0' bits and inter-bit gaps are 0.6ms long.

The data sent, therefore, is 010011101000. I know my PVR uses standard Sony control codes, so I know it is Sony SIRC; however Googling for "IR 40kHz 0.6ms" gets you going in the right direction.
And that right direction is to know that the protocol is split into two parts - the first seven bits, and the last five bits. Both of which are sent backwards.

So if we break these apart and flip 'em around, we arrive at a device ID of %00010 and a control code of %1110010.

Lookup tables are easy enough to find, so which can be decoded as device ID 2 which is "VTR1", and control code 114 (&72). This does note appear to be listed as anything sensible (in the various places I've looked), in the case of the PVR it is the "Enter" button, but it is quite possible that a VCR has no such functionality and this just happens to be some additional codes that the remote can produce.

Well, there's probably enough there to get started with a transmitter or decoder based upon an Arduino. I don't intend to, I have no need. This was just an exercise in looking at a real life waveform and pulling it to bits. Where this cheap little oscilloscope excelled for me was the one thing my analogue 'scope cannot do - that is respond to a trigger and then keep the waveform visible on-screen even when it isn't there any more. Also, let's face it, the LCD panel - even small as it is at 320×240 and maybe two and a half inches diagonal, is sharper and clearer than an aging cathode ray tube.
For fast signals, or dual channel sampling, I would need to use the CRT 'scope. But for things such as this, the little kit 'scope told me all I needed to know.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

David Pilling, 2nd January 2017, 22:13

o-scope software looks good (often software lets these things down). With the pig-o-scope which has same hardware, it was usually the case that the A2D had a lot higher resolution than the screen. Storage is what we take for granted. Didn't used to be like that. A storage 'scope was something. I never encountered one in my lab career.

David Pilling, 28th January 2017, 01:19

This video after dealing with setting up, details a fix for the oscope - might be a version older than yours:  https://youtu.be/TrblHfy3l8s?t=1037

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 10062 backwards.
		Your comment