I've been literally using that laminator for that purpose not 5 minutes ago :)
Sadly, it didn't work this time, but that's just because I screwed up cleaning the board. :P I've successfully run normal thickness FR4 through it in the past, although you need to get a screwdriver in the back and pry apart the metal vanes a bit, else the board won't get through.
All the Officeworks here in Brisbane are clearing out the model, so if you can still find one you'll get it cheap.
I'm finding it quite indispensable in my job too - we've got access to all sorts of high end test equipment, but the OLS trumps them all in it's little area. Even the expensive Tektronix scopes don't match up, since you have to spend extra $$$ to get even a single simple protocol analysis module... which all come free on the OLS!
I think you always get the RXTX warning. The auto-deploy errors are probably because there was a 'felix-cache' directory left over from when you tried to run it on the other system. Delete that directory and let ols rebuild it and the errors will go away.
[quote author="jawi"] [quote author="pelrun"] However, I'm currently having an issue with the SPI module; it insists on ignoring my /CS signal (despite "Honour /CS" being checked) and just starts decoding several clock cycles late. I've also seen it insist there are /CS transitions when none exist in the data. It's correctly configured in the decoder dialog, but perhaps it's reading data from the wrong place? [/quote]
could you provide me a dumpfile with sample data so I can look into this problem myself?
EDIT: pelrun, could you try to place the area you're trying to decode between cursors 1 & 2 and try the SPI decoder again? If this works, then I already know what is going on and will fix it... [/quote]
I've attached a capture to this post. Using the cursors just causes analysis to fail with a "CS not detected" error - incidentally, that closes the analysis dialog which is a bit annoying...
However, I'm currently having an issue with the SPI module; it insists on ignoring my /CS signal (despite "Honour /CS" being checked) and just starts decoding several clock cycles late. I've also seen it insist there are /CS transitions when none exist in the data. It's correctly configured in the decoder dialog, but perhaps it's reading data from the wrong place?
Additionally, it's not setting the channel labels for /CS and SCK, just MOSI and MISO (although I don't know if that's by design or part of the bug.) EDIT: okay, looks like it's by design.
The varied signal colours are a definite improvement; I also think it'd be nicer if the signals were a few pixels shorter, whilst retaining the same spacing - that way it's less likely to confuse a permanent low/high signal with the signal adjacent to it.
There is a "Delay" field in the trigger section of the SUMP client; this waits for n samples after the trigger condition is met before capturing data. I haven't tried it with the OBLS, though.
Okay, I've gotten the OLS up and running on my windows box, but I run linux down at my workbench and things are a little more complicated there. Instead of showing up as a /dev/ttyUSBx device, it appears as /dev/ttyACMx - and SUMP (more accurately, the RXTX java serial library) doesn't recognise that as a valid serial device.
It depends where you are - I got shipping confirmation on Monday, and my OLS arrived on Friday here in Australia.
The tracking is pretty useless, I agree. The best you can hope for is a date that the package left HK. Certain types of shipment can be further tracked using your local postal service's tracking system, but this doesn't seem to apply to Seeed's packages.
Thanks, I wouldn't have been able to find the drivers without this thread - it's practically impossible to find it from DP, as the software list doesn't have it, and the hardware page doesn't talk about it at all. Maybe it needs a bit of clarification?
