hi guys!

Do you have an idea how exactly is Sony SIRC protocol implemented in original Sony devices?

I am working on a project where complete data transfer between my own devices is based on Sony SIRC protocol (38 khz). The point is that I would like to know if there is anything that can be done to prevent my data colliding with Sony devices in the same room. I read nigel's articles about IR but I would need to know the exact Sony implementation so I could realize if there is a way to prevent this kind of collision. Have anyone of you already experienced a similar problem? Can you recommend any steps I should perform in order to solve this problem?

thank you for any feedback,
krompo

 

Read the tutorial more throughly!.

It explains about SIRC's, and how it uses a 'device code' and a 'command code', all you have to do is alter the device code to one not used by your Sony equipment. The tutorial also lists all the Sony 'device codes' I had remotes for, so there are plenty of unused codes for you to choose from. The transmitter code also includes a number of 'command codes' in the source, although as long as the 'device code' is different it doesn't matter what 'command codes' you use.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

Only the same devices cod have this problem.Since an TV will ignore an VCR comand.(And the other way round)Becose it sends for what type of device the signal is ment for along the data.

But 2 TVs will get the signal.

__________________
Il give you shocking experience.

 

hi nigel!

I read your tutorial so I know what you are talking about. I understand how device code and command code are working. The point is that in my project I use SIRC protocol to transmit any kind of binary data (regular data transfer) from one PIC to another and therefore it is very probable that it will happen once upon a time (or quite often as well) that my data may look like pretty valid device + command code for any Sony device in the room - since any combination of bits may occur while transfering data in my project.

The reason why I asked you for a very exact implementation of SIRC in original Sony devices is following:
If I knew for sure that Sony uses the exact same algoritm as you are using in your tutorial, everything would be very simple for me. When you check for start bit, valid range for startbit is from 1.2 - 2.4 ms. If the pulse is longer than 2.4 ms it is error for you. Therefore if I would change in my project the length of startbit to 3 ms, my project would work fine and I wouldn't collide with your system since you wouldn't even start receiveing any data since you didn't get any valid start bit. The problem is that I don't know if in Sony devices they check for the upper limit of start bit as you are doing or, if the pulse is greater than 1.2 ms it is allways a startbit so if it would be 3 ms it would be a valid start bit as well. Is it possible to see what I mean?

or, do you have a better approach how to handle this?

krompo

 

Just include a device ID with your transmission, as SIRC's is designed, that way it can NEVER randomly activate your Sony items. Presumably you want to send 8 bit data? (and SIRC is only 7 bit), you could either extend the entire word by one bit (giving 8 bit data and 5 bit device), or 'steal' a bit from the device code (giving 8 bit data and only 4 bit device). In both cases you would have to choose the device ID carefully, as Sony items would consider it bit zero of the device ID, but there are plenty of suitable codes available - for example, using a device ID of 4 (for a 4 bit ID) would translate as either 8 or 9 (depending on the eighth data bit) to a Sony, expecting 5 bit ID - neither of which are used.

I've no idea what the tolerance of the pulses is, as they can vary considerably (which is why this scheme is used), I would suspect 3mS would probably be recognised by a Sony anyway.

Just do it the way the SIRC system is designed, include a device code that you don't already use in your house, why complicate something that doesn't need it?.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

don't you think as a solution to this problem to use 56khz instead of 38khz? In such I case I wouldn't need to change anything (except the frequency itself). Are there any Sony devices that are using SIRC protocol on 56khz?

krompo

 

Not as far as I know?, I've never seen 56KHz used in the UK.

But it seems a pointless change?, you would still have to change the routines to use 8 bits (assuming you want 8 bits?), so it wouldn't make less changes required - in fact it would require more changes, because you would have to rewrite the transmitter routines.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

I counted these changes within the freq. change - it is still a minor change. The situation is that I already have my project up and running and it is all custom based - data I transfer range from 1 to 4 bytes. So I send a start bit following up with max. 32 bits. My goal is performance as well, so I am not very happy to include additional bits that are useless to my project - exactly opposite - I would like to speed up the current performance. As my application starts there is a constant data exchange that last until the application shutdown - so it is unpredictable what bit configurations will be transfered (it is based on another data that are not predictable so I can not guarantee any constant bits).

Everything is working fine this way but still I didn't try it yet to put my application in the same room with Sony devices.

I will probably go to search a little bit and hope I will find an IR Receiver chip that is able to switch states about 200 - 300 us (my current chip is not faster as 400 us). If I find such a chip, I will try to make the project 2x faster by reducing the pulse times by a factor of 2 (so instead of 0.6/1.2/2.4 I would have 0.3/0.6/1.2) - do you think is that a way to go?

krompo

 

You've never mentioned this before!, it obviously makes sense now you've explained what you're trying to do.

It's worth a try!.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

well, my mistake, sorry

anyway, if you have any comments, fee free to tell them, now when it is clear. I will go look for such a chip, since it would solve both my problems (performance & SIRC collision) at once.

krompo