Author Topic: Question about FLIR One for Android  (Read 173730 times)

0 Members and 2 Guests are viewing this topic.

Offline Ben321

  • Frequent Contributor
  • **
  • Posts: 506
Question about FLIR One for Android
« on: October 04, 2015, 03:12:39 am »
Now that FLIR has finally released it (not just for pre-sale anymore), has anybody managed to make a USB driver for Windows for it yet? I remember with the Seek Thermal imager, somebody managed to (after connecting it to their PC's USB port, via a USB-A to micro-USB cable) create Windows drivers for it, so that it was usable on the PC as a webcam. Has anybody yet managed to do the same thing with the FLIR One for Android, which (like the Seek Thermal) has a micro-USB connector on it?
 

Offline Ben321

  • Frequent Contributor
  • **
  • Posts: 506
Re: Question about FLIR One for Android
« Reply #1 on: October 05, 2015, 12:02:50 am »
50 views and no replies? I think there was an entire thread, several pages long, regarding 3rd party drivers for the Seek Thermal imager. I'd think this would be a hot topic, but nobody has replied yet. I'd think somebody would be trying to accomplish the same thing with the FLIR One for Android, but there seems to be little interest, as evidenced by the fact that this thread is on the second page of the Test Equipment section, and yet has no replies (other than the one I'm posting now, for the purpose of putting it back on the first page).
 

Offline encryptededdy

  • Frequent Contributor
  • **
  • Posts: 358
  • Country: nz
Re: Question about FLIR One for Android
« Reply #2 on: October 05, 2015, 01:40:42 am »
I think due to the use of a Lepton sensor, those who are interesting in integrating thermal imaging into some kind of product or for some kind of static PC-connected setup are just waiting for FLIR to officially release the Lepton 3 for sale. We already know PureEngineering/GroupGets has their hands on a Lepton 3 module and developed a USB <-> Lepton 3 interface board. https://vine.co/v/edPq5ZD9aO7



Also I can't see much use in connecting the FLIR One Gen 2 to a PC... with the Seek we could use it to increase image quality, fix the gradient, and get raw data out. However with the FLIR One I doubt there's much to be improved on in terms of IQ (due to FLIR's already heavy image processing done in-module) and it also saves radiometric JPEGs with full raw data.
 

Offline Ben321

  • Frequent Contributor
  • **
  • Posts: 506
Re: Question about FLIR One for Android
« Reply #3 on: October 05, 2015, 05:53:52 am »
I think due to the use of a Lepton sensor, those who are interesting in integrating thermal imaging into some kind of product or for some kind of static PC-connected setup are just waiting for FLIR to officially release the Lepton 3 for sale. We already know PureEngineering/GroupGets has their hands on a Lepton 3 module and developed a USB <-> Lepton 3 interface board. https://vine.co/v/edPq5ZD9aO7



Also I can't see much use in connecting the FLIR One Gen 2 to a PC... with the Seek we could use it to increase image quality, fix the gradient, and get raw data out. However with the FLIR One I doubt there's much to be improved on in terms of IQ (due to FLIR's already heavy image processing done in-module) and it also saves radiometric JPEGs with full raw data.

Even so, for those who want a simple way of doing it, without soldering (as you would need to do with the USB interface board you have been speaking of), having an already existing module (like the FLIR One for Android) would be a great thing. Also, you can get raw, unprocessed thermal image, if you create your own reverse engineered driver for the FLIR One for Android on the PC. And I want that raw, unprocessed data, and I don't want to have to use a soldered project board (like the one you were talking about) to do it. Using a PC driver created from info gathered by reverse engineering it the FLIR One for Android, I would be able to use an already assembled thermal module, that costs very little money, and requires absolutely ZERO soldering, in order to capture true thermal images. So consider this thread a request to all reverse engineers out there, to get on with reverse engineering the FLIR One for Android, so that I will be able to use it ultimately as a thermal webcam for doing all kinds of fun experiments.

One of the things about using the official software on an Android device is that it resizes the thermal image prior to embedding it in a JPEG. You see, the "FLIR One for Android"'s actual output is a 160x120 thermal image that comes out of the USB port, and is then processes by the FLIR One app on an Android device. Part of the processing is to interpolate the 160x120 thermal raw pixels to a 320x240 image. This interpolation is done prior to saving in the radiometric JPEG file, but it is done by the app, NOT by the microcontroller in the "FLIR One for Android" hardware (or at least I hope that's the case). If you can reverse engineer the USB communication protocol used by the FLIR One for Android, and then write your own driver for it for a PC, you SHOULD be able to access the truly RAW (160x120) thermal pixels data stream from the device. As nice as it is to have an image that is bigger than 160x120, doubling the resolution to 320x240 is in effect falsifying scientific data, meaning that it's basically useless for anything other than taking thermal pictures for fun. At this point, saving it as a thermometric JPEG image (as if the data was scientifically valid) is a quite deceptive practice. It give the false impression that the data is actually useful for measuring real temperatures. It is not. It only gives you APPROXIMATE temperatures (which any true scientist would laugh at).

But if I can access (via PC drivers, created through reverse engineering), the actual 160x120 raw thermal image data, I will have my hands on actual usable scientific data. And I will be guarantied that the temperatures calculated from this data are completely accurate.

And by the way, I've never heard of a Lepton 3. I haven't even heard of a Lepton 2. I've just heard of a Lepton, and that the new version with double the horizontal and vertical resolution (160x120, instead of 80x60) is still just called the Lepton. FLIR does not seem to number its newer versions of cores. I can't find any official naming of the Lepton 3 on FLIR's website.
« Last Edit: October 05, 2015, 06:01:08 am by Ben321 »
 

Offline encryptededdy

  • Frequent Contributor
  • **
  • Posts: 358
  • Country: nz
Re: Question about FLIR One for Android
« Reply #4 on: October 05, 2015, 06:25:17 am »
Lepton 2 is the 80x60 one we currently have access to. Lepton 3 is the new 160x120 one. They appear to be just internal FLIR names, so you won't find them on the FLIR website. See this document.

At least groupget's previous breakout boards were all sold pre-soldered and ready to use. See: https://groupgets.com/manufacturers/groupgets-labs/products/flir-lepton-breakout-board-v1-4

Here is the full datasheet for Lepton 3: http://media.wix.com/ugd/53cdb6_5191be73d1c943d78d2e1a095cb7f3b8.pdf

According to that, the Lepton 3 does output 160x120 data over voSPI (page 38), so the upscaling must be done in the app or the hardware of the FLIR One.

To be honest, I don't understand your issue with the upscaling. While it's true that native resolution data is the most optimal, if we consider the issues with sharpness on the Lepton's lens (see the FLIR One G2 actual resolution thread) making the sensor only resolve details similarly to a ~120x90 sensor (even though the sensor really is 160x120) and the fact that the Lepton's temperature accuracy is ±2 degrees C, I doubt the upscaling makes any appreciable difference to the observed accuracy of the temperature readings.
 

Offline Ben321

  • Frequent Contributor
  • **
  • Posts: 506
Re: Question about FLIR One for Android
« Reply #5 on: October 05, 2015, 06:30:22 am »
Lepton 2 is the 80x60 one we currently have access to. Lepton 3 is the new 160x120 one. They appear to be just internal FLIR names, so you won't find them on the FLIR website. See this document.

At least groupget's previous breakout boards were all sold pre-soldered and ready to use. See: https://groupgets.com/manufacturers/groupgets-labs/products/flir-lepton-breakout-board-v1-4

Here is the full datasheet for Lepton 3: http://media.wix.com/ugd/53cdb6_5191be73d1c943d78d2e1a095cb7f3b8.pdf

According to that, the Lepton 3 does output 160x120 data over voSPI (page 38), so the upscaling must be done in the app or the hardware of the FLIR One.

To be honest, I don't understand your issue with the upscaling. While it's true that native resolution data is the most optimal, if we consider the issues with sharpness on the Lepton's lens (see the FLIR One G2 actual resolution thread) making the sensor only resolve details similarly to a ~120x90 sensor (even though the sensor really is 160x120) and the fact that the Lepton's temperature accuracy is ±2 degrees C, I doubt the upscaling makes any appreciable difference to the observed accuracy of the temperature readings.

Do you have the software programming skills needed to write a driver for me, that will let me use a FLIR One for Android as a webcam on my PC? If so, please write this driver for me. I have no interest in building a thermal webcam from scratch, by soldering together a project board like the one mentioned in an above post. It should ideally be a VFW (video for windows) driver, as I have recently discovered how to control webcams in Visual Basic 6, using VFW drivers.
 

Offline encryptededdy

  • Frequent Contributor
  • **
  • Posts: 358
  • Country: nz
Re: Question about FLIR One for Android
« Reply #6 on: October 05, 2015, 06:48:06 am »
I literally just said that no soldering is required (at least for the previous boards they've shipped).

I don't have a skills to write a driver, and I also don't have access to the FLIR One gen 2 at this time.

I think your best bet is to wait until Groupgets release their USB interface board. I'm sure it will come with sample software that you can use.
 

Offline Ben321

  • Frequent Contributor
  • **
  • Posts: 506
Re: Question about FLIR One for Android
« Reply #7 on: October 06, 2015, 04:04:51 am »
I literally just said that no soldering is required (at least for the previous boards they've shipped).

I don't have a skills to write a driver, and I also don't have access to the FLIR One gen 2 at this time.

I think your best bet is to wait until Groupgets release their USB interface board. I'm sure it will come with sample software that you can use.

As far as I know, the only Lepton chip being sold as a separate component is the old one with 80x60 resolution. The new one with 160x120 resolution is not yet being sold to the public, and is only found inside gen-2 FLIR One units. Are you aware of any plans FLIR has to sell the new Lepton chip as a separate component?
 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #8 on: October 06, 2015, 05:11:32 pm »
50 views and no replies? I think there was an entire thread, several pages long, regarding 3rd party drivers for the Seek Thermal imager. I'd think this would be a hot topic, but nobody has replied yet.

The only reason why there is no discussion, is the lack of a Flir One G2 camera.
In Germany no trader can deliver this part.
The combination of a thermal camera with an automatic shutter and a real camera is a nice feature for robotics, spy cams and another hacker toys.

You can download the Flir One SDK and study the interesting docs and the code sample.
There is a precompiled flir library for Arm7 CPU. This is the only part which needs reverse engineering  :)

Until now we only know the similar USB announcements from Flir and Seek cameras (iAP Interface)

see my post here
https://www.eevblog.com/forum/testgear/new-flir-products/msg750352/#msg750352
« Last Edit: October 06, 2015, 05:16:12 pm by tomas123 »
 

Offline Ben321

  • Frequent Contributor
  • **
  • Posts: 506
Re: Question about FLIR One for Android
« Reply #9 on: October 07, 2015, 03:11:03 am »
50 views and no replies? I think there was an entire thread, several pages long, regarding 3rd party drivers for the Seek Thermal imager. I'd think this would be a hot topic, but nobody has replied yet.

The only reason why there is no discussion, is the lack of a Flir One G2 camera.
In Germany no trader can deliver this part.
The combination of a thermal camera with an automatic shutter and a real camera is a nice feature for robotics, spy cams and another hacker toys.

You can download the Flir One SDK and study the interesting docs and the code sample.
There is a precompiled flir library for Arm7 CPU. This is the only part which needs reverse engineering  :)

Until now we only know the similar USB announcements from Flir and Seek cameras (iAP Interface)

see my post here
https://www.eevblog.com/forum/testgear/new-flir-products/msg750352/#msg750352

But there's lots of other discussion of FLIR products here, why not a lot about the FLIR One version2? I believe it can be sold in Germany too, by the way. It is only 9 frames per second, which means that it is not prevented from being sold outside the USA by ITAR. Besides, there's lots of people on these forums from many places in the world, including the USA.

If I buy one of these FLIR One for Android units for $250, I won't want to have to buy a separate chip (another $150) plus a project board in order to use it on a PC. I will want to use one unit (the one I spent $250 for) to be able to work on both the PC and android. So that's why I want to see some reverse engineering project going on regarding the FLIR One for Android.
 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #10 on: October 07, 2015, 10:12:53 am »
I believe it can be sold in Germany too, by the way.

Yes, it's shipped from Flir UK to Germany. But if I want a regular bill with germany VAT then I need a germany Flir distributor.
Flir moved the deliver date to the germany distributors from end of september to november.
« Last Edit: October 07, 2015, 10:15:26 am by tomas123 »
 

Offline cynfab

  • Regular Contributor
  • *
  • Posts: 150
Re: Question about FLIR One for Android
« Reply #11 on: October 07, 2015, 01:53:06 pm »
There is some RE going on, just not as obvious as in the early E4 and Seek days.

Attached is a annotated dump of the first few seconds of usb activity between a F1G2 and the F1 Android app.
It's not finished.
There may be inaccuracies.
There is much more to uncover.
This is a long way from a stand alone PC program.
Your mileage may vary.
blah, blah, blah.
 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #12 on: October 07, 2015, 10:43:06 pm »
very intersting  :-+
How do you got the datas from a android handy?
« Last Edit: October 07, 2015, 10:54:42 pm by tomas123 »
 

Offline cynfab

  • Regular Contributor
  • *
  • Posts: 150
Re: Question about FLIR One for Android
« Reply #13 on: October 07, 2015, 10:47:17 pm »
I used my handy USB analyzer in series with the F1 and my tablet running F1 app.
 

Offline cynfab

  • Regular Contributor
  • *
  • Posts: 150
Re: Question about FLIR One for Android
« Reply #14 on: October 07, 2015, 10:57:20 pm »
Guess I can't add a picture after the fact...

 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #15 on: October 07, 2015, 11:06:57 pm »
Thank you, but which nice hardware is this? (altium is a PCB design software)
« Last Edit: October 07, 2015, 11:09:25 pm by tomas123 »
 

Offline cynfab

  • Regular Contributor
  • *
  • Posts: 150
Re: Question about FLIR One for Android
« Reply #16 on: October 07, 2015, 11:26:01 pm »
Sorry, forgot to add the link:

http://openvizsla.org/

Part of a KickStarter campaign, took many years to get the hardware, but it finally arrived, and works too!
Though it does take a bit of fiddling, and there is no nice GUI.

 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #17 on: October 08, 2015, 09:49:30 am »
really nice hardware :-+

as you posted here
https://www.eevblog.com/forum/testgear/new-flir-products/msg752703/#msg752703
it's possible to run the Flir Tools under Chrome with ARChon

I succesfull tested it!!
That's great, because the Flir Apps don't run under Android Studio because there is a precompiled library libflirsdk.so for armeabi-v7a.
There is is same problem with the Flir One SDK.

Unfortunately as yet I haven't a Flir One Android and can't test it: (I'm waiting for delivery).
It is possible to greb the USB traffic between camera and app (under Chrome+ARChon) with a "normal" windows usb sniffer (like sysinternals etc)?

 :palm: ARChon doesn't support the USB Port  :(

PS: https://developer.chrome.com/apps/getstarted_arc
Quote
PC, Mac, Linux, or Chromebook on Chrome Version 41+.

    Note: ARC is no longer supported on 32-bit x86 platforms and those platforms will no longer receive updates after October 13, 2015. All ARM platforms will continue to work and receive updates.
« Last Edit: October 08, 2015, 11:10:25 am by tomas123 »
 

Offline Fraser

  • Super Contributor
  • ***
  • Posts: 9307
  • Country: gb
Re: Question about FLIR One for Android
« Reply #18 on: October 08, 2015, 12:26:05 pm »
I received my replacement F1G2 this week. From my conversations with Bill Terre, VP FLIR, it is apparent that demand has far outstripped supply of this little camera. FLIR were not expecting such initial demand for the unit. This is good news as it will hopefully lead to a healthy user base and community support.

It is obvious from FLIRs invitation to developers to create new apps that they wish to encourage product development in many areas. It would be worth registering as a developer on the FLIR ONE web site as this gives access to the SDK, developer documentation and the community forum.

I can foresee the development of applications that run on Windows, Linux, Android etc.If FLIR really want to 'own' this market segment they may be willing to provide developer information for cross platform use.

Bill Terre is VP, GM and OEM market development so an email to him may gain a useful response. Bill is a gentleman and he has been very friendly and helpful to me in recent communications. Great chap.

I have been looking at the cheap Android TV boxes this week to see if they would run the FLIR ONE app. They are really just an ARM based computer and many will run most Android apps with a keyboard and mouse. They have a suitable USB port so should work. The issue will be processor power. Most TV boxes use older ARMtechnology, such as ARM 5 or 7.not great for the FLIR ONE app.

For those unaware, the FLIR ONE Android app was developed on a Samsung S5 and FLIR expect users to use similar powerful hardware. The S5 runs its modern processor at 2.5 GHz.

IMHO, the F1G2 should be considered a very reasonably priced thermal imaging building block. I see no reason to limit its use to just phones and tablets running Android. With a ZnSe close up lens it would make a cheap PCB thermal profiling camera. It could be run on a micro USB cable from a desktop host.

I am hopeful that the F1G2 will become a ground breaking camera that is embraced by the maker community. FLIR will likely release the LEPTON 3  as a part once the demand for the F1G2 can be met.

In the mean time FLIR are looking at placing thermal camera technology into all manner of test products. I have seen the new clamp meter and expect to see a thermal camera equipped multimeter in the future. The LEPTON is so small that it may be incorporated into many devices. Thermal imaging for the masses is coming. The F1G2 could become the VW Beetle of thermal cameras.

Fraser
« Last Edit: October 08, 2015, 12:30:55 pm by Fraser »
 

Offline Balaur

  • Supporter
  • ****
  • Posts: 525
  • Country: fr
Re: Question about FLIR One for Android
« Reply #19 on: October 08, 2015, 03:47:01 pm »
Bummer, I've just received a mail from the eBay seller where I've ordered the Flir One. According to this message, FLIR announced that they had a huge (and unexpected?) success with this product and will not be able to meet the promised delivery times. (Apparently more than 2 million devices have been pre-ordered)

Shipments originally expected on Sep 30 have now a delay of 6 to 8 weeks and will be rationed (fairly?).
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: ca
Re: Question about FLIR One for Android
« Reply #20 on: October 08, 2015, 04:19:36 pm »
And because of Flir's creepy practice to phone home (will this nice feature be embedded into the SDK?), it is a good time fo Flir to get a better "home" server to handle the increased volume of data.
Facebook-free life and Rigol-free shack.
 

Offline cynfab

  • Regular Contributor
  • *
  • Posts: 150
Re: Question about FLIR One for Android
« Reply #21 on: October 08, 2015, 04:50:35 pm »
Fraser,

My F1G2 works well on the Hardkernel XU4,
at < $US100, with an octa core processor, it's quite snappy with the F1 app. Runs Android or one of several flavours of Linux.

I am a Flir Registered dev. and have their SDK. So far, only Android, and it is a bit fiddly to get working.
I have been able to build the sample app, and although they say it will run on Android 4.x, my 4.4.2 tablet refuses to load it.
My 5.1.1 tablet loads & runs it, but it crashes. I need to get adb over wifi working again so I can see what's going on.
I think that there are some files missing from the built .apk file, but I need some time to play with it some more.
 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #22 on: November 11, 2015, 05:01:54 pm »
There is some RE going on, just not as obvious as in the early E4 and Seek days.

Attached is a annotated dump of the first few seconds of usb activity between a F1G2 and the F1 Android app.
It's not finished.
There may be inaccuracies.
There is much more to uncover.
This is a long way from a stand alone PC program.
Your mileage may vary.
blah, blah, blah.

Hi cynfab,

you dumped the usb traffic.

I wrote here and in the following posts some nice details about the Flir One SDK app.
https://www.eevblog.com/forum/testgear/actual-resolution-of-flir-one-v2/msg797214/#msg797214

The SDK contain a compiled modul flironesdk.aar with a system library libjnidevicewrapper.so and a classes.jar
With classes.jar we get some interesting details about the USB protocol like the endpoint numbers.

Code: [Select]
package com.flir.flironesdk.usb;

import android.hardware.usb.UsbDevice;
import android.hardware.usb.UsbDeviceConnection;
import android.hardware.usb.UsbEndpoint;
import android.hardware.usb.UsbInterface;
import android.hardware.usb.UsbRequest;
import android.util.Log;
import java.io.Closeable;
import java.nio.ByteBuffer;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Map.Entry;

public class UsbCommunicator
  implements Closeable
{
  private boolean IS_SIMULATED;
  private Delegate mDelegate;
  private volatile UsbDeviceConnection connection;
  private static final String LOG_TAG = "UsbCommunicator";
  private static final int SET_INTERFACE = 11;
  private static final int CTRL_TRANSFER_TIMEOUT = 200;
  static final int FRAME_READ_ENDPOINT_ID = 5;
  static final int CONFIG_READ_ENDPOINT_ID = 1;
  static final int CONFIG_WRITE_ENDPOINT_ID = 2;
  static final int FILEIO_READ_ENDPOINT_ID = 3;
  static final int FILEIO_WRITE_ENDPOINT_ID = 4;
  static final int SUPPORTED_VENDOR_ID = 2507;
  static final int SUPPORTED_PRODUCT_ID = 6550;
  private UsbEndpoint configWriteEndpoint;
 
  public static abstract interface Delegate
  {
    public abstract void onDataReceived(byte[] paramArrayOfByte, UsbCommunicator.ProtocolType paramProtocolType);
   
    public abstract void onCommunicationAvailabilityChange(boolean paramBoolean);
  }
 
  public static enum ProtocolType
  {
    CONFIGURATION((byte)1),  FILEIO((byte)2),  FRAME((byte)4);
   
    private final byte value;
   
    private ProtocolType(byte value)
    {
      this.value = value;
    }
   
    byte getValue()
    {
      return this.value;
    }
  }
 
  private UsbEndpoint fileioWriteEndpoint = null;
  final UsbRequest frameReadRequest = new UsbRequest();
  final UsbRequest fileioReadRequest = new UsbRequest();
  final UsbRequest configReadRequest = new UsbRequest();
  private UsbDevice mDevice;
  volatile boolean connected = false;
  volatile boolean expectFrameData = false;
  volatile boolean expectFileData = false;
 
  public static boolean deviceIsValid(UsbDevice device)
  {
    try
    {
      validateDevice(device);
      return true;
    }
    catch (Exception e)
    {
      Log.e("UsbCommunicator", "Invalid device: " + e.getMessage());
    }
    return false;
  }
 
  public static void validateDevice(UsbDevice device)
    throws Exception
  {
    if (device.getVendorId() != 2507) {
      throw new Exception("Unsupported USB Vendor ID of " + Integer.toHexString(device.getVendorId()));
    }
    if (device.getProductId() != 6550) {
      throw new Exception("Unsupported USB Product ID of " + Integer.toHexString(device.getProductId()));
    }
    int ifaceCount = device.getInterfaceCount();
    HashMap<Integer, Boolean> inEndpointsFound = new HashMap();
    HashMap<Integer, Boolean> outEndpointsFound = new HashMap();
    inEndpointsFound.put(Integer.valueOf(3), Boolean.valueOf(false));
    inEndpointsFound.put(Integer.valueOf(1), Boolean.valueOf(false));
    inEndpointsFound.put(Integer.valueOf(5), Boolean.valueOf(false));
    outEndpointsFound.put(Integer.valueOf(2), Boolean.valueOf(false));
    outEndpointsFound.put(Integer.valueOf(4), Boolean.valueOf(false));
    UsbInterface iface;
    for (int i = 0; i < ifaceCount; i++)
    {
      iface = device.getInterface(i);
     
      int endpointCount = iface.getEndpointCount();
      for (int e = 0; e < endpointCount; e++)
      {
        UsbEndpoint ep = iface.getEndpoint(e);
        if (ep.getDirection() == 128) {
          inEndpointsFound.put(Integer.valueOf(ep.getEndpointNumber()), Boolean.valueOf(true));
        } else {
          outEndpointsFound.put(Integer.valueOf(ep.getEndpointNumber()), Boolean.valueOf(true));
        }
      }
    }
    HashSet<Map.Entry<Integer, Boolean>> allEndpointsFound = new HashSet();
    allEndpointsFound.addAll(inEndpointsFound.entrySet());
    allEndpointsFound.addAll(outEndpointsFound.entrySet());
    for (Map.Entry<Integer, Boolean> endpoint : allEndpointsFound) {
      if (!((Boolean)endpoint.getValue()).booleanValue()) {
        throw new Exception("Unable to communicate with USB device, endpoint " + ((Integer)endpoint.getKey()).toString() + " not found");
      }
    }
  }
 
  public UsbCommunicator(UsbDevice device, UsbDeviceConnection usbConnection, Delegate delegate)
    throws Exception
  {
    validateDevice(device);
   
    this.mDelegate = delegate;
    this.connection = usbConnection;
    this.mDevice = device;
   
    int ifaceCount = device.getInterfaceCount();
    for (int i = 0; i < ifaceCount; i++)
    {
      UsbInterface iface = device.getInterface(i);
      if (false == this.connection.claimInterface(iface, false))
      {
        Log.e("UsbCommunicator", "Unable to claim interface " + iface.getId() + ", close connection and try again.");
        delegate.onCommunicationAvailabilityChange(false);
        throw new Exception("Unable to claim USB interface");
      }
      int endpointCount = iface.getEndpointCount();
      for (int e = 0; e < endpointCount; e++)
      {
        UsbEndpoint ep = iface.getEndpoint(e);
        if (ep.getDirection() == 128) {
          switch (ep.getEndpointNumber())
          {
          case 5:
            this.frameReadRequest.initialize(this.connection, ep);
            break;
          case 1:
            this.configReadRequest.initialize(this.connection, ep);
            break;
          case 3:
            this.fileioReadRequest.initialize(this.connection, ep);
            break;
          case 2:
          case 4:
          default:
            Log.w("UsbCommunicator", "Unknown USB_DIR_IN Endpoint on device!");break;
          }
        } else {
          switch (ep.getEndpointNumber())
          {
          case 2:
            this.configWriteEndpoint = ep;
            break;
          case 4:
            this.fileioWriteEndpoint = ep;
            break;
          default:
            Log.w("UsbCommunicator", "Unknown USB_DIR_OUT Endpoint on device!");
          }
        }
      }
    }
    if (this.fileioWriteEndpoint != null)
    {
      stopCommunication(ProtocolType.FRAME);
      stopCommunication(ProtocolType.FILEIO);
    }
    else
    {
      delegate.onCommunicationAvailabilityChange(false);
    }
  }
 
  final int CONFIG_BUFFER_SIZE = 4096;
  final int FRAME_BUFFER_SIZE = 131072;
  final int FILE_BUFFER_SIZE = 1048576;
  final ByteBuffer configBuffer = ByteBuffer.allocate(4096);
  final ByteBuffer frameBuffer = ByteBuffer.allocate(131072);
  final ByteBuffer fileBuffer = ByteBuffer.allocate(1048576);
 
  private void pollEndpoints()
  {
    new Thread(new Runnable()
    {
      public void run()
      {
        Log.d("configReadRequest", "Starting configReadRequest poll loop...");
        UsbCommunicator.this.configReadRequest.queue(UsbCommunicator.this.configBuffer, 4096);
        while (UsbCommunicator.this.connected)
        {
          UsbRequest requestResult = UsbCommunicator.this.connection.requestWait();
          synchronized (UsbCommunicator.this.configReadRequest)
          {
            if (!UsbCommunicator.this.connected) {
              break;
            }
            if (requestResult == UsbCommunicator.this.configReadRequest)
            {
              byte[] data = new byte[UsbCommunicator.this.configBuffer.position()];
              UsbCommunicator.this.configBuffer.flip();
              UsbCommunicator.this.configBuffer.get(data);
              if (data.length > 0) {
                UsbCommunicator.this.mDelegate.onDataReceived(data, UsbCommunicator.ProtocolType.CONFIGURATION);
              }
              UsbCommunicator.this.configBuffer.clear();
              UsbCommunicator.this.configReadRequest.queue(UsbCommunicator.this.configBuffer, 4096);
            }
            else if (requestResult == UsbCommunicator.this.frameReadRequest)
            {
              byte[] data = new byte[UsbCommunicator.this.frameBuffer.position()];
              UsbCommunicator.this.frameBuffer.flip();
              UsbCommunicator.this.frameBuffer.get(data);
              if (data.length > 0) {
                UsbCommunicator.this.mDelegate.onDataReceived(data, UsbCommunicator.ProtocolType.FRAME);
              }
              if (UsbCommunicator.this.expectFrameData) {
                UsbCommunicator.this.frameReadRequest.queue(UsbCommunicator.this.frameBuffer, 131072);
              }
              UsbCommunicator.this.frameBuffer.clear();
            }
            else if (requestResult == UsbCommunicator.this.fileioReadRequest)
            {
              byte[] data = new byte[UsbCommunicator.this.fileBuffer.position()];
              UsbCommunicator.this.fileBuffer.flip();
              UsbCommunicator.this.fileBuffer.get(data);
              UsbCommunicator.this.mDelegate.onDataReceived(data, UsbCommunicator.ProtocolType.FILEIO);
              UsbCommunicator.this.fileBuffer.clear();
              if (UsbCommunicator.this.expectFileData) {
                UsbCommunicator.this.fileioReadRequest.queue(UsbCommunicator.this.fileBuffer, 1048576);
              }
            }
          }
        }
      }
    })
   
      .start();
  }
 
  public UsbCommunicator(Delegate usbDelegate)
  {
    Log.i("UsbCommunicator", "Simulated device constructor");
    this.mDelegate = usbDelegate;
    this.IS_SIMULATED = true;
  }
 
  private void sendData(UsbEndpoint ep, byte[] data, int length)
  {
    Log.d("UsbCommunicator", "Sending " + length + " bytes on EP" + ep.getEndpointNumber());
    synchronized (this.connection)
    {
      int offset = 0;
      while (offset < length)
      {
        int result = this.connection.bulkTransfer(ep, data, offset, length - offset, 500);
        if (result > 0)
        {
          Log.d("UsbCommunicator", "Bulk transfer sent " + result + " bytes on Endpoint " + ep.getEndpointNumber());
          offset += result;
        }
        else
        {
          Log.w("UsbCommunicator", "Bulk Transfer Failed on Endpoint " + ep.getEndpointNumber());
        }
      }
    }
  }
 
  native void sendConfigDataToSimulatedDevice(byte[] paramArrayOfByte);
 
  public void sendDataToDevice(byte[] data, ProtocolType protocolType)
  {
    if (this.IS_SIMULATED)
    {
      switch (protocolType)
      {
      case CONFIGURATION:
        sendConfigDataToSimulatedDevice(data);
        break;
      }
    }
    else
    {
      UsbEndpoint destinationEndpoint;
      UsbEndpoint destinationEndpoint;
      switch (protocolType)
      {
      case CONFIGURATION:
        destinationEndpoint = this.configWriteEndpoint;
        break;
      case FILEIO:
        destinationEndpoint = this.fileioWriteEndpoint;
        break;
      default:
        Log.w("UsbCommunicator", "Attempted to send data on knosupported protocol!"); return;
      }
      UsbEndpoint destinationEndpoint;
      sendData(destinationEndpoint, data, data.length);
    }
  }
 
  public void sendConfigData(byte[] data)
  {
    sendDataToDevice(data, ProtocolType.CONFIGURATION);
  }
 
  public void sendFileioData(byte[] data)
  {
    sendDataToDevice(data, ProtocolType.FILEIO);
  }
 
  public void close()
  {
    if (this.connected)
    {
      pause();
     
      this.connection.close();
      this.mDelegate.onCommunicationAvailabilityChange(false);
      Log.d("UsbCommunicator", "Connection closed.");
    }
  }
 
  public void pause()
  {
    if (this.connected)
    {
      synchronized (this.configReadRequest)
      {
        stopFrames();
        stopCommunication(ProtocolType.FILEIO);
        this.connected = false;
        this.configReadRequest.cancel();
        this.configBuffer.clear();
       
        this.fileioReadRequest.cancel();
       
        this.frameReadRequest.cancel();
      }
      this.mDelegate.onCommunicationAvailabilityChange(false);
    }
  }
 
  private void startFrames()
  {
    startCommunication(ProtocolType.FRAME);
  }
 
  private void stopFrames()
  {
    stopCommunication(ProtocolType.FRAME);
  }
 
  private void startCommunication(ProtocolType protocolType)
  {
    toggleCommunication(protocolType, true);
  }
 
  private void stopCommunication(ProtocolType protocolType)
  {
    toggleCommunication(protocolType, false);
  }
 
  private void toggleCommunication(ProtocolType protocolType, boolean startCommunication)
  {
    if (this.IS_SIMULATED == true) {
      return;
    }
    switch (protocolType)
    {
    case FRAME:
      int interfaceNumber = 2;
      this.expectFrameData = startCommunication;
      this.frameBuffer.clear();
      if (this.expectFrameData) {
        this.frameReadRequest.queue(this.frameBuffer, 131072);
      }
      break;
    case FILEIO:
      int interfaceNumber = 1;
      this.expectFileData = startCommunication;
      this.fileBuffer.clear();
      if (this.expectFileData) {
        this.fileioReadRequest.queue(this.fileBuffer, 1048576);
      }
      break;
    case CONFIGURATION:
      Log.w("UsbCommunicator", "Configuration Protocol cannot be started or stopped.");
    default:
      return;
    }
    int interfaceNumber;
    int altSetting = startCommunication ? 1 : 0;
    synchronized (this.connection)
    {
      int result = this.connection.controlTransfer(1, 11, altSetting, interfaceNumber, null, 0, 200);
      Log.d("UsbCommunicator", "Result from control transfer: " + result);
    }
  }
 
  public void connect()
  {
    if (!this.connected)
    {
      this.connected = true;
      this.mDelegate.onCommunicationAvailabilityChange(true);
      startCommunication(ProtocolType.FILEIO);
      pollEndpoints();
    }
  }
}
« Last Edit: November 11, 2015, 05:04:31 pm by tomas123 »
 

Offline cynfab

  • Regular Contributor
  • *
  • Posts: 150
Re: Question about FLIR One for Android
« Reply #23 on: November 11, 2015, 06:05:33 pm »
Thanks for that,
I've been tied up with other projects,
I was able to recompile the example app from the sdk, but it just crashed on the 2 tablets I use for the Flir ONE, I was a bit disappointed, till you posted about the cropping issues. So I tried your recompilation, and found it did the same thing. I then tried it on my Odroid XU4, and it works just fine!. So I believe that there is a performance issue with the Example App and if your phone/tablet doesn't have the horsepower it just crashes.

I'll take a look at what you just posted as soon as I cand find some time.


   ...ken...
 

Offline tomas123

  • Frequent Contributor
  • **
  • Posts: 832
  • Country: de
Re: Question about FLIR One for Android
« Reply #24 on: November 12, 2015, 09:23:33 pm »
So I believe that there is a performance issue with the Example App and if your phone/tablet doesn't have the horsepower it just crashes.

I compiled also against the old SDK 1.0.1 ( FLIROneSDK-Android-1_0_1.zip )

there is  newer version
Quote
SDK 1.0.2

CHANGE LOG

Improves reliability of saving and loading frames.


The file size of system library  libjnidevicewrapper.so is shrinked from 33MB to 16MB  :-+

try it
« Last Edit: November 12, 2015, 09:26:43 pm by tomas123 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf