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 - rasmus

34
Open Bench Logic Sniffer / Re: Status of RLE
All right, I've implemented a few things that could use some testing:

32-bit (31-channel) RLE works as before.
16-bit (15-channel) RLE works (I think) but the client doesn't support it yet. You'll see the raw RLE data in the client.
8-bit (7-channel) RLE works with the same caveats.

All RLE modes time out and go into normal sampling mode after 20 seconds if the memory isn't full by then.

Known bugs:
RLE does not work reliably with sample rates below 10 kHz because of how the timeout works.
The first run after changing either channel groups or sample rate does not yield reliable data.
35
Open Bench Logic Sniffer / Re: Status of RLE
Sure, that is obviously the long term solution, but the timer will be hard coded to some value until there is client support for a configurable timer.
36
Open Bench Logic Sniffer / Re: Status of RLE
Any thoughts on how long the standard timeout of the RLE mode should be in cases when the memory doesn't get filled quickly? 10 seconds? 20 seconds? A minute?
37
Open Bench Logic Sniffer / Re: (Near) realtime cq. continuous mode acquisition
The RLE coding scheme is quite simple. Each word is either a sample, or a number n representing n repetitions of the previous sample. The MSB determines if a word is a sample or a run-length.

For example, the following 3-channel data...
000
111
000
000
000
111

In a 4-bit coding scheme would be encoded as...
0000
0111
0000
1010 <--- This sample represents two repetitions of 000
0111

Yeah I don't think CPU is an issue. It's mainly a RAM size-issue when dealing with long recordings.
38
Open Bench Logic Sniffer / Re: (Near) realtime cq. continuous mode acquisition
Typical achievable data rates for the continuous mode would be less thanb 10 Mbit/s, which means that an hour-long recording would be smaller than 5 GB. That's nothing.

That said I don't see any reason why RLE wouldn't work, except that it would really only serve to transform the disk size problem into a RAM/CPU problem.
39
Client software / VHDL RLE updates not supported by client
I've made some progress on the 15-channel RLE mode. The client does however not seem to support it, which is actually nice for me when I'm debugging because I can see exactly what the OLS spits out. :)

15-channel and 7-channel RLE would work analogous to the 31-channel RLE that we have now.

31-channel RLE: (Already implemented in the client.)
Channels 0 to 30 are used for samples and run-lengths. Channel 31 is the RLE flag (=0 for a sample, =1 for a run-length).
This mode can encode runs of up to 2G samples, which is actually a problem, because signals with little change in them could take hours, days, weeks or years to fully record depending on the sample rate. I'm going to add a timer that stops the RLE recording after a certain number of seconds (the timer could be made user configurable).

15-channel RLE:
Channels 0 to 14 are used for samples and run-lengths. Channel 15 is the RLE flag (=0 for a sample, =1 for a run-length).
This mode is useful when you're sampling 15 or fewer channels and you have no runs significantly longer than 32k samples.

7-channel RLE:
Channels 0 to 6 are used for samples and run-lengths. Channel 7 is the RLE flag (=0 for a sample, =1 for a run-length).
This mode is useful when you're sampling 7 or fewer channels and you have no runs significantly longer than 127 samples.

Edit: Attached a test bitstream.
41
Open Bench Logic Sniffer / Re: Status of RLE
My RLE test works for me too using the 0.9.2 release. Nice for me, but very confusing as to why the client matters but only for my OLS and in different ways on different computers. Weird stuff.
42
Open Bench Logic Sniffer / Re: Status of RLE
Well, I'm using a custom firmware that doesn't have any inputs. I posted it a few posts earlier in this thread. The input ports are commented out in the .ucf-file in the FPGA project. I also removed the probe cables, just in case they pick up something that gets amplified by the buffer and somehow disturbs the FPGA. It didn't make any difference.

It certainly seems as if certain computers generate certain noise profiles on the USB cable.
43
Open Bench Logic Sniffer / Re: Status of RLE
I tried my OLS on another computer and on  that one it worked reliably with the 1.5 kHz signal, but not with the other two. In other words the problem depends on which computer the OLS is connected to. Some weird noise problem perhaps?

I also tried it with my laptop with the power cord disconnected, running on batteries, since that can sometimes help with noise. No difference.
44
Open Bench Logic Sniffer / Re: Status of RLE
Thanks for testing the bitstream.

That's interesting. I ran the very same tests again and I still get the same results as before 100% success on the Inside, 50% success on the Outside and 0% on the Test mode. Always interesting when you get different results with the same design. Maybe your Spartan 3E is a better sample than mine is.
45
Open Bench Logic Sniffer / Re: Status of RLE
Here's a simple test firmware that i compiled to demonstrate the problems with the RLE.

In this firmware, the 32 signal inputs to the FPGA are left unconnected (commented out in the ucf-file). The 'number scheme' (inside, outside, test mode) in the client software selects between three different internally generated test signals (essentially clocks of three different frequencies), each attempting to provoke errors in the RLE module in the FPGA. I've only made changes to the ucf-file and one of the processes in the Logic_Sniffer.vhd file. Everything else is exactly as in firmware version 2.12. The project is too big to be attached to this message, but I'll attach the two source files that I've made changes to in case anyone else wants to do further testing.

The inside signal is a 6.10 kHz clock.
The outside signal is a 3.05 kHz clock.
The test mode signal is a 1.53 kHz clock.

If anyone would like to upload the firmware to their OLS and run each of the number schemes (inside, outside, test mode) with RLE and test for the success rate of each signal, that might be useful. My OLS has roughly 100% success rate with the inside signal, 50% with the outside and 0% with the test mode, but maybe yours is different.

( ! ) 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.01392423224session_write_close ( )...(null):0
20.01422554840ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01422555616Database_MySQL->query( ).../DatabaseHandler.php:119
40.05612694376Database_MySQL->error( ).../Db-mysql.class.php:273