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

46
Open Bench Logic Sniffer / Re: I2C BUS-ERRORs (should there be any?)
[quote author="stryker"]Not this? http://dangerousprototypes.com/docs/Logic_Pirate[/quote]

Perhaps he did mean that one.  On the other hand, that one doesn't seem to be available for purchase just yet.  The Logic_Pirate (honestly where do they get these names?) does have the advantage of 8 channels vs the Logic Shrimp with just 4 channels.  The Logic Pirate also does 40 MHz sample rate if you don't mind over-clocking 2x past the sram spec.  Neither the extra channels nor the extra speed will help with I2C.  Capture depth is the same 256k on both.

Both devices are based on a similar concept with SPI serial ram.  The Logic Pirate appears to be a newer design taking advantage of larger ram, allowing a doubling of channels.  If the ram chips were cascaded rather than run in parallel, you could get twice the capture depth and if it had a way to do RLE that would be even better.  Given the simplistic nature of the design, there just isn't any easy way to add RLE, though cascading could be made to work.
47
Open Bench Logic Sniffer / Re: I2C BUS-ERRORs (should there be any?)
[quote author="stryker"]Thanks jawi

This is my first PCB with multiple I2C devices on it, so I was really wanting to confirm that they're all co-existing nicely.  The project operates on the bench as I expect but it's really just curiosity on my part to see if there are issues that can be improved on.  From what you're saying here I won't be able to do that with the Logic Sniffer which is a shame.

I wasn't aware of the Logic Pirate project but will scoop one up when they come live on seeed and get back to this.

Cheers, Geoff[/quote]

I suspect that Jawi actually meant this one:

http://dangerousprototypes.com/docs/Log ... c_analyzer

That one is good for 256K samples at up to 20 MHz.  That's a good bit deeper than the OBLS.  At 1 MHz sample rate, you could get some 256ms of trace capture with the logic shrimp.
48
Open Bench Logic Sniffer / Re: I2C 400 KHz + 4 Digital channels recording limits ?
[quote author="neoirto"]Thanks for your very clear reply Qwlciguk,

So I would better choose something like the Saleae Logic, with 10 billions samples (sorry, I can't place an url as a new member) at 119€ ?
Do you know any other model that could match my needings at lower price please ?

When you say :
Quote
There is no mode that allows live "streaming" of data to the host PC. It is a simple 200K storage block.

Does it mean some logic analyzers can send all the channel's data to PC via an USB connection ? Is it what the Saleae Logic does ?

Tx again ;)[/quote]

Yes, it is my understanding that the Saleae Logic devices will stream continuously to the host computer, albeit at 24 MHz max sample rate.  So, in that case, you're limited only by the disk storage available on the host computer.  The OBLS is limited to the internal memory on board its FPGA.

My only direct experience with non-professional logic analyzers is with the OBLS.  In my day job, I regularly use a top of the line Tektronix Logic Analyzer that costs upwards of $180K.
49
Open Bench Logic Sniffer / Re: I2C 400 KHz + 4 Digital channels recording limits ?
[quote author="neoirto"]Hi all,

I'm looking for a logic analyzer to sniff, decode, and record an I2C bus with high traffic at 400 KHz.
In the same data records as I2C, I'd like to record 4-6 Digital channels at the same frequency, and then I'd like to be able to decode :
- I2C traffic between one I2C peripheral (saying 0x04 adress) and his master. In the analyze step, will it be possible to exclude all other peripheral address traffic than Master and 0x04, to be able to only debug my peripheral easily ?
- if not, perharps can I generate a raw recording file I can easily parse and clean later with C program on my own, or even on an Excel sheet (old ways...) ? And after this treatment on my own, will it be possible to re-import this cleaned data for a further graphical analysis ?

In the same data records as I2C, is there any limitation to record 4-6 digital channels during long times (several seconds) ? I heard some sniffer was limited by buffers, and can not record long time data samples ?

I will run under Win 7, if it helps.

Thank you in advance for your answers :)[/quote]

The answer is a little complicated.  The OBLS has some 200K bytes of internal memory storage.  There is no mode that allows live "streaming" of data to the host PC.  It is a simple 200K storage block.  You can capture no more than that.  This 200K storage can be divided up different ways depending on how many channels you're using.  For a simple 8 channel capture, you get a full 200k samples.  If you configure it for 16 or 32 channels, you can capture proportionally less samples.  This is for the standard non-RLE capture mode.  For RLE mode, it only captures data if it changes, though there is a limit even there.  If you configure for 8 bits with RLE, you can capture 200K "changes" in signal.  If the signals are qiescent for a long period of time, the timer rolls over and it consumes a sample anyway.  In 8 bit mode, you get a max of 127 sample clocks before rollover.  So, 1 sample gets recorded every 127 clocks even if there are no changes detected.  In 16 bit mode, you get 32767 clocks before rollover, but of course the total number of samples that can be recorded is cut in half due to the doubling of the channel count.  Similarly for 32 channel mode, the timer rolls over after 2^31 - 1 counts at the current sample clock.

In practice, it's hard to predict which limit you will run up against, "signal changes" or rollovers.

As far as live capture filtering on particular traffic, no the OBLS has no provision to understand anything about I2C and so cannot do any filtering of what gets captured.  That is the job of a proper protocol analyzer.  You can of course, capture everything, export the captured data, post-filter it and reload it back into the client software.

All that said, from your description of what you're trying to do, I predict that the OBLS will not work for you.  Given the low speed of I2C, you'd be better off with one of the commercial low speed streaming logic analyzers available.  Yes, they're more money, but they're more likely to be able to do what you want.
50
USB Infrared Toy / Re: IR Toy firmware v23 tests
[quote author="domi"]Widget mode in V22 and V23 are both erroneous.
Would a version based on the actual V23 once become the next version?
If so are theactual V23 sources available somewhere?

Is there a short description how to compile & link a firmware version?
Is the MinGW Shell appropriate?[/quote]

Based on the comments from Ian:

viewtopic.php?f=29&t=2554&start=30#p48349

It would seem that the JP1 folks (designers/maintainers of the original widget) don't really appreciate anyone messing with their stuff, open source notwithstanding.  That doesn't really encourage the people here to pursue debugging the IR Widget mode.  I modified their precious IR Scope software to automatically put the IR Toy into widget mode, but it was all for naught, as you also discovered, the IR Toy FW with widget mode, does not work correctly.  Since the JP1 folks lost their one and only supplier of the original widget design, you'd think that they'd be receptive to finding an alternative source.  To be exact, they didn't actually lose their supplier, he just had some political axe to grind and jacked up the price to nearly $40 for anyone residing in a state that voted to re-elect Obama president.
52
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="domi"]I am coming back with some results.



Here the value of the 25 first bytes received.
[attachment=0]

And finally, this last picture shows the full 5600 samples,  of which picture 3 represents the beginning of in more detail.
[attachment=1]

Is the Widget mode totally erroneous, of do I miss the basics thereof?
Maybe I have to compare with the firmware USBIRToy_irW.hex . Unfortunately I did not found that firmware yet.[/quote]

I wouldn't say that it is totally erroneous, but you seem to be repeatedly ignore what I've been telling you about widget mode.  I'll say it again.  The standalone widget FW for the IRToy works perfectly.  The all in one FW that includes all of the modes, does not work properly in widget mode.  I'll try to describe again how the widget mode is supposed to work.

Once the port is opened to the widget, nothing will be sent immediately.  The widget waits until it detects an IR pulse from the detector.  As soon as that happens, it opens a 100 us gate time during which it counts the number of pulses received.  At the conclusion of the 100us, it sends the count of pulses detected, to the host computer as a single byte value.  Immediately following the first 100us gate interval, the widget begins counting the number of pulses detected in the following 100us interval.  The part that I forgot to tell you previously, is that it doesn't start the count over at 0, it simply continues counting from the value it had at the end of the previous 100 us period.  That is why you see an increasing value being sent in successive bytes when there are IR pulses present in a given 100 us period.  From your list of values received, you can see that during the first 100us period, there were 3 pulses detected.  Then in the next 100us period, there were 4 additional pulses detected (07 - 03).  Then the next 100us period, there were 4 more pulses detected (0b - 07) and on and on.  Eventually at entry 9, you see that the byte value being sent, stops increasing.  That is, it keeps sending the same value over and over.  This is because starting at entry number 10 thru entry 17, no IR pulses were detected.  That is, there is a gap of 800us during which there were no pulses.  Then starting at entry 18, the pulse count starts increasing again meaning that pulses are again being detected.

So, very roughly, you have a total of 31 pulses detected for the first 900 us of time, followed by 800 us of no pulses, followed by 31 pulses detected during the next 800 us.  This is very rough.  There are more subtleties here, but this is the most basic analysis.  All is for naught though, since a real widget or an IRToy running the standalone widget FW both continuously send the pulse count FOREVER as long as the host computer keeps the port open.  As you've seen and I already saw in my own tests, the IRToy FW that includes all modes, does not keep sending continuously, but rather stops for no obvious reason aside from a FW bug.

Conclusion: Widget mode in the IRToy FW including all modes, is not functional in any useful way.  If you must have widget mode working, you must use the standalone widget FW for the IRToy.  There, it works perfectly.  Unless you just want to rediscover gravity, there isn't any reason not to use the existing IRScope software.  It is very well developed and refined, though not perfect.  It has extensive capabilities to analyze the protocol via the JP1 community's IRdecode.dll software.  If you really want to re-invent the wheel, by all means go ahead and develop your own software to do all of this.
53
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="domi"]The firmware, as shipped with the IRT and I used until now, was V212. I had not yet realized it was an older one.
Now I updated the firmware to V222 which gives better results.
Indeed e.g. IRIO Raw mode has disappeared, but Widget mode has appeared, and I got data using that widget mode:

Set DTR and RTS, then send 'p'.

The data I get back is about 1500 bytes, which however I could not get it in IRScope yet.
Sample and SUMP modes seem also to work OK.

I investigate further.[/quote]

The data you get back from a real widget or the IRToy running the widget only firmware, will not end.  It will continue on forever until you close the port.  The fact that you only got 1500 bytes back is consistent with what I saw.  That is, it works for a short time and then just quits when it should continue sending continuously until you close the port.

As for getting the data that you did receive into IRScope, normally IRScope software takes the raw data stream received directly from the port and processes into a different format that is then saved to a .ict format file which does not even remotely resemble the captured data stream.  It is just a text file something like this:

Code: [Select]
irscope 0
carrier_frequency 36060
sample_count 256
+2639,96
-892
+443,16
-446
+443,16
-447
+443,16
-891
+443,16
-892
+1332,48
-892
+443,16
-446
+443,16
-447
+443,16
-419
+443,16
-446
+443,16
-447
+443,16
-446
+444,16
-446
+443,16
-447
+443,16
-446
+443,16
-447
+888,32
-446
+443,16
-447
+443,16
-419
+443,16
-891
+888,32
-446
+444,16
-446
+443,16
-891
+888,32
-892
+443,16
-446
+443,16
-447
+443,16
-446
+861,32
-891
+888,32
-891
+443,16
-447
+443,16
-446
+443,16
-69363
+2667,96
-891
+444,16
-446
+443,16
-447
+443,16
-891
+443,16
-891
+1305,48
-892
+443,16
-446
+443,16
-447
+443,16
-446
+444,16
-446
+443,16
-447
+443,16
-446
+443,16
-447
+443,16
-446
+444,16
-446
+415,16
-447
+888,32
-446
+443,16
-447
+443,16
-446
+444,16
-891
+888,32
-446
+443,16
-447
+443,16
-891
+888,32
-864
+443,16
-446
+443,16
-447
+443,16
-446
+888,32
-892
+888,32
-891
+443,16
-446
+444,16
-446
+443,16
-69363
+2667,96
-891
+443,16
-447
+443,16
-419
+443,16
-891
+443,16
-891
+1333,48
-891
+444,16
-446
+443,16
-447
+443,16
-446
+443,16
-447
+443,16
-419
+443,16
-446
+443,16
-447
+443,16
-446
+444,16
-446
+443,16
-447
+888,32
-446
+443,16
-447
+443,16
-446
+443,16
-892
+888,32
-418
+443,16
-447
+443,16
-891
+888,32
-891
+444,16
-446
+443,16
-447
+443,16
-446
+888,32
-891
+888,32
-864
+443,16
-446
+444,16
-446
+443,16
-69363
+2667,96
-891
+443,16
-447
+443,16
-446
+444,16
-891
+443,16
-891
+1333,48
-891
+443,16
-419
+443,16
-447
+443,16
-446
+443,16
-447
+443,16
-446
+444,16
-446
+443,16
-447
+443,16
-446
+443,16
-447
+443,16
-446
+888,32
-447
+415,16
-447
+443,16
-446
+443,16
-892
+888,32
-446
+443,16
-447
+443,16
-891
+888,32
-891
+443,16
-447
+443,16
-419
+443,16
-446
+888,32
-891
+888,32
-892
+443,16
-446
+443,16
-447
+443,16
-47928

One of the trickiest things that IRScope software does in processing the data stream from the widget is to determine the pulse frequency.  Once it has that (assumes a constant frequency), it calculates the burst on/off times and saves the on times with pulse count for "on" bursts in the .ict file along with the "off" times on alternating lines in the .ict file.

So, you would need to replicate what the IRScope software does in creating the .ict file, in order to be able to import the data into IRScope.  If I remember correctly, you can also import Pronto format data and the JP1 learned format data via pasting into the import window in IRScope.  Both formats are documented, Pronto quite a bit better than JP1 learned format.  I am the author of one document describing the JP1 IR format.  I'll hunt up a link to it if you want to pursue this.

In any case, this is all for naught, as the integrated FW containing the widget mode is broken.  The standalone widget only FW for the IRToy works perfectly, but it's very inconvenient to have to reflash back and forth between the FWs just because you want to use the IRToy as a widget and all the other IRToy modes.  I considered just buying another IRToy so that I could have one IRToy for widget mode and another for everything else, but I already have built my own hardware based widget and don't have any need for another one.  So, my IRToy stays running IRToy standard FW.
54
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="domi"]Thanks Qwlciguk.

Maybe another question. Where can I find the contents of the output in the different operation modes.

6- IRWidget mode(P), with two flavors: Frequency and Time. Here different viewpoints seem causing trouble yet.

What are the fundamental differences between the protocols of these modes? Which of all these modes is the most versatile to analyse IR codes ?

All this will take me a lot of time and therefore taking a good start will result in time saving later on.[/quote]

I don't know much about any of the modes except the frequency protocol of the widget mode.  That, is very simple.  Once you enter frequency sub-mode of widget mode via the proper DTR/RTS sequencing, nothing will be output immediately.  It will wait until an infrared pulse is detected and accumulate the count of pulses for 100 usec.  At the end of 100 usec, it will send a single byte containing the number of pulses detected.  A new 100 usec period will then start and count the number of pulses detected and at the end of 100 usec, send the count for that period.  This will be repeated until the host computer closes the port.  It is the responsibility of the host computer to take the stream of bytes with the pulse counts and reconstruct the original signal and do the protocol analysis via decodeir.dll  The "time" mode of IR Widget is generally deprecated, as it was found to not be sufficiently accurate for the detailed analysis needed by the JP1 community.  Pretty much anything you can do with time mode, you can do better with frequency mode.
55
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="domi"]I am new here so apoligize for my poor detailed understanding of the following.

I am actually try to decode IR protocols from various remotes, specially to understand which codes are used on a remote of Telenet (Belgian provider) digibox in order to play them back e.g. from a PC.
As the goal is ultimately using th IRT Decode mode, I am playing with all modes to better understand the behaviour and richness of the IRT for the time being.


One one hand I test the IRT through its basic commands: codes sent (TX) and responses or data Received (RX).
So everything should work through a Terminal emulator. I use Hercules 3.2.6 and Realterm 2.0.0 70 and thats already very nice.

I understand this is not the most functional approach, but clearly the basic one.

Once for a certain mode I see results from this basic approach, I step further into applications as OLS, and IRSCOPE.
So I am now stranded at the IRScope2 hoping to use their protocol decoding expertise and share mine.

But I am stuck in connecting IRT to IRSCope.

I read that there has been a special firmware USBIRToy_irW.hex which successfully linked to IRScope. However it was not distributed in the IRT V2.2 package, therefore I assume this is not the preferred way to go. Also two firmwares to flash and re-flash is not ideal.
But I also read that the IRT firmware has a mode called IR Widget mode (ascii command 'P' or 'p') although that mode is not described in the actual firmware V2.2 documentation http://dangerousprototypes.com/docs/USB ... _protocols

Once in this forum there was a discussion point that switching from one application to another application on the same COM-connection would reset the IRT in its default Decode mode. This seems not to be the case. Indeed I tested the Raw IR mode (ascii command 'x') from Hercules. Closed the connection. Reopened the connection, and the IRT still was in its Raw IR mode.

Building on this I sent a 'p' through Hercules, closed the connection, and opened that same COM port with the IRScope. Unfortunately nothing happens. The IRScope does not see any input. Has this sometning to do with DTR or RTS ?

Has anybody ever successfully used the IRToy firmware (V2.2) in IR Widget mode?
Feedback greatly appreciated.[/quote]

I had modified the IRScope software to automatically send the 'p' to switch into widget mode when it opens the connection.  That part worked ok, but when capturing an actual IR transmission, the FW would send a few dozen bytes and then wedge itself such that it no longer responded to anything aside from disconnecting the IRToy from the USB cable and reconnecting it.  I don't know what was wrong, but I wasn't keen on debugging it and no one else seemed interested at all.  So, I dropped it.  I was hoping to provide an alternative source for working widgets to the JP1 community since the primary widget supplier was somewhat unhappy.  Running the alternative "widget only" FW would work fine for the JP1 folks, but since the IRToy is not delivered with that FW or even the FW that included the 'p' switch to widget mode, it was a dealbreaker for JP1 folks that were not going to be able to fiddle with updating the FW for the IRToy. That is all not to mention, being discouraged here not to mess with the admittedly open source code for IRScope even if it was going to be backward compatible.

Also, yes the widget FW absolutely relies on IRscope sequencing of DTR and RTS to know which widget mode to use, since there are 2 different modes.  It has been many months since I was playing with this.  So, I don't remember the details, but it is not so hard to find in the IRScope source code.
56
USB Infrared Toy / Re: Use communication RS232/TTL ??
[quote author="tech"]Hi,

I wonder if it is possible to use a microprocessor and use communication RS232/TTL RX & TX to communicate with the USB Infrared Toy?

Thank you for yours help!

Chris[/quote]

The IR Toy FW has been ported to various PICs that can comm via simple TTL level RS232.  Perhaps even the IR Toy itself can be used that way.  I don't know offhand.
58
USB Infrared Toy / Re: Cost saving idea for v3
[quote author="NiHaoMike"]Reading through the documentation for the USB Infrared Toy (I'm planning to build a version to integrate into a PC), I noted that the sensor added for frequency detection is quite expensive. Since it's only used for learning remotes (don't need much range), maybe it can be replaced with a cheaper device? Maybe a plain phototransistor or photodiode would work well. Or maybe add a 10k or so resistor across the IR LED and AC couple it through a single transistor amplifier. (I have actually seen that used in a learning remote.)[/quote]

I don't know how much cheaper it could be considering Avent has them for 37 cents in single unit quantities.  I expect that Seed should be able to source these for less than 20 cents each in their part of the world.
59
USB Infrared Toy / Re: USB Infrared Toy and IRScope
[quote author="secany"]Hi guys,
I've just bought IRToy yesterday. My target is trying to capture IR signal to pronto format then import to Bang Olufsen Beo6 remote. Any suggestion?
Based on some reading on forum, there is a firmware for IR Toy to use with IR scope. Do any of you still have it? Can I have it please? Thank you.[/quote]

It is here:

viewtopic.php?f=29&t=2554&start=30#p48238

The current version of the IRToy FW technically has support for IRScope mode, though it requires a modification to the IRScope software to enter that mode, which I have done, but there is some issue in the IRToy FW that prevents it all from working correctly.  In any case, the FW linked above works perfectly with the standard IRScope software.  It provides none of the other features present in the normal IRToy FW.  It's a bit of a pain to re-flash back and forth, but it can be done.
60
USB Infrared Toy / Re: Irtoy driver windows 7 64 bits
[quote author="Carl_electro"]I've been using Winlirc and IRtoy for quite a while without problem with windows 7 32 bits.
I have upgraded to windows 7 64 bits and I am now unable to communicate with winlirc via tcp.
Winlirc is working alright but will not listen to my tcp command. I tested it at work with win7 32 bits and it's working fine.
I even suspect the driver (version 5.1.2600) to be the problem of my BSOD.

Could someone post the link of the correct CDC driver.
I really have a hard time to find it on the website.[/quote]

The "driver", really just an inf file, is in the zipfile at:

http://dangerous-prototypes-open-hardwa ... ge.v22.zip

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