Skip to main content ↑ ↓
Topic: Why the 0xFFFF? (Read 9371 times) previous topic - next topic

Why the 0xFFFF?

Is there a real need for this in sampling mode? A programmer is responsible for managing the data buffer, so adding extra stuff is not useful. I don't have/see a need for a mark after 1.7s of inactivity.

Re: Why the 0xFFFF?

Reply #1 –
I think the goal is to make it possible for a program to read bytes until it sees 0xFFFF, and then jump to decode.  Without the 0xFFFF flag, a program would have to set up a timer, which complicates the design.  There's also the chance that the two side (IRToy and host) could have slightly different timings, and messages might be split.

In my OSX client for the v1 IRToy, I have a timer because there was no other way to trigger the display.  However, sometimes my timer gets out of sync with the RC commands, and my display cuts the message in half.  I still haven't updated my client for the new sampling mode, but I think the 0xFFFF should make display much simpler.

By the way, as I keep trying to inspire folks to write a "real" custom USB implementation for the IRToy instead of just using the CDC serial layer, it would be possible to have each IR command sent as a single USB packet, and then the 0xFFFF terminator would be redundant.  USB already has specific rules for detecting the end of a packet, so there is no need to add extra data to signal the end.  But the problem with my idea is that the Windows folks would have a much harder time writing software for custom class USB instead of simple serial, so we're back to needing a way to flag the end of a sequence of data, since there are no packets in serial.

Re: Why the 0xFFFF?

Reply #2 –
0xFFFF wouldn't ever be redudant. LIRC needs the space between remote signals. And the IRToy stops at 1.7 seconds or whatever it is. LIRC technically supports up to 16 second spaces between signals but that's over kill really.

Re: Why the 0xFFFF?

Reply #3 –
I can decode the signal perfectly in Windows without the need for an extraneous 0xFFFF in the way. Right now I have to code around it, just trouble without a benefit.

Who waits 1.7s to start decoding? Makes no sense. I mean the button pressing in a remote or the gap between repetitions determine the space between signals, not the IR Toy, which outputs what it receives.

USB programming in Windows is a pain, and will be until .NET embraces USB, hopefully way better than they did with the serial port.


libusb Windows Backend

http://www.libusb.org/wiki/windows_backend

libusb-win32

http://sourceforge.net/apps/trac/libusb-win32/wiki

Re: Why the 0xFFFF?

Reply #4 –
The 0xffff isn't so much a special flag, as it is a timeout. The IR Toy, unlike many receivers, can measure the long inter-pulse space of the repeat signals for certain protocols, etc. One thing Dukey mentioned when we designed the sampling mode was that the 50uS x 0xff (255) maximum time of the UIRT2 was too little for some protocols.

0xffff marks the end of packet, and helps sync to the IR pulse train. Without it, you'd end on a pulse, and then the next data would also be a pulse.

It's also used because we adopted a 16bit version of an existing protocol that used a 0xff termination flag.

Because 0xffff takes so long to arrive, it's not much use as a 'send to decoder' flag. Most people want more responsiveness, and if you hold the button on many remotes the time between commands is much less than 1.7seconds, so you end up needing some form of timeout anyways.
Got a question? Please ask in the forum for the fastest answers.

Re: Why the 0xFFFF?

Reply #5 –
Quote
0xffff marks the end of packet, and helps sync to the IR pulse train. Without it, you'd end on a pulse, and then the next data would also be a pulse.

If you press buttons several times, you get several signals, so it doesn't mark the end of a packet, unless a packet means any number of signals, plus 1.7s of silence.

The programmer has to manage the data buffer, how do you end on a pulse? Are you talking about the programming of the uC? The uC routine can keep measuring 1.7us after the "last" signal, it's the 0xFFFF where I see an issue. Is like you are trying to catch a fish in the water and an old Coke can passes you by, it gets in the way, is useless for your purposes.

The IR Toy already made the time measurements and is giving them to you, no sweat, why do you need syncing?

The next data happens all the time (new signals) without a problem. We are working with groups of bytes (signals), what makes the end-of-one special over the other, ... it's not, is the 0xFFFF what makes it a "special" case, but it is not.

Quote
It's also used because we adopted a 16bit version of an existing protocol that used a 0xff termination flag.

The part that makes sense, in the sense that it explains why.

Quote
Most people want more responsiveness, and if you hold the button on many remotes the time between commands is much less than 1.7seconds, so you end up needing some form of timeout anyways.

Again, why measure the measurement? That's what the IR Toy does for you, why do you still have a need to keep measuring time when you are dealing with data? You analyze data and process data (as fast as you can), you don't expect a timeout (you don't need it), you expect data for each signal (any number, any time).

Re: Why the 0xFFFF?

Reply #6 –
Quote
unless a packet means any number of signals, plus 1.7s of silence.

That is exactly what it means.

I guess I don't understand the alternative.

The IR Toy measures a signal

-------_________------_____------________-----

I believe you want to get rid of the 0xffff at the end and just send the measurement for the last signal.

--__--__--__--_____(between presses)________--__--__--__--__

How long between IR pulses should the IR Toy wait before resetting and not measuring? Does the computer time this independently and also reset? How do you know if the next measurement is blank or pulse?

Above, how much time should (between presses) be for:
A) send a the blank measurement, for example a repeating key press (short space between pulses)
B) don't send the blank measurement, for example long space between different key presses (next value will be pulse length measurement)

Do you just want a shorter timeout? We can do that, or even make it adjustable.
Got a question? Please ask in the forum for the fastest answers.

Re: Why the 0xFFFF?

Reply #7 –
I'll summarize my point, the IR Toy does the measuring and the syncing of IR signals, then it turns those pulses into protocol-based data.

The focus turns from measuring time and syncing to signals, to processing data, at a higher level (an abstract level).

So you don't think in terms of syncing or measuring time, that was done already, what you deal with is typical PC issues of filling a buffer, taking data from buffer, processing the data.

We are not talking about collision-sensitive data fragments, like TCP packets, but a stream of bytes, you analyze and process data as it comes from the serial port and fills your buffer(s).

At no point in the process you check for a token/mark (0xFFFF), because there's none, until 1.7us of inactivity have passed, and that measure means nothing to the data that was already decoded.

And no one will wait for this token/mark to (start to) process data, it is not data-bound, is just another measurement extraneous to the IR signal data.

Quote
How long between IR pulses should the IR Toy wait before resetting and not measuring?

That's a MCU issue and not protocol/data related. The time elapsed between two IR signals becomes important if the IR protocol doesn't provide a toggle bit like RC-5 does, in other words, when dealing with repeat signals.

The time between signals is a bit different from the particular case of the elapsed time (0xFFFF) of simply inactivity of the IR decoder/MCU. As the MCU waits, then resets, it ensures the next signal will be picked up by the IR decoder, as expected, but this is a hardware issue.

If we are talking "data" at the protocol-PC level, adding extra data messes things a bit. We are not talking about the time that passed between two signals, but the inactivity time of the IR decoder.

So the IR decoder/MCU inactivity timeout routine is not the issue, is the sending of the 0xFFFF as part of the data coming from the IR Toy.

Quote
Does the computer time this independently and also reset?

The PC/code doesn't reset, it keeps processing data as it arrives at the buffer.

Re: Why the 0xFFFF?

Reply #8 –
The IRToy doesn't send remote signals to the pc. It just streams a series of data. It has no knowledge of what the data might be. The 0xFFFF just gives you an opporunity to resync, and it says the max timeout has ellapsed and no change in signal has occured. That is all. LIRC needs the gap between the remote signals to work stuff out like repeats, and the 0xFFFF just says the max time has elapsed. I don't see what the big deal is.

Re: Why the 0xFFFF?

Reply #9 –
I'm sorry, I still think I'm not understanding what you're saying.
Quote
you analyze and process data as it comes from the serial port and fills your buffer(s).

But if it is just a stream of bytes, filling your buffer, don't you need a way to tell the end of one IR pulse train and the beginning of another?

How do you propose in your system to know if the next data is a measurement of a pulse or a space? There is no end flag so any measurement can be a pulse or a space, depending on how long it's been since the last data. I don't see how you can tell without having a time out. You'll have to explain this to me with some pesudo code, because I think I'm totally missing what you're getting at.
Quote
me >>How long between IR pulses should the IR Toy wait before resetting and not measuring?
That's a MCU issue and not protocol/data related.

Well, I'm the MCU guy and I have no clue where to set it. Would you say if no more activity for 1.7s just not send the 0xffff? That's dooable, and can be added as an option. What is the optimal delay after which I shouldn't report the silence?

Quote
The time elapsed between two IR signals becomes important if the IR protocol doesn't provide a toggle bit like RC-5 does
Most don't, I believe this is generally important info to have.

Quote
If we are talking "data" at the protocol-PC level, adding extra data messes things a bit.

How so? You get 0xffff and know the receiver has been quite for a while. You could even move to a low-priority service level to save on system resources. I guess I don't understand this because the decoder 7 and I write (python), and Dukey's plugin, and everything that supports the UIRT2 (LIRC, WinLIRC, Girder, etc) all use this format. We thought it was smart to use what other people have developed through hard work, engineering, and trial and error.
Got a question? Please ask in the forum for the fastest answers.

Re: Why the 0xFFFF?

Reply #10 –
Quote
But if it is just a stream of bytes, filling your buffer, don't you need a way to tell the end of one IR pulse train and the beginning of another?

A 0xFFFF is not gonna help you when you have more than one signal coming in before the 0xFFFF appears in the stream, which only happens after one of the signals ("the last one"), and it appears too late to be of significance to anything, it's just a hardware state (inactivity), not a signal descriptor.

Quote
Well, I'm the MCU guy and I have no clue where to set it. Would you say if no more activity for 1.7s just not send the 0xffff? That's dooable, and can be added as an option. What is the optimal delay after which I shouldn't report the silence?

"... the IR decoder/MCU inactivity timeout routine is not the issue, is the sending of the 0xFFFF as part of the data"

So I don't mind how long this delay is, but you got it right: "just not send the 0xffff?"

Quote
Most don't, I believe this is generally important info to have.

And we have it, is in the data (no problem there), but the 0xFFFF is not that, is something else, hardware inactivity info, not IR data info.

Quote
You get 0xffff and know the receiver has been quite for a while.

Why would I like to know that, the protocol saves me from dealing with the hardware, or that's what a protocol should aspire to, to shield you from the level below.

If you are timing things, don't you know already what's going on, you are not blind here, don't you have an idea about the IR signal protocol and the data you expect?

Quote
You could even move to a low-priority service level to save on system resources.

That's a MCU perspective in my opinion, my code only works when there's data to process, it does nothing when there is none.

I'm trying to separate the hardware side issues, from the PC side issues, they are separate.

Quote
I guess I don't understand this because the decoder 7 and I write (python), and Dukey's plugin, and everything that supports the UIRT2 (LIRC, WinLIRC, Girder, etc) all use this format.

I can tell you from my experience coding my application, you don't need it, if you code with it, or around it, it only shows that it is not essential, hence not part of the data, again, is hardware info, how it does it is not my concern. I'm not saying that there shouldn't be a MCU reset routine or when it should take place.

Quote
We thought it was smart to use what other people have developed through hard work, engineering, and trial and error.

The protocol the IR Toy uses is smart, I only object the sending of 0xFFFF after X number of seconds.


Summary:

0xFFFF => Doesn't represent the time elapsed between two signals, so it shouldn't appear in the stream of bytes (the data).
0xFFFF => Signals that X number of seconds have passed since the last signal so the MCU is resetting.

I wouldn't code based on a hardware routine, but code based on the actual data from the IR signals.

Re: Why the 0xFFFF?

Reply #11 –
The 0xFFFF is part of a particular streaming communication protocol, but I think that this topic is getting confused by discussions of what happens outside the protocol - e.g. the various Remote Controls with different protocols, the IRToy, and the USB host.  I don't think there is any way to understand "Why the 0xFFFF?" unless you focus on the protocol itself and ignore the distractions.

The most basic description of the IRToy sampling mode protocol would have to mention that some information is missing, and that is the state.  There are actually two state variables in the protocol, one is the high-byte versus low-byte, and the other is the pulse-time versus the blank-time.  There is no way to be certain that the USB host has these two state variables correct without some kind of periodic sync.  Every streaming protocol that is in use in the technology world has some form of synchronization to reset the state, even though this sync carries no useful content.

@liyin: You might be assuming that your program always receives the first byte of the protocol and never misses a byte for the duration of your connection.  But what if that is not true?  What if your protocol decoder misses a few bytes?  Then your decoder will not be in sync with the IRToy, and might decode a pulse and a blank, or swap the high byte and low byte.  I don't see why you're complaining about the sync byte unless you don't have full experience with streaming protocols (like MP3, MPEG, etc.).

Sure, it would be possible to reset the IRToy with 5 0x00 commands, followed by the sampling mode command, but that's a lot of extra trouble for sync and you might miss some IR measurements during that time.  The 0xFFFF sync allows your decoder to stay synchronized while continuously measuring.

P.S.  It actually seems possible that if a single byte were lost, then the IRToy sampling mode could easily get confused.  The high byte and low byte order would then be reversed, plus the word pairing would be wrong.  You might think that USB is totally reliable, but if you put enough devices on a bus then you could lose a byte.  At the very least, even when USB is 100% reliable, a program could be started at the wrong time or become unresponsive and lose a byte.

Re: Why the 0xFFFF?

Reply #12 –
Are you going to wait 1.7s to sync? Why sync? Aren't you analyzing the data coming from your buffer? You know for example that RC-5 uses 14 bits, you know how it translates in the sampling protocol, you know what to expect, this is no streaming data format like MP3, MPEG, etc.

Either you have the right amount, and right values, or you don't. You either get out a correctly decoded IR signal, or a badly decoded one that doesn't translate to one of the values in your table (hence you discard it), or you don't do nothing for that one IR signal in particular.

The next signal gets decoded independently of the previous one (this is what you should strive for in code), no need for a mark, which god knows when it's coming, but can take a while, and I don't see why wait for it.

You are talking about a not very responsive application if it needs a 1.7s mark to sync again.

Re: Why the 0xFFFF?

Reply #13 –
Quote
You are talking about a not very responsive application if you need a 1.7s mark to sync again.
You've used the winlirc plugin right ? Have you had to wait 1.7 seconds to receieve again ? No you can receive as fast as the remote will send. It'll just automatically resync the stream after 1.7seconds of no data. That is all.

Edit:
I meant to add. The streamzap remote I did a plugin for. It had a similar protocol, but sometimes it would either omit a value (due to bad signal maybe) or a value would come out as zero for space/pulse length. This would entirely break the decoder from then on because the decoder lost the PULSE/SPACE order, since the data stream didn't have a bit indiciting whether the value was a pulse or a space. It too had an 0xFF terminator, so you could resync and recover from a bad signal and fix the pulse/space order.

Re: Why the 0xFFFF?

Reply #14 –
Then we get into the issue of how frequently you get missed bytes, which in my experience is low and trivial (this is IR), but no need to go there, the issue is if you manage your buffers, you don't need to add extraneous hardware inactivity data to the byte stream of IR signal data, that's my point.