Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - rct

31
USB Infrared Toy / Re: Prescaler setup in sampling mode
[quote author="ian"]
I thought SUMP protocol analyzers were written in Pyton, but I guess that is sigrok. I'm not sure how to do it in SUMP.
[/quote]

Yes, protocol decoders in python is a sigrok platform goal.   IIRC, correctly Sigrok had consumer IR protocol decoders on their to do list.   AFAIK, the Java Sump clients aren't scriptable, so you'd have to implement the decoder in java.   I believe someone ported decodeIR to java at some point, but it becomes a maintenance issue.  The decodeIR code gets periodically updated to support new consumer IR protocols as they are documented in the jp1 forums.
32
USB Infrared Toy / Re: Prescaler setup in sampling mode
[quote author="ian"]
I'd actually like to convert your decoder scripts to python so they can be used with the logic sniffer client to decode captures. You said you had a problem connecting directly - it is pretty easy to save to the .sla format directly, it's a simple text format with an example in the rec&play app, and also another example somewhere here: http://code.google.com/p/dangerous-prot ... oy2ols.au3
[/quote]

Is there Python software for the OLS?  I didn't see any mentioned on the wiki.   What sort of python ntegration/tools did you have in mind?    Does the Alternative logic sniffer client work with the SUMP mode of the IRToy?  I used the original sump client when I first got the IR Toy, though I had to struggle a bit to get RXTX working correctly under linux

Regarding File Formsts: I think the current IRToy .bin files are a bit of a dead-end since they don't contain any descriptive information.   My bias is for simple text based files.   While, I think the SLA files are good for looking at timing, but don't contain other info you would want to use for IR code storage like carrier, device, function name, etc.    I think it would be better to work towards using LIRC files where possible.

Regarding analysis of Captured IR Signals:

Right now, my preference for analyzing a capture would be to use IRScope under windows(*).    On my list is to look into the DecodeIR C++ code for use on other platforms.  I know someone make the changes to make it compile under linux  as a .so (port was to gcc really, as opposed to ms visual ...).   Given that it's available as a shared library, should be able to dynamically load it and use it from python, perl, etc. with one of the C wrappers.    I guess there might be times where you'd want to use the logic analyzer client for looking at the IR signal, but I think the consumer IR specific decoding that IRscope/decodeIR are already doing is probably a bit more relevant.

* Right now it's multiple steps to use IRscope with the IR Toy, irtoy record to .bin, irbin2ict.pl to get a .ict file to load into IRScope.   Though it would be straightforward to make of the ir toy recorders spit out .ict files.   I have python already the reads the IRwidget pulse count or timing mode and spits out .ict files.  It works under linux or windows.  The python serial module is designed to be cross platform.
* I built an IR widget on a breadboard using an ATTiny2313.  It captures pulse counts using either a QSE157 or an IR LED as a photodiode.  It also has a timing mode with a standard IR demodulator.  Kevin Timmerman did an AVR port of his pic code to hack the Adafruit MiniPOV3 into an IRwidget.   The AVR port supports either pulse count mode or timing mode.
* Decode IR list of protocols
33
USB Infrared Toy / Re: New firmware features (now v10)
Is it too late to stake out a cmd prefix byte that begins a multi-byte command that would be the same in every mode and would give you enough "name space" for a full, orthogonal set of getters an setters?
34
USB Infrared Toy / Re: New firmware features (now v10)
Minor Feature Request, full set of Getters.

Ideally there should be a GET for each of the SET commands, so that it is possible for software to query the state of the connected IR toy instead of having hard coded assumptions about the settings.   In particular, I'd like to be able to get the transmit modulation setting, sample period, and prescalar.   A nice to have would be the ability to query the clock speed that the firmware was compiled for to eliminate another assumption in software for any code that wants to do the math itself.  I think this should allow software to be more robust for future firmware & hardware changes.

A suggestion regarding the default transmit modulation frequency.  The wiki says the default is 36 khz.   I think a better default value would be 38 khz which is used by some other software like LIRC.   38 khz seems to be the most common and is the median for 36 khz to 40 khz.   Those using IR receivers that have their bandpass filter at 40 khz, will see better distance if they are using a 38 khz default instead of a 36 khz default.   I haven't tested this so please feel free to correct me if I'm wrong.

Thanks,
--Rob
35
USB Infrared Toy / Re: PANASONIC EUR648251 decoder perl script
[quote author="anton.todorov"]
Quote
G:ProjectsEclipse-3.6IRToy>ir_PAN.pl test000.bin
...
IR-PAN: 0x40(01000000) 0x04(00000100) 0x05(00000101) 0x43(01000011) 0x89(10001001) 0xcf(11001111)
IR-PAN: 0x40(01000000) 0x04(00000100) 0x05(00000101) 0x43(01000011) 0x89(10001001) 0xcf(11001111)

Only last 2 bytes are different so maybe the first four are device descriptors and/or addresses?
[/quote]

FWIW, This is what your capture looks like in IRscope.  See this thread where I posted a tiny script to convert .bin files into .ict files. 

The last four bytes are:  Device Code (0x05), Sub-device code (0x43), Function code (0x89), and an 8 bit checksum (0xCF == 0x05 ^ 0x43 ^ 0x89). 



IRScope / DecodeIR came up with a summary of the signal using the IRP notation form the JP1 forums of: 
Quote
{0.0k,430,msb}<1,-1|1,-3>(8,-4,A:48,1,-74.7m)+{A=$4004054389CF}; Alt leadout form: ^135m

DecodeIR.html says Panasonics IRP form is:
Quote
{37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+

While there is a bunch I don't understand this means:
* the carrier frequency is 37 Khz, 
* The Mark/space (on/off) times are multiples of 432 microseconds.
* A '0' is represented by 432 us on, followed by 432 us off.
* A '1' is 432 us on, 3 x 432 us = 1296 us off.
* The lead in is 8 x 432 == 3456 us on, and 1728 us of off time.
* The first two pieces of data should be 2 and 32 encoded in 8 bits each, which are the oem id.
* The device , sub-device, and function code are 8 bits each.
* The checksum is are those three bytes xor'd together, also encoded in 8 bits. 
* The lead out is 432 us on, 74736 us off.

MSB vs. LSB.
* For the Device & Subdevice code, IRScope is showing 160, 194.  it's interpreting the data as sent MSB first.  160 = 0b1010000, interpreted LSB first that's 5 (0x101), and 194 = 0b11000010, lsb first is 0x43.
* Your first two bytes 0x40 and 0x04Y that should be the oem interpreted LSB first gives 2, 32.
36
USB Infrared Toy / IR Toy .bin to IRScope .ict converter script.
Here's a quick & dirty perl script to convert captured USB IR Toy .bin files into .ict files that can be read into IRscope (a windows utility) for display and analysis.   IRscope is a windows only utility by Kevin Timmerman and Graham Dixon.  The source code is available.   I'll post info about IRScope on the Dangerous Prototype's wiki.

Here's the code and some screen shots.   One is a Sony CD Stop and the other set of Panasonic codes are the test.bin that Anton posted recently.

Hope This Helps,
--Rob

(Ian, feel free to use.   Also could .pl be added to the allowed file types for the forum)
37
USB Infrared Toy / Re: irtoy recorder perl script
Note: I should point out, most Perl distributions that I've seen do not include either Win32::SerialPort or Device::SerialPort, so I users will need to install the module by using CPAN or what ever packaging system matches the version of perl they are using.

For windows users, ActiveState's Perl distribution does have Win32::SerialPort, so PPM, ActiveState's automatic package manager can be used to install it.
38
USB Infrared Toy / Re: irtoy recorder perl script
[quote author="ian"]
Here is a cross-platform method. You can also automate it with defines, but I couldn't find the example where I did that.
[/quote]

There are a couple of ways of accomplishing this automatically.    I thought there was a version of Device::SerialPort or maybe a similarly named module that wraps the whole things for you.

Code: [Select]
#!/usr/bin/perl
#
# use by platform.
#
BEGIN {
    our $ostype = lc($^O);  # Magic variable for OS type.
    our $SerialModule;

    if ($ostype eq "mswin32") {
        print "Windows 32n";
        $SerialModule = "Win32::SerialPort";
    } elsif ($ostype eq "cygwin") {  perl in cygwin envronment
        $SerialModule = "Win32::SerialPort";   # Cygwin win32 or Posix Device::SerialPort??
        print "Cygwinn";
    } else {
        print "Assuming POSIX compatible OS, using Device::SerialPortn";
        $SerialModule = "Device::SerialPort";
    }

    eval "use $SerialModule";
    print "eval returned $retn";
}

print "Using: $SerialModulen";

# Get SerialPort object
$com = $SerialModule->new();



UPDATE: never mind, already included in USBIRToy.pm.
39
USB Infrared Toy / Suggestions for user contributed software in source code repository.
I notice you're adding user contributions from the forum to the IRToy subversion repository.   While this makes things more convenient right now, I suggest you at least add a README with possibly the link to the forum thread that you extracted it from(*).  Someone who comes along later is going to have a really hard time figuring out what all this stuff is and what is current.   Further, I'd suggest making sure these are labeled as user contributions, (typical convention is a "contrib" directory) so it's easier to distinguish the more "official" or more directly maintained software from things that were pulled out of the forum.   It might help to put the contributions in separate directories by contributor.   If the contribution becomes a more official project with multiple maintainers then one could "promote" it out of the contrib/user/ directory and into it's own directory.   In other words it might be worthwhile to make a distinction between something that was copied from the forum and a project that is being maintained by someone with SVN access.

(*)If the software gets a DP wiki page, the README should ideally be updated to point to that.

Just some suggestions, there are many ways of organizing this stuff, but I thought I'd make a few suggestions while it is still early.

Hope This Helps,
--Rob
40
USB Infrared Toy / Re: irtoy recorder perl script
[quote author="anton.todorov"]
Hi,
Finally I managed to cleanup the code of my Perl script for recording data from IRToy.
Currently it is working with Win32::SerialPort module (windows only AFAIK).
[/quote]

There is a PERL module Device::SerialPort that provides the equivalent win32 serial API for Linux and other POSIX like systems.   It doesn't appear to be very commonly packaged, so you generally have to install it from CPAN.
41
USB Infrared Toy / Re: Record and playback under Linux
I tried V.04, I haven't looked at  V0.5 yet.   The short answer is I think you could probably simplify things greatly by changing the "Press any key logic" to be "Hit enter" when you need the user controlled pauses, and let CTRL-C interrupt processing break out as needed.  This would let you avoid all of the complexity of terminal mode handling under *nix.   Keep the simple record/playback utility as simple as possible.

The long answer is a bit of background on Unix history:

Given the Unix origins of using teletypes (tty) on minicomputers in the 70's, there is still a strong notion of a terminal session in *nix command line interaction.  In the *nix kernel there is a terminal driver stack that handles the raw interaction with the terminal, whether it's an actual RS-232 serial terminal, or an emulated pseudo terminal.   (Pseudo terminals provide the terminal style behavior for remote TCP/IP logins and terminal windows in the X window system.   The default mode for most programs to read input from the user's terminal is a line at a time is "cooked" mode.   In the cooked mode, the terminal driver stack reads each character from the terminal and adds it to an input buffer.  The input character is echoed back to the terminal so the user can see what they have typed.  When the user hits Return (aka Enter), the whole processed input line is made available for the program to read from it's standard input.    If the user has typed characters but hasn't hit enter yet, the program will not see any input because it is being buffered by the terminal driver in the kernel.   In the cooked mode, some of the other processing that is done is to interpret control characters such as backspace and/or delete, to delete the previously typed character from the input buffer.   A CTRL-C, is typically the interrupt character.   When this is read from the terminal, the terminal driver stack sends an interrupt signal to the program, which causes the program to exit if it hasn't made arrangements to handle the interrupt signal.   In the manual pages, this cooked mode is also referred to as the canonical mode and the terminal driver software is referred to as a line discipline.   The current, POSIX, interface for controlling the terminal driver stack is TERMIOS.

In order for a program to process input from the terminal a character at a time as it is typed, it must put the terminal in a mode that is less cooked.   In raw mode, characters are made available to be read as soon as they are typed.  No processing or interpretation of the characters is done.   This means typed characters will not be echoed back to the terminal unless the application the user is running specifically does it.   Backspaces will be sent as input characters.  More importantly, CTRL-C will not be interpreted and will just be sent up to the user level program as input to read, no signal will be generated.    This raw mode gives the application programmer full control but full responsibility.

The problems noted above by people with IRToyRecPlay under *nix are due to raw mode being used by IRToyRecPlay in order to implement "the press any character or X to exit" behavior.   First the terminal needs to be restored to it's previous state (the canonical or cooked mode) before the program exits.   If it doesn't, when the user tries to type at the next shell prompt no characters will be echoed giving the appearance that the terminal is hung.   To get back to a sane terminal mode, type reset and hit enter.   If that doesn't work you might have to type CTRL-J reset CTRL-J.   (This has to do with *nix mapping from carriage returns (0x0D) & linefeeds (0x0A) to newlines 'n' .)

The other problem people have seen is that when that incorrectly long sleep is done to pause, the user can't break out of it by typing CTRL-C.   Again this is due to the terminal not being in cooked mode, so the CTRL-C will just be put into the input buffer as a character to be read the next time the application reads standard input.

If the desire is to still use raw mode, in IRtoyRecPlay, then it needs to be better behaved about restoring the terminal mode to the state it was in when the application started before it exits.   Since programs can also exit as a result of signals such as interrupt, signal handlers are needed to catch the signal and restore the terminal state before exiting.   This is what programs like vi, emacs, etc. do.     If you do want it to work this way, I recommend that the terminal only be in raw mode while you are waiting for input from the user.

Hope This Helps,
--Rob
42
AVRDude / Re: avrdude v5.10 doesn't work with Bus Pirate firmware v5.9
[quote author="Sjaak"]
I guess linux users are capable of compiling the code themself, but a windows compile of the new trunk would be nice.
[/quote]

Agreed.  For the various avrdude programming tutorials out there it would be best to have a place to link to where a compatible windows .exe can be found until the next release occurs.   Or the alternate would be using BP 4.x firmware which will work with the current releases of avrdude, and software that includes it like WinAVR.
43
USB Infrared Toy / Re: Bluetooth Infrared Toy. Possible?
That's an interesting idea, a wireless remote IR sender or receiver using XBee or Bluetooth.  I think it would only need sample mode.   

(I have a hardwired IR repeater system so i don't actually need it, but the idea is cooler and more flexible than buying those X-10 IR repeater pyramids)
44
AVRDude / Re: avrdude v5.10 doesn't work with Bus Pirate firmware v5.9
[quote author="tgvaughan"]
Hrm.. it seems that the avrdude trunk (http://svn.savannah.nongnu.org/viewvc/t ... ot=avrdude) already fixes the prompt detection problem.  (The current release is 9 months behind.)
[/quote]

Improving the Bus Pirate support in future releases of AVRdude to make things more robust will certainly be a help.   However, I think it's worth keeping in mind that not only do AVRdude releases not happen that often (5.10 was January 2010), it takes even longer for all of the software that bundles AVRdude,  such as WinAVR, Arduino IDE, and linux distributations, etc. to update the included version of AVRdude.
45
Pirate PIC programmer / Re: New PIC programmer adapter
When the Bus Pirate PIC programmer becomes generally available, any chance it will also have high voltage programming capability to rescue AVRs that have the fuses set incorrectly?

How different (aside from the connectors) is Bus Pirate High Voltage Programming adapter http://dangerousprototypes.com/2010/02/13/bus-pirate-high-voltage-programming-adapter/ which looks like it may have had AVR HVP capability from the Bus Pirate PIC Programmer adapter that is current in development?

MightyOhm has an Arduino AVR HVP rescue shield http://mightyohm.com/blog/products/avr-hv-rescue-shield/.     However of course it would be nice to get a single HVP adapter for the bus pirate.

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01882461632session_write_close ( )...(null):0
20.01912593248ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01912594024Database_MySQL->query( ).../DatabaseHandler.php:119
40.06292732784Database_MySQL->error( ).../Db-mysql.class.php:273