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

Re: Why the 0xFFFF?

Reply #15 –
Why is this such a problem for you ? I really don't get it. What are you stuck on?

Re: Why the 0xFFFF?

Reply #16 –
I'm saying the 0xFFFF inactivity marker is not mandatory and you (anyone) can do without it.

It kind of breaks the byte streams to tell me something I don't really need, and a good protocol should shield you from that kind of detail (MCU detected X seconds of inactivity and is reseting (late info) != MCU encountered a logic problem and needs to reset, so don't waste time with the data you got (on time & pertinent).

Quote
just not send the 0xffff? That's dooable, and can be added as an option

Depending on your position, is a bit like do you like the glass half-full or half-empty.

Re: Why the 0xFFFF?

Reply #17 –
I don't think anyone sees your point, even though you describe individual pieces of the overall picture that each make sense on their own.  On the one hand, you complain that 1.7 seconds is too long to be useful, but on the other hand you complain that this 0xFFFF is a waste of bandwidth.  How can the 0xFFFF be a problem if it only happens when nothing else is going on?

I will repeat: All streaming protocol standards involve some kind of periodic sync.  I can't see how you can complain about the IRToy sampling mode protocol without complaining that MP3 or ATSC should also remove their sync bits (14-bit or more).

The IRToy is not even fool-proof, but at least the 0xFFFF is better than nothing.  If the 0xFFFF were deleted to "prevent waste" then a single lost byte would break the decoder forever, until the user manually reset both the IRToy and decoder software.  That would be a bad user experience.

Re: Why the 0xFFFF?

Reply #18 –
Quote
I don't think anyone sees your point

And yet my code works without the 0xFFFF, so what's your point? My point is it is not necessary, that's all, from my own experience, not an idea, but a fact, if your code or someone else's needs it, that's another fact (still not required, though).

Quote
you describe individual pieces of the overall picture that each make sense on their own

I talk about one thing, the 0xFFFF is not necessary.

Quote
complain about the IRToy sampling mode protocol

The protocol is nice, except the sending of the 0xFFFF, but I've said this before.

Quote
you complain that 1.7 seconds is too long to be useful, but on the other hand you complain that this 0xFFFF is a waste of bandwidth

I've said before that the duration of 1.7s is not an issue, it could be any number and is fine. I'm not talking about waste of bandwidth, but mixing of hardware inactivity info with IR signal data. Of course if you use it, you'll want it, which is the issue here, you don't use it you don't want it.

Quote
All streaming protocol standards involve some kind of periodic sync.  I can't see how you can complain about the IRToy sampling mode protocol without complaining that MP3 or ATSC should also remove their sync bits (14-bit or more).

You lost me. I'm talking about the IR Toy with a simple byte-oriented serial data that works well with managed buffers.

Quote
The IRToy is not even fool-proof, but at least the 0xFFFF is better than nothing.  If the 0xFFFF were deleted to "prevent waste" then a single lost byte would break the decoder forever, until the user manually reset both the IRToy and decoder software.  That would be a bad user experience.

And yet I don't see any of this Doomsday scenario with my application, which doesn't sync to this 0xFFFF, I suspected as much when I started, but better to test with working code.

The "nothing" alternative works fine.

A single lost byte will not brake my decoder, the next signal will decode fine, but can't talk for other code approaches where it could mess things until the 0xFFFF comes along, which is why it doesn't make sense to me to depend on syncing to this 0xFFFF, not that I ever saw a need to do that in the first place.

Maybe you are mixing the sending of / syncing to the 0xFFFF with the IR Toy reset after X seconds of inactivity. I'm only talking about the sending of 0xFFFF, not the IR Toy reset, so I don't see were a single byte will break the IR Toy forever.

Re: Why the 0xFFFF?

Reply #19 –
Quote
don't you have an idea about the IR signal protocol and the data you expect?

If you're talking about the IR Toy, then no, it has no idea. It just tries to time things as well as possible.

If you're talking about your software, then I might be seeing what you're getting at.

Is this the idea:
1. Program gets data
2. program sees the expected signal and decodes it
3. program is ready for another signal starting with a pulse

In that case you know the signal, know when it is done, and can reset your state machine to be ready for more data. Is that kinda what you're saying?

In this scenario I would add 3b) if data== 0xffff while waiting for the next signal, flush any stored samples and stay in state 3.

Quote
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.
In .NET it probably works like this, but in C or another lower-level language it could be very helpful.

Again, I'm happy to add it as an option or make it adjustable. I've already spent more time defending the choice than it will take to implement an alternative setting for you in the next firmware. I'm sorry, for backwards compatibility reasons I won't remove it totally at this point, and I can't really discuss it more.
Got a question? Please ask in the forum for the fastest answers.

Re: Why the 0xFFFF?

Reply #20 –
Quote
Again, I'm happy to add it as an option or make it adjustable. I've already spent more time defending the choice than it will take to implement an alternative setting for you in the next firmware. I'm sorry, for backwards compatibility reasons I won't remove it totally at this point, and I can't really discuss it more.

Thanks.

Re: Why the 0xFFFF?

Reply #21 –
I went through the whole post and I feel what liyin is telling will work out if the IR protocol is well known (like RC5) and IRToy can decode. Then may be there is no need for 0xFFF

But if the protocol is not known, then it is must have some marker so that the receiving side starts processing it assuming that IRToy capture is over.

This I am stating from my experience - I did not have any RC5 remote and I could not get any output frm IRToy. But when I got the sampling mode and later the eventghost pluggin I could use any remote because IRToy does not decode anything in sampling mode and the receiving end program waits for the marks to process it. As long as I press the same key, eventghose recognizes it and I could assign this received number to start anything.