Title: "Capture Aborted! Device Not Found!" after update
Post by: frank26080115 on January 16, 2011, 07:17:46 am
Post by: frank26080115 on January 16, 2011, 07:17:46 am
I got the sniffer back in July of last year, the lack of RLE back then made me never use it.
I just checked back, downloaded the latest windows installer, and ran all the upgrades. Now I can't capture any data. It says "Capture Aborted! Device Not Found!" when I try to start a capture.
The COM port is selected correctly (COM11, Logic Sniffer CDC-232). No other software is using the same COM port. VID is 04D8 and PID is FC92. The PWR LED is on, ACT LED is off, TRIG LED is on, ARM LED is off.
If I go into update mode, PUMO loader reports:
Opening serial port 'COM11' @ 921600 ... OK
Found PUMP HW: 1, FW: 2.1, Boot: 1
Found flash: ATMEL AT45DB041D
Downloading and re-installing the mchpcdc.inf does not help
I cannot find a way to re-assign the COM port number
Java is up-to-date
I'm running Win7 Pro 64-bit with test mode enabled (driver signing disabled)
edit: oh sorry I didn't realize this was some sort of new client with a bug report thread already
edit: wow you guys need a bug tracker instead of one massive thread, I was going to repost this to the thread and ask you to delete this one but now I don't know what's a better idea so I'll let the mods decide
edit: I just ran the old "classic" client and the rocket button doesn't do anything, no error messages, the diagram and tools menu are greyed-out
I just checked back, downloaded the latest windows installer, and ran all the upgrades. Now I can't capture any data. It says "Capture Aborted! Device Not Found!" when I try to start a capture.
The COM port is selected correctly (COM11, Logic Sniffer CDC-232). No other software is using the same COM port. VID is 04D8 and PID is FC92. The PWR LED is on, ACT LED is off, TRIG LED is on, ARM LED is off.
If I go into update mode, PUMO loader reports:
Opening serial port 'COM11' @ 921600 ... OK
Found PUMP HW: 1, FW: 2.1, Boot: 1
Found flash: ATMEL AT45DB041D
Downloading and re-installing the mchpcdc.inf does not help
I cannot find a way to re-assign the COM port number
Java is up-to-date
I'm running Win7 Pro 64-bit with test mode enabled (driver signing disabled)
edit: oh sorry I didn't realize this was some sort of new client with a bug report thread already
edit: wow you guys need a bug tracker instead of one massive thread, I was going to repost this to the thread and ask you to delete this one but now I don't know what's a better idea so I'll let the mods decide
edit: I just ran the old "classic" client and the rocket button doesn't do anything, no error messages, the diagram and tools menu are greyed-out
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: ian on January 16, 2011, 09:29:53 am
Post by: ian on January 16, 2011, 09:29:53 am
Hi frank -
Sorry about the problems with the Logic Sniffer.
The PIC looks to be in good shape, I'd guess there's a bitstream in the FPGA that doesn't work with the PIC firmware version. Which firmware and bitstream did you load? What version of the client did you test?
Sorry about the problems with the Logic Sniffer.
The PIC looks to be in good shape, I'd guess there's a bitstream in the FPGA that doesn't work with the PIC firmware version. Which firmware and bitstream did you load? What version of the client did you test?
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: jawi on January 16, 2011, 01:18:04 pm
Post by: jawi on January 16, 2011, 01:18:04 pm
[quote author="frank26080115"]
I got the sniffer back in July of last year, the lack of RLE back then made me never use it.
I just checked back, downloaded the latest windows installer, and ran all the upgrades. Now I can't capture any data. It says "Capture Aborted! Device Not Found!" when I try to start a capture.
...
I'm running Win7 Pro 64-bit with test mode enabled (driver signing disabled)
[/quote]
Hmm, I've got a Win7 64-bit installation on another laptop as well; I'll check whether the client still works there.
[quote author="frank26080115"]
edit: wow you guys need a bug tracker instead of one massive thread, I was going to repost this to the thread and ask you to delete this one but now I don't know what's a better idea so I'll let the mods decide
[/quote]
*grin* actually, there's an issue-tracker (http://https://github.com/jawi/ols/issues) on GitHub, but that is not (yet) being used. Probably it would be best to use that one instead of a major bug-tracking thread ;)
I'll let you know what the status of the Win7 64-bit issue is as soon as I've tested it.
I got the sniffer back in July of last year, the lack of RLE back then made me never use it.
I just checked back, downloaded the latest windows installer, and ran all the upgrades. Now I can't capture any data. It says "Capture Aborted! Device Not Found!" when I try to start a capture.
...
I'm running Win7 Pro 64-bit with test mode enabled (driver signing disabled)
[/quote]
Hmm, I've got a Win7 64-bit installation on another laptop as well; I'll check whether the client still works there.
[quote author="frank26080115"]
edit: wow you guys need a bug tracker instead of one massive thread, I was going to repost this to the thread and ask you to delete this one but now I don't know what's a better idea so I'll let the mods decide
[/quote]
*grin* actually, there's an issue-tracker (http://https://github.com/jawi/ols/issues) on GitHub, but that is not (yet) being used. Probably it would be best to use that one instead of a major bug-tracking thread ;)
I'll let you know what the status of the Win7 64-bit issue is as soon as I've tested it.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: frank26080115 on January 16, 2011, 10:10:25 pm
Post by: frank26080115 on January 16, 2011, 10:10:25 pm
New client is version 0.9.0
Classic client is version "OpenBench Logic Sniffer 2.1"
PIC upgraded to "OLSv1-firmware-v2.1"
the Xilinx is loaded with "Logic_Sniffer_dynamic_depth.mcs"
The upgrade all went through and I can keep upgrading to the same firmware.
Classic client is version "OpenBench Logic Sniffer 2.1"
PIC upgraded to "OLSv1-firmware-v2.1"
the Xilinx is loaded with "Logic_Sniffer_dynamic_depth.mcs"
The upgrade all went through and I can keep upgrading to the same firmware.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: rasmus on January 17, 2011, 02:01:54 am
Post by: rasmus on January 17, 2011, 02:01:54 am
Have you tried the 0.9.2 version of the client? Upgrading from 0.9.1 to 0.9.2 fixed a problem I had that I was sure was a hardware problem.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: frank26080115 on January 17, 2011, 04:30:23 am
Post by: frank26080115 on January 17, 2011, 04:30:23 am
oh the 0.90 version shows this at startup
the new 0.9.2 does not show the same errors and now it works, sort of, data captured at various settings display data that is obviously wrong and sort of patterned, sometimes it starts and never finishes capturing
ps, why are we using CDC and not USB bulk transfers?
Quote
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.api:1.0.1.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.tool.base:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.client:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.tool.i2c:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.export.image:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.logging:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.device.logicsniffer:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.tool.measure:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.fel
ix.log:1.0.0
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.fel
ix.prefs:1.0.4
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.fel
ix.shell:1.4.2
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.apache.fel
ix.shell.remote:1.1.2
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: org.rxtx:2.2.0
.8
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.tool.spi:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.tool.state:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.device.test:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.tool.uart:1.0.0.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.util:1.0.4.SNAPSHOT
Auto-deploy install: org.osgi.framework.BundleException: Bundle symbolic name and version are not unique: nl.lxtreme.ols
.export.vcd:1.0.0.SNAPSHOT
[16/01/11 10:19:59 PM - INFO - nl.lxtreme.ols.client.Host]: LogicSniffer v0.9.0 started ...
the new 0.9.2 does not show the same errors and now it works, sort of, data captured at various settings display data that is obviously wrong and sort of patterned, sometimes it starts and never finishes capturing
ps, why are we using CDC and not USB bulk transfers?
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: rasmus on January 17, 2011, 05:14:52 am
Post by: rasmus on January 17, 2011, 05:14:52 am
Is RLE on or off? Try turning it off. RLE on the 2.12 version doesn't really work.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: frank26080115 on January 17, 2011, 06:13:02 am
Post by: frank26080115 on January 17, 2011, 06:13:02 am
actually interesting note, it is off, but i turned it on once in v0.9.2 before and it worked, successively, and then do a reset to double check v0.9.0, and then it started doing the bad data thing and won't stop doing it.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: rsdio on January 17, 2011, 07:10:32 am
Post by: rsdio on January 17, 2011, 07:10:32 am
[quote author="frank26080115"]ps, why are we using CDC and not USB bulk transfers?[/quote]CDC allows the PIC firmware to be very basic, and it allows the SUMP client software to be written in any language that can open a generic serial port. Given the nature of the open community, it's difficult to find the resources for a "better" solution.
I also believe that it (CDC) allows Windows users to get by without needing a custom driver for the OLS. I'm a little uncertain about this, because I don't know when a USB driver is needed in Windows, and I'm uncertain about how universally available libusb is or whether it is a complete solution. All I know for certain is that OSX does not require a custom driver for any user application to access a custom USB device, but I don't think it's that simple under other operating systems.
If you'd like to develop support in the OLS for USB Bulk transfers, then you're welcome to give it a try. The firmware for the OLS is open source. The problem is that you'd also need to modify the SUMP client software to deal with a USB Bulk transfer instead of a generic serial port. I happen to think this is a worthwhile effort, and it shouldn't be impossible since the clients are usually open source, too. However, I would suggest that USB Isochronous transfers might be a better choice because of the guaranteed, negotiated bandwidth.
The $150 8-channel Saleae logic product suffers because it uses Bulk transfer, where the necessary bandwidth is not guaranteed. The result is that logic captures often fail in the middle for no good reason, simply due to random USB events. Bulk transfers get last priority after other types. I've suggested that logic should use isochronous to alleviate that product's issues, but it's a huge development effort.
It would be really cool if the OLS had support for USB Isochronous transfers, although with RLE it might be difficult to predict the amount of bandwidth to allocate.
I also believe that it (CDC) allows Windows users to get by without needing a custom driver for the OLS. I'm a little uncertain about this, because I don't know when a USB driver is needed in Windows, and I'm uncertain about how universally available libusb is or whether it is a complete solution. All I know for certain is that OSX does not require a custom driver for any user application to access a custom USB device, but I don't think it's that simple under other operating systems.
If you'd like to develop support in the OLS for USB Bulk transfers, then you're welcome to give it a try. The firmware for the OLS is open source. The problem is that you'd also need to modify the SUMP client software to deal with a USB Bulk transfer instead of a generic serial port. I happen to think this is a worthwhile effort, and it shouldn't be impossible since the clients are usually open source, too. However, I would suggest that USB Isochronous transfers might be a better choice because of the guaranteed, negotiated bandwidth.
The $150 8-channel Saleae logic product suffers because it uses Bulk transfer, where the necessary bandwidth is not guaranteed. The result is that logic captures often fail in the middle for no good reason, simply due to random USB events. Bulk transfers get last priority after other types. I've suggested that logic should use isochronous to alleviate that product's issues, but it's a huge development effort.
It would be really cool if the OLS had support for USB Isochronous transfers, although with RLE it might be difficult to predict the amount of bandwidth to allocate.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: robots on January 17, 2011, 08:29:56 am
Post by: robots on January 17, 2011, 08:29:56 am
CDC ACM uses bulk transfers as well. USRP (gnu radio) uses bulk transfers as well (example).
Isochronous transfers are not reliable in case of errors - no packet retransmission. In audio small glitch is introduced, that does not matter.
Today usb has bandwidth of 480mbit. OLS uses "just" 12mbit at most. I don't see any problem why couldn't the rate be maximum, unless you use the same roothub for HDD/streaming video/webcam/... , while trying to capture some data on OLS.
Libusb is used in few commercial projects. Version 1.0 creates "inf" file that will bind libusb driver to the device of your choice. In windows any device needs driver - (except for few that are included in "class" drivers - CDC acm, uvc video, etc). In linux libusb sees device directly. Not sure about macos.
I think CDC was used for compatibility with SUMP and ease with drivers. Compared to serial port used on original SUMP, CDC is a good choice for usb replacement.
Isochronous transfers are not reliable in case of errors - no packet retransmission. In audio small glitch is introduced, that does not matter.
Today usb has bandwidth of 480mbit. OLS uses "just" 12mbit at most. I don't see any problem why couldn't the rate be maximum, unless you use the same roothub for HDD/streaming video/webcam/... , while trying to capture some data on OLS.
Libusb is used in few commercial projects. Version 1.0 creates "inf" file that will bind libusb driver to the device of your choice. In windows any device needs driver - (except for few that are included in "class" drivers - CDC acm, uvc video, etc). In linux libusb sees device directly. Not sure about macos.
I think CDC was used for compatibility with SUMP and ease with drivers. Compared to serial port used on original SUMP, CDC is a good choice for usb replacement.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: ian on January 17, 2011, 08:36:37 am
Post by: ian on January 17, 2011, 08:36:37 am
Quote
ps, why are we using CDC and not USB bulk transfers?
What everyone else said. We were developing a new hardware device to go with the SUMP client, which was serial. It just made sense to use USB serial to get going fast and with minimal effort. There was a lot of push to use another protocol, but that would have lengthened and complicated development. In order to test the hardware we'd have needed to update the client too, and I'm not a Java programmer at all so it is beyond my abilities. Everything is open source though, so anyone is welcome to add that feature to a firmware and client.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: honken on January 17, 2011, 09:14:02 am
Post by: honken on January 17, 2011, 09:14:02 am
[quote author="robots"]
Today usb has bandwidth of 480mbit. OLS uses "just" 12mbit at most. I don't see any problem why couldn't the rate be maximum, unless you use the same roothub for HDD/streaming video/webcam/... , while trying to capture some data on OLS.
[/quote]
The 480mbps is for hi-speed devices the pic on ols is a full speed device and limited to 12mbps. So it would take a new hardware to get to hi-speed.
But I agree on that the communication path can be optimised if another (ie vendor) protocool was used.
Today usb has bandwidth of 480mbit. OLS uses "just" 12mbit at most. I don't see any problem why couldn't the rate be maximum, unless you use the same roothub for HDD/streaming video/webcam/... , while trying to capture some data on OLS.
[/quote]
The 480mbps is for hi-speed devices the pic on ols is a full speed device and limited to 12mbps. So it would take a new hardware to get to hi-speed.
But I agree on that the communication path can be optimised if another (ie vendor) protocool was used.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: robots on January 17, 2011, 04:50:37 pm
Post by: robots on January 17, 2011, 04:50:37 pm
[quote author="honken"]
But I agree on that the communication path can be optimised if another (ie vendor) protocool was used.
[/quote]
CDC does not use any protocol at all. The descriptor just says "I am cdc" and that's all. All data that should go out of Uart TX goes to one endpoint and data comming in goes to different endpoint.
It would be possible to write libusb application that directly writes to these endpoints with no effort at all, and no hw/fw modification.
I am not sure about throttling on the CDC line. I know that linux does have (only) output data rate throttling to the rate set as baudrate. Other than that its "max" speed.
But I agree on that the communication path can be optimised if another (ie vendor) protocool was used.
[/quote]
CDC does not use any protocol at all. The descriptor just says "I am cdc" and that's all. All data that should go out of Uart TX goes to one endpoint and data comming in goes to different endpoint.
It would be possible to write libusb application that directly writes to these endpoints with no effort at all, and no hw/fw modification.
I am not sure about throttling on the CDC line. I know that linux does have (only) output data rate throttling to the rate set as baudrate. Other than that its "max" speed.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: honken on January 17, 2011, 09:39:31 pm
Post by: honken on January 17, 2011, 09:39:31 pm
Yes, the datapath in cdc-acm is unaltered, but there is some signaling taking place, there is something like two extra usb packet transfers for every packet with data.
This is to support old hardware signaling with RTS/CTS.
A vendor protocool could fill every usb packet with data and ignore signaling.
If we eventually also got the ping-pong buffer mode of the pic usb engine implemented we would minimize the average latency of each transfer, because then there would always be data ready to be shipped.
This is to support old hardware signaling with RTS/CTS.
A vendor protocool could fill every usb packet with data and ignore signaling.
If we eventually also got the ping-pong buffer mode of the pic usb engine implemented we would minimize the average latency of each transfer, because then there would always be data ready to be shipped.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: frank26080115 on January 18, 2011, 04:58:22 am
Post by: frank26080115 on January 18, 2011, 04:58:22 am
I just wondered about the CDC stuff because I have a genuine Saleae Logic, and a Saleae Logic clone from ITead Studio called Mini Logic (which also works as an USBee and Altera USB Blaster). ITead Studio was able to reverse engineer the Saleae Logic and USBee so that he can make a clone that is compatible with their software (which wasn't hard, I think the Cypress chip is basically a USB FIFO bridge in all three cases, configured via EEPROM, the clone just had several EEPROM settings to load). I do have a software USB packet analyzer. I would like to see if it is possible to achieve the same thing with the OLS.
Great work with the open source stuff, but the USBee client software can analyze USB packets at a low level, which I hold in high regard
Great work with the open source stuff, but the USBee client software can analyze USB packets at a low level, which I hold in high regard
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: jawi on January 18, 2011, 09:18:39 am
Post by: jawi on January 18, 2011, 09:18:39 am
[quote author="frank26080115"]
I just wondered about the CDC stuff because I have a genuine Saleae Logic, and a Saleae Logic clone from ITead Studio called Mini Logic (which also works as an USBee and Altera USB Blaster). ITead Studio was able to reverse engineer the Saleae Logic and USBee so that he can make a clone that is compatible with their software (which wasn't hard, I think the Cypress chip is basically a USB FIFO bridge in all three cases, configured via EEPROM, the clone just had several EEPROM settings to load). I do have a software USB packet analyzer. I would like to see if it is possible to achieve the same thing with the OLS.
Great work with the open source stuff, but the USBee client software can analyze USB packets at a low level, which I hold in high regard
[/quote]
I've been playing with the idea to write a USB decoder tool, however, with the current OLS, sampling USB is only possible for USB1.1. An alternative could be to simply use the USB-protocol stack of the PIC controller directly, and let it "sniff" the USB signals. This way we could support both USB1.1 and USB2. I believe this is also how the USBee hardware does it...
Edit: an alternative would be to use a dedicated USB-sniffer, such as the (very promising!) OpenVizsla (http://http://b.openvizsla.org/) project.
I just wondered about the CDC stuff because I have a genuine Saleae Logic, and a Saleae Logic clone from ITead Studio called Mini Logic (which also works as an USBee and Altera USB Blaster). ITead Studio was able to reverse engineer the Saleae Logic and USBee so that he can make a clone that is compatible with their software (which wasn't hard, I think the Cypress chip is basically a USB FIFO bridge in all three cases, configured via EEPROM, the clone just had several EEPROM settings to load). I do have a software USB packet analyzer. I would like to see if it is possible to achieve the same thing with the OLS.
Great work with the open source stuff, but the USBee client software can analyze USB packets at a low level, which I hold in high regard
[/quote]
I've been playing with the idea to write a USB decoder tool, however, with the current OLS, sampling USB is only possible for USB1.1. An alternative could be to simply use the USB-protocol stack of the PIC controller directly, and let it "sniff" the USB signals. This way we could support both USB1.1 and USB2. I believe this is also how the USBee hardware does it...
Edit: an alternative would be to use a dedicated USB-sniffer, such as the (very promising!) OpenVizsla (http://http://b.openvizsla.org/) project.
Title: Re: "Capture Aborted! Device Not Found!" after update
Post by: rsdio on January 18, 2011, 11:46:04 am
Post by: rsdio on January 18, 2011, 11:46:04 am
[quote author="frank26080115"]ITead Studio was able to reverse engineer the Saleae Logic and USBee so that he can make a clone that is compatible with their software (which wasn't hard, I think the Cypress chip is basically a USB FIFO bridge in all three cases, configured via EEPROM, the clone just had several EEPROM settings to load). I do have a software USB packet analyzer. I would like to see if it is possible to achieve the same thing with the OLS.[/quote]I would not recommend this. Saleae logic needs a real-time protocol yet is not designed to take advantage of the appropriate USB features for real-time. As a result, since Saleae logic does not negotiate for guaranteed bandwidth, many LA captures fail. This makes the product really annoying, because the failed capture is always the one where you lose the data you need. The limited 24 MHz sampling rate is exacerbated by the fact that failures become more frequent at the highest rates. Some people have pointed out that Bulk transfers have error correction and retransmission, while Isochronous transfers do not. However, despite getting many other things wrong, the designers of USB understood that it is pointless to have the option of retransmission when you're already using the maximum bandwidth, or even a smaller but fixed bandwidth. Isochronous still allows error detection.
Anyway, I don't think it would be a good idea to try to turn the OLS into a Saleae logic emulator, because the performance would really suffer. About the only thing to be gained from this would be access to the gorgeous front end software. However, front ends are a dime a dozen, and it's probably better to spend time writing a nice front end for OLS that supports sample rates above 24 MHz and channel counts beyond 8 inputs, instead of trying to reverse engineer some kind of compatibility. Besides, I don't think Joe would appreciate anyone attempting to use his front end for another product. I sure hope Itead had permission...
Don't get me wrong: The Saleae logic is a beautiful piece of hardware and software. I'd love to have a tiny, milled aluminum enclosure for every Dangerous Gadget I own. I bought extra clips from Saleae for use with my OLS. I think the front end software is the nicest thing I've seen in a long time. But with all those great features, the Saleae logic still needs some serious work in the protocol department, because the way it uses USB is not appropriate. Emulating this part of the equation would be a really bad choice for the OLS.
Anyway, I don't think it would be a good idea to try to turn the OLS into a Saleae logic emulator, because the performance would really suffer. About the only thing to be gained from this would be access to the gorgeous front end software. However, front ends are a dime a dozen, and it's probably better to spend time writing a nice front end for OLS that supports sample rates above 24 MHz and channel counts beyond 8 inputs, instead of trying to reverse engineer some kind of compatibility. Besides, I don't think Joe would appreciate anyone attempting to use his front end for another product. I sure hope Itead had permission...
Don't get me wrong: The Saleae logic is a beautiful piece of hardware and software. I'd love to have a tiny, milled aluminum enclosure for every Dangerous Gadget I own. I bought extra clips from Saleae for use with my OLS. I think the front end software is the nicest thing I've seen in a long time. But with all those great features, the Saleae logic still needs some serious work in the protocol department, because the way it uses USB is not appropriate. Emulating this part of the equation would be a really bad choice for the OLS.
Title: Re:
Post by: mrjoda on November 12, 2016, 04:02:32 pm
Post by: mrjoda on November 12, 2016, 04:02:32 pm
hi guys, i have same problem as author of topick and this dude https://www.youtube.com/watch?v=b4142knk5pk (https://www.youtube.com/watch?v=b4142knk5pk)
after i bought it, i tried it and it wont work so i flashed new firmware, it tooks few hours because were problems with PIC flash. I flashed new Demon FW (now i cant flash older FW (errors)).
it doesnt work with any SW software (official, Jawis or PulseView) and i am really pissed of because i spend 67€ for not working crap.
can you help me please ?
thanks
after i bought it, i tried it and it wont work so i flashed new firmware, it tooks few hours because were problems with PIC flash. I flashed new Demon FW (now i cant flash older FW (errors)).
it doesnt work with any SW software (official, Jawis or PulseView) and i am really pissed of because i spend 67€ for not working crap.
can you help me please ?
thanks