VSM RS232 serial data simulation queries

[Pauldesign]

Hi

I have some few RS232 serial data simulation queries.

1) The SIR protocol stipulates a start bit and 12 data bits (7 data bits and 5 device bits). Is the order of the data bits MSB or LSB because when i analysed the infraout commands the data bit are flipped or mirrored. Neglecting the start bit and delays between bits: a data bit e.g of 5 and a device ID of 1 displays as 1010000 10000 instead of 0000101 00001.
What type of data format is the SIR protocol transmitted?

2) How can i analyse a serial data stream using the virtual scope? For example sending the code serout 2, N2400 (#b0 or b0 or "b0") where b0=5, i expect to see the RS232 protocol with 5 as the serial data but i see just a straight line (zeros). I can see the serial data (5 in this case) using the virtual terminal but disappears if i connect a scope.
What i'm trying to do is to modulate a PWM signal with a data bit connected to a Schmidt trigger NAND gate, whose output goes to a virtual IR link, then scope the output of the optocoupler to see if the data is right (although this can be monitored using a LED). I've achieved the above (OOK) using a high (38KHz) as carrier and low (1KHz) as data signals of 50 % duty cycles each and it work just fine but not with a serout command.

Can somebody please enlighten me.

Rgds

Paul

 

[hippy]

1) The SIR protocol is a serial protocol but not an RS232 compatible protocol. SIR is a start pulse followed by a stream of varying length on and off pulses, msb first I believe, RS232 is a start bit then bits either high or low at fixed time intervals after that, lsb first. Trying to read SIR as RS232 will give varying results and won't reveal what the SIR data is. You either need to look at the signal on a virtual scope or a virtual SIR decoder ( if there were such a thing ).

2) I'm not familiar with VSM and using virtual instruments but I would expect that if the RS232 decoder terminal is displaying the data sent via SEROUT the scope connected to the same signal line should be showing the signals sent. I don't know why the terminal display disappears when the scope is connected.

 

[Pauldesign]

Hi Hippy

Thanks for having a look at my post and your comments.

1) The VSM is a great simulation package and does reveal exactly what the IR
data is, my concern was why the 12 data bits appears to be reversed which
from doing some internet reading although not trust worthy but make some
sense, it appears that the 12 bit data format is device ID first (5bit) then
data or command bits (7bits) next. Then during transmission, the order is
reversed i.e 7 bits command codes then 5 bits device ID. E.g To send 5 using
TV device ID 1, it should be a start bit, then 00001, then 0000101 (1 00001
0000101 ) but will be transmitted LSB first as ( 1 1010000 10000 ) and this
explains exactly why the VSM scope shows the data reversed during
simulation. In order words the picaxe data sheet explain but the transmitted data which means a serial data of 5 will be displayed as 10 and vice versa.
Maybe Rev Edu might like to investigate this more and make it clearer in their tutorial. Just a thought.
==========================================================
Is it possible to use picaxe and implement the SIR protocol using a different device ID besides 1 because if a different device ID codes is use PICAXE prog edit displays a syntax error which means picaxe and the SIR protocol is limited to or can directly control only a sony or equivalent TV besides PICAXE to PICAXE coms.

Rgds

Paul

 

[hippy]

The PICAXE Manual 2 describes the protocol on Page 95 and shows data sent as start bit, 7 data bits ( lsb first ), 5 ID bits ( lsb first ). That seems to match with other SIRC data I have ( http://www.sbprojects.com/knowledge/ir/sirc.htm ) and also matches with IR remotes set to generate TV control signals I have looked at.

I therefore think web sites claiming that ID is sent first are incorrect and have led to this confusion.

The PICAXE can send SIRC using INFRAOUT and IROUT with any of the 32 device codes but INFRAIN, INFRAIN2 and IRIN are only programmed to accept data with Device Code 1 (TV). It can be possible to write bit-banged code which will receive SIRC signals for other ID codes.

 

[Technical]

The oscilloscope should be used in VSM for 'analogue' signals, the logic analysers for digital signals. This is because VSM is a combined SPICE/digital simulator - there are two 'levels' of simultaneous simulation, both SPICE analogue and microcontroller digital.

Although most of the time the difference is not visible to the end user it is much better to use the appropriate diagnostic tool that applies to either the digital or analogue signal being looked at.

 

[Pauldesign]

Hi

Thanks for the replies and the link. It was spot on as it exactly replicates the SIRC protocol when viewed using the virtual scope (I still have to figure out how to view data using the LA, i'll appreciate an example in the sample files). The example in the link says it all and something like it will be good to be in the manual for people who really want to understand it rather than just implementing it and having dark results (happy since it's working but not knowing what is happening in reality). Anyway i know it by asking.

With regards to the tutorial on manual 2 page 95, i saw that before and that was why i couldn't figured out why the transmitted data was reversed or transmitted LSB first. Data0 to Data6 (command code) and ID0 to ID4 (device ID code) if that was your argument, to me is not really clear to mean LSB transmitted first especially with all the ambiguity in different serial protocols which can be mis-interpreted to mean something else since Sony doesn't really support the protocol which brings me to the point why some people view it and convince themselves with device ID transmitted first then command next and to make it interesting, i'll ask this question.

1) If the command is transmitted first before the device ID, how do the device stay awake to receive the command? Which in my opinion makes sense for the device ID to be transmitted first to awake the device to receive the command following next and then performs the given task.
Which i can convince myself also to support command transmitted first before ID by saying that is why the transmission has to be perform more than once for reliable coms and this means the first command send is always a waste. Just my thought, not so sure.

================================================================================

2) By doing some arithmetic of the SIRC protocol pulse widths, i realized that the maximum duration to transmit a 12bit SIRC frame (start to start transmission packets) is 24.6mS and the minimum duration is 17.4mS.
Most IR data sheets including picaxe talk always of 45mS time frame between successive transmission.

Does this 45mS means the total time length (duration of each transmission) or the delay that must be included between successive frame transmission?

Am i right to convince myself by saying the 45mS is just a safe value and is used to prevent successive frames from overlapping because of the 15 and 20bits versions of the protocol whose max frame transmission might be around 45mS.

Rgds

 

[hippy]

I'm not sure how you mean by "Sony doesn't really support the protocol" as it's well defined and in widespread use, though perhaps not if one doesn't have Sony equipment. It has however been adopted by many others wishing to use IR communications, most IR remote controls can be configured to send SIRC data.

On your questions ...

1) All receivers will wake up when they see the elongated start bit and will then read all 12 bits, 7 command bits and 5 ID bits, each receiver will then decide whether to ignore or obey the command depending on what the ID bits are and if they match its own ID. There is no wasted command, no need to send the IR 'packet' twice. Some devices will wait for a second packet simply to confirm that it wasn't a false trigger but that is up to the receiver's designer to decide.

2) The delay ( usually said to be 45ms ) is the time to be left between consecutive packets sent. It may not be known what the reasoning for any actual period is but it probably includes time for a receiver to act upon the command data it received and to update any storage if it needs to. Some receivers may check the timing to try and filter out noise and transmissions which aren't directed to themselves but which may be mistaken as such. Reality is likely that the 45ms derives from what people observed a genuine Sony Remote Control putting out and this became the de-facto standard.

The repeat timing is also important for a receiver to tell what it is receiving; if a packet arrives within a certain period after the previous packet it can determine that if it's the same command and not take any action and misinterpret it as two distinct key presses. A receiver can also use that to tell when a key is held and it should go into an auto-repeat mode; such as pushing Fast Forward once may put a VCR into fast forward until Stop or Play is pressed, but a prolonged Fast Forward push and hold may fast forward until the key is released with an automatic drop-back to play.

I don't think the timing has any relationship to other SIRC code formats as this was designed before they existed.

 

[Pauldesign]

Finally this concludes this issue and i believe somebody will learn alots from this in future. Kudos Hippy, i must appreciate your time and explanation to this issue. Thanks once more and keep up with your great work.