Skip to main content
Topic: New Mac OS X client application (Read 3405 times) previous topic - next topic

New Mac OS X client application

I have been working with the IRIO mode of the USB IR Toy, and have developed a Mac application which displays waveforms, detects IR formats, and can even decode IR messages.  I made an alpha release earlier, but it was almost useless. This new release is a beta.

http://www.sounds.wa.com/software/IRToy-beta.dmg

There is a ReadMe.rtf which explains the basics.

Re: New Mac OS X client application

Reply #1
Sounds interesting, unfortunately, I'm not a Mac user.   Can you share any details?   Is it written in Objective-C using the Mac libraries?   

I'm interested in any cross platform opportunities.

Also, please post some screen shots.

Thanks,
--Rob

 

Re: New Mac OS X client application

Reply #2
Great suggestion! Why didn't I think about screen shots?

I think there are pretty much no cross-platform opportunities here at all. Seems like the SUMP front end is already cross-platform, so my goal is to focus on a native OSX front end. Everything is Cocoa and ObjC. Even the IR protocol detection and decoding uses Objective C objects for building unending lists of bits patterns, sample times, and sorting them into histograms or other methods of detection. Unless you have an ObjC runtime for your platform, my code will be useless unless you can port.

For now, the program opens the standard Unix serial device file, but that does not allow smooth unplugging or replugging of the USB IR Toy after the program starts. Future versions past beta will use the OSX USB API to match the USB IR Toy device by VID/PID and allow dynamic association.

Re: New Mac OS X client application

Reply #3
Hi rsdio,

Any further progress with your app? I've downloaded the beta above, and had a play round.
Once you get it talking to your IRToy it seems to work as per the readme. Great!

If I can be bold and make some suggestions:
- provide a save button in the prefs to save the edited text string (my first mistake... the change didn't stick because I forgot to hit "enter")
- remove the unimplemented modes strings from the mode popup (Test and IRIO are the only 2 that work now, right?)
- provide the ability to capture the full HEX output somehow (put it in a edit field?)

The later would allow the contents to be copied/saved to a file, then permit diffs to see potential patterns, compare with (similar) published remote codes etc

My (initial) 2 cents worth :)

Regards,
- Grant.

Re: New Mac OS X client application

Reply #4
[quote author="grant"]Any further progress with your app?[/quote]Nope, I've been too busy designing hardware and firmware.  :-)  My poor IR Toy is being neglected on my workbench.

Quote
- provide a save button in the prefs to save the edited text string (my first mistake... the change didn't stick because I forgot to hit "enter")
The goal is to use the OSX API which allow direct access to USB devices, instead of the serial port device file.  Thus, Preferences will go away because the USB IR Toy can be detected by VID/PID directly.

For now, just hit enter like most Preferences require.

Quote
- remove the unimplemented modes strings from the mode popup (Test and IRIO are the only 2 that work now, right?)
All of the modes "work" because the command is sent when you select from the popup.  The catch is that there is no SUMP engine in my front end, because it would probably be redundant, so my program doesn't really do much besides sit there after entering SUMP mode.

Quote
- provide the ability to capture the full HEX output somehow (put it in a edit field?)

The later would allow the contents to be copied/saved to a file, then permit diffs to see potential patterns, compare with (similar) published remote codes etc
You can't really diff the USB IR Toy hex because it's actually a bit stream.  Even the exact same bit stream can be represented in eight different byte streams, so diff would give a false failure.  With asynchronous sampling, even the bit stream can vary for the same input due to slight timing variations.  The only real way to find patterns and compare to published remote codes is to analyze the bit stream in a mode that isn't simply byte-oriented.

Besides, I think you can still select the hex and use Copy and Paste to save in TextEdit.app

Re: New Mac OS X client application

Reply #5
[quote author="rsdio"]
You can't really diff the USB IR Toy hex because it's actually a bit stream.  Even the exact same bit stream can be represented in eight different byte streams, so diff would give a false failure.
[/quote]

Ouch.... that's a bummer. Is that because the "start" bit can appear anywhere in the first byte due to timing/sampling differences?

[quote author="rsdio"]
besides, I think you can still select the hex and use Copy and Paste to save in TextEdit.app
[/quote]

Umm.... not when I tried, hence the 'feature' request.
Can't re-test right at the moment. Is there some special trick that I missed?

Re: New Mac OS X client application

Reply #6
[quote author="grant"]
[quote author="rsdio"]
You can't really diff the USB IR Toy hex because it's actually a bit stream.  Even the exact same bit stream can be represented in eight different byte streams, so diff would give a false failure.
[/quote]Ouch.... that's a bummer. Is that because the "start" bit can appear anywhere in the first byte due to timing/sampling differences?[/quote]You have to think more in analog terms.  What the remote considers a "bit" is different than what the USB IR Toy reports as a bit, and the relationship changes according to the sample rate.  Typically the sample rate is high enough that one remote "bit" becomes multiple bits in the byte stream.  Even if you precisely locked the sample rate, the asynchronous nature of the sampling means that your pulse width would vary by one or more bits each time you repeat.

The "start" bit pulse is also a different width for each IR protocol and, since the USB IR Toy firmware does not synchronize its sampling clock to the incoming data, there are a couple of reasons why you will not always see the same bits every time.  Actually, it does synchronize to the first rising edge, but there is no attempt to automatically align the remaining samples to the external clock frequency of the remote.

You're probably thinking in terms of RS-232 or UART hardware which works because the baud rate is set on both ends to match, and then oversampling clocks are used align the decoded data to the asynchronous clock.  There's actually quite a bit of technology in play which makes asynchronous serial devices work for you while hiding all of these details.  With a serial chip, the oversampled data is reduced and mostly discarded so that you only see the recovered data, but with the USB IR Toy you have to do that yourself.  Such things work only when both ends agree on a single protocol at a time.  There are no serial chips which decode IR remote protocols, at least not all of them.

The USB IR Toy is more of a logic analyzer that is not specific to any single protocol.  It does not have the equivalent of baud rate matching unless you manually set the sample rate - a feature which I hope to add to my front end, but which is already possible with the raw USB IR Toy protocol.

Quote
[quote author="rsdio"]
besides, I think you can still select the hex and use Copy and Paste to save in TextEdit.app

Umm.... not when I tried, hence the 'feature' request.
Can't re-test right at the moment. Is there some special trick that I missed?
[/quote]You are right, clicking on the hex just moves the window.  I probably won't change this since it's useless to save the data anyway.

In some ways, my Mac front end is a distraction.  It's only partially implemented, which shields you from discovering some of the lower level details without providing access to change them.  Hopefully the OSX app is useful for basic diagnostics, and to view waveforms.  Beyond that, you might want to try dealing more directly with the USB IR Toy protocol, which is more complete (and evolving).

Re: New Mac OS X client application

Reply #7
Yeah my toy arrived! - Now what?

The aim, to replace (no longer working) universal remote with my mac mini. (running snow leopard)
So I got your app and awesome I can see it working; displaying the signals it receives.

how do / can i send a signals?

I would love to write a script (perl or applescript) which would result in sending (one or multiple) signals turning on my receiver and setting the TV input or whatever, that's the easy bit I believe, but i have no clue about hardware.   Any suggestion on how to get started on this would be very much appreciated.