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

46
Client software / Re: Jawi's Logic Sniffer client software - releases
Hi Jawi. I have something.

In LogicSnifferConfig.java

Code: [Select]
  /**
  * Returns whether or not the device returns its samples in "reverse" order.
  *
  * @return <code>true</code> if the samples are returned in reverse order,
  *        <code>false</code> otherwise.
  */
  public boolean isSamplesInReverseOrder()
  {

    if ( this.deviceProfile != null )
    {
      return this.deviceProfile.isSamplesInReverseOrder();
    }
      return true;  //false;
  }

Changing the default return to true when the this.deviceProfile is null causes the samples to be shown FIFO as I require. When it is false they are always displayed FILO. The setting in the cfg file is never returned. I will not begin to pretend I know anything about java its classes to guess why.

What we can be sure about is that  this.deviceProfile  is null. Other properties that are accessed in the same manner from LogicSnifferAcquisitionTask.java also appear to be broken in 0.9.6 though they worked in 0.9.5.

I also came across a couple other little oddity.

In LogicSnifferAcquisitionTask.java your code to reverse the buffer is in:

Code: [Select]
  private int readSamples( int aSampleIdx, final int[] aBuffer ) throws IOException, InterruptedException

However it cannot really go there because this function is called twice. Once in awaitTrigger( buffer ); and then again a few lines later. This means the first sample is moved on its own and then finally overridden by the last sample.

I commented out that part of the code and instead added this in:

Code: [Select]
public AcquisitionResult call() throws IOException, InterruptedException:

    // read all other samples
    sampleIdx = readSamples( sampleIdx, buffer );

+        // In case the device sends its samples in "reverse" order, we need to
+     // revert it now, before processing them further...
+     if ( this.config.isSamplesInReverseOrder() )
+     {
+       HostUtils.reverse( buffer ); 
+  }

Well that is as far as I can go with it. Seems I did something that broke the tests and while a compile works I no longer can create a package.  Any way, I got a version that works the way I need it to so I can continue with all the firmware.

edit (JaWi): added some code blocks to aid readability...
47
USB Infrared Toy / Re: irrecord. does it work?
Well I am happy to say and I'm sure you will be happy to hear that it is all working now. Even firmware V22 that was not working before is working. I have no clear explanation for this given I know that there have not been any changes made to the firmware, none, zip, nadda, etc... I do have a theory that the problem is related to "other software" that had been run with the IR TOY previously. Today, I had not used that software and it is working. Right now I don't care to try to prove this as so much time had been spent already.... I am just happy that it is working and the new firmware now is passing every test beautifully.

Thanks for your time Dukey.
49
USB Infrared Toy / Critical bug in REC and PLAY
It is so dangerous delete any copy you have and use the attached .exe. Bad BAD BAD!

Good 'n'
01A6 00D2 001B 0019 001D 0018 001D 0018 
001B 001A 001B 0019 001C 0017 001C 001A
001C 0017 001E 004C 001D 004D 001B 004E
001D 004D 001C 004C 001C 004E 001D 0018
001A 004E 001D 0017 001C 004E 001D 004C
001D 0018 001D 0017 001C 001A 001C 0018
001D 0018 001B 004D 001E 0018 001B 001A
001B 004D 001B 004D 001E 004C 001D 004C
001C 004E 001D 077E 01A5 0068 001D FFFF

Bad 'n'
00A6 00D2 001B 0019 001D 0018 001D 0018
001B 001A 001B 0019 001C 0017 001C 001A
001C 0017 001E 004C 001D 004D 001B 004E
001D 004D 001C 004C 001C 004E 001D 0018
001A 004E 001D 0017 001C 004E 001D 004C
001D 0018 001D 0017 001C 001A 001C 0018
001D 0018 001B 004D 001E 0018 001B 001A
001B 004D 001B 004D 001E 004C 001D 004C
001C 004E 001D 007E 00A5 0068 001D FFFF

Sorry I am not sure how to compile for other OSes.

The updated source code will be part of a complete new IR TOY release soonish. Let me know if you need the beta source to compile for Linux etc in the meantime.
50
Client software / Re: Jawi's Logic Sniffer client software - releases
Ok, I tested all the versions I could download and this problem started with 0.9.6-B1. All of the 0.9.5 series worked.

I noticed in the source code that for the device.samples.reverseOrder you used a rawValue label where as all other true or false settings (that work, I tested them) use "value. I cannot see how this would have any effect though. It is just a label right?
51
USB Infrared Toy / Re: Bug in winlirc
Complied no problems with VS++ 8 and I will use this DLL in all further testing to make sure she is alright. Thanks
52
Project development, ideas, and suggestions / Re: USB Isochrnous Transfer Mode
[quote author="andersm"]Bulk transfers will use all bandwidth not allocated to other transfers. Unless you load the bus with other devices that won't be an issue.[/quote]

That is correct, and in fact bulk can actually be quicker if you do not load the bus. If you do the math on your requirements you will see that you only need two bulk packets per frame and this is not hard to achieve and as a tip you can use the CDC functions in our stack to do generic bulk.

I intend to release a generic bulk class in the next package that will use these functions but in the meantime it is not hard to copy microchip's FSUSB (generic bulk) descriptors tweaking it here are there.

Given that bulk is so much easier to get up and running and has a very high probable chance of meeting your requirements, that is where I would start.
53
USB Infrared Toy / Re: IR Toy firmware v23 tests
Forget that version. It has a number of coding errors. In fact there was one each in SUMP irS and irWidget. One each was enough to break it badly. These have been sorted out and there is new firmware that is been rather extensively tested. When that hits the shelves then do upgrade to that as it really sorts out a rather interesting timing problem that has slipped through unnoticed and there are rumors of a functional Easter egg that I cannot confirm or deny.
54
Client software / Re: Jawi's Logic Sniffer client software - releases
Hi Jawi, thanks for the links. I have downloaded and tried the latest and followed your suggestion about leaving the client running. It is certifiably clear that the device.samples.reverseOrder = no longer works. It worked in 0.9.5-b2 but then stopped working sometime between then and 0.9.6-b3.

Apart from that the IR TOY and it work together really well and I have not had one dud transfer.

When you IR TOY arrives I will send you the cfg files and the latest firmware that works supremely well and hopefully something may make sense as to what has happened to the  device.samples.reverseOrder thingy.
56
USB Infrared Toy / Re: Bug in winlirc
Yes, please remove the 's' in the place I mentioned. I will vouch for that change being correct and my altered DLL is working fine.

Removing that 's' will allow the IR TOY and any PC APP to easily resync if they get out of wack as I can treat any redundant 's' exactly the same as if it were a new irS mode entry.

Thanks for your response.
57
USB Infrared Toy / Re: irrecord. does it work?
Thanks for your feedback and vote of confidence in winlirc. All my remotes are NEC protocol (38kHz) and it is difficult to press a key without at least one repeat code being sent (0.1 seconds) I wonder if that is the problem. ???

Using REC and PLAY and outputting to OLS format and comparing the waveforms by hand I have satisfied myself that the IR TOY is now sampling the remotes correctly and that was my aim. I did find a couple of bugs in the firmware and one in rec and play so it was time well spent.

Even it there is some oddball problem somewhere, and as you said, it is not as if there are not many prerolled cfg files for the NEC protocol.
58
Client software / Re: Jawi's Logic Sniffer client software - releases
Jawi, attached are OLS dumps for both the LS and IR TOY with device.samples.reverseOrder = false and device.samples.reverseOrder = true as marked. These dumps show that the samples are always displayed the same regardless of the true or false setting.

This was not true in previous versions.  Attached is a dump showing that the samples are being displayed FIFO with device.samples.reverseOrder = true with 0.9.5-b2.

No there were not trailing spaces, the text editor removes them when the file is saved and I double checked. All changes occurred with the OLS client not loaded.

Re the usb stack to OLS port. This was done and posted many months ago now. However as Ian doesn't have access to the OLS github he could not post it there ans so far no one has provided any feedback on the version I posted myself.

In fact all the DP usb projects have been ported but the LS, serial LCD have not been tested or updated on the DP web site. I will be hosting all these changes I have done on my own web site and a new package will be available as soon as I get time to test all the hardware myself.
59
Client software / Re: Jawi's Logic Sniffer client software - releases
[quote author="jawi"][quote author="JTR"]Jawi, The new client looks really good and has some nice features added. I gave it a try out and found that the device.samples.reverseOrder  mode option for the IR TOY does not work any more.  The client always shows the output in reverse mode regardless of the setting. Somewhere between ols-0.9.5-b2 and ols-0.9.6-b3 this feature got broken.

(It appears to be broken on the logic shrimp too...)

Also noted that the comment in the cfg file is still opposite to the function.[/quote]

For my understanding: is the IRToy also spitting out its samples in reverse order (first sample first)? The profile in the client seems to tell me otherwise...
I'll take a look at what caused the reversing to go wrong, have to dust off my LogicShrimp for that ;)
[/quote]

There are two different SUMP modes on the IR TOY depending on firmware revision. The legacy mode was simply a one channel mode that rotated the IR RAW bit into a byte and stored in in the PICs RAM. Then in sump mode it unwrapped the packed bytes into one byte per bit and sent then off to the SUMP client. This was done in what I would call reverse order, last sample sent first. From the point of view of the legacy SUMP operation that would appear as not reversed (from the original SUMP spec.) The old method is LIFO

How about we stick to LIFO and FIFO so we both are on the same page.

When the IR TOY was ported to our stack and the double buffer mode employed there no longer was a need to store the samples in the PIC. They can be (and are) sent in real time and each are a full byte in width (All of PORT B). This is the JTR-SUMP mode and it is FIFO in real time. Currently I am sampling at 100kHz Bytes without problem and I think 200kHz is doable, just having tried to red line it yet.

Previously your client allowed for the FIFO mode if reverse order was set to TRUE. (However that does not match the comment in the CFG file.) The latest client does not allow this anymore, it is fixed in LIFO mode regardless of the setting in the CFG file.

As a guess it would seem to me that when you added the logic shrimp you hardcoded the LIFO mode as this makes sense for the Logic Shrimp. Perhaps, forgetting about the new IR TOY mode you did the same there too. Just a guess mind you...
 
[quote author="jawi"]
[quote author="JTR"]Finally, did you ever implement  the infinite samples mode that was floated quite some time ago now?[/quote]

By "infinite samples" you mean continuous sampling mode, or an infinite buffer? The latter will only work for very low sampling frequencies (< 100kHz IIRC), based on some crude tests I've done. As for the first: not for this release; I'm planning for the next release to do some rewriting on the acquisition logic, so this could probably be one of the new features. But, first lets get the 0.9.6 final...![/quote]

What I mean by infinite is real time storage on the PC RAM / hard drive. Realistically infinite means 65536 * 64 bytes as far as the IRTOY goes (currently) as the packet count is an unsigned  int. However there is no reason why it cannot be infinitely variable. That is sample until key stroke. This can be implemented for the OLS too.

I cannot see any reason why the OLS cannot sample like this @ 2Mb/s if / when the replacement USB stack is made official. It is much faster than the microchip stack. 2Mb/s is only 4 bulk packets per frame (from 19 maximum possible) and this is doable. Might need to green wire the OLS to improve the bandwidth between the PIC and FPGA but like you said, let get the current stuff working first. :)
60
USB Infrared Toy / irrecord. does it work?
Is anyone having any success with irrecord and the IR TOY? I have tried with the latest irrecord and various IR TOY firmwares and it almost always gives a "something went wrong" message when I try to record the actual keys. Occasionally it does receive  a key on a retry.

Up until that point it works correctly. I have used the -f option and that did not help.

I have everything working on the new IR TOY firmware and this is the only thing that is not working correctly. All my other tests show that the firmware is working correctly and in any case the same issue is happening with V22 firmware.

There is no problem using irgraph or rec and play or anything untoward visible with terminal software. It is just irrecord so I am wondering has anyone got this to work (on windows) or is there a problem with irrecord itself?

Edit: This was with the official IRTOY  DLL and not with my modified DLL.

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