[quote author="ian"]I'm sorry about the spam filter. I wrote it custom for our board because we got 100s of spams per day, even with questions, captchas, etc. It is the only thing that has been remotely successful at stopping the onslaught of porn and other spam. [/quote] I kinda understand the reason, yet there is something terribly wrong with the filter and/or its settings. E.g. the length of a post is limited and the filter seems to mistake (some) class names with dots as URLs. In both cases you get the offpage link error message though there is no link in the post and not a single of the other rules for new users is violated. To work around a defective filter by guessing based on wrong error messages is simply annoying.
Ok, I tried to reproduce the 8ch RLE issue with more realistic data. Unfortunately, the awful anti-Spam filter strikes again, so I can't post pictures or links to data.
Anyway, there really is an issue with the RLE compression for 8ch setups. I tried an SPI capture for different sampling and channel settings which shows that the higher the frequency, the worse the RLE compression for 8ch gets. E.g. at 100MHz the 16ch setup is able to capture three times the 8ch buffer though only half of the memory is available:
While for 10MHz, the recorded buffer is larger for 8ch compared to 16ch, this behavior changes for higher sample frequencies. At 50MHz the recorded buffer is already much longer for 16ch and at 100MHz, it's nearly three times as long. This is quite a shame as I usually only need 8 channels
The run.bat from the jawis-ols-client folder tries to call a class nl!lxtreme!ols!runner!Runner, which doesn't seem to exist. So actually it's obviously impossible to launch the application via this batch.
Note: I had to split my post in several parts and replace the dots in the class name by exclamation marks because of the crappy anti-spam function which nearly drove me crazy by complaining about non-existing offsite links. It's somewhat inexcusable to annoy new users with such badly implemented pseudo anti-spam crap.
There are some cases where a (fast) automatic/continuous trigger would be nice. E.g. most scopes have buttons for automatic/normal and single triggers. I think it would make sense to implement something like this as well. Automatic: start the capture immediately with a capture depth fitting the currently displayed time resolution. Display the result and start the next capture in a loop. Normal: start the capture with the current trigger settings, adjust the capture depth to the current time resolution. Display the result and re-enable the trigger. Single: behavior of capture like it is now (capture with current trigger/memory depths conditions, stop after the first capture).
I'd really love to use the advanced trigger options that the Demon Core offers. And while the FPGA code was obviously finished in March, there is still no clue when it will be possible to actually use these new trigger options. So any news regarding this topic?
It doesn't seem to be possible currently to define a bus as in other LA applications. Instead only a probe channel can serve as a hard coded 8bit bus. Are there any plans to change this?
When pressing "Zoom to original level" directly after a capture, the screen redraw always freezes (grey screen) until you scroll or zoom.
A zoom window would be nice. Maybe it would make sense to allow to toggle between the dragging feature and a zoom window.
I got my OLS today and played around with it a little bit. I installed the newest client (3.0.8.) and updated the firmware(s) to the newest version(s) (OLSv1.firmware.v3.0.hex, logic_sniffer_3.07-Demon-Core.bit).
Apart from some quirks (OLS_Upgrader.bat expect COM6, but my OLS installed as COM9, upgrader didn't find the HW in the first N trials, client had connection issues and then crashed etc., the scripts use non-existing Linux shell commands under Windows etc.) I could get it to run.
Then again, there seem to be some issues with the 200MHz sampling and the RLE. So while starting the capture with no trigger conditions works for 10 and 100MHz without any issues, it doesn't work for 200MHz: here the OLS behaves as if it's waiting for a trigger conditions, although there is none...
Also the behavior of the RLE confuses me a little: E.g. with RLE enabled and 16 channels, you can sample for about 20s at 10MHz if there are no edges at all. However if you reduce the channels to 8, only 156ms are sampled under otherwise exactly equal conditions. With 8 channels, there are 24k per channel, so without compression, you can sample for 2.4576ms. Enabling RLE increases this to about 156ms, so the compression factor under ideal conditions is only 64:1. Then again with 16 channels, there are 12k per channel -> without compression you can sample for 1.2288ms. Enabling RLE increases this to about 20s (!), which means a compression factor of about 16384:1. So why exactly does the maximum recordable time decrease by a factor of 256 when 16 channels are used instead of 8?
