Structure packing

[Dean Roddey]

The API header should probably set explicit packing on the info structure. If some compilers pack differently, or the user accidently leaks a packing pragma out of another file such that it affects your header, they could get some wierd effects. But, just in generally, it's usually not a good thing to depend on default packing, since it can be different on different platforms and different compilers.

[Guest]

Oh, and you should probably explicitly state the encoding of text strings passed in and out. I assume that they are strictly ASCII, but could be UTF8 or Latin1 or some other such single byte encoding. My system is all Unicode oriented, so I have to transcode in and out of such calls, and want to pick the right transcoder.

[Guest]

In some cases, you are using explicitly sized types, and in others you are using types that float with implementation. Is this what you intended? Wouldn't it be better to just use explicitly sized types all the time, to reduce the possible complexity?

[jrhees]

Dean,

You're right on all accounts. The API definition was based on some legacy code I had written many years ago for another OS. Hence, the type definitions are pretty loose. As far as data types, assume (until its corrected):

DWORD = UINT32

-Jon

[Dean Roddey]

Personally, I'd remove all Windows specific types, and provide a small number of typedefs at the top of the file that defines the types you need, which people can change if they need to. I don't use any of the Windows headers. They are hidden away down in the basement of my CIDLib C++ Frameworks, so I had to make a new version of your header that doesn't use things like BOOL and INT32 and such. Given the wide usage your product would eventually have, if you just provided the simple typedefs at the top, it could be fairly easily platform portable. Also provide them for WINAPI and CALLBACK and those things as well, so that folks whose compilers or platforms don't support them can define them away.


Since most of us will likely use it from C++, you should use the standard wrappers that indicate the C linkage:

#ifdef __cplusplus
extern "C" {
#endif

blah blah blah

#ifdef __cplusplus
}
#endif



And you should make use of whatever 'const' usage C supports these days, to make the API more self describing, though you might not be able to use as much const'ness as C++ would allow.


It probably would have been better to let people pass in how big their receieve buffer is, unless there is an absolute max size you will ever return, in which case you could provdie that as a constant. That way you can return an error and the required size. Otherwise, the danger of buffer overwrites is too dangerous to risk.

[Dean Roddey]

BTW, I got the bulk of my CQC driver done for the USB-UIRT yesterday. I've factored my IR architecture so much that it's fairly easy to implement a new blaster or receiver, and your API is pretty straightforward, so it's been fairly easy. I'll probalby finish and test it over the next couple days, so it should come out in the first public 0.9 CQC beta drop.

Oh, and I also sold a couple of UIRTs for you already . By the time those customers get theirs delivered, I'll have the driver out there for them to use.

And my little Pronto explorer program seems to be working fine. I tested some of the generated UIRT import files last night and the commands were going through fine. That gives me confidence that the other formats I'm generating (GlobalCache and RedRat3) will work when the time comes, and that I can go ahead and start generating my IR library files.

[Dean Roddey]

Ok, so I'm doing the receiever part now, and I'm a little confused. I always get at least two callbacks on any button press, and sometimes three. On the two, they are the same value, and on the threes, the first and last are the same and the middle one is slightly different.

This is going to be somewhat problematic, since I cannot tell whether they resulted from one button press or are legitimately multiple key presses, but I have to invoke actions based on the events I see. So I'm not sure how I'm supposed to know when I should actually invoke two events or when one of the events is bogus. Given that invoked events can be pretty serious stuff in an automation system like mine, I cannot ignore events and I cannot afford to invoke them multiple times.

Is this guy supposed to be giving me multiple events? Do I have to depend on some kind of 'minimum time between unique events' type timer to suppress the extra events after the first one?

[Dean Roddey]

Are the month and day fields zero or one based? I have to get it right because I have to format them, and my formatter will throw an exception if it's not a legal date. So I don't want it to start freaking out in December or some such thing.

[Dean Roddey]

Another thing that needs to be documented in detail is how receiving and transmitting and learning all interact. Can I get a receive call when I'm learning? Will it cause an error if some event I'm processing asynchronously in response to a receieved IR event, then turns around an invokes an IR command while I'm in the process of learning in another thread?

I can prevent any of these things from happening at the same time, but for the sake of throughput and responsiveness, I'd prefer to let those things that can overlap do so. And it affects whether I go through the trouble of making incoming client requests for learing (my system is network distributed), wait for any queued events to complete before I let them do a learning operation.

[jrhees]

Dean,

All date fields for SW/firmware revisions are 1-based. I.e., 0x1 for month is January.

The API will prevent you from transmitting, for example, while learning. The only state which prevents 'normal' operation is Learning, since this is a persistent state until Learning is completed or aborted.

As far as multiple events, you may want to try multiple remotes to get a feel for how this works. Unfortunately, different remotes have different ways of treating this -- some remotes send out a single IR burst when the button is pressed. Others send repeated codes as long as the button is held. And further others will send a unique code when the button is pressed, and another when the button is released. Since the USB-UIRT is a universal receiver and has no a-priori knowledge of the protocol used at any given time, it does its best to send relevant events to the host. The best way to deal with this is similar to how Girder users deal with it -- simply 'trigger' on one of the events sent by a button and not the rest. This solves the issue with multiple different codes coming from a single button-press. For multiple same codes originating as long as the button is held, you can have something similar to Girder's anti-repeat time.

-Jon

[Guest]

The best way to deal with this is similar to how Girder users deal with it -- simply 'trigger' on one of the events sent by a button and not the rest.

How can they prove that a set of events came from one button trigger? The only way I can think of is by requiring a minimum time, which still doesn't prove it, since a remote could be programmed to send multiple different buttons and the speed would be such that it might be within a minimum inter-event time.

The reason I don't already have such functionality in place is that the IRMan doesn't seem to operate this way. I only sends me one event, if I remember correctly, for each button press, so it must be doing some sort of supression itself. I always figured that they did it by only sending one event per continuous transmission from the remote. I.e. they wouldn't trigger until the carrier signal goes away or some such thing.

I just assumed that others would work this way and never had dealt with this issue.
[/quote]

[Dean Roddey]

I guess I have to register before I can edit my posts? I kind of screwed up that last one but cannot see any way to edit it. Anyway, that was from me, not Mr. Guest.

[jrhees]

No, you'll find that even with an IrMan or other receiver that you'll see multiple events from many remotes. Some remotes also vary from button to button. For eample, an AV receiver remote may send out a single IR code for all buttons *except* volume up/down.

The way you determine if the event is from a distinct button from the last event is simply by its contents. For example, if a Girder user assigns a particular event to happen when the user presses the '1' button, the user will associate one of the codes received by the USB-UIRT when he/she presses the '1' button. Even if a couple different codes are emitted, as long as the codes are unique, one of these codes will trigger the event. Then, assigning another event to the '2' button works the same way.

As far as determining when a button is being held down -- I have yet to see a remote that sends repeated codes that doesn't send the same code repeatedly during the duration of the button being held down.

-Jon

[Guest]

The way you determine if the event is from a distinct button from the last event is simply by its contents. For example, if a Girder user assigns a particular event to happen when the user presses the '1' button, the user will associate one of the codes received by the USB-UIRT when he/she presses the '1' button. Even if a couple different codes are emitted, as long as the codes are unique, one of these codes will trigger the event. Then, assigning another event to the '2' button works the same way.

Sure, but the same button is often sending the same code more than once, which is the issue here. The only way to avoid that triggering multiple events is to have some minimum time interval and ignore any events that come in within say 250ms to 500ms from the last one you triggered on. Otherwise, you'll trigger the same event multile times, which is a very bad thing when it kicks off a whole complex sequence of events.

I've now implemented that type of minimum time throttling, but it makes me a bit paranoid. The thing is, for my system, which is network distributed, it's not necessarily just a guy running a couple of HT components, who can see if the event did what it was supposed to do by just looking. In my system, such an event can kick off things all over the network, so I have to be very, very careful about this kind of thing, and it just worries me that there is not a more bullet proof means of insuring that one button invokes one event.

But, it's better to risk failing to cause an event if they press buttons too fast than to risk invoking the same event multiple times if they didn't mean to, so I'm using the minimum time thing, though even that will be a problem if they get fumble fingered and hold the button down too long.

[Dean Roddey]

Ok, I went back and checked the IRMan and, yes, I do get more than one event, always seems to be two, where the UIRT will do three for the same button from the same remote. But, anyway, I never noticed this happening on the IRMan before, and just never thought it would happen I guess. I added the same throttling scheme based on minimimum time. 250ms seems to be about right for both, but I may have to play with that a bit, or allow the user to configure it.