I'm trying to use SUMP (under linux). The good news is, I can successfully complete one capture of an IR code. The bad news is I can't get it to do any subsequent captures. SUMP attempts to do the capture however it never completes. The LED does not come on. (It does go on when I start the first capture.)
A quick test with terminal emulator (I'm using screen under linux), after I exit the SUMP client, I can type an R or X and get back an OK or an X01 respectively.
Note: I'm seeing the device under linux as /dev/ttyACM0, dmesg gives a line about it not being able to make calls since it's not a modem). To get SUMP to work, I make a symlink to ttyUSB0 from ttyACM0. (I didn't see where to tell sump what devices to look for.)
Thanks for any help.
--Rob
about the sump not seeing ttyACM look here:
http://dangerousprototypes.com/forum/in ... 53#msg3253 (http://dangerousprototypes.com/forum/index.php?topic=336.msg3253#msg3253)
Hey rct,
I don't know anything about the Linux version specifically. The SUMP client uses one-byte period as a timeout. On the Bus Pirate SUMP mode I had to increase the delay in the device driver settings so SUMP didn't give up while the next USB packet arrived. That may be someting to try - see if Linux will let you increase the timeout.
If you can capture the traffic through the (virtual) serial port and post it, I'll take a look and make sure the protocol is working properly.
[quote author="ian"]
I don't know anything about the Linux version specifically. The SUMP client uses one-byte period as a timeout. On the Bus Pirate SUMP mode I had to increase the delay in the device driver settings so SUMP didn't give up while the next USB packet arrived. That may be someting to try - see if Linux will let you increase the timeout.
[/quote]
I'm not sure where to set the equivalent driver parameter for linux. I'll see what I can find.
To be clear, here is the behavior I'm seeing:
- Start first capture in SUMP, the yellow LED goes on steady. I hit the button on the remote, Sump comes back and shows my waveform correctly. Sump has logged "Run completed".
- I start a 2nd capture, the yellow LED does NOT go on. SUMP waits for me to click close on the capture window. Also, the yellow LED does NOT flicker when I push a button on the remote.
- After I've closed the capture window, when I hit buttons on the remote the yellow LED does flash. (SUMP is still running, just not in capture mode)
- I can exit and restart SUMP and get a successful capture again.
It appears as if the IR Toy is making some state transitions that match SUMP's state.
The console log from sump. I've added annotations starting with #
$ java -Dgnu.io.rxtx.SerialPorts="/dev/ttyACM0" -jar analyzer.jar
Experimental: JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
/dev/ttyACM0
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
/dev/ttyACM0
Device Controller found: org.sump.analyzer.devices.Hp16500DeviceController
Device Controller = FPGA Controller
Tool found: org.sump.analyzer.tools.I2CProtocolAnalysis
Tool found: org.sump.analyzer.tools.SPIProtocolAnalysis
Tool found: org.sump.analyzer.tools.StateAnalysis
Tool found: org.sump.analyzer.tools.UARTProtocolAnalysis
Attaching to: /dev/ttyACM0 (115200bps)
Run started
Device ID: 0x534c4131
11000000 00000000 00000000 00000000 00000000
11000001 00000000 00000000 00000000 00000000
11000010 00000000 00000000 00000000 00001000
10000000 10011111 10000110 00000001 00000000
10000001 11111111 00000000 11111111 00000000
Flags: 111010
10000010 00111010 00000000 00000000 00000000
Run completed
# SUMP successfully shows my correct IR waveform.
...
# Starting 2nd capture.
Attaching to: /dev/ttyACM0 (115200bps)
Run started
Device ID: 0x534c4131
11000000 00000000 00000000 00000000 00000000
11000001 00000000 00000000 00000000 00000000
11000010 00000000 00000000 00000000 00001000
10000000 10011111 10000110 00000001 00000000
10000001 11111111 00000000 11111111 00000000
Flags: 111010
10000010 00111010 00000000 00000000 00000000
# sending IR signals, no LED activity, finally click close on capture window.
Run aborted
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1168)
at gnu.io.RXTXPort.removeEventListener(RXTXPort.java:814)
at gnu.io.RXTXPort.close(RXTXPort.java:1039)
at org.sump.analyzer.devices.FpgaDevice.detach(FpgaDevice.java:483)
at org.sump.analyzer.devices.FpgaDeviceController.run(FpgaDeviceController.java:537)
at java.lang.Thread.run(Thread.java:636)
If you can capture the traffic through the (virtual) serial port and post it, I'll take a look and make sure the protocol is working properly.
How do you want me to do that? Is there a debug option to sump to log the serial traffic? I can probably pull out the read's/writes with strace.
Is there a firmware upgrade for the IR Toy yet? How do I tell what version it's running? (obviously it's running whatever seeed programmed it to before shipping)
Thanks for your help,
--Rob
One more bit of information - It seems like the IR toy isn't receiving the 0x01 from SUMP to start the 2nd capture (or it's receiving it and ignoring it).
If I start the 2nd (or subsequent) capture and the yellow light doesn't go on, I then send a '0x01' to port, which will turn the yellow light on. SUMP then properly receives an IR code when I send one.
(This is the command I'm using to force a 0x01 into the port)
perl -e 'print " 01"' > /dev/ttyACM0
Thanks for the extra info. There isn't a firmware update yet, but there are a few things on the to do list so there will be one soon.
The IR Toy has a self-test mode that reports the firmware version. Send 't' to the base mode and it will reply 'v101', or faiX where X is an error code. Basically it tests the LED and receiver (and USB connection/crystal/etc). Failure is normal in a bright room if there's nothing to reflect the IR LED back to the receiver (try a desk, floor, piece of paper, etc), so don't worry if you get a failure code or two.
That part of the code is here:
http://code.google.com/p/dangerous-prot ... main.c#156 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/IRtoy-firmware/main.c#156)
http://code.google.com/p/dangerous-prot ... main.c#192 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/USBIRtoy/IRtoy-firmware/main.c#192)
I'm not sure how to do a port sniff in Linux, I use portmon on windows. The SUMP output is pretty helpful though, it shows that the IR Toy responds the second time and SUMP is OK with it. It would be nice to see a byte-level log of the transactions too, but I'm going to do some debugging and see what I find. I'll post my results here.
Anyone else ever see this problem using SUMP with the USB IR Toy?
I'm curious if this problem is specific to my setup.
Thanks,
--Rob
I did run it under debug, but I didn't see anything on a Windows PC that might be giving problems. I have a Linux boot, but I haven't installed the IR Toy or SUMP on it yet, so I've been dragging my feet on debugging it on Linux. I'll try to take a look at it this weekend.
If it just me, then don't worry about it, At least not until someone else complains. I can live with it as is, since I can always send it the character to put it into sump mode. I'm guessing it is probably timing related, which will make tracking it down a bit harder.
Thanks,
--Rob