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

92
Client software / Re: Jawi's Logic Sniffer client software - releases
I'm seeing an issue when aborting a capture.  I have 16 channels enabled with RLE (so really 15), but I'm only using 4 channels.  I enabled 16 channels to extend the time length of capture with RLE.  Anyway, I arm a capture and the trigger condition happens and you can see that the OLS has detected that by looking at the LEDs on the OLS.  Since the sample rate is only 1 MHz, it can take a long time for the capture to time out when there isn't much activity on the channels.  So, I click on the red circle with the minus sign to abort the capture.  On the older 0.9.4 client, this worked fine.  The data that did get captured is transferred and then displayed immediately.  On 0.9.5b2 version, very little data is displayed, not even the trigger event and the screen is showing almost all gray until I click the button to "zoom to best fit" and then the screen displays the channels, but there is only a very short (10ms) captured time displayed when there should be several seconds shown.  If I let the capture time out on its own, then everything works correctly.  It's not really feasible to wait for the capture to time out naturally, since with a 1 MHz sample clock and 16 channels, it can take upwards of 200 seconds for the capture to finish on its own, assuming that there are only very sparse transitions on the channels.

The problem does not appear to be limited to 16 channels.  It also fails in the same way when setup for 8 or 32 channels, though I can't say for certain that letting it time out naturally with 32 channels works correctly because I got bored while waiting hours for it to finish on its own.

B.B.
93
Client software / Re: Jawi's Logic Sniffer client software - releases
FWIW since the comm channel between the PIC and the FPGA was changed from UART serial to SPI, baud rate is not actually used any more.  Set whatever baud rate you like, the data transfers at the same speed regardless.  The PIC still emulates a UART interface, but baud rate is ignored as far as I can tell.

B.B.
94
Open Bench Logic Sniffer / Re: how run OLS
[quote author="kind2011"]hi i received my logic sniffer but i can install the client when i download the latest version 0.9.5 beta 2, there aren't executable file or setup file, how can a install it?[/quote]

Assuming that you're running Windows, double-click the run.bat file.  For Linux, run.sh.

B.B.
95
Open Bench Logic Sniffer / Re: header pins
[quote author="bitchanger"]I am only using 5 channels right now.  Are you saying I can disable the other 3 in group 0 and have the memory available?
How would I go about that?  It would be nice to have a longer record of what happens in this circuit....[/quote]

As already pointed out, you cannot enable/disable channels on a one by one basis.  You can do it on an 8bit basis.

Also, there are some subtle points about RLE.  Specifically, there is no degradation of timing accuracy when using RLE.  It simply extends the length of time of captures for which there are significant periods of inactivity.  Also, depending on exactly how much activity, you will get a different amount of capture time and explicity enabling groups that you're not using, can increase the amount of time captured.  Example; with just 8 channels enabled, you can get 24K samples recorded and a sample gets recorded for one of two reasons.  The first reason is if one or more of the 8 signals makes a transition to high or low state.  The second reason is if the max count is exhausted.  That is, if no channels are changing state, the hardware is counting how many 1 us intervals that the same data is seen and eventually the counter will reach it's maximum value.  At that point, it must record the max count, using one byte of memory that would otherwise be used for recording a transition on a channel. 

With 8 channels enabled and RLE, the 8th channel is not available for capturing data, but is used for the RLE flag signalling that the other 7 bits recorded aren't actually recorded data, but are the count of how many successive samples of data had the same exact pattern.  So, if we have a sample clock and there is no activity, we must record a count of 127 samples of the same data, every 128us.  With 24K total sample memory, that works out to some 1.5 seconds total capture time.  Of course that's with no channels transitioning.  If any channel has a transition, then that must be recorded and uses memory and so, that will subtract from the available memory and you'll get less than the theoretical 3 seconds of capture.

If you enable 2 groups for 16 channels, you will get an even longer total capture time if there are no transitions since now there are 15 bits available for the repetition count.  In this case, you get 15 channels and the 16th channel becomes the RLE flag.  Now, you get 32768 rep max count.  Of course, you don't get something for nothing.  Now our total sample memory drops to 12K.  Still, at 1 MHz, you get some 200 seconds of capture.  Again, this is if there were no transitions.  If there are transitions, then that uses up sample memory and subtracts from the total capture time available.

So, even if you don't need 16 channels, you may get a longer capture time for a situation where data transitions are sparse when using RLE.  32 channels with RLE will extend the total capture time to ridiculous extremes, but you're left with just 6K of sample memory for actual transitions.  When using these really long capture times on sparsely transitioning data, it's fairly common that you have to manually terminate the capture, as you get tired of waiting for the capture to finish on its own.

B.B.
96
Client software / Re: run.bat and Java Console
I'm not sure if this works correctly, but to avoid the console window for Windows, you need to run Javaw.exe instead of Java.exe.  Assuming that Javaw.exe accepts cmd line options, then create a shortcut with this cmd line:

javaw -Xmx1024m -Dnl.lxtreme.ols.bundle.dir="P:plugins" -Dplastic.defaultTheme=SkyBluer -cp "P:bin*" nl.lxtreme.ols.runner.Runner

replace the "P:" with the path to OLS.

It seems to work, but I'm suspicious that it will work correctly in all cases.

Or you could just copy the Jawis-OLS-client.exe file from the 0.9.4 released version into the folder with the beta version and use that instead of the run.bat.

B.B.
97
Client software / Re: Feature Request: Group signals and display them in HEX
Actually, that is not quite correct.  It's channel 7 that you give up when configured for 8 channels with RLE enabled.  It's always the highest numbered channel that gets used for RLE.  So, for a 16 channel config you give up channel 15, etc.  As for keeping the channels in order when setting up a group, yes that is true.  This reflects the way the HP/Agilent 16550 from which the OLS seems to be heavily borrowing.  There are other high end Logic analyzers that allow arbitrary grouping/ordering amongst the channels, but the OLS client doesn't allow that, or if it does, I'm not aware of how to do it.

B.B.
98
Client software / Re: OLS capture file
You need to to multiply the number to the right of the "@" with 1/rate.  You get the rate from the header of the file.

Code: [Select]
;Size: 219
;Rate: 10000000
;Channels: 32
;EnabledChannels: 65535
;TriggerPosition: 325
;Compressed: true
;AbsoluteLength: 64626925
;CursorEnabled: false
00000061@0
00000060@326
00000061@3007
00000060@45958


From this you see the sample "rate" was 10 MHz.  So, each count is 100 ns.  Channel 0 went from a '1' to a '0' 326 samples after the start or 32.6 us.  Then channel 0 went high again some 3007 - 326 = 2681 samples later, or 268.1 us.

B.B.
101
USB Infrared Toy / Re: Transmit success with Microsoft XBOX 360 remote config?
FWIW XBOX 360 IR is using 36 KHz not 56 KHz.  It is the well known MCE protocol which is an extension of RC6. 

One common problem with simple record/playback of IR with most RCx protocols, is the dreaded "toggle code" issue.  Most if not all of the RCx protocol IR receivers enforce strict compliance of alternating toggle code on successive keypresses.  The toggle code is one bit out of the 32 bits in the MCE protocol.  The IR receiver in the 360 requires successive presses of a given button, transmit the toggle code alternately as a '1' and a '0'.  So, if you record a particular key, say the pwr key, you will capture one state for the toggle bit.  You can play that back once and it will probably work.  Once the 360 saw that toggle state for that key, it will assume that any further reception of that same toggle state for this key, is just a repeat.  That is, you're holding the key down.  I won't get into the rationale for this design decision on the part of Philips engineers back in the early 80s, but we're stuck with it.  If you want the 360 to respond to the pwr key IR cmd again, you have to send it with the toggle bit opposite to what was sent the first time.

Some RCx IR receivers (not the 360) timeout and eventually go back to accepting either toggle code.  Pressing or sending any other key cmd, will cancel the receiver's expectation for toggle code on a given key.  It all sounds pretty grim, but many have enountered and overcome the dreaded toggle code issue.  The simplest thing that can be done is to always send a "dummy" keypress prior to sending the key that you want.  For discrete on and discrete off keys, just send the code with one toggle state first and then follow it with the code with the other toggle state.  If the 360 is expecting toggle code 0 and you send 1, it ignores it, but then you immediately send toggle 0, which it won't ignore.  If the 360 is expecting toggle code 1 and you send it toggle code 1, it will of course respond.  Then you send it the same discrete on with toggle code 0 and it WOULD respond to that, but since this is a discrete on cmd and the unit is already on, nothing happens.

If you want to learn the ins and outs of RCx protocols, I've attached (assuming that is allowed) a large GIF image showing how they breakdown.  The last one at the bottom, is the MCE protocol.  The diagram shows the signal as a '1' when the 36 KHz carrier is on and a '0' when the 36 KHz carrier is off.

B.B.
102
Client software / Re: Jawi's Logic Sniffer client software - releases
[quote author="jawi"]@B.B.: WOW! Thanks for the investigation and detailed report! It will be of great use when I'll dive into this bug. I've created a new issue (#81) on GitHub for this; so you (and others) can track its progress.[/quote]

Here are the Portmon logs showing the behavior:

Code: [Select]
0.9.5b1 8 ch capture. No hang.

1  0.10029515  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
3  0.10037784  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
5  0.10040773  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
7  0.10043092  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
9  0.10040131  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
11  0.10042785  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
13  0.10039516  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
15  0.02005227  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 1: 62   
17  0.00000503  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 1: 62   
19  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 1: 62   

0.9.5b1 16 ch capture. Hung at the end.

1  0.10034683  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
3  0.10034990  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
5  0.10034767  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
7  0.10038371  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
9  0.10041081  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
11  0.10037672  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
13  0.10041164  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
15  0.10035074  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
17  0.10032057  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
19  0.09724644  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 1: 62   
21  0.00000475  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
23  0.00000475  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
25  0.00000475  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
				|
				|
				|
				|
				|
				|
22513  0.00000391  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
22515  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
22517  0.00000335  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
22519  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
22521  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
22523  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 2: 00 60   
24601  0.10042058  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
24603  0.10016832  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
24605  0.10042701  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
24607  0.10038622  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   

0.9.5b1 24 ch capture. Hung at the end.

1  0.10035745  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
3  0.10035018  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
5  0.10039600  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
7  0.10038036  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
9  0.10038510  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
11  0.04189555  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 1: 62   
13  0.00000447  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 3: 00 00 62   
15  0.00000475  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 3: 00 00 62   
17  0.00000447  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 3: 00 00 60   
19  0.00000447  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 3: 00 00 60   
21  0.00000475  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 3: 00 00 60   

0.9.5b1 32 ch capture. No hang.

1  0.10039991  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
3  0.10038455  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
5  0.10039404  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
7  0.10038622  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
9  0.10036974  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
11  0.10038036  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
13  0.10039069  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
15  0.10039460  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
17  0.10039097  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
19  0.10034627  java.exe  IRP_MJ_READ  USBSER002  TIMEOUT  Length 0:   
21  0.02927048  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 1: 63   
23  0.00000503  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 3: 00 00 00   
25  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 4: 63 00 00 00   
27  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 4: 63 00 00 00   
29  0.00000363  java.exe  IRP_MJ_READ  USBSER002  SUCCESS  Length 4: 63 00 00 00 


With 0.9.4, all reads are single byte no matter what the number of channels configured.  Also I noticed on the 32 channel capture with 0.9.5b1, that the beginning of the transfer is one byte followed by 3 bytes and then 4 bytes per call all the way to the end.  In the 16 and 24 channel captures, I see a one byte followed by 2 byte transfers for 16 channel and 3 byte transfers for 24 channel, all the way to the end.  Of course, it doesn't add up to the right amount of data for the 16 and 24 channel cases.  I'm not really sure how calls to read from the serial port are handled at the various layers, but i expect that if you ask for x bytes and only x-1 bytes are available, then it waits forever.

So, I'm thinking that what I said earlier about ignoring the first byte is incorrect.  The first byte seems to be the last data in the capture, as it appears that the data gets transferred in reverse order.  So, the channel scrambling problem is caused by missing data at the end of the transfer.  That missing data corresponds to the beginning of the capture.  If there is one byte or two bytes missing at the end, then when you interpret the data that you did get, you'll be de-synchronized about which data belongs to which channel group.

Getting back to the original issue though, if you start the transfer with a one byte transfer and then switch to 2 byte transfers for the duration of a 16 channel capture, then you're going to have to do a one byte transfer at the end in order to even things up.  If the last call to the serial driver asked for 2 bytes, but there is only one more byte in the buffer, then it hangs I'm guessing.  I didn't count the exact number of bytes transferred, but I expect if I did, we'd see the mismatch.

B.B.
103
Client software / Re: Jawi's Logic Sniffer client software - releases
Flubberflab and Jawi,

I'm glad to see that I'm not the only one with the hang issue on 16 and 24 channel captures.  I also see scrambled data on 16 and 24 channel captures with RLE enabled after manually stopping a hung capture.  For non-RLE captures, after manually stopping, the channels assignments are not correct.  That is, data from channel 0 displays as if were on channel 8.  I did some investigation with Portmon and confirmed that the setup for the capture is absolutely identical between 0.9.4 (which works correctly) and 0.9.5b1.  So, it isn't a setup issue.  Examining the captured data as it is being read, shows something interesting.  On 0.9.4 version, a 16 channel capture gets read one byte per function call to the Windows serial comm driver.  On 0.9.5b1 version, the timing seems just a little bit different and the very first call returns a single byte, but every call after that returns two bytes.  In theory that should be irrelevant, as the calling program should be able to handle how many ever bytes the driver returns, but in 0.9.5b1 it seems to cause a problem.  The first byte appears to be ignored completely and then the client software is out of sync with which data belongs to which channel.  When it gets to the end of the data transfer, the software is waiting for one more byte that the OLS will never send since it already sent all the required data.  It's just that the client software somehow got confused and ignored the first byte.  So, the client software waits forever for the last byte, or until you cancel the capture manually.

B.B.
104
Open Bench Logic Sniffer / Re: Something you might find useful too [OLS add-on PCB]
[quote author="alm"][quote author="Qwlciguk"]I'm not sure what you mean by "not very well behaved" with respect to the OLS input impedance.
[/quote]
What I mean is that I don't expect the impedance to be very flat across the frequency spectrum, since it's just an unterminated input straight into the buffer, without any form of damping or termination. Maybe even some resonance in the pass band. The HP RC matching network might help, although I expect their front-end to be much better given their RF background. Agilent scope inputs also tend to be better in this regard than other manufacturers.

[quote author="Qwlciguk"]
I too was a bit concerned when I discovered that the flying lead set included an RRC matching circuit in each lead.  So, I did some quick sims last night to see what effect it might have.  It was nothing dramatic at all.  Assuming 1.0pf and 100 Meg for the input buffer capacitance/resistance and including the RRC matching circuit, I see only very minor effects.  There was ~2db of attenuation at 1 GHz.[/quote]
This is not something I'd trust a simulator on. I highly doubt the 1pF spec, the PCB trace alone is probably more than that. -2dB at 1GHz would be extremely impressive, since scope vendors on the market never (?) succeeded in making a useful 1 Mohm front-end beyond 500MHz, it's all 50 ohm above that.

But if it works for you I guess that's all you should care about.[/quote]

We're not trying to make a commercial instrument here.  The OLS only goes to 200 MHz sample rate.  I only did the sim to see if some nasty stuff would happen in the 10-500 MHz region.  I'm very much aware that sims need to include full characterization of all parasitics in the complete path.  If the sim had shown problems with just a simple model, then I'd stop immediately and question why I was getting good results in the real world.  After I get back to work next week, I can do a full TDR characterization on the path, but from long experience with doing this stuff, I don't expect any big revelations.  I can also make measurements with a high-speed scope right at the buffer pin with an ultra-low capacitance (<1.7pf) 3GHz bandwith probe. As for the 1.0pf, the pin capcitance itself is probably a fraction of a pf, though the input buffer stage adds another 3-5pf to that.  Playing with the load cap in the sim doesn't change things much.  Remember that there is an 8.2pf cap in parallel with the series 90.9K resistor and this offsets the effects of the load cap.  A trace on a 2 layer PCB with no gnd plane and large spacing to other traces, tends to show more inductance than capacitance.  If there's a problem with the sim model, it's the non-inclusion of parasitic inductance, not under-estimation of capacitance.

B.B.
105
Open Bench Logic Sniffer / Re: Something you might find useful too [OLS add-on PCB]
[quote author="alm"]Are these pods readily available on the used market? I know people buying old HP/Tek logic analyzers often have trouble finding correct pods, and sometimes pay more for the pods than for the analyzer.

I'm convinced that HP did an excellent job on the design of those pods, but I would be worried about the matching of the OLS input impedance (which is probably not very well-behaved) to the RC network. Weren't these designed to be used with the special woven cables?

Matching a popular pin-out sounds like a good idea, as long as it still works with cheap 0.025" connectors (i.e. no Mictor or other exotic stuff). If the OLS were to be changed to match this pin-out, it may also be a good time to add a proper input circuit with some attention paid to signal integrity and maybe even a pull-down somewhere ;).[/quote]

I'm not sure what you mean by "not very well behaved" with respect to the OLS input impedance.  I too was a bit concerned when I discovered that the flying lead set included an RRC matching circuit in each lead.  So, I did some quick sims last night to see what effect it might have.  It was nothing dramatic at all.  Assuming 1.0pf and 100 Meg for the input buffer capacitance/resistance and including the RRC matching circuit, I see only very minor effects.  There was ~2db of attenuation at 1 GHz.  I don't expect nor have I encountered any issues with using the HP/Agilent flying leadset since last August.  200 MHz captures work fine and compare favorably with captures from state of the art high end logic analyzers.  Having a gnd pin at each probe end is an absolute must for high speed work.

On the subject of pinout for the OLS, I absolutely do not recommend any pinout change for the OLS.  The HP/Agilent flying lead set is ridiculously easy to rearrange the pins to an OLS compatible pin arrangement.  The only change that I'd recommend for the OLS, is to support a double row female header, keeping the basic pinout the same.

B.B.

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