-
Turned off the highway this morning and took this photo of the Flir office right north of Stockholm, where I understood that my camera is "designed and engineered", and where they come up with passwords like 3vlig, thank you Flir for making it possible for me to own a 320x240 TIC!
This is MSX@320x240, when I look at it in pure termal image, it's apparent that I need to go for the T-series
I thought the floors and some of the chairs in there would have been a LOT hotter...
-
Quote
I thought the floors and some of the chairs in there would have been a LOT hotter...
Actually, the thermal camera cannot see through the glass. It's only the MSX outlines (from the regular camera) of the chairs etc inside the building that you are seeing -
If you were a thermal imaging comany, wouldn't it be fun to have a logo on your building that was only visible through a TIC...QuoteI thought the floors and some of the chairs in there would have been a LOT hotter...
Actually, the thermal camera cannot see through the glass. It's only the MSX outlines (from the regular camera) of the chairs etc inside the building that you are seeing
..or on a smaller scale, how about some T-shirts printed in inks with different emissivities, with logos you can only see with a TIC...
-
Received my camera today
from Alpha Electronics Maidstone UK. Camera is made in Estonia.
SW version 1.19.8
Calibration date: November 22 2013.
Just installing FLIR tools... -
If you were a thermal imaging comany, wouldn't it be fun to have a logo on your building that was only visible through a TIC...
Perhaps the FLIR guys could borrow this tech (also developed in Sweden):
-
It looks like the rumors about FLIR making the E4 "hack-proof" are just that - rumors.
-
testing firmware takes time, they wouldn't want to rush out some crappy firmware, that would be extremely bad advertisement.
-
How's the Linux-based E4->E8 transition looking? mrflibble posted the autohack https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg333051/#msg333051 but things on the Windows side seem to have advanced quite a bit since then. And it doesn't have a README.
So, should I go with the flow and set up a one-time Windows VM? Or should I go for glory on Linux (which I expect would require re-reading everything posted since around page 50...?)
Gotta say, this camera has already been surprisingly useful. Looking forward to when they cost $200 and everyone has one. -
Turned off the highway this morning and took this photo of the Flir office right north of Stockholm, where I understood that my camera is "designed and engineered", and where they come up with passwords like 3vlig, thank you Flir for making it possible for me to own a 320x240 TIC!
This is MSX@320x240, when I look at it in pure termal image, it's apparent that I need to go for the T-series
Ah! This is great! I hope they don't take this as an insult, we all love FLIR and this photo proves the influence of this forum on the electronics industry, great job ullki.
Indeed, maybe I should be explicit about that: This was by no means meant as an insult but rather as a tribute, to all you Flir employees out there: you make (well develop) some awesome hardware inside that glass facade, thank you very much! I'm now* a proud Flir TIC owner and will try my best to promote your products!
* Yes, I'm not a lost E8 customer but rather a gained new customer that only went for the E4 due to the upgrade-ability, so you made an additional $1000 on me (actually, in Sweden it's considerably more expensive than that, must be very costly to ship it across the Baltic Sea )
/U -
will knot soon if last batch of 62 unit on tequipment was 1.2.x or not
To Be Shipped
Estimated Ship Date: 11/26/2013
(1 day) -
How's the Linux-based E4->E8 transition looking? mrflibble posted the autohack https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg333051/#msg333051 but things on the Windows side seem to have advanced quite a bit since then. And it doesn't have a README.
I'm sure if you ask nicely someone will CRC01 a file with your serial number, but it shouldn't be a problem for anyone who speaks Linux or Mac to recompile the CRC01 source
So, should I go with the flow and set up a one-time Windows VM? Or should I go for glory on Linux (which I expect would require re-reading everything posted since around page 50...?)
Gotta say, this camera has already been surprisingly useful. Looking forward to when they cost $200 and everyone has one. -
will knot soon if last batch of 62 unit on tequipment was 1.2.x or not
Now 51.... still flying off the shelves!
To Be Shipped
Estimated Ship Date: 11/26/2013
(1 day) -
I have a feeling FLIR is creating rumors of the "fix" to get people to buy more E4's.
-
i found the great Mike tread just this week end
and when buy my saturday have 60 left
so yup may have a rush before to late ;-0 ,or it fault of santa claus
-
i found the great Mike tread just this week end
and when buy my saturday have 60 left
so yup may have a rush before to late ;-0 ,or it fault of santa claus
almost hope it 1.2 just for the fun
-
I just wanted to share a tip for a nice little focus tool: an automotive fuse! For macro thermal vision I just turn it CC half a turn to almost a full turn. Fine tuning is only a matter of going closer or further away with my E4-8.
Some hot shots to lighten up this great forum:
-
How's the Linux-based E4->E8 transition looking? mrflibble posted the autohack https://www.eevblog.com/forum/testgear/flir-e4-thermal-imaging-camera-teardown/msg333051/#msg333051 but things on the Windows side seem to have advanced quite a bit since then. And it doesn't have a README.
So, should I go with the flow and set up a one-time Windows VM? Or should I go for glory on Linux (which I expect would require re-reading everything posted since around page 50...?)
Gotta say, this camera has already been surprisingly useful. Looking forward to when they cost $200 and everyone has one.
You can run the original crc01.exe under wine. It worked fine for me, gave me the same CRC as it did running under Win 7.
What would really be useful is for someone to set up a VM with Win 7 in it and do a packet capture (WireShark) of the transactions that occur over the USB/Ethernet when the flir drivers talk to the RNDIS DHCP server on the camera.
I've tried setting a linux pc up with a static address of 192.168.0.1 and 192.168.1.1 (both of which I've seen my Win7 PC get from the camera) to no avail. I'm thinking that the flir drivers are using a non-standard port for DHCP or some other magic handshake with the camera. WireShark under native Win 7 will not capture USB transactions.
It would really be nice to be able to talk to the camera via telnet/ftp/http from linux.
I haven't seen this mentioned before (but may have missed it). Point your web browser at the IP of the camera when connected via RNDIS... Quite a lot of info there, but be carefull!!! don't do any fiddling with the calibration pages, or things might get upset.
Again, many heartfelt thanks to Mike and all the others that contributed to this hack.
...ken... -
What would really be useful is for someone to set up a VM with Win 7 in it and do a packet capture (WireShark) of the transactions that occur over the USB/Ethernet when the flir drivers talk to the RNDIS DHCP server on the camera.
I've tried setting a linux pc up with a static address of 192.168.0.1 and 192.168.1.1 (both of which I've seen my Win7 PC get from the camera) to no avail. I'm thinking that the flir drivers are using a non-standard port for DHCP or some other magic handshake with the camera. WireShark under native Win 7 will not capture USB transactions.
It would really be nice to be able to talk to the camera via telnet/ftp/http from linux.
I would probably dig through docs on the RNDIS standard. From what i remember RNDIS emulates a point to point ethernet link that appears to an OS as ethernet, but the lower layers are fudged - at least that's the way i think of it. If you do a release/renew the RNDIS adaptor gets upset and will not get a new IP, probably does not support this. You have to unplug-replug to restore connectivity. Like i say the lower layers are fudged because there will only ever be two hosts on the "network".
Google for "[MS-RNDIS].pdf"
I had a go anyway with Wireshark, it's tricky to sniff what is happening because the RNDIS interface is not available until the camera is plugged in. However if you are quick you can capture some initial traffic. The camera appears to offer an address to itself, the source MAC appears to be from an unknown vendor - will send you the grab if you like.
I used to use a program called "USB Trace" years ago do do USB sniffing, was playing with an FTDI USB Host module at the time. Looks like it is still around, http://www.sysnucleus.com/. This was great because you could set it running and watch the whole init process as you plugged a device in and of course pick through the protocol. -
Quote
What would really be useful is for someone to set up a VM with Win 7 in it and do a packet capture (WireShark) of the transactions that occur over the USB/Ethernet when the flir drivers talk to the RNDIS DHCP server on the camera.
Not sure why this would be particularly useful, compared to rev-enging the protocol they use for firmware updates over USB UVC, as that would be a more likely way in if RNDIS got disabled as a hack countermeasure. -
Mike,
That would certainly be useful as well, and would require the same USB sniffing/recording setup as figuring out the RNDIS DHCP. Time will tell as to what version 1.2.? will bring.
MrSquirrel,
I'd like to see the dump you got, may give me some ideas. Thanks..
I had gotten the MS-RNDIS .pdf a while ago and at first read, it's DHCP seemed like it should work with a linux client. But I will read it again.
I haven't set up a VM with Win 7 for lack of Win 7. I ran it on my desktop for the first time since I bought the box, just to update my E4 to E8+. I took many hours to update Win 7 before I could begin installing the flir tools.
I might try Win 7 again to use the "USB Trace" program.
-
Quote
What would really be useful is for someone to set up a VM with Win 7 in it and do a packet capture (WireShark) of the transactions that occur over the USB/Ethernet when the flir drivers talk to the RNDIS DHCP server on the camera.
Not sure why this would be particularly useful, compared to rev-enging the protocol they use for firmware updates over USB UVC, as that would be a more likely way in if RNDIS got disabled as a hack countermeasure.
I've been doing some reversing on the USB protocol, but I stopped. Amusingly enough exactly with the above setup, not sure if I mentioned it somewhere. win7-64 in a virtualbox. That's how I applied the E8 hack as well. That's also how I run my telnet scripts. win7 guest sets up the link, and then I ssh tunnel to the linux guest. That way you have the ports of the flir available on your linux localhost. I would have preferred using native rndis on linux directly to the flir, but that was a nogo. I'm pretty sure I
about that, because it's damn annoying. I hope it's just a matter of me using an old kernel or me being stupid. That way there should be an easy fix for it.
Oh yeah, tip du jour when setting up rndis etc in vm... I get the best results when I killed the IRCAM somethingsomething in the system tray. You get that one after you install the Flir RNDIS drivers. So the low level drivers are okay, but the "handy tool" only gets in the way...
I was busy reversing the command protocol over UVC, but then I decided that using the camera through telnet+ftp interface made a bit more sense in terms of flushing time.
So on the linux side it would be more productive to get rndis working. Or maybe it's already working for you because you have a more recent kernel and/or I am being silly.
As in for the functionality, having rndis working properly without needing a VM would be action #1. After that a libusb based tool to do commands/updates over UVC would be #2 IMO. Too bad that for me right now #0 is "Use Camera" and other non-E4 related things.
Oh yeah, re VM ... you obviously have to pass the USB device through to the VM. I think I listed the various USB ID's somewhere earlier on... I'll just paste it here...Code: [Select]MSD : 09cb:ffff
UVC : 09cb:1004
RNDIS : 09cb:1002
RNDIS and UVC : 09cb:1005
RNDIS and MSD : 09cb:1006
UVC and MSD (standard): 09cb:1007
RNDIS, UVC and MSD : 09cb:1005
Re: RNDIS + DHCP... From the win7 guest this is working. When using native rndis on linux I can see the USB payloads for a dhcp request going from linux box to flir. Payload looks proper (using wireshark to snoop usb traffic). However, no return URBs from flir. So it's silently dropping those because it hasn't seen the proper handshake yet.
After a couple more tries I went a screw it, and telnet through the VM. After all, there are thermal images to be made...
-
mrflibble,
I tried the camera on several different kernels,
3.5.? x86 Linux Mint
3.8.13 Arm Cortex A8 Angstrom
2.6.31 x86-64 Ubuntu 9.10
3.8.0 x86-64 Ubuntu 13.04
All had the same (lack of) DHCP performance.
When I ran WireShark on Ubuntu 13.04 I could see the USB data encapsulating the Ethernet DHCP requests when I monitored the USB interface, I could also monitor the "derived" Ethernet interface and see DHCP requests going over to the camera, but nothing coming back.
Googling rndis ,linux, WinCE 6 gets lots of hits on people using linux to talk to WinCE devices via RNDIS. Sooo, I think it is possible, there is just something about the flir WinCE build.
-
All had the same (lack of) DHCP performance.
Exactly all of that, yes.
When I ran WireShark on Ubuntu 13.04 I could see the USB data encapsulating the Ethernet DHCP requests when I monitored the USB interface, I could also monitor the "derived" Ethernet interface and see DHCP requests going over to the camera, but nothing coming back.
Googling rndis ,linux, WinCE 6 gets lots of hits on people using linux to talk to WinCE devices via RNDIS. Sooo, I think it is possible, there is just something about the flir WinCE build.
Like I said, you see the DHCP request (encapsulated in URB) going to the flir, but the E4 never even sends an acknowledge of the URB. Almost as if it is just not servicing that endpoint. Although it probably is, but just silently dropping it.
I have also tried static ip + route + arp, but no dice. So my suspicion is that Flir did something not 100% standard in their rndis drivers. Oh and on kernel 3.3.4 it doesn't work either.
-
So here is an interesting point, when I connected my E4 to my Win 7 PC, that already had an ethernet connection to my 192.168.0.x network, the new ethernet interface created when the camera was connected got 192.168.1.1. So the camera must have exchanged enough data with the PC to realize that the 192.168.0.x net was already in use. Just like DHCP should be behaving. This is why I think sniffing that interface while Win 7 + flir drivers negotiate the DHCP lease will be enlightening.
BTW if i disabled the 192.168.0.x ethernet interface before connecting the camera, the usb-->camera "ethernet" then got 192.168.0.1. -
Here is the DHCP capture file. You always get that malformed packet which seems to confuse Windows initally.
I don't know the Linux equivalent but there are Windows command line tools (i forget the name of) you can use to "replay" packets captured in a Wireshark grab back out an interface. That is sometimes useful when debugging when you have a known good trace.