reading a 10bit serial stream

[hal9000]

hi all.

I am looking to decode a serial code stream from an old Laserdisc Player controller. I have written a lengthy program already that uses the 'serin' command, its a dirty and imprecise way of doing it, and ultimately its useless and i need to stop and do it properly...

Thing is, i can't get the PICaxe to read the stream in and get the information out of it that i need. I'm using a 28X2..

Briefly, I have this serial command line hooked to an input on the picaxe (say C.2), it sits at 5v most the time, and goes low (to gnd) when its sending the info.

Each command is sent in a series of 11 low-going pulses. Each pulse is 260usec, that seperate the data. So the space between two pulses indicates a 1 or 0. A small space (1.05 mSec) between two pulses indicates a 0. A large space (2.1 mSec) between two pulses indicates a 1.

My initial attempts have been to have this serial input set as a low-going interrupt, which would run a series of 'pulsin' commands set on rising end-triggers.

The idea being that the interupt is triggered when the first pulse is detected, then we measure the time it takes for the next 10 high-going pulses... the resulting bunch of captured signals should show a pattern of long and short counts from which i can decode the meaning..

Except i think that invoking the 'pulsin' command each time is in fact taking its sweet time to do so and its missing the data anyway.

Can anyone suggest anything for reading this fairly quick serial stream? I'm sure im approaching it wrong..

Oh, i did switch to using a 16mhz external resonator as running at 8mhz i think it was just too slow..

many thanks in advance!

 

[eclectic]

How many "bit patterns" do you need to read?

As an aside, was the 28X2 an "old" 3v version
that could run at 64 MHz (1 x 16)

e

 

[hippy]

A series of PULSIN's should do the job. That was how Sony IR can be bit-banged in, measure each pulse, convert each to a 1 or 0 and then merge them together ...

PulsIn pin, level, w0
PulsIn pin, level, w1
PulsIn pin, level, w2
:
w0 = w0 / N
bit1 = w1 / N
bit2 = w2 / N
:

 

[hal9000]

Opps sorry, i misunderstood you at first, its a normal 5v 28x2, not a 3v..

If i can read this 10bit stream then i can just rinse and reapeat, the actual commands are repeated and longer but the aim right now is to read just one 10bit stream accurately...

I agree, a bunch of pulsin commands should work, but i don't get anything intelligible what is your experience of the time that a pulsin command takes to execute through the PIC?

 

[eclectic]

Opps sorry, i misunderstood you at first, its a normal 5v 28x2, not a 3v..
snipped

Please see Manual 2, p.214
You'll need an 8MHz resonator for 32MHz operation.
The 28X2 5v will "ignore" the 16MHz

e

 

[hippy]

I'm not sure what you mean by the PULSIN takes to execute but I'll guess how long you mean between one PULSIN and the next so it doesn't miss pulses. I'd guess approximately 250us-500us at 4MHz, so you could be missing some pulses but 16MHz should have fixed that. Trying to bit-bang read IR can be a bit hit and miss.

Have you put a scope on the IR data line to see exactly what you are receiving ?

 

[eclectic]

If i can read this 10bit stream then i can just rinse and reapeat, the actual commands are repeated and longer

Sorry, but could you elaborate on that?

e

 

[hal9000]

Please see Manual 2, p.214
You'll need an 8MHz resonator for 32MHz operation.
The 28X2 5v will "ignore" the 16MHz

e

I see... hmm.. well right now i have setfreq em16, i'm using the axe022 proto board with jumpers set to X2 position with the 16mhz resonator in there and i see a significant speed increase... (x8 over normal operation)

 

[hal9000]

Sorry, but could you elaborate on that?

e

Its irrelevant for now, the single 10 bit stream is what needs to be read, the actual practical use is to read several 10 bit streams, but they are seperated in time from each other, so will only need successive iterations of reading the 10bit stream to read info and decode instructions. The coding for that is relatively simple, right now explaining that will only serve to confuse things

 

[hal9000]

I'm not sure what you mean by the PULSIN takes to execute but I'll guess how long you mean between one PULSIN and the next so it doesn't miss pulses. I'd guess approximately 250us-500us at 4MHz, so you could be missing some pulses but 16MHz should have fixed that. Trying to bit-bang read IR can be a bit hit and miss.

Have you put a scope on the IR data line to see exactly what you are receiving ?

I see. yeh i think this is what i was seeing at 4mhz, missing stuff because of the length of time it takes to execute the next pulsin command.

Now its been pointed out that i might have my resonator setup incorrectly anyway which might explain the continued timing related issues... i'll try work this out.. but right now i seem to have it hooked up at 64mhz!?

I have scope on the input yes, and what i describe is a fair approximation of what i see... I notice you say IR data line... yes, it is from a signal that could drive an IR LED in some applications - for this one they drive the interface directly over a cable instead.

 

[westaust55]

There was a very very similar thread to this recently looking to decode data from a lazerdisk player - Pioneer brand I recall.

In the first post, there was a link to some work done by others outside this thread.

Unfortunately after I responded, the poster responded but also deleted the first post (poor performance there ) and the moderators then seemingly took it upon themselves to delete the entire thread.
So I cannot find the previous information or link.

As the waveform is two pulses per bit with the 1 or 0 being determined by the duration between the two pulses, the PULSIN command would seem idea and run the PICAXE at max speed.

As I had mentioned in that previous thread, I suggest you need to quickly collect the state of each bit in the stream and may need to worry about compiling in a word varable once the entire 10 bits are received.

Then again if the PICAXE is fast enough maybe just:
- take the word variable
- multiply by 2 to bit left 1 bit left
- put the new bit in the lsb position
- fetch the next incoming bit.

Information such as:
- what is the time duration between each 10-bit data stream
- how many lots of the 10-bit data sequences do you need to receive? 1, a few, continuous stream?
could be helpful in assessing a concept

 

[inglewoodpete]

I used a fast PICAXE (20X2 @ 64 MHz) to decode NEC formatted (32-bit) Infra Red remote control signals. This protocol uses the gaps between pulses to deliver 0's and 1's. It seems to be similar to what you require. I documented to project in the completed projects section.

For a hardware + slower PICAXE solution, have a look at another of my designs described in post #8 of this thread.

 

[hippy]

There was a very very similar thread to this recently looking to decode data from a lazerdisk player ... Unfortunately after I responded, the poster responded but also deleted the first post (poor performance there ) and the moderators then seemingly took it upon themselves to delete the entire thread.
So I cannot find the previous information or link.

I had the same deja vu and it could have been this one ...

http://www.picaxeforum.co.uk/showthread.php?t=17222

I wouldn't have expected a moderator to delete a thread if there were anything but a single 'deleted' post.

 

[hal9000]

Thanks for you responses guys, especially inglewoodpete i will read and digest and report back. I have been called away abroad for a couple of weeks so i wont be able to test any of this out in hardware for 2 weeks, but just typing out the problem i think has helped in some way too

 

[hal9000]

ok.. if anyone is still interested i have learned a few more thngs since the start of this thread,, namely :

- I got hold of a coupe iof new 28x2 5v 64mhz PICaxes..
- I borrowed a logic analyser which has really helped

here is my code:

' Testing serial comms input from controller pcb 
' 
' PHYSICAL HOOKUP:
' 	PinC.2	=	Laserdisc Controller PCB output
'	PinB.0	=	Logic Analyser input D1
'	
'
' CURRENT WORK DATE : 20/02/11
' 

#picaxe28x2
#no_table

	setfreq em64	 			'64mhz opration (16mhz external oscillator used)

initialisation:
	
      pause 500					'powerup wait period (probably not needed? old habits..)

      let PinsC=$00 				'set PortC as input
      let PinsB=$FF				'set PortB as output 

Main:

  setint %00000000, %00000100, C		'Set interupt for PinC.2 
  low B.0

start:


goto start


interrupt:

	high B.0					'indicate we are in the interrupt routine

	setint %00000000, %00000100, C	'turn the interupt back on

	low B.0					'indicate we are leaving interupt routine

return

end

and here is the resulting Logic analyser code :

So, observations:

- The original controller output doesn't appear to be particulary rigid, with some double-dips, and some shorter than normal low-going pulses.
- the Picaxe doesn't always pickup on the low-going pulse
- I don't think the Picaxe isn't going to have any time to process anything in the interupt routine...

questions :
- Should I abandon this method and go for using hspiin instead maybe? is that even possible?
- am i going to need to abandon the picaxe and find something else?
- Should i try and hack the controller to find a clock maybe?

any thoughts appreciated...

 

[geoff07]

My suggestions would be:
- use hardware interrupts, so you don't miss any (hint etc). The double-dips might be a problem to deal with.
- make absolutely sure that you have the fastest clock speed. If I read the timings right that looks a little slow to react to me for a 64MHz chip, though I'm not certain.
- in addition to clearing the interrupt, just use a single toggle flag statement in the ISR to keep it as short as possible
- have the main program process the flag perhaps using timer to check if pulse gaps are short or long by exceeding a threshold, but very economically
- leave all other work to after the pulse stream has passed.

 

[hippy]

The double pulses do look odd and it would be interesting to know why they are there, if part of the protocol or for some other reason. "PinC.2 = Laserdisc Controller PCB output"; it would be interesting to see how that compares against the output of a TSOP18 IR Receiver with pull-up.

Though the low pulses are short, these can probably be extended with a simple RC ( and perhaps a diode ) circuit which would allow PULSIN to be used as suggested earlier.

 

[inglewoodpete]

My suggestions would be:
- use hardware interrupts, so you don't miss any (hint etc). The double-dips might be a problem to deal with.
- make absolutely sure that you have the fastest clock speed. If I read the timings right that looks a little slow to react to me for a 64MHz chip, though I'm not certain.
- in addition to clearing the interrupt, just use a single toggle flag statement in the ISR to keep it as short as possible
- have the main program process the flag perhaps using timer to check if pulse gaps are short or long by exceeding a threshold, but very economically
- leave all other work to after the pulse stream has passed.

I guess I'll say this just 1 more time. This is how my background "universal" infrared receiver design works. Refer to "Completed Projects - Communication" here

- Fastest PICAXE available (20X2 @ 64MHz)
- Background operation, using hardware interrupts
- Independent timer
- Flag bits for status recording
- Calculation (determination) is done at the end of the pulse train

Why reinvent the wheel? The hard work has been done. The only thing that you will have to work out is how to recognise the train start signature.

 

[hal9000]

Why reinvent the wheel? The hard work has been done. The only thing that you will have to work out is how to recognise the train start signature.

I'll be honest, i looked at your code and started to modify it, but it gave me a real headache last month. Partly because i didn't understand some of it, and partly because I was getting compile errors. I will re-visit it today though... Sorry, I don't know what you mean by the 'train start signature' ? the line i'm monitoring stays high all the time, and the code you see appears on it... thats the start if anything, each 10 bit code starts with 001,thats the only sortof identifier..


@hippy - the double-dips are not part of the protocol they should just be low for as long as the rest, it might be my logic analyser, but that would surprise me.. unless the clock timebase that is creating the output is stretching and contracting, its 30 year old stuff so maybe? Also, i still don't see how the pulsin command would work as we need to measure the durations?

To all.. i didn't realise hardware interupts were different from normal interupts, i'll experiment, but i can see inglwood pete is urging me to go over his code again, and i duly will.

@geoff7 - My code snippet sets up em64 and has a 16mhz external res. I had thought overnight about overclocking the pic to squeeze some more speed out, maybe with a 20mhz resonator to get 80mhz... I did run an older 5v28x2 at 64mhz for a week or so while testing before, and while it was good for a few days, it started failing to download code without a manual reset, and serout commands started to produce errant characters, so i'm glad to actually have 64mhz spec'd ship this time rather than pushing the old one too far.

 

[inglewoodpete]

hal9000, A couple of points. The 'train' refers to the pulse train that you are trying to read. The 'start signature' is what tells the receiver that the following data is valid. That signature is used to start the code reception process.

I understand that you have a TSOP18 receiver/demodulator (or similar). As an exercise to better understand the code, I suggest you set up the IR recever on an appropriate pin. It would be easiest if you have a 20X2 to experiment with, however, any PICAXE that can run at 64MHz could be used, although some definitions may need to be changed. For the learning experience, use practically any IR remote control - most use NEC's format (however, not a Sony, of course!) You should get consistant logs appearing on the PR's terminal screen.

 

[hippy]

i still don't see how the pulsin command would work as we need to measure the durations?

The durations are the highs of the signal, the period between low pulses ( unless I've got that wrong ), so start the PULSIN while low and it will read the high length until it next goes low, repeat with further PULSINS until all bits have been timed, turn those times into bit values.

With 64MHz ( and perhaps RC stretching ) there should be plenty of time within the low pulses to end one PULSIN timing and get the next underway before it goes high again.

That won't work reliably at the moment because we are seeing those odd double pulses which will act as false bits. Hence 'why that is' is important to discover and if it's a feature of the controller it then needs a means to either hide the short / double pulses or work around them.

The reason for looking at TSPO18 output rather than the remote's output line is that the TSOP18 will give a clean 0/1 output whereas the controller output voltages may be near a level which causes the logic analyser to misinterpret them - The double pulses may not be there when detected via TSOP18.

 

[hal9000]

Hi Pete..

The train im trying to read is shown in the logic analyser screenshot, its a 5v carrier pulsing low. The duration between the pulses is the data. There is no header, there is no signature, there is no validity check, there are 10 bits that appear on the line as shown in the screenshot. I'm not using a TSOP demodulator, i'm not using anything with IR. I'm using a new 64mhz capable 28x2 which i'm running with a 16mhz external oscillator at 64mhz.

I have been modifying your code but I think that because i'm not reading a 32bit IR code with headers it will need extensive modification. As i'm not the original author of the code, modifying it is harder than writing from scratch. I appreciate your structure of how to detect and process a similar pulse train, i'm sure with the right modification it would answer my questions, but please understand i'm not a complete expert and able to modify your code in a snap, otherwise i wouldn't be posting here I also don't expect you to re-write it for me, but please know that i'm not re-inventing the wheel, i understand your code is doing a similar task, its not the same.

Currently yes, there is an issue with double-dip pulses.

Something very strange has happened now though, after i played with the Hintsetup command on this pic, i saw a noticeable response increase. But then I reverted to the old code again and the response is now very quick, how can this be?! see this :

Thoroughly confused now, but i'm happy its responding quicker. I'm not liking the double-spike of the picaxe now tho at some parts, and ignoring pulses at other times...

 

[hal9000]

thanks hippy, i think i see wht you mean now, i forgot it counts time not pulses. I had stopped using it ages ago because at the old 8mhz speed it wouldn't count anything meaninful.

The double-dips are not part of the protocol, they are definately errant, i'm now not entirely sure the logic analyser is ok... i'm going in circles :| i need some thinking time...

 

[hippy]

i need some thinking time...

In that I'd consider thinking about not including whatever it is you think you are achieving with the PICAXE. That seems to be clouding the issue when all we are after at this stage is determining what the signal is as a PICAXE would see it.

What the PICAXE does and how it will do that comes later.

It's actually more important than I thought to move to looking at what's received by a TSOP18 output; that's what the PICAXE circuit you later build will see so it's what you must be looking at ( though it's reasonable to compare that against what is actually being sent ). With the circuit of the remote unknown we can't tell how that affects whatever the logic analyser or PICAXE currently used may be seeing. Look at the TSOP18 output which is the signal you will have to ultimately deal with.

 

[inglewoodpete]

hal9000, I understand what it's like to rework someone else's code. I lived and breathed that code for a couple of weeks (and a hundred variations before I got it working and cleaned up).

Does the code arrive after a reasonable pause or quiet period (Eg 500mS)? Maybe the triggering that I've used in my code could be dramatically simplified.

Do you have access to an oscilloscope?

Actually, at these frequencies, you get away with a computer soundcard. With free Oscilloscope software and a stereo Line In cable (with two 10:1 attenuators), you can make a dual trace oscilloscope on your computer. That's all I used when I debugged my first Infrared decoder, a few years ago.

 

[hal9000]

In that I'd consider thinking about not including whatever it is you think you are achieving with the PICAXE. That seems to be clouding the issue when all we are after at this stage is determining what the signal is as a PICAXE would see it.

Abandon the PICaxe? I don't know how to make it more clearer... the Picaxe is seeing the 10 bit serial code as shown in the screenshots on input D0. I'm sure you're not suggesting we cut the PDIP package back and bring out the microscopic analysis machine and start probing the silicon?

What the PICAXE does and how it will do that comes later.

It's actually more important than I thought to move to looking at what's received by a TSOP18 output; that's what the PICAXE circuit you later build will see so it's what you must be looking at ( though it's reasonable to compare that against what is actually being sent ). With the circuit of the remote unknown we can't tell how that affects whatever the logic analyser or PICAXE currently used may be seeing. Look at the TSOP18 output which is the signal you will have to ultimately deal with.

I don't know what this TSOP18 is, i think its something to do with IR remotes, and you keep saying it,... I don't have one, i don't intend to use one... ? there are no IR remotes involved anywhere in this project... this is the output from an old laserdisc player show controller, intended to be hard-wired to a player to control it. I want to read the 10 bit stream and decode the commands.

The signal show in the screenshot is the signal i have to deal with... I appreciate your comments, but don't over think this... there is a 10bit serial stream i want to read... this is what i need to do... ?

I do appreciate the input, but i thnk you are trying to think what it is i am doing and referring to that idea, rather than what i'm actually doing?

 

[hal9000]

Does the code arrive after a reasonable pause or quiet period (Eg 500mS)? Maybe the triggering that I've used in my code could be dramatically simplified.

There is 33ms between the 10 bit choo choo train.

Do you have access to an oscilloscope?

Actually, at these frequencies, you get away with a computer soundcard. With free Oscilloscope software and a stereo Line In cable (with two 10:1 attenuators), you can make a dual trace oscilloscope on your computer. That's all I used when I debugged my first Infrared decoder, a few years ago.

I do have a 20hz hameg storage scilloscope, but not one hooked to a PC, its old school. I might have to build this soundcard scope tho, see if the logic analyser is telling me porkies. I'm also starting to suspect my USB port on the computer, it has had toruble with trakballs in the past, i'm wondering if there's an issue.

 

[hippy]

I don't know what this TSOP18 is, i think its something to do with IR remotes, and you keep saying it,... I don't have one, i don't intend to use one... ? there are no IR remotes involved anywhere in this project... this is the output from an old laserdisc player show controller, intended to be hard-wired to a player to control it.

My mistake as I'd got the impression it was an IR remote control and missed your last line comment in post #10.

What I was meaning by 'forget the PICAXE' was not to worry about what it's doing, how it responds to interrupts or whatever at this moment in time. I didn't mean abandon PICAXE, just ignore it for now, concentrate on determining what the signal fully is first.

It doesn't really matter how you read and decode the signal, just that you can, and if we have these odd type pulses they will have to be dealt with, in software or hardware. Knowing exactly what those signals are will provide the indicator of how that's best done. If PICAXE code cannot tolerate such pulses then that code won't work. I don't see double pulses as a particular problem that can't be worked around but it may affect the way the code is written and what code works - more importantly, what code doesn't.

What would be good to know is what the voltages are of the signal. A circuit of the controller would also be handy to have but possibly not available.

What would also be useful is a zoomed-out capture of the data which also shows a full signal sequence over a longer time frame.

 

[hippy]

One useful PICAXE test you can do with the logic analyser is to read the input pin and replicate that as an output as fast as posible. That will give a good idea of what the PICAXE is seeing -

#Picaxe 28X2
SetFreq EM32
dirB.0 = 1
Do
pinB.0 = pinC.2
Loop

 

[hal9000]

thats what i see from your code, i've upped the sample rate to 20khz, my thoughts are now that the incoming signal does indeed transition a bunch of times rather than just sit low.. the higher the sample rate the more transitions i see when it should be just low...

(this is a whole 10bit stream)

 

[hal9000]

ok, so i'm still learning the Logic analyser here, but here is the first few transitions zoomed in... (there is a 1.2ms space between low pulses, indicating a 0)

You can see that the 'low' from the incoming signal which i had thought to be low all the time is in fact a square wave..

This is sampled at 100khz, this looks the same, sampled all the way up to 500mhz. This is showing your basic replicant code Hippy...

here is the output from the controlling hardware :

I joined and 470ohm resistor between the shield and the signal, this gives a 5v carrier transitioning low.

I also hooked the LA to pin 12 of W3 to see what it was feeding in, and of course, it is the inverse of what i have been currently seeing, with the stupid fequency in the pulses.

 

[hippy]

thats what i see from your code

There's something very odd going on there with the PICAXE seeing signals which aren't present in the incoming stream and missing some which are.

The hardware output drive is interesting - and thanks for posting that. It's not referenced to 0V so it could come down to how you are interfacing things. It looks like the output is intended to drive an opto-coupler isolated input. You probably will be seeing odd things using the logic analyser and how the PICAXE sees things without one.

 

[hal9000]

What would also be useful is a zoomed-out capture of the data which also shows a full signal sequence over a longer time frame.

This signal sequence is the biggest i can do with the scaling...

This sequence shows 3 commands, 0011010000 0011010000 0000000000

Not amazingly clear, but good enough. The controller squirts out a sequence of either 3x 10 bit codes like this shown above, or 34x 10 bit codes depending on what its trying to say to the player, but that is how they are clustered. I can do the programming to decode afterwards, thats not what i need help with, right now i just want to grab the 10bit sucker by the throat and read it

 

[hippy]

See post #32 as you were probably typing when I posted.

Also; there seems to be a green tint in the background of the "D0" trace; is this really there, and is it a high frequency carrier wave, or just an illusion ?

Could that be the "stupid frequency in the pulses" you mention - which makes me think it is an IR LED style modulated pulse stream even though wired not IR. That should however have completely messed up the PICAXE responses seen earlier but that could be tied into lack of opto-coupling.

 

[hal9000]

You're seing things there's no high frequency there...

http://www.andysarcade.net/pix/Clip_5.jpg

That is the actual output, with the correct resolution of whats going on in the low pulses.

So, lets say that the PICaxe interupt is waiting for a low transisiton on a pin, but it sees this high frequency (30us cycle) it can't quite decided if it sees it or not... ? hence its just not firing all the time.

Do you think i should try run this signal into a 555 to give a stretched pulse that the picaxe can actually see?

I would say that this stream was once destined for IR, but in this configuration they went with hard-wired instead

 

[geoff07]

Have you thought of using IR and let the TSOP48xx clean it up? Then you get isolation as well!

 

[hippy]

You're seing things there's no high frequency there... So, lets say that the PICaxe interupt is waiting for a low transisiton on a pin, but it sees this high frequency (30us cycle)

So are you saying there is high frequency or there isn't ?

Assuming it is there you'll have to demodulate that, and the easiest way is likely an IR LED and a TSOP18. Then back to earlier and look at what's coming out of the TSOP18.

 

[hal9000]

This is what i'm talking about... The protocol says these manic periods of 30us square waves should be a period of all low, but its not. I think thats why the PICaxe's interupt isn't being reliably triggered. This is what i called high frequency silliness...

You were describing some green hue to the whole trace, that is not there, i think it is green tinged because its a JPEG.

Can you tell me what TSOP part number you are referring to and i will go look at a datasheet andthink about going down another road.

At what speed of pulse do you need to get to before the PICaxe just cannot see it reliably? here we have 30us pulses that are causing the picaxe trouble.

I still don't know how to implement the hardware interupts properly, are they only available on port B ?

 

[hal9000]

I've just talked with someone else that has verified that this is correct operation, its a 38khz square wave in the low periods.

So i guess my problem is, this 38khz cannot reliably trigger a PICaxe interupt... (and i've been chasing a problem that isn't there)

I started looking at TSOP datasheets, and i'm now guessing that you would reccomend i actually make this drive an IR LED then use a TSOP of some kind to go from there? feels a bit like a kludge...

 

[geoff07]

That was my point. And if it is 38khz (I thought 33 but didn't measure it) then the TSOP4838-equiv that rev-ed sell is the business. It isn't just a photocell, it has logic in it that demodulates. And costs 50p from rev-ed. No kludge. You just need enough oomph to light an IR led on the sending end, range <1cm. Another 13p. Your kit was designed to use IR in the first place. The alternative is a retriggerable monostable, and that is harder.