|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun Apr 27, 2014 3:11 am Post subject: |
|
|
probono wrote: | Congratulations Barf to this useful program. It is exciting to see readily available hardware (read: cheap hardware) such as Arduino supported. |
. Also expensive hardware is supported...
Quote: |
In IrScrutinizer 1.0.0 I found what might be a bug: Some codes seem not to be sent via the Arduino.
For example, these do NOT send anything via Arduino:
GlobalCache, telefunken, tv, 702, Power On/Off, Transmit selected
IRDB, Samsung, TV, Load, Power, Transmit selected
|
Try to turn on the "verbose" option. And using the latest release 1.0.1. The sending sketch of 1.0.0 is based on Shirriff's sender. I concentrate on getting the new version 1.1.0 finished instead.
Quote: |
Have you considered moving the project to github? You would probably increase the chances of getting bugreports and pull requests. |
Sooner or later I will do this, or something similar,
Edit (2014-06-28): Test version deleted. Use the current version instead.
Last edited by Barf on Sat Jun 28, 2014 5:13 am; edited 1 time in total |
|
Back to top |
|
|
probono
Joined: 12 Aug 2012 Posts: 48
|
Posted: Sun Apr 27, 2014 7:01 am Post subject: |
|
|
1.0.1 does not send this either, the verbose output does not show an error. But I guess I will just wait for 1.1.0 |
|
Back to top |
|
|
splink
Joined: 27 May 2014 Posts: 2
|
Posted: Tue May 27, 2014 5:44 am Post subject: Decoding Raw IR Signal via Command Line Interface |
|
|
Hi!
Awesome software first of all, thanks!
I was playing around with the irpmaster CLI on linux and am wondering if there's currently a way to analyze the raw form (into IRP form) from the CLI just like the CCF form is analyzed here, http://www.hifi-remote.com/forums/viewtopic.php?t=14252 .
cheers,
Matt |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Tue May 27, 2014 12:54 pm Post subject: |
|
|
Quote: | Awesome software first of all, thanks! |
4 sure:
Code: |
$ irpmaster --decodeir --analyze --ccf 0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 06A4 015B 0057 0016 0E6C
protocol = NEC1, device = 12, subdevice = 34, obc = 56
AnalyzeIR: {38.4k,573,msb}<1,-1|1,-3>(16,-8,A:32,1,^109m,(16,-4,1,^108m)+){A=0x30441ce3}
$ irpmaster --ccf --decodeir --analyze +9024 -4512 564 -564 564 -564 564 -1692 564 -1692 564 -564 564 -564 564 -564 564 -564 564 -564 564 -1692 564 -564 564 -564 564 -564 564 -1692 564 -564 564 -564 564 -564 564 -564 564 -564 564 -1692 564 -1692 564 -1692 564 -564 564 -564 564 -1692 564 -1692 564 -1692 564 -564 564 -564 564 -564 564 -1692 564 -1692 564 -44268
protocol = NEC, device = 12, subdevice = 34, obc = 56
AnalyzeIR: {38.0k,564,msb}<1,-1|1,-3>(16,-8,A:32,1,-44.3m){A=0x30441ce3}
|
|
|
Back to top |
|
|
splink
Joined: 27 May 2014 Posts: 2
|
Posted: Tue May 27, 2014 10:01 pm Post subject: Mutipart Messages |
|
|
Thanks for the quick reply. This was easy
One more question, the IrScrutinizer GUI also handles messages consisting of several parts (at least in the one case below which I've actually tried) when a newline is inserted between the parts. Is there a way to separate a message with multiple parts so that it's parsed accordingly from the CLI as well?
Here's the example of a my two part message,
Code: | irpmaster --ccf --decodeir --analyze +3458 -1756 +410 -464 +410 -1346 +414 -464 +414 -464 +414 -462 +410 -466 +410 -468 +408 -468 +410 -464 +414 -464 +414 -464 +414 -464 +414 -458 +416 -1344 +410 -466 +410 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -460 +414 -1346 +410 -1340 +416 -1344 +410 -468 +410 -460 +414 -1346 +414 -464 +414 -464 +414 -464 +414 -462 +412 -464 +410 -468 +410 -468 +410 -468 +410 -468 +410 -464 +414 -464 +414 -462 +414 -462 +408 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -462 +414 -462 +416 -462 +414 -464 +414 -460 +414 -464 +414 -464 +414 -460 +414 -1342 +410 -1346 +414 -462 +414 -462 +414 -462 +414 -462 +414 -462 +416 -10192 +3458 -1762 +414 -458 +414 -1344 +416 -462 +414 -460 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -462 +414 -462 +416 -462 +414 -460 +414 -1346 +410 -468 +410 -468 +410 -468 +410 -466 +410 -466 +408 -468 +408 -460 +414 -1342 +414 -1342 +410 -1348 +410 -462 +416 -458 +414 -1346 +414 -464 +414 -464 +414 -464 +414 -464 +414 -462 +414 -462 +414 -462 +416 -462 +410 -468 +410 -468 +410 -468 +410 -468 +410 -460 +414 -462 +414 -462 +416 -458 +414 -1346 +414 -464 +414 -464 +414 -464 +414 -458 +414 -458 +414 -1346 +414 -464 +414 -460 +414 -1340 +408 -1350 +410 -468 +410 -468 +410 -468 +410 -468 +410 -468 +410 -466 +408 -468 +410 -468 +410 -464 +410 -1346 +410 -1344 +414 -1340 +414 -1342 +410 -1342 +414 -1340 +414 -1344 +414 -462 +410 -464 +414 -1342 +414 -460 +414 -1340 +414 -1344 +414 -462 +416 -462 +414 -464 +414 -460 +414 -464 +414 -464 +414 -464 +414 -462 +414 -462 +414 -462 +416 -462 +416 -462 +414 -460 +414 -1342 +410 -1344 +414 -1344 +414 -462 +414 -462 +414 -462 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -458 +414 -1340 +410 -1342 +414 -1346 +414 -464 +414 -464 +414 -464 +414 -462 +414 -458 +414 -1346 +414 -464 +414 -460 +414 -464 +414 -464 +414 -464 +414 -462 +414 -462 +414 -462 +414 -462 +414 -464 +414 -464 +414 -1342 +414 -1346 +410 -468 +410 -468 +410 -466 +410 -462 +410 -1346 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -464 +414 -462 +414 -462 +416 -462 +414 -464 +414 -460 +410 -1350 +410 -468 +410 -468 +410 -468 +410 -462 +416 -462 +414 -464 +414 -460 +414 -1346 +414 -460 +414 -1340 +414 -458 +414 -1342 +414 -130656
AnalyzeIR: Undetermined
|
The GUI does find the IRP form,
Code: | {38.0k,413,msb}<1,-1|1,-3>(8,-4,A:64,1,-9586u,(8,-4,B:152,1,-122.9m)+){A=0x4004072000000060,B=0x4004072000104c01fcb0007007040061001015}
|
when the input is given on two lines as
Code: | +3458 -1759 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +416 -10192
+3458 -1759 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -1344 +413 -1344 +413 -1344 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -463 +413 -1344 +413 -463 +413 -1344 +413 -463 +413 -1344 +414 -130656
|
|
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Wed May 28, 2014 2:23 pm Post subject: |
|
|
You have already discovered that in the GUI "scrutinize signal" window a signal consisting of several sequences (intro, repeat, ending) can be entered. So, you want to do it from the command line, in IrpMaster?
One way is to use the CCF-Form, which contains an intro sequence and a repeat sequence. There is presently no way to enter a multi-sequence signal, neither is there to give the modulation frequency in a raw signal.
It is always difficult to press a lot of functionality into a command line interface, in particular if it involves very long arguments. And fewer and fewer people can use command line programs -- you might like to check out some of the early postings in the IrpMaster thread.
There is the GUI, and there is also the possibility to use the Java API, i.e. writing your own programs using IrpMaster as library, for special use case.
Anyhow, I could not resist the temptation to see if I could extend the command line interface, with success! It is now possible to do what you want using the syntax
Code: |
$ irpmaster --ccf --analyze "intro-sequence" "repeat-sequence"
|
or
Code: |
$ irpmaster --ccf --analyze "intro-sequence" "repeat-sequence" "ending-sequence"
|
wait for next release, planned early next month. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Fri Jun 20, 2014 2:50 pm Post subject: |
|
|
So, finally, version 1.1.0. has been released. Download links as before. See the first posting for release notes.
It contains all the bug fixes I have promised. I am sorry that it took so long to publish them...
This version contains a lot of minor enhancements and bug fixes, none really important, but taken together, an update is strongly recommended.
Keep scrutinizing!! |
|
Back to top |
|
|
hanryz
Joined: 21 Jun 2014 Posts: 8 Location: Netherlands |
Posted: Wed Jun 25, 2014 3:44 pm Post subject: |
|
|
Barf wrote: | So, finally, version 1.1.0. has been released. Download links as before. See the first posting for release notes.
It contains all the bug fixes I have promised. I am sorry that it took so long to publish them...
This version contains a lot of minor enhancements and bug fixes, none really important, but taken together, an update is strongly recommended.
Keep scrutinizing!! |
Dear Barf, I am trying to scrutinize using your great tool IrScrutinizer v1.1.0 (latest) and IR Toy v2 hardware. The IR TOY is running on v222 firmware (also latest). My PC is running a Win7 64bit OS and Java 8 (latest). The IR Toy is connected on COM3 with 9600 or 115200 kBit/s (does not matter).
However, I have a very strange behaviour both when sending and when capturing.
When capturing, the software reports "internal error" but only after 3rd received and decoded command (NEC protocol), the first three commands are received and decoded fine. Once the "internal error" is reported, no more decoding is possible. I have to restart the Tool in order to continue my work.
When transmitting with the application started for the first time upon Windows start, it is even more bizzar. I am able to send approx the same three times a code (I see the LED on the IR TOY going On and Off for a very short period), and it is sent properly (the target reacts).
After the three times, I see the LED on the IR Toy lit for unusually long time, and the software keeps hanging for a while. The code is not sent properly. I have to restart the Tool and reconnect the IR Toy. Then, again, I am able to sent the code once, then the whole software is hanging again.
I don't think that this is a Hardware related because I can run the test apps coming with the IR Toy without problems.
Would you have an Idea please, what could be wrong? Thank you in advance!!! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Thu Jun 26, 2014 3:03 pm Post subject: |
|
|
Thanx for your posting. Summarizing in my own words: everything works, sending as well as caputuring. It is just that the device + IrScrutinizer hangs after some time. This happens both on sending and on capturing, and seems to be happen independently of communication speed.
Actually.I was able to reproduce the problem in Linux. So there is definitely a problem lying aroung, and it is not the windows usb drivers.
The bad news is there is no real obvious way to fix it. It is not really good for IrScrutinizer to "hang", possibly the sending/capturing should (always) take place in separate threads, with the possibilities to interrupt/kill/reset?
Also, I am a bit disappointed by the 'toy. As I just added to the documentation, a capture has to end with a time out of 1.4 seconds, non-configurable. Clearly suboptimal for bulk capturing. The forums by dangerous prototypes seems to more-or-less full of hanging-problems. Also, a beta test of a new firmware (2.3) was announced 2 years ago, but has still not reached "official".
So, I do not promise a fix, in particular, not soon. I may find a way around it, or even to fix ot. Be sure to follow this forum, or my home page.
Or do you have any other suggestions?
Sorry. |
|
Back to top |
|
|
hanryz
Joined: 21 Jun 2014 Posts: 8 Location: Netherlands |
Posted: Fri Jun 27, 2014 1:52 am Post subject: |
|
|
Hi Barf, thanks a lot for your reply.
I'm still busy with the problem. In the meanwhile I read on the Toy's forum that there are issues with response time on the toy. In particular, it was reported that the toy (hardware) may not react within the predetermined time. This in turn, as far as I understand (please confirm) may lead to "hangs" in the IrScrutinizer. The very bad thing about this all is that the problem is not solved by reconnection the hardware to PC and restarting the software. If the port is not closed properly and because the software is running on JVM, the JVM also hangs on the ports. This creates mess in the Win OS (I get the JVM error when trying to restart the software).
Nevertheless. I'm going to try my arduino nano with IR-Sensor and IR-diode connected to it and your scrutinize_receiver and scrutinize_sender sketches located in the "Arduino" folder of your software package. I hope they are designed to work and are supported by your IrScrutinizer software (please confirm).
Summing up:
1) It may yet be mostly hardware-related problem with the hangs when using IrToy.
2) I will try arduino with the sketches (please see above and confirm).
3) Still, the IrScrutinizer may do better by a more sofisticated handling of the response timeouts caused by the toy hardware.
If you would find time to response to above points, I would be very thankful.
Thank you in advance. |
|
Back to top |
|
|
cauer29
Joined: 03 Feb 2010 Posts: 236
|
Posted: Fri Jun 27, 2014 9:19 am Post subject: |
|
|
Barf wrote: | Thanx for your posting. Summarizing in my own words: everything works, sending as well as caputuring. It is just that the device + IrScrutinizer hangs after some time. This happens both on sending and on capturing, and seems to be happen independently of communication speed.
Actually.I was able to reproduce the problem in Linux. So there is definitely a problem lying aroung, and it is not the windows usb drivers.
The bad news is there is no real obvious way to fix it. It is not really good for IrScrutinizer to "hang", possibly the sending/capturing should (always) take place in separate threads, with the possibilities to interrupt/kill/reset?
Also, I am a bit disappointed by the 'toy. As I just added to the documentation, a capture has to end with a time out of 1.4 seconds, non-configurable. Clearly suboptimal for bulk capturing. The forums by dangerous prototypes seems to more-or-less full of hanging-problems. Also, a beta test of a new firmware (2.3) was announced 2 years ago, but has still not reached "official".
So, I do not promise a fix, in particular, not soon. I may find a way around it, or even to fix ot. Be sure to follow this forum, or my home page.
Or do you have any other suggestions?
Sorry. |
Technically, the IR Toy can be re-flashed with Widget compatible firmware. I've done that and it works extremely well. Obviously, you lose the transmit capability. Also, apparently there has been some friction between the JP1 guys here and the Dangerous Proto guys, as they're claiming that they were actively discouraged from proliferating Widget FW for the IR Toy. I don't understand what the beef was. Given the issues with non-availability of Widgets in the recent past, you'd think that an alternative hardware platform would be welcomed.
There is actually a Widget mode built-in to the existing IR Toy FW, but it is broken. That is, when first opening the port, you send a certain character and it switches to Widget mode. I had modified the source for IRScope to do that, but ran into the fact that the integrated Widget mode was broken. I believe that somebody or other on the Dangerous Proto forums, did identify what that issue was, but there was nobody to put that fix into the release FW.
I suppose it would be pretty cool if somebody got that working, as then we could use Widget mode for captures and IR Toy mode for sending, hang issues notwithstanding. As it is, I keep my IR Toy flashed with the "Widget only" FW most of the time and that works perfectly. |
|
Back to top |
|
|
hanryz
Joined: 21 Jun 2014 Posts: 8 Location: Netherlands |
Posted: Fri Jun 27, 2014 9:55 am Post subject: |
|
|
cauer29 wrote: | Barf wrote: | Thanx for your posting. Summarizing in my own words: everything works, sending as well as caputuring. It is just that the device + IrScrutinizer hangs after some time. This happens both on sending and on capturing, and seems to be happen independently of communication speed.
Actually.I was able to reproduce the problem in Linux. So there is definitely a problem lying aroung, and it is not the windows usb drivers.
The bad news is there is no real obvious way to fix it. It is not really good for IrScrutinizer to "hang", possibly the sending/capturing should (always) take place in separate threads, with the possibilities to interrupt/kill/reset?
Also, I am a bit disappointed by the 'toy. As I just added to the documentation, a capture has to end with a time out of 1.4 seconds, non-configurable. Clearly suboptimal for bulk capturing. The forums by dangerous prototypes seems to more-or-less full of hanging-problems. Also, a beta test of a new firmware (2.3) was announced 2 years ago, but has still not reached "official".
So, I do not promise a fix, in particular, not soon. I may find a way around it, or even to fix ot. Be sure to follow this forum, or my home page.
Or do you have any other suggestions?
Sorry. |
Technically, the IR Toy can be re-flashed with Widget compatible firmware. I've done that and it works extremely well. Obviously, you lose the transmit capability. Also, apparently there has been some friction between the JP1 guys here and the Dangerous Proto guys, as they're claiming that they were actively discouraged from proliferating Widget FW for the IR Toy. I don't understand what the beef was. Given the issues with non-availability of Widgets in the recent past, you'd think that an alternative hardware platform would be welcomed.
There is actually a Widget mode built-in to the existing IR Toy FW, but it is broken. That is, when first opening the port, you send a certain character and it switches to Widget mode. I had modified the source for IRScope to do that, but ran into the fact that the integrated Widget mode was broken. I believe that somebody or other on the Dangerous Proto forums, did identify what that issue was, but there was nobody to put that fix into the release FW.
I suppose it would be pretty cool if somebody got that working, as then we could use Widget mode for captures and IR Toy mode for sending, hang issues notwithstanding. As it is, I keep my IR Toy flashed with the "Widget only" FW most of the time and that works perfectly. |
Hi cauer29, are you using the IrScrutinizer for transmission (no issues?) or a different soft (which?) with the IR Toy?
Thank you! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Fri Jun 27, 2014 11:41 am Post subject: |
|
|
hanryz wrote: | ... it was reported that the toy (hardware) may not react within the predetermined time. This in turn, as far as I understand (please confirm) may lead to "hangs" in the IrScrutinizer.
|
My gutfeeling is different, that the 'toy does not respond when it is supposed to do, and IrScrutinizer wait forever. But I better spend the time with the debugger than with guesses .
Quote: |
The very bad thing about this all is that the problem is not solved by reconnection the hardware to PC and restarting the software. If the port is not closed properly and because the software is running on JVM, the JVM also hangs on the ports. This creates mess in the Win OS (I get the JVM error when trying to restart the software).
|
"Good news" is that at least my Linux machine does not behave like that...
Quote: |
Nevertheless. I'm going to try my arduino nano with IR-Sensor and IR-diode connected to it and your scrutinize_receiver and scrutinize_sender sketches located in the "Arduino" folder of your software package. I hope they are designed to work and are supported by your IrScrutinizer software (please confirm).
|
Please update to the current version and use the sketch therein. It is a huge difference! See the Arduino thread, in particular the firmware from MikeT.
I do have some ideas on how to go after the problem.
cauer29 wrote: | Technically, the IR Toy can be re-flashed with Widget compatible firmware. I've done that and it works extremely well. Obviously, you lose the transmit capability. Also, apparently there has been some friction between the JP1 guys here and the Dangerous Proto guys, as they're claiming that they were actively discouraged from proliferating Widget FW for the IR Toy. I don't understand what the beef was. Given the issues with non-availability of Widgets in the recent past, you'd think that an alternative hardware platform would be welcomed. |
Unfortunately, the IrToy is not very widely available, or easy to get. I ordered mine here (which was easy, cheap, and fast), but they are out of it since more than a year. Also, as I wrote in my previous post., a beta firmware having had its second birthday without being released, is not a good sign.
As far as I am aware of, and Arduino (Nano or micro), preferable "Pro" (without the pins, just holes where compents can be soldered), with a sensor like e.g. OPL-551, would probably make a good IrWidget. Only someone has to write the firmware, which should be a moderate effort for the right person.
Having said that, I consider MikeT's solution for the Arduino (which is contained in IrScrutinizer 1.1.0, danke Dir Michael!!) as vastly superior to the IrWidget idea, much more accurate and reproducible captures. |
|
Back to top |
|
|
StephenR0
Joined: 12 Feb 2007 Posts: 109 Location: Iowa, US |
Posted: Fri Jun 27, 2014 12:00 pm Post subject: |
|
|
Barf wrote: |
As far as I am aware of, and Arduino (Nano or micro), preferable "Pro" (without the pins, just holes where compents can be soldered), with a sensor like e.g. OPL-551, would probably make a good IrWidget. Only someone has to write the firmware, which should be a moderate effort for the right person.
|
Ok, I'm confused. Isn't that what the sketch that you included is for? If not, what hardware are we supposed to use with that sketch? |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Fri Jun 27, 2014 12:23 pm Post subject: |
|
|
You should use the sketch included with the software.It is not compatible between versions. It is that simple.
In the passage quoted, I consider a new project writing firmware for the Arduino that behaves like Kevin Timmerman's IrWidget (counting transitions within each 100-ns interval). This is a project for the future, but, as I write above, not anything that I consider will produce better result than the present MikeT-based firmware. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|